Kubernetes: что это и как его запустить

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

Сегодня всё это происходит автоматически: система сама замечает, что нагрузка растёт, поднимает новые копии приложения в контейнерах и распределяет между ними запросы. А когда рабочий день заканчивается — самостоятельно сворачивает лишнее, чтобы компания не платила за простой. Так работает контейнеризация и оркестрация контейнеров.

В этом материале разберём систему, которая стала для неё стандартом, — Kubernetes. Узнаем, как устроен инструмент, установим его локально и в облаке и задеплоим веб-приложение.

Содержание

• Что такое контейнеризация
• Что такое Kubernetes и для чего он нужен
• Архитектура K8s
• Компоненты K8s
• Запускаем Kubernetes локально на компьютере
• Запускаем Kubernetes в облаке
• Что дальше?

Что такое контейнеризация

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

Контейнеризация — это способ запускать приложения в изолированных «коробках», которые включают в себя сам код и всё, что нужно для его работы: библиотеки, зависимости и настройки окружения. Такая «коробка» называется контейнером. Она запускается одинаково на ноутбуке разработчика, на тестовом сервере и в продакшене — потому что внутри неё есть всё необходимое для правильной работы.

До контейнеров приложения изолировали через виртуальные машины (ВМ). Каждая ВМ — это полноценная операционная система внутри другой операционной системы со своим ядром, драйверами и службами. Подход надёжный, но тяжеловесный: одна виртуальная машина занимает гигабайты памяти и работает медленно.

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

Главное в контейнеризации — изоляция. Контейнеры работают независимо от операционной системы и друг от друга. Поэтому разработчикам не нужно подстраиваться под конкретное окружение, а DevOps-инженерам проще разворачивать ПО.

Самый известный инструмент для контейнеризации — Docker. Он собирает образ контейнера по описанию в файле Dockerfile, запускает контейнер и управляет его жизненным циклом на одном сервере.

Читайте также:

Как работает Docker: подробный гайд от техлида

Пока приложение состоит из одного-двух контейнеров на одной машине, Docker справляется сам. Но когда контейнеров становятся десятки и сотни, а серверов — несколько, появляются вопросы: на каком сервере поднять новый контейнер, что делать, если он упал, как распределить трафик, как выкатить новую версию без простоя? Решать это вручную — нереально. Здесь и появляется оркестрация контейнеров и её главный инструмент — Kubernetes.

Что такое Kubernetes и для чего он нужен

Kubernetes (часто сокращают до K8s: между K и s ровно восемь букв) — это система управления множеством запущенных контейнеров на серверах. Она разворачивает их, следит, чтобы они работали без перебоев, и распределяет между ними нагрузку.

Читайте также:

Обзор Kubernetes для программистов: как он устроен, как работает и как связан с облаками

Kubernetes умеет:

• Запускать и обновлять приложения одной командой. Девопсу или системному администратору не нужно вручную настраивать каждый сервер — достаточно описать, как должно быть, и K8s сам приведёт систему к этому состоянию.
• Автоматически чинить то, что сломалось. Если приложение зависло или упало с ошибкой, K8s перезапустит его.
• Подстраиваться под нагрузку. В часы пик добавит мощностей, чтобы выдержать наплыв пользователей. Ночью, когда трафик падает, свернёт лишнее, чтобы компания не платила за простой.
• Упрощать работу с контейнеризацией. Если в проекте десятки сервисов в контейнерах на разных серверах, Kubernetes даст системному администратору или DevOps-специалисту единый интерфейс управления.

Проще всего представить Kubernetes как дирижёра: серверы — это сцена, контейнеры — музыканты, а дирижёр следит, чтобы все играли по партитуре. Если кто-то сбивается — Kubernetes сам выводит замену, не прерывая концерт.

При этом сам «дирижёр» — это не один «человек», а команда из нескольких внутренних компонентов. В следующем разделе разберём, «кто» и за что отвечает в K8s.

Архитектура Kubernetes

Систему Kubernetes называют кластером. Кластер делится на две большие части: контрольную панель и рабочие узлы (или ноды). Контрольная панель управляет всем кластером, а рабочие узлы запускают приложения.

Контрольная панель

Это ядро системы. Контрольная панель раздаёт задачи, следит за порядком и хранит данные о состоянии кластера.

Все компоненты контрольной панели общаются между собой не напрямую, а через API Server. Он сохраняет данные в базу и передаёт команды рабочим узлам. Разберём по очереди, что делает каждый компонент: API Server, Scheduler, Controller Manager и Etcd.

API Server — главный шлюз кластера. Когда пользователь отправляет команду — например, «запусти приложение», — она сначала попадает сюда. API Server проверяет права и, если всё в порядке, передаёт команду остальным компонентам.

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

Scheduler отвечает в K8s за распределение задач. Когда требуется запустить новый под, Scheduler смотрит, на каком узле сейчас больше свободных ресурсов — процессора и памяти, — и отправляет под именно туда.

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

Внутри Controller Manager работают несколько отдельных контроллеров. Основные из них:

• ReplicaSet Controller — следит, чтобы запущенных копий приложения было ровно столько, сколько указано в настройках.
• Node Controller — отслеживает состояние узлов и реагирует, если какой-то из них перестал отвечать.
• Deployment Controller — управляет обновлениями приложений: запускает новые версии, останавливает старые.

Etcd — база данных в формате «ключ — значение». В ней хранится вся актуальная информация о состоянии кластера: настройки, объекты Secret с паролями и ключами и текущее положение всех ресурсов.

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

Рабочие узлы, или узлы кластера, — это физические компьютеры или виртуальные серверы, на которых запускаются приложения. Чтобы узел понимал команды контрольной панели K8s, на нём работают несколько служебных программ:

• Pods (Поды) — самая маленькая и неделимая единица в Kubernetes. Внутри пода работает один или несколько контейнеров — обычно Docker-контейнеров. Сам Kubernetes не управляет контейнерами напрямую: он всегда оборачивает их в под и отдаёт команды поду целиком.
• Kubelet — агент контрольной панели на узле. Получает команды от API Server, передаёт их среде выполнения контейнеров и отчитывается о результатах. Если контрольная панель сказала запустить два пода, kubelet проследит, чтобы это произошло.
• Container Runtime — среда выполнения контейнеров. Kubernetes не может самостоятельно запускать контейнеры — для этого нужна сторонняя программа: Containerd, CRI-O или Docker. Kubelet передаёт ей команды, а она распаковывает образ и запускает контейнер.
• Kube-proxy — сетевая компонента узла. Настраивает правила маршрутизации, чтобы поды могли общаться друг с другом внутри кластера и принимать трафик из интернета.

Компоненты K8s

В прошлом разделе мы разобрали внутреннее устройство Kubernetes — компоненты, которыми сама система управляет своим состоянием. С ними DevOps-инженер напрямую не взаимодействует. Теперь поговорим о сущностях, которые он использует в работе с контейнеризацией в Kubernetes и при деплое приложений.

Cluster (кластер) — это вся инфраструктура целиком: серверы, сети и ресурсы, объединённые в единую систему. Внутри кластера находятся все остальные сущности.

Namespace (пространство имён) — пространство имён в K8s. Делит кластер на изолированные логические зоны — например, dev для тестирования и prod для реальных пользователей. Проекты в разных пространствах имён не пересекаются и не мешают друг другу, даже если работают на одних и тех же серверах.

Deployment (развёртывание) — главный манифест приложения. В нём описано, какие программы запускаются, какая версия образа используется и сколько копий нужно. Когда инженер планирует выкатить новую версию — он изменяет Deployment, и Kubernetes обновляет приложение.

ReplicaSet — контроллер количества копий. Он создаётся автоматически на основе Deployment и отвечает за то, чтобы в кластере всегда работало ровно столько подов, сколько указано в манифесте. Если один упал — ReplicaSet тут же поднимает новый.

Pod (под) — базовая рабочая единица, внутри которого работает контейнер с приложением. Подробнее про устройство пода мы говорили в прошлом разделе.

Service — внутренний балансировщик нагрузки. Поды постоянно перезапускаются и получают новые IP-адреса, поэтому обращаться к ним напрямую неудобно. Service даёт стабильную точку входа и распределяет запросы между всеми живыми подами одного приложения.

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

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

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

Этап 1: запуск приложения. DevOps-инженер применяет Deployment в нужном пространстве имён. Deployment передаёт задачу ReplicaSet, и тот запускает заданное количество подов. На старте поды читают настройки из ConfigMap и достают пароли из Secret — теперь приложение готово принимать запросы.

Этап 2: приём пользователей. Пользователь открывает сайт в браузере. Запрос приходит в Ingress, тот по доменному имени определяет, какому приложению он адресован, и передаёт нужному Service. Service выбирает один из работающих подов и отправляет запрос на него. Под обрабатывает запрос и возвращает страницу.

Как запустить Kubernetes локально

Прежде чем разворачивать Kubernetes в облаке, запустим его локально. Для этого есть Minikube — облегчённая версия K8s, которая работает даже на относительно слабом железе. На ней удобно тренироваться: разворачивать кластеры, ломать их, поднимать заново — без риска что-то сломать в продакшене и без большого счёта от облачного провайдера в конце месяца.

В этом разделе сделаем две вещи: запустим локальный кластер и задеплоим в него простое приложение.

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

• 2 ядра процессора;
• 2 ГБ оперативной памяти;
• 20 ГБ свободного места на диске;
• стабильное интернет-соединение.

Для работы с Minikube понадобится Docker — он используется как среда для запуска контейнеров. О том, что такое контейнеры и контейнеризация, мы говорили в начале статьи. Если этого недостаточно и вы никогда не работали с ними на практике — отложите материал и познакомьтесь с Docker подробнее. Пытаться разобраться в K8s без опыта работы с контейнерами — всё равно что учиться вождению, не зная, что такое автомобиль.

Читайте также:

Как работает Docker: подробный гайд от техлида

Если компьютер соответствует минимальным требованиям и вы уверены в своих знаниях Docker, перейдём к практической части

Шаг 1: устанавливаем и запускаем Minikube

Перейдите на страницу Minikube и в разделе Installation скачайте установочный файл для своей операционной системы. Мы разберём последующие шаги на примере Windows.

Установите Minikube. Теперь нам понадобится Docker.

Запустите Docker Desktop, откройте PowerShell и введите команду:

minikube start --driver=docker

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

По окончании установки в терминале появится сообщение.

Проверим работу единственного узла командой:

kubectl get nodes

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

Шаг 2: запускаем веб-сервер

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

kubectl create deployment my-first-app --image=nginx

Дальше произойдёт «магия»: kubectl передаст команду API Server, тот создаст Deployment, Deployment поручит ReplicaSet поднять под, а ReplicaSet запустит под с контейнером Nginx внутри.

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

kubectl get pods

Статус Running в выводе означает, что под работает и Nginx внутри него запустился без ошибок.

Nginx сейчас спрятан внутри кластера — снаружи до него не достучаться. Чтобы открыть приложение в браузере, нужно сделать два шага. Сначала — создать Service, который откроет приложение для внешнего доступа:

kubectl expose deployment my-first-app --type=NodePort --port=80

Теперь пробросим порт с локального компьютера в кластер — это нужно, потому что Minikube живёт в виртуальной машине и без проброса до него не дотянуться:

kubectl port-forward service/my-first-app 8080:80

Готово. Откройте в браузере http://127.0.0.1:8080/. Вы должны увидеть приветственную страницу Nginx.

Квест с локальным запуском K8s выполнен. Остаётся завершить работу кластера — нажмите комбинацию клавиш Ctrl + C и удалите приложение, последовательно введя:

kubectl delete deployment my-first-app
kubectl delete service my-first-app

Сам Kubernetes останавливаем простой командой:

minikube stop

Команда stop остановит виртуальную машину, но оставит её на диске — в следующий раз кластер запустится с того же состояния через minikube start. Если вы хотите полностью удалить Minikube вместе со всеми образами и настройками, используйте minikube delete.

Как запустить Kubernetes в облаке

У многих IT-компаний есть готовые управляемые сервисы Kubernetes, где контрольную панель кластера настраивают за вас — остаётся только описать рабочую нагрузку. Среди популярных платформ — Amazon Web Services (сервис EKS), Google Cloud (GKE) и Microsoft Azure (AKS), а среди отечественных — Yandex Cloud и VK Cloud.

Сервисы устроены по принципу «одна команда — готовый кластер», поэтому останавливаться на этом подробно не будем. Если хотите попробовать конкретную платформу, начните с её документации:

• Amazon Web Servers,
• Google Cloud Platform,
• Microsoft Azure,
• Yandex Cloud,
• VK Cloud.

Мы пойдём другим путём — арендуем обычный сервер и развернём Kubernetes на нём вручную. Так лучше видно, как кластер устроен изнутри и какие компоненты приходится поднимать самому, — это полезный опыт для тех, кто планирует работать с K8s в будущем.

Шаг 1: запускаем Kubernetes на AWS

AWS — крупнейший в мире облачный провайдер. Его доля рынка облачной инфраструктуры доходит до 30%, и для DevOps-инженеров это самая частая среда работы в международных проектах. Поэтому в качестве примера развернём кластер с K8s именно на AWS — а навыки, которые получите, переносятся на любую другую платформу почти без изменений.

Чтобы зарегистрироваться, понадобится иностранная карта (Visa или Mastercard, выпущенная за пределами России) и зарубежный IP. Если есть и то и другое — заводите аккаунт на странице регистрации AWS. Новым пользователям AWS даёт стартовые кредиты на эксперименты. Условия у программы периодически меняются, актуальные лимиты смотрите на странице AWS Free Tier.

После регистрации вы попадёте в консоль AWS — на главную страницу со списком доступных сервисов. Нам нужен EC2 (Elastic Compute Cloud) — это сервис аренды виртуальных серверов. Найдите его в строке поиска или в категории Compute.

На странице EC2 нажмите оранжевую кнопку Launch instance.

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

Первое: выбрать операционную систему. В разделе Application and OS Images (Amazon Machine Image) выберите Ubuntu. По умолчанию подставится последняя стабильная LTS-версия — её и оставьте.

Второе: тип инстанса (Instance type). В разделе Instance type выберите t3.micro. Если ваш аккаунт подпадает под лимиты бесплатного использования, рядом с подходящими типами появится плашка Free tier eligible.

Третье: ключ для SSH. В разделе Key pair (login) нажмите Create new key pair. В открывшемся окне:

• Введите имя ключа — например, kubernetes-key.
• Выберите тип RSA.
• В формате файла укажите .pem.
• Нажмите Create key pair — браузер сразу скачает файл с расширением .pem.

Сохраните этот файл в надёжном месте: повторно скачать его с AWS не получится, а без него подключиться к серверу будет невозможно.

В разделе Network settings поставьте галочку Allow HTTP traffic from the internet. Это откроет 80-й порт — именно через него мы будем заходить на сайт, который запустим в кластере.

Нажмите Launch instance в правой панели.

Через несколько секунд AWS сообщит, что сервер успешно запущен.

Чтобы подключиться к серверу по SSH, понадобится его публичный IP-адрес. Вернитесь на экран Instances и поставьте галочку напротив только что созданного сервера. Внизу появится панель с его параметрами — публичный адрес лежит в поле Public IPv4 address.

Чтобы подключиться к серверу, потребуется SSH-клиент. В Windows 10 и 11 он сразу доступен в командной строке. Проверим: откройте PowerShell и введите ssh -V. Если в ответ появится строка вроде OpenSSH_for_Windows_9.5p2, можно переходить к следующему шагу.

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

Параметры → Система → Дополнительные компоненты → Просмотреть функции → OpenSSH-клиент → Установить

Установка занимает несколько минут. После неё команда ssh будет работать в любом терминале — путь C:\Windows\System32\OpenSSH\Windows добавляет в PATH автоматически. Если PowerShell или командная строка были запущены до установки, перезапустите их, чтобы они увидели новую команду.

Перед подключением приведём в порядок права на .pem-файл — иначе SSH откажется его использовать. Откройте PowerShell и выполните две команды, подставив свой путь к ключу:

icacls "C:\Папка\Где\Лежит\Ключ\имя-ключа.pem" /inheritance:r
icacls "C:\Папка\Где\Лежит\Ключ\имя-ключа.pem" /grant:r "%USERNAME%:R"

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

Теперь можно подключаться. Команда состоит из трёх частей: это путь к ключу, имя пользователя на сервере и его публичный IP.

ssh -i "C:\Папка\Где\Лежит\Ключ\имя-ключа.pem" 
ubuntu@XX.XXX.XXX.XXX

В первый раз SSH спросит, доверяете ли вы серверу, — введите yes и нажмите Enter. Дальше клиент выдаст несколько служебных строк про последний вход и баннер Ubuntu, а приглашение в терминале сменится на что-то вроде ubuntu@ip-172-31-…: ~$. Это значит, что вы внутри сервера и можно работать.

Шаг 2: устанавливаем K3s

Для работы установим K3s — облегчённую сборку Kubernetes от Rancher. Вместо тяжёлой Etcd в ней используется встроенная SQLite, все компоненты упакованы в один бинарник меньше 100 МБ, а из дистрибутива убраны устаревшие и редко используемые функции.

Установка занимает одну команду, но сначала подготовим сервер. Даже такой компактный оркестратор требователен к памяти — на нашем t3.micro с 1 ГБ оперативной памяти запустить его получится впритык. Чтобы система не падала при пиковой нагрузке, добавим файл подкачки на 2 ГБ. Это резерв виртуальной памяти на диске, к которому ядро Linux обращается, когда оперативная память заканчивается.

Введите четыре команды по порядку:

# Выделяем 2 ГБ на жёстком диске под виртуальную память
sudo fallocate -l 2G /swapfile

# Закрываем файл от посторонних (требование безопасности)
sudo chmod 600 /swapfile

# Превращаем файл в системный диск подкачки
sudo mkswap /swapfile

# Включаем его
sudo swapon /swapfile

Проверим, что всё получилось:

free -h

Если в строке Swap в колонке total появилось значение 2.0 Gi — подкачка работает.

Для скачивания и установки K3s введите:

curl -sfL https://get.k3s.io | sh -

Установщик скачает файл, зарегистрирует K3s как системную службу systemd и запустит её. В конце вывода вы увидите строку systemd: starting k3s — кластер готов.

Проверим, что узел работает:

sudo kubectl get nodes

Как и в локальном варианте, если в ответ вывелось имя вашего сервера со статусом Ready — поздравляем, у вас есть собственный облачный кластер!

Шаг 3: деплоим приложение на облачный сервер

Главное преимущество K8s — после настройки kubectl команды деплоя одинаковы везде: на локальном Minikube, на AWS, на Yandex Cloud и на любой другой платформе. Поэтому повторим сценарий из локального запуска, только теперь на облачном сервере.

Развернём сервер Nginx:

sudo kubectl create deployment cloud-app --image=nginx

Откроем приложение для внешнего доступа через NodePort:

sudo kubectl expose deployment cloud-app --type=NodePort --port=80

Узнаем, какой порт K3s выдал нашему сервису:

sudo kubectl get service cloud-app

В выводе найдите колонку PORT (S)— там будет значение вроде 80:31234/TCP. Цифры после двоеточия (31234 в этом примере) — внешний порт, по которому Nginx доступен с самого сервера. Запомните или запишите это число: оно понадобится дальше.

Сейчас Nginx крутится на сервере, но AWS не выпускает его наружу: на уровне облака открыты только 22-й порт (SSH) и 80-й порт (HTTP), который мы разрешили при создании инстанса.

NodePort живёт в диапазоне 30 000–32 767 — этот порт нужно открыть отдельно в Security Group, виртуальном фаерволе AWS перед сервером.

Вернитесь в консоль AWS на экран Instances. Поставьте галочку напротив вашего сервера и опуститесь к нижней панели с его параметрами. Откройте вкладку Security.

В строке Security groups будет ссылка на группу безопасности — обычно она называется launch-wizard-1. Кликните по ней — откроется страница настроек этой группы.

Нажмите Edit inbound rules → Add rule и заполните появившуюся форму:

• Type — Custom TCP.
• Port range — ваш порт из вывода kubectl get service. В нашем примере — 31234.
• Source — Anywhere-IPv4. В соседнем поле автоматически появится 0.0.0.0/0 — это значит «разрешить доступ с любого IP-адреса в интернете».

Нажмите Save rules, чтобы сохранить изменения.

Теперь Nginx доступен снаружи. Откройте в браузере адрес вида http://<Публичный IP>:<Порт> — например, http://3.142.55.100:31234. Вы увидите ту же приветственную страницу Nginx, что и в локальном сценарии с Minikube.

Это и есть рабочий Kubernetes-кластер на облачном сервере. Архитектура та же, что и при локальной работе, — отличие только в том, что узел теперь живёт не на вашем ноутбуке, а в дата-центре AWS.

После эксперимента инстанс нужно удалить, иначе AWS продолжит его тарифицировать или расходовать бесплатные кредиты. Вернитесь на экран Instances, поставьте галочку напротив вашего сервера и выберите Instance state → Terminate instance. AWS попросит подтвердить — нажмите Terminate, и через минуту сервер исчезнет из списка.

Удаление инстанса — необратимое действие: все данные на диске пропадут. Если хотите сохранить состояние сервера на будущее, используйте Stop instance вместо Terminate: остановленный сервер не списывает плату за работу процессора, но небольшая плата за EBS-диск продолжит начисляться.

Что дальше?

Эта статья — фундамент, который помогает понять основы контейнеризации и Kubernetes и попробовать их на практике. Дальше стоит идти по двум осям: вглубь — изучать продвинутые объекты в K8s и архитектурные паттерны; и вширь — осваивать экосистему вокруг Kubernetes и DevOps в целом: мониторинг, CI/CD и так далее.

Вот ресурсы, с которыми удобно продолжить знакомиться с Kubernetes:

• Официальная документация — главный справочник по Kubernetes. В ней описаны концепции и архитектура системы, разобраны все объекты и API, собраны гайды по настройке и решению типовых задач — от запуска первого приложения до настройки сетевых политик и работы с секретами.
• Kubernetes Basics — интерактивное руководство на сайте Kubernetes. Кластер запускается прямо в браузере, ничего не нужно устанавливать на компьютер. В руководстве доступно несколько модулей по основам: создание кластера, развёртывание приложения, его масштабирование, обновление и работа с подами.
• «Kubernetes: Лучшие практики» — настольная книга по K8s. Авторы — Брендан Бёрнс, Эдди Вильяльба, Дейв Штребель и Лахлан Эвенсон — практикующие инженеры в Microsoft. В книге собраны лучшие подходы к оркестрации контейнеров.