Контейнери
Kubernetes: оркестр, чесно сперечаючись
Kubernetes — це оркестратор контейнерів, який став стандартною основою великої системи інфраструктури: розгортання, служби, вхід, PersistentVolumes і API, який описує бажаний стан. Він також величезний. Чесна стаття про Kubernetes починається з того, коли його не використовувати, а потім розглядається справжня архітектура, параметри хостингу (керований або k3s) і дисципліна операцій, яких він вимагає.
Головне
- Основна об’єктна модель справді хороша: розгортання описують бажаний стан репліки, служби забезпечують стабільну мережу, ConfigMaps/Secrets окрему конфігурацію, а Ingress досягає зовнішнього середовища; декларативне узгодження (контролери, що фіксують дрейф) — це архітектура, на якій будується все інше.
- Операційна вага реальна: компоненти площини керування (сервер API тощо, планувальник, менеджер контролера) потребують HA та моніторингу; резервне копіювання etcd — єдине непривабливе завдання, яке вирішує, чи можна відновити кластер; і дисципліна оновлення (одна другорядна версія на крок, спочатку канаркові вузли) є постійним зобов’язанням.
- Керований і самокерований форк: контроль торгівлі GKE/EKS/AKS для скорочення операцій, k3s/microk8s є законними міні-дистрибутивами для невеликих груп, а самокеровані головні HA залишаються проектом великої команди; Для хостингового бізнесу k3s на кількох вузлах часто є правильною межею.
- Сховище – це те, де більшість перших кластерів завдає шкоди: PV/PVC у різних класах сховища в різних хмарах відрізняються, hostPath – це пістолет, а класи з підтримкою блокового сховища мають реальну семантику IOPS/швидкість; планувати класи зберігання та стратегію резервного копіювання (velero-клас) перед першим робочим навантаженням із збереженням стану.
- Мережа — це окрема дисципліна: вибір CNI (фланель, бязь, війка) керування накладанням проти рідної маршрутизації та вихідної політики; Ingress (nginx/traefik) плюс менеджер сертифікатів обробляє TLS; ринкові інструменти відрізняються залежно від зрілості API шлюзу; виміряти перед вибором.
- Чесний вердикт у нашій категорії контейнерів: використовуйте Kubernetes, коли багатовузлове планування, автоматичне масштабування та автоматизація розгортання на основі API несуть робоче навантаження; не використовуйте один сервер WordPress; Дистрибутиви класу k3s розширюють зону корисності, але найменші чесні кластери все одно коштують більше операцій, ніж compose.
Польова нотатка
Клієнту, якому «потрібен був Kubernetes», виявилося, що потрібні чотири служби на двох хостах, і k3s запропонував їм контрольну площину для догляду за привілеєм. Ми перевели їх на звичайні стеки, і їхній пейджер замовк. Найкращим рішенням Kubernetes часто є те, яке ви не приймаєте.
Часті запитання
Чи варто нашому невеликому стеку хостингу перейти на Kubernetes?
Швидше за все, ні: якщо ваші робочі навантаження складаються з кількох служб на кількох хостах, стеки, керовані Podman, простіше захистити та контролювати; Виплата k8s починається зі справді динамічних потреб у плануванні або масштабної автоматизації на основі API.
GKE, EKS, AKS чи самокеровані k3s?
Керовані площини управління обмінюються контролем для розвантажених оновлень; k3s-клас для on-prem і витратних стель; повний Kubernetes із самокеруванням — це спеціалізований проект і рідко правильна відповідь для профілю хостингового бізнесу.
Яка найпоширеніша операційна несправність?
etcd залишається без резервної копії: закінчення терміну дії сертифіката в площині керування відображається наступним; сприймайте резервне копіювання кластера (знімки тощо або velero) як перше, що розгортається після самого кластера.
Як розумно захистити кластер?
Найменші привілеї RBAC із реальними ролями для команди, мережевими політиками, які фактично сегментують трафік простору імен, скануванням зображень під час входу (перехоплення політики trivy-class) і секретами в кластері, які обробляються через ваш зовнішній секретний менеджер, а не через необроблений YAML.
Допомога Kinetikatech: контейнери
Вам не обов'язково ставати експертом із контейнери: Керування, оркестрація й безпека контейнерів у виробничих середовищах. Саме для цього й існує служба Адміністрування серверів та Безпека серверів Linux: налаштування, посилення захисту, моніторинг і жива людина на зв'язку цілодобово.