Kubernetes 1.17: cómo actualizar sin gastar todo el presupuesto de errores

El 9 de diciembre se lanzó una nueva versión de Kubernetes — 1.17. Su lema es «Estabilidad», muchas características obtuvieron el estado GA, y un número considerable de características obsoletas fueron eliminadas…

Y, como siempre, nuestra sección favorita de Acción Requerida del archivo CHANGELOG-1.17.md requiere atención.

Manos a la obra…

¡Atención, Storage!

La actualización de kubelet en caliente en la versión 1.17 no es compatible, porque cambió la ruta a los volúmenes de bloque. Antes de actualizar el nodo, es necesario evacuar todos los pods de él con el comando kubectl drain.

Banderas y puertas…

En el changelog generalmente se indica que se ha añadido o eliminado tal flag o feature gate, pero curiosamente nunca se menciona la aplicación en la que ocurrió este cambio…:

• Se eliminó la bandera --include-uninitialized sa-logic-subsets-canary-vs.yaml kubectl;
• Funcionalidad que era permitida por los feature gates GCERegionalPersistentDisk, EnableAggregatedDiscoveryTimeout y VolúmenesLocalPersistentes, ahora se utiliza siempre y no se puede desactivar. Estas opciones han sido eliminadas de las claves posibles api-server y controller-manager;
• La red de direcciones IP para los servicios ya no se asigna por defecto. Es necesario especificarla con la bandera --service-cluster-ip-range al iniciar el API server y el controller-manager.

kubeadm

• Kubeadm ha aprendido a configurar la actualización automática de certificados para kubelet en todos los nodos del clúster, incluido el primer maestro, donde se ejecutó el comando kubeadm init. El efecto secundario fue la necesidad de un archivo con la configuración inicial de kubelet bootstrap-kubelet.conf en lugar de kubelet.conf durante la ejecución kubeadm init;
• Al agregar modos de autorización en el API servidor kubeadm ya no inserta los modos Node, RBAC en el manifiesto del pod estático, permitiendo cambiar completamente la configuración.

RBAC

Se eliminaron roles de clúster integrados system:csi-external-provisioner y system:csi-external-attacher.

Obsoleto…

Un número de características han sido declaradas obsoletas, sin embargo, todavía siguen siendo soportadas. Pero especialmente queremos destacar el proceso de transición al uso de ContainerStorageInterface. Los administradores que han desplegado clústeres propios (no gestionados) en AWS y GCE deben planear la migración al uso de CSI Driver para trabajar con volúmenes persistentes — en lugar de los drivers integrados en Kubernetes. Deben ser ayudados por el procedimiento de CSIMigration — esperamos la aparición de una guía paso a paso. Los administradores que utilizan otros proveedores para conectar discos persistentes, es momento de buscar y leer la documentación: se promete eliminar finalmente todos los drivers integrados en la versión 1.21.

Fuente: habr.com