Le cluster GKE ne peut pas extraire (ErrImagePull) du registre GCR dans le même projet (intégration GitLab Kubernetes): Pourquoi?

Donc, après avoir googlé un peu (ce qui est pollué par des personnes ayant des problèmes avec Pull Secrets), je poste ceci ici - et au support GCP (mettra à jour si j'entends).

J'ai créé un cluster à partir de l'intégration de GitLab Kubernetes (docs: https://about.gitlab.com/solutions/kubernetes ) dans le même projet que mon registre/images GCR.

Lorsque j'ajoute un nouveau service/déploiement à ce cluster à l'aide de Kubectl (qui s'appuie sur une image privée dans le registre GCR dans ce projet), les pods du cluster créé par GitLab ne parviennent pas à tirer de GCR avec: ErrImagePull.

Pour être clair - je ne tire pas d'un registre privé GitLab, j'essaie de tirer d'un registre GCR dans le même projet que le cluster GKE créé à partir de GitLab (qui ne devrait pas nécessiter de Pull Secret).

Les autres clusters (créés à partir de la console GCP) au sein de ce projet peuvent accéder correctement à la même image.Je pense donc qu'il existe une différence entre les clusters créés via une API (dans ce cas à partir de GitLab) et les clusters créés à partir de la console GCP.

J'espère que quelqu'un a rencontré cela dans le passé - ou peut expliquer les différences dans les comptes de service, etc., qui pourraient être à l'origine du problème.

Je vais essayer de créer un compte de service et lui accorder manuellement le rôle Project Viewer pour voir si cela résout le problème.

Mise à jour: le compte de service configuré manuellement n'a pas résolu le problème.

Remarque: J'essaie de tirer une image dans le cluster PAS dans un GitLab Runner qui s'exécute sur le cluster. C'est à dire. Je souhaite qu'un service/déploiement distinct s'exécute à côté de mon infrastructure GitLab.

kubernetesgoogle-cloud-platformgitlabgoogle-kubernetes-engine

4 janv. 2019Necevil

TL; DR - Les clusters créés par GitLab-Ci Kubernetes Integration ne pourront pas extraire une image d'un registre GCR dans le même projet que les images de conteneur - sans modifier les autorisations (étendues) des nœuds.

Par défaut, les nœuds de cluster créés par un cluster lui-même créé par l'intégration Kubernetes de GitLab-Ci sont créés avec des autorisations (étendues) minimales pour les services Google Cloud.

Vous pouvez le voir visuellement depuis le tableau de bord de la console GCP pour votre cluster, faites défiler vers le bas jusqu'à la section des autorisations et recherchez "Stockage":

Cela signifie essentiellement que le ou les nœuds exécutés dans votre cluster d'intégration GitLab-Ci Kubernetes N'AURONT PAS les autorisations par défaut du registre GCR (lecture seule) nécessaires pour extraire une image d'un registre GCR.

Cela signifie également (pour autant que je sache) que même si vous accordez à un compte de service un accès approprié au registre GCR, cela ne fonctionnera toujours pas - je ne suis pas totalement sûr d'avoir correctement configuré mon compte de service, mais je pense que oui.

Génial.

Comment réparer les autorisations

Fondamentalement, vous avez deux options. La première consiste à créer un cluster (c'est-à-dire en dehors de l'intégration de GitLab Kubernetes), puis à reconnecter votre projet GitLab à ce cluster en suivant le manuel `` se connecter à un cluster existant '' qui se trouve ici: https://gitlab.com/help/user/project/clusters/index#adding-an-existing-kubernetes-cluster

La deuxième option consiste à modifier vos autorisations mais c'est plus compliqué.

4 janv. 2019Necevil

TL; DR - Les clusters créés par GitLab-Ci Kubernetes Integration ne pourront pas extraire une image d'un registre GCR dans le même projet que les images de conteneur - sans modifier les autorisations (étendues) des nœuds.

Alors que vous POUVEZ modifier manuellement les autorisations sur une machine individuelle Node) pour accorder les informations d'identification par défaut de l'application (voir: https://developers.google.com/identity/protocols/application-default-credentials ) les portées appropriées en temps réel - le faire de cette façon signifierait que si votre nœud est recréé à un moment donné dans le futur, il N'AURAIT PAS vos portées modifiées et les choses se briseraient.

Au lieu de modifier les autorisations manuellement - créez un nouveau pool Node qui possède les étendues appropriées pour accéder à vos services GCP requis.

Voici quelques ressources que j'ai utilisées comme référence:

Création d'un pool Node Pool correctement défini) ressemble généralement à ceci

gcloud container node-pools create [new pool name] \
 --cluster [cluster name] \
 --machine-type [your desired machine type] \
 --num-nodes [same-number-nodes] \
 --scopes [your new set of scopes]

Si vous n'êtes pas sûr du nom de vos étendues requises - Vous pouvez voir une liste complète des étendues ET des alias d'étendue ici: https://cloud.google.com/sdk/gcloud/reference/container/node-pools/create

Pour moi, j'ai fait gke-default (comme mon autre cluster) et sql-admin. La raison en est que je dois pouvoir accéder à une base de données SQL dans Cloud SQL pendant une partie de ma génération et je ne veux pas avoir à me connecter à une adresse IP publique pour le faire.

étendues gke-default (pour référence)

Comparez ce qui précède avec des autorisations plus verrouillées à partir d'un cluster créé par GitLab-Ci (UNIQUEMENT ces deux: https://www.googleapis.com/auth/logging.write , https://www.googleapis.com/auth/monitoring ):

La configuration évidente de votre cluster sur SEULEMENT les autorisations minimales nécessaires est à coup sûr la voie à suivre ici. Une fois que vous avez compris ce que c'est et que vous avez créé votre nouvelle portée correctement définie Node Pool ...

Listez vos nœuds avec:

kubectl get nodes

Celui que vous venez de créer (le plus récent) a les nouveaux paramètres tandis que l'ancienne option est le cluster gitlab par défaut qui peut être extrait du GCR.

Ensuite:

kubectl cordon [your-node-name-here]

Après cela, vous voulez drainer:

kubectl drain [your-node-name-here] --force

J'ai rencontré des problèmes où le fait d'avoir installé un GitLab Runner signifiait que je ne pouvais pas vider les pods normalement en raison de l'ensemble de données/démon local utilisé pour le contrôler.

Pour cette raison, une fois que j'ai bouclé mon Node je viens de supprimer le nœud de Kubectl (je ne sais pas si cela causera des problèmes - mais cela me convenait). Une fois votre nœud supprimé, vous devez pour supprimer le pool de nœuds 'default-pool' créé par GitLab.

Listez vos pools de nœuds:

gcloud container node-pools list --cluster [CLUSTER_NAME]

Voir les anciennes étendues créées par gitlab:

gcloud container node-pools describe default-pool \
    --cluster [CLUSTER_NAME]

Vérifiez si vous disposez des nouvelles étendues correctes (que vous venez d'ajouter):

gcloud container node-pools describe [NEW_POOL_NAME] \
    --cluster [CLUSTER_NAME]

Si votre nouveau pool Node a les bonnes étendues, vos déploiements peuvent maintenant supprimer le pool par défaut avec:

gcloud container node-pools delete default-pool \
   --cluster <YOUR_CLUSTER_NAME> --zone <YOUR_ZONE>

Dans mon cas personnel, j'essaie toujours de comprendre comment autoriser l'accès au réseau privé (c'est-à-dire accéder à Cloud SQL via une IP privée), mais je peux récupérer mes images maintenant, donc je suis à mi-chemin.

Je pense que c'est tout - j'espère que cela vous a fait gagner quelques minutes!

4 janv. 2019Necevil