Este tema describe los problemas comunes y sus soluciones al crear, usar y gestionar clústeres.
Migración de clústeres autogestionados a ACK
ACK ofrece una solución de migración para trasladar sin problemas un clúster de Kubernetes autogestionado a un clúster ACK con un impacto mínimo en su negocio. Para obtener más información, consulte Overview of Kubernetes migration solutions.
Compatibilidad de imágenes de Alibaba Cloud Linux y CentOS
Sí, son compatibles. Para obtener más información, consulte Alibaba Cloud Linux 3.
Cambio del entorno de ejecución de contenedores tras la creación del clúster
No es posible cambiar el entorno de ejecución de contenedores una vez creado el clúster. Sin embargo, puede crear node pools que utilicen distintos entornos de ejecución. Para obtener más información, consulte Create and manage a node pool.
Para migrar el entorno de ejecución de contenedores de un nodo de Docker a containerd, consulte Migrate the container runtime of a node from Docker to containerd.
Docker no se admite como entorno de ejecución de contenedores integrado en clústeres que ejecutan Kubernetes 1.24 o versiones posteriores. Debe utilizar containerd como entorno de ejecución para los node pools en estos clústeres.
Comparación de entornos de ejecución de contenedores
Container Service for Kubernetes admite tres entornos de ejecución: containerd, Docker y Sandboxed-Container. Se recomienda utilizar el entorno de ejecución containerd. El entorno de ejecución Docker solo se admite en clústeres que ejecutan Kubernetes 1.22 o versiones anteriores. El entorno de ejecución Sandboxed-Container solo se admite en clústeres que ejecutan Kubernetes 1.24 o versiones anteriores. Para consultar una comparación de estos entornos, véase Comparison of containerd, Sandboxed-Container, and Docker runtimes. Al actualizar un clúster ACK a Kubernetes 1.24 o posterior, debe migrar el entorno de ejecución de contenedores de los nodos de Docker a containerd. Para obtener más información, consulte Migrate the container runtime of a node from Docker to containerd.
ACK y certificación MLPS 2.0 Nivel 3
Puede habilitar el endurecimiento basado en MLPS para su clúster y configurar políticas de verificación de línea base. Con Alibaba Cloud Linux, puede implementar MLPS 2.0 Nivel 3 y configurar verificaciones de línea base para el cumplimiento de MLPS a fin de satisfacer los siguientes requisitos:
Autenticación de identidad
Control de acceso
Auditoría de seguridad
Prevención de intrusiones
Prevención de código malicioso
Para obtener más información, consulte Enable MLPS-based hardening for ACK clusters.
Compatibilidad de ACK e Istio
Yes. You can use Alibaba Cloud Service Mesh(ASM). ASM is a service mesh product that is fully compatible with community Istio. Su plano de control totalmente gestionado le permite centrarse en el desarrollo y despliegue de sus aplicaciones empresariales . ASM es compatible con diversos sistemas operativos de nodos y plugins de red en clústeres ACK. You can add an un clúster ACK existente a una instancia de ASM y utilizar funciones such as traffic management, fault handling, unified monitoring, and log management. For more information, see Add a cluster to an ASM instance. Para obtener información sobre la facturación de ASM, consulte ASM billing.
Recopilación de información de diagnóstico
Si un clúster de Kubernetes presenta un problema o un nodo tiene un comportamiento anómalo, puede utilizar la función de diagnóstico con un solo clic proporcionada por ACK para identificar el problema. Para obtener más información, consulte Use cluster diagnostics.
Si la función de diagnóstico del clúster no satisface sus necesidades y requiere recopilar información de diagnóstico de los nodos maestros y de los nodos trabajadores anómalos, siga los pasos de las secciones siguientes para recopilar información de nodos Linux o Windows.
Nodo Linux
Los nodos trabajadores pueden ejecutar Linux o Windows, pero los nodos maestros solo pueden ejecutar Linux. El siguiente método se aplica tanto a nodos maestros como a nodos trabajadores que ejecutan Linux. Este ejemplo utiliza un nodo maestro.
-
Inicie sesión en un nodo maestro del clúster de Kubernetes y ejecute el siguiente comando para descargar el script de diagnóstico.
curl -o /usr/local/bin/diagnose_k8s.sh http://aliacs-k8s-cn-hangzhou.oss-cn-hangzhou.aliyuncs.com/public/diagnose/diagnose_k8s.shNotaEl script de diagnóstico para nodos Linux solo se puede descargar desde la región China (Hangzhou).
-
Ejecute el siguiente comando para otorgar permisos de ejecución al script de diagnóstico:
chmod u+x /usr/local/bin/diagnose_k8s.sh -
Ejecute el siguiente comando para cambiar al directorio especificado:
cd /usr/local/bin -
Ejecute el siguiente comando para ejecutar el script de diagnóstico:
diagnose_k8s.shLa salida es similar a la siguiente. El nombre del archivo de registro generado varía cada vez que ejecuta el script. Este ejemplo utiliza diagnose_1514939155.tar.gz.
...... + echo 'please get diagnose_1514939155.tar.gz for diagnostics' please get diagnose_1514939155.tar.gz for diagnostics + echo 'Please upload diagnose_1514939155.tar.gz' Please upload diagnose_1514939155.tar.gz -
Ejecute el siguiente comando para ver el archivo que contiene la información de diagnóstico del clúster:
ls -ltr | grep diagnose_1514939155.tar.gzNotaReemplace diagnose_1514939155.tar.gz por el nombre real del archivo de registro en su entorno.
Nodo Windows
Para recopilar información de diagnóstico del clúster desde un nodo trabajador Windows, descargue y ejecute el script de diagnóstico.
Windows solo se admite para nodos trabajadores.
Inicie sesión en el nodo trabajador anómalo y abra una herramienta de línea de comandos.
-
Ejecute el siguiente comando para entrar en modo PowerShell:
powershell -
Ejecute el siguiente comando para descargar y ejecutar el script de diagnóstico.
Puede descargar el script de diagnóstico para nodos Windows desde la región de su clúster. Reemplace
[$Region_ID]en el comando con el ID de la región de su clúster.Invoke-WebRequest -UseBasicParsing -Uri http://aliacs-k8s-[$Region_ID].oss-[$Region_ID].aliyuncs.com/public/pkg/windows/diagnose/diagnose.ps1 | Invoke-ExpressionLa siguiente salida indica que la información de diagnóstico se recopiló correctamente.
INFO: Compressing diagnosis clues ... INFO: ...done INFO: Please get diagnoses_1514939155.zip for diagnosticsNotaEl archivo diagnoses_1514939155.zip se guarda en el directorio donde se ejecuta el script.
Solución de problemas en clústeres ACK
Paso 1: Verificar los nodos del clúster
-
Ejecute el siguiente comando para ver el estado de los nodos del clúster. Compruebe que todos los nodos existen y se encuentran en estado Ready.
kubectl get nodesLa salida esperada es similar a la siguiente.
NAME STATUS ROLES AGE VERSION cn-hxxx.20 Ready master 86m v1.18.8-aliyun.1 cn-hxxx.21 Ready master 84m v1.18.8-aliyun.1 cn-hxxx.22 Ready master 81m v1.18.8-aliyun.1 cn-hxxx.23 Ready <none> 78m v1.18.8-aliyun.1 cn-hxxx.24 Ready <none> 78m v1.18.8-aliyun.1 cn-hxxx.25 Ready <none> 78m v1.18.8-aliyun.1 -
Ejecute el siguiente comando para ver información detallada y eventos de un nodo.
Reemplace
[$NODE_NAME]con el nombre de su nodo.kubectl describe node [$NODE_NAME]NotaPara obtener más información sobre la salida de kubectl, consulte Estado del nodo.
Paso 2: Verificar los componentes del clúster
Si no logra identificar el problema tras revisar los nodos del clúster, revise los registros de los componentes del clúster en el plano de control.
-
Ejecute el siguiente comando para ver todos los componentes en el namespace kube-system.
kubectl get pods -n kube-systemLa salida esperada es la siguiente.
NAME READY STATUS RESTARTS AGE alicloud-monitor-controller-6fbd5454f9-tvsls 1/1 Running 0 91m aliyun-acr-credential-helper-587bf4b6f8-bq2bg 1/1 Running 0 91m cloud-controller-manager-74q86 1/1 Running 0 91m cloud-controller-manager-sktzk 1/1 Running 0 91m cloud-controller-manager-tkvtz 1/1 Running 0 91m coredns-64d57b9c4b-222pj 1/1 Running 0 91m coredns-64d57b9c4b-fcr8t 1/1 Running 0 91m csi-plugin-5hnn8 4/4 Running 0 91m csi-plugin-6wxtm 4/4 Running 0 91m csi-plugin-jdvg4 4/4 Running 0 91m csi-plugin-njd28 4/4 Running 0 91m csi-plugin-tvf2h 4/4 Running 0 91m csi-plugin-zt76m 4/4 Running 0 91m csi-provisioner-84c4866d86-874wm 7/7 Running 0 91m csi-provisioner-84c4866d86-wvj86 7/7 Running 0 91m ingress-nginx-admission-create-9gnv8 0/1 Completed 0 91m ingress-nginx-admission-patch-wjskw 0/1 Completed 2 91m kube-apiserver-cn-huhehaote.1xxx 0 1/1 Running 0 95m kube-apiserver-cn-huhehaote.1xxx 1 1/1 Running 0 95m kube-apiserver-cn-huhehaote.1xxx 2 1/1 Running 0 95m kube-controller-manager-cn-huhehaote.1xxx 20 1/1 Running 1 100m kube-controller-manager-cn-huhehaote.1xxx 21 1/1 Running 1 97m kube-controller-manager-cn-huhehaote.1xxx 22 1/1 Running 1 91m kube-flannel-ds-b5zt4 1/1 Running 0 91m kube-flannel-ds-blj25 1/1 Running 0 91m kube-flannel-ds-d8v7j 1/1 Running 0 91m kube-flannel-ds-dq6nz 1/1 Running 0 91m kube-flannel-ds-vx97g 1/1 Running 0 91m kube-flannel-ds-wp8cj 1/1 Running 0 91m kube-proxy-master-8kl67 1/1 Running 0 91m kube-proxy-master-mnqmt 1/1 Running 0 91m kube-proxy-master-zfns9 1/1 Running 0 91m kube-proxy-worker-j2gr2 1/1 Running 0 91m kube-proxy-worker-n69x8 1/1 Running 0 91m kube-proxy-worker-qrft5 1/1 Running 0 100m kube-scheduler-cn-huhehaote.1xxx l20 1/1 Running 0 97m kube-scheduler-cn-huhehaote.1xxx l21 1/1 Running 0 97m kube-scheduler-cn-huhehaote.1xxx l22 1/1 Running 0 95m metrics-server-84f55db549-h9n4k 1/1 Running 0 91m nginx-ingress-controller-7474b6cc84-7pk7v 1/1 Running 0 91m nginx-ingress-controller-7474b6cc84-hg8l9 1/1 Running 0 91mLos pods cuyos nombres comienzan con
kube-son componentes del sistema del clúster de Kubernetes. Los pods cuyos nombres comienzan con coredns- son complementos de DNScoredns-son plugins de DNS. Esta salida indica que los componentes se encuentran en estado normal. Si algún componente presenta un estado anómalo, continúe con el siguiente paso. -
Ejecute el siguiente comando para ver los registros del componente anómalo e identificar y resolver el problema.
Reemplace
[$Component_Name]con el nombre del componente anómalo.kubectl logs -f [$Component_Name] -n kube-system
Paso 3: Verificar el componente kubelet
-
Ejecute el siguiente comando para comprobar el estado de kubelet.
systemctl status kubelet -
Si el estado de kubelet no es
active (running), ejecute el siguiente comando para ver los registros de kubelet e identificar y resolver el problema.journalctl -u kubelet
Problemas comunes del clúster
La siguiente tabla enumera algunas causas comunes de fallos en clústeres ACK y sus soluciones.
Problema | Solución |
El componente API Server o un componente maestro se detiene:
| Los componentes de ACK tienen alta disponibilidad integrada. Se recomienda comprobar si el propio componente presenta anomalías. Por ejemplo, el API Server de un clúster ACK utiliza una instancia CLB de forma predeterminada. Puede solucionar el estado anómalo de la instancia CLB. |
Se pierden los datos de backend del API Server:
| Si creó una instantánea, puede restaurar los datos desde ella cuando ocurra un problema. Si no creó una instantánea, submit a ticket. Una vez resuelto el problema, tome las siguientes medidas para evitar que vuelva a ocurrir:
|
Un nodo individual se apaga y todos los pods de ese nodo dejan de ejecutarse. | Utilice una carga de trabajo como Deployment, StatefulSet o DaemonSet para crear pods en lugar de crearlos directamente. Esto garantiza que los pods de reemplazo se programen en nodos sanos si un nodo falla. |
El componente kubelet falla:
|
|
Los problemas son causados por configuraciones manuales u otras razones. | Si creó una instantánea, puede utilizarla para restaurar datos cuando ocurra un problema. Si no ha creado una instantánea, submit a ticket para reportar el problema. Una vez resuelto, cree periódicamente instantáneas del volumen de datos utilizado por kubelet. Para obtener más información, consulte Create a snapshot for a single disk volume. |
Configurar autorización detallada
De forma predeterminada, un usuario RAM o un rol RAM no tiene permisos para invocar la OpenAPI de ningún servicio en la nube. Para usar y gestionar clústeres de ACK, debe otorgar la política del sistema AliyunCSFullAccess o una política personalizada de Container Service for Kubernetes al usuario RAM o al rol RAM. Para obtener más información, consulte Grant access permissions to clusters and cloud resources by using RAM.
-
Según el mecanismo RBAC de Kubernetes, debe use RBAC to authorize a RAM user para gestionar los recursos internos del clúster, como la creación de Deployments y Services.
En escenarios que requieren un control detallado sobre los permisos de lectura y escritura en los recursos, consulte Use custom RBAC policies to restrict operations on resources in a cluster para configurar permisos RBAC más específicos mediante un ClusterRole y un Role personalizados.
Cuando un usuario RAM accede a la consola, también debe configurar los permisos correspondientes del servicio en la nube para utilizar funciones como la visualización de actividades de escalado del node pool y los paneles de monitoreo del clúster. Para obtener más información, consulte Permissions required for the Container Service for Kubernetes console.
¿Qué rangos de direcciones IP se deben permitir en la política de control de acceso del SLB del API Server del clúster?
Las reglas de la lista de control de acceso (ACL) para la instancia de SLB del API Server deben permitir los siguientes bloques CIDR.
El bloque CIDR 100.104.0.0/16, reservado para el plano de control de Container Service for Kubernetes.
Los bloques CIDR principales y adicionales de la Virtual Private Cloud (VPC) del clúster, o los bloques CIDR de los vSwitches donde residen los nodos del clúster.
Los bloques CIDR de salida de los clientes que necesitan acceder al servidor API.
Para los clústeres ACK Edge, también debe agregar los bloques CIDR de salida de los nodos perimetrales.
Para los clústeres ACK Lingjun, también debe agregar los bloques CIDR del Virtual Private Datacenter (VPD) de Lingjun.
Para obtener más información, consulte Configure the access control policy for the API Server.
Acceder a un nodo maestro
Clúster dedicado: Para obtener más información, consulte Connect to the master node of a dedicated ACK cluster by using SSH.
Clúster gestionado: Los nodos del plano de control de un clúster gestionado de ACK están totalmente gestionados. No puede iniciar sesión en las terminales de los nodos del plano de control. Si necesita iniciar sesión en los nodos del plano de control, considere usar un clúster dedicado.
Si se elimina accidentalmente un nodo maestro de un clúster dedicado de ACK, ¿se puede actualizar el clúster?
No. Después de eliminar un nodo maestro de un clúster dedicado, no puede agregar nodos maestros ni actualizar el clúster. Puede create a dedicated ACK cluster (discontinued).
Clúster dedicado de ACK: ¿Se pueden eliminar o agregar nodos maestros y cuáles son las operaciones de alto riesgo?
No. Agregar o eliminar nodos maestros de un clúster dedicado puede provocar que el clúster quede inutilizable e irrecuperable.
En los nodos maestros de un clúster dedicado, las operaciones inadecuadas pueden dejar inservibles a los nodos maestros o incluso a todo el clúster. Las operaciones de alto riesgo incluyen reemplazar certificados maestros o de etcd, modificar componentes principales, eliminar o formatear datos en directorios críticos como /etc/kubernetes en un nodo y reinstalar el sistema operativo. Para obtener más información, consulte High-risk operations related to clusters.
Error del API Server de un clúster dedicado de ACK:**api/v1/namespaces/xxx/resourcequotes": x509: certificate has expired or is not yet valid: current time XXX is after xxx. ¿Qué debo hacer?
Síntomas
Al crear un pod en un clúster dedicado, el API Server devuelve un error de caducidad de certificado, o bien los registros o eventos del kube-controller-manager muestran un error de caducidad de certificado. El mensaje de error es el siguiente.
"https://localhost:6443/api/v1/namespaces/xxx/resourcequotes": x509: certificate has expired or is not yet valid: current time XXX is after XXX"https://[::1]:6443/api/v1/namespaces/xxx/resourcequotes": x509: certificate has expired or is not yet valid: current time XXX is after XXXCausa
En Kubernetes, el API Server cuenta con un certificado integrado para su LoopbackClient interno. En la versión comunitaria, este certificado tiene un periodo de validez de 1 año y no se puede rotar automáticamente. Solo se rota y actualiza cuando se reinicia el pod del API Server. Si el clúster no se ha actualizado durante más de un año, el certificado interno caduca y provoca fallos en las solicitudes a la API. Para obtener más información, consulte #86552.
Para reducir los riesgos de estabilidad causados por el corto periodo de validez de los certificados en la versión comunitaria, ACK amplía el periodo de validez predeterminado de este certificado integrado a 10 años para los clústeres que ejecutan Kubernetes 1.24 o versiones posteriores. Para obtener más información sobre los cambios y su alcance de impacto, consulte Product Change: Validity Period of ACK Cluster API Server Internal Certificates.
Solución
Puede iniciar sesión en un nodo maestro y ejecutar el siguiente comando para consultar la fecha de caducidad del certificado LoopbackClient.
En el comando, XX.XX.XX.XX es la dirección IP local del nodo maestro.
curl --resolve apiserver-loopback-client:6443:XX.XX.XX.XX -k -v https://apiserver-loopback-client:6443/healthz 2>&1 |grep expirePara clústeres con certificados de 1 año que han caducado o están a punto de hacerlo, consulte Manually upgrade an ACK cluster para actualizar el clúster a la versión 1.24 o posterior. Se recomienda migrar a una instancia de ACK Managed Cluster Pro (Hot migrate a dedicated ACK cluster to an ACK Managed Cluster Pro instance).
-
Para un clúster dedicado que no se pueda actualizar a corto plazo, inicie sesión en cada nodo maestro y reinicie manualmente el API Server para generar un nuevo certificado válido.
-
Nodo containerd
crictl pods | grep kube-apiserver- | awk '{print $1}' | xargs -I '{}' crictl stopp {} -
Nodo Docker
docker ps | grep kube-apiserver- | awk '{print $1}' | xargs -I '{}' docker restart {}
-