Кластеры K8s в облаке на базе VMware

Контейнеризация приложений на сегодняшний день — один из самых удобных и часто используемых способов их доставки конечным пользователям. Но что делать, если существующая инфраструктура построена на VMware и хочется использовать Kubernetes? Ответ на этот вопрос в нашей новой статье.

CSE и его место в экосистеме VMware

Container Service Extension (CSE) — это расширение для VMware vCloud Director (VCD), позволяющее создавать кластеры Kubernetes (K8s) и управлять ими внутри существующей облачной инфраструктуры VMware. Важность этого сложно переоценить, ведь обеспечение доступа к кластерам K8s и управление «жизненным циклом» приложений — задача, требующая серьезного внимания.

Зачем нужен CSE

Появление системы оркестрации контейнеров, k8s, стало «философским камнем» для разработчиков и «Святым Граалем» для облачных провайдеров, предоставляющих возможность запуска контейнеризованных приложений. Несмотря на сложную архитектуру и более высокий порог вхождения (по сравнению с тем же Docker Swarm), K8s дает более широкие возможности по управлению контейнеризованной инфраструктурой.

Отлично, давайте использовать k8s! Но как быть, если бережно выстраиваемая в компании IT-инфраструктура изначально создавалась в экосистеме VMware?

Именно эту проблему и решает CSE, позволяя реализовать потребность в контейнеризованных приложениях внутри действующей инфраструктуры VMware. Это расширение позволяет создать кластер k8s в виде отдельного vApp, привычной инфраструктурной единицы, а также обеспечить локальную сетевую связность с имеющимися приложениями и сервисами.

Приведем пример. Есть компания X, которая активно использует CRM в связке с базой данных. Инфраструктура реализована в виде виртуального дата-центра в экосистеме VMware. При необходимости запуска какого-либо контейнеризованного приложения, требующего взаимодействия с этой же базой данных, не потребуется выход за пределы периметра существующей инфраструктуры.

Наша реализация

Мы уже рассказывали о нашем «Облаке на базе VMware». Кластер K8s, размещенный внутри нашей инфраструктуры, будет иметь такие же преимущества и возможность применения тех же механизмов отказоустойчивости. Legacy-приложения смогут легко взаимодействовать с контейнеризованными через общую локальную сеть.

Распределение ролей на администратора и пользователей весьма удобно, когда требуется не только использовать K8s для доставки приложений, но и обеспечить разработчиков удобной средой для тестирования кода. Пользователи не могут выполнять административные действия и взаимодействуют с кластером только при помощи kubectl. Администраторы же выполняют любые действия как внутри кластера, так и над ним.

Для развертывания и масштабирования кластера не потребуется вникать в тонкости работы K8s, поскольку все действия происходят из vcd-cli за несколько минут.

Установка расширения CSE в vcd-cli

По умолчанию vcd-cli не умеет работать с CSE, поэтому сперва необходимо установить расширение container-service-extension.

python3 -m pip install container-service-extension

После установки расширения необходимо зафиксировать его в конфигурационном файле vcd-cli. Открываем ~/.vcd-cli/profiles.yaml и добавляем после параметра active следующие строки:

extensions:
- container_service_extension.client.cse

Далее выполняем вход:

vcd login vcd.selectel.ru <название организации> <логин>

Теперь можно убедиться, что расширение успешно установлено и взаимодействует с сервером:

root@hedwig:~# vcd cse version
CSE, Container Service Extension for VMware vCloud Director, version 3.0.1
root@hedwig:~# vcd cse system info
property     value
-----------  ------------------------------------------------------
description  Container Service Extension for VMware vCloud Director
product      CSE
version      2.6.1

Создание кластера k8s

Интеграция с vCloud Director обеспечивает удобство управления из единой точки при помощи привычных действий и интерфейса. Внутри виртуального дата-центра используется общий пул ресурсов, а развертывание происходит из шаблонов виртуальных машин с уже установленным и настроенным k8s. Создание кластера kubernetes выполняется в одну команду:

vcd cse cluster create название-кластера \
         --network название-сети \
         --ssh-key ~/.ssh/id_rsa.pub \
         --nodes количество-узлов \
         --template имя-шаблона

Обратите внимание, что обязательными параметрами является название кластера и используемая сеть, остальные параметры можно опустить. По умолчанию создается 3 узла из шаблона ubuntu-16.04_k8-1.18_weave-2.6.5. Посмотреть все доступные шаблоны можно командой vcd cse template list.

В веб-интерфейсе vCloud Director созданный кластер можно видеть в разделе vApps.

Остался завершающий штрих: получить файл конфигурации для kubectl. Его можно сгенерировать следующим образом:

vcd cse cluster config название-кластера > config

Для дальнейшей работы с кластером k8s размещаем файл конфигурации на нужное место:

mkdir ~/.kube/config
cp config ./.kube/config

Теперь кластер k8s готов к работе.

Особенности и ограничения реализации

На текущий момент не поддерживается тип сервиса LoadBalancer из коробки, а это означает, что манифесты K8s, использующие сервисы LoadBalancer и Ingress, не будут работать корректно. Тем не менее, есть решения данной проблемы. Допустимо использовать любую реализацию LoadBalancer и Ingress, но мы расскажем про MetalLB и ProjectContour.

MetalLB

В качестве балансировщика можно использовать MetalLB (имплементация LB, использующая стандартные протоколы маршрутизации, вместо облачных LB). Создаем пространство имен и добавляем MetalLB через манифесты:

kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.9.5/manifests/namespace.yaml

kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.9.5/manifests/metallb.yaml

Настраиваем безопасное общение между узлами. Если не выполнить данную команду, то все поды перейдут в статус CreateContainerConfigError, а в логах будет причина Error: secret «memberlist» not found.

kubectl create secret generic -n metallb-system memberlist --from-literal=secretkey="$(openssl rand -base64 128)"

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

root@hedwig:~# kubectl get pod --namespace=metallb-system 
NAME                          READY   STATUS    RESTARTS   AGE
controller-57f648cb96-2lzm4   1/1     Running   0          5h52m
speaker-ccstt                 1/1     Running   0          5h52m
speaker-kbkps                 1/1     Running   0          5h52m
speaker-sqfqz                 1/1     Running   0          5h52m

Файл конфигурации не включен в манифест, поэтому его необходимо создать самостоятельно. Создаем metallb-config.yaml и заполняем его следующим образом:

apiVersion: v1 
kind: ConfigMap 
metadata: 
  namespace: metallb-system 
  name: config 
data: 
  config: | 
    address-pools: 
    - name: default 
      protocol: layer2 
      addresses: 
      - X.X.X.101-X.X.X.102

Обратите внимание, что параметр addresses необходимо заполнять свободными адресами, которые будут использованы балансировщиком нагрузки. Применяем файл конфигурации:

kubectl apply -f metallb-config.yaml

LoadBalancer настроен, остался Ingress.

Project Contour

Создание Ingress реализуется в применении манифеста Project Contour.

kubectl apply -f https://projectcontour.io/quickstart/contour.yaml

Эта команда автоматически развернет прокси-сервер Envoy внутри нового, созданного namespace projectcontour, который будет слушать стандартные порты 80/443.

Заключение

Использование VMware Container Service Extension позволяет применить гибридный подход и объединить использование Legacy-приложений с контейнеризованными в рамках одной виртуальной инфраструктуры VMware и одного сетевого периметра. Тем самым сохраняется однородность и системный подход к управлению инфраструктурой.

VMware Container Service Extension доступен всем пользователям нашего Облака на базе VMware и предоставляется бесплатно (оплачиваются только потребляемые ресурсы).