Tanzu K8s - деплой кластера (HAProxy + vDS)

Сегодня хотелось поделиться опытом настройки и пониманием работы такого managed решения, как VMware Tanzu. На актуальное время достаточно различной информации по архитектуре и практикам использования Tanzu. Поэтому хотелось бы сделать небольшое summary, и продемонстрировать пример настройки такого кластера с нуля. Так скажем собрать чемодан всего необходимого.

В небольшое отступление, стоит отметить что я пойду по самому простому пути и мой сетап будет построен на HAproxy и vDS, без NSX-t (Или его собрата AVI). Так как это дополнительный расход на обслуживание и отдельная лицензия.

Немного теории

Когда только начинаешь погружаться в мир Tanzu, нам представлется не единый как таковой продукт, а несколько вариаций решений. Например, мы имеем:

TKGm (Tanzu Kubernetes Grid Multi-cloud) - решение позволяющие развернуть workload область в различных облаках,
TKGi (Tanzu Kubernetes Grid Integrated) - это решение подходит для использования в своей локальной инфраструктуре, если же у вас активно используется NSX-t.
TKGs (Tanzu Kubernetes Grid Service) - аналогичное решение, но без использования NSX-t, как я и говорил самый простой путь начать использовать Tanzu.

Также стоит отметить различные SaaS продукты - Tanzu Mission Control, Tanzu Mesh, Tanzu Observability и прочее.

Когда мы настраиваем workload control plane (WCP) на наших esxi-хостах объединенных в DRS/HA кластер разворачивается плоскость - Supervisor cluster.

Supervisor кластер состоит из трех виртуальных машин, которые образуют область управления кластером. Также каждом esxi-хосте поднимается дополнительный процесс, по принципу аналогичный kubelet, называется vSpherelet. Ну и container рантайм - CRX (Container Runtime for Exsi).

Выше Supervisor кластера создается более высокая абстракция - Namespace. Namespace в Tanzu схож с логическим объектом - namespace в нативном кубернетес. И нужен для предоставления механизма назначения границ по гресурсам и лимита - CPU/Memory и Storage. По умолчанию создаваемый namespace не имеет каких либо лимитов и желательно их определять, так скажем, на берегу. И благодаря этому объекту мы можем разделять права доступа к каждому проекту.

Внутри каждого namespace, представляется возможность создавать вложенные кластера k8s за счет механизмов Grid-сервиса (TKGS), сделать это можно путем простого обращения в API Grid-cервиса используя манифейст и kubectl.

На практике, если же взглянуть в разрезе vSphere UI, то будет такая матрешка: (Розовым цветом подсвечены вложенные кластера)

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

Прежде чем разворачивать область supervisor кластера, нам нужно выполнить ряд подготовительных работ.

Если идти по поинтам, то нужно сделать:

Собрать DRS/HA кластер
Настоить vDS свитч. И добавить три порт группы:
- Managment - адреса из этого пула будут назначаться на все ноды кластеров для менеджента и управления балансоровкой на HAProxy
- Workload - эта сеть будет использоваться для доступа к сервисам supervisor кластера и TKC нод.
- Frontend - внешняя сетка для подключения сторонних клиентов. Для доступа к рабочим нагрузкам кластера.
Создать Storage политику, под хранение данных
Добавить репозиторий в Content Library

Настройка DRS/HA

Под тестовую лабу я выделил два физических сервера, на их основе и будем создавать кластер. На иконке датацентра кликаем правой кнопкой мыши, и жмакаем на кнопку - New Cluster:

В новом окне настройки кластера включаем опции DRS и HA. А в поле name прописываем имя для нашего кластера.

Далее жмем кнопку Finish, и доживаемся завершения инициализации кластера. После того, дропом просто переносим наши сервера в новый кластер.

В конфигурации кластера, раздел Quickstart, проверяем что все поинты подсвечены зеленым и жмем на - Configure.

Откроется окно с конфигурацией кластера, пункт настройки дестребьютид свитча. Так как у меня свитчи были настроены ранее, я просто ставлю крыжик на опции - настроить позже и жму далее:

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

Настрока vDS свитча

Как я упомянул ранее vDS у меня уже был настроен, в этом поинте мне нужно только добавить три порт группы. Перейдем в настройки сети на vSphere UI, выбираем наш свитч и жмем на добавление новой порт группы:

Перед нами откроется новое окно конфигурации из 3х поинтов. В первом разделе мы указываем имя для порт группы.

Во втором разделе, с настройками порт группы указываем нужны vlan.

В окне третьего раздела проверяем настройку и жмем на Finish.

Эти же действия выполняем для добавления workload и frontend портгруппы. И по итогу будем иметь:

Создание StoragePolicy

Под постоянное хранение объектов Tanzu у меня также выделен отдельный датастор, на данном этапе нам остается только создать политику хранения.

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

В новом окне проваливаемся в подраздел с категориями, и жмем на добавление новой категории:

Откроется раздел создания категории, в полях заполнения прописываем - имя категории. И ставим крыжики на объектах, с которыми хотим ассоциировать эту категорию:

Вернемся в раздел с тегами, и создаем новый тег: Здесь также указываем имя, и ранее созданную категорию.

После создания нового тега, нам нужно его навесить на целевой датастор. Для этого проваливаемся в раздел с датасторами, выбираем нужный датастор из списка.

И вешаем на него тег:

Остается только создать новую StoragePolicy, идем в раздел с политиками и создаем новую полиси. В первом разделе просто указываем имя политики:

На втором разделе нужно поставить галку, в правилах выбора датастора. В нашем случаи это на основе тегов:

Следующий поинт для выбора тегов. Нам нужно выбрать ранее созданную категорию и тег:

Если все настроено корретно следующим этапом отобразиться список доступных нам датасторов:

Жмем далее и завершаем создаение политики.

Добавление репозитория в Content library

В раздел Content Library нужно добавить репозиторий, из которого будут стягиваться образа для создания кластеров. Идем в раздел Content Libraries, и жмем на кнопку создания новой библиотеки.

В конфигурации нужно выбрать пункт - Subscribed content library, а в поле для url вставить ссылку: https://wp-content.vmware.com/v2/latest/lib.json

В третьем пункте настройки не нужно указываеть security policy. При первой попытке настроить tanzu я столкнулся с такой проблемой, когда вложенные кластера не хотели заводиться из за отсутствия образов. Хотя они были выкачаны ранее. Решить эту проблему удалось путем создания новой политики, без применения security policy. Поэтому тут просто жмем далее:

В пункте добавления нового стораджа, просто кликаем на наш сторадж из списка и жмем далее:

Сверяем настройки и жмем на кнопку - завершить.

Запустим синхронизацию созданного репозитория, и продолжим конфигурацию далее:

Пока дойдем до этапа создания кластеров, все уже синканется.

Настройка TKGs

Процесс настройки платформы TKGs занимает буквально два этапа:

Деплой виртуальной машины с HAProxy
И включение Workload managment

Далее vSphere все выполнил за нас =)

Деплой HAProxy

Развернуть заготовленный образ с HAProxy достаточно просто. Но могут быть нюансы связанные с определением параметров сети, где я не раз ошибался и путался. Поэтому для нашего же удобства будет хорошим шагов определить параметры сетевых настроек, так скажем на берегу.

Итак, основные сабнеты:

10.200.70.0/24 - сетка для менеджмент скоупа. Адреса из этого пула будут назначаться на ноды supervisor кластера и один IP отойдет на Dataplane HAProxy.
- Под dataplane HAProxy, я выделил - 10.200.70.43/24
- Остальные адреса, начиная с 10.200.70.45 будут присваиваться нодам supervisor кластера.
10.200.71.0/24 - сетка под рабочие нагрузки, это значит что всем объектам supervisor кластера будут назначатся адреса из этого диапозона.
- Для взаимосвязи HAProxy и объектов плоскости supervisor кластера, для HAProxy я выделяю IP - 10.200.71.43/24
- Также выделяю диапозон под кластер ноды начиная с 10.200.71.45/42
10.200.72.0/24 - сегмент для доступа к кластерам из вне.
- Для HAProxy выделяю ip - 10.200.72.43/24
- И под диапазон виртуальных IP отдаю сетку - 10.200.72.128/25. Адреса из этого пула будут назначатся как плавающий IP, для доступа к namespace.

В документации vmware есть несколько диаграмм для примера. Для своего же понимания, на основную диаграмму я наложил все IPшники:

Надесь стало более-менее яснее. Теперь идем на github-репозиторий и качаем ova-образ с haproxy. Теперь этот образ нужно задеплоить в кластер:

Подключаем скачанный файл:

Указываем имя для виртуальной машины, и ее размещение в датацентре:

В выборе компьют ресурсов, нужно указать кластер созданный для Tanzu:

Затем соглашаемся с лицензией, и идем в поинт с выбором конфигурации. В этом сетапе нужно выбрать конфигурацию с использованием Frontend Network.

В пункте настройки сети, нужно проставить ранее созданные порт группы:

После перехода в следующее окно, нас встречает менюшка с кастомизацией шаблона. Давайте по порядку пропишем все важные настройки:

Appliance Configuration - в этом разделе достаточно указать только пароль root к апплаенсу:
Network Config - основной раздел с настройкой сети: Думаю тут ясно, указываем dns-имя апплаенса, его менеджмент IP, гейт для менеджмент сети и dns. Спускаемся ниже, и указываем сетевые параметры для workload:

Ну и тут же указывает сетевые настройки для frontend сегмента:
Load Balancing - этот раздел определяет настройки балансировки haproxy: Здесь мы указываем ip-диапaзон (поле - Load Balancer IP), что выделили ранее. Для доступа к немспейсу будут использоваться адреса из этого диапазона.

Затем указываем настройки подключения к dataplane API - указываем порт и креды login/password.

Завершаем настройку и жмем финиш.

Пока деплоется наш образ, давайте на схеме отобразим настройки нашего HAProxy.

Для последующей настройки Workload control plane, будет нужен ca-сертификат, который лежит на haproxy.

По ssh поключаемся к серверу и копируем содержимое ca-сертификата - /etc/haproxy/ca.crt.

root@haproxy01-k8s [ ~ ]# cat /etc/haproxy/ca.crt
-----BEGIN CERTIFICATE-----
MIIDnzCCAoegAwIBAgIJAJ55Ws+3Y5PVMA0GCSqGSIb3DQEBBQUAMG0xCzAJBgNV
BAYTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRIwEAYDVQQHDAlQYWxvIEFsdG8x
MIIDnzCCAoegAwIBAgIJAJ55Ws+3Y5PVMA0GCSqGSIb3DQEBBQUAMG0xCzAJBgNV
LjcwLjQzMB4XDTIzMDYwNzEyMjMzOVoXDTMzMDYwNDEyMjMzOVowbTELMAkGA1UE
MIIDnzCCAoegAwIBAgIJAJ55Ws+3Y5PVMA0GCSqGSIb3DQEBBQUAMG0xCzAJBgNV
MA0GA1UECgwGVk13YXJlMQ0wCwYDVQQLDARDQVBWMRUwEwYDVQQDDAwxMC4yMDAu
MIIDnzCCAoegAwIBAgIJAJ55Ws+3Y5PVMA0GCSqGSIb3DQEBBQUAMG0xCzAJBgNV
3Y5PVMA0GCSq==
-----END CERTIFICATE-----
root@haproxy01-k8s [ ~ ]#

Настройка Supervisor кластера

Идем в раздел настроек - Workload Management:

Жмем кнопку - Get started, что бы начать:

vCenter Server and Network - в этом подразделе просто выбираем сетевой стек. В нашем случаи это vDS.
Cluster - думаю тут понятно, мы выбираем кластер на котором будем размещен supervisor control plane.
Storage - данный подраздел предопределяет используемую политику хранения данных. И тут нужно выбрать политику, которую создали ранее.
Load Balancer - здесь определяются параметры для балансировки: В этом поинте указываем тип балансировщика и имя. Далее вставляем адрес и порт менеджмент интерфейса HAProxy, ну и логин/пароль.

В поле Virtual IP Ranges, указывается тот же диапазон, что мы указывали при настройки балансировки при развертывании HAProxy (это была сетка - 10.200.72.128/25). А в поле вставки TLS сертификата, вставляем содержимое ca.crt c сервера HAProxy.
Management Network - настройка сети для VM в supervisor кластере: Тут вроде все ясно, выбираем менеджмент порт группу. В поле Starting IP Address - указываем адрес, начиная с которого будут выдаваться ip-адреса нодам в supervisor кластере. Ну в конце прописываем - маску, гейт, dns, ntp.
Workload Network - этот поинт определяет настройки для сети рабочих нагрузок В начале выбираем порт группу для workload сети, режим работы сети (Network Mode) - Static. Спускаемся немного ниже, и в поле IP Address Range(s) указываем сетевой диапазон, адреса из которого будут назначаться на workload сущности, namespace например. Ну и далее указываем - гейт, dns, ntp.
Tanzu Kubernetes Grid Service - Здесь просто указываем репозиторий из content library.
В последнем разделе просто выбираем размер нашего будущего control plane, и жмем на finish.

В течении некоторого времени, у меня это занято 15 минут, развернется supervisor cluster. И в менюшке - workload managment увидем:

Namespace и вложенные кластера

Все готово к тому, что бы создать первый namespace и начать поднимать вложенные кластера. Для создания нового пространства (namespace) идем в workload managment, и во вкладке Namespaces жмем на кнопку создания:

В новом окне нужно выбраться кластер, и сетку:

В течении 1-2 минут namespace будет создан. Для доступа к этому неймспейсу даем доступ пользователю:

В новом окне выбираем identity источник, ищем пользователя. А в поле - Role, нужно проставить роль для добавляемого пользователя. В моем случаи пользователь k8s-admin будет владельцем своего namespace:

Двигаемся далее и выбираем storage policy:

Ну и завершающим этапом нужно добавить - content library, из которой будут деплоиться наши кластера:

В этом же разделе нужно выбрать VM классы:

Подключаемся к namespace

На главном дашборде нашего немйспейка копируем или открываем ссылку:

На новой странице браузера откроется окно с приветствием, и описанием что далее.

С этой же странице мы качаем и распаковываем плагин c kubectl, где нибудь на компе. Затем открываем настройки переменных среды, и добавляем путь к бинарям плагина:

В раздел системных переменных добавляем новую переменную. В значение переменной путь к плагину:

Открываем консоль и пробуем пихнуть какую нибудь команду:

Отлично, теперь подключаемся к кластеру используя команду:

PS C:\Users\user> kubectl vsphere login --server=10.200.72.129 --insecure-skip-tls-verify
Welcome to Photon 3.0 (\m) - Kernel \r (\l)

Username: k8s-admin@domain.local
KUBECTL_VSPHERE_PASSWORD environment variable is not set. Please enter the password below
Password: ***********
Logged in successfully.

You have access to the following contexts:
   10.200.72.129
   10.200.72.130
   cluster01
   k8s-cluster-02
   prod01
   test-ns

If the context you wish to use is not in this list, you may need to try
logging in again later, or contact your cluster administrator.

To change context, use `kubectl config use-context <workload name>`

После успешного логина нам нужно переключится на рабочий контекст. Для получения списка всех контекствов выполняем команду:

PS C:\Users\user> kubectl config get-contexts
CURRENT   NAME             CLUSTER         AUTHINFO                                        NAMESPACE
          prod01           10.200.72.129   wcp:10.200.72.129:k8s-admin@domain.local      prod01
PS C:\Users\user>

Переключаемся на наш контекст:

PS C:\Users\user> kubectl config use-context prod01
Switched to context "prod01".

Давайте создадим вложенный кластер, для этого нужно предварительно подготовить манифест:

apiVersion: run.tanzu.vmware.com/v1alpha1     
kind: TanzuKubernetesCluster                  
metadata:
  name: k8s01                       
  namespace: prod01                      
spec:
  distribution:
    version: v1.21.6---vmware.1-tkg.1.b3d708a  
  topology:
    controlPlane:
      count: 3                               
      class: best-effort-small              
      storageClass: nvme-tkgs
    workers:
      count: 3                               
      class: best-effort-medium             
      storageClass: nvme-tkgs                
  settings:
    network:                                  
      cni:                  
        name: antrea                                       
      pods:
       cidrBlocks:
        - 193.0.1.0/16                          
      services:
       cidrBlocks:
       - 195.51.100.0/12

Подразберем основные директивы этого манифеста:

apiVersion - в значении этой директивы указывается TKGs API Endpoint
kind - тип создаваего объекта
metadata - область метаданных
- name - имя TKC кластера
- namespace - пространство в котором будет создан наш кластер
spec - обрасть описания спецификации объекта
- distribution > version - тут думаю понятно, указывается версия образа из которого будет подняты ноды кластера.
- topology - внутри этого контекста описывается топология кластера
  - controlPlane/workers - контекст для описания мастер/воркер нод кластера
    - count - количество мастеров создаваемого кластера
    - class - класс vm (классы мы указывали при настройки namespace)
    - storageClass - тут указываем Storage политику (Сторадж полиси создавали в самом начале). Посмотреть доступные нам сторадж классы можно командой: kubectl get sc
settings - в рамках этого контекста описываются настройки сети внутри кластера, cni адаптер, подсети.

Ну и поднимаем наш кластер, применив манифест:

PS C:\Users\user> kubectl apply -f k8s-cluster.yaml

В течении 3-5 минут развернеться новый кластер, посмотреть его доступность можно через командную строку:

PS C:\Users\user> kubectl get tkc
NAME    CONTROL PLANE   WORKER   TKR NAME                           AGE   READY   TKR COMPATIBLE   UPDATES AVAILABLE
k8s01   3               3        v1.21.6---vmware.1-tkg.1.b3d708a   67s   False   True             [1.22.9+vmware.1-tkg.1.cc71bc8]

Колонка READY: True - говорит нам, что кластер уже готов.

В разрере vSphere UI будет вот такая картинка:

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

PS C:\Users\user> kubectl vsphere login --server=10.200.72.129 --insecure-skip-tls-verify --tanzu-kubernetes-cluster-namespace prod01 --tanzu-kubernetes-cluster-name k8s01

После логина, аналогичным способом переключаем контекст на новый кластер:

PS C:\Users\user> kubectl config use-context k8s01

Что бы убедится в том, что мы действительно в нужном контексте можно выполнить листинг нод текущего кластера:

PS C:\Users\user> kubectl get nodes
NAME                                   STATUS   ROLES                  AGE   VERSION
k8s01-control-plane-25vdx              Ready    control-plane,master   39m   v1.21.6+vmware.1
k8s01-control-plane-9vx45              Ready    control-plane,master   41m   v1.21.6+vmware.1
k8s01-control-plane-l5fjd              Ready    control-plane,master   36m   v1.21.6+vmware.1
k8s01-workers-knrv2-598f68d976-m6k84   Ready    <none>                 39m   v1.21.6+vmware.1
k8s01-workers-knrv2-598f68d976-ss4nf   Ready    <none>                 39m   v1.21.6+vmware.1
k8s01-workers-knrv2-598f68d976-wgszj   Ready    <none>                 39m   v1.21.6+vmware.1

Снести наш кластер, можно командой:

PS C:\Users\user> kubectl delete tkc k8s01
tanzukubernetescluster.run.tanzu.vmware.com "k8s01" deleted

Думаю на этом пока что все, далее будем запускать приложения внутри нашего кластера. Ну и пробовать открывать доступ из вне к нашему кластеру.

Немного теории#

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

Настройка DRS/HA#

Настрока vDS свитча#

Создание StoragePolicy#

Добавление репозитория в Content library#

Настройка TKGs#

Деплой HAProxy#

Настройка Supervisor кластера#

Namespace и вложенные кластера#

Подключаемся к namespace#