Installing kubeadm

Setting up the container

Similarly to OpenStack, the conjure-up deployed version of Kubernetes expects a lot more privileges and resource access than LXD would typically provide. As a result, we have to create a privileged container, with nesting enabled and with AppArmor disabled.

This means that not very much of LXD’s security features will still be in effect on this container. Depending on how you feel about this, you may choose to run this on a different machine.

Note that all of this however remains better than instructions that would have you install everything directly on your host machine. If only by making it very easy to remove it all in the end.

lxc launch ubuntu:16.04 kubernetes -c security.privileged=true -c security.nesting=true -c linux.kernel_modules=ip_tables,ip6_tables,netlink_diag,nf_nat,overlay -c raw.lxc=lxc.aa_profile=unconfined
lxc config device add kubernetes mem unix-char path=/dev/mem

Then we need to add a couple of PPAs and install conjure-up, the deployment tool we’ll use to get Kubernetes going.

lxc exec kubernetes -- apt-add-repository ppa:conjure-up/next -y
lxc exec kubernetes -- apt-add-repository ppa:juju/stable -y
lxc exec kubernetes -- apt update
lxc exec kubernetes -- apt dist-upgrade -y
lxc exec kubernetes -- apt install conjure-up -y

And the last setup step is to configure LXD networking inside the container.
Answer with the default for all questions, except for:

Use the “dir” storage backend (“zfs” doesn’t work in a nested container)
Do NOT configure IPv6 networking (conjure-up/juju don’t play well with it)

lxc exec kubernetes -- lxd init

And that’s it for the container configuration itself, now we can deploy Kubernetes!

1: Настройка рабочего пространства и инвентаря Ansible

На локальной машине нужно создать каталог, который будет служить рабочим пространством. Настройте Ansible локально, чтобы он мог взаимодействовать с командами на удаленных серверах. После этого нужно создать файл инвентаря hosts, содержащий информацию об оркестровке (IP-адреса серверов и группы, к которым принадлежит каждый сервер).

Примечание: Мы используем условный IP-адрес мастер-ноды – master_ip, а также условные IP-адреса рабочих нод – worker_1_ip и worker_2_ip. Их вам нужно будет заменить своими данными.

На локальной машине создайте каталог ~/kube-cluster и перейдите в него:

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

Создайте файл ~/kube-cluster/hosts, используя nano или другой текстовый редактор:

Добавьте в файл такие строки (это информация о логической структуре кластера).

Как вы помните, файлы инвентаря в Ansible используются для указания информации о сервере (IP-адреса, удаленных пользователей и т.д.) и для группировки серверов в единый блок для выполнения команд. ~/kube-cluster/hosts будет таким файлом инвентаря, в нем указаны две группы Ansible (masters и workers), в которых определяется логическая структура кластера.

В группе masters есть запись сервера «master», которая определяет IP-адрес ведущей ноды (master_ip) и указывает, что Ansible должен запускать удаленные команды в качестве пользователя root.

Аналогично, в группе workers есть две записи рабочих серверов (worker_1_ip и worker_2_ip), которые также указывают ansible_user как root.

Последняя строка файла позволяет Ansible для выполнения своих операций использовать интерпретаторы Python 3 на удаленных серверах.

Сохраните и закройте файл.

Ingress Controller

В данной инструкции не будет рассказано о работе с Ingress Controller. Оставляем данный пункт для самостоятельного изучения.

Данное приложение позволяет создать балансировщик, распределяющий сетевые запросы между нашими сервисами. Порядок обработки сетевого трафика определяем с помощью Ingress Rules.

Для установки Ingress Controller Contour (среди множества контроллеров, он легко устанавливается и на момент обновления данной инструкции полностью поддерживает последнюю версию кластера Kubernetes) вводим:

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

Цели

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

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

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

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

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

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

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

Настройка Kubernetes

Инициализация кластера

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

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

В данном примере будем использован наиболее распространенный сетевой плагин — Flannel. По умолчанию он использует сеть «10.244.0.0/16», которая была указана в параметре, приведенном выше.

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

Ошибки нужно исправлять в обязательном порядке, а на предупреждения можно не обращать внимание, если это не окружение «production»

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

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

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

mkdir -p $HOME/.kube

sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config

sudo chown $(id -u):$(id -g) $HOME/.kube/config

Настройка CNI

Перед тем, как начать запускать в кластере приложения, нужно выполнить настройку Container Network Interface («сетевой интерфейс контейнера» или CNI). CNI нужен для настройки взаимодействия и управления контейнерами внутри кластера.

Существует много плагинов для создания CNI. В данном примере применяется Flannel, так как это наиболее простое и проверенное решение. Однако, не меньшей популярностью пользуются плагины Weave Net от компании Weaveworks и Calico (Project Calico), обладающие более широким функционалом и возможностями сетевых настроек.

Чтобы установить Flannel, выполните в терминале команду:

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

В выводе будут отображены имена всех созданных ресурсов.

Добавление узлов (нод) в кластер

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

Подключиться к серверу через SSH.
Установить на сервер Docker, Kubelet, Kubeadm (как показано выше).
Выполнить команду:

kubeadm join --token <token> <control-plane-host>:<control-plane-port> --discovery-token-ca-cert-hash sha256:<hash>

Данная команда была выведена при выполнении команды «kubeadm init» на мастер-ноде.

Если команда не была сохранена, то можно ее составить повторно.

Получение токена авторизации кластера (<token>)

Подключиться к серверу через SSH.
Запустить команду, которая присутствовала на выводе команды «kubeadm init». Например:
```
kubeadm join --token <token> <control-plane-host>:<control-plane-port> --discovery-token-ca-cert-hash sha256:<hash>
```
Если токена нет, его можно получить, выполнив следующую команду на мастер-ноде:
```
kubeadm token list
```
Вывод должен быть примерно таков:

По умолчанию, срок действия токена — 24 часа. Если требуется добавить новый узел в кластер по окончанию этого периода, можно создать новый токен следующей командой:
```
kubeadm token create
```
Вывод будет примерно таков:
```
5didvk.d09sbcov8ph2amjw
```
Если значение параметра «—discovery-token-ca-cert-hash» неизвестно, его можно получить следующей командой:
```
openssl x509 -pubkey -in /etc/kubernetes/pki/ca.crt | openssl rsa -pubin -outform der 2>/dev/null | \
openssl dgst -sha256 -hex | sed 's/^.* //'
```
Будет получен примерно такой вывод:
```
8cb2de97839780a412b93877f8507ad6c94f73add17d5d7058e91741c9d5ec78
```
Для ввода IPv6-адреса в параметр «<control-plane-host>:<control-plane-port>», адрес должен быть заключен в квадратные скобки. Например:
```
:2073
```
Должен быть получен вывод следующего вида:
Спустя несколько секунд нода должна появиться в выводе команды:
```
kubectl get nodes
```

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

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

kubectl taint nodes --all node-role.kubernetes.io/master-

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

Проверить, что кластер запустился и правильно работает, можно так:

kubectl -n kube-system get pods

Вывод будет аналогичен. В нем будут отображены системные POD’ы k8s.

Теперь установку можно считать завершенной. Далее можно продолжить настройку K8s для работы с веб-приложениями. Например, подключить диспетчер пакетов «helm» для автоматического развертывания приложений или контроллер «nginx ingress», отвечающий за маршрутизацию внешнего трафика.

Before you begin

A compatible Linux host. The Kubernetes project provides generic instructions for Linux distributions based on Debian and Red Hat, and those distributions without a package manager.
2 GB or more of RAM per machine (any less will leave little room for your apps).
2 CPUs or more.
Full network connectivity between all machines in the cluster (public or private network is fine).
Unique hostname, MAC address, and product_uuid for every node. See for more details.
Certain ports are open on your machines. See for more details.
Swap disabled. You MUST disable swap in order for the kubelet to work properly.

Системные требования

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

2-3 мастер ноды с 2 cpu и 4 gb ram
ingress нода с 1 cpu и 2 gb ram
рабочие ноды для контейнеров от 2 cpu и 4 gb ram

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

Название	IP	CPU	RAM	HDD
kub-master-1	10.1.4.36	2	4G	50G
kub-master-2	10.1.4.37	2	4G	50G
kub-master-3	10.1.4.38	2	4G	50G
kub-ingress-1	10.1.4.39	2	4G	50G
kub-node-1	10.1.4.32	2	4G	50G
kub-node-2	10.1.4.33	2	4G	50G

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

По гипервизорам виртуальные машины распределил следующим образом.

Упомяну про еще одну рекомендацию. Мастер ноды с etcd дают приличную нагрузку на диск. Их рекомендуется размещать на быстрых ssd дисках. Чем больше кластер — тем больше нагрузка. В наших тестах сойдет и hdd диск под мастер. Но если будете использовать в продакшене с учетом расширения и роста, лучше сразу планируйте быстрые диски под мастера.

Шаг 7 — Запуск приложения на кластере

Теперь вы можете развернуть на кластере любое приложение в контейнере. Для удобства мы развернем Nginx с помощью Deployments и Services и посмотрим, как можно развернуть это приложение на кластере. Вы можете использовать приведенные ниже команды для других приложений в контейнерах, если вы измените имя образа Docker и дополнительные параметры (такие как и ).

Запустите на главном узле следующую команду для создания развертывания с именем :

Развертывание — это тип объекта Kubernetes, обеспечивающий постоянную работу определенного количества подов на основе заданного шаблона, даже в случае неисправности пода в течение срока службы кластера. Вышеуказанное развертывание создаст под с одним контейнером из образа Nginx Docker в реестре Docker.

Запустите следующую команду, чтобы создать службу , которая сделает приложение общедоступным. Для этого используется схема NodePort, которая делает под доступным на произвольном порту, который открывается на каждом узле кластера:

Службы — это еще один тип объектов Kubernetes, который открывает внутренние службы кластера для внутренних и внешних клиентов. Они поддерживают запросы балансировки нагрузки на разные поды и являются неотъемлемым компонентом Kubernetes, который часто взаимодействует с другими компонентами.

Запустите следующую команду:

Будет выведен текст следующего вида:

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

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

Если вы захотите удалить приложение Nginx, предварительно удалите службу с главного узла:

Запустите следующую команду, чтобы проверить удаление службы:

Результат будет выглядеть следующим образом:

Затем удалите развертывание:

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

Шаг 6 — Проверка кластера

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

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

Затем выполните следующую команду, чтобы получить данные о статусе кластера:

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

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

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

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

Краткое руководство

Эта простая демонстрация поможет запустить, использовать и удалить Minikube на локальной машине. Следуйте перечисленным ниже шагам, чтобы начать знакомство с Minikube.

Запустите Minikube и создайте кластер:

Вывод будет примерно следующим:

Дополнительную информацию о запуске кластера в определенной версии Kubernetes, виртуальной машине или среде выполнения контейнера смотрите в разделе .
Теперь вы можете работать со своим кластером через CLI-инструмент kubectl. Для получения дополнительной информации смотрите раздел .

Давайте создадим развёртывание (Deployment) в Kubernetes, используя существующий образ , представляющий простой HTTP-сервер, и сделаем его доступным на порту 8080 с помощью .

Вывод будет примерно следующим:
Чтобы получить доступ к объекту Deployment извне, создайте объект сервиса (Service):

Опция определяет тип сервиса.

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

Проверьте, что под работает:

Если в столбце вывода выводится , значит под все еще создается:

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

Вывод будет примерно следующим:

Если сервис и кластер вам больше не нужны, их можно удалить.
Удалите сервис :

Вывод будет примерно следующим:
Удалите развёртывание :

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

Вывод будет примерно следующим:

Подробности смотрите в разделе .
Удалите локальный кластер Minikube:

Вывод будет примерно следующим:

Подробности смотрите в разделе .

Introduction

For those who haven’t heard of Kubernetes before, it’s defined by the upstream project as:

It is important to note the “applications” part in there. Kubernetes deploys a set of single application containers and connects them together. Those containers will typically run a single process and so are very different from the full system containers that LXD itself provides.

This blog post will be very similar to one I published last year on running OpenStack inside a LXD container. Similarly to the OpenStack deployment, we’ll be using conjure-up to setup a number of LXD containers and eventually run the Docker containers that are used by Kubernetes.

Set up Docker

Step 1: Install Docker

Kubernetes requires an existing Docker installation. If you already have Docker installed, skip ahead to Step 2.

If you do not have Kubernetes, install it by following these steps:

1. Update the package list with the command:

2. Next, install Docker with the command:

3. Repeat the process on each server that will act as a node.

4. Check the installation (and version) by entering the following:

Step 2: Start and Enable Docker

1. Set Docker to launch at boot by entering the following:

2. Verify Docker is running:

To start Docker if it’s not running:

3. Repeat on all the other nodes.

Подготовка[править]

Нужны несколько машин (nodes), одна из которых будет мастером.
Системные требования:

2GB ОЗУ или больше;
2 ядра процессора или больше;
Все машины должны быть доступны по сети друг для друга;
Все машины должны успешно разрешать имена hostname друг друга (через DNS или hosts);
Своп должен быть выключен

Следует выбрать один из двух интерфейсов запуска контейнеров: docker или crio.

Dockerправить

Для разворачивания кластера с использованием docker

Должны быть установлены следующие пакеты:

;

И запущены сервисы docker, kubelet и kube-proxy:

Crioправить

А для разворачивания кластера с использованием crio

Должны быть установлены следующие пакеты:

;

Отредактирован конфиг для использования crio

;

И запущены сервисы crio, kubelet и kube-proxy:

Работа с кластером

Kubectl

Команда создает под именем «minikube».
Этот контекст содержит конфигурацию для взаимодействия с кластером Minikube.

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

Либо передайте контекст при выполнении команды следующим образом: .

Панель управления

Чтобы получить доступ к веб-панели управления Kubernetes, запустите эту команду в командной оболочке после запуска Minikube, чтобы получить адрес:

Сервисы

Чтобы получить доступ к сервису, открытой через порт узла, выполните команду в командной оболочке после запуска Minikube, чтобы получить адрес:

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

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

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

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

Если ваш кластер запущен, то в выводе команды должно быть что-то вроде этого:

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

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

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

Проверка конфигурации kubectl

Чтобы kubectl мог найти и получить доступ к кластеру Kubernetes, нужен файл kubeconfig, который создаётся автоматически при создании кластера с помощью скрипта kube-up.sh или при успешном развертывании кластера Minikube. По умолчанию конфигурация kubectl находится в .

Посмотрите на состояние кластера, чтобы убедиться, что kubectl правильно сконфигурирован:

Если вы видите URL-ответ, значит kubectl корректно настроен для работы с вашим кластером.

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

Например, если вы собираетесь запустить кластер Kubernetes на своем ноутбуке (локально), вам потребуется сначала установить специальный для этого инструмент, например Minikube, а затем снова выполнить указанные выше команды.

Если команда возвращает URL-ответ, но вы не можете подключиться к своему кластеру, чтобы убедиться, что он правильно настроен, воспользуйтесь этой командой:

Installing runtime

To run containers in Pods, Kubernetes uses a
container runtime.

By default, Kubernetes uses the
(CRI)
to interface with your chosen container runtime.

If you don’t specify a runtime, kubeadm automatically tries to detect an installed
container runtime by scanning through a list of well known Unix domain sockets.
The following table lists container runtimes and their associated socket paths:

Container runtimes and their socket paths
Runtime	Path to Unix domain socket
Docker
containerd
CRI-O

If both Docker and containerd are detected, Docker takes precedence. This is
needed because Docker 18.09 ships with containerd and both are detectable even if you only
installed Docker.
If any other two or more runtimes are detected, kubeadm exits with an error.

The kubelet integrates with Docker through the built-in CRI implementation.

See container runtimes
for more information.

By default, kubeadm uses Docker as the container runtime.
The kubelet integrates with Docker through the built-in CRI implementation.

See container runtimes
for more information.

2: Создание пользователей sudo на удаленных серверах

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

В рабочем пространстве создайте ~/kube-cluster/initial.yml:

Затем добавьте в файл такой код, чтобы на всех серверах создать пользователя без прав root с привилегиями sudo. Плей в Ansible представляет собой набор действий, которые необходимо выполнить на целевых серверах и группах. Этот плей создаст пользователя sudo:

Этот плейбук:

Создает пользователя sudo по имени ubuntu.
Настраивает файл sudoers, чтобы предоставить пользователю ubuntu права sudo без пароля.
Добавляет открытый ключ локальной машины (обычно это ~/.ssh/id_rsa.pub) в список ключей удаленного пользователя ubuntu. Это позволит вам подключаться к серверам по SSH как пользователь ubuntu.

Сохраните и закройте файл.

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

Команда будет выполняться в течение 2-5 минут. Затем вы увидите такой вывод:

Основные компоненты архитектуры

Несмотря на удобство и простоту фреймворка Kubernetes, перед его использованием, при разработке или развертывании приложений, необходимо разобраться в архитектуре. Например, понять, как соединяются между собой контейнеры (через интерфейс API), и узнать, почему компоненты разделены на две основные группы – Master Node и Worker Node.

Базовые компоненты:

Nodes – виртуальная (физическая) машина, на мощностях которой запущены контейнеры.
Pods – базовые модули управления приложениями, состоящие из одного или нескольких контейнеров.
Volume – ресурс, позволяющий одновременно запускать несколько контейнеров.
Kube-Proxy – комплекс из прокси-сервера и модуля балансировки нагрузки, позволяющий маршрутизировать входящий трафик под конкретный контейнер Pods.
Kubelet – транслятор статусов Pods на узле и контроллер корректности работы контейнера и образа в целом.

Перечисленные компоненты устанавливаются автоматически при помощи сторонних инструментов или вручную, по отдельности. Они составляют модуль под названием Master Node, где собраны все управляющие и контролирующие функции. Через API они связываются с контейнерами, считывают их показатели, дают команду на запуск, штатную остановку или принудительное закрытие.

Как работает технология

Принципы устройства

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

Помимо этого, в Kubernetes могут быть задействованы императивные команды (create, edit, delete), которые позволяют непосредственно создавать, модифицировать и удалять ресурсы. Однако, их не рекомендуется использовать для критически важных задач.

Для развертывания программного обеспечения в Kubernetes применяется база Linux-контейнеров (например, Containerd или CRI-O) и описание — сколько потребуется контейнеров и в каком количестве им потребуются ресурсы. Само развертывание контейнеров происходит на основе рабочих нод — виртуальных или физических машин.

Основные задачи Kubernetes

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

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

Обнаружение сервисов и балансировка нагрузок. Контейнеры могут работать через собственные IP-адреса или использовать общее имя DNS для целой группы. K8s может регулировать нагрузку сетевого трафика и распределять его, чтобы поддержать стабильность развертывания.
Автоматическое управление хранилищами. Пользователь может задавать, какое хранилище использовать для развертывания по умолчанию — внутреннее, внешнего облачного провайдера (GKE, Amazon EKS, AKS), другие варианты.
Автоматическое внедрение и откат изменений. Пользователь может на лету делать любые дополнения к текущей конфигурации контейнеров. Если это нарушит стабильность развертывания, K8s самостоятельно откатит изменения до стабильно работающей версии.
Автоматическое распределение ресурсов. Kubernetes сам распределяет пространство и оперативную память из выделенного кластера нод, чтобы обеспечить каждый контейнер всем необходимым для работы.
Управление паролями и настройками. K8s может служить приложением для безопасной обработки конфиденциальной информации, связанной с работой приложений — паролей, OAuth-токенов, SSH-ключей. В зависимости от способа применения, данные и настройки можно обновлять без создания контейнера заново.
Самовосстановление при возникновении сбоя. С помощью особых метрик и тестов система может быстро опознать поврежденные или переставшие отвечать на запросы контейнеры. Вышедшие из строя контейнеры создаются заново и перезапускаются на том же поде.

Kubernetes – удобный инструмент оркестрации контейнеров. Однако, это решение, не работает само по себе, без подготовки и дополнительных настроек. Например, пользователям придется решать вопросы по миграции схем баз данных или разбираться с обратной совместимостью API.

Заключение

Если у вас нет возможности или желания настраивать кластер Kubernetes самостоятельно на своем железе, можете купить его в готовом виде как сервис в облаке Mail.ru Cloud Solutions.

На этом начальную статью по Kubernetes заканчиваю. На выходе у нас получился рабочий кластер из трех мастер нод, двух рабочих нод и ingress контроллера. В последующих статьях я расскажу об основных сущностях kubernetes, как деплоить приложения в кластер с помощью Helm, как добавлять различные стореджи, как мониторить кластер и т.д. Да и в целом, хочу много о чем написать, но не знаю, как со временем будет.

В планах и git, и ansible, и prometeus, и teamcity, и кластер elasticsearch. К сожалению, доход с сайта не оправдывает временных затрат на написание статей, поэтому приходится писать их либо редко, либо поверхностно. Основное время уходит на текущие задачи по настройке и сопровождению.