Partilhar via

Ligar aos nós de cluster do Azure Kubernetes Service (AKS) para manutenção ou resolução de problemas

Durante todo o ciclo de vida do cluster do Serviço Kubernetes do Azure (AKS), você eventualmente precisará acessar diretamente um nó AKS. Esse acesso pode ser para manutenção, coleta de logs ou operações de solução de problemas.

Você acede a um nó através de autenticação, cujos métodos variam dependendo do sistema operativo do nó e do método de conexão. Você se autentica com segurança nos nós AKS Linux e Windows através de duas opções discutidas neste artigo. Um requer que você tenha acesso à API do Kubernetes e o outro é através da API AKS ARM, que fornece informações IP privadas diretas. Por razões de segurança, os nós AKS não estão expostos à internet. Em vez disso, para se conectar diretamente a qualquer nó AKS, você precisa usar kubectl debug ou o endereço IP privado do host.

Acessar nós usando a API do Kubernetes

Este método requer o uso de kubectl debug comando.

Antes de começar

Este guia mostra como criar uma conexão com um nó AKS e atualizar a chave SSH do seu cluster AKS. Para seguir as etapas, você precisa usar a CLI do Azure que oferece suporte à versão 2.0.64 ou posterior. Execute az --version para verificar a versão. Se precisar de instalar ou atualizar, veja Install Azure CLI (Instalar o Azure CLI).

Conclua estas etapas se você não tiver uma chave SSH. Crie uma chave SSH de acordo com a imagem do sistema operativo do Node, para macOS e Linux ou Windows. Certifique-se de salvar o par de chaves no formato OpenSSH, evite formatos não suportados, como .ppk. Em seguida, consulte Gerenciar configuração SSH para adicionar a chave ao cluster.

Linux e macOS

Os utilizadores de Linux e macOS podem aceder aos seus nós usando kubectl debug ou o seu endereço IP privado. Os usuários do Windows devem pular para a seção Proxy do Windows Server para obter uma solução alternativa para SSH via proxy.

Conectar usando kubectl debug

Para criar uma conexão de shell interativa, use o comando kubectl debug para executar um contentor privilegiado no seu nó.

  1. Para listar seus nós, use o kubectl get nodes comando:

    kubectl get nodes -o wide

    Saída de exemplo:

    NAME                                STATUS   ROLES   AGE    VERSION   INTERNAL-IP   EXTERNAL-IP   OS-IMAGE
aks-nodepool1-37663765-vmss000000   Ready    agent   166m   v1.25.6   10.224.0.33   <none>        Ubuntu 22.04.2 LTS
aks-nodepool1-37663765-vmss000001   Ready    agent   166m   v1.25.6   10.224.0.4    <none>        Ubuntu 22.04.2 LTS
aksnpwin000000                      Ready    agent   160m   v1.25.6   10.224.0.62   <none>        Windows Server 2022 Datacenter

  2. Use o kubectl debug comando para iniciar um contêiner privilegiado no nó e conectar-se a ele.

    kubectl debug node/aks-nodepool1-37663765-vmss000000 -it --image=mcr.microsoft.com/cbl-mariner/busybox:2.0

    Saída de exemplo:

    Creating debugging pod node-debugger-aks-nodepool1-37663765-vmss000000-bkmmx with container debugger on node aks-nodepool1-37663765-vmss000000.
If you don't see a command prompt, try pressing enter.
root@aks-nodepool1-37663765-vmss000000:/#

    Agora você tem acesso ao nó por meio de um contêiner privilegiado como um pod de depuração.

    Nota

    Você pode interagir com a sessão do nó executando chroot /host a partir do contêiner privilegiado.

Sair do modo de depuração kubectl

Quando terminar com o seu nó, insira o comando exit para encerrar a sessão interativa do shell. Depois de a sessão de contenedor interativo ser fechada, exclua o pod de depuração usado com kubectl delete pod.

kubectl delete pod node-debugger-aks-nodepool1-37663765-vmss000000-bkmmx

Conexão de proxy do Windows Server para SSH

Siga estas etapas como uma solução alternativa para estabelecer ligação via SSH num nó do Windows Server.

Criar um servidor proxy

Atualmente, não é possível estabelecer ligação direta com um nó do Windows Server utilizando kubectl debug. Em vez disso, você precisa primeiro se conectar a outro nó no cluster com kubectl, e depois conectar-se ao nó do Windows Server a partir desse nó usando SSH.

Para se conectar a outro nó no cluster, use o comando kubectl debug. Para obter mais informações, siga as etapas acima na seção kubectl. Crie uma conexão SSH com o nó do Windows Server a partir de outro nó usando as chaves SSH fornecidas quando você criou o cluster AKS e o endereço IP interno do nó do Windows Server.

Importante

Os passos seguintes para criar a ligação SSH ao nó do Windows Server a partir de outro nó só podem ser usados se tiver criado o seu cluster AKS usando a CLI do Azure com o parâmetro --generate-ssh-keys. Se você quiser usar suas próprias chaves SSH, você pode usar o az aks update para gerenciar chaves SSH em um cluster AKS existente. Para obter mais informações, consulte gerenciar o acesso ao nó SSH.

Nota

Se o nó proxy do Linux estiver inativo ou não estiver a responder, use o método Azure Bastion para se conectar.

  1. Use o comando kubectl debug para iniciar um contentor privilegiado no nó proxy (Linux) e conectar-se a ele.

    kubectl debug node/aks-nodepool1-37663765-vmss000000 -it --image=mcr.microsoft.com/cbl-mariner/busybox:2.0

    Saída de exemplo:

    Creating debugging pod node-debugger-aks-nodepool1-37663765-vmss000000-bkmmx with container debugger on node aks-nodepool1-37663765-vmss000000.
If you don't see a command prompt, try pressing enter.
root@aks-nodepool1-37663765-vmss000000:/#

  2. Abra uma nova janela do terminal e use o kubectl get pods comando para obter o nome do pod iniciado por kubectl debug.

    kubectl get pods

    Saída de exemplo:

    NAME                                                    READY   STATUS    RESTARTS   AGE
node-debugger-aks-nodepool1-37663765-vmss000000-bkmmx   1/1     Running   0          21s

    Na saída de exemplo, node-debugger-aks-nodepool1-37663765-vmss000000-bkmmx é o nome do pod iniciado por kubectl debug.

  3. Use o kubectl port-forward comando para abrir uma conexão com o pod implantado:

    kubectl port-forward node-debugger-aks-nodepool1-37663765-vmss000000-bkmmx 2022:22

    Saída de exemplo:

    Forwarding from 127.0.0.1:2022 -> 22
Forwarding from [::1]:2022 -> 22

    O exemplo anterior começa a encaminhar o tráfego de rede da porta 2022 no computador de desenvolvimento para a porta 22 no pod implantado. Ao usar kubectl port-forward para abrir uma conexão e encaminhar o tráfego de rede, a conexão permanece aberta até que você pare o kubectl port-forward comando.

  4. Abra um novo terminal e execute o comando kubectl get nodes para mostrar o endereço IP interno do nó do Windows Server:

    kubectl get no -o custom-columns=NAME:metadata.name,'INTERNAL_IP:status.addresses[?(@.type == \"InternalIP\")].address'

    Saída de exemplo:

    NAME                                INTERNAL_IP
aks-nodepool1-19409214-vmss000003   10.224.0.8

    No exemplo anterior, 10.224.0.62 é o endereço IP interno do nó do Windows Server.

  5. Crie uma ligação SSH com o nodo do Windows Server usando o endereço IP interno e conecte-se à porta 22 através da porta 2022 no seu computador de desenvolvimento. O nome de usuário padrão para nós AKS é azureuser. Aceite o prompt para continuar com a conexão. Em seguida, você receberá o prompt bash do nó do Windows Server:

    ssh -o 'ProxyCommand ssh -p 2022 -W %h:%p azureuser@127.0.0.1' azureuser@10.224.0.62

    Saída de exemplo:

    The authenticity of host '10.224.0.62 (10.224.0.62)' can't be established.
ECDSA key fingerprint is SHA256:1234567890abcdefghijklmnopqrstuvwxyzABCDEFG.
Are you sure you want to continue connecting (yes/no)? yes

    Nota

    Se preferir usar a autenticação por senha, inclua o parâmetro -o PreferredAuthentications=password. Por exemplo:

     ssh -o 'ProxyCommand ssh -p 2022 -W %h:%p azureuser@127.0.0.1' -o PreferredAuthentications=password azureuser@10.224.0.62

Usar um contêiner de processo de host para acessar o nó do Windows

  1. Execute o seguinte script para criar hostprocess.yaml. No script, substitua AKSWINDOWSNODENAME pelo nome do nó AKS Windows.

    Esta especificação usa a imagem base nanoserver. A imagem base não tem PowerShell, mas como é executada como um contêiner de processo de host (HPC), o PowerShell está disponível na VM subjacente.

    apiVersion: v1
kind: Pod
metadata:
  labels:
    pod: hpc
  name: hpc
spec:
  securityContext:
    windowsOptions:
      hostProcess: true
      runAsUserName: "NT AUTHORITY\\SYSTEM"
  hostNetwork: true
  containers:
    - name: hpc
      image: mcr.microsoft.com/windows/nanoserver:ltsc2022 # Use nanoserver:1809 for WS2019
      command:
        - powershell.exe
        - -Command
        - "Start-Sleep 2147483"
      imagePullPolicy: IfNotPresent
  nodeSelector:
    kubernetes.io/os: windows
    kubernetes.io/hostname: AKSWINDOWSNODENAME
  tolerations:
    - effect: NoSchedule
      key: node.kubernetes.io/unschedulable
      operator: Exists
    - effect: NoSchedule
      key: node.kubernetes.io/network-unavailable
      operator: Exists
    - effect: NoExecute
      key: node.kubernetes.io/unreachable
      operator: Exists

  2. Corra kubectl apply -f hostprocess.yaml para implementar o HPC no nó especificado do Windows.

  3. Utilize kubectl exec -it [HPC-POD-NAME] -- powershell.

  4. Você pode executar qualquer comando do PowerShell dentro do contêiner HPC para acessar o nó do Windows.

Nota

Você precisa mudar a pasta raiz para C:\ dentro do contêiner HPC para aceder aos ficheiros no nó do Windows.

SSH usando o Azure Bastion para Windows

Se o nó de proxy do Linux não estiver acessível, usar o Azure Bastion como proxy é uma alternativa. Esse método requer que você configure um host do Azure Bastion para a rede virtual na qual o cluster reside. Consulte Conectar-se com o Azure Bastion para obter mais detalhes.

SSH usando IPs privados da API AKS

Se você não tiver acesso à API do Kubernetes, poderá obter acesso a propriedades como Node IP e Node Name através da API do pool de agentes do AKS (disponível em versões 07-01-2024 estáveis ou superiores) para se conectar aos nós do AKS.

Criar uma conexão shell interativo com um nó usando o endereço IP

Por conveniência, os nós AKS são expostos na rede virtual do cluster através de endereços IP privados. No entanto, você precisa estar na rede virtual do cluster para aceder ao nó via SSH. Se ainda não tiveres um ambiente configurado, podes usar o Azure Bastion para estabelecer um proxy a partir do qual possas aceder aos nós do cluster através de SSH. Verifique se o Azure Bastion está implantado na mesma rede virtual que o cluster.

  1. Obtenha IPs privados usando o az aks machine list comando, direcionando todas as VMs em um pool de nós específico com o --nodepool-name sinalizador.

    az aks machine list --resource-group myResourceGroup  --cluster-name myAKSCluster --nodepool-name nodepool1 -o table

    A seguinte saída de exemplo mostra os endereços IP internos de todos os nós do pool de nós:

    Name                               Ip           Family
---------------------------------  -----------  -----------
aks-nodepool1-33555069-vmss000000  10.224.0.5   IPv4
aks-nodepool1-33555069-vmss000001  10.224.0.6   IPv4
aks-nodepool1-33555069-vmss000002  10.224.0.4   IPv4

    Para direcionar um nó específico dentro do pool de nós, use o --machine-name flag:

    az aks machine show --cluster-name myAKScluster --nodepool-name nodepool1 -g myResourceGroup --machine-name aks-nodepool1-33555069-vmss000000 -o table

    O exemplo de saída a seguir mostra o endereço IP interno de todos os nós especificados:

    Name                               Ip         Family
---------------------------------  -----------  -----------
aks-nodepool1-33555069-vmss000000  10.224.0.5   IPv4

  2. SSH para o nó usando o endereço IP privado obtido na etapa anterior. Esta etapa é aplicável apenas para máquinas Linux. Para máquinas Windows, consulte Conectar-se com o Azure Bastion.

    ssh -i /path/to/private_key.pem azureuser@10.224.0.33

Próximos passos

Se precisar de mais dados de solução de problemas, você pode visualizar os logs do kubelet ou os logs do plano de controle do Kubernetes.

Para saber mais sobre como gerenciar suas chaves SSH, consulte Gerenciar configuração SSH.

  • Last updated on