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. Puede encontrar una solución alternativa adicional para los problemas conocidos de esta versión en las Notas de la versión o en los Artículos de la base de conocimientos de VMware.

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 y posteriores, los comandos tanzu package se basan enkctrl y ya no son compatibles con 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.

Almacenamiento

Al cambiar el objeto StorageClass predeterminado, se produce un error de conciliación en los clústeres de carga de trabajo

Problema

Si se modifican las propiedades de un objeto StorageClass predeterminado incluido en TKG, se produce un error de conciliación de paquetes en los clústeres de carga de trabajo que utilizan la clase de almacenamiento.

Solución:

Para personalizar una clase de almacenamiento, cree una nueva definición de StorageClass con un name diferente, en lugar de modificar la definición de objeto predeterminada, y vuelva a configurar el clúster para que use la nueva clase de almacenamiento.

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.

Con NSX ALB, no puede crear clústeres con nombres idénticos

Problema

Si utiliza NSX Advanced Load Balancer para cargas de trabajo (AVI_ENABLE) o el plano de control (AVI_CONTROL_PLANE_HA_PROVIDER), es posible que el controlador AVI no pueda distinguir entre clústeres con nombres idénticos.

Solución:

Establezca un valor CLUSTER_NAME único para cada clúster. No cree varios clústeres de carga de trabajo que tengan el mismo CLUSTER_NAME y que también estén en el mismo espacio de nombres del clúster de administración, tal y como establece su valor NAMESPACE.

La eliminación del volumen de vSphere CSI podría fallar en AVS

Problema

En Azure vSphere Solution (AVS), la eliminación de volúmenes persistentes (PV) de vSphere CSI puede producir un error. Para eliminar un PV, se requiere el permiso cns.searchable. La cuenta de administrador predeterminada para AVS, <[email protected]>, no se crea con este permiso. Para obtener más información, consulte Funciones y privilegios de vSphere.

Solución

Para eliminar un PV de vSphere CSI en AVS, póngase en contacto con el soporte de Azure.

Se produce un error al eliminar el clúster en AWS si el clúster utiliza recursos de redes no implementados con Tanzu Kubernetes Grid

Problema

Los comandos tanzu cluster delete y tanzu management-cluster delete pueden dejar de responder con los clústeres que utilizan recursos de redes creados por AWS Cloud Controller Manager independientemente del proceso de implementación de Tanzu Kubernetes Grid. Estos recursos pueden incluir equilibradores de carga y otros servicios de redes, como se indica en El controlador de servicios en la documentación del proveedor de nube de Kubernetes AWS.

Para obtener más información, consulte el problema de la API del clúster Purgar clústeres de carga de trabajo del servicio Type=Loadbalancer en el desmontaje.

Solución

Utilice kubectl delete para eliminar servicios del tipo LoadBalancer del clúster. O bien, si se produce un error, utilice la consola de AWS para eliminar manualmente cualquier objeto LoadBalancer y SecurityGroup creado para este servicio por el administrador de controladores de nube.

Precaución

No elimine balanceadores de carga o grupos de seguridad administrados por Tanzu, que tienen las etiquetas key: sigs.k8s.io/cluster-api-proider-aws/cluster/CLUSTER-NAME ,value: owned .

Se produce un error en la eliminación del clúster cuando el volumen de almacenamiento utiliza una cuenta con endpoint privado

Problema

Con un clúster de carga de trabajo de Azure en un grupo de recursos no administrado, cuando el controlador CSI de Azure crea un volumen persistente (PV) que utiliza una cuenta de almacenamiento con un endpoint privado, crea un recurso privateEndpoint y un recurso vNet que no se eliminan cuando se elimina el PV. Como resultado, al eliminar el clúster, se produce un error como subnets failed to delete. err: failed to delete resource ... Subnet management-cluster-node-subnet is in use.

Solución:

Antes de eliminar el clúster de Azure, elimine manualmente la interfaz de red del endpoint privado de la cuenta de almacenamiento:

1. Desde un navegador, inicie sesión en Azure Resource Explorer.
2. Haga clic en suscripciones (subscriptions) a la izquierda y expanda la suscripción.
3. En la suscripción, expanda resourceGroups a la izquierda y el grupo de recursos de la implementación de TKG.
4. En el grupo de recursos, expanda proveedores (providers) > Microsoft.Network > networkinterfaces.
5. En networkinterfaces, seleccione el recurso de NIC que no se puede eliminar.
6. Haga clic en el botón Leer/Escribir (Read/Write) en la parte superior y, a continuación, en la pestaña Acciones (PUBLICAR, ELIMINAR) (Actions [POST, DELETE]) justo debajo.
7. Haga clic en Eliminar.
8. Una vez eliminada la NIC, elimine el clúster de Azure.