Поради щодо конфігурації

Цей документ виділяє та консолідує найкращі практики конфігурації, які представлені в документації користувача, документації для початківців та прикладах.

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

Загальні поради щодо конфігурації

• При створенні конфігурацій вкажіть останню стабільну версію API.

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

• Пишіть файли конфігурації за допомогою YAML, а не JSON. Хоча ці формати можна використовувати взаємозамінно практично в усіх сценаріях, YAML зазвичай є більш зручним для користувачів.

• Гуртуйте повʼязані обʼєкти в один файл, якщо це має сенс. Одним файлом часто легше керувати, ніж кількома. Podʼивіться на файл guestbook-all-in-one.yaml як приклад використання цього синтаксису.

• Також зверніть увагу, що багато команд kubectl можна виконувати з теками. Наприклад, ви можете застосувати kubectl apply в теці з файлами конфігурації.

• Не вказуйте типові значення без потреби: проста, мінімальна конфігурація зменшить ймовірність помилок.

• Додайте описи обʼєктів в анотації, щоб забезпечити кращий самоаналіз.

"Чисті" Podʼи проти ReplicaSets, Deployments та Jobs

• Не використовуйте "чисті" Podʼи (тобто Podʼи, не повʼязані з ReplicaSet або Deployment), якщо можна уникнути цього. "Чисті" Podʼи не будуть переплановані в разі відмови вузла.

  Використання Deployment, який як створює ReplicaSet для забезпечення того, що потрібна кількість Podʼів завжди доступна, так і вказує стратегію для заміни Podʼів (таку як RollingUpdate), майже завжди є переважним варіантом на відміну від створення Podʼів безпосередньо, за винятком деяких явних сценаріїв restartPolicy: Never. Також може бути прийнятним використання Job.

Services

• Створіть Service перед створенням відповідного робочого навантаження (Deployments або ReplicaSets), і перед будь-якими створенням робочих навантажень, які мають до нього доступ. Коли Kubernetes запускає контейнер, він надає змінні середовища, які вказують на всі Serviceʼи, які працювали під час запуску контейнера. Наприклад, якщо існує Service з іменем foo, то всі контейнери отримають наступні змінні у своєму початковому середовищі:

  FOO_SERVICE_HOST=<хост, на якому працює Service>
  FOO_SERVICE_PORT=<порт, на якому працює Service>
  

  Це передбачає вимоги щодо черговості — будь-який Service, до якого Pod хоче отримати доступ, повинен бути створений перед створенням цього Podʼу, бо змінні середовища не будуть заповнені. DNS не має такого обмеження.

• Необовʼязкова (хоча настійно рекомендована) надбудова для кластера — це DNS-сервер. DNS-сервер спостерігає за Kubernetes API за появою нових Serviceʼів та створює набір DNS-записів для кожного з них. Якщо DNS було активовано в усьому кластері, то всі Podʼи повинні мати можливість автоматичного використовувати назви Serviceʼів.

• Не вказуйте hostPort для Podʼа, якщо це не є абсолютно необхідним. Коли ви привʼязуєте Pod до hostPort, це обмежує місця, де може бути запланований Pod, оскільки кожна комбінація <hostIP, hostPort, protocol> повинна бути унікальною. Якщо ви не вказуєте явно hostIP та protocol, Kubernetes використовуватиме 0.0.0.0 як типовий hostIP та TCP як типовий protocol.

  Якщо вам потрібен доступ до порту лише для налагодження, ви можете використовувати apiserver proxy або kubectl port-forward.

  Якщо вам дійсно потрібно використовувати порт Подʼа на вузлі, розгляньте можливість використання NodePort Service перед використанням hostPort.

• Уникайте використання hostNetwork, з тих самих причин, що й hostPort.

• Використовуйте headless Service (які мають ClusterIP None) для виявлення Service, коли вам не потрібен балансувальник навантаження kube-proxy.

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

• Визначайте та використовуйте мітки, які ідентифікують семантичні атрибути вашого застосунку або Deployment, такі як { app.kubernetes.io/name: MyApp, tier: frontend, phase: test, deployment: v3 }. Ви можете використовувати ці мітки для вибору відповідних Podʼів для інших ресурсів; наприклад, Service, який вибирає всі Podʼи з tier: frontend, або всі складові phase: test з app.kubernetes.io/name: MyApp. Подивіться застосунок гостьова книга для прикладів застосування такого підходу.

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

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

• Використовуйте загальні мітки Kubernetes для загальних випадків використання. Ці стандартизовані мітки збагачують метадані таким чином, що дозволяють інструментам, включаючи kubectl та інфопанель (dashboard), працювати в сумісний спосіб.

• Ви можете маніпулювати мітками для налагодження. Оскільки контролери Kubernetes (такі як ReplicaSet) та Service отримують збіг з Podʼами за допомогою міток селектора, видалення відповідних міток з Podʼа зупинить його від обробки контролером або від обслуговування трафіку Serviceʼом. Якщо ви видалите мітки наявного Podʼа, його контролер створить новий Pod, щоб зайняти його місце. Це корисний спосіб налагоджувати раніше "справний" Pod в "карантинному" середовищі. Щоб інтерактивно видаляти або додавати мітки, використовуйте kubectl label.

Використання kubectl

• Використовуйте kubectl apply -f <directory>. Виконання цієї команди шукає конфігурацію Kubernetes у всіх файлах .yaml, .yml та .json у <directory> та передає її до apply.

• Використовуйте селектори міток для операцій get та delete замість конкретних назв об'єктів. Подивіться розділи про селектори міток та ефективне використання міток.

• Використовуйте kubectl create deployment та kubectl expose, щоб швидко створити Deployment з одним контейнером та Service. Подивіться Використання Service для доступу до застосунку в кластері для прикладу.