Update container images translation (#16594)

pull/16732/head
Philippe MARTIN 2019-10-07 23:15:11 +02:00 committed by Kubernetes Prow Robot
parent 69adf15e49
commit 7b7082c0c4
1 changed files with 18 additions and 10 deletions

View File

@ -59,15 +59,17 @@ Ces certificats peuvent être fournis de différentes manières :
- par cluster
- automatiqueent configuré dans Google Compute Engine ou Google Kubernetes Engine
- tous les pods peuvent lire le registre privé du projet
- En utilisant AWS EC2 Container Registry (ECR)
- En utilisant Amazon Elastic Container Registry (ECR)
- utilise des rôles et politiques IAM pour contrôler l'accès aux dépôts ECR
- rafraîchit automatiquement les certificats de login ECR
- En utilisant Oracle Cloud Infrastructure Registry (OCIR)
- utilisez les rôles et politiques IAM pour contrôler l'accès aux dépôts OCIR
- En utilisant Azure Container Registry (ACR)
- En utilisant IBM Cloud Container Registry
- En configurant les nœuds pour s'authentifier auprès d'un registre privé
- tous les pods peuvent lire les registres privés configurés
- nécessite la configuration des nœuds par un administrateur du cluster
- En pré-chargeant les images
- En utilisant des images pré-chargées
- tous les pods peuvent utiliser toutes les images mises en cache sur un nœud
- nécessite l'accès root à tous les nœuds pour la mise en place
- En spécifiant ImagePullSecrets dans un Pod
@ -87,10 +89,9 @@ Kubelet va s'authentifier auprès de GCR en utilisant le compte de service Googl
Le compte de service dans l'instance aura un `https://www.googleapis.com/auth/devstorage.read_only`,
afin qu'il puisse récupérer depuis le GCR du projet mais qu'il ne puisse pas pousser une image.
### Utiliser AWS EC2 Container Registry
### Utiliser Amazon Elastic Container Registry
Kubernetes prend en charge nativement [AWS EC2 Container
Registry](https://aws.amazon.com/ecr/), lorsque les nœuds sont des instances de AWS EC2.
Kubernetes prend en charge nativement [Amazon Elastic Container Registry](https://aws.amazon.com/ecr/), lorsque les nœuds sont des instances de AWS EC2.
Utilisez simplement le nom complet de l'image (par ex. `ACCOUNT.dkr.ecr.REGION.amazonaws.com/imagename:tag`)
dans la définition du Pod.
@ -195,8 +196,8 @@ Voici les étapes recommandées pour configurer vos nœuds pour qu'ils utilisent
Vérifiez en créant un pod utilisant une image privée, par ex. :
```yaml
kubectl create -f - <<EOF
```shell
kubectl apply -f - <<EOF
apiVersion: v1
kind: Pod
metadata:
@ -228,7 +229,7 @@ Vous devez vous assurer que tous les nœuds du cluster ont le même fichier `.do
Tous les pods auront un accès en lecture aux images d'un registre privé dès que les clés du registre privé sont ajoutées au fichier `.docker/config.json`.
### Pré-chargement des images
### Images pré-chargées
{{< note >}}
Si vous travaillez dans Google Kubernetes Engine, vous trouverez un `.dockercfg` sur chaque nœud avec les certificats pour Google Container Registry. Vous ne pourrez pas utiliser cette méthode.
@ -263,7 +264,7 @@ Kubernetes permet de spécifier des clés de registre dans un pod.
Exécutez la commande suivante, en substituant les valeurs en majuscule :
```shell
kubectl create secret docker-registry myregistrykey --docker-server=SERVEUR_REGISTRE_DOCKER --docker-username=UTILISATEUR_DOCKER --docker-password=MOT_DE_PASSE_DOCKER --docker-email=EMAIL_DOCKER
kubectl create secret docker-registry <name> --docker-server=SERVEUR_REGISTRE_DOCKER --docker-username=UTILISATEUR_DOCKER --docker-password=MOT_DE_PASSE_DOCKER --docker-email=EMAIL_DOCKER
secret/myregistrykey created.
```
@ -282,7 +283,8 @@ ces étapes doivent donc être faites pour chaque namespace.
Vous pouvez maintenant créer des pods qui référencent ce secret en ajoutant une section `imagePullSecrets`
dans la définition du pod.
```yaml
```shell
cat <<EOF > pod.yaml
apiVersion: v1
kind: Pod
metadata:
@ -294,6 +296,12 @@ spec:
image: janedoe/awesomeapp:v1
imagePullSecrets:
- name: myregistrykey
EOF
cat <<EOF >> ./kustomization.yaml
resources:
- pod.yaml
EOF
```
Ceci doit être fait pour chaque pod utilisant un registre privé.