Подключение к узлам кластера Службы Azure Kubernetes (AKS) для обслуживания или устранения неполадок
На протяжении всего жизненного цикла кластера Служба Azure Kubernetes (AKS) вам в конечном итоге потребуется напрямую получить доступ к узлу AKS. Этот доступ может быть для операций обслуживания, сбора журналов или устранения неполадок.
Вы обращаетесь к узлу через проверку подлинности, какие методы зависят от операционной системы узла и метода подключения. Вы безопасно проходите проверку подлинности на узлах AKS Linux и Windows с помощью двух вариантов, рассмотренных в этой статье. Для одного из них требуется доступ к API Kubernetes, а другой — через API ARM AKS, который предоставляет прямые частные IP-адреса. По соображениям безопасности узлы AKS не предоставляются в Интернете. Вместо этого для подключения непосредственно к любым узлам AKS необходимо использовать kubectl debug
частный IP-адрес узла или его частный IP-адрес.
Доступ к узлам с помощью API Kubernetes
Для этого метода требуется использование kubectl debug
команды.
Подготовка к работе
В этом руководстве показано, как создать подключение к узлу AKS и обновить ключ SSH кластера AKS. Чтобы выполнить действия, необходимо использовать Azure CLI, поддерживающую версию 2.0.64 или более позднюю. Чтобы узнать номер версии, выполните команду az --version
. Если вам необходимо выполнить установку или обновление, см. статью Установка Azure CLI 2.0.
Выполните эти действия, если у вас нет ключа SSH. Создайте ключ SSH в зависимости от образа ОС узла, для macOS и Linux или Windows. Обязательно сохраните пару ключей в формате OpenSSH, избегайте неподдерживаемых форматов, таких как .ppk
. Затем перейдите к управлению конфигурацией SSH, чтобы добавить ключ в кластер.
Linux и macOS
Пользователи Linux и macOS могут получить доступ к своему узлу с помощью kubectl debug
или частного IP-адреса. Пользователи Windows должны перейти к разделу прокси-сервера Windows Server для обходного решения по протоколу SSH через прокси-сервер.
Подключение с помощью отладки kubectl
Чтобы создать интерактивное подключение оболочки, используйте kubectl debug
команду для запуска привилегированного контейнера на узле.
Чтобы вывести список узлов, используйте
kubectl get nodes
команду:kubectl get nodes -o wide
Образец вывода:
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
kubectl debug
Используйте команду, чтобы запустить привилегированный контейнер на узле и подключиться к нему.kubectl debug node/aks-nodepool1-37663765-vmss000000 -it --image=mcr.microsoft.com/cbl-mariner/busybox:2.0
Образец вывода:
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:/#
Теперь у вас есть доступ к узлу через привилегированный контейнер в качестве модуля pod отладки.
Примечание.
Вы можете взаимодействовать с сеансом узла, запустив
chroot /host
из привилегированного контейнера.
Выход из режима отладки kubectl
Когда вы закончите работу с узлом, введите exit
команду, чтобы завершить интерактивный сеанс оболочки. После закрытия интерактивного сеанса контейнера удалите модуль pod отладки, используемый с kubectl delete pod
.
kubectl delete pod node-debugger-aks-nodepool1-37663765-vmss000000-bkmmx
Подключение прокси-сервера Windows Server для SSH
Выполните следующие действия в качестве обходного решения для подключения к SSH на узле Windows Server.
Создание прокси-сервера
Сейчас подключиться напрямую к узлу Windows Server с помощью kubectl debug
невозможно. Вместо этого необходимо сначала подключиться к другому узлу в кластере kubectl
, а затем подключиться к узлу Windows Server с этого узла с помощью SSH.
Чтобы подключиться к другому узлу в кластере kubectl debug
, используйте команду. Дополнительные сведения см. в разделе kubectl. Создайте подключение SSH к узлу Windows Server с другого узла с помощью ключей SSH, предоставленных при создании кластера AKS и внутреннего IP-адреса узла Windows Server.
Внимание
Следующие действия по созданию подключения SSH к узлу Windows Server с другого узла можно использовать только в том случае, если вы создали кластер AKS с помощью Azure CLI с параметром --generate-ssh-keys
. Если вы хотите использовать собственные ключи SSH, вы можете управлять az aks update
ключами SSH в существующем кластере AKS. Дополнительные сведения см. в статье об управлении доступом к узлу SSH.
Примечание.
Если прокси-узел Linux отключен или не отвечает, используйте вместо этого метод Бастиона Azure.
kubectl debug
Используйте команду, чтобы запустить привилегированный контейнер на узле прокси-сервера (Linux) и подключиться к нему.kubectl debug node/aks-nodepool1-37663765-vmss000000 -it --image=mcr.microsoft.com/cbl-mariner/busybox:2.0
Образец вывода:
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:/#
Откройте новое окно терминала и используйте
kubectl get pods
команду, чтобы получить имя модуля pod, запущенногоkubectl debug
.kubectl get pods
Образец вывода:
NAME READY STATUS RESTARTS AGE node-debugger-aks-nodepool1-37663765-vmss000000-bkmmx 1/1 Running 0 21s
В примере выходных данных node-debugger-aks-nodepool1-37663765-vmss0000000-bkmmx — это имя модуля pod, запущенного с
kubectl debug
.kubectl port-forward
Используйте команду, чтобы открыть подключение к развернутой pod:kubectl port-forward node-debugger-aks-nodepool1-37663765-vmss000000-bkmmx 2022:22
Образец вывода:
Forwarding from 127.0.0.1:2022 -> 22 Forwarding from [::1]:2022 -> 22
В предыдущем примере начинается переадресация сетевого трафика с порта
2022
на компьютере разработки на порт22
в развернутом модуле pod. При использованииkubectl port-forward
для установки подключения и пересылки сетевого трафика подключение остается открытым до тех пор, пока вы не остановите командуkubectl port-forward
.Откройте новый терминал и выполните команду
kubectl get nodes
, чтобы отобразить внутренний IP-адрес узла Windows Server:kubectl get no -o custom-columns=NAME:metadata.name,'INTERNAL_IP:status.addresses[?(@.type == \"InternalIP\")].address'
Образец вывода:
NAME INTERNAL_IP aks-nodepool1-19409214-vmss000003 10.224.0.8
В предыдущем примере 10.224.0.62 — это внутренний IP-адрес узла Windows Server.
Создайте SSH-подключение к узлу Windows Server с помощью внутреннего IP-адреса и подключитесь к порту через порт
22
2022
на компьютере разработки. Имя пользователя по умолчанию для узлов AKS — azureuser. Примите приглашение, чтобы продолжить подключение. Затем вы получите запрос bash узла Windows Server:ssh -o 'ProxyCommand ssh -p 2022 -W %h:%p azureuser@127.0.0.1' azureuser@10.224.0.62
Образец вывода:
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
Примечание.
Если вы предпочитаете использовать проверку подлинности паролей, включите параметр
-o PreferredAuthentications=password
. Например:ssh -o 'ProxyCommand ssh -p 2022 -W %h:%p azureuser@127.0.0.1' -o PreferredAuthentications=password azureuser@10.224.0.62
Использование контейнера процесса узла для доступа к узлу Windows
Создайте
hostprocess.yaml
следующее содержимое и заменитеAKSWINDOWSNODENAME
именем узла Windows AKS.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/servercore:ltsc2022 # Use servercore: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
Запустите
kubectl apply -f hostprocess.yaml
, чтобы развернуть контейнер процесса узла Windows (HPC) на указанном узле Windows.Используйте
kubectl exec -it [HPC-POD-NAME] -- powershell
.Для доступа к узлу Windows можно выполнять любые команды PowerShell в контейнере HPC.
Примечание.
Для доступа к файлам на узле Windows необходимо переключить корневую папку C:\
в контейнер HPC.
SSH с помощью Бастиона Azure для Windows
Если ваш прокси-узел Linux недоступен, использование Бастиона Azure в качестве прокси-сервера является альтернативой. Для этого метода требуется настроить узел Бастиона Azure для виртуальной сети, в которой находится кластер. Дополнительные сведения см. в статье "Подключение к Бастиону Azure".
SSH с помощью частных IP-адресов из API AKS (предварительная версия)
Если у вас нет доступа к API Kubernetes, вы можете получить доступ к таким свойствам, как Node IP
Node Name
API пула агентов AKS (предварительная версия) (доступно в предварительных версиях или более поздних версиях 07-02-2023
), чтобы подключиться к узлам AKS.
Внимание
Предварительные версии функций AKS доступны на уровне самообслуживания. Предварительные версии предоставляются "как есть" и "при наличии". На них не распространяются соглашения об уровне обслуживания и ограниченная гарантия. Предварительные версии AKS предоставляются с частичной клиентской поддержкой по мере возможности. Следовательно, эти функции не предназначены для использования в рабочей среде. Дополнительные сведения доступны в следующих статьях поддержки.
Создание интерактивного подключения оболочки к узлу с помощью IP-адреса
Для удобства узлы AKS предоставляются в виртуальной сети кластера через частные IP-адреса. Однако вам нужно быть в виртуальной сети кластера для SSH в узле. Если у вас еще нет настроенной среды, можно использовать Бастион Azure для создания прокси-сервера, из которого можно использовать SSH для узлов кластера. Убедитесь, что бастион Azure развернут в той же виртуальной сети, что и кластер.
Получите частные IP-адреса с помощью
az aks machine list
команды, нацелив все виртуальные машины в определенном пуле узлов с флагом--nodepool-name
.az aks machine list --resource-group myResourceGroup --cluster-name myAKSCluster --nodepool-name nodepool1 -o table
В следующем примере выходных данных показаны внутренние IP-адреса всех узлов в пуле узлов:
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
Чтобы нацелить определенный узел в пуле узлов, используйте
--machine-name
флаг:az aks machine show --cluster-name myAKScluster --nodepool-name nodepool1 -g myResourceGroup --machine-name aks-nodepool1-33555069-vmss000000 -o table
В следующем примере выходных данных показан внутренний IP-адрес всего указанного узла:
Name Ip Family --------------------------------- ----------- ----------- aks-nodepool1-33555069-vmss000000 10.224.0.5 IPv4
SSH на узел, используя частный IP-адрес, полученный на предыдущем шаге. Этот шаг применим только для компьютеров Linux. Сведения о компьютерах Windows см. в статье "Подключение с помощью Бастиона Azure".
ssh -i /path/to/private_key.pem azureuser@10.224.0.33
Следующие шаги
Если вам нужны дополнительные сведения об устранении неполадок, вы можете просмотреть журналы kubelet или просмотреть журналы плоскости управления Kubernetes.
Сведения об управлении ключами SSH см. в статье "Управление конфигурацией SSH".
Azure Kubernetes Service