Solucionar problemas del clúster de carga de trabajo

Esta sección incluye sugerencias para ayudarle a solucionar problemas de los clústeres de carga de trabajo. Para obtener información sobre la solución de problemas de implementaciones de clústeres de administración independientes, consulte Solucionar problemas del clúster de administración.

Tareas comunes

Eliminar usuarios, contextos y clústeres con kubectl

Para limpiar su estado kubectl eliminando algunos o todos sus usuarios, contextos y clústeres:

1. Abra el archivo ~/.kube/config.

2. Para los objetos user que desea eliminar, ejecute:

   kubectl config unset users.USER-NAME
   

   Donde USER-NAME es la propiedad name de cada objeto user de nivel superior, tal como aparece en los archivos config.

3. Para los objetos context que desea eliminar, ejecute:

   kubectl config unset contexts.CONTEXT-NAME
   

   Donde CONTEXT-NAME es la propiedad name de cada objeto context de nivel superior, como se indica en los archivos config, normalmente con el formato contexts.mycontext-admin@mycontext.

4. Para los objetos cluster que desea eliminar, ejecute:

   kubectl config unset clusters.CLUSTER-NAME
   

   Donde CLUSTER-NAME es la propiedad name de cada objeto cluster de nivel superior, tal como aparece en los archivos config.

5. Si los archivos config muestran el contexto actual como un clúster que eliminó, desconfigure el contexto:

   kubectl config unset current-context
   

Paquetes

No se crea el secreto al instalar Grafana desde el archivo YAML predeterminado

Problema

Si intenta instalar Grafana generando un archivo de configuración predeterminado de Grafana, se produce un error en la instalación con error: Secret in version "v1" cannot be handled as a Secret: illegal base64 data at input byte 4 (reason: BadRequest).

Solución

Cree el secreto manualmente y utilice el mismo archivo YAML sin la etiqueta secreta para instalar Grafana.

1. Realice los pasos descritos en Implementar Grafana en el clúster de carga de trabajo para crear el archivo de configuración de la configuración de Grafana.
2. Elimine las entradas grafana.secret.* del archivo de configuración generado.

3. Cree un secreto manualmente.

   kubectl create secret generic grafana -n tanzu-system-dashboards  --from-literal=admin=admin
   

4. Implemente el paquete.

   tanzu package install grafana \
   --package grafana.tanzu.vmware.com \
   --version AVAILABLE-PACKAGE-VERSION \
   --values-file grafana-data-values.yaml \
   --namespace TARGET-NAMESPACE
   

5. Realice los pasos restantes de Implementar Grafana en el clúster de carga de trabajo.

Error al ejecutar tanzu package repository

Problema

Se produce un error en el comando tanzu package repository.

Solución

Ejecute kubectl get pkgr REPOSITORY-NAME -n NAMESPACE -o yaml​ para obtener detalles sobre el error.

Donde:

• REPOSITORY-NAME es el nombre del repositorio del paquete.
• NAMESPACE es el espacio de nombres de destino del repositorio de paquetes.

El comando tanzu package repository puede generar un error similar al siguiente:

Error	Descripción	Solución
NOT_FOUND	La ruta de la URL del repositorio no es válida.	Asegúrese de que se pueda acceder a la URL del repositorio de paquetes desde el clúster.
UNKNOWN o UNAUTHORIZED	Este error puede producirse al intentar conectarse al repositorio.
Ownership	Ya hay un repositorio con la misma URL de repositorio de paquetes instalado en el clúster.	Realice una de las siguientes opciones: Ejecute tanzu package available list -n NAMESPACE para ver si el paquete que desea instalar ya está disponible para la instalación. Para revertir el intento fallido actual de agregar el repositorio, ejecute tanzu package repository delete REPOSITORY-NAME -n NAMESPACE. Ejecute tanzu package repository list -A para recuperar un repositorio de paquetes existente con la misma URL. Si recupera el repositorio de paquetes, puede continuar con su eliminación bajo su propio riesgo.

Error al ejecutar tanzu package installed

Problema

Se produce un error en el comando tanzu package installed.

Solución

Ejecute kubectl get pkgi INSTALLED-PACKAGE-NAME -n NAMESPACE -o yaml​ para obtener detalles sobre el error.

Donde:

• INSTALLED-PACKAGE-NAME es el nombre del paquete instalado.
• NAMESPACE es el espacio de nombres del paquete instalado.

El comando tanzu package installed puede generar un error similar al siguiente:

Error	Descripción	Solución
Ownership	Ya hay un paquete con el mismo nombre instalado en el clúster.	Ejecute tanzu package installed list -A para comprobar si el paquete que desea instalar ya está instalado. Si es así, es posible que desee utilizar el paquete ya instalado, actualizar su versión o eliminar el paquete para poder continuar con la instalación.
Evaluating starlark template	Este error puede producirse cuando falta el valor de configuración indicado.	Ejecute tanzu package available get AVAILABLE-PACKAGE-NAME/VERSION -n NAMESPACE –values-schema para ver todos los valores de configuración disponibles y proporcionar los valores de configuración necesarios al comando tanzu package install.
Failed to find a package with name PACKAGE-NAME in namespace NAMESPACE	El paquete especificado y los metadatos del paquete no están disponibles en el espacio de nombres de destino	Asegúrese de que el paquete especificado aparezca en los resultados de tanzu package available list AVAILABLE-PACKAGE-NAME -n NAMESPACE​. Si no es así, agregue el repositorio de paquetes que contiene el paquete al espacio de nombres de destino.
Namespace NAMESPACE not found	El espacio de nombres en el que desea instalar el paquete no existe.	En TKG v2.1, los comandos tanzu package se basan en kctrl y ya no admiten la marca —create-namespace. Antes de instalar un paquete o un repositorio de paquetes, el espacio de nombres de destino ya debe existir.
Provided service account SERVICE-ACCOUNT-NAME is already used by another package in namespace NAMESPACE​	Otro paquete instalado ya utiliza la cuenta de servicio proporcionada con la marca service-account-name.	Permita que el complemento de paquete cree la cuenta de servicio por usted o seleccione otro nombre de cuenta de servicio.

Pods

Los pods se bloquean en estado pendiente en el clúster debido a la conectividad de vCenter

Problema

Cuando se ejecuta kubectl get pods -A en el clúster creado, algunos pods permanecen en estado pendiente.

Ejecute kubectl describe pod -n pod-namespace pod-name en un pod afectado y vea el siguiente evento:

n node(s) had taint {node.cloudprovider.kubernetes.io/uninitialized: true}, that the pod didn't tolerate

Solución

Asegúrese de que haya reglas de firewall y conectividad en lugar de garantizar la comunicación entre el clúster y vCenter. Para conocer los requisitos de protocolos y puertos de firewall, consulte las listas de vSphere 8 en Puertos y protocolos de VMware.

Clústeres de carga de trabajo

Se agota el tiempo de espera de la implementación de un clúster, pero se crea el clúster

Problema

Al ejecutar tanzu cluster create se produce un error de tiempo de espera similar al siguiente:

I0317 11:11:16.658433 clusterclient.go:341] Waiting for resource my-cluster of type *v1beta1.Cluster to be up and running
E0317 11:26:16.932833 common.go:29]
Error: unable to wait for cluster and get the cluster kubeconfig: error waiting for cluster to be created (this may take a few minutes): cluster control plane is still being initialized
E0317 11:26:16.933251 common.go:33]

Solución

Utilice la marca --timeout para especificar el tiempo de espera para que se complete la creación del clúster. El tiempo de espera predeterminado es de 30 minutos.

tanzu cluster create --timeout TIME

Donde TIME es el tiempo, en minutos para que se complete la creación del clúster. Por ejemplo, 60m.

El clúster de carga de trabajo se bloquea en la eliminación

Problema

tanzu cluster delete no puede eliminar el clúster de carga de trabajo.

Para eliminar el clúster manualmente, consulte las dos soluciones que aparecen a continuación.

Solución 1

1. En el clúster de destino, elimine el objeto StatefulSet para AKO, que se ejecuta en el espacio de nombres avi-system:

   kubectl delete sts ako -n avi-system
   

Solución 2

1. Inicie sesión en el clúster y elimine las máquinas de trabajo:

   kubectl delete machine worker1 worker2
   

2. En vCenter, apague y elimine las máquinas virtuales del nodo de trabajo.

3. Edite las máquinas del plano de control y elimine el vínculo finalizador:

   finalizers:
    - machine.cluster.x-k8s.io
   

4. Elimine las máquinas del plano de control:

   kubectl delete machine controlplane1 controlplane2
   

5. Desde vCenter, apague y elimine las máquinas virtuales del plano de control

Nodos de trabajo del clúster en el estado No listo (NotReady) debido a que las MTU no coinciden

Problema

La configuración de la unidad de transmisión máxima (MTU) diferente en los nodos de trabajo de un clúster provoca que se agote el tiempo de espera del protocolo de enlace TLS.

Los registros de journalctl -u kubelet en un nodo muestran un error de comunicación con el servidor de API. Al ejecutar kubectl get nodes se muestra que los nodos de trabajo se han movido al estado No listo (NotReady).

Puede volver a confirmar el problema haciendo lo siguiente:

1. En el nodo del plano de control y las máquinas del nodo de trabajo, ejecute ip link y compare los valores de MTU de la interfaz eth0. Si no coinciden, es un indicio de este problema.
2. Ejecute Diagnósticos de bloqueo (Crash Diagnostics) (Crashd) y revise los registros de kubelet para determinar que se agotó el tiempo de espera de las conexiones o que los nodos de trabajo se encuentran en el estado No listo (NotReady). Para obtener más información sobre cómo ejecutar Crashd, consulte Solucionar problemas de clústeres de carga de trabajo con diagnósticos de bloqueo

3. Confirme que los siguientes comandos fallan al ejecutarlos en una máquina, que se encuentra en el estado de nodo No listo (NotReady):

   • openssl s_client -connect IP:PORT

   • curl IP:PORT -k /healthz

   Donde IP y PORT es la dirección IP y el número de puerto del endpoint del plano de control del servidor de API de Kubernetes. De forma predeterminada, PORT se establece en 6443.

Solución

1. Revise los daemonsets con privilegios implementados en el clúster y revise los daemonsets de proveedores de terceros que puedan modificar las configuraciones de red del sistema operativo del host. Es posible que deba consultar al proveedor de software para averiguarlo. Los daemonsets que pueden modificar el sistema operativo del host tendrán .spec.template.spec.hostNetwork: true o tendrán privileged: true o NET_ADMIN en el campo de capacidades de cualquier contexto de seguridad de contenedor.

2. Si desea configurar ajustes de MTU de gran tamaño, aprovisione el clúster con un plano de control con un valor de MTU de mayor tamaño.

3. Asegúrese de que la red del clúster permita la detección de MTU de ruta de acceso o de que tenga fijación de MSS de TCP para permitir el dimensionamiento de MTU correcto en servicios externos, como registros de contenedores o vCenter.

4. Asegúrese de configurar los mismos ajustes de MTU para todos los nodos de un clúster.

5. La configuración del firewall de red debe permitir paquetes del tamaño de MTU configurado.