Descripción de la actualización
CCE ha aprobado el Certified Kubernetes Conformance Program y es una oferta certificada de Kubernetes. Para habilitar la interoperabilidad de una instalación de Kubernetes a la siguiente, debe actualizar sus clústeres de Kubernetes antes de que finalice el período de mantenimiento.
Después de que la última versión de Kubernetes esté disponible en CCE, CCE describirá los cambios en esta versión.
Puede utilizar la consola de CCE para actualizar la versión de Kubernetes de un clúster.
Se mostrará un indicador de actualización en la vista de tarjeta de clúster si hay una nueva versión para que el clúster actualice.
Cómo comprobarlo:
Actualización de clúster
En la siguiente tabla se describe la versión de destino a la que se puede actualizar cada versión de clúster, los modos de actualización admitidos y los efectos de la actualización.
|
Versión de origen |
Versión actualizada |
Modos de actualización |
Impactos |
|---|---|---|---|
|
v1.19 |
v1.21 |
Actualización local |
Necesita aprender acerca de las diferencias entre versiones. Para obtener más información, véase Precauciones para la actualización de la versión principal. |
|
v1.17 v1.15 |
v1.19 |
Actualización local |
Necesita aprender acerca de las diferencias entre versiones. Para obtener más información, véase Precauciones para la actualización de la versión principal. |
|
v1.13 |
v1.15 |
Actualización gradual Actualización de reemplazar |
|
|
v1.11 v1.9 |
La última versión que se puede crear en la consola |
Migración |
Necesita aprender acerca de las diferencias entre versiones. Para obtener más información, véase Precauciones para la actualización de la versión principal. |
|
v1.9.2 v1.7 |
La última versión que se puede crear en la consola |
Migración |
Necesita aprender acerca de las diferencias entre versiones. Para obtener más información, véase Precauciones para la actualización de la versión principal. |
Modos de actualización
Los procesos de actualización son los mismos para los nodos maestros. Las diferencias entre los modos de actualización de los nodos de trabajo se describen de la siguiente manera:
|
Modo de actualización |
Método |
Ventaja |
Desventaja |
|---|---|---|---|
|
Actualización local |
Los componentes de Kubernetes, componentes de red y componentes de gestión de CCE se actualizan en el nodo. Durante la actualización, los pods de servicio y las redes no se ven afectados. La etiqueta SchedulingDisabled se agregará a todos los nodos existentes. Una vez completada la actualización, puede utilizar correctamente los nodos existentes. |
No es necesario migrar servicios, lo que garantiza la continuidad del servicio. |
La actualización in situ no actualiza el sistema operativo de un nodo. Si desea actualizar el sistema operativo, borre los datos de nodo correspondientes una vez completada la actualización del nodo y restablezca el nodo para actualizar el sistema operativo a una nueva versión. |
|
Actualización gradual |
Solo los componentes de Kubernetes y ciertos componentes de red se actualizan en el nodo. La etiqueta SchedulingDisabled se agregará a todos los nodos existentes para garantizar que las aplicaciones en ejecución no se vean afectadas.
AVISO:
|
Los servicios no se interrumpen. |
|
|
Actualización de reemplazar |
La última imagen del nodo de trabajo se utiliza para restablecer el sistema operativo del nodo. |
Este es el modo de actualización más rápido y requiere pocas intervenciones manuales. |
Los datos o configuraciones en el nodo se perderán, y los servicios se interrumpirán durante un período de tiempo. |
Precauciones para la actualización de la versión principal
|
Ruta de actualización |
Precaución |
Autoverificación |
|---|---|---|
|
v1.19 a v1.21 |
El error de exec probe timeouts se corrige en Kubernetes 1.21. Antes de esta corrección de errores, la sonda exec no tiene en cuenta el campo timeoutSeconds. En su lugar, la sonda se ejecutará indefinidamente, incluso más allá de su fecha límite configurada. Se detendrá hasta que se devuelva el resultado. Si no se especifica este campo, se utiliza el valor predeterminado 1. Este campo entra en vigor después de la actualización. Si el sondeo se ejecuta durante 1 segundo, la comprobación de estado de la aplicación puede fallar y la aplicación puede reiniciarse con frecuencia. |
Antes de la actualización, compruebe si el tiempo de espera está configurado correctamente para la sonda exec. |
|
kube-apiserver de CCE 1.19 o posterior requiere que el campo Subject Alternative Names (SANs) esté configurado para el certificado de su servidor webhook. De lo contrario, kube-apiserver no puede invocar al servidor webhook después de la actualización, y contenedores no se puede iniciar correctamente. Causa raíz: X.509 CommonName se descarta en Go 1.15. kube-apiserver de CCE 1.19 se compila usando Go 1.15. Si su certificado webhook no tiene SAN, kube-apiserver no procesa el campo CommonName del certificado X.509 como nombre de host de forma predeterminada. Como resultado, la autenticación falla. |
Antes de la actualización, compruebe si el campo SAN está configurado en el certificado de su servidor webhook.
|
|
|
v1.15 a v1.19 |
El plano de control de en los clústeres v1.19 es incompatible con kubelet v1.15. Si un nodo no se puede actualizar o el nodo que se va a actualizar se reinicia después de que el nodo principal se actualice con éxito, hay una alta probabilidad de que el nodo esté en el estado NotReady. Esto se debe a que el nodo no puede actualizarse reinicia el kubelet y activa el registro del nodo. En los clústeres de v1.15, las etiquetas de registro predeterminadas failure-domain.beta.kubernetes.io/is-baremetal y kubernetes.io/availablezone son consideradas como etiquetas no válidas por los clústeres de v1.19. Las etiquetas válidas en los clústeres de v1.19 son node.kubernetes.io/baremetal y failure-domain.beta.kubernetes.io/zone. |
|
|
En los clústeres 1.15 y 1.19 de CCE, el sistema de archivos del controlador de almacenamiento de Docker cambia de XFS a Ext4. Como resultado, la secuencia de paquetes de importación en los pods de la aplicación Java actualizada puede ser anormal, causando excepciones de pod. |
Antes de la actualización, compruebe el archivo de configuración de Docker /etc/docker/daemon.json en el nodo. Compruebe si el valor de dm.fs es de xfs.
{
"storage-driver": "devicemapper",
"storage-opts": [
"dm.thinpooldev=/dev/mapper/vgpaas-thinpool",
"dm.use_deferred_removal=true",
"dm.fs=xfs",
"dm.use_deferred_deletion=true"
]
} |
|
|
kube-apiserver de CCE 1.19 o posterior requiere que el campo Subject Alternative Names (SANs) esté configurado para el certificado de su servidor webhook. De lo contrario, kube-apiserver no puede invocar al servidor webhook después de la actualización, y contenedores no se puede iniciar correctamente. Causa raíz: X.509 CommonName se descarta en Go 1.15. kube-apiserver de CCE 1.19 se compila usando Go 1.15. El campo CommonName se procesa como el nombre de host. Como resultado, la autenticación falla. |
Antes de la actualización, compruebe si el campo SAN está configurado en el certificado de su servidor webhook.
AVISO:
Para mitigar el impacto de las diferencias de versión en la actualización del clúster, CCE realiza un procesamiento especial durante la actualización de 1.15 a 1.19 y sigue soportando certificados sin SAN. Sin embargo, no se requiere ningún procesamiento especial para las actualizaciones posteriores. Le aconsejamos que rectifique su certificado lo antes posible. |
|
|
En clústeres de v1.17.17 y posteriores, CCE crea automáticamente políticas de seguridad de pods (PSP) para usted, que restringen la creación de pods con configuraciones inseguras, por ejemplo, pods para los que net.core.somaxconn bajo un sysctl está configurado en el contexto de seguridad. |
Después de una actualización, puede permitir configuraciones de sistema inseguras según sea necesario. Para obtener más información, véase Configuración de una política de seguridad de pod. |
|
|
v1.13 a v1.15 |
Después de actualizar un clúster de red de VPC, el nodo principal ocupa un bloque CIDR adicional debido a la actualización de los componentes de red. Si no hay ningún bloque CIDR contenedor disponible para el nuevo nodo, el pod programado para el nodo no puede ejecutarse. |
Generalmente, este problema se produce cuando los nodos en el clúster están a punto de ocupar completamente el bloque CIDR contenedor. Por ejemplo, el bloque CIDR contenedor es 10.0.0.0/16, el número de direcciones IP disponibles es de 65,536 y a la red VPC se le asigna un bloque CIDR con el tamaño fijo (utilizando la máscara para determinar el número máximo de direcciones IP contenedor asignadas a cada nodo). Si el límite superior es 128, el clúster admite un máximo de 512 (65536/128) nodos, incluidos los tres nodos principales. Después de actualizar el clúster, cada uno de los tres nodos principales ocupa un bloque CIDR. Como resultado, se soportan 506 nodos. |
