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.
Algunos de los siguientes procedimientos utilizan la CLI kind
. Para instalar kind
, consulte Instalación en la documentación de kind
.
087bf3b4 (actualizaciones de RN para Ghost [#1178])
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:
capv
ubuntu
ubuntu
ec2-user
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:
ssh capv@node-address
ssh ubuntu@node-address
ssh ec2-user@node-address
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
.
kubectl
Para limpiar su estado kubectl
eliminando algunos o todos sus usuarios, contextos y clústeres:
Abra el archivo ~/.kube-tkg/config
.
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
.
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
.
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
.
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
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 context delete
como se describe en Eliminar clústeres de administración desde la configuración de la CLI de Tanzu.
nfs-utils
en los nodos de Photon OSProblema
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
Problema
Debido a un problema de etiquetado de recursos en el proveedor de API del clúster AWS (CAPA) ascendente, las implementaciones sin conexión no pueden acceder a la API ResourceTagging
, lo que provoca errores de conciliación durante la creación o la actualización del clúster de administración.
Solución
En un entorno de AWS sin conexión, establezca EXP_EXTERNAL_RESOURCE_GC=false
en el entorno local o en el archivo de configuración del clúster de administración antes de ejecutar tanzu mc create
o tanzu mc upgrade
.
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.
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:
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
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…”).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 plataforma de destino:
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.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:
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.
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:
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
Editar el secreto para incluir las credenciales de AWS:
[default]
aws_access_key_id = <key id>
aws_secret_access_key = <access_key>
region = <region>
Ejecute tanzu mc delete
de nuevo.
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
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
Enumere todos los clústeres en ejecución e identifique el clúster kind
.
docker ps -a
Copie el identificador de contenedor del clúster kind
y elimínelo.
docker kill container-ID
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.
Recupere el estado del clúster de administración. Por ejemplo:
kubectl -n tkg-system get cluster my-mgmt-cluster -o yaml
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
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.
Establezca kubectl
en el contexto del clúster de administración. Por ejemplo:
kubectl config use-context mgmt-cluster-admin@mgmt-cluster
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.
Espere a que el controlador KubeadmControlPlane
vuelva a implementar la máquina.
~/.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
:
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.
En cada clúster de administración que aparece en el resultado, restáurelo a la CLI y el directorio ~/.config/tanzu
ejecutando:
tanzu context create --management-cluster --kubeconfig ~/.kube-tkg/config --context MGMT-CLUSTER-CONTEXT --name MGMT-CLUSTER
tanzu management-cluster
en macOS, se produce un error de versión de kubectlProblema
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.26.8
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.
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.
tanzu mc create
para volver a crear el archivo .kube-tkg/config
.Utilice SSH para iniciar sesión en el nodo del plano de control del clúster de administración.
Consulte Conectarse a los nodos del clúster con SSH anteriormente para conocer las credenciales que se utilizarán para cada plataforma de destino.
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.
.kube-tkg/config
del sistema en el que ejecuta los comandos tanzu
.VSPHERE_CONTROL_PLANE_ENDPOINT
ficticioProblema
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
Secret
de forma manual en los clústeres heredadosProblema
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.
Problema
La actualización a Tanzu Kubernetes Grid v2.3 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.
Elimine el trabajo posterior a la implementación de Pinniped.
kubectl delete jobs.batch -n pinniped-supervisor pinniped-post-deploy-job
Espere unos 5 minutos hasta que kapp-controller
vuelva a implementar el trabajo posterior a la implementación.
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.
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
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:
Establezca el contexto kubectl
en el clúster de administración.
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
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.
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
.
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
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
Autentíquese en el clúster. Por ejemplo:
kubectl get pods -A --kubeconfig my-cluster-credentials
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.
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.
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.
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.
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
regedit
para abrir la utilidad Editor del registro (Registry Editor).HKEY_CLASSES_ROOT
y seleccione .js
.application/javascript
y haga clic en OK (Aceptar).tanzu mc create --ui
para volver a iniciar la interfaz de usuario.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.
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.
AKODeploymentConfig
que se puede ignorar durante la creación del clúster de administraciónProblema
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.
medium
y más pequeños con NSX Advanced Load BalancerProblema
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
.
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.
Problema
En TKG v2.3, 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.