В предыдущих сериях...

Для начала следует разобраться с тем, что нового произошло с тех времен, как я рассказывал о поднятии кластера с Windows узлами:

1. актуальной версией кубернетеса является 1.22;
2. в качестве CNI кроме Flannel можно использовать еще и Calico;
3. вышел Windows Server 2022;
4. появилась возможность использовать CRI-containerD в том числе и в режиме HostProcess.

Немного слов про Docker

Мы не будем его использовать в контексте Kubernetes. Нас теперь интересует только ContainerD. Тем не менее удалять Docker рано, т.к. он всё еще нужен для создания образов.

Теперь перейдем к самому вкусному

Я расскажу как настроить Kubernetes кластер с узлами на базе Windows Server 2022 и CRI-ContainerD. В качетсве CNI для кластера будет Calico.

Создаем учетную запись:

New-ADServiceAccount $serviceaccount `
  -DNSHostName $hostname `
  -PrincipalsAllowedToRetrieveManagedPassword $principals

Здесь:

• $serviceaccount - имя учетной записи (gMSA)
• $hostname - $serviceaccount.domain.com (имя учетной записи + имя домена)
• $principals - Список компьютеров, имеющих права на получение пароля от очетной записи

Теперь ее необходимо установить на всех Windows узлах в кластере. Подключаемся к каждому узлу и выполняем:

Add-WindowsFeature RSAT-AD-PowerShell
Install-ADServiceAccount -Identity $serviceaccount
Test-ADServiceAccount -Identity $serviceaccount

На github есть готовый скрипт, для развертывания всего необходимого.

Нам надо скачать 5 файлов:

• .helpers.sh
• create-signed-cert.sh
• deploy-gmsa-webhook.sh
• gmsa-crd.yml
• gmsa-webhook.yml.tpl

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

./deploy-gmsa-webhook.sh --file deploy-gmsa.yml --overwrite --tolerate-master

Group Managed Service Account

Для начала следует рассказать что же такое gMSA и зачем оно нам надо в контексте Kubernetes.

Сети на базе Windows обычно используют Active Directory (AD) для облегчения проверки подлинности и авторизации между пользователями, компьютерами и другими сетевыми ресурсами. Разработчики корпоративных приложений часто проектируют свои приложения для интеграции AD и работают на серверах, связанных с доменом, чтобы воспользоваться преимуществами интегрированной аутентификации Windows.

Хотя контейнеры Windows не могут быть соединены доменом, они все еще могут использовать идентификаторы домена Active Directory для поддержки различных сценариев проверки подлинности.

Для начала нам необходиом скачать 3 файла:

1. Kubeclustervxlan.json
2. KubeCluster.ps1
3. KubeClusterHelper.psm1

Теперь отредактируем файл Kubeclustervxlan.json

    "ControlPlane" : {  // Contains values associated with Kubernetes control-plane ("Master") node
        "IpAddress" : "kubemasterIP",  // IP address of control-plane ("Master") node
        "Username" : "localadmin",  // Username on control-plane ("Master") node with remote SSH access  
        "KubeadmToken" : "token",  // Kubeadm bootstrap token
        "KubeadmCAHash" : "discovery-token-ca-cert-hash"  // Kubeadm CA key hash
    },

И последние 2 заклинания:

.\KubeCluster.ps1 -ConfigFile .\Kubeclustervxlan.json -install 
.\KubeCluster.ps1 -ConfigFile .\Kubeclustervxlan.json -join

Так же, как и в случае с Linux, будем считать что у нас есть только что установленный Windows Server 2019 (1809). В случае, если это именно 2019, нам вполне достаточно Server Core.

(Add-WindowsFeature Containers).RestartNeeded

Если результатом команды будет Yes, то перезагружаем компьютер.

Далее:

Install-Module DockerMsftProvider -Force
Install-Package Docker -ProviderName DockerMsftProvider -Force

... ```

Введение

Данный проект помогает реализовать TLS подключение к Docker Remote API с аутентификацией по сертификату с проверкой отзыва клиентского сертификата. Операционной системой на сервере является Windows Server 1803+.

Удаленное управление Docker

Для нужд удаленного управления Docker'ом, Docker умеет предоставлять веб-API. Это API может как вовсе не требовать аутентификации (что крайне не рекомендуется), так и использовать аутентификация по сертификату. Проблема заключается в том, что родная аутентификация по сертификату не предусматривает проверку отзыва сертификата. А это может стать проблемой.

Сборка Docker образа

Для сборки образа нам потребуется публичный сертификат центра сертификации (ca.cer), который будет выдавать сертификаты пользователям. Этот сертификат будет установлен в доверенные корневые центры сертификации контейнера, в котором будет запущен наш прокси. Установка его необходима для процедуры проверки сертификата.