Основи Kubernetes

Більшість нових компаній сьогодні виконують свої бізнес-процеси у хмарах. Нові стартапи та підприємства, які вчасно змогли зрозуміти напрямок розвитку технологій, розробили власні застосунки для хмарних платформ. Не всім компаніям так пощастило. Деякі з них забезпечили свій успіх багато років тому, ще за часів старих технологій – монолітних програм, у яких усі компоненти було тісно пов’язані між собою і які практично неможливо роз’єднати, а їх розміщення і управління буде потребувати дуже дорогого обладнання.

• Моноліт
• Сучасний мікросервіс
• Рефакторинг
• Виклики
• Історії успіху

Образи контейнерів дозволяють нам обмежити код програми, час її виконання та всі залежності у заздалегідь визначеному форматі. Контейнерні середовища виконання, такі як runC, containerd або cri-o, можуть використовувати попередньо запаковані образи як джерело для створення і запуску одного або декількох контейнерів. Ці середовища виконання здатні запускати контейнери на одному хості, хоча на практиці хотілось би мати відмовостійке і масштабоване рішення, що досягається створенням єдиного контролера / управління, колекції кількох хостів, з'єднаних разом. Цей контролер / управлінський блок зазвичай називають оркестром контейнерів. У цьому розділі ми розберемось, чому варто використовувати оркестрування контейнерів, розглянемо різні способи оркестрування та де саме їх розгортати.

• Що таке контейнери?
• Що таке оркестрування контейнерів?
• Оркестратори контейнерів
• Навіщо застосовувати оркестрування контейнерів?
• Де краще розгортати оркестрування контейнерів?

У цьому розділі ми поговоримо про Kubernetes, його можливості та причини використання саме його. Ми розглянемо еволюцію Kubernetes від Borg, менеджера розподілення робочих навантажень від Google. Ми також дізнаємося про Cloud Native Computing Foundation (CNCF), яка зараз опікується та розміщує проєкт Kubernetes, а також інші популярні хмарні проєкти, такі як Prometheus, Fluentd, cri-o, containerd, Helm, Envoy та Contour, і це лише для прикладу.

• Що таке Kubernetes?
• Від Borg до Kubernetes
• Особливості Kubernetes
• Навіщо користуватися Kubernetes?
• Користувачі Kubernetes
• Cloud Native Computing Foundation (CNCF)
• CNCF та Kubernetes

У цьому розділі ми розглянемо архітектуру Kubernetes, компоненти ноди панелі керування, роль робочих нод, керування станом кластера за допомогою etcd та вимоги до налаштування мережі. Ми також дізнаємося про мережевий інтерфейс контейнера мережі (Container Network Interface, CNI) як мережеву специфікацію Kubernetes

• Архітектура Kubernetes
• Нода панелі керування (Control Plane Node): Огляд Заголовки 2-го рівня можуть бути створені провайдерами курсів у майбутньому.
• Нода панелі керування (Control Plane Node): Компоненти Заголовки 2-го рівня можуть бути створені провайдерами курсів у майбутньому.
• Компоненти ноди панелі керування (Control Plane Node): Сервер API Заголовки 2-го рівня можуть бути створені провайдерами курсів у майбутньому.
• Компоненти ноди панелі керування (Control Plane Node): Планувальник
• Компоненти ноди панелі керування (Control Plane Node): Менеджери контролерів
• Компоненти ноди панелі керування (Control Plane Node): Сховище типу ключ-значення
• Робоча нода (Worker Node): Огляд Заголовки 2-го рівня можуть бути створені провайдерами курсів у майбутньому.
• Робоча нода (Worker Node): Компоненти
• Компоненти робочої ноди (Worker Node Components): Середовище виконання контейнера
• Компоненти робочої ноди (Worker Node Components): Агент ноди - kubelet
• Компоненти робочої ноди (Worker Node Components): kubelet - оболонки (shims) CRI Заголовки 2-го рівня можуть бути створені провайдерами курсів у майбутньому.
• Компоненти робочої ноди (Worker Node Components): Проксі - kube-proxy
• Компоненти робочої ноди (Worker Node Components): Розширення
• Мережеві виклики
• Комунікація між контейнерами всередині подів
• Комунікація між подами через ноди (Pod-to-Pod Communication)
• Комунікація подів із зовнішнім світом (Pod-to-External World)

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

• Конфігурація Kubernetes
• Інфраструктура для інсталяції Kubernetes
• Інсталяція локального навчального кластера
• Інсталяція виробничих кластерів (Production Clusters) за допомогою засобів розгортання
• Виробничі кластери (Production Clusters) від сертифікованих надавачів рішень
• Kubernetes на Windows

Minikube – це один із найпростіших, найгнучкіших та найпопулярніших методів запуску «все-в-одному» або кількома робочими нодами локального кластера Kubernetes, ізольованого віртуальними машинами (ВМ) або контейнерами безпосередньо на робочих станціях. Minikube – це інструмент для встановлення компонентів Kubernetes, завантаження кластера або його демонтажу. Він містить також додаткові функції, спрямовані на полегшення взаємодії користувача з кластером Kubernetes, але, тим не менш, ініціалізує також повністю функціональний невиробничий кластер, надзвичайно корисний для навчання. Minikube можна встановити на macOS, Windows та на багатьох дистрибутивах Linux. У цьому розділі ми розглянемо вимоги до локального встановлення Minikube на нашій робочій станції.

• Що таке Minikube?
• Вимоги до запуску Minikube
• Інсталяція Minikube на Linux
• Початок роботи з Minikube на Linux (демовідео)
• Інсталяція Minikube на macOS
• Інсталяція Minikube на Windows
• Можливості Minikube для досвідчених користувачів (1)
• Можливості Minikube для досвідчених користувачів (2)
• Вивчення профілів Minikube (демовідео)

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

• Доступ до Minikube
• Доступ до Minikube: Інтерфейс командного рядка (CLI)
• Доступ до Minikube: Вебінтерфейс користувача (Web UI) Заголовки 2-го рівня можуть бути створені провайдерами курсів у майбутньому.
• Доступ до: API
• kubectl
• Інсталяція kubectl на Linux
• Інсталяція kubectl на macOS
• Інсталяція kubectl на Windows
• Файли конфігурації kubectl
• Відео: Інсталяція клієнта інтерфейсу командного рядка (CLI Client) (демовідео)
• Kubernetes Dashboard
• Запуск Dashboard та metrics-server (демовідео)
• API з 'kubectl proxy'
• API з автентифікацією
• Доступ до API Kubernetes з kubectl (демовідео)

У цьому розділі ми дослідимо об'єктну модель Kubernetes і розглянемо деякі її основні структурні елементи, такі як ноди, простори імен, поди, ReplicaSets (набори копій), засоби розгортання, DaemonSets тощо. Ми також обговоримо важливу роль міток (labels) і селекторів в архітектурі, що керується мікросервісами, оскільки вони логічно поєднують відокремлені об'єкти.

• Об’єктна модель Kubernetes
• Ноди
• Простори імен
• Поди
• Відео: Як запускати застосунки з подами (демовідео)
• Мітки
• Мітки селекторів
• Контролери реплікацій (ReplicationControllers)
• ReplicaSets (1)
• ReplicaSets (2)
• Розгортання (Deployments) (1)
• Розгортання (Deployments) (2)
• Розгортання послідовного оновлення та зворотний процес
• DaemonSets
• Керування нодою застосунків з DaemonSets (демовідео)
• Сервіси (Services)

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

• Автентифікація, авторизація, контроль доступу – Огляд
• Автентифікація
• Авторизація (1)
• Авторизація (2)
• Автентифікація та авторизація - демогід (1)
• Автентифікація та авторизація - демогід (2)
• Автентифікація та авторизація - демогід (3)
• Автентифікація та авторизація - демогід (4)
• Автентифікація та авторизація - демогід (5)
• Автентифікація та авторизація - демогід (6)
• Автентифікація та авторизація (демовідео)
• Контроль доступу

У цьому розділі ви дізнаєтеся про об'єкти Сервісів, які використовуються для моделювання комунікації між мікросервісами внутрішнього кластера або із зовнішнім світом. Сервіс пропонує окремий запис DNS для контейнеризованого застосунку без статусу, керованого кластером Kubernetes, незалежно від кількості реплік. Він забезпечує спільну точку доступу до балансування навантаження логічно згрупованих і керованих контролером наборів подів, зокрема розгортанню (Deployment), ReplicaSet або DaemonSet.

• Підключення користувачів або застосунків до подів
• Сервіси
• Приклад об’єкту сервісу
• kube-proxy
• Політика керування трафіком
• Виявлення сервісів
• Типи сервісу (ServiceType)
• ServiceType: ClusterIP та NodePort
• Типи сервісів ClusterIP та NodePort Service Types (демовідео)
• ServiceType: LoadBalancer
• ServiceType: ExternalIP
• ServiceType: ExternalName
• Сервіси з кількома портами

У цьому розділі ми розповімо, як розгорнути застосунок за допомогою Dashboard (Kubernetes WebUI) та інтерфейсу командного рядка (CLI). Ми також опублікуємо застосунок з використанням сервісу типу NodePort та отримаємо до нього доступ за межами кластера Minikube.

• У цьому розділі ми розповімо, як розгорнути застосунок за допомогою Dashboard (Kubernetes WebUI) та інтерфейсу командного рядка (CLI). Ми також опублікуємо застосунок з використанням сервісу типу NodePort та отримаємо до нього доступ за межами кластера Minikube.
• Розгортання застосунку за допомогою Dashboard (2)
• Розгортання застосунку за допомогою Dashboard (3)
• Вивчення міток і селекторів (1)
• Вивчення міток і селекторів (2)
• Розгортання застосунку з використанням інтерфейсу командного рядка (1)
• Розгортання застосунку з використанням інтерфейсу командного рядка (2)
• Експонування застосунку (1)
• Експонування застосунку (2)
• Доступ до застосунку
• Налаштування пробів Liveness та Readiness
• Liveness
• Команда Liveness
• Команда Liveness (демовідео)
• HTTP-запит Liveness
• TCP-проб Liveness
• Проби Readiness
• Pозгортання контейнеризованого застосунку (демовідео)

У сучасній бізнес-моделі дані – найцінніший актив для багатьох стартапів і підприємств. У кластері Kubernetes контейнери в межах подів можуть бути або виробниками даних, або споживачами даних, або і тими, й іншими. І якщо деякі дані контейнера тимчасові, тобто не передбачено, що вони проінснують довше подів, то інші типи даних мають проіснувати довше подів, щоб агрегуватися та, за необхідності, завантажитися системами аналітики. Kubernetes має надавати ресурси для зберігання даних, що споживаються контейнерами, або для зберігання даних, створених контейнерами. Для керування даними контейнерів у Kubernetes використовуються томи кількох типів і трохи інші форми ресурсів зберігання для управління даними контейнера. У цьому розділі ми поговоримо про об'єкти PersistentVolume та PersistentVolumeClaim, які допоможуть прикріпити постійні сховища томів до подів.

• Томи
• Типи томів
• Постійний том (PersistentVolumes)
• Запит до постійних томів (PersistentVolumeClaims)
• Інтерфейс зберігання контейнерів
• Демопосібник з використання спільного типу томів hostPath
• Використання спільного типу тому hostPath (демовідео)

Під час розгортання застосунку вам може знадобитися передати такі параметри виконання, як дані конфігурації, дозволи, паролі, ключі, сертифікати або токени. Припустимо, вам необхідно розгорнути десять різних застосунків для ваших клієнтів, і для кожного клієнта необхідно відобразити назву компанії в інтерфейсі користувача. Тоді, замість створення десяти різних образів Docker для кожного клієнта, ви можете просто використовувати один шаблонний образ та передавати назви клієнтів як параметри виконання. У таких випадках ви якраз можете використовувати ресурс ConfigMap API.

• ConfigMaps
• Створення ConfigMap з літеральних значень
• Створення ConfigMap з маніфесту визначення
• Створення ConfigMap з файлу
• Використання ConfigMaps у межах подів: змінні середовищ Заголовки 2-го рівня можуть бути створені провайдерами курсів у майбутньому.
• Використання ConfigMaps у межах подів: томи
• Демогід з використання ConfigMaps як томів
• Використання ConfigMaps як томів (демовідео)
• Secrets
• Створення Secret з літеральних значень
• Створення Secret з маніфесту визначення
• Створення Secret з файлу
• Використання Secrets у межах подів: змінні середовища
• Використання Secrets у межах подів: томи

У попередньому розділі ми розглянули способи отримання доступу до нашого розгорнутого контейнеризованого застосунку із зовнішнього світу за допомогою сервісів. Серед типів сервісів найчастіше використовуються NodePort та LoadBalancer. Для типу сервісу LoadBalancer необхідна підтримка базової інфраструктури. Навіть за такої підтримки, ви можете не захотіти використовувати його для кожного сервісу, оскільки ресурси LoadBalancer обмежені і можуть значно збільшувати витрати. Керування типом сервісу NodePort іноді також може бути складним, оскільки необхідно постійно оновлювати налаштування проксі-сервера і відстежувати призначені порти. У цьому розділі ми опишемо ресурс API Ingress – ще один рівень абстракції, розгорнутий перед ресурсами API Service, і пропонує уніфікований метод керування доступом до наших застосунків із зовнішнього світу.

• Ingress (1)
• Ingress (2)
• Ingress (3)
• Контролер Ingress
• Доступ до сервісів через Ingress
• Використання правил Ingress для доступу до застосунків (демовідео)

У цьому курсі ми витратили більшість часу на розуміння основних концепцій Kubernetes і простих робочих процесів, щоб побудувати надійну базу. Для підтримки виробничих навантажень професійного рівня Kubernetes також підтримує багатонодові контролери подів, контролери стану застосунків, контролери пакетного виконання, автомасштабування, керування ресурсами і квотами, керування пакетами, контексти безпеки, мережеву та безпекову політики, тощо. У цьому розділі ми коротко розглянемо кілька цих складних тем, оскільки занурення в деталі вийшло б за межі цього курсу.

• Анотації
• Керування квотами та обмеженнями
• Автомасштабування
• Jobs та CronJobs
• StatefulSets
• Користувацькі ресурси
• Kubernetes Federation
• Контексти безпеки та под доступів безпеки
• Політики мережі
• Моніторинг, журнали, вирішення проблем
• Helm
• Сервісна мережа (Service Mesh)
• Стратегії розгортання застосунків
• Стратегія розгортання застосунків: Canary (демовідео)

Як і в будь-якому іншому проєкті з відкритим кодом, спільнота відіграє важливу роль у розробці Kubernetes. Спільнота визначає дорожню карту проєктів і працює над її реалізацією. Спільнота бере участь у різних онлайн та офлайн форумах, зокрема мітапах, каналах в Slack, щотижневих зустрічах тощо. У цьому розділі ви ознайомитеся зі спільнотою Kubernetes та дізнаєтеся, як доєднатися до неї.

• Спільнота Kubernetes
• Щотижневі зустрічі та групові мітапи
• Канали у Slack та поштові розсилки
• Групи за інтересами і Stack Overflow
• Заходи CNCF
• Що робити далі на шляху розвитку з Kubernetes?
• Kubernetes та Cloud Native Associate
• Сертифікований адміністратор Kubernetes
• Сертифікований розробник застосунків Kubernetes
• Сертифікований спеціаліст з безпеки Kubernetes