Mejores prácticas de cambio de versión
Descubra las mejores prácticas de actualización para clusters que ha creado con Kubernetes Engine (OKE).
Esta sección contiene las mejores prácticas para la actualización y el motor de Kubernetes.
Mejores prácticas: uso de la última versión de Kubernetes
Las nuevas versiones de Kubernetes suelen incluir muchas actualizaciones, funciones adicionales y, lo que es más importante, parches para abordar problemas de seguridad en versiones anteriores. Kubernetes Engine proporciona soporte para tres versiones menores de Kubernetes, con la última versión de parche para cada una de esas versiones.
Por lo tanto, recomendamos que:
- Los clusters de producción siempre ejecutan la última versión estable de Kubernetes.
- Especifique la última versión secundaria soportada de Kubernetes al crear clusters con Kubernetes Engine.
- Actualiza los clusters existentes cuando Oracle anuncia el soporte de Kubernetes Engine para una versión principal, versión secundaria o versión de parche de Kubernetes. La actualización regular de clusters permite evitar situaciones en las que los clusters ejecutan versiones anteriores de Kubernetes que no incluyen las últimas funciones y correcciones.
Consulte Versiones de Kubernetes y Kubernetes Engine (OKE), Actualización de clusters a versiones más recientes de Kubernetes.
Mejores prácticas: configuración de entornos de prueba y producción
Recomendamos utilizar varios entornos de Kubernetes Engine como parte de un flujo de trabajo para desplegar y lanzar aplicaciones. El uso de varios entornos ayuda a minimizar el riesgo y el tiempo de inactividad no deseado al permitirle probar actualizaciones de software e infraestructura en un entorno independiente del entorno de producción. Como mínimo, le recomendamos que disponga de un entorno de producción y un entorno de preproducción o prueba.
También recomendamos que antes de actualizar un cluster a una nueva versión de Kubernetes, pruebe cualquier aplicación desplegada en el cluster para confirmar que las aplicaciones son compatibles con la nueva versión de Kubernetes. Después de actualizar los nodos de plano de control a una versión más reciente de Kubernetes, no puede volver a una versión anterior de Kubernetes. De ahí la importancia de probar las aplicaciones antes de actualizar el cluster a una nueva versión de Kubernetes. Por ejemplo, antes de actualizar un cluster, puede crear un cluster independiente que ejecute la nueva versión de Kubernetes y probar las aplicaciones en ese cluster.
Consulte Actualización de clusters a versiones más recientes de Kubernetes.
Mejores prácticas: uso de una estrategia de despliegue azul/verde
Le recomendamos que utilice una estrategia de despliegue azul/verde para reducir el riesgo y minimizar el tiempo de inactividad al actualizar los clusters de Kubernetes. Los despliegues azul/verde utilizan dos entornos de producción, conocidos como "azul" y "verde", para proporcionar pruebas fiables, actualizaciones continuas sin interrupción y rollbacks instantáneos. El uso de una estrategia de despliegue azul/verde garantiza que los usuarios tengan acceso a un entorno de producción mientras se actualiza el otro entorno de producción.
Mejores Prácticas: Programación de Ventanas de Mantenimiento
Le recomendamos que programe actividades de mantenimiento durante las horas valle para limitar el impacto en las aplicaciones que no manejan correctamente la interrupción de pod causada por el mantenimiento y las actualizaciones de cluster/nodo.
Por ejemplo, durante las actualizaciones, puede haber interrupciones temporales cuando se mueven las cargas de trabajo para volver a crear los nodos. Para garantizar que tales interrupciones causen un impacto mínimo, cuando sea posible:
- programar actualizaciones para horas valle
- Diseñar despliegues de aplicaciones para manejar interrupciones parciales sin problemas
Mejores prácticas: Tratar los nodos de trabajador como inmutables
Recomendamos que trate los nodos de trabajador existentes como entidades inmutables.
Cualquier cambio que realice en las propiedades del nodo de trabajador de un pool de nodos solo se aplica a los nuevos nodos de trabajador que se creen posteriormente. No puede cambiar las propiedades de los nodos de trabajador existentes.
Por ejemplo, en lugar de actualizar la imagen del sistema operativo que se ejecuta en nodos de trabajador existentes, considere la posibilidad de crear un nuevo pool de nodos con nodos de trabajador que tengan la imagen del sistema operativo actualizada. Una vez especificadas las opciones de cableado y vaciado para el pool de nodos original a fin de evitar el inicio de nuevos pods y suprimir pods existentes, puede cambiar el trabajo del pool de nodos original al nuevo pool de nodos. A continuación, puede suprimir el pool de nodos original.
Mejores prácticas: cordón y drenaje de nodos de trabajador en preparación para el mantenimiento
Le recomendamos que conecte y drene un nodo de trabajador antes del mantenimiento programado en ese nodo.
La conexión por cable marca un nodo de trabajador como no programable e impide que el programador de kube coloque nuevos pods en ese nodo. El drenaje expulsa de forma segura los pods de un nodo de trabajador, lo que garantiza que los contenedores terminan correctamente y realizan cualquier limpieza necesaria.
Consulte Cordoning and Draining Managed Nodes Before Shut Down or Termination. Consulte también Administración manual de nodos y Drenaje seguro de un nodo en la documentación de Kubernetes.