Мета

• Дізнатись, що таке кластер Kubernetes.
• Дізнатись, що таке Minikube.
• Запустити Kubernetes кластер на вашому компʼютері.

Kubernetes кластери

Kubernetes організовує високодоступний кластер компʼютерів, які взаємодіють, працюючи як єдиний блок. Абстракції в Kubernetes дозволяють розгортати контейнеризовані застосунки в кластері, не привʼязуючи їх специфічно до окремих машин. Щоб скористатися цією новою моделлю розгортання, застосунки повинні бути упаковані таким чином, що відділяє їх від конкретних хостів: вони повинні бути контейнеризовані. Контейнеризовані застосунки є більш гнучкими та доступними, ніж у минулих моделях розгортання, коли застосунки встановлювалися безпосередньо на конкретні машини як пакунки, глибоко інтегровані в хост. Kubernetes автоматизує розподіл та планування контейнерів застосунків у кластері більш ефективним способом. Kubernetes є платформою з відкритим кодом і готовою до операційного використання.

Кластер Kubernetes складається з двох типів ресурсів:

• Панелі управління (Control Plane), що координує роботу кластера
• Вузлів (Nodes) — робочіх машин, на яких запущені застосунки

Схема кластера

Панель управління (Control Plane) відповідає за керування кластером. Вона координує всі процеси у вашому кластері, такі як запуск застосунків, підтримка їх бажаного стану, масштабування застосунків та розгортання оновлень.

Вузол (Node) — це ВМ або фізичний компʼютер, що виступає у ролі робочої машини в кластері Kubernetes. Кожен вузол має kubelet — агента для управління вузлом та обміну даними з панеллю управління Kubernetes. Також на вузлі мають бути встановлені інструменти для виконання операцій з контейнерами, такі як containerd або CRI-O. Кластер Kubernetes, що обслуговує операційний трафік має складатися як мінімум із трьох вузлів. Якщо один вузол вийде з ладу обидва члени etcd та панель управління будуть втрачені, а надмірність буде порушена. Ви можете зменшити ризик додаванням більше одного вузла з панеллю управління.

Коли ви розгортаєте застосунки у Kubernetes, ви наказуєте панелі управління запустити контейнери застосунку. Панель управління розподіляє (планує) контейнери для запуску на вузлах кластера. Компоненти на рівні вузла, такі, як kubelet, спілкуються з панеллю управління за допомогою API Kubernetes, який надається панеллю управління. Кінцеві користувачі також можуть використовувати API Kubernetes для взаємодії з кластером.

Кластер Kubernetes можна розгорнути як на фізичних, так й на віртуальних машинах. Щоб розпочати розробку під Kubernetes, ви можете скористатися Minikube — спрощеною реалізацією Kubernetes. Minikube створює на вашому локальному компʼютері ВМ, на якій розгортає простий кластер з одного вузла. Існують версії Minikube для операційних систем Linux, macOS та Windows. Minikube CLI надає основні операції для роботи з вашим кластером, такі як start, stop, status та delete.

Тепер ви знаєте, що таке Kubernetes. Тож відвідаємо сторінку Привіт Minikube та спробуємо його на вашому компʼютері.

Мета

• Дізнатися, що таке Deployment застосунків.
• Розгорнути свій перший застосунок у Kubernetes за допомогою kubectl.

Процеси Kubernetes Deployment

Після створення працюючого кластера Kubernetes ви можете розгортати свої контейнеризовані застосунки на його основі. Для цього створіть розгортання (Deployment) Kubernetes. Deployment вказує Kubernetes, як створювати та оновлювати екземпляри вашого застосунку. Після створення Deployment панель управління Kubernetes розподіляє екземпляри застосунків, що включені в цей Deployment, для запуску на окремих вузлах в кластері.

Коли екземпляри застосунків створені, контролер розгортання Kubernetes безперервно відстежує їх стан. Якщо вузол, на якому запущено екземпляр, вимикається або видаляється, контролер розгортання замінює екземпляр новим на іншому вузлі в кластері. Це забезпечує механізм самовідновлення для розвʼязання проблем з відмовою або обслуговуванням вузлів.

У світі до-оркестрування часто використовувалися скрипти встановлення для запуску застосунків, але вони не дозволяли відновлення після відмови вузла. Шляхом як створення екземплярів застосунків, так і утримання їх в робочому стані на різних вузлах, розгортання Kubernetes забезпечує фундаментально відмінний підхід до управління застосунками.

Розгортання вашого першого застосунку в Kubernetes

Ви можете створювати та управляти розгортанням (Deployment) за допомогою інтерфейсу командного рядка Kubernetes, kubectl. Kubectl використовує API Kubernetes для взаємодії з кластером. У цьому модулі ви вивчите найпоширеніші команди kubectl, які потрібні для створення розгортань та запуску застосунків в кластері Kubernetes.

Коли ви створюєте Deployment, вам необхідно вказати образ контейнера вашого застосунку та скільки його реплік ви бажаєте запустити. Згодом цю інформацію можна змінити, оновивши Deployment. В навчальних модулях 5 і 6 йдеться про те, як масштабувати і оновлювати Deployment'и.

Для вашого першого розгортання ви будете використовувати застосунок hello-node, який упакований в Docker-контейнер і використовує NGINX для відгуку на всі запити. (Якщо ви ще не пробували створити застосунок hello-node та розгортати його за допомогою контейнера, ви можете це зробити, слідуючи інструкціям з посібника Привіт Minikube).

Вам також потрібно мати `kubectl`. Якщо ви ще не встановили його, відвідайте встановлення інструментів.

Тепер ви знаєте, що таке Deployment. Тож розгорнемо ваш перший застосунок!

Основи kubectl

Загальний формат команди kubectl: kubectl дія ресурс

Тут виконується вказана дія (наприклад, create, describe або delete) для вказаного ресурсу (наприклад, node або deployment). Ви можете використовувати --help після команд для отримання додаткової інформації про можливі параметри (наприклад, kubectl get nodes --help).

Перевірте, що kubectl налаштовано для роботи з вашим кластером, виконавши команду kubectl version.

Перевірте, що kubectl встановлено і ви можете бачити як версію клієнта, так і версію сервера.

Щоб переглянути вузли в кластері, виконайте команду kubectl get nodes.

Ви побачите доступні вузли. Пізніше Kubernetes вибере, де розгорнути наш застосунок на основі ресурсів, доступних на вузлах.

Розгортання застосунку

Розгорнімо наш перший застосунок на Kubernetes за допомогою команди kubectl create deployment. Ми повинні вказати назву розгортання та розташування образу застосунку (вкажіть повну URL-адресу репозиторію образів, розміщених за межами Docker Hub).

kubectl create deployment kubernetes-bootcamp --image=gcr.io/google-samples/kubernetes-bootcamp:v1

Відмінно! Ви щойно розгорнули свій перший застосунок, створивши Deployment. Це призвело до виконання для вас кількох дій:

• пошук відповідного вузла, де може бути запущений екземпляр застосунку (у нас доступний лише 1 вузол)
• планування запуску застосунку на цьому вузлі
• налаштування кластера для перепланування екземпляра на новому вузлі за необхідності

Щоб переглянути ваші розгортання, використовуйте команду kubectl get deployments:

kubectl get deployments

Ми бачимо, що є 1 розгортання, яке запускає один екземпляр вашого застосунку. Екземпляр працює в контейнері на вашому вузлі.

Перегляд застосунку

Podʼи, які працюють всередині Kubernetes, запущені в ізольованій приватній мережі. Типово вони видимі з інших Podʼів та служб всередині того ж самого кластера Kubernetes, але не за межами цієї мережі. Коли ми використовуємо kubectl, ми взаємодіємо через точку доступу API для спілкування з нашим застосунком.

Розглянемо інші варіанти того, як вивести наш застосунок за межі кластера Kubernetes пізніше, в Модулі 4. Також, як у базовому посібнику, тут ми не пояснюємо докладно, що таке Podʼи, це буде розглянуто в подальших темах.

Команда kubectl proxy може створити проксі, який буде пересилати дані в мережу, що охоплює весь кластер. Роботу проксі можна завершити, натиснувши control-C, і він не виводитиме жодного результату під час роботи.

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

kubectl proxy

Тепер у нас є зʼєднання між вашим хостом (терміналом) та кластером Kubernetes. Проксі дозволяє безпосередній доступ до API з цих терміналів.

Ви можете побачити всі ці API, розміщені через проксі-endpoint. Наприклад, ми можемо запитати версію напряму через API, використовуючи команду curl:

curl http://localhost:8001/version

Сервер API автоматично створює точку доступу для кожного Podʼа на основі імені Podʼа, яка також доступна через проксі.

Спочатку нам потрібно отримати імʼя Podʼа, і ми збережемо його в змінну оточення POD_NAME:

export POD_NAME=$(kubectl get pods -o go-template --template '{{range .items}}{{.metadata.name}}{{"\n"}}{{end}}')
echo Name of the Pod: $POD_NAME

Ви можете отримати доступ до Podʼа через проксі-API, запустивши:

curl http://localhost:8001/api/v1/namespaces/default/pods/$POD_NAME:8080/proxy/

Для того, щоб нове розгортання було доступним без використання проксі, потрібен сервіс, про що буде розказано в Модулі 4.

Мета

• Дізнатися, що таке Podʼи Kubernetes.
• Дізнатися, що таке вузли Kubernetes.
• Діагностика розгорнутих застосунків.

Podʼи Kubernetes

Коли ви створили Deployment у модулі 2, Kubernetes створив Pod, щоб розмістити ваш застосунок. Pod — це абстракція в Kubernetes, що являє собою групу з одного або декількох контейнерів застосунку (таких як Docker) та ресурсів, спільних для цих контейнерів. До цих ресурсів належать:

• Спільні сховища даних, або Volumes
• Мережа, адже кожен Pod у кластері має унікальну IP-адресу
• Інформація про запуск кожного контейнера, така як версія образу контейнера або використання певних портів

Pod моделює специфічний для даного застосунку "логічний хост" та може містити різні, але доволі щільно звʼязані один з одним контейнери. Наприклад, в одному Podʼі може бути контейнер з вашим Node.js застосунком та інший контейнер, що передає дані для публікації Node.js вебсерверу. Контейнери в межах Podʼа мають спільну IP-адресу та порти, завжди є сполученими, плануються для запуску разом та запускаються у спільному контексті на одному вузлі.

Pod є неподільною одиницею платформи Kubernetes. Коли ви створюєте Deployment у Kubernetes, цей Deployment створює Podʼи вже з контейнерами всередині, на відміну від створення контейнерів окремо. Кожен Pod привʼязаний до вузла, до якого його було розподілено, і лишається на ньому до припинення роботи (згідно з політикою перезапуску) або видалення. У разі відмови вузла ідентичні Podʼи розподіляються по інших доступних вузлах кластера.

Узагальнена схема Podʼів

Вузли

Pod завжди запускається на вузлі. Вузол — це робоча машина в Kubernetes, віртуальна або фізична, залежно від кластера. Функціонування кожного вузла контролюється панеллю управління. Вузол може мати декілька Podʼів, а панель управління автоматично призначає Podʼи вузлам в кластері. Панель управління Kubernetes автоматично розподіляє Podʼи по вузлах кластера з урахуванням ресурсів, наявних на кожному вузлі.

На кожному вузлі Kubernetes запущені як мінімум:

• Kubelet — процес, що забезпечує обмін даними між панеллю управління Kubernetes та робочим вузлом; kubelet керує Podʼами та контейнерами, запущеним на машині.
• Оточення для запуску контейнерів (таке як Docker) забезпечує завантаження образу контейнера з реєстру, розпакування контейнера та запуск застосунку.

Узагальнена схема вузлів

Виправлення проблем за допомогою kubectl

У модулі 2 ви використовували інтерфейс командного рядка kubectl. Ви будете продовжувати його використовувати в модулі 3 для отримання інформації про розгорнуті застосунки та їхні середовища. За допомогою наступних підкоманд kubectl можна виконати найбільш поширені операції:

• kubectl get — показати перелік ресурсів
• kubectl describe — виведення детальної інформації про ресурс
• kubectl logs — виведення логів контейнера в Podʼі
• kubectl exec — виконання команди в контейнері в Podʼі

Ви можете використовувати ці команди, щоб переглядати інформацію про те, коли були розгорнуті застосунки, який їхній поточний статус, де вони запущені та які їхні конфігурації.

Тепер, коли ми більше знаємо про компоненти нашого кластера та командний рядок, дослідімо наш застосунок.

Перевірка конфігурації застосунку

Перевірмо, чи працює застосунок, який ми розгорнули в попередньому сценарії. Ми використаємо команду kubectl get і подивимося на наявні Podʼи:

kubectl get pods

Якщо Podʼи не запущені, зачекайте кілька секунд і знову спробуйте вивести список Podʼів. Ви можете продовжити, якщо ви бачите, що працює один Pod.

Далі, щоб переглянути, які контейнери є всередині цього Podʼа і які образи використовуються для створення цих контейнерів, ми використовуємо команду kubectl describe pods:

kubectl describe pods

Тут ми бачимо деталі про контейнер Podʼа: IP-адресу, порти та список подій, повʼязаних з життєвим циклом Podʼа.

Вивід підкоманди describe є розлогим і охоплює деякі концепції, які ми ще не пояснили, але не хвилюйтеся, вони стануть зрозумілими до кінця цього курсу.

Примітка: підкоманду describe можна використовувати для отримання детальної інформації про більшість примітивів Kubernetes, включаючи вузли, Podʼи та Deployment. Вивід команди describe призначений для сприйняття людиною, а не для сценаріїв.

Показати застосунок у терміналі

Пригадайте, що Podʼи працюють в ізольованій, приватній мережі — тому нам потрібно налаштувати проксі-доступ до них для налагодження та взаємодії з ними. Для цього ми використовуємо команду kubectl proxy для запуску проксі в іншому терміналі. Відкрийте нове вікно термінала і введіть у цьому новому терміналі:

kubectl proxy

Тепер ми знову отримаємо імʼя Podʼа та будемо звертатись до цього Podʼа безпосередньо через проксі. Щоб отримати імʼя Podʼа та зберегти його в змінну середовища POD_NAME:

export POD_NAME="$(kubectl get pods -o go-template --template '{{range .items}}{{.metadata.name}}{{"\n"}}{{end}}')"
echo Name of the Pod: $POD_NAME

Щоб переглянути вивід нашого застосунку, виконайте запит curl:

curl http://localhost:8001/api/v1/namespaces/default/pods/$POD_NAME:8080/proxy/

URL — це шлях до API Podʼа.

Перегляд логів контейнера

Все, що застосунок зазвичай виводить на стандартний вивід, стає логами контейнера всередині Podʼа. Ми можемо отримати ці логи, використовуючи команду kubectl logs:

kubectl logs "$POD_NAME"

Примітка: Нам не потрібно вказувати імʼя контейнера, оскільки у нас є лише один контейнер всередині Podʼа.

Виконання команди в контейнері

Ми можемо виконувати команди безпосередньо в контейнері після того, як Pod буде запущено та він працюватиме. Для цього ми використовуємо підкоманду exec і вказуємо імʼя Podʼа як параметр. Перегляньмо змінні середовища:

kubectl exec "$POD_NAME" -- env

Знову варто зазначити, що можна пропустити імʼя самого контейнера, оскільки у нас є лише один контейнер в Podʼі.

Далі розпочнім сеанс bash в контейнері Podʼа:

kubectl exec -ti $POD_NAME -- bash

Тепер у нас є відкрита консоль в контейнері, де запущений наш застосунок NodeJS. Вихідний код застосунку знаходиться у файлі server.js:

cat server.js

Ви можете перевірити, чи застосунок запущено, виконавши команду curl:

curl http://localhost:8080

Примітка: тут ми використовували localhost, оскільки ми виконали команду всередині Podʼа NodeJS. Якщо ви не можете підʼєднатися до localhost:8080, перевірте, чи ви виконали команду kubectl exec і запускаєте команду зсередини Podʼа

Щоб закрити підключення до контейнера, введіть exit.

Мета

• Дізнатись про Service у Kubernetes.
• Ознайомитись з тим, як мітки та селектори повʼязані з Service.
• Відкрити доступ до застосунку по за межами Kubernetes кластера.

Огляд Сервісів в Kubernetes

Існування Podʼів в Kubernetes є обмеженими за часом, також вони мають свій життєвий цикл. Коли робочий вузол припиняє існування, також втрачаються Podʼи, які виконуються на цьому вузлі. ReplicaSet може динамічно приводити кластер до бажаного стану шляхом створення нових Podʼів, щоб ваш застосунок продовжував працювати. Наприклад, розгляньмо обробник зображень, що має 3 копії. Ці копії (репліки) можуть бути взаємозамінні; система форонтенду не повинна перейматися репліками бекенду або навіть тим, чи Pod втрачено та створено наново. Проте кожен Pod в кластері Kubernetes має унікальну IP-адресу, навіть Podʼи на одному вузлі, тому потрібно мати спосіб автоматичного узгодження змін серед Podʼів, щоб ваші застосунки продовжували працювати.

Service в Kubernetes є абстракцією, яка визначає логічний набір Podʼів та політику доступу до них. Serviceʼи забезпечують слабку звʼязаність між залежними Podʼами. Service визначається за допомогою YAML або JSON, так само як і всі обʼєкти Kubernetes. Набір Podʼів, на які призначений Service, зазвичай визначається селектором міток (label selector) (див. нижче, чому selector іноді не включають у специфікацію Service).

Хоча кожний Pod має унікальну IP-адресу, ці IP не доступні за межі кластера без використання Service. Serviceʼи уможливлюють надходження трафіку до ваших застосунків. Serviceʼи можуть бути оприлюднені у різний спосіб, за допомогою type у spec Service:

• ClusterIP (типове значення) — відкриває доступ до внутрішнього IP Service в кластері. Цей тип робить Service доступним лише зсередини кластера.
• NodePort — відкриває доступ до Service на тому ж порті кожного обраного вузла в кластері за допомогою NAT. Робить Service доступним ззовні кластера за допомогою <NodeIP>:<NodePort>. Є надмножиною відносно ClusterIP.
• LoadBalancer — створює зовнішній балансувальник навантаження в поточному хмарному середовищі (якщо підтримується) та призначає фіксовану зовнішню IP-адресу для Service. Є надмножиною відносно NodePort.
• ExternalName — звʼязує Service з вмістом поля externalName (наприклад, foo.bar.example.com), повертаючи запис CNAME із його значенням. Не встановлюється жодного проксі. Цей тип вимагає v1.7 або вище kube-dns або CoreDNS версії 0.0.8 або вище.

Додаткову інформацію про різновиди Service можна знайти у посібнику Використання IP-адреси джерела. Дивіться також Підключення застосунків за допомогою Service.

Крім того, слід зауважити, що існують випадки використання Service, при яких не визначається selector у специфікації. Service, створений без selector, також не створить відповідний обʼєкт Endpoints. Це дозволяє користувачам вручну відкривати доступ Service на конкретні точки доступу. Ще одна можливість, чому може бути відсутній селектор — використання виключно type: ExternalName.

Services та мітки (Labels)

Service маршрутизує трафік набору Podʼів. Service є абстракцією, яка дозволяє Podʼам зникати та реплікуватися в Kubernetes, не впливаючи на ваш застосунок. Виявлення та маршрутизація серед залежних Podʼів (таких як компоненти frontend та backend у застосунку) обробляються Serviceʼами Kubernetes.

Service визначають набір Podʼів за допомогою міток та селекторів, примітиву гуртування, який дозволяє логічно взаємодіяти з обʼєктами в Kubernetes. Мітки — це пари ключ/значення, призначені обʼєктам та можуть бути використані різними способами:

• Призначення обʼєктів до оточення розробки, тестування та експлуатації
• Вбудовування теґів версій
• Класифікація обʼєкта за допомогою теґів

Мітки можна прикріплювати до обʼєктів при їх створенні або пізніше. Їх можна змінювати в будь-який час. Давайте зараз використаємо Service для надання доступу до нашого застосунку та застосуємо деякі мітки.

Крок 1: Створення нового Service

Перевіримо, що наш застосунок працює. Ми використовуватимемо команду kubectl get та переглядатимемо наявні Podʼи:

kubectl get pods

Якщо Podʼи не запущені, це означає, що обʼєкти з попередніх кроків були видалені. У цьому випадку поверніться та створіть Deployment з посібника Використання kubectl для створення Deployment. Зачекайте кілька секунд та перегляньте список Podʼів знову. Ви можете продовжити, як тільки побачите, що один Pod працює.

Далі виведемо список наявних Serviceʼів у нашому кластері:

kubectl get services

У нас є Service з назвою kubernetes, яка створюється стандартно, коли minikube запускає кластер. Щоб створити новий Service та зробити зовнішній трафік доступним для нього, ми використовуватимемо команду expose з параметром NodePort.

kubectl expose deployment/kubernetes-bootcamp --type="NodePort" --port 8080

Давайте знову запустимо команду get services:

kubectl get services

Тепер у нас є робочий Service з назвою kubernetes-bootcamp. Тут ми бачимо, що Service отримав унікальний IP в кластері, внутрішній порт та зовнішній IP (IP вузла).

Щоб дізнатися, який порт був відкритий ззовні (для Serviceʼу з type: NodePort), ми запустимо команду describe service:

kubectl describe services/kubernetes-bootcamp

Створимо змінну середовища з назвою NODE_PORT, яка матиме значення порту вузла:

export NODE_PORT="$(kubectl get services/kubernetes-bootcamp -o go-template='{{(index .spec.ports 0).nodePort}}')"
echo "NODE_PORT=$NODE_PORT"

Тепер ми можемо перевірити, що застосунок отримав доступ за межі кластера, використовуючи curl, IP-адресу вузла та зовнішній порт:

curl http://"$(minikube ip):$NODE_PORT"

http://127.0.0.1:51082
!  Because you are using a Docker driver on darwin, the terminal needs to be open to run it.

І, ми отримуємо відповідь від сервера. Service — працює.

Крок 2: Використання міток

Мета

• Масштабування застосунку за допомогою kubectl.

Масштабування Застосунку

Раніше ми створили Deployment, а потім робили його загальнодоступним за допомогою Service. Deployment створив лише один Pod для запуску нашого pfcnjceyre. Зі збільшенням трафіку, нам потрібно масштабувати застосунок, щоб відповідати зростаючим вимогам користувачів.

Якщо ви ще не працювали над попередніми розділами, почніть з Використання minikube для створення кластера.

Масштабування досягається зміною кількості реплік в Deployment.

Огляд масштабування

Масштабування Deployment гарантує створення нових Podʼів і їх призначення на Вузли з вільними ресурсами. Масштабування збільшить кількість Podʼів до нового бажаного стану. Kubernetes також підтримує автоматичне масштабування Podʼів, але це виходить за рамки цього посібника. Також можливе масштабування до нуля, і це призведе до завершення всіх Podʼів вказаного Deployment.

Запуск кількох екземплярів застосунку вимагає засобів для розподілу трафіку між ними. У Service є вбудований балансер навантаження, який розподілить мережевий трафік на всі Podʼи, що виставлені Deployment. Service будуть постійно відстежувати робочі Podʼи, використовуючи точки доступу, щоб гарантувати, що трафік направляється лише на доступні Podʼи.

Якщо у вас є кілька екземплярів застосунку, ви зможете робити оновлення без перерв. Ми розглянемо це в наступному розділі посібника. Тепер перейдемо до термінала та масштабуємо наш застосунок.

Масштабування Deployment

Щоб переглянути свій Deployment, використовуйте команду get deployments:

kubectl get deployments

Вивід повинен бути схожий на:

    NAME                  READY   UP-TO-DATE   AVAILABLE   AGE
    kubernetes-bootcamp   1/1     1            1           11m
    

Маємо 1 Pod. Якщо цього немає, виконайте команду ще раз. Тут маємо:

• NAME — назви Deployment в кластері.
• READY — показує співвідношення поточних/бажаних реплік
• UP-TO-DATE — показує кількість реплік, які були оновлені для досягнення бажаного стану.
• AVAILABLE — показує, скільки реплік застосунку доступні користувачам.
• AGE — показує час, протягом якого застосунок працює.

Щоб переглянути ReplicaSet, створений Deployment, виконайте:

kubectl get rs

Зверніть увагу, що назва ReplicaSet завжди форматується як [DEPLOYMENT-NAME]-[ВИПАДКОВИЙ-РЯДОК]. Випадковий рядок генерується випадковим чином та використовує pod-template-hash як основу для створеня.

Два важливі стовпці цього виводу:

• DESIRED — показує бажану кількість реплік застосунку, яку ви визначаєте під час створення Deployment. Це бажаний стан.
• CURRENT — показує, скільки реплік в цей час працюють.

Далі масштабуймо Deployment до 4 реплік. Ми використаємо команду kubectl scale, за якою слідує тип Deployment, назва та бажана кількість екземплярів:

kubectl scale deployments/kubernetes-bootcamp --replicas=4

Щоб знову переглянути свої Deployment, використовуйте get deployments:

kubectl get deployments

Зміни були застосовані, і у нас є 4 екземпляри застосунку. Далі перевірмо, чи змінилася кількість Podʼів:

kubectl get pods -o wide

Тепер є 4 Podʼа з різними IP-адресами. Зміна була зареєстрована в журналі подій Deployment. Щоб перевірити це, використовуйте команду describe:

kubectl describe deployments/kubernetes-bootcamp

Ви також можете побачити, що у виводі цієї команди тепер є 4 репліки.

Балансування навантаження

Перевіримо, чи Service балансує трафік. Щоб дізнатися зовнішній IP та порт, ми можемо використовувати команду describe, як ми дізнались в попередній частині посібника:

kubectl describe services/kubernetes-bootcamp

Створіть змінну середовища з іменем NODE_PORT, яка має значення як порт Вузла:

export NODE_PORT="$(kubectl get services/kubernetes-bootcamp -o go-template='{{(index .spec.ports 0).nodePort}}')"

echo NODE_PORT=$NODE_PORT

Далі ми запустимо curl з зовнішньою IP-адресою та портом. Виконайте команду кілька разів:

curl http://"$(minikube ip):$NODE_PORT"

Ми потрапляємо на різні Podʼи при кожному запиті. Це демонструє, що балансування навантаження працює.

http://127.0.0.1:51082
!  Оскільки ви використовуєте драйвер Docker на darwin, термінал повинен бути відкритий для його запуску.

Зменшення розгортання

Щоб зменшити Deployment до 2 реплік, знову запустіть команду scale:

kubectl scale deployments/kubernetes-bootcamp --replicas=2

Перевірте Deployment, щоб переконатися, що зміни були застосовані, за допомогою команди get deployments:

kubectl get deployments

Кількість реплік зменшилася до 2. Перегляньте кількість Podʼів за допомогою get pods:

kubectl get pods -o wide

Це підтверджує, що роботу двох Podʼів було завершено.

Мета

• Виконати розгортання з оновленням за допомогою kubectl.

Оновлення застосунку

Користувачі очікують, що застосунки будуть доступні цілодобово, і очікується, що розробники розгортатимуть нові версії кілька разів на день. У Kubernetes це робиться за допомогою розгортань з поступовим оновленням. Поступове оновлення (rolling update) дозволяє виконати оновлення Deployment без перерви в роботі застосунку. Це досягається поетапною заміною поточних Podʼів новими. Нові Podʼи призначаються вузлам з вільними ресурсами, а Kubernetes чекає, доки ці нові Podʼи не почнуть працювати, перш ніж вилучити старі Podʼи.

У попередньому розділі ми масштабували наш застосунок для запуску кількох екземплярів. Це є вимогою для виконання оновлень без впливу на доступність застосунку. Стандартно максимальна кількість Podʼів, які можуть бути недоступні під час оновлення, та максимальна кількість нових Podʼів, які можуть бути створені, дорівнює одному. Обидві опції можуть бути налаштовані як у вигляді точної кількості, так і у відсотках (від усіх Podʼів). У Kubernetes оновлення мають версії, і будь-яке оновлення Deployment може бути повернуте до попередньої (стабільної) версії.

Огляд поступового оновлення

Аналогічно масштабуванню застосунку, якщо Deployment є публічно доступним, Service буде балансувати трафік лише на доступні Podʼи під час оновлення. Доступний Pod — це екземпляр, який доступний користувачам застосунку.

Поступові оновлення дозволяють виконувати наступні дії:

• Просування застосунку з одного середовища в інше (за допомогою оновлень образів контейнерів)
• Відкат до попередніх версій
• Неперервна інтеграція та постійна доставка застосунків без перерви в роботі

У наступному інтерактивному практикумі ми оновимо наш застосунок до нової версії та виконаємо відкат.

Оновлення версії застосунку

Для виведення списку Deploymentʼів виконайте команду get deployments: kubectl get deployments

Для виведення списку запущених Podʼів виконайте команду get pods:

kubectl get pods

Для перегляду поточної версії образу застосунку виконайте команду describe pods та шукайте поле Image:

kubectl describe pods

Для оновлення образу застосунку до версії 2 використовуйте команду set image, за якою йде назва Deployment та нова версія образу:

kubectl set image deployments/kubernetes-bootcamp kubernetes-bootcamp=docker.io/jocatalin/kubernetes-bootcamp:v2

Команда повідомляє Deployment про використання іншого образу для вашого застосунку та запускає поступове оновлення. Перевірте стан нових Podʼів та перегляньте той, що відключається, використовуючи команду get pods:

kubectl get pods

Перевірка оновлення

Спочатку перевірте, чи Service працює, бо ви могли його видалити його на попередньому кроці, виконайте kubectl describe services/kubernetes-bootcamp. Якщо його немає, створіть його знов:

kubectl expose deployment/kubernetes-bootcamp --type="NodePort" --port 8080

Створіть змінну середовища з іменем NODE_PORT зі значенням призначеного порту вузла:

export NODE_PORT="$(kubectl get services/kubernetes-bootcamp -o go-template='{{(index .spec.ports 0).nodePort}}')"
echo "NODE_PORT=$NODE_PORT"

Потім виконайте curl з зовнішньою IP-адресою та портом:

curl http://"$(minikube ip):$NODE_PORT"

Кожен раз, коли ви виконуєте команду curl, ви попадете на різні Podʼи. Зверніть увагу, що всі Podʼи зараз працюють на останній версії (v2).

Ви також можете підтвердити оновлення, використовуючи команду rollout status:

kubectl rollout status deployments/kubernetes-bootcamp

Для перегляду поточної версії образу застосунку виконайте команду describe pods:

kubectl describe pods

У полі Image перевірите, що ви використовуєте останню версію образу (v2).

Відкат оновлення

Виконаймо ще одне оновлення та спробуємо розгорнути образ з теґом v10:

kubectl set image deployments/kubernetes-bootcamp kubernetes-bootcamp=gcr.io/google-samples/kubernetes-bootcamp:v10

Використовуйте get deployments, щоб переглянути стан розгортання:

kubectl get deployments

Зверніть увагу, що вивід не вказує бажану кількість доступних Podʼів. Використайте команду get pods, щоб вивести список всіх Podʼів:

kubectl get pods

Зверніть увагу, що деякі Podʼи мають статус ImagePullBackOff.

Щоб отримати більше відомостей про проблему, використовуйте команду describe pods:

kubectl describe pods

У розділі Events виводу для проблемних Podʼів, зверніть увагу, що версії образу v10 немає в репозиторії.

Щоб відкотити розгортання до попередньої робочої версії, використовуйте команду rollout undo:

kubectl rollout undo deployments/kubernetes-bootcamp

Команда rollout undo повертає розгортання до попередньо відомого стану (v2 образу). Оновлення мають версії, і ви можете повернутися до будь-якого раніше відомого стану розгортання.

Використайте команду get pods, щоб знову вивести список Podʼів:

kubectl get pods

Чотири Podʼи працюють. Щоб перевірити образ, розгорнутий на цих Podʼах, використайте команду describe pods:

kubectl describe pods

Розгортання знову використовує стабільну версію застосунку (v2). Відкат був успішним.

Не забудьте очистити свій локальний кластер

kubectl delete deployments/kubernetes-bootcamp services/kubernetes-bootcamp