Traitement des incidents liés aux agents privés Delivery Pipeline

Les incidents généraux liés à l'utilisation d'agents privés Delivery Pipeline peuvent inclure des problèmes liés aux clusters Kubernetes et à la version de kubectl. Dans de nombreux cas, ces problèmes peuvent être résolus en quelques opérations simples.

Pourquoi mon agent privé Delivery Pipeline est-il inactif ?

Les agents privés d'un pool d'agents peuvent se trouver dans l'un des états suivants :

  • Actif avec la version actuelle et prise en charge des agents privés
  • Inactif avec une version non prise en charge des agents privés
  • Inactif et non enregistré

Votre agent privé est inactif. Les agents privés inactifs ne peuvent pas traiter les demandes d'exécution entrantes. Les étapes de pipeline qui utilisent un agent privé inactif ne peuvent pas s'exécuter.

Un agent peut devenir inactif

  1. en cas de problème avec votre cluster Kubernetes et si le travailleur ne peut pas communiquer avec les services du plan de contrôle régional
  2. si la version du programme privé que vous utilisez n'est plus prise en charge
  3. si l'agent sur le cluster est devenu Unregistered (non enregistré)

Si l'agent signale qu'il n'est pas enregistré alors qu'il fonctionnait auparavant, vous pouvez essayer de corriger l'enregistrement en exécutant la commande suivante

kubectl patch worke${AGENT_NAME} --subresource=status --type=merge -p '{"status": {"registrationStatus": {"state": "Succeeded"}}}'

Si la commande précédente échoue ou si votre Delivery Pipeline travailleur privé est enregistré mais reste inactif, vous pouvez réinstaller le travailleur privé. Enregistrez à nouveau le Delivery Pipeline travailleur privé sur le Kubernetes cluster.

J'ai essayé d'installer la prise en charge des agents privés Delivery Pipeline dans Kubernetes. Pourquoi l'installation a-elle échoué ?

S'il existe un problème avec la version de kubectl que vous exécutez sur la machine client, l'installation de l'agent privé Delivery Pipeline échoue.

Une fois que vous avez tenté d'installer la prise en charge des agents privés dans Kubernetes, un message d'erreur s'affiche pour signaler une non-concordance de schéma et l'échec de l'installation.

SchemaError(io.k8s.apimachinery.pkg.apis.meta.v1.APIGroup): invalid object doesn't have additional properties

Il existe une non-concordance entre les versions de kubectl que vous exécutez sur le serveur Kubernetes et le client Kubernetes.

Installez la dernière version de kubectl sur la machine client.

Pourquoi ne puis-je pas extraire des images tekton-releases ou pipeline-private-worker de certains registres de conteneurs ?

La sécurité au niveau des clusters vous empêche d'extraire des images.

Lorsque vous tentez d'installer l'infrastructure d'agent privé, un message d'erreur s'affiche.

Error from server (InternalError): error when creating "https://private-worker-service.us-south.devops.cloud.ibm.com/install": Internal error occurred: admission webhook "trust.hooks.securityenforcement.admission.cloud.ibm.com" denied the request:
Deny "ghcr.io/tekton-releases/github.com/tektoncd/pipeline/cmd/controller@sha256:80e040a58ce6c4d58ae893eb934777bce013ef8be079967dc3db783d76fa5aaa", no matching repositories in ClusterImagePolicy and no ImagePolicies in the "tekton-pipelines" namespace
Error from server (InternalError): error when creating "https://private-worker-service.us-south.devops.cloud.ibm.com/install": Internal error occurred: admission webhook "trust.hooks.securityenforcement.admission.cloud.ibm.com" denied the request:
Deny "ghcr.io/tekton-releases/github.com/tektoncd/pipeline/cmd/webhook@sha256:da75fbdaeb800813d85b99f7f54b665e8d0edbb2c5a7ffc6a99d66aede0291a3", no matching repositories in ClusterImagePolicy and no ImagePolicies in the "tekton-pipelines" namespace

Le programme d'installation de l'agent privé extrait les images de icr.io. Certaines plateformes, telles qu'IBM Cloud Private, n'autorisent pas ces registres de conteneurs sur la règle d'image par défaut.

Assurez-vous que la politique de récupération des images dans votre cluster prend en charge la récupération des images à partir de icr.io. Par exemple, si vous installez l'infrastructure d'agent privé sur IBM Cloud Privé, ajoutez ces règles à l'aide de la console Web IBM Cloud Private. Pour plus d'informations sur la gestion de l'application de la sécurité des images à l'aide de la console IBM Cloud Private Web, consultez la section Application de la sécurité des images de conteneur. Pour plus d'informations sur la gestion de la sécurité des images à l'aide de Porteris, consultez la section Portieris Politiques.

L'exemple suivant montre comment utiliser l'interface CLI de IBM Cloud pour créer le fichier ClusterImagePolicy:

Si vous utilisez Portieris comme contrôleur d'admission, vous devrez peut-être remplacer apiVersion dans l'exemple par portieris.cloud.ibm.com/v1.

cat <<EOF | kubectl apply -f -
apiVersion: securityenforcement.admission.cloud.ibm.com/v1beta1
kind: ClusterImagePolicy
metadata:
  name: iks-private-registries
spec:
  repositories:
  - name: "*.icr.io/*"
    policy:
EOF

Pourquoi mon agent privé Delivery Pipeline n'est-il pas répertorié?

Mon agent d'agent privé est répertorié sur le cluster avec le statut inactive, mais il n'est pas répertorié sur la page de présentation de l'intégration d'agent privé.

La clé d'API qui a été utilisée pour installer l'agent d'agent peut ne pas être incluse dans le ServiceID qui est utilisé par l'intégration d'agent privé.

Supprimez l'agent d'agent mal configuré du cluster et installez à nouveau l'agent d'agent d'agent. Assurez-vous que la clé d'API incluse dans la commande d'installation existe également dans le fichier ServiceId qui est utilisé dans la même commande d'installation. Utilisez le lien disponible ServiceId à la fois sur la page d'intégration des travailleurs privés et sur la page Identity and Access Management IAM (Identity and Access Management) pour générer une clé API valide.