Kubernetes 1.17: cómo actualizar y no gastar todo el presupuesto de error

imagen

El 9 de diciembre, se lanzó la próxima versión de Kubernetes: 1.17. Su lema es "Estabilidad", muchas características recibieron el estado de GA, se eliminaron varias características obsoletas ...

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

Trabajemos con tus manos ...

Advertencia de almacenamiento!


La actualización de Kubelet sobre la marcha en la versión 1.17 no es compatible porque la ruta para bloquear volúmenes ha cambiado. Antes de actualizar el nodo, debe evacuar todos los pods del mismo utilizando el kubectl drain .

Banderas y puertas ...


Changelog generalmente escribe que se ha eliminado o agregado un indicador o puerta de características, pero por alguna razón nunca escriben una aplicación que tenga este cambio ...:

  • La bandera --include-uninitialized para kubectl ;
  • La funcionalidad que presenta las puertas GCERegionalPersistentDisk , EnableAggregatedDiscoveryTimeout y PersistentLocalVolumes permitidas ahora siempre se usa y no se puede deshabilitar. Estas opciones se eliminan de las posibles claves de api-server y controller-manager ;
  • La red de direcciones IP para servicios ya no está asignada de manera predeterminada. Debe especificarlo usando el --service-cluster-ip-range cuando inicie la API del servidor y el controlador-administrador.

kubeadm


  • Kubeadm aprendió a configurar la renovación automática de certificados para kubelet en todos los nodos del clúster, incluido el primer asistente donde se kubeadm init comando kubeadm init . Un efecto secundario fue el requisito de tener un archivo con la configuración inicial kubelet bootstrap-kubelet.conf lugar de kubelet.conf durante kubeadm init ;
  • Al agregar modos de autorización a la API, el servidor kubeadm ya no sustituye los modos Node, RBAC en el manifiesto de las estadísticas del pod, lo que le permite cambiar completamente la configuración.

RBAC


Se eliminó el system:csi-external-provisioner roles de clúster system:csi-external-provisioner y el system:csi-external-attacher .

En desuso ...


Una serie de características han quedado en desuso, pero aún siguen siendo compatibles. Pero me gustaría especialmente notar el proceso de cambiar a usar ContainerStorageInterface. Los administradores que han implementado sus propios clústeres (no administrados) en AWS y GCE deberían planear moverse para usar el controlador CSI para trabajar con volúmenes persistentes, en lugar de los controladores integrados en Kubernetes. El procedimiento de CSIMigration debería ayudarlos en esto: estamos esperando que aparezca la guía paso a paso. Es hora de que los administradores que usan otros proveedores para conectar unidades persistentes busquen y lean la documentación: en la versión 1.21 prometen eliminar permanentemente todos los controladores incorporados.

Source: https://habr.com/ru/post/479534/


All Articles