Warum ist mein privater Delivery Pipeline-Worker inaktiv?

Private Worker in einem Pool von Workern können folgende Status aufweisen:

• Aktiv mit der aktuellen, unterstützten Version von privaten Workern
• Inaktiv mit einer nicht unterstützten Version von privaten Workern
• Inaktiv und unregistriert

Ihr privater Worker ist inaktiv. Inaktive private Worker können keine eingehenden Ausführungsanforderungen verarbeiten. Pipeline-Phasen, die einen inaktiven privaten Worker verwenden, können nicht abgeschlossen werden.

Ein Agent kann inaktiv werden

1. wenn es ein Problem mit Ihrem Kubernetes-Cluster gibt und der Arbeitnehmer nicht mit den regionalen Kontrollplandiensten kommunizieren kann
2. wenn die Version des privaten Workers, die Sie ausführen, nicht mehr unterstützt wird
3. wenn der Agent des Clusters nicht mehr registriert ist

Wenn der Agent die Meldung Nicht registriert ausgibt, obwohl er zuvor funktioniert hat, können Sie versuchen, die Registrierung zu reparieren, indem Sie den folgenden Befehl ausführen

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

Wenn der vorhergehende Befehl fehlschlägt oder wenn Ihr Delivery Pipeline privater Worker registriert, aber immer noch inaktiv ist, können Sie den privaten Worker erneut installieren. Registrieren Sie den Delivery Pipeline privaten Worker erneut im Kubernetes Cluster.

Ich habe versucht, die Unterstützung für private Delivery Pipeline-Worker in Kubernetes zu installieren. Warum ist die Installation fehlgeschlagen?

Wenn es ein Problem mit der Version von kubectl gibt, die auf der Clientmaschine ausgeführt wird, schlägt die Installation des privaten Delivery Pipeline-Workers fehl.

Nachdem Sie versucht haben, Unterstützung für private Worker in Kubernetes zu installieren, wird eine Fehlernachricht angezeigt, die angibt, dass eine Schemaabweichung vorliegt und die Installation fehlschlägt.

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

Die Versionen von kubectl, die auf dem Kubernetes-Server und dem Kubernetes-Client ausgeführt werden, weichen voneinander ab.

Installieren Sie die aktuelle Version von kubectl auf der Clientmaschine.

Warum kann ich aus manchen Container-Registrys keine Images für 'tekton-releases' oder 'pipeline-private-worker' extrahieren?

Die Clustersicherheit verhindert, dass Sie Images extrahieren.

Wenn Sie versuchen, das private Worker-Framework zu installieren, wird eine Fehlernachricht angezeigt.

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

Das Installationsprogramm für private Worker extrahiert Images aus icr.io. Manche Plattformen, z. B. IBM Cloud Private, lassen diese Container-Registrys in der Standardimagerichtlinie nicht zu.

Stellen Sie sicher, dass die Richtlinie zum Abrufen von Images in Ihrem Cluster das Abrufen von Images aus unterstützt icr.io. Wenn Sie beispielsweise das private Worker-Framework in IBM Cloud Private installieren, fügen Sie diese Richtlinien hinzu, indem Sie die IBM Cloud Private-Webkonsole verwenden. Weitere Informationen zum Verwalten der Durchsetzung von Bildsicherheit mithilfe der IBM Cloud Private Webkonsole finden Sie unter Durchsetzen der Sicherheit von Container-Images. Weitere Informationen zum Verwalten der Durchsetzung von Bildsicherheit mithilfe von Porteris finden Sie unter Portieris Richtlinien.

Das folgende Beispiel zeigt, wie Sie die IBM Cloud CLI verwenden, um die ClusterImagePolicy:

Wenn Sie als Portieris Zulassungssteuerung verwenden, müssen Sie möglicherweise das apiVersion im Beispiel in ändern 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

Warum wird mein Delivery Pipeline Private Worker nicht aufgelistet?

Mein privater Workeragent wird im Cluster mit dem Status inactive aufgelistet, aber er wird nicht auf der Übersichtsseite für die Integration privater Worker aufgelistet.

Der API-Schlüssel, der zum Installieren des Worker-Agenten verwendet wurde, ist möglicherweise nicht in der ServiceID enthalten, die von der privaten Worker-Integration verwendet wird.

Entfernen Sie den fehlerhaft konfigurierten Workeragenten aus dem Cluster und installieren Sie den Workeragenten erneut. Stellen Sie sicher, dass der API-Schlüssel, der im Installationsbefehl enthalten ist, auch in der ServiceId enthalten ist, die in demselben Installationsbefehl verwendet wird. Verwenden Sie den Link für die ServiceId, der sowohl auf der Seite zur Integration privater Mitarbeiter als auch auf der Identity and Access Management Seite (IAM) verfügbar ist, um einen gültigen API-Schlüssel zu generieren.