Versiones de Kubernetes compatibles en el servicio de Kubernetes de Azure Operator Nexus
En este documento se proporciona información general sobre el esquema de control de versiones usado para el servicio de Kubernetes de Operator Nexus, incluidas las versiones de Kubernetes compatibles. Explica las diferencias entre las versiones principales, secundarias y de revisión, y proporciona instrucciones sobre cómo actualizar las versiones de Kubernetes y cómo es la experiencia de actualización. En el documento también se tratan el ciclo de vida de soporte técnico de la versión y el fin de la vida útil (EOL) para cada versión secundaria de Kubernetes.
La Comunidad de Kubernetes libera versiones secundarias aproximadamente cada tres meses. A partir de la versión 1.19, la comunidad de Kubernetes ha aumentado el período de soporte técnico de todas las versiones de nueve meses a un año.
Las versiones secundarias incluyen nuevas características y mejoras. Las versiones de revisión son más frecuentes (a veces semanales) y están previstas para correcciones de errores críticos en una versión secundaria. Las versiones de revisión incluyen correcciones para vulnerabilidades de seguridad o errores importantes.
Versiones de Kubernetes
Kubernetes usa el esquema de versiones estándar de SemVer en todas las versiones:
[major].[minor].[patch]
Examples:
1.24.7
1.25.4
Cada número en la versión indica compatibilidad general con la versión anterior:
- Los números de versión principal cambian cuando es posible la introducción de cambios importantes en la API
- Los números de versión secundaria cambian cuando se realizan actualizaciones de la funcionalidad que son compatibles con otras versiones anteriores secundarias.
- Los números de versión de revisión cambian cuando se hacen correcciones de errores compatibles con versiones anteriores.
Se recomienda encarecidamente mantenerse al día con las revisiones disponibles más recientes. Por ejemplo, si el clúster de producción está en 1.25.4 y 1.25.6 es la versión de revisión más reciente disponible para la serie 1.25. Debe realizar la actualización a 1.25.6 lo antes posible para asegurarse de que el clúster tiene todas las revisiones y es compatible. Encontrará más información sobre cómo actualizar el clúster en la documentación sobre cómo actualizar las versiones de Kubernetes.
Calendario de publicación de Kubernetes de Nexus
Vea las próximas versiones en el calendario de versiones de Kubernetes de Nexus.
Nota:
Lea más información sobre nuestra directiva de soporte técnico para el control de versiones de Kubernetes.
Para ver el historial de versiones anteriores, consulte Historial de Kubernetes.
| Versión de K8s | Nexus GA | Final de la vida útil | Disponibilidad ampliada |
|---|---|---|---|
| 1,25 | Jun. de 2023 | Dic. de 2023 | Hasta la versión 1.31 de disponibilidad general |
| 1,26 | Set. de 2023 | Marzo de 2024 | Hasta la versión 1.32 de disponibilidad general |
| 1.27* | Set. de 2023 | Julio de 2024, LTS hasta julio de 2025 | Hasta la versión 1.33 de disponibilidad general |
| 1.28 | Nov. de 2023 | Octubre de 2024 | Hasta la versión 1.34 de disponibilidad general |
* Indica que la versión se designa para soporte técnico a largo plazo
Componentes de la versión del servicio de Kubernetes de Nexus
Una versión del servicio de Kubernetes de Operator Nexus está formada por dos componentes discretos que se han combinado en una única representación:
- La versión de Kubernetes. Por ejemplo, 1.25.4, es la versión de Kubernetes que se implementa en Operator Nexus. Azure AKS proporciona estos paquetes, incluidas todas las versiones de revisión que admite Operator Nexus. Para más información sobre las versiones de Azure AKS, consulte Versiones de Kubernetes compatibles en Azure Kubernetes Service (AKS).
- La agrupación de versiones, que encapsula las características (complementos) y la imagen del sistema operativo que usan los nodos en el clúster de Kubernetes de Operator Nexus, como un único número. Por ejemplo, 2.
La combinación de estos valores se representa en la API como la única kubernetesVersion. Por ejemplo,
1.25.4-2o la notación “v” admitida alternativamente:v1.25.4-2.
Agrupaciones de versiones
Al extender la versión de Kubernetes para incluir un valor secundario para la versión de revisión, la agrupación de versiones, el servicio de Kubernetes de Operator Nexus puede tener en cuenta los casos en los que se modifica la implementación para incluir actualizaciones adicionales relacionadas con el sistema operativo. Estas actualizaciones podrían incluir, entre otras: imágenes actualizadas del sistema operativo, versiones de revisión para características (complementos), etc. Las agrupaciones de versiones siempre son compatibles con agrupaciones de versiones anteriores dentro de la misma versión de revisión, por ejemplo, 1.25.4-2 es compatible con 1.25.4-1.
Los cambios en la configuración de un clúster de Kubernetes de Operator Nexus implementado solo se deben aplicar dentro de una actualización de la versión secundaria de Kubernetes, no durante una actualización de la versión de revisión. Entre los ejemplos de cambios de configuración que se podrían aplicar durante la actualización de la versión secundaria se incluyen:
- Cambio de la configuración del kube-proxy, pasando del uso de iptables a ipvs
- Cambio de la CNI de un producto a otro
Cuando seguimos estos principios, resulta más fácil predecir y administrar el proceso de movimiento entre las diferentes versiones de clústeres de Kubernetes que ofrece el servicio de Kubernetes de Operator Nexus.
Podemos actualizar fácilmente desde cualquier actualización pequeña en una versión de Kubernetes a cualquier actualización pequeña en la versión siguiente, lo que le proporciona flexibilidad. Por ejemplo, se permitiría una actualización de 1.24.1-x a 1.25.4-x, independientemente de la presencia de una versión 1.24.2-x intermedia.
Cambios importantes y versión de los componentes
Tenga en cuenta los siguientes cambios importantes que se deberán realizar antes de actualizar a cualquiera de las versiones secundarias disponibles:
| Versión de Kubernetes | Agrupación de versiones | Componentes | Componentes del sistema operativo | Últimos cambios | Notas |
|---|---|---|---|---|---|
| 1.25.6 | 1 | Calico v3.24.0 metrics-server v0.6.3 Multus v3.8.0 CoreDNS v1.9.3 etcd v3.5.6-5 sriov-dp v3.5.1 |
Azure Linux 2.0 | No hay cambios importantes. | |
| 1.25.6 | 2 | Calico v3.26.1 metrics-server v0.6.3 Multus v3.8.0 CoreDNS v1.9.3 etcd v3.5.6-5 sriov-dp v3.7.0-48 |
Azure Linux 2.0 | No hay cambios importantes. | |
| 1.25.6 | 3 | Calico v3.26.1 metrics-server v0.6.3 Multus v3.8.0 CoreDNS v1.9.3 etcd v3.5.6-5 sriov-dp v3.7.0-48 |
Azure Linux 2.0 | No hay cambios importantes. | |
| 1.25.6 | 4 | Calico v3.26.1 metrics-server v0.6.3 Multus v3.8.0 azure-arc-servers v1.0.0 CoreDNS v1.9.3 etcd v3.5.6-5 sriov-dp v3.7.0-48 |
Azure Linux 2.0 | No hay cambios importantes. | Los nodos de clúster están habilitados para Azure Arc |
| 1.25.6 | 5 | Calico v3.26.1 metrics-server v0.6.3 Multus v3.8.0 azure-arc-servers v1.0.0 CoreDNS v1.9.3 etcd v3.5.6-5 sriov-dp v3.7.0-48 Csi-nfs v4.6.0 |
Azure Linux 2.0 | No hay cambios importantes. | |
| 1.25.11 | 1 | Calico v3.26.1 metrics-server v0.6.3 Multus v3.8.0 CoreDNS v1.9.3 etcd v3.5.6-5 sriov-dp v3.7.0-48 |
Azure Linux 2.0 | No hay cambios importantes. | |
| 1.25.11 | 2 | Calico v3.26.1 metrics-server v0.6.3 Multus v3.8.0 azure-arc-servers v1.0.0 CoreDNS v1.9.3 etcd v3.5.6-5 sriov-dp v3.7.0-48 |
Azure Linux 2.0 | No hay cambios importantes. | Los nodos de clúster están habilitados para Azure Arc |
| 1.25.11 | 3 | Calico v3.26.1 metrics-server v0.6.3 Multus v3.8.0 azure-arc-servers v1.0.0 CoreDNS v1.9.3 etcd v3.5.6-5 sriov-dp v3.7.0-48 Csi-nfs v4.6.0 |
Azure Linux 2.0 | No hay cambios importantes. | |
| 1.26.3 | 1 | Calico v3.24.0 metrics-server v0.6.3 Multus v3.8.0 CoreDNS v1.9.3 etcd v3.5.6-5 sriov-dp v3.5.1 |
Azure Linux 2.0 | No hay cambios importantes. | |
| 1.26.3 | 2 | Calico v3.26.1 metrics-server v0.6.3 Multus v3.8.0 CoreDNS v1.9.3 etcd v3.5.6-5 sriov-dp v3.7.0-48 |
Azure Linux 2.0 | No hay cambios importantes. | |
| 1.26.3 | 3 | Calico v3.26.1 metrics-server v0.6.3 Multus v3.8.0 CoreDNS v1.9.3 etcd v3.5.6-5 sriov-dp v3.7.0-48 |
Azure Linux 2.0 | No hay cambios importantes. | |
| 1.26.3 | 4 | Calico v3.26.1 metrics-server v0.6.3 Multus v3.8.0 azure-arc-servers v1.0.0 CoreDNS v1.9.3 etcd v3.5.6-5 sriov-dp v3.7.0-48 |
Azure Linux 2.0 | No hay cambios importantes. | Los nodos de clúster están habilitados para Azure Arc |
| 1.26.3 | 5 | Calico v3.26.1 metrics-server v0.6.3 Multus v3.8.0 azure-arc-servers v1.0.0 CoreDNS v1.9.3 etcd v3.5.6-5 sriov-dp v3.7.0-48 Csi-nfs v4.6.0 |
Azure Linux 2.0 | No hay cambios importantes. | |
| 1.26.6 | 1 | Calico v3.26.1 metrics-server v0.6.3 Multus v3.8.0 CoreDNS v1.9.3 etcd v3.5.6-5 sriov-dp v3.7.0-48 |
Azure Linux 2.0 | No hay cambios importantes. | |
| 1.26.6 | 2 | Calico v3.26.1 metrics-server v0.6.3 Multus v3.8.0 azure-arc-servers v1.0.0 CoreDNS v1.9.3 etcd v3.5.6-5 sriov-dp v3.7.0-48 |
Azure Linux 2.0 | No hay cambios importantes. | Los nodos de clúster están habilitados para Azure Arc |
| 1.26.6 | 3 | Calico v3.26.1 metrics-server v0.6.3 Multus v3.8.0 azure-arc-servers v1.0.0 CoreDNS v1.9.3 etcd v3.5.6-5 sriov-dp v3.7.0-48 Csi-nfs v4.6.0 |
Azure Linux 2.0 | No hay cambios importantes. | |
| 1.27.1 | 1 | Calico v3.24.0 metrics-server v0.6.3 Multus v3.8.0 CoreDNS v1.9.3 etcd v3.5.6-5 sriov-dp v3.5.1 |
Azure Linux 2.0 | Cgroupv2 | Aquí encontrará los pasos para deshabilitar cgroupv2 |
| 1.27.1 | 2 | Calico v3.26.1 metrics-server v0.6.3 Multus v3.8.0 CoreDNS v1.9.3 etcd v3.5.6-5 sriov-dp v3.7.0-48 |
Azure Linux 2.0 | Cgroupv2 | Aquí encontrará los pasos para deshabilitar cgroupv2 |
| 1.27.1 | 3 | Calico v3.26.1 metrics-server v0.6.3 Multus v3.8.0 CoreDNS v1.9.3 etcd v3.5.6-5 sriov-dp v3.7.0-48 |
Azure Linux 2.0 | Cgroupv2 | Aquí encontrará los pasos para deshabilitar cgroupv2 |
| 1.27.1 | 4 | Calico v3.26.1 metrics-server v0.6.3 Multus v3.8.0 azure-arc-servers v1.0.0 CoreDNS v1.9.3 etcd v3.5.6-5 sriov-dp v3.7.0-48 |
Azure Linux 2.0 | No hay cambios importantes. | Los nodos de clúster están habilitados para Azure Arc |
| 1.27.1 | 5 | Calico v3.26.1 metrics-server v0.6.3 Multus v3.8.0 azure-arc-servers v1.0.0 CoreDNS v1.9.3 etcd v3.5.6-5 sriov-dp v3.7.0-48 Csi-nfs v4.6.0 |
Azure Linux 2.0 | No hay cambios importantes. | |
| 1.27.3 | 1 | Calico v3.26.1 metrics-server v0.6.3 Multus v3.8.0 CoreDNS v1.9.3 etcd v3.5.6-5 sriov-dp v3.7.0-48 |
Azure Linux 2.0 | Cgroupv2 | Aquí encontrará los pasos para deshabilitar cgroupv2 |
| 1.27.3 | 2 | Calico v3.26.1 metrics-server v0.6.3 Multus v3.8.0 azure-arc-servers v1.0.0 CoreDNS v1.9.3 etcd v3.5.6-5 sriov-dp v3.7.0-48 |
Azure Linux 2.0 | No hay cambios importantes. | Los nodos de clúster están habilitados para Azure Arc |
| 1.27.3 | 3 | Calico v3.26.1 metrics-server v0.6.3 Multus v3.8.0 azure-arc-servers v1.0.0 CoreDNS v1.9.3 etcd v3.5.6-5 sriov-dp v3.7.0-48 Csi-nfs v4.6.0 |
Azure Linux 2.0 | No hay cambios importantes. | |
| 1.28.0 | 1 | Calico v3.26.1 metrics-server v0.6.3 Multus v3.8.0 CoreDNS v1.9.3 etcd v3.5.6-5 sriov-dp v3.7.0-48 |
Azure Linux 2.0 | No hay cambios importantes. | |
| 1.28.0 | 2 | Calico v3.26.1 metrics-server v0.6.3 Multus v3.8.0 azure-arc-servers v1.0.0 CoreDNS v1.9.3 etcd v3.5.6-5 sriov-dp v3.7.0-48 |
Azure Linux 2.0 | No hay cambios importantes. | Los nodos de clúster están habilitados para Azure Arc |
| 1.28.0 | 3 | Calico v3.26.1 metrics-server v0.6.3 Multus v3.8.0 azure-arc-servers v1.0.0 CoreDNS v1.9.3 etcd v3.5.6-5 sriov-dp v3.7.0-48 Csi-nfs v4.6.0 |
Azure Linux 2.0 | No hay cambios importantes. |
Actualización de las versiones de Kubernetes
Para obtener más información sobre cómo actualizar el clúster, consulte el artículo sobre cómo actualizar un clúster del servicio de Kubernetes de Azure Operator Nexus.
Directiva de soporte técnico de versión de Kubernetes
Operator Nexus es compatible con tres versiones secundarias de Kubernetes:
- La versión secundaria más reciente en disponibilidad general publicada en Operator Nexus (a la que nos referiremos como N).
- Dos versiones secundarias anteriores.
- Cada versión secundaria compatible también admite un máximo de dos revisiones estables más recientes, mientras que las revisiones anteriores están sujetas a la directiva de disponibilidad ampliada durante la vigencia de la versión secundaria.
El servicio de Kubernetes de Operator Nexus proporciona una duración estandarizada de compatibilidad con cada versión secundaria de Kubernetes que se publica. Las versiones se adhieren a dos escalas de tiempo diferentes, lo que refleja lo siguiente:
- Duración del soporte técnico: cuánto tiempo se mantiene una versión de manera activa. Al terminarse el período de prestación de soporte, la versión alcanza el “fin de su vida útil”.
- Disponibilidad ampliada: cuánto tiempo puede seleccionarse una versión para su implementación tras alcanzar el “fin de su vida útil”.
La ventana admitida de versiones de Kubernetes en Operator Nexus se conoce como "N-2": (N (última versión) - 2 (versiones secundarias)), y ".letra" es representativo de las versiones de revisión.
Por ejemplo, si Operator Nexus presenta 1.17.a hoy, también se proporciona compatibilidad para las versiones siguientes:
| Nueva versión secundaria | Lista de versiones admitidas |
|---|---|
| 1.17.a | 1.17.a, 1.17.b, 1.16.c, 1.16.d, 1.15.e, 1.15.f |
Cuando se introduce una nueva versión secundaria, la versión secundaria compatible más antigua y las versiones de revisión dejan de ser compatibles. Por ejemplo, la lista de versiones que se admiten actualmente es:
1.17.a
1.17.b
1.16.c
1.16.d
1.15.e
1.15.f
Cuando Operator Nexus publica la versión 1.18.*, todas las versiones 1.15.* salen de soporte técnico.
Escala de tiempo del soporte técnico
El servicio de Kubernetes de Operator Nexus proporciona compatibilidad durante 12 meses a partir de la versión inicial de AKS de disponibilidad general de una versión secundaria normalmente. Esta escala de tiempo sigue el plazo de Azure AKS, que incluye una versión de soporte técnico a largo plazo declarada, 1.27.
Versiones compatibles:
- Se pueden implementar como nuevos clústeres de Kubernetes de Operator Nexus.
- Pueden ser el destino de las actualizaciones desde versiones anteriores. Están limitadas por rutas de actualización normales.
- Pueden tener agrupaciones de versiones o revisiones adicionales dentro de la versión secundaria.
Nota:
En circunstancias excepcionales, el soporte técnico del servicio de Kubernetes de Nexus podría llegar a su fin en breve o de forma inmediata si se identifica una vulnerabilidad o un problema de seguridad. Microsoft notificará de forma proactiva a los clientes si esto fuera a suceder y trabajará para mitigar cualquier posible problema.
Final del ciclo de vida (EOL)
Fin de la vida útil (EOL) significa que no se generan más agrupaciones de versiones ni revisiones. Es posible que el clúster que ha configurado ya no se pueda actualizar porque las versiones compatibles más recientes ya no estén disponibles. En este evento, la única manera de actualizar es volver a crear por completo el clúster de Kubernetes de Nexus mediante la versión compatible más reciente. Es posible que las actualizaciones no admitidas a través de Extended availability se usen para volver a una versión compatible.
Directiva de disponibilidad ampliada
Durante el período de disponibilidad ampliado para versiones de Kubernetes no admitidas (es decir, versiones de Kubernetes de EOL), los usuarios no reciben actualizaciones de seguridad ni correcciones de errores. Para obtener información detallada sobre las categorías de soporte técnico, consulte la tabla siguiente.
| Categoría de soporte técnico | N-2 a N | Disponibilidad ampliada |
|---|---|---|
| Actualizaciones de N-3 a una versión compatible | Compatible | Compatible |
| Escalado de grupos de nodos | Compatible | Compatible |
| Creación de clústeres o grupos de nodos | Compatible | Compatible |
| Componentes de Kubernetes (incluidos complementos) | Compatible | No compatible |
| Actualizaciones de componentes | Compatible | No compatible |
| Revisiones de componentes | Compatible | No compatible |
| Aplicación de correcciones de errores de Kubernetes | Compatible | No compatible |
| Aplicación de actualizaciones de seguridad de Kubernetes | Compatible | No compatible |
| Actualizaciones de seguridad de las imágenes de nodo | Compatible | No compatible |
Nota:
Operator Nexus se basa en las versiones y revisiones de kubernetes, que es un proyecto de código abierto que solo admite una ventana deslizante de tres versiones secundarias. Operator Nexus solo puede garantizar compatibilidad total mientras esas versiones tienen servicio ascendente. Puesto que no se producen más revisiones ascendentes, Operator Nexus puede dejar esas versiones sin revisión o bifurcación. Debido a esta limitación, la disponibilidad ampliada no admitirá nada que dependa directamente de kubernetes ascendente.
Versiones de kubectl admitidas
Puede usar una versión secundaria de kubectl que sea inmediatamente anterior o posterior a la versión de kubectl y que sea coherente con la directiva de compatibilidad de Kubernetes para kubectl.
Por ejemplo, si la versión de kube-apiserver es 1.17, puede usar las versiones de kubectl comprendidas entre 1.16 y 1.18 con esa versión de kube-apiserver.
Para instalar o actualizar kubectl a la versión más reciente, ejecute:
az aks install-cli
Soporte técnico a largo plazo (LTS)
Azure Kubernetes Service (AKS) proporciona una versión de soporte técnico a largo plazo (LTS) de Kubernetes durante un período de dos años. Solo hay una versión menor de Kubernetes considerada LTS en un momento dado.
| Soporte técnico de la comunidad | Compatibilidad a largo plazo | |
|---|---|---|
| Cuándo se deben usar | Cuando pueda mantenerse al día con las versiones ascendentes de Kubernetes | Escenarios en los que las aplicaciones no son compatibles con los cambios implementados en versiones de Kubernetes más recientes, y no se puede realizar la transición a un ciclo de versión continua debido a restricciones técnicas u otros factores |
| Compatibilidad con versiones | Tres versiones secundarias de disponibilidad general | Una versión de Kubernetes (actualmente 1.27) durante dos años |
La comunidad ascendente mantiene una versión secundaria de Kubernetes durante un año a partir de la versión. Después de este período, Microsoft crea y aplica actualizaciones de seguridad a la versión LTS de Kubernetes para proporcionar un total de dos años de soporte en AKS.
Importante
La versión 1.27 de Kubernetes es la primera versión LTS compatible de Kubernetes en el servicio de Kubernetes de Operator Nexus.
Preguntas más frecuentes
¿Cómo me notifica Microsoft las nuevas versiones de Kubernetes?
Este documento se actualiza periódicamente con las fechas programadas de las nuevas versiones de Kubernetes.
¿Con qué frecuencia debo planear actualizar las versiones de Kubernetes para mantenerme con soporte técnico?
A partir de Kubernetes 1.19, la comunidad de código abierto ha ampliado el soporte técnico a 1 año. Operator Nexus se compromete a habilitar unas revisiones y un soporte técnico que cumplan los compromisos ascendentes. Para clústeres de Operator Nexus en 1.19 y superiores, puede actualizar como mínimo una vez al año para permanecer en una versión compatible.
¿Qué ocurre cuando se actualiza un clúster Kubernetes con una versión menor no admitida?
Si está en la versión N-3 o anterior, está fuera del período de soporte técnico. Cuando actualice de la versión N-3 a N-2, estará dentro de nuestro período de soporte técnico. Por ejemplo:
- Si la versión de AKS admitida más antigua es la 1.25.x y la suya es la 1.24.x o anterior, no tiene soporte.
- Actualizar correctamente de 1.24.x a 1.25.x o versiones posteriores hará que vuelva a estar dentro de nuestro período de soporte técnico.
- No se admiten las "actualizaciones de nivel omitido". Para actualizar de 1.23.x a 1.25.x, primero debe actualizar a 1.24.x y, a continuación, a 1.25.x.
No se admiten cambios a una versión anterior.
¿Qué sucede si no actualizo mi clúster?
Si no actualiza el clúster, seguirá recibiendo soporte técnico para la versión de Kubernetes que ejecute hasta que termine el período de soporte técnico. Después, dejará de recibir soporte técnico para el clúster. Debe actualizar el clúster a una versión compatible para seguir recibiendo soporte técnico.
¿Qué ocurre si no actualizo el clúster antes de que termine el período de disponibilidad ampliado?
Si no actualiza el clúster antes de que termine el período de disponibilidad ampliado, ya no podrá actualizarlo a una versión compatible ni escalar horizontalmente grupos de agentes. Debe volver a crear el clúster con una versión compatible para seguir recibiendo soporte técnico.
¿Qué significa "fuera de soporte técnico"?
"Fuera del soporte técnico" significa lo siguiente:
- La versión que utiliza está fuera de la lista de versiones admitidas.
- Se le pedirá que actualice el clúster a una versión compatible al solicitar soporte técnico.
Además, Operator Nexus no ofrece ningún entorno de ejecución ni otras garantías para los clústeres que estén fuera de la lista de versiones admitidas.
¿Qué ocurre cuando un cliente escala un clúster de Kubernetes con una versión secundaria que no es compatible?
Tanto la reducción como el escalado horizontales deberían seguir funcionando en las versiones secundarias que no son compatibles con Operator Nexus. Dado que no hay garantías con la calidad de servicio, se recomienda realizar la actualización para que el clúster vuelva tener soporte técnico.
¿Puedo saltarme varias versiones de Kubernetes durante la actualización del clúster?
Cuando se actualiza un clúster de Kubernetes de Operator Nexus compatible, no se pueden omitir las versiones secundarias de Kubernetes. La directiva de sesgo de versiones de los planos de control de Kubernetes no admite la omisión de versiones secundarias. Por ejemplo, las actualizaciones entre las siguientes versiones:
- 1.12.x ->1.13.x: permitida.
- 1.13.x ->1.14.x: permitida.
- 1.12.x ->1.14.x: no permitida.
Para actualizar de 1.12.x ->1.14.x:
- Actualice desde 1.12.x ->1.13.x.
- Actualice desde 1.13.x ->1.14.x.
¿Puedo crear un clúster durante su ventana de disponibilidad ampliada?
Sí, puede crear un clúster 1.xx.x durante su ventana de disponibilidad ampliada. Sin embargo, se recomienda crear un clúster con la versión compatible más reciente.
¿Puedo actualizar un clúster a una versión más reciente durante su ventana de disponibilidad ampliada?
Sí, puede actualizar un clúster N-3 a N-2 durante su ventana de disponibilidad ampliada. Si el clúster se encuentra actualmente en N-4, puede usar la disponibilidad ampliada para actualizar primero de N-4 a N-3 y, a continuación, seguir con la actualización a una versión compatible (N-2).
Estoy en una ventana de disponibilidad ampliada, ¿puedo agregar nuevos grupos de nodos? ¿O tendré que actualizar?
Sí, puede agregar grupos de nodos al clúster.