En las secciones siguientes, se describen los problemas que puedes encontrar cuando usas GKE On-Prem y cómo resolverlos.
Antes de comenzar
Revisa las siguientes secciones antes de comenzar a solucionar problemas.
Diagnostica problemas de clústeres mediante gkectl
Usa los comandos gkectl diagnose
para identificar los problemas de clústeres y compartir la información de un clúster con Google. Consulta Diagnostica problemas de clústeres.
Comportamiento de registro predeterminado
Para gkectl
y gkeadm
, basta con usar la configuración de registro predeterminada:
-
De forma predeterminada, las entradas de registro se guardan de la siguiente manera:
-
Para
gkectl
, el archivo de registro predeterminado es/home/ubuntu/.config/gke-on-prem/logs/gkectl-$(date).log
y el archivo está vinculado con un symlink con el archivologs/gkectl-$(date).log
en el directorio local en el que ejecutasgkectl
. -
Para
gkeadm
, el archivo de registro predeterminado eslogs/gkeadm-$(date).log
en el directorio local en el que ejecutasgkeadm
.
-
Para
- Todas las entradas de registro se guardan en el archivo de registro, incluso si no se imprimen en la terminal (cuando
--alsologtostderr
esfalse
). - El nivel de verbosidad
-v5
(predeterminado) cubre todas las entradas de registro que necesita el equipo de asistencia al cliente. - El archivo de registro también contiene el comando ejecutado y el mensaje de error.
Recomendamos que envíes el archivo de registro al equipo de asistencia al cliente cuando necesites ayuda.
Especifica una ubicación no predeterminada para el archivo de registro
A fin de especificar una ubicación no predeterminada para el archivo de registro gkectl
, usa la marca --log_file
. El archivo de registro que especifiques no se vinculará con un symlink con el directorio local.
A fin de especificar una ubicación no predeterminada para el archivo de registro gkeadm
, usa la marca --log_file
.
Ubica los registros de la API de clúster en el clúster de administrador
Si una VM no se inicia después de que se inicia el plano de control de administrador, puedes intentar depurarla mediante la inspección de los registros de los controladores de la API de clúster en el clúster de administrador:
Encuentra el nombre del Pod de controladores de la API de clúster en el espacio de nombres
kube-system
, en el que [ADMIN_CLUSTER_KUBECONFIG] es la ruta de acceso al archivo kubeconfig del clúster de administrador:kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] -n kube-system get pods | grep clusterapi-controllers
Abre los registros del Pod, en los que [POD_NAME] es el nombre del Pod. De manera opcional, usa
grep
o una herramienta similar para buscar errores:kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] -n kube-system logs [POD_NAME] vsphere-controller-manager
Instalación
Depura los problemas de BIG-IP de F5 mediante el kubeconfig del nodo del plano de control del clúster de administrador
Después de una instalación, GKE On-Prem genera un archivo kubeconfig llamado internal-cluster-kubeconfig-debug
en el directorio principal de la estación de trabajo de administrador. Este archivo kubeconfig es idéntico al kubeconfig de tu clúster de administrador, excepto que apunta directamente al nodo del plano de control del clúster de administrador, en el que se ejecuta el plano de control de administrador. Puedes usar el archivo internal-cluster-kubeconfig-debug
para depurar los problemas de BIG-IP de F5.
La validación de gkectl check-config
falla: No se pueden encontrar las particiones de BIG-IP de F5
- Síntomas
La validación falla porque las particiones de BIG-IP de F5 no se pueden encontrar, aunque existen.
- Causas posibles
Un problema con la API de BIG-IP de F5 puede causar que la validación falle.
- Solución
Vuelve a ejecutar
gkectl check-config
.
gkectl prepare --validate-attestations
falla: No se puede validar la certificación de la compilación
- Síntomas
La ejecución de
gkectl prepare
con la marca opcional--validate-attestations
muestra el siguiente error:could not validate build attestation for gcr.io/gke-on-prem-release/.../...: VIOLATES_POLICY
- Causas posibles
Es posible que no exista una certificación para las imágenes afectadas.
- Solución
Vuelve a descargar y a implementar el OVA de la estación de trabajo de administrador, como se indica en Crea una estación de trabajo de administrador. Si el problema persiste, comunícate con Google para obtener asistencia.
Depura mediante los registros del clúster de arranque
Durante la instalación, GKE On-Prem crea un clúster de arranque temporal. Después de una instalación exitosa, GKE On-Prem borra el clúster de arranque, por lo que solo tienes el clúster de administrador y el de usuario. Por lo general, no deberías tener ningún motivo para interactuar con este clúster.
Si algo sale mal durante una instalación y pasaste --cleanup-external-cluster=false
a gkectl create cluster
, es posible que te resulte útil depurar mediante los registros del clúster de arranque. Puedes buscar el Pod y, luego, obtener sus registros:
kubectl --kubeconfig /home/ubuntu/.kube/kind-config-gkectl get pods -n kube-system
kubectl --kubeconfig /home/ubuntu/.kube/kind-config-gkectl -n kube-system get logs [POD_NAME]
Complemento de autenticación para Anthos
Mantén la CLI de gcloud anthos auth
actualizada
Muchos problemas comunes se pueden evitar si se comprueba que los componentes de la instalación de gcloud anthos auth
están actualizados con las correcciones de la versión más reciente.
Hay dos partes que deben verificarse, puesto que el comando gcloud anthos auth
tiene lógica en el componente principal gcloud
y un componente anthos-auth
empaquetado por separado.
-
El componente principal
gcloud
.-
Para actualizar el componente principal
gcloud
, ejecutagcloud components update
-
Verifica que tu instalación de
gcloud
no esté desactualizada. Para ello, ejecuta el siguiente comando y comprueba que la fecha impresa sea de los últimos 12 días.gcloud version
-
-
El componente
anthos-auth
.-
Para actualizar el componente
anthos-auth
, ejecutagcloud components install anthos-auth
-
Verifica que tu instalación de
anthos-auth
no esté desactualizada. Para ello, ejecuta el siguiente comando y comprueba que la versión sea la v1.1.3 o superior.gcloud anthos auth version
-
Instalaciones de apt-get
de gcloud
Para comprobar si tu instalación de gcloud
se administra a través de apt-get
, ejecuta el comando gcloud
components update
y verifica el siguiente error.
$ gcloud components update ERROR: (gcloud.components.update) You cannot perform this action because the gcloud CLI component manager is disabled for this installation. You can run the following command to achieve the same result for this installation: ...
Problema: No puedes realizar esta acción porque el administrador de componentes de la CLI de gcloud está inhabilitado para esta instalación:
Para las instalaciones administradas mediante apt-get
, la ejecución de los comandos de gcloud components
anteriores no funcionará directamente y generará un mensaje de error similar al que se mostró antes. Sin embargo, ejecutar los comandos gcloud components update
y gcloud components install anthos-auth
mostrará los comandos apt-get
específicos que puedes ejecutar para actualizar la instalación.
Falla en la ejecución de gkectl create-login-config
Problema 1:
- Síntomas
Cuando ejecutas
gkectl create-login-config
, se produce el siguiente error:Error getting clientconfig using [user_cluster_kubeconfig]
- Causas posibles
Este error significa que el archivo kubeconfig que se pasó a
gkectl create-login-config
no es para un clúster de usuario o que la CRD de ClientConfig no apareció durante la creación del clúster.- Solución
Ejecuta el siguiente comando para ver si la CRD de ClientConfig está en el clúster:
kubectl --kubeconfig [user_cluster_kubeconfig] get clientconfig default -n kube-public
Problema 2:
- Síntomas
Cuando ejecutas
gkectl create-login-config
, se produce el siguiente error:error merging with file [merge_file] because [merge_file] contains a cluster with the same name as the one read from [kubeconfig]. Please write to a new output file
- Causas posibles
Cada archivo de configuración de acceso debe contener nombres de clúster únicos. Si ves este error, entonces el archivo en el que escribes los datos del archivo de configuración de acceso contiene un nombre de clúster que ya existe en el archivo de destino.
- Solución
Escribe en un archivo
--output
nuevo. Ten en cuenta lo siguiente:- Si no se proporciona
--output
, los datos del archivo de configuración de acceso se escribirán de forma predeterminada en un archivo llamadokubectl-anthos-config.yaml
en el directorio actual. - Si
--output
ya existe, el comando intentará combinar el archivo de configuración de acceso nuevo con--output
.
- Si no se proporciona
Falla en la ejecución de gcloud anthos auth
login
Problema 1:
- Síntomas
Falla la ejecución de
login
mediante el complemento de autenticación y el archivo de configuración de acceso en formato YAML que se generó.- Causas posibles
Es posible que haya un error en los detalles de configuración de OIDC.
- Solución
Verifica el registro del cliente de OIDC con tu administrador.
Problema 2:
- Síntomas
Cuando se configura un proxy para el tráfico HTTPS, la ejecución del comando
gcloud anthos auth login
falla y se muestraproxyconnect tcp
en el mensaje de error. Un ejemplo del tipo de mensaje que puedes ver esproxyconnect tcp: tls: first record does not look like a TLS handshake
.- Causas posibles
Es posible que haya un error en las opciones de configuración de las variables de entorno
https_proxy
oHTTPS_PROXY
. Si se especificahttps://
en las variables de entorno, las bibliotecas cliente HTTP de GoLang pueden fallar si el proxy está configurado para controlar conexiones HTTPS mediante otros protocolos, como SOCK5.- Solución
Modifica las variables de entorno
https_proxy
yHTTPS_PROXY
para omitir el prefijohttps://
. En Windows, modifica las variables de entorno del sistema. Por ejemplo, cambia el valor de la variable de entornohttps_proxy
dehttps://webproxy.example.com:8000
awebproxy.example.com:8000
.
Falla el uso de kubeconfig que generó gcloud anthos auth login
para acceder al clúster
- Síntomas
Error “No autorizado”
Si hay un error “No autorizado” cuando se usa el kubeconfig que
gcloud anthos auth login
generó para acceder al clúster, significa que el apiserver no puede autorizar al usuario.- Causas posibles
- Faltan los RBAC adecuados, son incorrectos o hay un error en la configuración de OIDC para el clúster.
- Solución
- Intenta seguir estos pasos para resolver el problema:
Analiza el
id-token
desde kubeconfig.En el archivo kubeconfig que generó el comando de acceso, copia el archivo
id-token
:kind: Config … users: - name: … user: auth-provider: config: id-token: [id-token] …
Sigue los pasos para instalar jwt-cli y ejecuta lo siguiente:
jwt [id-token]
Verifica la configuración de OIDC.
En la sección
oidc
completada enconfig.yaml
, que se usó en la creación del clúster, se encuentran los camposgroup
yusername
, que se usan para establecer las marcas--oidc-group-claim
y--oidc-username-claim
en el apiserver. Cuando se presenta el apiserver con el token, buscará esa reclamación de grupo y de nombre de usuario y verificará que el grupo o usuario correspondiente tenga los permisos correctos.Verifica que las reclamaciones establecidas para
group
yuser
en la secciónoidc
deconfig.yaml
estén presentes en elid-token
.Verifica los RBAC que se aplicaron.
Verifica que haya un RBAC con los permisos correctos para el usuario que especifica la reclamación de nombre de usuario o uno de los grupos enumerados en la reclamación de grupo del paso anterior. El nombre del usuario o grupo en el RBAC debe tener el prefijo
usernameprefix
ogroupprefix
que se proporcionó en la secciónoidc
deconfig.yaml
.Ten en cuenta que si
usernameprefix
se dejó en blanco yusername
es un valor distinto deemail
, el prefijo seráissuerurl#
de forma predeterminada. Para inhabilitar los prefijos de nombre de usuario,usernameprefix
debe establecerse como-
.Para obtener más información sobre los prefijos de usuarios y grupos, consulta Propaga la especificación oidc.
Ten en cuenta que, por el momento, el servidor de la API de Kubernetes trata una barra inversa como un carácter de escape. Por lo tanto, si el nombre del usuario o grupo contiene
\\
, el servidor de la API lo leerá como una sola\
cuando analice elid_token
. Es por eso que el RBAC aplicado a este usuario o grupo debe contener solo una barra inversa o es posible que se produzca un errorUnauthorized
.Ejemplo:
config.yaml:
oidc: issuerurl: … username: "unique_name" usernameprefix: "-" group: "group" groupprefix: "oidc:" ...
id_token:
{ ... "email": "cluster-developer@example.com", "unique_name": "EXAMPLE\\cluster-developer", "group": [ "Domain Users", "EXAMPLE\\developers" ], ... }
Los siguientes RBAC otorgarían a este usuario permisos de administrador de clústeres (ten en cuenta que hay una sola barra en el campo de nombre en lugar de una barra doble):
Group RBAC:
apiVersion: kind: metadata: name: example-binding subjects: - kind: Group name: "oidc:EXAMPLE\developers" apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: pod-reader apiGroup: rbac.authorization.k8s.io
User RBAC:
apiVersion: kind: metadata: name: example-binding subjects: - kind: User name: "EXAMPLE\cluster-developer" apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: pod-reader apiGroup: rbac.authorization.k8s.io
Verifica los registros del servidor de la API.
Si el complemento de OIDC configurado en kube apiserver no se inicia de forma correcta, el servidor de la API mostrará un error “No autorizado” cuando se presente con el
id-token
. Para ver si hubo algún problema con el complemento OIDC en el servidor de la API, ejecuta lo siguiente:kubectl --kubeconfig=[admin_cluster_kubeconfig] logs statefulset/kube-apiserver -n [user_cluster_name]
- Síntomas
No se pudo establecer una conexión con el servidor: obtén el certificado {DISCOVERY_ENDPOINT}: x509 firmado por una autoridad desconocida
- Causas posibles
El token de actualización de kubeconfig caducó.
- Solución
Ejecuta el comando
login
de nuevo.
Acceso a la consola de Google Cloud
Los siguientes son errores comunes que pueden ocurrir cuando usas la consola de Google Cloud para el acceso:
Acceso que redirecciona a la página con el error “No se encuentra la URL”
- Síntomas
La consola de Google Cloud no puede acceder al proveedor de identidad de GKE On-Prem.
- Causas posibles
La consola de Google Cloud no puede acceder al proveedor de identidad de GKE On-Prem.
- Solución
Te sugerimos seguir estos pasos para intentar resolver el problema:
-
Configura
useHTTPProxy
entrue
.Si no se puede acceder al IDP a través de la Internet pública, deberás habilitar el proxy HTTP de OIDC para acceder mediante la consola de Google Cloud. En la sección
oidc
deconfig.yaml
,usehttpproxy
debe establecerse entrue
. Si ya creaste un clúster y quieres activar el proxy, puedes editar la CRD de ClientConfig directamente. Ejecuta$ kubectl edit clientconfig default -n kube-public
y cambiauseHTTPProxy
portrue
. useHTTPProxy
ya está establecido entrue
Si el proxy HTTP está habilitado y sigue apareciendo este error, es posible que se haya generado un problema mientras se iniciaba el proxy. Para obtener los registros del proxy, ejecuta
$ kubectl logs deployment/clientconfig-operator -n kube-system
. Ten en cuenta que, incluso si tu IDP tiene una CA conocida, se debe proporcionar el campocapath
en la secciónoidc
deconfig.yaml
para iniciar el proxy HTTP.Solicitudes de IDP de consentimiento
Si el servidor de autorización solicita el consentimiento y no incluiste el extraparam
prompt=consent
, es posible que veas este error. Ejecuta$ kubectl edit clientconfig default -n kube-public
, agregaprompt=consent
aextraparams
e intenta acceder de nuevo.Los RBAC están mal configurados
Si aún no lo hiciste, intenta autenticar con el complemento de autenticación para Anthos. Si también ves un error de autorización cuando accedes con el complemento, sigue los pasos para solucionar problemas a fin de resolver el problema del complemento y vuelve a acceder a través de la consola de Google Cloud.
Intenta salir y volver a acceder
En algunos casos, si se cambia la configuración del servicio de almacenamiento, es posible que debas salir de forma explícita. Ve a la página de detalles del clúster, haz clic en Salir y vuelve a acceder.
Estación de trabajo de administrador
openssl
no puede validar el OVA de la estación de trabajo de administrador- Síntomas
Si ejecutas
openssl dgst
en el archivo OVA de la estación de trabajo de administrador, no se muestra el mensajeVerified OK
.- Causas posibles
Hay un problema en el archivo OVA que impide que la validación se realice con éxito.
- Solución
Vuelve a descargar y a implementar el OVA de la estación de trabajo de administrador, como se indica en Descarga el OVA de la estación de trabajo de administrador. Si el problema persiste, comunícate con Google para obtener asistencia.
Connect
No se puede registrar un clúster de usuario
Si tienes problemas para registrar los clústeres de usuario, comunícate con Google a fin de obtener asistencia.
El registro del clúster que se creó durante la etapa Alfa se anuló
Consulta Registra un clúster de usuario en la documentación de Connect.
También puedes elegir borrar y volver a crear el clúster.
Storage
No se puede conectar el volumen
Síntomas
El resultado de
gkectl diagnose cluster
se parece al siguiente ejemplo:Checking cluster object...PASS Checking machine objects...PASS Checking control plane pods...PASS Checking gke-connect pods...PASS Checking kube-system pods...PASS Checking gke-system pods...PASS Checking storage...FAIL PersistentVolume pvc-776459c3-d350-11e9-9db8-e297f465bc84: virtual disk "[datastore_nfs] kubevols/kubernetes-dynamic-pvc-776459c3-d350-11e9-9db8-e297f465bc84.vmdk" IS attached to machine "gsl-test-user-9b46dbf9b-9wdj7" but IS NOT listed in the Node.Status 1 storage errors
Uno o más Pods están atascados en el estado
ContainerCreating
con una advertencia como la que se muestra a continuación:Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning FailedAttachVolume 6s (x6 over 31s) attachdetach-controller AttachVolume.Attach failed for volume "pvc-776459c3-d350-11e9-9db8-e297f465bc84" : Failed to add disk 'scsi0:6'.
Causas posibles
Si un disco virtual está conectado a la máquina virtual incorrecta, puede deberse al problema n.º 32727 en Kubernetes 1.12.
Solución
Si un disco virtual está conectado a la máquina virtual incorrecta, es posible que debas desconectarlo de forma manual:
- Desvía el nodo.
Consulta Safely drain a node (Desvío seguro de un nodo). Te recomendamos incluir las marcas
--ignore-daemonsets
y--delete-local-data
en tu comandokubectl drain
. - Apaga la VM.
- Edita el archivo de configuración de hardware de la VM en vCenter para quitar el volumen.
- Enciende la VM.
- Desacordona el nodo.
Se perdió el volumen
Síntomas
El resultado de
gkectl diagnose cluster
se parece al siguiente ejemplo:Checking cluster object...PASS Checking machine objects...PASS Checking control plane pods...PASS Checking gke-connect pods...PASS Checking kube-system pods...PASS Checking gke-system pods...PASS Checking storage...FAIL PersistentVolume pvc-52161704-d350-11e9-9db8-e297f465bc84: virtual disk "[datastore_nfs] kubevols/kubernetes-dynamic-pvc-52161704-d350-11e9-9db8-e297f465bc84.vmdk" IS NOT found 1 storage errors
Uno o más Pods están atascados en el estado
ContainerCreating
con una advertencia como la que se muestra a continuación:Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning FailedAttachVolume 71s (x28 over 42m) attachdetach-controller AttachVolume.Attach failed for volume "pvc-52161704-d350-11e9-9db8-e297f465bc84" : File []/vmfs/volumes/43416d29-03095e58/kubevols/ kubernetes-dynamic-pvc-52161704-d350-11e9-9db8-e297f465bc84.vmdk was not found
Causas posibles
Si ves un error “no encontrado” relacionado con tu archivo VMDK, es probable que el disco virtual se haya borrado de forma permanente. Esto puede suceder si un operador borra de forma manual un disco virtual o la máquina virtual a la que está conectado. Para evitar esto, administra tus máquinas virtuales como se describe en Cambia el tamaño de un clúster de usuario y Actualiza clústeres.
Solución
Si se borró un disco virtual de manera permanente, es posible que tengas que limpiar de forma manual los recursos relacionados de Kubernetes:
- Ejecuta
kubectl delete pvc [PVC_NAME].
para borrar el PVC que hizo referencia al PV. - Ejecuta
kubectl delete pod [POD_NAME].
para borrar el Pod que hizo referencia al PVC. - Repite el paso 2. (Sí, de verdad. Consulta el problema 74374 de Kubernetes).
No se puede desconectar el volumen de CSI de vSphere
Síntomas
Si encuentras pods atascados en la fase
ContainerCreating
con advertenciasFailedAttachVolume
, podría deberse a una desconexión con errores en un nodo diferente.Ejecuta el siguiente comando para encontrar errores de desconexión de CSI:
kubectl get volumeattachments -o=custom-columns=NAME:metadata.name,DETACH_ERROR:status.detachError.message
El resultado debe tener el siguiente aspecto:
NAME DETACH_ERROR csi-0e80d9be14dc09a49e1997cc17fc69dd8ce58254bd48d0d8e26a554d930a91e5 rpc error: code = Internal desc = QueryVolume failed for volumeID: "57549b5d-0ad3-48a9-aeca-42e64a773469". ServerFaultCode: NoPermission csi-164d56e3286e954befdf0f5a82d59031dbfd50709c927a0e6ccf21d1fa60192d
csi-8d9c3d0439f413fa9e176c63f5cc92bd67a33a1b76919d42c20347d52c57435c csi-e40d65005bc64c45735e91d7f7e54b2481a2bd41f5df7cc219a2c03608e8e7a8 Causas posibles
El privilegio
CNS > Searchable
no se otorgó al usuario de vSphere.Solución
Agrega el privilegio
CNS > Searchable
a tu cuenta de usuario de vCenter. La operación de desconexión se reintenta automáticamente hasta tener éxito.Actualizaciones
Información sobre el tiempo de inactividad durante las actualizaciones
Recurso Descripción Clúster de administrador Cuando un clúster de administrador está inactivo, los planos de control y las cargas de trabajo en los clústeres de usuario continúan ejecutándose, a menos que se vean afectados por una falla que causó el tiempo de inactividad.
Plano de control del clúster de usuario Por lo general, no es probable que se produzcan tiempos de inactividad perceptibles en los planos de control del clúster de usuario. Sin embargo, las conexiones de larga duración al servidor de la API de Kubernetes podrían fallar y tendrían que restablecerse. En esos casos, el emisor de la API debe volver a intentarlo hasta que se establezca una conexión. En el peor de los casos, puede haber hasta un minuto de tiempo de inactividad durante una actualización.
Nodos del clúster de usuario Si una actualización requiere un cambio en los nodos del clúster de usuario, GKE On-Prem los vuelve a crear de forma progresiva y reprograma los Pods que se ejecutan en estos nodos. Puedes evitar el impacto en tus cargas de trabajo; para ello, configura PodDisruptionBudgets y reglas de antiafinidad adecuados.
Puede que sea necesario renovar los certificados antes de que se actualice el clúster de administrador
Antes de comenzar el proceso de actualización de clústeres de administrador, debes asegurarte de que tus certificados de clúster de administrador sean actualmente válidos y renovarlos si no lo son.
Proceso de renovación del certificado del clúster de administrador
Antes de comenzar, asegúrate de que OpenSSL esté instalado en la estación de trabajo de administrador.
Configura la variable
KUBECONFIG
.KUBECONFIG=ABSOLUTE_PATH_ADMIN_CLUSTER_KUBECONFIG
Reemplaza ABSOLUTE_PATH_ADMIN_CLUSTER_KUBECONFIG por la ruta absoluta al archivo kubeconfig del clúster de administrador.
Obtén la dirección IP y las claves SSH del nodo principal de administrador:
kubectl --kubeconfig "${KUBECONFIG}" get secrets -n kube-system sshkeys \ -o jsonpath='{.data.vsphere_tmp}' | base64 -d > \ ~/.ssh/admin-cluster.key && chmod 600 ~/.ssh/admin-cluster.key export MASTER_NODE_IP=$(kubectl --kubeconfig "${KUBECONFIG}" get nodes -o \ jsonpath='{.items[*].status.addresses[?(@.type=="ExternalIP")].address}' \ --selector='node-role.kubernetes.io/master')
Verifica si los certificados vencieron:
ssh -i ~/.ssh/admin-cluster.key ubuntu@"${MASTER_NODE_IP}" \ "sudo kubeadm alpha certs check-expiration"
Si los certificados vencieron, debes renovarlos antes de actualizar el clúster de administrador.
Crea una copia de seguridad de los certificados anteriores:
Este es un paso opcional, pero recomendado.
# ssh into admin master ssh -i ~/.ssh/admin-cluster.key ubuntu@"${MASTER_NODE_IP}" # on admin master sudo tar -czvf backup.tar.gz /etc/kubernetes logout # on worker node sudo scp -i ~/.ssh/admin-cluster.key \ ubuntu@"${MASTER_NODE_IP}":/home/ubuntu/backup.tar.gz .
Renueva los certificados con kubeadm:
# ssh into admin master ssh -i ~/.ssh/admin-cluster.key ubuntu@"${MASTER_NODE_IP}" # on admin master sudo kubeadm alpha certs renew all
Reinicia el nodo principal del administrador:
# on admin master cd /etc/kubernetes sudo mkdir tempdir sudo mv manifests/*.yaml tempdir/ sleep 5 echo "remove pods" # ensure kubelet detect those change remove those pods # wait until the result of this command is empty sudo docker ps | grep kube-apiserver # ensure kubelet start those pods again echo "start pods again" sudo mv tempdir/*.yaml manifests/ sleep 30 # ensure kubelet start those pods again # should show some results sudo docker ps | grep -e kube-apiserver -e kube-controller-manager -e kube-scheduler -e etcd # clean up sudo rm -rf tempdir logout
Debido a que el archivo kubeconfig del clúster de administrador también vence si los certificados de administrador vencen, debes crear una copia de seguridad de este archivo antes de la fecha de vencimiento.
Crea una copia de seguridad del archivo kubeconfig del clúster de administrador:
ssh -i ~/.ssh/admin-cluster.key ubuntu@"${MASTER_NODE_IP}"
"sudo cat /etc/kubernetes/admin.conf" > new_admin.conf vi "${KUBECONFIG}"Reemplaza
client-certificate-data
yclient-key-data
en la kubeconfig porclient-certificate-data
yclient-key-data
en el archivonew_admin.conf
que creaste.
Debes validar los certificados renuevas y el certificado de kube-apiserver.
Verifica el vencimiento de los certificados:
ssh -i ~/.ssh/admin-cluster.key ubuntu@"${MASTER_NODE_IP}"
"sudo kubeadm alpha certs check-expiration"Verifica el certificado de kube-apiserver:
# Get the IP address of kube-apiserver cat $KUBECONFIG | grep server # Get the current kube-apiserver certificate openssl s_client -showcerts -connect
:
| sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p'
> current-kube-apiserver.crt # check expiration date of this cert openssl x509 -in current-kube-apiserver.crt -noout -enddate
Cambia el tamaño de los clústeres de usuario
El cambio de tamaño de un clúster de usuario falla
- Síntomas
Una operación de cambio de tamaño en un clúster de usuario falla.
- Causas posibles
Varios factores pueden hacer que las operaciones de cambio de tamaño fallen.
- Solución
Si falla el cambio de tamaño, sigue estos pasos:
Verifica el estado del MachineDeployment del clúster para ver si hay eventos o mensajes de error:
kubectl describe machinedeployments [MACHINE_DEPLOYMENT_NAME]
Verifica si hay errores en las máquinas recién creadas:
kubectl describe machine [MACHINE_NAME]
Error: “No se pueden asignar direcciones”
- Síntomas
Después de cambiar el tamaño de un clúster de usuario,
kubectl describe machine [MACHINE_NAME]
muestra el siguiente error:Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning Failed 9s (x13 over 56s) machineipam-controller ipam: no addresses can be allocated
- Causas posibles
No hay suficientes direcciones IP disponibles para el clúster de usuario.
- Solución
Asigna más direcciones IP al clúster. Luego, borra la máquina afectada:
kubectl delete machine [MACHINE_NAME]
Si el clúster se configura de forma correcta, se creará una máquina de reemplazo con una dirección IP.
Hay una cantidad suficiente de direcciones IP asignadas, pero la máquina no se registra con el clúster
- Síntomas
La red tiene suficientes direcciones asignadas, pero la máquina aún no se logra registrar con el clúster de usuario.
- Causas posibles
Puede haber un conflicto de IP. Es posible que otra máquina o tu balanceador de cargas tome la IP.
- Solución
Verifica que no se haya tomado la dirección IP de la máquina afectada. Si hay un conflicto, debes resolverlo en tu entorno.
vSphere
Realiza una depuración con
govc
Si tienes problemas específicos de vSphere, puedes usar
govc
para solucionarlos. Por ejemplo, puedes confirmar con facilidad los permisos y el acceso de tus cuentas de usuario de vCenter y recopilar registros de vSphere.Camba el certificado de vCenter
Si ejecutas vCenter Server en modo de evaluación o de configuración predeterminado y tiene un certificado TLS generado, este certificado puede cambiar con el tiempo. Si cambió, debes informar a tus clústeres en ejecución sobre el certificado nuevo:
Recupera el certificado nuevo de vCenter y guárdalo en un archivo:
true | openssl s_client -connect [VCENTER_IP_ADDRESS]:443 -showcerts 2>/dev/null | sed -ne '/-BEGIN/,/-END/p' > vcenter.pem
Ahora puedes borrar el ConfigMap que contiene el certificado de vSphere y vCenter de cada clúster y crear un ConfigMap con el certificado nuevo. Por ejemplo:
kubectl --kubeconfig kubeconfig delete configmap vsphere-ca-certificate -n kube-system
kubectl --kubeconfig kubeconfig delete configmap vsphere-ca-certificate -n user-cluster1
kubectl --kubeconfig kubeconfig create configmap -n user-cluster1 --dry-run vsphere-ca-certificate --from-file=ca.crt=vcenter.pem -o yaml | kubectl --kubeconfig kubeconfig apply -f -
kubectl --kubeconfig kubeconfig create configmap -n kube-system --dry-run vsphere-ca-certificate --from-file=ca.crt=vcenter.pem -o yaml | kubectl --kubeconfig kubeconfig apply -f -
Borra el Pod clusterapi-controllers de cada clúster. Cuando el Pod se reinicia, comienza a usar el certificado nuevo. Por ejemplo:
kubectl --kubeconfig kubeconfig -n kube-system get pods
kubectl --kubeconfig kubeconfig -n kube-system delete pod clusterapi-controllers-...
Varios
Límite de sesiones del proveedor de vSphere de Terraform
GKE On-Prem usa el proveedor de vSphere de Terraform para abrir las VM en tu entorno de vSphere. El límite de sesiones del proveedor es de 1,000 sesiones. La implementación actual no cierra las sesiones activas después de su uso. Es posible que experimentes errores 503 si tienes demasiadas sesiones en ejecución.
Las sesiones se cierran de forma automática después de 300 segundos.
- Síntomas
Si tienes demasiadas sesiones en ejecución, es posible que encuentres el siguiente error:
Error connecting to CIS REST endpoint: Login failed: body: {"type":"com.vmware.vapi.std.errors.service_unavailable","value": {"messages":[{"args":["1000","1000"],"default_message":"Sessions count is limited to 1000. Existing sessions are 1000.", "id":"com.vmware.vapi.endpoint.failedToLoginMaxSessionCountReached"}]}}, status: 503 Service Unavailable
- Causas posibles
Hay demasiadas sesiones de proveedor de Terraform en ejecución en el entorno.
- Solución
Por el momento, esto funciona según lo previsto. Las sesiones se cierran de forma automática después de 300 segundos. Para obtener más información, consulta el problema n.º 618 de GitHub.
Usa un proxy para Docker:
oauth2: cannot fetch token
- Síntomas
Mientras uses un proxy, verás el siguiente error:
oauth2: cannot fetch token: Post https://oauth2.googleapis.com/token: proxyconnect tcp: tls: oversized record received with length 20527
- Causas posibles
Es posible que hayas proporcionado un proxy HTTPS en lugar de HTTP.
- Solución
En tu configuración de Docker, cambia la dirección del proxy por
http://
en lugar dehttps://
.
Verifica que las licencias sean válidas
Recuerda verificar que tus licencias sean válidas, en especial, si usas licencias de prueba. Es posible que encuentres fallas inesperadas si tus licencias de F5, host de ESXi o vCenter vencieron.
-