Guia de início rápido: Conectar um cluster existente do Kubernetes ao Azure Arc

  • Artigo

Introdução ao Kubernetes habilitado para o Azure Arc usando a CLI do Azure ou o Azure PowerShell para conectar um cluster Kubernetes existente ao Azure Arc.

Para obter uma visão conceitual de como conectar clusters ao Azure Arc, confira Visão geral do agente do Kubernetes habilitado para o Azure Arc. Para uma experiência de amostra/prática, visite o Jumpstart do Azure Arc.

Pré-requisitos

Importante

Além desses pré-requisitos, certifique-se de atender a todos os requisitos de rede Kubernetes habilitado para Azure Arc.

  • Uma conta do Azure com uma assinatura ativa. Crie uma conta gratuitamente.

  • Uma compreensão básica dos conceitos principais do Kubernetes.

  • Uma identidade (usuário ou entidade de serviço) que pode ser usada para fazer logon na CLI do Azure e conectar seu cluster ao Azure Arc.

  • A versão mais recente da CLI do Azure.

  • A versão mais recente da extensão da CLI do Azure connectedk8s, instalada executando o seguinte comando:

    az extension add --name connectedk8s

  • Um cluster funcional do Kubernetes. Se você não tiver um, poderá criar um cluster usando uma destas opções:

    • KIND (Kubernetes no Docker)

    • Criar um cluster do Kubernetes usando o Docker para Mac ou para Windows

    • Cluster do Kubernetes autogerenciado usando a API de Cluster

      Observação

      O cluster precisa ter pelo menos um nó de sistema operacional e arquitetura do tipo, linux/amd64 e/ou linux/arm64. Consulte Requisitos de cluster para mais informações sobre cenários ARM64.

  • Pelo menos 850 MB livres para os agentes do Arc que serão implantados no cluster e capacidade de usar aproximadamente 7% de uma única CPU.

  • Um arquivo kubeconfig e o contexto apontando para o cluster. Para saber mais sobre o que é um arquivo kubeconfig e como definir o contexto para apontar para seu cluster, confira este artigo.

Registrar provedores do Kubernetes habilitado para o Azure Arc

  1. Digite os seguintes comandos:

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

  2. Monitore o processo de registro. O registro pode levar até 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

    Depois de registrado, você verá o estado RegistrationState desses namespaces mudar para Registered.

Criar um grupo de recursos

Execute o seguinte comando:

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

Saída:

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

Conectar um cluster existente do Kubernetes

Execute o comando a seguir para se conectar ao cluster. Esse comando implanta os agentes do Azure Arc no cluster e instala o Helm v. 3.6.3 na pasta .azure do computador de implantação. Essa instalação do Helm 3 só é usada para o Azure Arc e não remove nem altera nenhuma versão do Helm instalada anteriormente no computador.

Neste exemplo, o nome do cluster é AzureArcTest1.

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

Saída:

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"
    }

Dica

O comando acima sem o parâmetro de local especificado cria o recurso do Kubernetes habilitado para o Azure Arc no mesmo local que o grupo de recursos. Para criar o recurso do Kubernetes habilitado para o Azure Arc em um local diferente, especifique --location <region> ou -l <region> ao executar o comando az connectedk8s connect.

Importante

Se a implantação falhar devido a um erro de tempo limite, veja nosso guia de solução de problemas para obter detalhes sobre como resolver esse problema.

Conectar-se usando um servidor proxy de saída

Se o cluster estiver atrás de um servidor proxy de saída, as solicitações deverão ser roteadas por meio do servidor proxy de saída.

  1. Na máquina de implantação, defina as variáveis de ambiente necessárias para a CLI do Azure usar o servidor proxy de saída:

    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. No cluster do Kubernetes, execute o comando connect com os parâmetros proxy-https e proxy-http especificados. Se o servidor proxy estiver configurado com HTTP e HTTPS, certifique-se de usar --proxy-http para o proxy HTTP e --proxy-https para o proxy HTTPS. Se o servidor proxy usar apenas HTTP, você poderá usar esse valor para ambos os 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>

Observação

  • Algumas solicitações de rede, como as que envolvem a comunicação de serviço a serviço no cluster, precisam ser separadas do tráfego que é roteado por meio do servidor proxy para comunicação de saída. O parâmetro --proxy-skip-range pode ser usado para especificar o intervalo de CIDR e os pontos de extremidade separados por vírgula, de maneira que qualquer comunicação dos agentes com esses pontos de extremidade não passe pelo proxy de saída. No mínimo, o intervalo CIDR dos serviços do cluster deve ser especificado como um valor para esse parâmetro. Por exemplo, digamos que kubectl get svc -A retorne uma lista de serviços em que todos os serviços tenham valores ClusterIP no intervalo 10.0.0.0/16. O valor a ser especificado para --proxy-skip-range será 10.0.0.0/16,kubernetes.default.svc,.svc.cluster.local,.svc.
  • --proxy-http, --proxy-https e --proxy-skip-range são esperados para a maioria dos ambientes de proxy de saída. --proxy-certsó será necessário se você precisar injetar certificados confiáveis esperados pelo proxy no repositório de certificados confiáveis dos pods do agente.
  • O proxy de saída precisa ser configurado para permitir conexões WebSocket.

Para servidores proxy de saída em que apenas um certificado confiável precisa ser fornecido sem as entradas do ponto de extremidade do servidor proxy, az connectedk8s connect pode ser executado apenas com a entrada --proxy-cert especificada. Caso vários certificados confiáveis sejam esperados, a cadeia de certificados combinada pode ser fornecida em apenas um arquivo usando o parâmetro --proxy-cert.

Observação

  • --custom-ca-cert é um alias para --proxy-cert. Ambos os parâmetros podem ser usados de maneira intercambiável. A transmissão dos dois parâmetros no mesmo comando respeitará aquele que foi transmitido por último.

Execute o comando connect com o parâmetro --proxy-cert especificado:

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

Verificar a conexão do cluster

Execute o seguinte comando:

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

Saída:

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

Observação

Após a integração do cluster, levará cerca de 5 a 10 minutos para que os metadados do cluster (versão do cluster, versão do agente, número de nós etc.) sejam exibidos na página de visão geral do recurso do Kubernetes habilitado para o Azure Arc no portal do Azure.

Dica

Para obter ajuda para solucionar problemas ao conectar seu cluster, confira Diagnosticar problemas de conexão para clusters do Kubernetes habilitados para Azure Arc.

Exibir agentes do Azure Arc para Kubernetes

O Kubernetes habilitado para Azure Arc implanta vários agentes no namespace azure-arc.

  1. Veja essas implantações e os pods usando:

    kubectl get deployments,pods -n azure-arc

  2. Verifique se todos os pods estão em um estado Running.

    Saída:

     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 obter mais informações sobre esses agentes, consulte Visão geral do agente do Kubernetes habilitado para o Azure Arc.

Limpar os recursos

Exclua o recurso do Kubernetes habilitado para o Azure Arc, todos os recursos de configuração associados e todos os agentes em execução no cluster usando o seguinte comando na CLI do Azure:

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

Se o processo de exclusão falhar, use o comando a seguir para forçar a exclusão (adicionar -y se desejar ignorar o prompt de confirmação):

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

Esse comando também pode ser usado se você tiver problemas ao criar uma nova implantação de cluster (causados pela remoção incompleta de recursos criados anteriormente).

Observação

A exclusão do recurso do Kubernetes habilitado para o Azure Arc pelo portal do Azure remove todos os recursos de configuração associados, mas não remove nenhum agente em execução no cluster. A melhor prática é excluir o recurso do Kubernetes habilitado para o Azure Arc usando az connectedk8s delete em vez de excluir o recurso no portal do Azure.

Próximas etapas