Кластеры 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.


Указанная сеть должна быть типа Routed и иметь выход в интернет, иначе инициализация кластера зависнет после создания мастер-узла. Допустимо использовать как «серую» сеть с использованием NAT, так и сеть Direct Connect. Подробнее о создании сетей читайте в нашей Базе знаний.

В веб-интерфейсе 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 и предоставляется бесплатно (оплачиваются только потребляемые ресурсы).

Что еще почитать по теме

Кирилл Филипенко 14 сентября 2022

Увеличиваем FPS в аниме с помощью нейросети и GPU Tesla T4

Рассказываем про технологию интерполяции и ее практическое применение с помощью облачных серверов с GPU.
Кирилл Филипенко 14 сентября 2022
Ульяна Малышева 25 августа 2022

CDN против DDoS-атак: в каких случаях это действительно работает

Рассказываем про неочевидное преимущество CDN — услуга повышает безопасность инфраструктуры за счет защиты от DDoS-атак.
Ульяна Малышева 25 августа 2022
T-Rex 24 августа 2022

IT-инфраструктура организации: понятие, типы и функции

Рассказываем об IT-инфраструктуре предприятия и ее компонентах для малого, среднего и крупного бизнеса.
T-Rex 24 августа 2022

Новое в блоге

Михаил Фомин 24 июня 2022

Docker Swarm VS Kubernetes — как бизнес выбирает оркестраторы

Рассказываем, для каких задач бизнесу больше подойдет Docker Swarm, а когда следует выбрать Kubernetes.
Михаил Фомин 24 июня 2022
Владимир Туров 5 октября 2022

DBaaS: что такое облачные базы данных

Рассказываем о сервисе управляемых баз данных в облаке и объясняем, как разделяется ответственность за работу кластеров БД между провайдером и клиентом.
Владимир Туров 5 октября 2022
Ульяна Малышева 30 сентября 2022

«Нулевой» локальный диск. Как мы запустили облако только с сетевыми дисками и приручили Ceph

Чем хороши сетевые диски и почему именно Ceph, рассказал директор по развитию ядра облачной платформы Иван Романько.
Ульяна Малышева 30 сентября 2022
Валентин Тимофеев 30 сентября 2022

Как проходит онбординг сотрудников ИТО? Что нужно, чтобы выйти на смену в дата-центр

Рассказываем, как обучаем новых сотрудников, какие задачи и испытания проходят инженеры прежде, чем выйти на свою первую смену.
Валентин Тимофеев 30 сентября 2022