Resolución de problemas de trabajadores privados de Delivery Pipeline

Al utilizar trabajadores privados de Delivery Pipeline algunos problemas generales están relacionados con la versión de kubectl y el clúster de Kubernetes. En muchos de los casos, puede solucionar estos problemas siguiendo unos sencillos pasos.

¿Por qué el trabajador privado de Delivery Pipeline está inactivo?

Los trabajadores privados dentro de una agrupación de trabajadores pueden estar en uno de los estados siguientes:

  • Activo con la versión admitida actual de los trabajadores privados
  • Inactivo con una versión admitida de trabajadores privados
  • Inactivo y no registrado

Su trabajador privado está inactivo. Los trabajadores privados inactivos no pueden manejar las solicitudes de ejecución de entrada. Las etapas del conducto que utilizan un trabajador privado inactivo no se pueden completar.

Un agente puede quedar inactivo

  1. si hay un problema con su grupo Kubernetes y el trabajador no puede comunicarse con los servicios regionales del plan de control
  2. si la versión del trabajador privado que está ejecutando ya no es compatible
  3. si el agente del clúster ha dejado de estar registrado

Si el agente está reportando No Registrado después de haber funcionado previamente, puede intentar arreglar el registro ejecutando el siguiente comando

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

Si el comando anterior falla o si tu Delivery Pipeline trabajador privado está registrado pero sigue inactivo, puedes volver a instalar el trabajador privado. Vuelve a registrar el Delivery Pipeline trabajador privado en el Kubernetes clúster.

He intentado instalar el soporte de los trabajadores privados de Delivery Pipeline en Kubernetes. ¿Por qué ha fallado la instalación?

Si hay un problema con la versión de kubectl que se está ejecutando en la máquina cliente, la instalación del trabajador privado de Delivery Pipeline falla.

Después de intentar instalar el soporte para los trabajadores privados en Kubernetes, se muestra un mensaje de error para indicar que hay una discrepancia de esquema y que la instalación falla.

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

Hay una discrepancia entre las versiones de kubectl que se están ejecutando en el servidor de Kubernetes y en el cliente de Kubernetes.

Instale la versión más reciente de kubectl en la máquina cliente.

¿Por qué no puedo extraer imágenes para releases de tekton o del trabajador privado del conducto para determinados registros de contenedor?

La seguridad de clúster evita que se extraigan imágenes.

Cuando se intenta instalar la infraestructura del trabajador privado, se muestra un mensaje de error.

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

El instalador del trabajador privado extrae imágenes de icr.io. Algunas plataformas como, por ejemplo, IBM Cloud Private, no permiten estos registros de contenedor en la política de imágenes predeterminada.

Asegúrate de que la política para extraer imágenes en tu clúster admite la extracción de imágenes desde icr.io. Por ejemplo, si está instalando la infraestructura del trabajador privado en IBM Cloud Privado, añada estas políticas utilizando la Consola web privada de IBM Cloud. Para obtener más información sobre cómo gestionar la aplicación de la seguridad de las imágenes mediante la IBM Cloud Private consola web, consulte Aplicación de la seguridad de las imágenes de contenedor. Para obtener más información sobre cómo gestionar la aplicación de la seguridad de las imágenes mediante Porteris, consulte Portieris Políticas.

El siguiente ejemplo muestra cómo utilizar la CLI de IBM Cloud para crear el archivo ClusterImagePolicy:

Si utiliza Portieris como controlador de admisión, es posible que tenga que cambiar el apiVersion del ejemplo por 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

¿Por qué no se lista mi trabajador privado de Delivery Pipeline ?

Mi agente de trabajador privado se lista en el clúster con un estado de inactive, pero no se lista en la página Visión general de integración de trabajador privado.

Es posible que la clave de API que se ha utilizado para instalar el agente de trabajador no se incluya en el ServiceID que utiliza la integración de trabajador privado.

Elimine el agente de trabajador mal configurado del clúster e instale de nuevo el agente de trabajador. Asegúrese de que la clave de API que se incluye en el mandato de instalación también existe en el ServiceId que se utiliza en el mismo mandato de instalación. Utilice el enlace para que ServiceId está disponible tanto en la página de integración de trabajadores privados como en la página Identity and Access Management (IAM) para generar una clave API válida.