Este documento ha sido traducido utilizando tecnología de traducción automática. Si bien nos esforzamos por proporcionar traducciones precisas, no ofrecemos garantías sobre la integridad, precisión o confiabilidad del contenido traducido. En caso de discrepancia, la versión original en inglés prevalecerá y constituirá el texto autorizado.

Migración de Azure In-tree a Out-of-tree

Kubernetes está dejando de mantener proveedores de nube integrados.

A partir de Kubernetes 1.29, los proveedores de nube internos se han deshabilitado. Debes desactivar DisableCloudProviders y DisableKubeletCloudCredentialProvider para utilizar el proveedor de nube in-tree de Azure o migrar del proveedor de nube in-tree al proveedor out-of-tree. Puedes desactivar las puertas de características requeridas configurando feature-gates=DisableCloudProviders=false como argumento adicional para el Kubelet, el Administrador de Controladores y el Servidor API del clúster en la configuración avanzada del clúster. Además, configura DisableKubeletCloudCredentialProvider=false en los argumentos del Kubelet para habilitar la funcionalidad in-tree para autenticarte en los registros de contenedores de Azure para las credenciales de extracción de imágenes. Consulta la documentación upstream para más detalles.

En Kubernetes v1.30 y versiones posteriores, se han eliminado los proveedores de nube in-tree. Rancher te permite actualizar a Kubernetes v1.30 cuando migras de un proveedor in-tree a uno out-of-tree.

Para migrar del proveedor de nube in-tree al proveedor de nube out-of-tree de Azure, debes detener el kube controller manager del clúster existente e instalar el Azure cloud controller manager.

Si es aceptable tener un tiempo de inactividad durante la migración, sigue las instrucciones para configurar un proveedor de nube out-of-tree. Estas instrucciones describen cómo configurar el proveedor de nube out-of-tree para un clúster recién aprovisionado. Durante la configuración, habrá un tiempo de inactividad, ya que hay un lapso de tiempo entre cuando el antiguo proveedor de nube deja de funcionar y cuando el nuevo proveedor de nube comienza a funcionar.

Si tu configuración no puede tolerar ningún tiempo de inactividad del plano de control, debes habilitar la migración de líderes. Esto facilita una transición suave de los controladores en el kube controller manager a sus contrapartes en el cloud controller manager.

Importante:

La documentación de migración del cloud controller manager de Kubernetes indica que es posible migrar con la misma versión de Kubernetes, pero asume que la migración es parte de una actualización de Kubernetes. Consulta la documentación de Kubernetes sobre migrar para usar el cloud controller manager para ver si necesitas personalizar tu configuración antes de migrar. Confirma tus valores de configuración de migración. Si tu proveedor de nube proporciona una implementación del Node IPAM controller, también necesitas migrar el IPAM controller.

A partir de Kubernetes v1.26, los tipos de volumen persistente in-tree kubernetes.io/azure-disk y kubernetes.io/azure-file quedan obsoletos y ya no son compatibles. No hay planes para eliminar estos controladores tras quedar obsoletos, sin embargo, deberías migrar a los controladores CSI correspondientes, disk.csi.azure.com y file.csi.azure.com. Para revisar las opciones de migración para tus clases de almacenamiento y actualizar tu clúster para utilizar los controladores CSI de Azure Disks y Azure Files, consulta Migrar de controladores in-tree a controladores CSI.

  • RKE2

  • RKE

  1. Actualiza la configuración del clúster para habilitar la migración del líder:

    spec:
      rkeConfig:
        machineSelectorConfig:
          - config:
              kube-controller-manager-arg:
                - enable-leader-migration
            machineLabelSelector:
              matchExpressions:
                - key: rke.cattle.io/control-plane-role
                  operator: In
                  values:
                    - 'true'

    Ten en cuenta que el proveedor de la nube sigue siendo azure en este paso:

    spec:
      rkeConfig:
        machineGlobalConfig:
          cloud-provider-name: azure
  2. Marca los nodos del plano de control como no programables para que los pods del controlador de nube de Azure se ejecuten en los nodos solo después de actualizar al proveedor de nube externo.

    kubectl cordon -l "node-role.kubernetes.io/control-plane=true"
  3. Para desplegar el administrador del controlador de nube de Azure, utiliza cualquiera de las opciones disponibles:

    Confirma que el chart está instalado pero que los nuevos pods aún no se están ejecutando debido a los nodos del plano de control cordonizados.

  4. Para habilitar la migración del líder, añade --enable-leader-migration a los argumentos del contenedor de cloud-controller-manager:

    kubectl -n kube-system patch deployment cloud-controller-manager \
    --type=json \
    -p='[{"op": "add", "path": "/spec/template/spec/containers/0/args/-", "value": "--enable-leader-migration"}]'
  5. Actualiza el clúster de aprovisionamiento para cambiar el proveedor de nube y eliminar los argumentos de migración del líder del administrador del controlador kube. Si actualizas la versión de Kubernetes, establece también la versión de Kubernetes en la sección spec.kubernetesVersion del archivo YAML del clúster.

    spec:
      rkeConfig:
        machineGlobalConfig:
          cloud-provider-name: external

    Elimina enable-leader-migration del administrador del controlador kube:

    spec:
      rkeConfig:
        machineSelectorConfig:
          - config:
              kube-controller-manager-arg:
                - enable-leader-migration
            machineLabelSelector:
              matchExpressions:
                - key: rke.cattle.io/control-plane-role
                  operator: In
                  values:
                    - 'true'
  6. Descordoniza los nodos del plano de control para que los pods del controlador de nube de Azure ahora se ejecuten en los nodos:

    kubectl uncordon -l "node-role.kubernetes.io/control-plane=true"
  7. Actualiza el clúster. Los pods de cloud-controller-manager deberían estar ahora en ejecución.

    kubectl rollout status deployment -n kube-system cloud-controller-manager
    kubectl rollout status daemonset -n kube-system cloud-node-manager
  8. El proveedor de la nube es responsable de establecer el ProviderID del nodo. Verifica si todos los nodos están inicializados con el ProviderID:

    kubectl describe nodes | grep "ProviderID"
  9. (Opcional) También puedes deshabilitar la migración del líder después de la actualización, ya que la migración del líder no es necesaria con solo un controlador de nube. Actualiza la ampliación de cloud-controller-manager para eliminar la migración del líder de los argumentos del contenedor:

    - --enable-leader-migration=true
  1. Actualiza la configuración del clúster para habilitar la migración del líder en cluster.yml:

    services:
      kube-controller:
        extra_args:
          enable-leader-migration: "true"

    Ten en cuenta que el proveedor de la nube sigue siendo azure en este paso:

    cloud_provider:
      name: azure
  2. Marca los nodos del plano de control como no programables, para que los pods del controlador de nube de Azure se ejecuten en los nodos solo después de actualizar al proveedor de nube externo.

    kubectl cordon -l "node-role.kubernetes.io/controlplane=true"
  3. Para instalar el administrador del controlador de nube de Azure, sigue los mismos pasos que al instalar el proveedor de nube de Azure en un nuevo clúster:

  4. Confirma que el chart está instalado pero que los nuevos pods aún no se están ejecutando debido a los nodos del plano de control cordonizados. Después de actualizar el clúster en el siguiente paso, RKE actualizará y descordonará cada nodo, y programará cloud-controller-manager pods.

  5. Para habilitar la migración del líder, añade --enable-leader-migration a los argumentos del contenedor de cloud-controller-manager:

    kubectl -n kube-system patch deployment cloud-controller-manager \
    --type=json \
    -p='[{"op": "add", "path": "/spec/template/spec/containers/0/args/-", "value": "--enable-leader-migration"}]'
  6. Actualiza cluster.yml para cambiar el proveedor de nube a external y eliminar los argumentos de migración del líder del kube-controller.

    rancher_kubernetes_engine_config:
      cloud_provider:
        name: external

    Elimina enable-leader-migration si no deseas que esté habilitado en tu clúster:

    services:
      kube-controller:
        extra_args:
          enable-leader-migration: "true"
  7. Si estás actualizando la versión de Kubernetes del clúster, establece también la versión de Kubernetes.

  8. Actualiza el clúster. Los pods de cloud-controller-manager deberían estar ahora en ejecución.

    kubectl rollout status deployment -n kube-system cloud-controller-manager
    kubectl rollout status daemonset -n kube-system cloud-node-manager
  9. El proveedor de la nube es responsable de establecer el ProviderID del nodo. Verifica que todos los nodos estén inicializados con el ProviderID:

    kubectl describe nodes | grep "ProviderID"
  10. (Opcional) También puedes deshabilitar la migración del líder después de la actualización, ya que la migración del líder no es necesaria con solo un controlador de nube. Actualiza la ampliación de cloud-controller-manager para eliminar la migración del líder de los argumentos del contenedor:

    - --enable-leader-migration=true