Примечание
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
В этом документе представлены рекомендации по ротации сертификатов в существующем кластере AKS Engine и по использованию 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
с виртуальной машины, которая имеет сетевой доступ к контрольной плоскости, например, посреднической виртуальной машины, находящейся в той же виртуальной сети, что и главные виртуальные машины.Если вы используете
aks-engine rotate-certs
в рабочей среде, рекомендуется выполнить тестирование смены сертификатов в кластере, созданном в соответствии с теми же спецификациями. То есть кластер создается с той же конфигурацией кластера, той же версией программы командной строки ядра AKS и тем же набором включенных надстроек, что и рабочий кластер перед выполнением смены сертификатов. Модуль AKS поддерживает различные конфигурации кластера, и степень сквозного тестирования, которую команда AKS engine проводит, не может практически охватывать каждую возможную конфигурацию. Поэтому рекомендуется убедиться, что в промежуточной среде конфигурация конкретного кластера работает с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 кластера. |
--местоположение | да | Расположение Azure, в котором развернут кластер. |
--subscription-id | да | Подписка Azure, в которой развернута инфраструктура кластера. |
--resource-group | да | Группа ресурсов Azure, в которой развернута инфраструктура кластера. |
--client-id | Зависит | Идентификатор клиента служебного субъекта. Требуется, если для метода проверки подлинности задано значение client_secret или client_certificate. |
--секрет-клиента | Зависит | Секрет клиента субъекта-службы. Требуется, если для метода проверки подлинности задано значение client_secret. |
--azure-env | Зависит | Целевое имя облака. Необязательный вариант, если целевое облако — AzureCloud. |
--профиль-сертификата | Нет | Относительный путь к JSON-файлу с новым набором сертификатов. |
--сила | Нет | Принудительное выполнение, даже если сервер API не отвечает. |
Простые шаги для смены сертификатов
Для версий AKS Engine 0.75.3 и выше, после того как вы ознакомились со всеми требованиями , выполните команду aks-engine-azurestack rotate-certs
с соответствующими аргументами (см. ниже).
Для версий AKS Engine 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 "00001111-aaaa-2222-bbbb-3333cccc4444" \
--client-secret "00001111-aaaa-2222-bbbb-3333cccc4444" \
--subscription-id "aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e" \
--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).
Дополнительные сведения о том, что происходит под капотом при выполнении этой операции или для дальнейшей настройки, см. в разделе под.
Дальнейшие действия
- Читайте о движке AKS на Azure Stack Hub