День добрый, Уважаемый!

Еще одна памятка мне самому в будудем о том, как установить и настроить ContainerD.

Этап первый - установка: ``` sudo apt-get update

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

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

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

• .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 для поддержки различных сценариев проверки подлинности.