Смена сертификатов Kubernetes с помощью обработчика AKS в Azure Stack Hub

В этом документе содержатся рекомендации по смене сертификатов в существующем кластере обработчика AKS и рекомендации по внедрению aks-engine rotate-certs в качестве инструмента.

Предварительные требования

В этом руководстве предполагается, что вы уже развернули кластер с помощью обработчика AKS и кластер находится в работоспособном состоянии.

Планирование смены сертификатов

При использовании этой функции следует учитывать, что уровень управления Kubernetes будет недоступен на этапах обновления, проверки и перезапуска. Спланируйте эту операцию обслуживания соответствующим образом. Кроме того, запланируйте выполнение этой операции в промежуточной среде с конфигурацией, равной рабочей среде, прежде чем выполнять попытку в рабочей среде.

Прежде чем пытаться выполнить эту операцию, ознакомьтесь со следующими рекомендациями.

Примечание

Для AKSe версии 0.75.3 и выше команды для смены сертификатов начинаются с aks-engine-azurestack , а не aks-engineс .

  • Вам потребуется доступ к модели API (apimodel.json), созданной командами aks-engine deploy или aks-engine generate. По умолчанию этот файл помещается в относительный каталог, _output/<clustername>/например .

  • Операция aks-engine rotate-certs приводит к простою сервера API.

  • aks-engine rotate-certs ожидает модель API, которая соответствует текущему состоянию кластера. aks-engine rotate-certs выполняет удаленные команды на узлах кластера и использует сведения о модели API для установки безопасного SSH-подключения. aks-engine rotate-certs также использует некоторые ресурсы для именования в соответствии с исходным aks-engine развертыванием, например, виртуальные машины должны следовать именам, предоставляемым aks-engine.

  • aks-engine rotate-certs зависит от рабочего подключения к уровню управления кластером во время смены сертификата:

    • Для проверки каждого этапа процесса.
    • Перезапуск или повторное создание ресурсов кластера, таких как модули pod kube-system и маркеры учетной записи службы.

    При смене сертификатов кластера в виртуальной сети, закрытой для внешнего доступа, необходимо запустить aks-engine rotate-certs с виртуальной машины узла с сетевым доступом к уровню управления, например с виртуальной машины Jumpbox, которая находится в той же виртуальной сети, что и виртуальные машины master.

  • Если вы используете aks-engine rotate-certs в рабочей среде, рекомендуется провести проверку смены сертификатов в кластере, который был создан с теми же спецификациями. То есть перед сменой сертификата кластер создается с той же конфигурацией кластера, той же версией программы командной строки обработчика AKS и тем же набором включенных надстроек, что и рабочий кластер. Обработчик AKS поддерживает различные конфигурации кластера, и степень комплексного тестирования, выполняемого командой обработчика AKS, не может практически охватывать все возможные конфигурации. Поэтому рекомендуется убедиться, что в промежуточной среде работает aks-engine rotate-certs определенная конфигурация кластера, прежде чем пытаться выполнить операцию в рабочем кластере.

  • aks-engine rotate-certsне гарантирует обратную совместимость. Если вы развернули с aks-engine версии 0.60.x, следует предпочесть выполнение процесса смены сертификатов с версией 0.60.x.

  • Получение нового набора сертификатов из Key Vault на данный момент не поддерживается.

  • Используйте надежное сетевое подключение. aks-engine rotate-certs требует выполнения нескольких удаленных команд, которые могут быть подвержены потенциальным сбоям, главным образом, если подключение к узлам кластера не является надежным. Запуск aks-engine rotate-certs из виртуальной машины, работающей на целевой метке Azure Stack, может сократить количество временных проблем.

Параметры

Параметр Обязательно Описание
--api-model да Относительный путь к модели API (определение кластера), которая объявляет ожидаемую конфигурацию кластера.
--ssh-host да Полное доменное имя (FQDN) или IP-адрес прослушивателя SSH, доступного ко всем узлам в кластере.
--linux-ssh-private-key да Путь к допустимому закрытому ключу SSH для доступа к узлам Linux кластера.
--location да Расположение Azure, в котором развернут кластер.
--subscription-id да Подписка Azure, в которой развернута инфраструктура кластера.
--resource-group да Группа ресурсов Azure, в которой развернута инфраструктура кластера.
--client-id зависит Идентификатор клиента субъекта-службы. Требуется, если для метода проверки подлинности задано значение client_secret или client_certificate.
--client-secret зависит Секрет клиента субъекта-службы. Требуется, если для метода проверки подлинности задано значение client_secret.
--azure-env зависит Имя целевого облака. Необязательно, если целевое облако — AzureCloud.
--certificate-profile нет Относительный путь к JSON-файлу, который содержит новый набор сертификатов.
--force нет Принудительное выполнение, даже если сервер API не отвечает.

Простые действия по смене сертификатов

Для обработчика AKS 0.75.3 и более поздних версий после прочтения всех требований выполните команду aks-engine-azurestack rotate-certs с соответствующими аргументами (см. ниже).

Для обработчика AKS версии 0.73.0 и более поздних версий после прочтения всех требований выполните команду aks-engine rotate-certs с соответствующими аргументами:

./bin/aks-engine rotate-certs \
  --location <resource-group-location> \
  --api-model <generated-apimodel.json> \
  --linux-ssh-private-key <private-SSH-key> \
  --ssh-host <apiserver-URI> \
  --resource-group <resource-group-name> \
  --client-id <service-principal-id> \
  --client-secret <service-principal-secret> \
  --subscription-id <subscription-id> \
  --azure-env <cloud-name>

Пример:

./bin/aks-engine rotate-certs \
  --location "westus2" \
  --api-model "_output/my-cluster/apimodel.json" \
  --linux-ssh-private-key "~/.ssh/id_rsa" \
  --ssh-host "my-cluster.westus2.cloudapp.azure.com"\
  --resource-group "my-cluster" \
  --client-id "12345678-XXXX-YYYY-ZZZZ-1234567890ab" \
  --client-secret "12345678-XXXX-YYYY-ZZZZ-1234567890ab" \
  --subscription-id "12345678-XXXX-YYYY-ZZZZ-1234567890ab" \
  --azure-env "AzureStackCloud" # optional if targeting AzureCloud

Смена front-proxy сертификатов

Примечание

Для AKSe версии 0.75.3 и выше команды для смены сертификатов начинаются с aks-engine-azurestack , а не aks-engineс .

Обработчик AKS создает отдельную PKI для в front-proxy рамках процесса начальной загрузки узла и доставляет их на все узлы через etcd. Чтобы эффективно использовать эту функцию повторно, необходимо заменить сертификаты, rotate-certs хранящиеся в etcd. Срок front-proxy действия сертификатов истекает через 30 лет. aks-engine rotate-certs поворачивает сертификаты переднего прокси-сервера.

Устранение неполадок

Примечание

Для AKSe версии 0.75.3 и выше команды для смены сертификатов начинаются с aks-engine-azurestack , а не aks-engineс .

Если процесс смены сертификатов останавливается до завершения из-за сбоя или временной проблемы, например сетевого подключения, его можно запустить повторно aks-engine rotate-certs с помощью флага --force .

Также обратите внимание, что aks-engine rotate-certs записывает выходные данные каждого шага в файл /var/log/azure/rotate-certs.log (Linux) и c:\\k\\rotate-certs.log (Windows).

Дополнительные сведения о том, что происходит под капотом при выполнении этой операции, или о дальнейшей настройке см. в разделе Под капотом.

Дальнейшие действия