Цей посібник надає інструкції з основ системи оркестрування кластерів Kubernetes. Кожний модуль містить деяку вступну інформацію про основні функції та концепції Kubernetes, а також практичний посібник, за яким ви можете вчитися.
За допомогою цих посібників ви дізнаєтесь:
Як розгорнути контейнеризований застосунок в кластері.
Як масштабувати Deployment.
Як оновити версію контейнеризованого застосунку.
Як налагодити контейнеризований застосунок.
Чим Kubernetes може бути корисний для вас?
З сучасними вебсервісами користувачі очікують доступності застосунків 24/7, а розробники прагнуть розгортати нові версії цих застосунків кілька разів на день. Контейнеризація допомагає упаковувати програмне забезпечення для досягнення цих цілей, дозволяючи випускати оновлення застосунків без перерви в роботі. Kubernetes допомагає забезпечити те, що контейнеризовані застосунки працюватимуть там і тоді, де це потрібно, та надає їм необхідні ресурси та інструменти для ефективної роботи. Kubernetes — це готова до використання, відкрита платформа, розроблена на основі здобутого Google досвіду в оркеструванні контейнерів, поєднаного з найкращими ідеями та практиками спільноти.
Дізнайтесь про кластери Kubernetes та створіть простий кластер за допомогою Minikube.
1.1 - Використання Minikube для створення кластера
Цілі
Дізнайтесь, що таке Kubernetes кластер.
Дізнайтесь, що таке Minikube.
Запустіть кластер Kubernetes на вашому компʼютері.
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.
2.1 - Використання kubectl для створення Deployment
Цілі
Дізнайтесь, що таке Deployment застосунків.
Розгорніть свій перший застосунок у Kubernetes за допомогою kubectl.
Процеси Kubernetes Deployment
Deployment відповідає за створення та оновлення екземплярів для вашого застосунку.
Примітка:
Цей навчальний посібник використовує контейнер, який вимагає архітектури AMD64. Якщо ви використовуєте minikube на компʼютері з іншою архітектурою процесора, ви можете спробувати використовувати minikube з драйвером, який може емулювати AMD64. Наприклад, драйвер Docker Desktop може це зробити.
Після запуску кластера Kubernetes ви можете розгортати свої контейнеризовані застосунки на його основі. Для цього створіть Deployment (розгортання) Kubernetes. Deployment вказує Kubernetes, як створювати та оновлювати екземпляри вашого застосунку. Після створення Deployment панель управління Kubernetes розподіляє екземпляри застосунків, що включені в цей Deployment, для запуску на окремих Вузлах в кластері.
Коли екземпляри застосунків створені, контролер Deployment безперервно відстежує їх стан. Якщо вузол, на якому запущено екземпляр, вимикається або видаляється, контролер Deployment замінює екземпляр новим на іншому вузлі в кластері. Це забезпечує механізм самовідновлення для розвʼязання проблем з відмовою або обслуговуванням вузлів.
У світі до ери оркестрування часто використовувалися скрипти встановлення для запуску застосунків, але вони не дозволяли відновлення після відмови вузла. Шляхом як створення екземплярів застосунків, так і утримання їх в робочому стані на різних вузлах, Deployments Kubernetes забезпечує принципово новий підхід до управління застосунками.
Розгортання вашого першого застосунку в Kubernetes
Для того, щоб розгортати застосунки в Kubernetes, їх потрібно упакувати в один із підтримуваних форматів контейнерів
Ви можете створювати та управляти Deployment (розгортанням) за допомогою інтерфейсу командного рядка Kubernetes — kubectl. kubectl використовує API Kubernetes для взаємодії з кластером. У цьому модулі ви вивчите найпоширеніші команди kubectl, які потрібні для створення Deployment та запуску застосунків в кластері Kubernetes.
Коли ви створюєте Deployment, вам необхідно вказати образ контейнера вашого застосунку та скільки його реплік ви бажаєте запустити. Згодом цю інформацію можна змінити, оновивши ваш Deployment; Модуль 5
та Модуль 6 розповідають, як масштабувати та оновлювати ваші Deploymentʼи.
Для вашого першого 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).
Відмінно! Ви щойно розгорнули свій перший застосунок, створивши розгортання. Це призвело до виконання для вас кількох дій:
пошук відповідного вузла, де може бути запущений екземпляр застосунку (у нас доступний лише 1 вузол)
планування запуску застосунку на цьому Вузлі
налаштування кластера для перепланування екземпляра на новому Вузлі за необхідності
Щоб переглянути ваші розгортання, використовуйте команду kubectl get deployments:
kubectl get deployments
Ми бачимо, що у нас є 1 розгортання, яке запускає один екземпляр вашого застосунку. Екземпляр працює в контейнері на вашому вузлі.
Перегляд застосунку
Podʼи, які працюють всередині Kubernetes, запущені в ізольованій приватній мережі. Стандартно вони видимі з інших podʼів та сервісів всередині того ж самого кластера Kubernetes, але не за межами цієї мережі. Коли ми використовуємо kubectl, ми взаємодіємо через точку доступу API для спілкування з нашим застосунком.
Розглянемо інші варіанти того, як експонувати наш застосунок за межі кластера Kubernetes пізніше, в Модулі 4. Також, як у базовому посібнику, тут ми не пояснюємо докладно, що таке Pods, це буде розглянуто в подальших темах.
Команда kubectl proxy може створити проксі, який буде пересилати дані в мережу, що охоплює весь кластер. Роботу проксі можна завершити комбінацією Control-C, і він не виводитиме жодного результату під час роботи.
Для запуску проксі потрібно відкрити друге вікно термінала.
kubectl proxy
Тепер у нас є зʼєднання між вашим хостом (терміналом) та кластером Kubernetes. Проксі дозволяє безпосередній доступ до API з цих терміналів.
Ви можете побачити всі ці API, що знаходяться за точкою доступу проксі. Наприклад, ми можемо запитати версію напряму через API, використовуючи команду curl:
curl http://localhost:8001/version
Примітка:
Якщо порт 8001 недоступний, переконайтеся, що команда kubectl proxy, яку ви запустили вище, працює в другому терміналі.
Сервер API автоматично створює точку доступу для кожного podʼа на основі імені podʼа, яка також доступна через проксі.
Спочатку нам потрібно отримати імʼя Podʼа, і ми збережемо його в змінну оточення POD_NAME.
exportPOD_NAME=$(kubectl get pods -o go-template --template '{{range .items}}{{.metadata.name}}{{"\n"}}{{end}}')echo Name of the Pod: $POD_NAME
Ви можете отримати доступ до Podʼа через API за допомогою проксі, виконавши команду:
Pod — це група з одного або декількох контейнерів (таких як Docker), що має спільне сховище даних (volumes), IP-адресу та містить інформацію про те, як їх запустити.
Коли ви створили Deployment у Модулі 2, Kubernetes створив Pod, щоб розмістити екземпляр вашого застосунку. Pod — це абстракція в Kubernetes, що являє собою групу з одного або декількох контейнерів застосунку (таких як Docker) та ресурсів, спільних для цих контейнерів. До цих ресурсів належать:
Спільні сховища даних, або Volumes
Мережа, адже кожен Pod у кластері має унікальну IP-адресу
Інформація про те, як запускати кожний контейнер, така як версія образу контейнера або використання певних портів
Pod моделює специфічний для даного застосунку "логічний хост" та може містити різні, але доволі тісно повʼязані один з одним контейнери. Наприклад, в одному Podʼі може бути контейнер з вашим Node.js застосунком та інший контейнер, що передає дані Node.js для публікації вебсервером. Контейнери в межах Podʼа мають спільну IP-адресу та порти, завжди є сполученими, плануються для запуску разом та запускаються у спільному контексті на одному Node (вузлі).
Pod є неподільною атомарною одиницею платформи Kubernetes. Коли ви створюєте Deployment у Kubernetes, цей Deployment створює Podʼи вже з контейнерами всередині, на відміну від створення контейнерів окремо. Кожен Pod привʼязаний до вузла, до якого його було розподілено, і лишається на ньому до припинення роботи (згідно з політикою перезапуску) або видалення. У разі відмови вузла ідентичні Podʼи розподіляються по інших доступних Вузлах кластера.
Узагальнена схема Podʼів
Контейнери слід розміщувати разом в одному Podʼі, тільки якщо вони тісно повʼязані між собою і потребують спільного використання ресурсів, таких як диск.
Вузли
Pod завжди запускається на Node (Вузлі). 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, включаючи Node, Podʼи та Deployment. Вивід команди describe призначений для сприйняття людиною, а не для створення скриптів.
Показати застосунок у терміналі
Памʼятаєте, що Podʼи працюють в ізольованій, приватній мережі — тому нам потрібно налаштувати проксі-доступ до них для налагодження та взаємодії з ними. To do this, Для цього ми використовуємо команду kubectl proxy для запуску проксі в іншому терміналі. Відкрийте нове вікно термінала і введіть у цьому новому терміналі:
kubectl proxy
Тепер ми знову отримаємо імʼя Podʼа та будемо звертатись до цього Podʼа безпосередньо через проксі. Щоб отримати імʼя Podʼа та зберегти його в змінну середовища POD_NAME:
exportPOD_NAME="$(kubectl get pods -o go-template --template '{{range .items}}{{.metadata.name}}{{"\n"}}{{end}}')"echo Name of the Pod: $POD_NAME
Щоб переглянути вивід нашого застосунку, виконайте запит curl:
Нам не потрібно вказувати імʼя контейнера, оскільки у нас є лише один контейнер всередині podʼа.
Виконання команди в контейнері
Ми можемо виконувати команди безпосередньо в контейнері після того, як Pod буде запущено та він працюватиме. Для цього ми використовуємо команду exec і вказуємо імʼя Podʼа як параметр. Перегляньмо змінні середовища:
kubectl exec"$POD_NAME" -- env
Знову варто зазначити, що можна пропустити імʼя самого контейнера, оскільки у нас є лише один контейнер в Podʼі.
Далі розпочнімо сеанс bash в контейнері Podʼа:
kubectl exec -ti $POD_NAME -- bash
Тепер у нас є відкрита консоль в контейнері, де запущений наш застосунок NodeJS. Вихідний код застосунку знаходиться у файлі server.js:
cat server.js
You can check that the application is up by running a curl command:
curl http://localhost:8080
Примітка:
тут ми використовували localhost, оскільки ми виконали команду всередині Podʼа NodeJS. Якщо ви не можете підʼєднатися до localhost:8080, перевірте, чи ви виконали команду kubectl exec і запускаєте команду зсередини Podʼа.
Щоб закрити підключення до контейнера, введіть exit.
4.1 - Використання Service для доступу до застосунку
Цілі
Дізнайтесь про Service у Kubernetes.
найомтесь з тим, як мітки та селектори повʼязані з Service.
Відкрийте доступ до застосунку по за межами Kubernetes кластера.
Огляд Сервісів в Kubernetes
Існування Podʼів в Kubernetes є обмеженими за часом, також вони мають свій життєвий цикл. Коли робочий вузол припиняє існування, також втрачаються Podʼи, які виконуються на цьому Вузлі. Replicaset може динамічно приводити кластер до бажаного стану шляхом створення нових Podʼів, щоб ваш застосунок продовжував працювати. As another example, consider an image-processing
backend with 3 replicas. Наприклад, розгляньмо обробник зображень, що має 3 копії. Ці копії (репліки) можуть бути взаємозамінні; система форонтенду не повинна перейматися репліками бекенду або навіть тим, чи Pod втрачено та створено наново. Проте кожен Pod в кластері Kubernetes має унікальну IP-адресу, навіть Podʼи на одному Вузлі, тому потрібно мати спосіб автоматичного узгодження змін серед Podʼів, щоб ваші застосунки продовжували працювати.
Service в Kubernetes – це рівень абстракції, який визначає логічний набір 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 (стандартно) — експонує Service на внутрішній IP-адресі в кластері. Цей тип робить 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, при яких не визначається selector у специфікації. Service, створений без selector також не створить відповідний обʼєкт Endpoints. Це дозволяє користувачам вручну відкривати доступ Service на конкретні точки доступу. Ще одна можливість, чому може бути відсутній селектор — використання виключно type: ExternalName.
Services та мітки (Labels)
Service маршрутизує трафік набору Podʼів. Service є абстракцією, яка дозволяє podʼам зникати та відновлюватись в Kubernetes, не впливаючи на ваш застосунок. Виявлення та маршрутизація серед залежних Podʼів (таких як компоненти frontend та backend у застосунку) обробляються Serviceʼами Kubernetes.
Services поєднуються з набором Podʼів використовуючи мітки та селектори, примітиву гуртування, який дозволяє логічно взаємодіяти з обʼєктами в Kubernetes. Мітки — це пари ключ/значення, призначені обʼєктам та можуть бути використані різними способами:
Призначення обʼєктів до оточення розробки, тестування та промислової експлуатації
Вбудовування теґів версій
Класифікація обʼєкта за допомогою теґів
Мітки можна прикріплювати до обʼєктів при їх створенні або пізніше. Їх можна змінювати в будь-який час. Давайте зараз використаємо Service для надання доступу до нашого застосунку та застосуємо деякі мітки.
Крок 1: Створення нового Service
Перевіримо, що наш застосунок працює. Ми використовуватимемо команду kubectl get та подивимось на наявні Podʼи:
kubectl get pods
Якщо Podʼи не запущені, це означає, що обʼєкти з попередніх кроків були видалені. У цьому випадку поверніться та створіть Deployment з посібника Використання kubectl для створення Deployment. Зачекайте кілька секунд та перегляньте список Podʼів знову. Ви можете продовжити, як тільки побачите, що один Pod працює.
Далі виведемо список наявних Serviceʼів у нашому кластері:
kubectl get services
Для експонування розгортання для зовнішнього трафіку ми будемо використовувати команду kubectl expose з параметром --type=NodePort:
Тепер у нас є запущений Service з назвою kubernetes-bootcamp. Тут ми бачимо, що Service отримав унікальну кластерну IP-адресу, внутрішній порт і зовнішню IP-адресу (IP-адресу Вузла).
Щоб дізнатися, який порт було відкрито назовні (для сервісу type: NodePort), виконаємо підкоманду describe service:
kubectl describe services/kubernetes-bootcamp
Створіть змінну оточення з назвою NODE_PORT, якій буде присвоєно значення порту вузла:
exportNODE_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"
Примітка:
Якщо ви використовуєте minikube з Docker Desktop як драйвер контейнера, потрібно використовувати minikube tunnel. Це тому, що контейнери всередині Docker Desktop ізольовані від вашого компʼютера.
В окремому вікні термінала виконайте:
minikube service kubernetes-bootcamp --url
Вивід виглядає так:
http://127.0.0.1:51082
! Because you are using a Docker driver on darwin, the terminal needs to be open to run it.
Потім використовуйте вказаний URL для доступу до застосунку:
curl 127.0.0.1:51082
І, ми отримуємо відповідь від сервера. Service — працює.
Крок 2: Використання міток
Deployment автоматично створив мітку для нашого Podʼа. За допомогою команди describe deployment ви можете побачити імʼя (ключ) цієї мітки:
kubectl describe deployment
Використаємо цю мітку для отримання списку наших Podʼів. Ми використовуватимемо команду kubectl get pods з параметром -l, за яким слідують значення мітки:
kubectl get pods -l app=kubernetes-bootcamp
Ви можете зробити те саме, щоб вивести список поточних Services:
kubectl get services -l app=kubernetes-bootcamp
Отримайте назву Podʼа та збережіть її в змінній середовища POD_NAME:
exportPOD_NAME="$(kubectl get pods -o go-template --template '{{range .items}}{{.metadata.name}}{{"\n"}}{{end}}')"echo"Name of the Pod: $POD_NAME"
Для застосування нової мітки ми використовуємо команду label за якою слідує тип обʼєкта, назва обʼєкта та нова мітка:
kubectl label pods "$POD_NAME"version=v1
Це додасть нову мітку до нашого Podʼа (ми закріпили версію програми для Podʼа), і ми можемо перевірити це за допомогою команди describe pod:
kubectl describe pods "$POD_NAME"
Тут ми бачимо, що мітка тепер прикріплена до нашого Podʼа. Тепер ми можемо переглянути список podʼів за допомогою нової мітки:
kubectl get pods -l version=v1
І, ми бачимо Pod.
Крок 3: Видалення Service
Для видалення Service ви можете використовувати команду delete service. Тут також можна використовувати мітки:
kubectl delete service -l app=kubernetes-bootcamp
Переконайтеся, що Service видалено:
kubectl get services
Це підтверджує, що наш Service видалено. Щоб переконатися, що маршрут більше не експонується, ви можете перевірити раніше експоновані IP та порт за допомогою curl:
curl http://"$(minikube ip):$NODE_PORT"
Це доводить, що застосунок більше не доступний ззовні кластера. Ви можете переконатись, що застосунок все ще працює за допомогою curl з середини podʼа:
Тут ми бачимо, що застосунок працює. Це тому, що Deployment управляє застосунком. Для припинення роботи застосунку вам слід видалити також й Deployment.
5.1 - Запуск кількох екземплярів вашого застосунку
Цілі
Масштабування застосунку вручну за допомогою kubectl.
Масштабування застосунку
Ви можете створити Deployment з декількома екземплярами з самого початку за допомогою параметра --replicas команди kubectl create deployment.
Раніше ми створили Deployment, а потім робили його загальнодоступним за допомогою Service. Deployment створив лише один Pod для запуску нашого застосунку. Зі збільшенням трафіку, нам потрібно масштабувати застосунок, щоб відповідати зростаючим вимогам користувачів.
Масштабування досягається зміною кількості реплік в Deployment..
Примітка:
Якщо ви спробуєте це після попереднього розділу, то, можливо, ви видалили Service, який створили, або створили Service з type: NodePort. У цьому розділі припускається, що для Deployment kubernetes-bootcamp створено Service з type: LoadBalancer.
Якщо ви не видалили Service, створений у попередньому розділі, спочатку видаліть цей Service, а потім запустіть наступну команду для створення нового Service з параметром type встановленим на LoadBalancer:
Масштабування здійснюється шляхом зміни кількості реплік у Deployment.
Масштабування Deployment гарантує створення нових Podʼів і їх призначення на Вузли з вільними ресурсами. Масштабування збільшить кількість Podʼів до нового бажаного стану. Kubernetes також підтримує автоматичне масштабування Podʼів, але це виходить за рамки цього посібника. Також можливе масштабування до нуля, і це призведе до завершення всіх Podʼів вказаного Deployment.
Запуск кількох екземплярів застосунку вимагає засобів для розподілу трафіку між ними. У Service є вбудований балансувальник навантаження, який розподілить мережевий трафік на всі Podʼи, які експонує Deployment. Service будуть постійно відстежувати робочі Podʼи, використовуючи точки доступу, щоб гарантувати, що трафік направляється лише на доступні Podʼи.
Після того, як ви запустите кілька екземплярів застосунку, ви зможете виконувати Rolling-оновлення без простоїв. Ми розглянемо це у наступному розділі підручника. Тепер перейдемо до термінала і масштабуємо наш застосунок.
Масштабування 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]-[RANDOM-STRING]. Випадковий рядок генерується випадковим чином та використовує pod-template-hash як основу для створення.
Два важливі стовпці цього виводу:
DESIRED — показує бажану кількість реплік застосунку, яку ви визначаєте під час створення Deployment. Це бажаний стан.
CURRENT — показує, скільки реплік в цей час працюють.
Далі масштабуймо Deployment до 4 реплік. Ми використаємо команду kubectl scale, за якою слідує тип Deployment, назва та бажана кількість екземплярів:
Щоб знову переглянути свої 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 service, як ми дізнались в попередній частині посібника:
kubectl describe services/kubernetes-bootcamp
Створіть змінну середовища з іменем NODE_PORT, яка має значення як порт Вузла:
exportNODE_PORT="$(kubectl get services/kubernetes-bootcamp -o go-template='{{(index .spec.ports 0).nodePort}}')"echoNODE_PORT=$NODE_PORT
Далі ми запустимо curl з зовнішньою IP-адресою та портом. Виконайте команду кілька разів:
curl http://"$(minikube ip):$NODE_PORT"
Ми потрапляємо на різні Podʼи при кожному запиті. Це демонструє, що балансування навантаження працює.
Вивід має бути схожим на:
Hello Kubernetes bootcamp! | Running on: kubernetes-bootcamp-644c5687f4-wp67j | v=1
Hello Kubernetes bootcamp! | Running on: kubernetes-bootcamp-644c5687f4-hs9dj | v=1
Hello Kubernetes bootcamp! | Running on: kubernetes-bootcamp-644c5687f4-4hjvf | v=1
Hello Kubernetes bootcamp! | Running on: kubernetes-bootcamp-644c5687f4-wp67j | v=1
Hello Kubernetes bootcamp! | Running on: kubernetes-bootcamp-644c5687f4-4hjvf | v=1
Примітка:
Якщо ви використовуєте minikube з Docker Desktop як драйвер контейнера, потрібен тунель minikube. Це через те, що контейнери всередині Docker Desktop ізольовані від вашого компʼютера-хосту.
В окремому вікні термінала виконайте:
minikube service kubernetes-bootcamp --url
Вивід виглядає так:
http://127.0.0.1:51082
! Because you are using a Docker driver on darwin, the terminal needs to be open to run it.
Потім використовуйте наданий URL для доступу до застосунку:
curl 127.0.0.1:51082
Зменшення масштабу розгортання
Щоб зменшити Deployment до 2 реплік, знову запустіть команду scale:
Виконання постійного оновлення застосунку (rolling update) за допомогою kubectl.
Оновлення застосунку
Поступові оновлення дозволяють виконувати оновлення Deployment без зупинки роботи застосунку за допомогою поетапного оновлення екземплярів Podʼів.
Користувачі очікують, що застосунки будуть доступні постійно, а розробники — випускатимуть нові версії по кілька разів на день. У Kubernetes це робиться за допомогою розгортань з поступовим оновленням. Поступове оновлення (rolling update) дозволяє виконати оновлення Deployment без перерви в роботі застосунку. Це досягається поетапною заміною поточних Podʼів новими. Нові Podʼи призначаються Вузлам з вільними ресурсами, а Kubernetes чекає, доки ці нові Podʼи не почнуть працювати, перш ніж вилучити старі Podʼи.
У попередньому розділі ми масштабували наш застосунок для запуску кількох екземплярів. Це є вимогою для виконання оновлень без впливу на доступність застосунку. Стандартно максимальна кількість Podʼів, які можуть бути недоступні під час оновлення, та максимальна кількість нових Podʼів, які можуть бути створені, дорівнює одному. Обидві опції можуть бути налаштовані як у вигляді точної кількості, так і у відсотках (від усіх Podʼів). У Kubernetes оновлення мають версії, і будь-яке оновлення Deployment може бути повернуте до попередньої (стабільної) версії.
Огляд поступового оновлення
Якщо Deployment публічно доступний, Service буде спрямовувати трафік лише на доступні 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 працює, бо ви могли його видалити на попередньому кроці, виконайте describe services/kubernetes-bootcamp. Якщо його немає, створіть його знов:
Команда rollout undo повертає розгортання до попередньо відомого стану (v2 образу). Оновлення мають версії, і ви можете повернутися до будь-якого раніше відомого стану Deployment.
Використайте команду get pods, щоб знову вивести список Podʼів:
kubectl get pods
Щоб перевірити образ, розгорнутий на цих Podʼах, використайте команду describe pods:
kubectl describe pods
Deployment знову використовує стабільну версію застосунку (v2). Відкат був успішним
