Solucionar problemas del clúster de administración

Este tema incluye sugerencias para ayudarle a solucionar problemas de implementaciones de clústeres de administración independientes.

Para obtener información sobre la solución de problemas de los clústeres de carga de trabajo, consulte Solucionar problemas de clústeres de carga de trabajo. 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.

Requisitos previos

Algunos de los siguientes procedimientos utilizan la CLI kind. Para instalar kind, consulte Instalación en la documentación de kind.

Tareas comunes

Conectarse a nodos del clúster con SSH

Puede utilizar SSH para conectarse a nodos individuales de clústeres de carga de trabajo o clústeres de administración independientes. Para ello, el par de claves SSH que creó al implementar el clúster de administración debe estar disponible en la máquina en la que se ejecuta el comando SSH. Por lo tanto, debe ejecutar comandos ssh en la máquina en la que ejecute comandos tanzu.

Las claves SSH que se registran en el clúster de administración y que utilizan los clústeres de carga de trabajo que se implementan desde el clúster de administración se asocian con las siguientes cuentas de usuario:

• vSphere clúster de administración y nodos de Tanzu Kubernetes que se ejecutan en Photon OS y Ubuntu: capv
• Nodos de bastión de AWS: ubuntu
• Clúster de administración de AWS y nodos de Tanzu Kubernetes que se ejecutan en Ubuntu: ubuntu
• Clúster de administración de AWS y nodos de Tanzu Kubernetes que se ejecutan en Amazon Linux: ec2-user
• Clúster de administración de Azure y nodos de Tanzu Kubernetes (siempre Ubuntu): capi

Para conectarse a un nodo de mediante SSH, ejecute uno de los siguientes comandos desde la máquina que utiliza como máquina de arranque:

• Nodos de vSphere: ssh capv@node-address
• Nodos de bastión de AWS y nodos de carga de trabajo y clúster de administración en Ubuntu: ssh ubuntu@node-address
• Clúster de administración de AWS y nodos de Tanzu Kubernetes que se ejecutan en Amazon Linux: ssh ec2-user@node-address
• Nodos de Azure: ssh capi@node-address

No se requiere ninguna contraseña debido a que la clave SSH está presente en el sistema en el que se ejecuta el comando ssh.

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-tkg/config.

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

   kubectl config unset users.USERNAME --kubeconfig ~/.kube-tkg/config
   

   Donde USERNAME es la propiedad name de cada objeto user de nivel superior, tal como aparece en el archivo config.

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

   kubectl config unset contexts.CONTEXT-NAME --kubeconfig ~/.kube-tkg/config
   

   Donde CONTEXT-NAME es la propiedad name de cada objeto context de nivel superior, tal como aparece en el archivo config, normalmente con la forma contexts.mycontext-admin@mycontext.

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

   kubectl config unset clusters.CLUSTER-NAME --kubeconfig ~/.kube-tkg/config
   

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

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

   kubectl config unset current-context --kubeconfig ~/.kube-tkg/config
   

6. Si eliminó clústeres de administración de los que realiza un seguimiento la CLI de tanzu, elimínelos del estado de la CLI de tanzu ejecutando tanzu config server delete como se describe en Eliminar clústeres de administración desde la configuración de la CLI de Tanzu.

Desactivar nfs-utils en los nodos de Photon OS

Problema

En Tanzu Kubernetes Grid v1.1.2 y versiones posteriores, nfs-utils está habilitado de forma predeterminada. Si no necesita nfs-utils, puede eliminarlo de las máquinas virtuales del nodo del clúster.

Solución

Para desactivar nfs-utils en los clústeres que implemente con Tanzu Kubernetes Grid v1.1.2 o versiones posteriores, use SSH para iniciar sesión en las máquinas virtuales del nodo de clúster y ejecute el siguiente comando:

tdnf erase nfs-utils

Plataforma de destino

Error de validación, error de credenciales en AWS

Problema

Al ejecutar tanzu management-cluster create o tanzu mc create, se produce un error similar al siguiente:

Validating the pre-requisites...
Looking for AWS credentials in the default credentials provider chain

Error: : Tkg configuration validation failed: failed to get AWS client: NoCredentialProviders: no valid providers in chain
caused by: EnvAccessKeyNotFound: AWS_ACCESS_KEY_ID or AWS_ACCESS_KEY not found in environment
SharedCredsLoad: failed to load shared credentials file
caused by: FailedRead: unable to open file
caused by: open /root/.aws/credentials: no such file or directory
EC2RoleRequestError: no EC2 instance role found
caused by: EC2MetadataError: failed to make EC2Metadata request

Solución

Tanzu Kubernetes Grid utiliza la cadena de proveedores de credenciales de AWS predeterminadas. Antes de crear un clúster de administración o de carga de trabajo en AWS, debe configurar las credenciales de la cuenta de AWS como se describe en Configurar credenciales de AWS.

Error de validación, error de términos legales en Azure

Problema

Antes de crear un clúster de carga de trabajo o de administración independiente en Azure, debe aceptar los términos legales que cubren la imagen de máquina virtual que utilizan los nodos del clúster. Al ejecutar tanzu mc create o tanzu cluster create sin haber aceptado la licencia, se produce un error como el siguiente:

User failed validation to purchase resources. Error message: 'You have not accepted the legal terms on this subscription: '*********' for this plan. Before the subscription can be used, you need to accept the legal terms of the image.

Solución

Si esto ocurre, acepte los términos legales y vuelva a intentarlo:

• Clúster de administración: Consulte Aceptar la licencia de imagen base
• Clúster de carga de trabajo: Consulte las instrucciones de Azure en Implementar un clúster con una versión de Kubernetes no predeterminada.

Clúster de administración

Limpiar después de una implementación incorrecta del clúster de administración

Problema

Un intento incorrecto de implementar un clúster de administración independiente deja objetos huérfanos en la infraestructura de nube y en la máquina de arranque.

Solución

1. Supervise los resultados del comando tanzu mc create en la interfaz del instalador de Tanzu Kubernetes Grid o el terminal. Si se produce un error en el comando, imprime un mensaje de ayuda que incluye lo siguiente: “Error al implementar el clúster de administración. Para limpiar los recursos creados por el clúster de administración: tkg delete mc” (“Failure while deploying management cluster… To clean up the resources created by the management cluster: tkg delete mc…”).
2. Ejecute tanzu mc delete YOUR-CLUSTER-NAME. Este comando elimina los objetos que creó en la infraestructura y de forma local.

También puede utilizar los métodos alternativos que se describen a continuación:

• Limpieza de máquinas de arranque:

  • Para eliminar un clúster kind, utilice la CLI kind. Por ejemplo:

    kind get clusters
    kind delete cluster --name tkg-kind-example1234567abcdef
    

  • Para eliminar objetos de Docker, utilice la CLI docker. Por ejemplo, docker rm, docker rmi y docker system prune -a --volumes.

    Precaución

    Si ejecuta procesos de Docker que no están relacionados con Tanzu Kubernetes Grid en el sistema, elimine individualmente los objetos de Docker que no sean necesarios.

• Limpieza de la plataforma de destino:

  • vSphere: Busque, desconecte y elimine las máquinas virtuales y otros recursos creados por Tanzu Kubernetes Grid.
  • AWS: Inicie sesión en el panel de control de Amazon EC2 y elimine los recursos manualmente o utilice una solución automatizada.
  • Azure: En (Grupos de recursos) Resource Groups, abra el AZURE_RESOURCE_GROUP. Utilice las casillas de verificación para seleccionar y Eliminar (Delete) los recursos creados por Tanzu Kubernetes Grid, que contienen una marca de tiempo en sus nombres.

No se puede eliminar el clúster de administración en AWS

Problema

Después de ejecutar tanzu mc delete en AWS, tanzu mc get y otros comandos de la CLI de Tanzu ya no enumeran el clúster de administración eliminado, pero:

• El clúster no se elimina de la infraestructura de AWS y sus nodos siguen apareciendo en el panel de control de Amazon EC2
• Los registros del clúster de administración muestran el error cluster infrastructure is still being provisioned: VpcReconciliationFailed.

Solución

Este comportamiento se produce cuando TKG utiliza credenciales de la cuenta de AWS caducadas o no válidas. Para evitar o recuperarse de esta situación:

• Prevenir: Actualice las credenciales de la cuenta de AWS como se describe en Configurar credenciales de cuenta de AWS mediante perfiles de credenciales de AWS o variables de entorno locales y estáticas.

  • No se pueden utilizar las credenciales del perfil de instancia de AWS para eliminar un clúster de administración.

• Recuperar mediante el panel de control de EC2: Elimine manualmente los nodos del clúster de administración del panel de control de EC2

• Recuperar usando la CLI:

  1. En el clúster de kind que permanece en la máquina de arranque debido a un error en la eliminación del clúster de administración, corrija el secreto de la credencial de AWS:

     kubectl get secret capa-manager-bootstrap-credentials -n capa-system -ojsonpath="{.data.credentials}"| base64 -d
     

  2. Editar el secreto para incluir las credenciales de AWS:

     [default]
     aws_access_key_id = <key id>
     aws_secret_access_key = <access_key>
     region = <region>
     

  3. Ejecute tanzu mc delete de nuevo.

El clúster Kind permanece después de eliminar el clúster de administración

Problema

Al ejecutar tanzu mc delete se elimina el clúster de administración, pero no se puede eliminar el clúster kind local de la máquina de arranque.

Solución

1. Enumere todos los clústeres kind en ejecución y elimine los que parecen tkg-kind-unique_ID:

   kind delete cluster --name tkg-kind-unique_ID
   

2. Enumere todos los clústeres en ejecución e identifique el clúster kind.

   docker ps -a
   

3. Copie el identificador de contenedor del clúster kind y elimínelo.

   docker kill container-ID
   

Máquinas bloqueadas después de que el clúster de administración no se implemente

Problema

El clúster de administración independiente no se puede implementar, porque las máquinas se bloquean y esperan una corrección.

Solución

Para un clúster de administración que implementó con el plan dev, que solo tiene un nodo del plano de control, debe volver a implementar el clúster de administración. Para los clústeres de administración con más de un nodo del plano de control, puede identificar y eliminar las máquinas bloqueadas.

1. Recupere el estado del clúster de administración. Por ejemplo:

   kubectl -n tkg-system get cluster my-mgmt-cluster -o yaml
   

2. Busque los nombres de las máquinas bloqueadas en los resultados del paso anterior. Una máquina bloqueada se marca como WaitingForRemediation. Por ejemplo, el nombre de la máquina bloqueada es my-mgmt-cluster-zpc7t en el siguiente resultado:

   status:
     conditions:
     - lastTransitionTime: "2021-08-25T15:44:23Z"
       message: KCP can't remediate if current replicas are less or equal then 1
       reason: WaitingForRemediation @ Machine/my-mgmt-cluster-zpc7t
       severity: Warning
       status: "False"
       type: Ready
   

3. Aumente los valores de tiempo de espera de comprobación de estado de la máquina para los nodos del plano de control a un valor superior al predeterminado, 5m. Por ejemplo:

   tanzu cluster machinehealthcheck control-plane set my-cluster --mhc-name my-control-plane-mhc --unhealthy-conditions "Ready:False:10m,Ready:Unknown:10m"
   

   Para obtener más información sobre la actualización de un objeto MachineHealthCheck, consulte Crear o actualizar un objeto MachineHealthCheck en Configurar comprobaciones de estado de la máquina para clústeres de carga de trabajo.

4. Establezca kubectl en el contexto del clúster de administración. Por ejemplo:

   kubectl config use-context mgmt-cluster-admin@mgmt-cluster
   

5. Elimine las máquinas bloqueadas.

   kubectl delete machine MACHINE-NAME
   

   Donde MACHINE-NAME es el nombre de la máquina ubicada en un paso anterior.

6. Espere a que el controlador KubeadmControlPlane vuelva a implementar la máquina.

Restaurar el directorio ~/.config/tanzu

Problema

El directorio ~/.config/tanzu de la máquina de arranque se eliminó o se dañó accidentalmente. La CLI de Tanzu crea y utiliza este directorio, y no puede funcionar sin él.

Solución

Para restaurar el contenido del directorio ~/.config/tanzu:

1. Para identificar los clústeres de administración de Tanzu Kubernetes Grid existentes, ejecute:

   kubectl --kubeconfig ~/.kube-tkg/config config get-contexts
   

   Los resultados del comando incluyen los nombres y los contextos de todos los clústeres de administración creados o agregados por la CLI de Tanzu.

2. En cada clúster de administración que aparece en el resultado, restáurelo a la CLI y el directorio ~/.config/tanzu ejecutando:

   tanzu login --kubeconfig ~/.kube-tkg/config --context MGMT-CLUSTER-CONTEXT --name MGMT-CLUSTER
   

Al ejecutar la creación de tanzu management-cluster en macOS, se produce un error de versión de kubectl

Problema

Si ejecuta el comando tanzu management-cluster create o tanzu mc create en macOS con la versión estable más reciente de Docker Desktop, se produce un error como el siguiente:

Error: : kubectl prerequisites validation failed: kubectl client version v1.15.5 is less than minimum supported kubectl client version 1.25.7

Esto ocurre porque Docker Desktop crea enlaces simbólicos a una versión anterior de kubectl en la ruta de acceso.

Solución

Coloque una versión compatible más reciente de kubectl en la ruta de acceso antes de la versión de Docker.

Recuperar credenciales del clúster de administración

Si perdió las credenciales de un clúster de administración independiente, por ejemplo, al eliminar accidentalmente el archivo .kube-tkg/config del sistema en el que ejecuta los comandos tanzu, puede recuperar las credenciales del nodo del plano de control del clúster de administración.

1. Ejecute tanzu mc create para volver a crear el archivo .kube-tkg/config.
2. Obtenga la dirección IP pública del nodo del plano de control del clúster de administración de vSphere, AWS o Azure.

3. Utilice SSH para iniciar sesión en el nodo del plano de control del clúster de administración.

   Consulte Conectarse a nodos del clúster con SSH anteriormente para conocer las credenciales que se utilizarán para cada plataforma de destino.

4. Acceda al archivo admin.conf del clúster de administración.

   sudo vi /etc/kubernetes/admin.conf
   

   El archivo admin.conf contiene el nombre del clúster, el nombre de usuario del clúster, el contexto del clúster y los datos del certificado de cliente.

5. Copie el nombre del clúster, el nombre de usuario del clúster, el contexto del clúster y los datos del certificado de cliente en el archivo .kube-tkg/config del sistema en el que ejecuta los comandos tanzu.

Pinniped

Para añadir la administración de identidades externa a una implementación existente, es posible que sea necesario establecer un valor VSPHERE_CONTROL_PLANE_ENDPOINT ficticio

Problema

Para integrar un proveedor de identidad externo con una implementación de TKG existente, es posible que sea necesario establecer un valor VSPHERE_CONTROL_PLANE_ENDPOINT ficticio en el archivo de configuración del clúster de administración utilizado para crear el secreto del complemento, como se describe en Generar el secreto del complemento Pinniped para el clúster de administración

Para desactivar Pinniped, es necesario eliminar Secret de forma manual en los clústeres heredados

Problema

Cuando se desactiva la administración de identidades externa en un clúster de administración, el objeto Pinniped no utilizado Secret permanece presente en los clústeres de carga de trabajo heredados.

Si un usuario intenta acceder al clúster mediante un kubeconfig antiguo, aparecerá una ventana emergente de inicio de sesión y se producirá un error.

Solución alternativa

Elimine manualmente Pinniped Secret del clúster heredado, como se describe en Desactivar administración de identidades.

Error en el trabajo Pinniped posterior a la implementación

Problema

La actualización a Tanzu Kubernetes Grid v2.2 devuelve un error similar al siguiente:

 Operation cannot be fulfilled on certificates.cert-manager.io "pinniped-cert": the object has been modified; please apply your changes to the latest version and try again

Solución

Este error puede producirse si el trabajo posterior a la implementación de Pinniped entra en conflicto con el proceso de actualización de un componente. Siga estos pasos para eliminar y volver a implementar el trabajo.

1. Elimine el trabajo posterior a la implementación de Pinniped.

   kubectl delete jobs.batch -n pinniped-supervisor pinniped-post-deploy-job
   

2. Espere unos 5 minutos hasta que kapp-controller vuelva a implementar el trabajo posterior a la implementación.

3. Compruebe el estado de la aplicación Pinniped.

   kubectl get app -n tkg-system pinniped
   NAME       DESCRIPTION           SINCE-DEPLOY   AGE
   pinniped   Reconcile succeeded   5s             49m
   

   Si DESCRIPTION muestra Reconciling, espere unos minutos y vuelva a comprobarlo. Una vez que muestre Reconcile succeeded, continúe con el siguiente paso.

4. Compruebe el estado del trabajo posterior a la implementación de Pinniped.

   kubectl get jobs -n pinniped-supervisor
   NAME                             COMPLETIONS   DURATION   AGE
   pinniped-post-deploy-job-ver-1   1/1           9s         62s
   

Error de autenticación de Pinniped en el clúster de carga de trabajo después de la actualización del clúster de administración

Problema

Ha actualizado recientemente el clúster de administración. Al intentar autenticarse en un clúster de carga de trabajo asociado con este clúster de administración, recibe un mensaje de error similar al siguiente:

Error: could not complete Pinniped login: could not perform OIDC discovery for "https://IP:PORT": Get "https://IP:PORT/.well-known/openid-configuration": x509: certificate signed by unknown authority

Solución

Esto sucede porque la copia del paquete de CA del supervisor de Pinniped que utiliza el clúster de carga de trabajo está desactualizada. Para actualizar el paquete de CA del supervisor, siga los pasos que se indican a continuación:

1. Establezca el contexto kubectl en el clúster de administración.

2. Obtenga el paquete de CA con codificación base64 y el endpoint issuer de ConfigMap pinniped-info:

   kubectl get configmap pinniped-info -n kube-public -o jsonpath={.data.issuer_ca_bundle_data} > /tmp/ca-bundle && kubectl get configmap pinniped-info -n kube-public -o jsonpath={.data.issuer} > /tmp/supervisor-endpoint
   

3. Obtenga la sección values.yaml del secreto de complemento de Pinniped para el clúster de carga de trabajo:

   kubectl get secret WORKLOAD-CLUSTER-NAME-pinniped-addon -n WORKLOAD-CLUSTER-NAMESPACE -o jsonpath="{.data.values\.yaml}" | base64 -d > values.yaml
   

   Este secreto se encuentra en el clúster de administración.

4. En el archivo values.yaml creado anteriormente, actualice la clave de supervisor_ca_bundle_data para que coincida con el paquete de CA desde ConfigMap pinniped-info. Además, asegúrese de que el supervisor_svc_endpoint coincida con el endpoint issuer.

5. Aplique la actualización mediante codificación base64 del archivo values.yaml editado y sustituyéndolo en el secreto del clúster de carga de trabajo. Este comando varía según el sistema operativo del entorno. Por ejemplo:

   Linux:

   kubectl patch secret/WORKLOAD-CLUSTER-NAME-pinniped-addon -n WORKLOAD-CLUSTER-NAMESPACE -p "{\"data\":{\"values.yaml\":\"$(base64 -w 0 < values.yaml)\"}}" --type=merge
   

   macOS:

   kubectl patch secret/WORKLOAD-CLUSTER-NAME-pinniped-addon -n WORKLOAD-CLUSTER-NAMESPACE -p "{\"data\":{\"values.yaml\":\"$(base64 < values.yaml)\"}}" --type=merge
   

6. En el clúster de carga de trabajo, confirme que la aplicación Pinniped concilió correctamente los cambios:

   kubectl get app pinniped -n tkg-system
   

7. Autentíquese en el clúster. Por ejemplo:

   kubectl get pods -A --kubeconfig my-cluster-credentials
   

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 en Puertos y protocolos de VMware.

CLI de Tanzu

La CLI de Tanzu no puede acceder al clúster de administración

Problema

La ejecución de los comandos de la CLI de tanzu devuelve un error similar al siguiente:

Failed to invoke API on cluster : the server has asked for the client to provide credentials, retrying

Solución

Consulte Actualizar certificado del clúster de administración en la configuración de la CLI de Tanzu y No es posible acceder a los clústeres mediante los comandos de la CLI de tkg/tanzu en Tanzu Kubernetes Grid.

Windows CMD: Caracteres extraños en los encabezados de las columnas de resultados de CLI

Problema

En la línea de comandos de Windows (CMD), los resultados del comando de la CLI de Tanzu con formato en columnas incluye caracteres extraños en los encabezados de las columnas. El problema no ocurre en Windows Terminal ni PowerShell.

Solución

En máquina de arranque de Windows, ejecute la CLI de Tanzu desde Windows Terminal.

La CLI informa de forma errónea temporalmente del estado de los nodos eliminados recientemente cuando se desactivan los MHC

Problema

Cuando las comprobaciones de estado de las máquinas (MHC) se desactivan, los comandos de la CLI de Tanzu, como tanzu cluster status, pueden no informar del estado actualizado del nodo mientras se vuelve a crear la infraestructura.

Solución

Ninguna.

Interfaz del instalador de Tanzu Kubernetes Grid

La interfaz de usuario de Tanzu Kubernetes Grid no se muestra correctamente en Windows

Problema

Al ejecutar el comando tanzu management-cluster create --ui o tanzu mc create --ui en un sistema Windows, la interfaz de usuario se abre en el navegador predeterminado, pero no se aplican los gráficos ni el estilo. Esto sucede porque un registro de Windows se establece en application/x-css.

Solución

1. En la búsqueda de Windows, introduzca regedit para abrir la utilidad Editor del registro (Registry Editor).
2. Expanda HKEY_CLASSES_ROOT y seleccione .js.
3. Haga clic con el botón secundario en Tipo de contenido (Content Type) y seleccione Modificar (Modify).
4. Establezca el valor en application/javascript y haga clic en OK (Aceptar).
5. Vuelva a ejecutar el comando tanzu mc create --ui para volver a iniciar la interfaz de usuario.

NSX Advanced Load Balancer

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 administración con el mismo valor CLUSTER_NAME, ni siquiera desde máquinas de arranque diferentes.

Se produce un error en las solicitudes a NSX Advanced Load Balancer VIP con el mensaje no hay ruta al host

Problema

Si el número total del servicio tipo LoadBalancer es elevado y si todos los motores de servicio están implementados en la misma red de capa 2, se puede producir un error en las solicitudes a NSX Advanced Load Balancer VIP con el mensaje no route to host.

Esto se debe a que el límite de velocidad de ARP predeterminado en los motores de servicio es 100.

Solución

Establezca el límite de velocidad de ARP en un número mayor. Este parámetro no se puede corregir en NSX Advanced Load Balancer Essentials, pero sí en NSX Advanced Load Balancer Enterprise Edition.

Error de AKODeploymentConfig que se puede ignorar durante la creación del clúster de administración

Problema

Al ejecutar tanzu management-cluster create para crear un clúster de administración con NSX ALB, se produce el error no matches for kind ???AKODeploymentConfig??? in version ???networking.tkg.tanzu.vmware.com/v1alpha1???.

Solución

Se puede ignorar el error. Para obtener más información, consulte el artículo de la KB.

Se produce un error en la CNI de Multus en pods medium y más pequeños con NSX Advanced Load Balancer

Problema

En vSphere, los clústeres de carga de trabajo con nodos de trabajo medium o más pequeños que ejecutan el paquete de la CNI de Multus con NSX ALB pueden generar errores con Insufficient CPU u otro tipo de errores.

Solución

Para utilizar la CNI de Multus con NSX ALB, implemente clústeres de carga de trabajo con nodos de trabajo de tamaño large o extra-large.

Actualizar

Se produce un error al actualizar los clústeres en Azure

Problema

En Azure, se produce un error al actualizar los clústeres de administración y los clústeres de carga de trabajo con errores como context deadline exceeded o unable to upgrade management cluster: error waiting for kubernetes version update for kubeadm control plane. Esto sucede porque las operaciones en Azure a veces tardan más que en otras plataformas.

Solución

Vuelva a ejecutar tanzu management-cluster upgrade o tanzu cluster upgrade y especifique un tiempo de espera más largo en la marca --timeout. El tiempo de espera predeterminado es 30m0s.

Se produce un error en la actualización de los clústeres de administración independientes creados originalmente en TKG v1.3 o versiones anteriores

Problema

En TKG v2.2, los componentes que convierten un clúster genérico en un clúster de administración independiente de TKG se empaquetan en un paquete Carvel tkg-pkg. Los clústeres de administración independientes que se crearon originalmente en TKG v1.3 o versiones anteriores carecen de un secreto de configuración que el proceso de actualización requiere para instalar tkg-pkg, lo que provoca un error en la actualización.

Solución

Realice los pasos adicionales que se indican en Actualizar clústeres de administración independientes para los clústeres de administración independientes creados en TKG v1.3 o versiones anteriores.