Легко. Берем и делаем.

Терминология

Server Message Block (SMB) - сетевой протокол прикладного уровня для удалённого доступа к файлам, принтерам и другим сетевым ресурсам. Часто используется в Windows сетях.

Container Storage Interface (CSI) - стандарт для предоставления блочного и файлового хранилища рабочим нагрузкам (контейнерам) в системах оркестрации контейнеров, таких как Kubernetes. Не смотря на то, что использоваться оно может не только в Kubernetes, нас интересует только это.

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

Для начала следует разобраться с тем, что нового произошло с тех времен, как я рассказывал о поднятии кластера с 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.

Дамы и господа, Docker всё, расходимся. Шутка.

А если серьезно, то у нас есть примерно год, чтобы избавиться от Docker в качестве среды исполнения контейнеров в Kubernetes. В версии 1.20 (которая выйдет уже совсем скоро) будет объявлен устаревшим Docker. А в версии 1.23 его поддержка будет удалена вовсе. Чтобы в будущем не было проблем с обновлением кластера, надо потрудиться уже сейчас.

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

Доброго времени суток, уважаемый читатель.

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

  1. kubelet
  2. kubeproxy
  3. flannel (или что-то другое, что обеспечивает работу сети)

Kubelet запускается в виде Windows-службы, тут всё просто и по сути ничем не отличается от того, как это происходит на Linux узлах. А вот с kubeproxy и flannel всё куда интереснее. Ранее я писал, как сделать так, чтобы они запускались в виде Windows-служб; но на Linux узлах эти 2 компонента запускаются с помощью DaemonSets.

Всем привет. Сегодня я хочу рассказать о том, как установить traefik в свой собственный on-premise kubernetes кластер в качестве Ingress Controller.

Traefik может работать в Kubernetes в 2 режимах:

  1. kubernetesingress - это когда он будет мониторить стандартные объекты с kind: Ingress с строить маршруты на базе их
  2. kubernetescrd - это когда для описания маршрутов надо будет создавать объкты kind: IngressRoute. Этот способ более гибкий, однако при переходе на другой Ingress Controller, вам полностью придется переписать Ingress правила. Кроме того, с точки зрения kubernetes, такой способ развертывания не является Ingress Controller'ом, но нам это не так важно. Важно что мы получим тот же результат.

Мы будем разворачивать и то, и то. Кроме того, мы еще и Let's Encrypt подключим.

Если есть необходимость примотнировать SMB шару внутрь Windows контейнера, то можно воспользоваться вот такой штукой.

Если коротко, то для начала надо настроить сами Windows узлы в кластере. Делается это путем копирования папки сюда: C:\usr\libexec\kubernetes\kubelet-plugins\volume\exec\

Затем создать секрет с логином и паролем (в виде base-64):

apiVersion: v1
kind: Secret
metadata:
  name: smb-secret
data:
  password: cGFzc3dvcmQ=
  username: dXNlcm5hbWU=
type: microsoft.com/smb.cmd

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

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 файлов:

Поместив все файлы на 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