Kubernetes Vocabulary: 40 Terms You Need When Working with K8s
Майстер лексики Kubernetes — підрозділи, розгортання, служби, вхід, RBAC, HPA, Helm, оператори і 30+ інших термінів K8s, пояснених для розробників.
Kubernetes (часто скорочується як K8s) є стандартною платформою для розгортання і управління контейнеризованими застосунками в масштабі. Навіть якщо ви розробник, який рідко торкається інфраструктури, ви почуєте цей словник у плануванні спринтів, викликах інциденту і перегляді архітектури. Цей посібник пояснює 40 основних термінів K8s простою англійською.
Основні будівельні блоки
Pod
pod є найменшим розгорнутим блоком в Kubernetes. Підрозділ обгортає один або декілька контейнерів, які мають спільний мережевий простір назв і сховище. На практиці, більшість підсистем працюють в одному контейнері.
«Под знаходиться в
CrashLoopBackOff— перевірте журнали зkubectl logs <pod-name>.» Не розгортайте контейнери безпосередньо — завжди використовуйте розгортання для управління вашими підсистемами
Deployment
** Розгортання ** — це ресурс вищого рівня, який керує набором ідентичних підсистем. Цей інструмент обробляє послідовні оновлення, відновлення і забезпечує, щоб завжди було запущено потрібну кількість реплік.
«Скалярне розгортання до 5 реплік для обробки збільшеного трафіку» «The rollout is stuck — run
kubectl rollout status deployment/<name>to see what’s happening.» (англійською)
ReplicaSet
** НабірРеплік** забезпечує виконання вказаної кількості реплік підсистеми у будь- який час. Розгортання створюють і керують наборами реплік автоматично — ви рідко взаємодієте з ними безпосередньо.
Namespace
** Простір імен ** це віртуальний кластер всередині кластера Kubernetes. Команди використовують простори імен для ізоляції своїх завантажень — наприклад, production, staging, і development простори імен в тому ж кластері.
«Впровадити в просторі імен
stagingспочатку і перевірити його там перед підвищенням до виробництва» Проверьте, в якому просторі імен ви знаходитесь —kubectl config get-contexts
Service
** Служба ** виставляє набір підсистем як стабільну кінцеву точку мережі. Підрозділи з’ являються і зникають, але адреса IP та назва DNS служби залишаються незмінними. Поширені типи: ClusterIP (внутрішній), NodePort, і LoadBalancer (зовнішній).
«Програма не може дістатися бази даних — перевірте, чи відповідає Service selector під-меткам.» Використовувати
ClusterIPсервіс для внутрішнього зв’язку іLoadBalancerдля зовнішнього трафіку
Ingress
Ingress — це об’ єкт API, який керує зовнішнім доступом HTTP( S) до служб. Цей параметр надає вам змогу визначити правила маршрутизації, наприклад, маршрутизацію /api до однієї служби і / до іншої, за допомогою єдиного балансувальника навантаження.
Додати нове правило хоста до Ingress, щоб трафік до
api.example.comйшов до API-сервісу «Контролер Ingress обробляє SSL-завершення, тому піди бачать тільки простий HTTP.»
Налаштування і зберігання
ConfigMap
ConfigMap зберігає нечутливі дані налаштування як пари ключ- значення. Підсистеми можуть використовувати ConfigMaps як змінні середовища або змонтовані файли.
«Пересунути рядок з’єднання бази даних в ConfigMap замість того, щоб твердо кодувати його в специфікації розгортання.»
Secret
** Секретний ** зберігає конфіденційні дані, такі як паролі, токени і ключі. Дані кодуються за допомогою base64 (типово не зашифровано — використовувати шифрування у стані спокою для виробничих цілей).
«Зберігати ключ API в секреті і посилатися на нього в специфікації pod як на змінну середовища» «Ніколи не передавайте секретні значення в Git — використовуйте Sealed Secrets або зовнішній оператор секретів»
Постійний обсяг (PersistentVolumeClaim)
** PersistentVolumeClaim (PVC) ** — це запит на зберігання. Підсистема заявляє про том через PVC, а Kubernetes прив’язує його до відповідного PersistentVolume (PV). Таким чином програми з відомим станом зберігають дані.
«База даних pod потребує PVC, щоб її дані пережили pod restarts.»
StatefulSet
** StatefulSet ** керує підсистемами, які потребують стабільних профілів і постійного зберігання — базами даних, чергами повідомлень і подібними програмами, що вимагають стану. На відміну від розгортання, підсистеми в StatefulSet мають передбачувані імена (pod-0, pod-1).
Використовуйте StatefulSet для Postgres — це гарантує впорядкований запуск і стабільне зберігання на під
DaemonSet
** DaemonSet ** забезпечує, що одна копія підсистеми буде запущена на кожному вузлі (або підмножини вузлів). Він використовується для служб на рівні вузлів, таких як збирачі журналів, агенти моніторингу і мережеві додатки.
«Log shipper розгортається як DaemonSet, тому кожен вузол має агента.»
Надійність і довговічність
Горизонтальний підйомник (англ. Horizontal lift)
** HPA ** автоматично масштабує кількість реплік підсистем на основі спостережених показників — використання процесора, пам’ яті або нетипових показників. Коли навантаження зменшується, вона знову зменшується.
«Налаштування HPA для масштабування API-подів між 2 і 20 репліками на основі використання процесора» «HPA масштабується, але піди чекають — перевірте, чи кластер має достатню потужність вузлів.»
Запити і обмеження ресурсів
** Запити ** — це мінімальні ресурси (ЦП, пам’ ять), які гарантовано буде використано підсистемою. ** Обмеження ** — це максимальні ресурси, які вона зможе використовувати. Правильне встановлення обох параметрів є обов’ язковим для стабільності кластера.
«Встановіть відповідні запити на ресурси і обмеження — під без них може голодувати інші завдання» The pod was OOMKilled — increase the memory limit or fix the memory leak. — Процитовано 2011-03-14
Випробування на живучість
** Пробка живості ** перевіряє, чи живий контейнер. Якщо це неодноразово не вдається, Kubernetes перезапускає контейнер. Скористайтеся цим пунктом, щоб відновити роботу після застою або пошкодження внутрішнього стану.
Додати зонд живості на
/healthz, щоб Kubernetes перезапустив под, якщо він перестане відповідати
Пробка готовності
** Пробка готовності ** перевіряє, чи готовий контейнер до обслуговування трафіку. Kubernetes надсилає запити тільки до підсистем, які пройшли тест готовності. Це важливо для плавного оновлення.
“Зонд готовності не працює, тому що програмі потрібно 30 секунд, щоб розігрітися. Збільшити
initialDelaySeconds. “
Бюджетний дефіцит (БД)
** PodDisruptionBudget ** обмежує кількість підсистем з набору, які можна перервати одночасно під час добровільних перерв (обслуговування вузлів, послідовні оновлення). Це захищає доступність під час операцій кластера.
«Ми маємо PDB, який вимагає принаймні 2 репліки, щоб бути доступними в будь-який час»
Контроль доступу
Рольовий контроль доступу (Role-Based Access Control, RBAC)
** RBAC ** керує тим, які користувачі та облікові записи служб можуть виконувати які дії на яких ресурсах Kubernetes. Ключеві об’єкти: Role, ClusterRole, RoleBinding, ClusterRoleBinding.
«Створити роль, яка дозволяє доступ тільки для читання до підсистем в просторі імен
production» «Конвейєр CI зазнає невдачі, тому що обліковий запис служби не має дозволу на створення розгортань — перевірте правила RBAC»
Керування пакунками і розширюваність
Helm
Helm — менеджер пакунків Kubernetes. chart є пакунком попередньо налаштованих ресурсів Kubernetes. Helm надає вам змогу встановлювати, оновлювати і керувати програмами за допомогою шаблонних файлів YAML.
“Ми розгортаємо програму, використовуючи схему Helm. Запустити
helm upgrade --installв CI конвеєрі» «Перевірка типового тег зображення в Helmvalues.yamlдля виробничого середовища»
Operator
Operator є розширенням Kubernetes, яке використовує нетипові контролери для автоматизації управління складними становими застосунками (бази даних, брокери повідомлень тощо) за допомогою рідних API Kubernetes.
«Ми використовуємо Postgres Operator для керування кластерами баз даних — він автоматично обробляє відключення»
CRD (визначення нетипових ресурсів)
** CRD ** дозволяє визначити власні типи ресурсів у Kubernetes. Оператори використовують CRD для додавання нетипових об’єктів, таких як PostgresCluster або KafkaTopic до API Kubernetes.
Оператор встановив CRD під назвою
DatabaseBackup— ви можете створювати резервні завдання, створюючи об’єкти цього типу
Робота з kubectl
Звичайні команди kubectl
** kubectl ** — це інструмент командного рядка для взаємодії з кластером Kubernetes. Ось фрази, які ви будете постійно чути:
«Запустити
kubectl get pods -n production, щоб побачити, що відбувається» «Описати під, щоб побачити події:kubectl describe pod <name>.» «Перенаправити порт локально для зневадження:kubectl port-forward pod/<name> 8080:8080.» Перевірте журнали:kubectl logs <pod-name> --tail=100 -f«Застосувати манифест:kubectl apply -f deployment.yaml.»
Context
** контекст ** у kubectl є поєднанням кластера, користувача і простору імен. Ви можете перемикатися між контекстами для роботи з різними кластерами.
«Переключитися на контекст стажування перед запуском цієї команди — ви не хочете застосовувати її до виробництва»
Як використовувати цю функцію в прикладі
В ответ на инцидент:
«Поди виселяються — перевірте використання пам’яті вузла і подивіться на обмеження ресурсів.»
** В планах: **
«Ми потребуємо StatefulSet для кеш-рівня, а не розгортання, тому що кожна репліка потребує власного постійного зберігання.»
** В перегляді коду: **
“В розгортанні немає обмежень ресурсів — додайте їх перед об’єднанням. Без обмежень, цей под може голодувати інші завантаження»
В процессе набора:
«Все в Kubernetes декларативне — ви описуєте те, що хочете, і контрольна площина робить це»
Завдяки цьому словнику ви зможете переглядати документацію K8s, брати участь у обговореннях щодо інфраструктури і робити внесок у розмови щодо надійності з повною впевненістю.