Riesgo de compatibilidad

v1.19 a v1.21 o v1.23

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.

• Si no tiene su propio servidor webhook, puede omitir esta comprobación.
• Si el campo no está definido, se recomienda utilizar el campo SAN para especificar la dirección IP y el nombre de dominio admitidos por el certificado.

Los nodos de Arm no se admiten en los clústeres de v1.21 y posteriores.

Compruebe si sus servicios se verán afectados si no se pueden utilizar los nodos de Arm.

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.

1. En los casos normales, este escenario no se activa.
2. Después de actualizar el nodo principal, no suspenda la actualización para que el nodo pueda actualizarse rápidamente.
3. Si un nodo no se puede actualizar y no se puede restaurar, desaloje las aplicaciones en el nodo tan pronto como sea posible. Póngase en contacto con el soporte técnico y omita la actualización del nodo. Una vez completada la actualización, restablezca el nodo.

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.

• Si el valor es de ext4 o el controlador de almacenamiento es Overlay, puede omitir los siguientes pasos.
• Si el valor es de xfs, se recomienda desplegar aplicaciones en el clúster de la nueva versión con antelación para probar si las aplicaciones son compatibles con la nueva versión del clúster.

{
      "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.

• Si no tiene su propio servidor webhook, puede omitir esta comprobación.
• Si el campo no está definido, se recomienda utilizar el campo SAN para especificar la dirección IP y el nombre de dominio admitidos por el certificado.

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.