Введение

В современном мире технологий, где облачные сервисы занимают доминирующее положение в решениях для бизнеса, многие компании всё ещё находят необходимость в развертывании инфраструктуры на собственных мощностях. Это решение не лишено смысла: от соображений безопасности и законодательных ограничений до специфических требований к производительности и управлению, — существует целый ряд обстоятельств, заставляющих организации искать альтернативы облачным решениям. В таких случаях на передний план выходят технологии, позволяющие создавать мощные и гибкие инфраструктурные решения в закрытом контуре, полностью адаптированные под уникальные потребности бизнеса.

Развитие и распространение контейнерных технологий, в частности оркестрации контейнерных решений, а именно Kubernetes-кластеров, открывают новые возможности для компаний, стремящихся к оптимизации своих IT-процессов и повышению эффективности. Kubernetes предлагает мощный и гибкий инструментарий для управления контейнеризированными приложениями, но его развертывание и настройка в условиях собственной инфраструктуры может представлять определенные трудности, особенно для новичков в этой области.

Эта статья предназначена для тех, кто только начинает свой путь в мире Kubernetes и ищет понимание основ развёртывания кластера Kubernetes на собственных серверах с использованием MetalLB для обеспечения балансировки нагрузки и трафика, а также развёртывания распределенного файлового хранилища внутри Kubernetes-кластера. Описываемый подход позволяет построить закрытую, высокоэффективную систему, способную удовлетворить специфические потребности вашего бизнеса, и обойтись меньшим количеством VM и, как следствие, меньшими затратами по ресурсам на развёртывание инфраструктуры.

Структура Bare-metal Kubernetes-кластера

При развёртывании Kubernetes-кластера на физических серверах выбор компонентов критически влияет на производительность, масштабируемость и управляемость вашей инфраструктуры. Рассмотрим ключевые компоненты, формирующие основу Bare-metal Kubernetes-кластера, их роль и важность для создания устойчивой и эффективной среды.

MetalLB как сетевой балансировщик

MetalLB — важный компонент в архитектуре Kubernetes-кластера, который обеспечивает функциональность балансировщика нагрузки в средах, где не доступны облачные балансировщики. Это решение позволяет сервисам Kubernetes типа LoadBalancer работать на bare-metal кластерах, предоставляя IP-адреса из заранее определенного пула и обеспечивая доступность приложений из внешней сети. MetalLB поддерживает два режима работы — L2 и BGP, позволяя выбрать наиболее подходящий вариант в зависимости от конкретных требований к сетевой инфраструктуре и масштаба проекта.

Longhorn как распределённое файловое хранилище

Longhorn является легким, но мощным распределённым блочным хранилищем для Kubernetes, обеспечивающим высокую доступность и лёгкость управления. В отличие от Ceph, другого популярного решения для распределённого хранилища, который требует развёртывания в отдельном кластере и может оказаться сложным в управлении, Longhorn предлагает простоту и интеграцию непосредственно с Kubernetes. Это делает его идеальным выбором для сред, где необходимо обеспечить устойчивое хранение данных без необходимости комплексной настройки и поддержки отдельного хранилища.

Longhorn входит в перечень проектов Cloud Native Computing Foundation (CNCF), что подчеркивает его значимость и актуальность для современных cloud-native приложений.

Harbor как registry

Harbor — это продвинутый реестр контейнеров, который предлагает такие функции, как управление ролями, сканирование на уязвимости и карантин изображений, подписи и политики репликации. Этот инструмент позволяет создавать защищенные и управляемые пространства для хранения и распределения контейнерных изображений, что является ключевым для непрерывной интеграции и доставки (CI/CD) в Kubernetes. Использование Harbor в качестве registry обеспечивает надежное хранение и доступность образов контейнеров, упрощая развертывание и управление приложениями.

GitLab для доставки кода

GitLab выступает не просто как система контроля версий, но и как платформа для непрерывной интеграции/доставки (CI/CD), управления проектами и коллаборации. В контексте Kubernetes, GitLab позволяет автоматизировать процессы доставки кода от разработки до продуктивного окружения, обеспечивая быстрое и безопасное развертывание приложений. Интеграция с Harbor и Kubernetes усиливает этот процесс, предоставляя централизованное и эффективное управление всем циклом разработки и эксплуатации приложений.

Комбинируя эти компоненты, можно создать мощную, гибкую и масштабируемую инфраструктуру для современных приложений, максимально используя преимущества Kubernetes на физических серверах. MetalLB, Longhorn, Harbor и GitLab вместе формируют основу для устойчивого и эффективного Kubernetes-кластера, обеспечивая бесперебойную работу и лёгкость управления приложениями в современной IT-среде.

Что такое MetalLB

MetalLB является решением для балансировки нагрузки в средах Kubernetes, которые не имеют доступа к встроенным балансировщикам нагрузки, как в облачных провайдерах. Это позволяет использовать стандартный ресурс Service типа LoadBalancer в кластерах, развернутых на собственных серверах или в любой другой среде, не поддерживающей автоматическое создание балансировщиков нагрузки. MetalLB предлагает простой и эффективный способ добиться внешней доступности для сервисов в Kubernetes, используя собственную инфраструктуру.

Режимы работы: L2 и BGP

MetalLB поддерживает два режима работы для балансировки нагрузки: L2 (Layer 2) и BGP (Border Gateway Protocol).

L2 Mode: В режиме L2 MetalLB работает, назначая IP-адреса из заранее определенного пула адресов сервисам Kubernetes типа LoadBalancer и используя ARP (Address Resolution Protocol) для разрешения сетевого трафика к соответствующим адресам. Этот режим подходит для простых сценариев, где требуется минимальная настройка и нет необходимости в сложных маршрутизационных протоколах.

BGP Mode: В режиме BGP MetalLB взаимодействует с сетевыми устройствами, используя протокол BGP для анонсирования маршрутов к IP-адресам сервисов. Этот режим позволяет более гибко управлять распределением трафика и обеспечивает интеграцию с широким спектром сетевой инфраструктуры, поддерживающей BGP.

Что же выбрать: L2 или BGP

L2 Mode (Layer 2)

Преимущества:

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

• Меньшая зависимость от сетевой инфраструктуры: поскольку L2 работает на основе ARP, нет необходимости в дополнительных соглашениях с провайдерами интернет-услуг или сложной настройке сетевого оборудования.

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

Недостатки:

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

• Отсутствие гранулярного контроля над маршрутизацией: L2 предлагает ограниченные возможности для тонкой настройки маршрутизации и распределения трафика.

BGP Mode (Border Gateway Protocol)

Преимущества:

• Высокая масштабируемость и гибкость: BGP поддерживает сложные маршрутизационные сценарии и динамическое распределение трафика, что делает его подходящим для больших и растущих сетей.

• Тонкая настройка маршрутизации: BGP предоставляет гранулярный контроль над тем, как трафик распределяется в сети, позволяя оптимизировать производительность и доступность сервисов.

• Интеграция с существующей сетевой инфраструктурой: BGP может интегрироваться с существующим сетевым оборудованием и протоколами, предлагая улучшенную совместимость и управление маршрутизацией на уровне сети.

Недостатки:

• Сложность настройки: BGP требует более глубоких знаний и понимания сетевой инфраструктуры, что может стать препятствием для некоторых организаций.

• Необходимость сотрудничества с провайдерами интернет-услуг: для полноценного использования BGP может потребоваться координация с ISP и настройка сетевого оборудования для поддержки протокола.

Когда выбирать L2, а когда — BGP

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

BGP подходит для крупных организаций с динамически изменяющимися сетевыми средами, где требуется максимальная гибкость управления трафиком и маршрутизацией, а также для сред, предъявляющих высокие требования к доступности и производительности сервисов.

Выбор между L2 и BGP зависит от вашей конкретной ситуации, требований к сетевой инфраструктуре и уровня технической подготовки вашей команды.

Ещё в MetalLB есть поддержка FRR.

FRR (FRRouting) — это сетевой демон маршрутизации, который может использоваться с MetalLB в режиме BGP для улучшения и расширения возможностей динамической маршрутизации.

FRR поддерживает широкий спектр маршрутизационных протоколов, включая BGP, и позволяет более эффективно управлять распределением трафика и маршрутизационными политиками в крупномасштабных или сложных сетевых топологиях. Использование FRR с MetalLB может значительно усилить гибкость и надежность балансировки нагрузки, обеспечив более точный контроль над тем, как трафик распределяется между сервисами в вашем Kubernetes кластере.

Заключение по MetalLB

Использование MetalLB в качестве встроенного решения для балансировки нагрузки обеспечивает гибкость и масштабируемость Kubernetes-сервисов, делая их доступными из внешней сети без дополнительных слоев и компонентов инфраструктуры. Будь то малый бизнес, ищущий простое и экономичное решение, или крупная организация с высокими требованиями к управлению трафиком и маршрутизации, MetalLB предлагает настройки, удовлетворяющие различные потребности и сценарии использования.

Таким образом, выбор в пользу MetalLB не только определяется вашими конкретными требованиями к балансировке нагрузки и сетевой инфраструктуре, но и способствует оптимизации расходов на поддержку и развитие IT-инфраструктуры за счёт уменьшения количества необходимых серверов балансировщиков. MetalLB представляет собой мощное и эффективное решение для организаций, стремящихся максимально использовать возможности Kubernetes и упростить управление своей сетью.

Longhorn

Longhorn — это высокодоступное распределенное блочное хранилище, созданное специально для Kubernetes. Это решение уникально тем, что оно одинаково хорошо подходит как для облачных сред, так и для сред Bare Metal благодаря своей гибкости, легкости в управлении и интеграции с Kubernetes. Вот несколько ключевых аспектов, почему Longhorn является отличным выбором для обоих типов инфраструктур:

Простота установки и управления

Longhorn предлагает простую установку и управление через Kubernetes CLI или через графический интерфейс пользователя (GUI), что существенно упрощает работу администраторов. Вне зависимости от того, развёртываете ли вы его в облачной среде или на серверах Bare Metal, процесс настройки остается одинаково простым и интуитивно понятным.

Высокая доступность и устойчивость

Longhorn автоматически реплицирует данные между узлами кластера, обеспечивая высокую доступность и защиту от потери данных даже в случае сбоя одного из узлов. Для облачных сред это означает возможность легко переживать сбои облачных инстансов, а для сред Bare Metal — защиту от аппаратных сбоев.

Гранулярное масштабирование

Longhorn позволяет масштабировать хранилище независимо от вычислительных ресурсов, благодаря чему подходит для приложений с переменными требованиями к хранению данных. Эта возможность гранулярного масштабирования делает его выгодным как для облачных, так и для Bare Metal сред, где требования к хранению могут существенно отличаться.

Интеграция с Kubernetes

Longhorn разработан с учётом тесной интеграции с Kubernetes и предлагает такие функции, как автоматическое создание и управление томами, снапшотами и репликациями через Kubernetes API. Это обеспечивает бесшовную работу в любой среде Kubernetes, будь то облачная или Bare Metal.

Производительность

Longhorn оптимизирован для работы в различных средах, включая высокопроизводительные Bare Metal конфигурации. Он обеспечивает высокую I/O производительность, необходимую для интенсивных приложений, таких как базы данных и системы реального времени.

Облачная агностика и переносимость

Благодаря своей агностики к облачным провайдерам, Longhorn обеспечивает легкую переносимость приложений между облачными и Bare Metal средами. Это особенно ценно для организаций, стремящихся к созданию мультиоблачных или гибридных инфраструктур.

Поддержка сообщества и CNCF

Будучи проектом Cloud Native Computing Foundation (CNCF), Longhorn пользуется широкой поддержкой сообщества и соответствует лучшим практикам и стандартам, установленным для cloud-native экосистемы. Это гарантирует постоянное развитие проекта и обеспечение совместимости с другими инструментами и платформами.

В совокупности эти качества делают Longhorn универсальным решением для любой Kubernetes-инфраструктуры, предоставляя надёжное, гибкое и легко управляемое хранилище для приложений в различных средах.

Развертывание металлического Kubernetes-кластера

В рамках этой статьи мы рассмотрим простую установку Bare-metal Kubernetes-кластера в самом простом варианте, где все VM находятся в одной подсети.

Для установки Kubernetes-кластера на подготовленных виртуальных машинах рекомендуется использовать Kubespray — отличный инструмент, основанный на Ansible, который облегчает развертывание и управление кластерами Kubernetes. Важно отметить, что для обеспечения стабильности и надежности вашего кластера лучше использовать роль Kubespray не из master-ветки, а из тегов релиза. Это позволяет избежать потенциальных проблем с нестабильными или непроверенными изменениями, обеспечивая более гладкую и предсказуемую установку.

Сам принцип установки подробно описан в README — https://github.com/kubernetes-sigs/kubespray

Обратите внимание! Для работы MetalLB необходимо включить параметр kube_proxy_strict_arp. Данный параметр находится в 

kubespray/inventory/название_вашего_кластера/group_vars/k8s_cluster/k8s-cluster.yml

Переводим параметр в true:

kube_proxy_strict_arp: true

Также Kubespray может устанавливать MetalLB из коробки, более подробно ознакомится можно тут — https://github.com/kubernetes-sigs/kubespray/blob/master/docs/metallb.md
С нашей стороны мы рекомендуем пользоваться Helm-чартами, чтобы гибко редактировать все установленные компоненты, оставим Kubespray для развёртывания и скалирования нашего кластера, а пока перейдём непосредственно к MetalLB.

Для установки будем пользоваться официальным Helm-чартом. Просмотреть все темплейты и дефолтные values можно тут — https://artifacthub.io/packages/helm/metallb/metallb

Для установки будем использовать следующие values:

controller:
  enabled: true
  logLevel: debug
  image:
    repository: quay.io/metallb/controller
  strategy:
    type: RollingUpdate
  resources:
    limits:
      cpu: 100m
      memory: 100Mi

speaker:
  enabled: true
  logLevel: debug
  tolerateMaster: true
  memberlist:
    enabled: true
    mlBindPort: 7946
    mlSecretKeyPath: "/etc/ml_secret_key"
  excludeInterfaces:
    enabled: true
  image:
    repository: quay.io/metallb/speaker
    tag:
    pullPolicy:
  updateStrategy:
    type: RollingUpdate
  resources:
    limits:
      cpu: 100m
      memory: 100Mi
  frr:
    enabled: false

crds:
  enabled: true
  validationFailurePolicy: Fail

Далее устанавливаем наш чарт:

helm repo add metallb https://metallb.github.io/metallb
kubectl create namespace metallb-system
helm upgrade --install -n metallb-system metallb metallb/metallb -f values.yml

При установке MetalLB с использованием Helm-чарта, особое внимание следует уделить ключевым компонентам: controller, speaker, и crds. Эти компоненты играют центральную роль в функционировании MetalLB. Давайте рассмотрим каждый из этих компонентов более подробно.

Controller

Controller в MetalLB отвечает за назначение IP-адресов сервисам типа LoadBalancer. Этот компонент наблюдает за изменениями в сервисах Kubernetes и применяет конфигурацию IP-адресов, основываясь на заранее определенном пуле адресов, указанных в настройках. Controller обеспечивает централизованное управление и распределение IP-адресов, что критически важно для обеспечения доступности и балансировки нагрузки внутри кластера.

Speaker

Speaker работает на уровне каждого узла кластера и отвечает за реализацию протокола балансировки нагрузки на уровне сети. В режиме L2 Speaker использует ARP для ассоциации виртуальных IP-адресов сервисов с физическими адресами узлов. В режиме BGP Speaker анонсирует маршруты к виртуальным IP через BGP, обеспечивая их доступность снаружи кластера. Speaker играет ключевую роль в маршрутизации трафика к подам, выполняющим конкретные сервисы, и является неотъемлемой частью для реализации функций балансировщика нагрузки.

CRDs (Custom Resource Definitions)

CRDs или определения пользовательских ресурсов, являются расширениями Kubernetes API, которые позволяют MetalLB работать со своими собственными конфигурационными объектами. Эти объекты используются для настройки поведения MetalLB, включая определение пулов адресов для балансировки нагрузки и настройки специфических параметров для режимов работы L2 и BGP. CRDs важны для интеграции MetalLB с экосистемой Kubernetes, так как они обеспечивают гибкость и управляемость конфигурации на уровне кластера, позволяя администраторам точно определять, как должны распределяться и управляться IP-адреса.

Когда вы устанавливаете MetalLB с помощью Helm-чарта без вышеописанных values, указанные компоненты (controller, speaker, crds) автоматически настраиваются и развертываются в вашем кластере. Это обеспечивает бесшовную интеграцию с Kubernetes и упрощает процесс развертывания и настройки MetalLB, делая его доступным даже для тех, кто только начинает работать с Kubernetes и сетевыми балансировщиками.

По завершении установки необходимо предоставить MetalLB пул ip-адресов, которые будут использоваться нашими Service типа LoadBalancer Для примера используем L2 протокол в подсети 10.15.250.0/24

apiVersion: v1
kind: ConfigMap
metadata:
  namespace: metallb-system
  name: config
data:
  config: |
    address-pools:
    - name: default
      protocol: layer2
      addresses:
      - 10.15.250.25/32
      - 10.15.250.26/32
      - 10.15.250.27/32
      - 10.15.250.28/32
      - 10.15.250.29/32

apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: mes-pool
  namespace: metallb-system
spec:
  addresses:
  - 10.15.250.25/32
  - 10.15.250.26/32
  - 10.15.250.27/32
  - 10.15.250.28/32
  - 10.15.250.29/32

В манифестах выше мы предоставили 5 IP-адресов. Рекомендуем не использовать всю подсеть, так как большое количество ARP запросов может негативно сказываться на работу сети.

Далее при развертывании нашего Ingress-contorller, например в Ingress-Nginx, мы можем явно указать IP-адрес для нашего LoadBalancer. При создании каких-либо дополнительных Service с типом LoadBalacner можем использовать аннотацию как в примере ниже:

apiVersion: v1
kind: Service
metadata:
  name: some-additional-service
  labels:
    app: magic
  annotations:
    metallb.universe.tf/loadBalancerIPs: 10.15.250.25
spec:
  type: LoadBalancer
[...]

Так как дальнейшие утилиты более комплексные в своей установке, мы не будем уделять им столько времени.

При развёртывании Longhorn используем следующие values:

longhornUI:
  replicas: 2

ingress:
  enabled: true
  ingressClassName: nginx
  host: longhorn.your-domain.com
  tls: true
  secureBackends: true
  tlsSecret: your-tls
  path: /

После чего устанавливаем Longhorn. Добавляем репозиторий чарта:

helm repo add longhorn https://charts.longhorn.io

Делаем helm update:

helm repo update

Создаём неймспейс и устанавливаем чарт:

kubectl create namespace longhorn-system

helm -n longhorn-system upgrade --install longhorn longhorn/longhorn -f values.yaml

Более подробно с темплейтами и значениями в values можно ознакомиться тут.

По завершении установки наш Kubernetes-кластер готов к развертыванию как stateless приложений, так и stateful решений.

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

Заключение

В заключение по всему вышеописанному о Kubernetes-cluster и его компонентов на bare-metal инфраструктуре, стоит подчеркнуть несколько ключевых моментов. Хотя облачные сервисы предлагают удобство и масштабируемость «из коробки», построение собственного Kubernetes-кластера на физических серверах является не только выполнимой задачей, но и может принести значительные преимущества в плане контроля, безопасности и оптимизации затрат.

Используя MetalLB и Longhorn в сочетании с гибкостью Kubespray, вы можете создать мощную, гибкую и полностью контролируемую среду Kubernetes, которая отвечает специфическим требованиям вашего бизнеса. MetalLB обеспечивает надёжную балансировку нагрузки в вашем кластере, предлагая простоту настройки и управления, в то время как Longhorn добавляет гибкость и надежность в управлении данными. Мы рекомендуем добавить к этому Harbor и GitLab, чтобы дополнить эту картину. 

В итоге, создание собственного Kubernetes-кластера на физических серверах может показаться более трудоёмким по сравнению с использованием облачных решений, однако с правильными инструментами и подходами этот процесс становится вполне доступным и управляемым.

Спасибо, что дочитали до конца! Подписывайтесь на наши соцсети: Telegram, vc.ru и YouTube. Мы всегда рады новым друзьям!