Как получить SSH-пароль для виртуальных машин Supervisor Control Plane в инфраструктуре VMware vSphere

Supervisor Control Plane — это управляющий уровень встроенного Kubernetes (Supervisor Cluster) в решении VMware vSphere with Tanzu (ранее vSphere with Kubernetes). Он развёрнут как три виртуальные машины (Supervisor Control Plane VMs), которые выполняют контроль над кластером Kubernetes, включая etcd, API-сервер, контроллеры и планировщик. Важнейшие функции этих виртуальных машин:

  • Интеграция с инфраструктурой vSphere: Supervisor Control Plane взаимодействует с ресурсами ESX-хостов — CPU, память, сеть, хранилище — и позволяет запускать контейнеры напрямую на гипервизоре (vSphere Pods).
  • API-доступ: администраторы управляют кластерами через интерфейс vSphere Client и API vSphere with Tanzu, а разработчики — через kubectl.
  • Высокая доступность: обеспечивается трёхкомпонентной архитектурой. Если один узел выходит из строя, другие продолжают работу.

Полезный трюк — как получить SSH-пароль для Supervisor Control Plane VM

Есть простой способ получить доступ по SSH для виртуальных машин, входящих в состав Supervisor Control Plane:

  1. Подключитесь по SSH к виртуальному модулю сервера vCenter под пользователем root.
  2. Выполните скрипт:

/usr/lib/vmware-wcp/decryptK8Pwd.py

Скрипт выведет IP-адрес (обычно FIP, то есть «floating IP») и автоматически сгенерированный пароль. После этого вы можете подключиться по SSH к Supervisor Control Plane VM как root@<FIP> с полученным паролем.

Важно! Доступ к этим ВМ следует использовать только для диагностики и устранения проблем — любые изменения в них (особенно без одобрения от поддержки VMware) могут привести к нарушению работоспособности Supervisor-кластера, и поддержка может потребовать его полного развертывания заново.

Полезные рекомендации и предосторожения

  • Скрипт /usr/lib/vmware-wcp/decryptK8Pwd.py извлекает пароль из базы данных vCenter. Он удобен для быстрого доступа, особенно при отладке сетевых или других проблем с Supervisor VM.
  • Убедитесь, что FIP действительно доступен и корректно маршрутизируется. При сбое etcd FIP не назначится, и придётся использовать реальный IP-адрес интерфейса (например, eth0). Также при смене FIP удалите старую запись из known_hosts — сертификаты могут изменяться при «плавании» IP.
  • Используйте доступ только для анализа, чтения логов и выполнения команд kubectl logs/get/describe.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *