Найкращі 10 хитрощів і порад з Kubernetes

Найкращі 10 хитрощів і порад з Kubernetes

В інтернеті багато довідкової літератури, але іноді найціннішими стають найпростіші поради. Команда Kubernetes aaS від Mail.ru переклала добірку з десяти хитрощів та порад, які автор статті зібрала після року роботи з Kubernetes Поради не відсортовані за важливістю, але вважаємо, що кожен знайде щось корисне для себе.

Найпростіша команда в роботі з Kubernetes

Для початку, мабуть, найпростіша і найкорисніша дія в роботі з Kubernetes. Наступна команда включає автодоповнення команд kubectl в оболонці bash:

echo "source <(kubectl completion bash)" >> ~/.bashrc

Автозаповнення kubectl пропишеться у файл .bashrc і автоматично активуватиметься щоразу під час запуску оболонки. Це прискорює набір довгих команд та параметрів, таких як all-namespaces. Детальніше у довідці Kubernetes за bash.

Обмеження за промовчанням на пам'ять та CPU у просторі імен

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

Щоб запобігти такому, Kubernetes дозволяє встановлювати стандартні обмеження для кожного простору імен. Вони прописуються у yaml файл для конкретного простору імен. Ось приклад такого файлу:

apiVersion: v1
kind: LimitRange
metadata:
  name: mem-limit-range
spec:
  limits:
  - default:
      memory: 512Mi
    defaultRequest:
      memory: 256Mi
    type: Container

Створіть такий yaml і застосуйте будь-який простір імен. Наприклад, до простору імен limit-example. Тепер для будь-якого контейнера, розгорнутого в цьому просторі імен, діятиме ліміт 512Mi, якщо для цього контейнера додатково не встановлено інший індивідуальний ліміт.

Прибирання сміття у старих версіях Kubernetes

Kubelet за замовчуванням починає прибирання сміття, коли var/lib/docker займає 90% доступного дискового простору. Це чудово, однак, до версії Kubernetes 1.7 не було ліміту за умовчанням на кількість використовуваних індексних дескрипторів inode (інодів), які відповідають кількості файлів у файловій системі.

Потенційно ваш контейнер var/lib/docker може використовувати лише 50 % дискового простору, але при цьому іноди можуть закінчитися, що спричинить проблеми в роботі воркерів.

У старих версіях kubelet від 1.4 до 1.6 доведеться додати такий прапор:

--eviction-hard
=memory.available<100Mi,nodefs.available<10%,nodefs.inodesFree<5%

У 1.7 і свіжіших версіях цей прапор встановлено за замовчуванням. Однак попередні версії слідкують за лімітом інодів.

Minikube… маленький, але потужний локальний Kubernetes

Minikube – найпростіший спосіб запустити локальний кластер Kubernetes. Він запускається простою командою:

minikube start

В результаті виконання цієї команди у вас на комп'ютері працює кластер Kubernetes.

Найкращі 10 хитрощів і порад з Kubernetes
Джерело ілюстрації

Хитрість у тому, як зібрати програму і запустити її локально в цьому кластері. Якщо не дати спеціальних вказівок, образ Docker буде збиратися на вашому комп'ютері, а не в кластері.

Щоб змусити Docker відправити образ до локального кластера Kubernetes, докер-машині дається така команда:

eval $(minikube docker-env)

Тепер ми можемо збирати програми на локальному кластері Kubernetes.

Не роздавайте доступ kubectl усім поспіль

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

Можна заморочитися, прописуючи кожному пода права на доступ, читання, створення, видалення та інші операції. Але головне — обмежити доступ до секретів, дозволивши його лише адміністраторам. Так ми розмежуємо тих, хто може адмініструвати кластер і тих, хто може просто розгортатися в ньому.

Керуйте бюджетами подов

Як гарантувати відсутність простоїв для застосування у кластері Kubernetes? PodDisruptionBudget та ще раз PodDisruptionBudget.

Кластери періодично оновлюються, а вузли спустошуються. Ніщо не стоїть на місці, такою є реальність. У кожну деплою з більш ніж однією інстансом слід обов'язково включити PDB (PodDisruptionBudget). Він створюється у простому файлі yaml, який застосовується до кластера. Область покриття конкретного PDB визначається селекторами міток.

Примітка: Бюджет PDB враховується лише за оборотного порушення бюджету (voluntary disruption). У ситуаціях на кшталт апаратних збоїв PDB не спрацює.

Приклад PDB:

apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
  name: app-a-pdb
spec:
  minAvailable: 2
  selector:
      matchLabels:
        app: app-a

Два основні параметри - це matchLabels и minAvailable. У першому параметрі вказується, для яких програм діє бюджет. Наприклад, якщо у мене є деплої з мітками app: app-a и app: app-b, то цей PDB буде застосовуватися лише до першого.

Параметр minAvailable обліковується при спустошенні (очищенні) вузла. Наприклад, у нашому прикладі під час спустошення витісняються всі інстанси app: app-a, Окрім двох.

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

Моніторинг справності програми

Такий моніторинг можливий двома способами: пробами Readiness або Liveness.

Перша проба (readiness) визначає готовність контейнера прийому трафіку.

Друга (liveness) показує, чи контейнер або його необхідно перезапустити.

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

Мітки скрізь

Мітки – одне з фундаментальних понять у Kubernetes. Вони дозволяють об'єктам вільно зв'язуватися один з одним, а також створювати запити на основі міток. У Kubernetes можна навіть перейти до клієнта та спостерігати за подіями за конкретними мітками.

За допомогою міток можна зробити практично все, але гарним прикладом буде створення кількох оточень для виконання програм в одному кластері.

Допустимо, ви використовуєте один і той же кластер для dev и qa. Це означає, що у вас може бути програма app-a, що одночасно працює в обох середовищах qa и dev. У цьому випадку ми можемо звертатися окремо до екземпляра програми в конкретному середовищі, вказавши відповідний параметр environment. наприклад, app: app-a и environment: dev для одного оточення, а app: app-a и environment: qa для другого.

Це дозволяє звертатися до обох екземплярів програми, наприклад, одночасно проводити тестування.

Наведіть порядок

Kubernetes - дуже сильна система, але кожна система в результаті здатна загрузнути у великій кількості процесів. Kubelet запускає всі вказані процеси та перевірки, а також свої власні.

Звичайно, одна безхазяйна служба не загальмує систему, а Kubernetes спочатку розрахована на масштабування. Але якщо замість однієї служби з'являється мільйон, кубелет починає захлинатися.

Якщо з якоїсь причини ви видаляєте розгортання (контейнер, образ, що завгодно) просто переконайтеся в повному очищенні.

Познайомтеся з Go

Головну пораду ми приберегли насамкінець. Вивчіть мову програмування Go.

Kubernetes розроблено на Go, всі розширення написані на Go, а також офіційно підтримується клієнтська бібліотека client-go.

Її можна використовувати для різних та цікавих речей. Наприклад, для розширення системи Kubernetes на власний смак. Так, ви можете використовувати власні програми для збору даних, розгортання програм або простий очищення контейнерів.

Вивчити мову програмування Go і освоїти client-go - мабуть, найважливіша порада, яку можна дати користувачам-початківцям Kubernetes.

Перекладено за підтримки Mail.ru Cloud Solutions

Що ще почитати:

  1. Три рівні автомасштабування в Kubernetes та як їх ефективно використовувати.
  2. Робочі вузли Kubernetes: багато маленьких чи мало великих?
  3. 25 корисних інструментів для розгортання та керування Kubernetes.

Джерело: habr.com

Додати коментар або відгук