Контейнеры
Kubernetes: оркестратор, аргументированный честно
Kubernetes — это оркестратор контейнеров, который стал основой большой системы инфраструктуры по умолчанию: развертывания, службы, вход, PersistentVolumes и API, описывающий желаемое состояние. Это также огромно. Честная статья о Kubernetes начинается с того, когда его не следует использовать, затем рассказывается о реальной архитектуре, вариантах хостинга (управляемый или k3s) и дисциплине эксплуатации, которую он требует.
Главное
- Базовая объектная модель действительно хороша: развертывания описывают желаемое состояние реплики, службы обеспечивают стабильную сеть, ConfigMaps/Secrets отделяют конфигурацию, а Ingress достигает внешней среды; декларативная сверка (контроллеры, фиксирующие отклонения) — это архитектура, на которой строится все остальное.
- Операционный вес реален: каждый компонент плоскости управления (API-сервер и т. д., планировщик, диспетчер контроллеров) нуждается в высокой доступности и мониторинге; резервное копирование etcd — это единственная непривлекательная задача, которая решает, можно ли восстановить кластер; а дисциплина обновления (одна второстепенная версия на шаг, сначала канареечные узлы) является постоянным обязательством.
- Управляемый и самоуправляемый форк: торговый контроль GKE/EKS/AKS для сокращения операций, k3s/microk8s — законные мини-дистрибутивы для небольших парков, а самоуправляемые мастера высокой доступности остаются проектом большой команды; для хостингового бизнеса k3s на нескольких узлах часто является правильным потолком.
- Хранилище — это то место, где страдают большинство первых кластеров: PV/PVC для классов хранения в разных облаках различаются, HostPath — это пистолет, а классы с поддержкой блочного хранилища имеют реальную семантику IOPS/скорости; планируйте классы хранения и стратегию резервного копирования (класс velero) перед первой рабочей нагрузкой с отслеживанием состояния.
- Сеть — это отдельная дисциплина: выбор CNI (фланель, бязь, ресничка) для управления наложением против собственной политики маршрутизации и выхода; Ingress (nginx/traefik) плюс дескриптор TLS диспетчера сертификатов; рыночные инструменты различаются по степени зрелости API шлюза; прежде чем выбрать, измерьте.
- Честный вердикт в нашей категории контейнеров: используйте Kubernetes, когда многоузловое планирование, автоматическое масштабирование и автоматизация развертывания на основе API несут рабочую нагрузку; не используйте ни один сервер WordPress; Дистрибутивы класса k3s расширяют зону полезности, но самые маленькие честные кластеры по-прежнему требуют больше операций, чем Compose.
Заметка из практики
Клиенту, которому «нужен был Kubernetes», оказалось, что нужно ровно четыре сервиса на двух хостах, и k3s предоставил ему плоскость управления, чтобы присматривать за этой привилегией. Мы перевели их в стеки простого набора сообщений, и их пейджер по вызову замолчал. Часто лучшее решение Kubernetes — это то, которое вы не принимаете.
Частые вопросы
Должен ли наш небольшой стек хостинга перейти на Kubernetes?
Вероятно, нет: если ваши рабочие нагрузки представляют собой несколько сервисов на нескольких хостах, стеки, управляемые Compose или Podman, проще защитить и отслеживать; Преимущества k8s начинаются с действительно динамичного планирования или масштабной автоматизации на основе API.
GKE, EKS, AKS или самоуправляемые k3s?
Управляемые самолеты управления обменивают контроль на разгруженные обновления; к3с-класс для локальных и стоимостных потолков; Полноценный Kubernetes с самоуправлением — это специализированный проект, который редко является правильным решением для хостингового бизнес-профиля.
Какой самый распространенный сбой в работе?
etcd не резервируется: следующим отображается срок действия сертификата в плоскости управления; рассматривайте резервное копирование кластера (снимки etcd или velero) как первое, что развертывается после самого кластера.
Как нам разумно защитить кластер?
Наименьшие привилегии RBAC с реальными ролями для каждой команды, сетевые политики, которые фактически сегментируют трафик пространства имен, сканирование изображений при входе (перехватчики политики тривиального класса) и секреты внутри кластера, обрабатываемые через внешний менеджер секретов, а не через необработанный YAML.
Как мы берём на себя контейнеры
Честно: чаще всего к нам приходят после того, как команда попробовала справиться сама. Управление, оркестрация и безопасность контейнеров в производственной среде. Услуга Администрирование серверов и Безопасность серверов Linux существует как раз затем, чтобы не изучать контейнеры на своих ошибках: настройку, ночные сюрпризы и постоянное наблюдение мы берём на себя.