web-dev-qa-db-fra.com

AKS. Impossible de tirer l'image d'un acr

J'essaie de tirer une image d'un ACR en utilisant un secret et je ne peux pas le faire.

J'ai créé des ressources à l'aide des commandes Azure cli:

az login
az provider register -n Microsoft.Network
az provider register -n Microsoft.Storage
az provider register -n Microsoft.Compute
az provider register -n Microsoft.ContainerService

az group create --name aksGroup --location westeurope

az aks create --resource-group aksGroup --name aksCluster --node-count 1 --generate-ssh-keys -k 1.9.2
az aks get-credentials --resource-group aksGroup --name aksCluster

az acr create --resource-group aksGroup --name aksClusterRegistry --sku Basic --admin-enabled true

Après cela, je me suis connecté et j'ai poussé l'image avec succès pour créer ACR à partir de la machine locale.

docker login aksclusterregistry.azurecr.io
docker tag jetty aksclusterregistry.azurecr.io/jetty
docker Push aksclusterregistry.azurecr.io/jetty

L'étape suivante consistait à créer un secret:

kubectl create secret docker-registry secret --docker-server=aksclusterregistry.azurecr.io --docker-username=aksClusterRegistry --docker-password=<Password from tab ACR/Access Keys> [email protected]

Et finalement, j'ai essayé de créer un pod avec une image de l'ACR:

#pod.yml
apiVersion: v1
kind: Pod
metadata:
  name: jetty
spec:
  containers:
  - name: jetty
    image: aksclusterregistry.azurecr.io/jetty
  imagePullSecrets:
  - name: secret

kubectl create -f pod.yml

En conséquence, j'ai un pod avec le statut ImagePullBackOff:

>kubectl get pods
NAME                    READY     STATUS             RESTARTS   AGE
jetty                   0/1       ImagePullBackOff   0          1m
> kubectl describe pod jetty
Events:
  Type     Reason                 Age              From                               Message
  ----     ------                 ----             ----                               -------
  Normal   Scheduled              2m               default-scheduler                  Successfully assigned jetty to aks-nodepool1-62963605-0
  Normal   SuccessfulMountVolume  2m               kubelet, aks-nodepool1-62963605-0  MountVolume.SetUp succeeded for volume "default-token-w8png"
  Normal   Pulling                2m (x2 over 2m)  kubelet, aks-nodepool1-62963605-0  pulling image "aksclusterregistry.azurecr.io/jetty"
  Warning  Failed                 2m (x2 over 2m)  kubelet, aks-nodepool1-62963605-0  Failed to pull image "aksclusterregistry.azurecr.io/jetty": rpc error: code = Unknown desc = Error response from daemon: Get https://aksclusterregistry.azurecr.io/v2/jetty/manifests/latest: unauthorized: authentication required
  Warning  Failed                 2m (x2 over 2m)  kubelet, aks-nodepool1-62963605-0  Error: ErrImagePull
  Normal   BackOff                2m (x5 over 2m)  kubelet, aks-nodepool1-62963605-0  Back-off pulling image "aksclusterregistry.azurecr.io/jetty"
  Normal   SandboxChanged         2m (x7 over 2m)  kubelet, aks-nodepool1-62963605-0  Pod sandbox changed, it will be killed and re-created.
  Warning  Failed                 2m (x6 over 2m)  kubelet, aks-nodepool1-62963605-0  Error: ImagePullBackOff

Qu'est-ce qui ne va pas? Pourquoi l'approche avec secret ne fonctionne-t-elle pas? Veuillez ne pas me conseiller d'approcher le directeur de service, car j'aimerais comprendre pourquoi cette approche ne fonctionne pas. Je pense que ça doit marcher.

azuredockerkubernetesazure-cli2
16
Andryusha2006

Cela me semble bien aussi. Cela dit, la recommandation n'est pas d'utiliser le compte administrateur, mais plutôt un principe de service. Avec le SP vous gagnez un certain contrôle granulaire sur les droits d'accès à l'instance ACR (lecture, contributeur, propriétaire).

Ce document comprend deux méthodes d'authentification entre AKS et ACR en utilisant les principes de service.

https://docs.Microsoft.com/en-us/Azure/container-registry/container-registry-auth-aks

8
Neil Peterson