Inicio rápido: conexión de un clúster de Kubernetes existente a Azure Arc

  • Artículo

Para empezar a trabajar con Kubernetes habilitado para Azure Arc, use la CLI de Azure o Azure PowerShell para conectar un clúster de Kubernetes existente a Azure Arc.

Para obtener una visión conceptual de la conexión de clústeres a Azure Arc, consulte Información general del agente de Kubernetes habilitado para Azure Arc. Para probar esto en una experiencia de ejemplo o práctica, visite el Jumpstart de Azure Arc.

Requisitos previos

Además de estos requisitos previos, asegúrese de cumplir todos los requisitos de red para Kubernetes habilitado para Azure Arc.

  • Una cuenta de Azure con una suscripción activa. Cree una cuenta gratuita.

  • Conocimientos básicos de los conceptos básicos de Kubernetes.

  • Una identidad (usuario o entidad de servicio) que se puede usar para iniciar sesión en la CLI de Azure y conectar el clúster a Azure Arc.

  • La versión más reciente de la CLI de Azure.

  • La versión más reciente de la extensión de la CLI de Azure connectedk8s, instalada mediante la ejecución del siguiente comando:

    az extension add --name connectedk8s

  • Un clúster de Kubernetes en funcionamiento. Si no tiene ninguno, puede crear un clúster mediante una de estas opciones:

    • Kubernetes en Docker (KIND)

    • Creación de un clúster de Kubernetes con Docker para Mac o Windows

    • Clúster de Kubernetes autoadministrado mediante la API de clúster

      Nota

      El clúster debe tener al menos un nodo de sistema operativo y el tipo de arquitectura linux/amd64 o linux/arm64. Consulte Requisitos de clúster para más información sobre los escenarios de ARM64.

  • Al menos 850 MB libres para los agentes de Arc que se implementarán en el clúster y capacidad para usar aproximadamente el 7 % de una sola CPU.

  • Un archivo kubeconfig y un contexto que apunte al clúster.

Registro de proveedores en Kubernetes habilitado para Azure Arc

  1. Escriba los siguientes comandos:

    az provider register --namespace Microsoft.Kubernetes
az provider register --namespace Microsoft.KubernetesConfiguration
az provider register --namespace Microsoft.ExtendedLocation

  2. Supervise el proceso de registro. El registro puede tardar un máximo de 10 minutos.

    az provider show -n Microsoft.Kubernetes -o table
az provider show -n Microsoft.KubernetesConfiguration -o table
az provider show -n Microsoft.ExtendedLocation -o table

    Una vez registrado, debería ver que el estado RegistrationState de estos espacios de nombres cambia a Registered.

Crear un grupo de recursos

Ejecute el siguiente comando:

az group create --name AzureArcTest --location EastUS --output table

Salida:

Location    Name
----------  ------------
eastus      AzureArcTest

Conexión de un clúster de Kubernetes existente

Ejecute el siguiente comando para conectar su clúster. Este comando implementa los agentes de Azure Arc en el clúster e instala Helm v. 3.6.3 en la carpeta .azure de la máquina de implementación. Esta instalación de Helm 3 solo se usa para Azure Arc y no quita ni cambia ninguna versión instalada anteriormente de Helm en la máquina.

En este ejemplo, el nombre del clúster es AzureArcTest1.

az connectedk8s connect --name AzureArcTest1 --resource-group AzureArcTest

Salida:

Helm release deployment succeeded

    {
      "aadProfile": {
        "clientAppId": "",
        "serverAppId": "",
        "tenantId": ""
      },
      "agentPublicKeyCertificate": "xxxxxxxxxxxxxxxxxxx",
      "agentVersion": null,
      "connectivityStatus": "Connecting",
      "distribution": "gke",
      "id": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/AzureArcTest/providers/Microsoft.Kubernetes/connectedClusters/AzureArcTest1",
      "identity": {
        "principalId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
        "tenantId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
        "type": "SystemAssigned"
      },
      "infrastructure": "gcp",
      "kubernetesVersion": null,
      "lastConnectivityTime": null,
      "location": "eastus",
      "managedIdentityCertificateExpirationTime": null,
      "name": "AzureArcTest1",
      "offering": null,
      "provisioningState": "Succeeded",
      "resourceGroup": "AzureArcTest",
      "tags": {},
      "totalCoreCount": null,
      "totalNodeCount": null,
      "type": "Microsoft.Kubernetes/connectedClusters"
    }

Sugerencia

El comando anterior sin el parámetro location especificado crea el recurso de Kubernetes habilitado para Azure Arc en la misma ubicación que el grupo de recursos. Para crear el recurso de Kubernetes habilitado para Azure Arc en una ubicación diferente, especifique --location <region> o -l <region> al ejecutar el comando az connectedk8s connect.

Importante

Si se produce un error de implementación debido a un error de tiempo de espera, consulte nuestra guía de solución de problemas para obtener más información sobre cómo resolver este problema.

Conexión mediante un servidor proxy de salida

Si el clúster está detrás de un servidor proxy de salida, las solicitudes se deben enrutar a través del servidor proxy de salida.

  1. En la máquina de implementación, establezca las variables de entorno necesarias para que la CLI de Azure use el servidor proxy de salida:

    export HTTP_PROXY=<proxy-server-ip-address>:<port>
export HTTPS_PROXY=<proxy-server-ip-address>:<port>
export NO_PROXY=<cluster-apiserver-ip-address>:<port>

  2. En el clúster de Kubernetes, ejecute el comando connect con los parámetros proxy-https y proxy-http especificados. Si el servidor proxy está configurado con HTTP y HTTPS, asegúrese de usar --proxy-http para el proxy HTTP y --proxy-https para el proxy HTTPS. Si el servidor proxy solo usa HTTP, puede usar ese valor para ambos parámetros.

    az connectedk8s connect --name <cluster-name> --resource-group <resource-group> --proxy-https https://<proxy-server-ip-address>:<port> --proxy-http http://<proxy-server-ip-address>:<port> --proxy-skip-range <excludedIP>,<excludedCIDR> --proxy-cert <path-to-cert-file>

Nota

  • Algunas solicitudes de red, como las que implican la comunicación entre servicios en el clúster, deben separarse del tráfico que se enruta a través del servidor proxy para la comunicación saliente. El parámetro --proxy-skip-range se puede usar para especificar el intervalo CIDR y los puntos de conexión en formato separado por comas para que las comunicaciones entre los agentes y estos puntos de conexión no se realicen a través del proxy de salida. Como mínimo, el intervalo CIDR de los servicios del clúster debe especificarse como valor para este parámetro. Por ejemplo, supongamos que kubectl get svc -A devuelve una lista de servicios donde todos los servicios tienen valores ClusterIP en el intervalo 10.0.0.0/16. A continuación, el valor que se va a especificar para --proxy-skip-range es 10.0.0.0/16,kubernetes.default.svc,.svc.cluster.local,.svc.
  • --proxy-http--proxy-https y --proxy-skip-range se esperan para la mayoría de los entornos de proxy de salida. --proxy-certsolo se necesita si hay que insertar en el almacén de certificados de confianza de pods del agente certificados de confianza que espera el proxy.
  • El proxy de salida debe configurarse para permitir conexiones de WebSocket.

En el caso de los servidores proxy de salida en los que solo es necesario proporcionar un certificado de confianza sin las entradas del punto de conexión del servidor proxy, se puede ejecutar az connectedk8s connect solo con la entrada --proxy-cert especificada. En caso de que se esperen varios certificados de confianza, la cadena de certificados combinada se puede proporcionar en un único archivo mediante el parámetro --proxy-cert.

Nota

  • --custom-ca-cert es un alias de --proxy-cert. Los parámetros se puede usar indistintamente. Si se usan ambos parámetros en el mismo comando respetará el último usado.

Ejecute el comando connect con el parámetro --proxy-cert especificado:

az connectedk8s connect --name <cluster-name> --resource-group <resource-group> --proxy-cert <path-to-cert-file>

Comprobación de la conexión del clúster

Ejecute el siguiente comando:

az connectedk8s list --resource-group AzureArcTest --output table

Salida:

Name           Location    ResourceGroup
-------------  ----------  ---------------
AzureArcTest1  eastus      AzureArcTest

Nota

Después de la incorporación del clúster, los metadatos del mismo (versión del clúster, versión del agente, número de nodos, etc.) tardan entre 5 y 10 minutos en aparecer en la página de información general del recurso de Kubernetes compatible con Azure Arc en Azure Portal.

Sugerencia

Para obtener ayuda con la solución de problemas de conexión del clúster, consulte Diagnóstico de problemas de conexión para clústeres de Kubernetes habilitados para Azure Arc.

Visualización de agentes de Azure Arc para Kubernetes

Kubernetes habilitado para Azure Arc implementa varios agentes en el espacio de nombres azure-arc.

  1. Para ver estas implementaciones y pods, utilice:

    kubectl get deployments,pods -n azure-arc

  2. Compruebe que todos los pods están en el estado Running.

    Salida:

     NAME                                        READY   UP-TO-DATE   AVAILABLE   AGE
 deployment.apps/cluster-metadata-operator   1/1     1            1           13d
 deployment.apps/clusterconnect-agent        1/1     1            1           13d
 deployment.apps/clusteridentityoperator     1/1     1            1           13d
 deployment.apps/config-agent                1/1     1            1           13d
 deployment.apps/controller-manager          1/1     1            1           13d
 deployment.apps/extension-manager           1/1     1            1           13d
 deployment.apps/flux-logs-agent             1/1     1            1           13d
 deployment.apps/kube-aad-proxy              1/1     1            1           13d
 deployment.apps/metrics-agent               1/1     1            1           13d
 deployment.apps/resource-sync-agent         1/1     1            1           13d

 NAME                                            READY   STATUS    RESTARTS   AGE
 pod/cluster-metadata-operator-9568b899c-2stjn   2/2     Running   0          13d
 pod/clusterconnect-agent-576758886d-vggmv       3/3     Running   0          13d
 pod/clusteridentityoperator-6f59466c87-mm96j    2/2     Running   0          13d
 pod/config-agent-7cbd6cb89f-9fdnt               2/2     Running   0          13d
 pod/controller-manager-df6d56db5-kxmfj          2/2     Running   0          13d
 pod/extension-manager-58c94c5b89-c6q72          2/2     Running   0          13d
 pod/flux-logs-agent-6db9687fcb-rmxww            1/1     Running   0          13d
 pod/kube-aad-proxy-67b87b9f55-bthqv             2/2     Running   0          13d
 pod/metrics-agent-575c565fd9-k5j2t              2/2     Running   0          13d
 pod/resource-sync-agent-6bbd8bcd86-x5bk5        2/2     Running   0          13d

Para obtener más información sobre estos agentes, consulte Información general sobre el agente de Kubernetes habilitado para Azure Arc.

Limpieza de recursos

Para eliminar el recurso Kubernetes habilitado para Azure Arc, todos los recursos de configuración asociados y todos los agentes que se ejecuten en el clúster mediante la CLI de Azure, utilice el siguiente comando:

az connectedk8s delete --name AzureArcTest1 --resource-group AzureArcTest

Si se produce un error en el proceso de eliminación, use el siguiente comando para forzar la eliminación (agregando -y si desea omitir el símbolo del sistema de confirmación):

az connectedk8s delete -n AzureArcTest1 -g AzureArcTest --force

Este comando también se puede usar si experimenta problemas al crear una nueva implementación de clúster (debido a que los recursos creados anteriormente no se quitan completamente).

Nota

Si se usa Azure Portal para eliminar el recurso Kubernetes habilitado para Azure Arc, se eliminan todos los recursos de configuración asociados, pero no se elimina ningún agente que se ejecute en el clúster. El procedimiento recomendado es eliminar el recurso de Kubernetes habilitado para Azure Arc mediante az connectedk8s delete en lugar de eliminar el recurso de Azure Portal.

Pasos siguientes