Понимание сети kubernetes: сервисы / блог компании southbridge / хабр

Kube Proxy и Сервисы

Само по себе функционирование kube-proxy зависит от двух факторов:

функционирование сети контейнеров между узлами (как уже было отмечено в , сеть между подами должна функционировать исправно);
правилами iptables, в основном filter и nat таблицы.

Важно, 10.32.0.0/24 адреса явлаются «виртуальными». То есть, их не прослушивает ни один из сетевых интерфейсов

По сути это правила iptables, то есть правила маршрутизации трафика, которые будут применены, как только вы попытаетесь что-то запросить по данному адресу+порту. Вы не можете послать icmp запросы на эти адреса, поэтому стандартный способ проверить сервис ping’ом не сработает. Отсутствие результата не будет свидетельствовать ни о поломке, ни о корректном его функционировании.

Для того, чтобы проверить корректную работу kube-proxy, можно отправить запрос на созданный сервис с любого узла и посмотреть на результат его работы:

Нас будет интересовать вторая пара src/dst (9 и 10 столбцы). Как мы видим, тут src меняется и имеет два уникальных значения:

10.200.8.105
10.200.12.68

Это означает, что сервис работает корректно. Если вы видите только один адрес, то какой-то контейнер (скорее всего, расположенный на другом узле) не функционирует. Для отладки этой проблемы можно воспользоваться тестированием непосредственно сети.

Если вдруг вы обнаружили, что оба адреса функционируют, но в таблице conntrack у вас все равно указан только один адрес, это означает, что проблема находится на уровне kube-proxy. Проверьте функционирование сервиса, а также содержимое ваших маршрутов в nat таблице:

Также стоит проделать эту операцию на всех узлах вашего кластера.

Добавление OSD

В данный момент мы имеем работающий кластер, но в нем еще нет дисков (osd в терминологии ceph) для хранения информации.

OSD можно добавить следующей командой (общий вид)

В моем тестовом стенду под osd выделен disk /dev/sdb, по этому в моем случае команды будут следующие

Проверим что все OSD работают

Вывод

Так же можете попробовать полезные команды для OSD

Если все ОК, то мы имеем работоспособный кластер ceph. В следующей части я расскажу как использовать ceph с kubernetes

Подключение ceph к kubernetes

К сожалению, я не смогу в рамках данной статьи подробно рассказать про работу томов Kubernetes, поэтому попробую уложиться в один абзац.
Для работы с томами данных данных Kubernetes использует storage classes, для каждого storage class есть свой provisioner, можно рассматривать его как некий «драйвер» для работы с различными томами хранения данных. Полный список который поддерживает kubernetes можно посмотреть в официальной документации.
В самом Kubernetes так же есть поддержка работы с rbd, но в официальном образе kube-controller-manager нет установленного клиента rbd, поэтому нужно использовать другой образ.
Также следует учесть, что тома (pvc) созданные как rbd могут быть только ReadWriteOnce (RWO) и, а это значит что созданный том Вы сможете примонтировать ТОЛЬКО к одному поду.

Для того что бы наш кластер смог работать с томами на ceph, нам нужно:
в кластере Сeph:

создать pool данных в кластере ceph
создать клиента и ключ доступа до пула данных
получить сeph admin secret

Для того что бы наш кластер смог работать с томами на ceph, нам нужно:
в кластере Сeph:

создать pool данных в кластере ceph
создать клиента и ключ доступа до пула данных
получить сeph admin secret

в кластере Kubernetes:

создать сeph admin secret и ключ клиента ceph
установить ceph rbd provisioner или изменить образ kube-controller-manager на образ который поддерживает rbd
создать secret c ключом клиента ceph
создать storage class
установить ceph-common на воркер нодах kubernetes

Шаг 3 — Установка зависимостей Kubernetetes

В этом разделе вы научитесь устанавливать требующиеся Kubernetes пакеты уровня операционной системы с помощью диспетчера пакетов Ubuntu. Вот эти пакеты:

Docker — среда исполнения контейнеров. Это компонент, который запускает ваши контейнеры. В настоящее время для Kubernetes активно разрабатывается поддержка других сред исполнения, в том числе rkt.
— инструмент командной строки, который устанавливает и настраивает различные компоненты кластера стандартным образом.
— системная служба / программа, которая работает на всех узлах и обрабатывает операции на уровне узлов.
— инструмент командной строки, используемый для отправки команд на кластер через сервер API.

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

Добавьте в файл следующие сценарии, чтобы установить данные пакеты на ваши серверы:

~/kube-cluster/kube-dependencies.yml

Первый сценарий в плейбуке выполняет следующие операции:

Устанавливает среду исполнения контейнеров Docker.
Устанавливает , позволяя добавлять внешние источники HTTPS в список источников APT.
Добавляет ключ apt-key репозитория Kubernetes APT для проверки ключей.
Добавляет репозиторий Kubernetes APT в список источников APT ваших удаленных серверов.
Устанавливает и .

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

Примечание. Хотя документация по Kubernetes рекомендует использовать для вашей среды последнюю стабильную версию Kubernetes, в данном обучающем модуле используется конкретная версия. Это обеспечит успешное следование процедуре, поскольку Kubernetes быстро изменяется и последняя версия может не соответствовать этому обучающему модулю.

Сохраните файл и закройте его после завершения.

Затем запустите плейбук на локальном компьютере:

После завершения вы увидите примерно следующий результат:

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

Теперь все системные зависимости установлены. Далее мы настроим главный узел и проведем инициализацию кластера.

Изменяем hostname и IP адреса виртуальных машин

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

Сначала запустим виртуальную машину Kube Master и сделаем изменения на ней.

Для начала изменим hostname. Это делается простой командой:

Настройки IP адреса в Ubuntu Server 20.04 хранятся в файле . Откроем этот файл и поменяем IP адрес на 192.198.10.10:

После сохранения изменений их необходимо применить командой:

Проверить, что изменения hostname и IP адреса успешно применились можно командой:

Но это ещё не всё. Когда Kubernetes (а если быть точным, то kubelet) будет запускаться на узле, он в качестве IP узла будет использовать IP адрес сетевого адаптера по умолчанию, а это NAT с динамическими адресами, который нам не подходит.

Чтобы использовать статический IP адрес, который мы указали, отредактируем файл . Ранее, мы уже добавили в него параметр . Теперь добавим ещё один: :

Сохраняем изменения, выключаем виртуальную машину и повторяем эти изменения для двух остальных машин.

Для машины Kube Node1 укажем имя хоста kube-node1 и IP адрес 192.168.10.11.

Для машины Kube Node2 укажем имя хоста kube-node2 и IP адрес 192.168.10.12.

Запуск сервисов

Для запуска сервисов необходимо скопировать в или любой другой каталог, где размещаются сервисы для systemd, и после этого включить и запустить сервис. Пример для kube-apiserver:

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

Не торопитесь запускать все серверы сразу, для начала достаточно будет включить etcd и kube-apiserver. Если все прошло удачно, и у вас сразу заработали все четыре сервиса на мастере, запуск мастера можно считать успешным.

Мастер

Можно воспользоваться systemd настройками или сгенерировать init скрипты для конфигурации, которую вы используете. Как уже было сказано, для мастера вам необходим:

— systemd/etcd
— systemd/kube-apiserver
— systemd/kube-controller-manager
— systemd/kube-scheduler

Клиент

Для работы клиента достаточно скопировать (после того, как вы сгенерируете его или напишете самостоятельно) в

Скачайте kubectl и проверьте работу kube-apiserver. Еще раз напомню, что на данном этапе для работы kube-apiserver должен функционировать только etcd. Остальные компоненты понадобятся для полноценной работы кластера несколько позже.

Проверяем, что kube-apiserver и kubectl работают:

Конфигурация Flannel

В качестве конфигурации flannel я остановился на бэкенде. Подробнее о бэкендах можно почитать тут.

Для установки нужной конфигурации flannel можно воспользоваться из etc/flannel

Важно помнить: если вы решите поменять backend, необходимо будет удалить конфигурацию в etcd и перезапустить все flannel демоны на всех узлах, — поэтому выбирайте его с умом. По умолчанию используется vxlan

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

Оформление презентации в PowerPoint

Создание слайда и выбор макета

Для начала добавим несколько слайдов, нажав на кнопку «создать слайд». Если нажать на белую иконку над надписью «создать слайд», то он автоматически будет добавлен с макетом заголовок и объект, если же нажать на саму надпись со стрелочкой вниз, то появится выпадающее меню со всеми доступными макетами.

По ходу создания презентации вы сможете изменить макет слайда нажав на кнопку «макет» рядом с кнопкой создания слайда.

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

Выбор темы презентации

Один из важных моментов в создании презентации в PowerPoint это её оформление. Для начала подберем тему, для этого переходим в меню во вкладку «дизайн».

В теме подобраны фон слайда и стиль текста

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

В каждой теме можно изменить цветовое решение, что расширяет ваши возможности. Для смены цветовой палитры в разделе «варианты» нужно открыть выпадающее меню нажав на стрелочку с горизонтальной линией и выбрать «цвет».

В некоторых темах слайды с разными макетами выглядят по-разному.

Не ограничивайте себя предустановленными в PowerPoint темами, поищите новые темы в сети, на сегодняшний день выбор огромен. Если вы работаете в крупной компании, где есть корпоративные цвета и свой логотип, то вероятно у этой компании есть и специально разработанная фирменная тема.

Следите, чтобы оформление не отвлекало внимание от основной информации в презентации PowerPoint. Последнее, на что стоит обратить внимание на вкладке «дизайн», это размер слайдов

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

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

Данная характеристика зависит от оборудования, на котором будет показываться презентация.

Переходы между слайдами

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

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

Тут же можно настроить смену слайдов, будет ли один слайд сменять другой по вашей команде «по щелчку» или смена будет производиться автоматически после того как истечет указанное вами время. Если презентация сопровождает ваше выступление, то смену слайдов лучше делать «по щелчку», вы никогда не будете уверены, что на тот или иной слайд у вас уйдет именно столько времени, сколько было запланировано. Могут возникнуть неполадки или вам могут задать вопрос, при автоматической смене презентация убежит вперед. Если же вы создаете мини ролик с помощью PowerPoint, то автоматическая смена слайдов для вас.

Дополнительные ссылки

Цели: цели проекта Minikube смотрите в дорожной карте.
Руководство по разработке: посмотрите CONTRIBUTING.md, чтобы ознакомиться с тем, как отправлять пулрексты.
Сборка Minikube: инструкции по сборке/тестированию Minikube из исходного кода смотрите в руководстве по сборке.
Добавление новой зависимости: инструкции по добавлению новой зависимости в Minikube смотрите в руководстве по добавлению зависимостей.
Добавление нового дополнения: инструкции по добавлению нового дополнения для Minikube смотрите в руководстве по добавлению дополнений.
MicroK8: пользователи Linux, которые не хотят использовать виртуальную машину, могут в качестве альтернативы посмотреть в сторону MicroK8s.

Цели

Ваш кластер будет включать следующие физические ресурсы:

Один главный узел

Главный узел (под узлом в Kubernetes подразумевается сервер), отвечающиой за управление состоянием кластера. На нем работает система Etcd, которая хранит данные кластера среди компонентов, распределяющих рабочие задачи по рабочим узлам.

Два рабочих узла

Рабочие узлы — это серверы, где выполняются рабочие задачи (т. е. приложения и службы в контейнерах). Рабочий узел продолжает выполнять назначенную задачу, даже если главный узел отключается после распределения задач. Добавление рабочих узлов позволяет увеличить объем кластера.

После прохождения данного обучающего модуля вы получите кластер, готовый к запуску приложений в контейнерах, при условии, что серверы кластера имеют достаточные ресурсы процессорной мощности и оперативной памяти для выполнения этих приложений. Практически любые традиционные приложения Unix, в том числе веб-приложения, базы данных, демоны и инструменты командной строки, можно поместить в контейнеры и запускать в кластере. Сам кластер потребляет примерно 300-500 МБ оперативной памяти и 10% ресурсов процессора на каждом узле.

После настройки кластера вы развернете веб-сервер Nginx для проверки правильного выполнения рабочих задач.

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

По-отдельности, рассмотрим процесс настройки мастер ноды (control-plane) и присоединения к ней двух рабочих нод (worker).

Настройка control-plane (мастер ноды)

Выполняем команду на мастер ноде:

kubeadm init —pod-network-cidr=10.244.0.0/16

* данная команда выполнит начальную настройку и подготовку основного узла кластера. Ключ —pod-network-cidr задает адрес внутренней подсети для нашего кластера.

Выполнение займет несколько минут, после чего мы увидим что-то на подобие:

…
Then you can join any number of worker nodes by running the following on each as root:
kubeadm join 192.168.0.15:6443 —token f7sihu.wmgzwxkvbr8500al \
—discovery-token-ca-cert-hash sha256:6746f66b2197ef496192c9e240b31275747734cf74057e04409c33b1ad280321

* данную команду нужно вводить на worker нодах, чтобы присоединить их к нашему кластеру. Можно ее скопировать, но позже мы будем генерировать данную команду по новой.

В окружении пользователя создаем переменную KUBECONFIG, с помощью которой будет указан путь до файла конфигурации kubernetes:

export KUBECONFIG=/etc/kubernetes/admin.conf

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

vi /etc/environment

И добавляем в него строку:

export KUBECONFIG=/etc/kubernetes/admin.conf

Посмотреть список узлов кластера можно командой:

kubectl get nodes

На данном этапе мы должны увидеть только мастер ноду:

NAME STATUS ROLES AGE VERSION
k8s-master.dmosk.local NotReady <none> 10m v1.20.2

Чтобы завершить настройку, необходимо установить CNI (Container Networking Interface) — в моем примере это flannel:

kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml

* краткий обзор и сравнение производительности CNI можно почитать в статье на хабре.

Узел управления кластером готов к работе.

Настройка worker (рабочей ноды)

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

kubeadm token create —print-join-command

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

kubeadm join 192.168.0.15:6443 —token f7sihu.wmgzwxkvbr8500al \
—discovery-token-ca-cert-hash sha256:6746f66b2197ef496192c9e240b31275747734cf74057e04409c33b1ad280321

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

Run ‘kubectl get nodes’ on the control-plane to see this node join the cluster.

На мастер ноде вводим:

kubectl get nodes

Мы должны увидеть:

NAME STATUS ROLES AGE VERSION
k8s-master1.dmosk.local Ready control-plane,master 18m v1.20.2
k8s-worker1.dmosk.local Ready <none> 79s v1.20.2
k8s-worker2.dmosk.local Ready <none> 77s v1.20.2

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

Настраиваем сетевой плагин

На последнем скриншоте мы видим, что у нас в кластере три узла, но все они в статусе NotReady.

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

Причина в том, что Kubernetes имеет абстрактную модель работы с сетью, а конкретная её реализация определяется сетевыми плагинами, такими как Flannel или Calico. Подробнее почитать про сравнение разных плагинов можно тут.

Мы установим Flannel (т.к. по описанию он самый простой).

Зайдя на страницу проекта на GitHub видим, что для настройки плагина достаточно выполнить команду:

Не делаем этого, т.к. это не будет работать. Вместо этого скачиваем файл kube-flannel.yml себе на рабочий стол.

Открываем файл и находим там следующий кусок:

Заменяем значение 10.244.0.0 на 10.10.0.0. Это то значение, которое мы передавали в команду .

Сохраняем изменения и вот теперь уже устанавливаем Flannel командой:

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

Узлы также перейдут в состояние Ready:

Теперь наш кластер готов к использованию.

Шаг 2 — Создание пользователя без привилегий root на всех удаленных серверах

В этом разделе вы создадите пользователя без привилегий root с привилегиями sudo на всех серверах, чтобы вы могли вручную подключаться к ним через SSH как пользователь без привилегий. Это полезно на случай, если вы захотите посмотреть информацию о системе с помощью таких команд как , просмотреть список работающих контейнеров или изменить файлы конфигурации, принадлежащие пользователю root. Данные операции обычно выполняются во время технического обслуживания кластера, и использование пользователя без привилегий root для выполнения таких задач минимизирует риск изменения или удаления важных файлов или случайного выполнения других опасных операций.

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

Добавьте в файл следующую строку сценария play для создания пользователя без привилегий root с привилегиями sudo на всех серверах. Сценарий в Ansible — это набор выполняемых шагов, нацеленных на определенные серверы и группы. Следующий сценарий создаст пользователя без привилегий root с привилегиями sudo:

~/kube-cluster/initial.yml

Далее приведено детальное описание операций, выполняемых этим плейбуком:

Создает пользователя без привилегий root с именем .
Настраивает файл , чтобы пользователь мог запускать команды без ввода пароля.
Добавляет на локальный компьютер открытый ключ (обычно ) в список авторизованных ключей удаленного пользователя . Это позволит вам подключаться к каждому серверу через SSH под именем пользователя .

Сохраните и закройте файл после добавления текста.

Затем запустите плейбук на локальном компьютере:

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

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

Один большой общий кластер

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

+ Эффективное использование ресурсов

+ Дешевизна

+ Эффективное администрирование

обновление версии Kubernetes;
настройка конвейера CI/CD;
установка плагина CNI;
настройка системы аутентификации пользователей;
установка контроллера допуска;

А теперь несколько слов о минусах.

− Единая точка отказа

единственноговсе

обновление Kubernetes приводит к неожиданным побочным эффектам;
общекластерный компонент (например, плагин CNI) начинает работать не так, как ожидалось;
один из компонентов кластера настроен неправильно;
сбой в нижележащей инфраструктуре.

− Отсутствие жесткой изоляции

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

− Отсутствие жесткой multi-tenancy

запросы ресурсов и лимиты(см. также статью « CPU-лимиты и агрессивный троттлинг в Kubernetes » — прим. перев.)ResourceQuotasLimitRanges

− Большое число пользователей

управления доступом на основе ролей (RBAC)(см. статью « Пользователи и авторизация RBAC в Kubernetes » — прим. перев.)

− Кластеры не могут расти до бесконечности

5000 узлов, 150 тыс. pod’ов и 300 тыс. контейнеров500 узлахЭта проблема изучается в соответствующей статье в оригинальном блоге под названием «Architecting Kubernetes clusters — choosing a worker node size».Но давайте рассмотрим противоположный подход: множество мелких кластеров.

Установка kubectl в Windows

Установка с помощью Powershell из PSGallery

Если вы работаете в Windows и используете менеджер пакетов Powershell Gallery, вы можете установить и обновить kubectl с помощью Powershell.

Выполните команды по установке (обязательно укажите ):

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

Установка в Windows с помощью Chocolatey или Scoop

Для установки kubectl в Windows вы можете использовать либо менеджер пакетов Chocolatey , либо установщик в командной строке Scoop.

Перейдите в домашнюю директорию:
Создайте директорию :
Перейдите в созданную только что директорию :
Настройте kubectl, чтобы возможно было использовать удаленный кластер Kubernetes:

Удаление неисправной ноды

Иногда случается так что какая-то из нод вышла из строя. И вам нужно восстановить работоспособность etcd-кластера, как быть?

Первым делом нам нужно удалить failed member:

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

Команды выше удалят static-pod для etcd и дирректорию с данными на ноде.

Разумеется в качестве альтернативы вы также можете воспользоваться командой , которая удалит все Kubernetes-related ресурсы и сертификаты с вашей ноды.

Добавление новой ноды

Теперь у нас есть два пути:

В первом случае мы можем просто добавить новую control-plane ноду используя стандартный механизм:

Вышеприведённые команды сгенерируют команду для джойна новой control-plane ноды в Kubernetes. Этот кейс довольно подробно описан в Kubernetes и не нуждается в разъяснении.

Этот вариант наиболее удобен тогда, когда вы деплоите новую ноду с нуля или после выполнения

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

Для начала убедимся что наша нода имеет валидный CA-сертификат для etcd:

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

и выполним присоединение к кластеру:

Для понимания, вышеописанная команда сделает следующее:

Добавит новый member в существующий etcd-кластер:
Сгенерирует новый static-manifest для etcd с опциями:

эти опции позволят нашей ноде автоматически добавиться в существующий etcd-кластер.

Как Kubernetes работает с базами данных

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

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

Концепт StatefulSet — целая серия примитивов для обработки событий об остановке работы подов и осуществления Graceful Shutdown (предсказуемого завершения работы приложения).
Persistent Volumes — хранилища данных, которые связаны с подами, объектами управления Kubernetes.
Operator Framework — то есть возможность создавать компоненты для управления базами данных и другими stateful-приложениями, распределенными на многих узлах.

Уже сейчас в публичных облаках есть крупные Database as a Service, в бэкенде которых Kubernetes, например: CockroachCloud, InfluxDB, PlanetScale. То есть база данных на Kubernetes — это не только то, что теоретически возможно, но и то, что работает на практике.

У Percona есть два open source решения для Kubernetes:

Kubernetes Operator for Percona Server for MongoDB.
Kubernetes Operator for XtraDB CLUSTER — сервис, который совместим с MySQL, обеспечивает высокую доступность и консистентность. Также можно использовать single node, если высокая доступность не нужна, например для dev database.

Пользователей Kubernetes можно разделить на две группы. Одни используют Kubernetes Operators напрямую — это, в основном, продвинутые пользователи, которые хорошо понимают, как работает технология. Другие запускают его на бэкенде — таким пользователям интересно что-то вроде Database as a Service, они не хотят вникать в нюансы работы Kubernetes. Для второй группы пользователей у нас есть еще одно open source решение — Percona DBaaS CLI Tool. Это экспериментальное решение для тех, кто хочет получить open source DBaaS на основе Kubernetes без глубокого понимания технологии.

Вертикальное автомасштабирование pod’ов

pods distribution budget, PDBофициальном вики VPA

VPA непрерывно проверяет значения метрик, указанные при установке, с интервалом по умолчанию 10 секунд.
Если достигнут заданный порог, VPA пытается изменить выделенное количество ресурсов.
VPA обновляет количество ресурсов внутри контроллера развертывания/репликации.
При перезапуске модулей все новые ресурсы применяются к созданным инстансам.

VPA добавляет необходимое количество ресурсов

Масштабирование требует обязательного перезапуска pod’а. Это нужно, чтобы избежать нестабильной работы после внесения изменений. Для надежности модули перезапускают и распределяют по узлам на основе новых выделенных ресурсов.
VPA и HPA пока несовместимы друг с другом и не могут работать на одних и тех же pod’ах. Если вы применяете в одном кластере оба механизма масштабирования, убедитесь, что настройки не позволят им активироваться на одних и тех же объектах.
VPA настраивает запросы контейнеров на ресурсы, исходя только из прошлого и текущего их использования. Он не устанавливает лимиты использования ресурсов. Могут возникнуть проблемы с некорректной работой приложений, которые начнут захватывать все больше ресурсов, это приведет к тому, что Kubernetes выключит данный pod.
VPA пока на ранней стадии разработки. Будьте готовы, что в ближайшее время система может претерпеть некоторые изменения. Можно почитать об и . Так, в планах реализовать совместную работу VPA и HPA, а также развертывание модулей вместе с политикой вертикального автомасштабирования для них (например, специальная метка ‘requires VPA’).