Все инструменты Kubernetes в одном посте (и зачем они нужны)

Примечание переводчика: оригинальный пост читайте на Reddit.

У экосистемы Kubernetes своя предыстория: каждая утилита появилась потому, что возможностей самого K8s просто не хватало.

Сначала вы управляете всем с помощью kubectl: запускаете kubectl get pods, describe, logs, exec, delete и apply по 50 раз в день в пяти неймспейсах. Это работает, но процесс медленный и неудобный — особенно потому, что каждый раз приходится указывать ключ -n namespace.

— На помощь приходит K9s (или Lens). Это терминальный UI, который собирает всю информацию о кластере в одном месте. С ним можно переключаться между неймспейсами и кластерами, смотреть логи, заходить в под (exec) и делать всё необходимое.

Статистика подов в K9s

Вы деплоите манифесты с ноутбука через kubectl apply. Кто-то меняет Deployment прямо в кластере, и запущенные сервисы больше не согласуются с тем, что прописано в Git. Типичный дрейф конфигурации — про него никак не узнаешь, пока не упадёт прод.

— Внедряете Argo CD. Git становится единым источником истины: любые изменения автоматически синхронизируются с кластером; если кто-то поменяет Deployment вручную, Argo CD сразу перезапишет его обратно. (А ещё есть werf, который отлично интегрируется с Argo CD. Познакомиться с ним поближе можно на сайте проекта или в нашем курсе — заглядывайте!).

В Kafka скопилось 200К сообщений, но процессор загружен всего на 5 %, поэтому HPA не видит причин для масштабирования. Очередь растёт, пользователи ждут.

— Перехóдите на KEDA. Инструмент умеет масштабировать поды по размеру очереди, числу сообщений Simple Queue Service или метрикам Prometheus, а не только по процессору. В итоге бэклог благополучно разгребается.

Нагрузка скакнула, Horizontal Pod Autoscaler добавил поды, но узлы забиты под завязку, и те зависают в состоянии Pending. HPA свою работу сделал, но проблема в том, что новые поды просто негде разместить.

— На выручку приходит Karpenter. Поды зависли в Pending? Не беда! Karpenter поднимет новый узел за пару секунд (и удалит, когда нагрузка спадёт). Платишь только за то, что используешь.

По умолчанию все поды могут общаться друг с другом. Платёжный сервис ходит в базу данных, внутренняя утилита — в сервис логов. Всё открыто, пока вручную не настроишь ограничения.

— Поэтому вы используете Network Policies. База данных принимает трафик только от приложения, всё остальное закрыто. В итоге, если какой-то под взломают, радиус поражения будет минимальным.

У вас 20 микросервисов. Один из них начинает тормозить, из-за чего в четырёх других копятся повторные запросы. Начинается каскадный сбой, но определить его источник невозможно из-за непрозрачности трафика.

— Внедряете сервис меш. Istio или Linkerd подселяют сайдкар-прокси к каждому поду, и вы получаете mTLS между всеми сервисами, повторные запросы, circuit breaker'ы и метрики трафика. А самое главное — не надо править код приложения!

Секреты в Kubernetes закодированы в Base64, лежат в etcd, и их может прочесть любой, у кого есть доступ к kubectl. Хорошо бы перенести их в специализированное хранилище вроде HashiCorp Vault или AWS Secrets Manager, но переписывать код приложения — не вариант.

— Поэтому вы используете Secrets Store CSI Driver. Секреты хранятся в Vault или AWS Secrets Manager и монтируются прямо в поды как файлы. В самом Kubernetes они нигде не «светятся».

Один разработчик выкатывает контейнер с root-правами, другой забывает проставить лимиты на ресурсы. Но вы узнаёте об этом только после инцидента, и так постоянно.

— Ставите Kyverno. Ресурсы проверяются на соответствие политикам ещё до того, как попадут в кластер: теперь нельзя развернуть root-контейнеры, образы без digest-хеша и деплойменты без лимитов.

			# Пример политики Kyverno, которая удаляет все capabilities пода
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: drop-all-capabilities
  annotations:
    policies.kyverno.io/title: Drop All Capabilities
    policies.kyverno.io/category: Best Practices
    policies.kyverno.io/severity: medium
    policies.kyverno.io/minversion: 1.6.0
    policies.kyverno.io/subject: Pod
    policies.kyverno.io/description: "Capabilities permit privileged actions without giving full root access. All capabilities should be dropped from a Pod, with only those required added back. This policy ensures that all containers explicitly specify the `drop: [\"ALL\"]` ability. Note that this policy also illustrates how to cover drop entries in any case although this may not strictly conform to the Pod Security Standards."
spec:
  validationFailureAction: Audit
  background: true
  rules:
    - name: require-drop-all
      match:
        any:
          - resources:
              kinds:
                - Pod
      preconditions:
        all:
          - key: "{{ request.operation || 'BACKGROUND' }}"
            operator: NotEquals
            value: DELETE
      validate:
        message: Containers must drop `ALL` capabilities.
        foreach:
          - list: request.object.spec.[ephemeralContainers, initContainers, containers][]
            deny:
              conditions:
                all:
                  - key: ALL
                    operator: AnyNotIn
                    value: "{{ element.securityContext.capabilities.drop[].to_upper(@) || `[]` }}"

		

Что-то сломалось. Поды перезапускаются, задержка скачет, потребление памяти растёт, но нет ни метрик, ни истории, ни понимания, когда всё это началось.

— Значит, пора установить Prometheus и Grafana. Prometheus собирает метрики со всех подов, узлов и системных компонентов, а Grafana превращает их в наглядные дашборды. Сразу видны всплеск нагрузки, точное время его появления и сервис-виновник. (К слову, наш высокопроизводительный форк Prometheus — Deckhouse Prom++ — потребляет до 10 раз меньше памяти.)

Grafana показывает сам всплеск, но не говорит, какой запрос его вызвал, на какой сервис он пришёл первым и где именно начал тормозить. Логи дают лишь обрывки данных, а метрики — общие цифры. Ни то, ни другое не показывает картину целиком.

— Поэтому вы добавляете Jaeger. Он отслеживает путь запроса через все сервисы, показывая задержку на каждом переходе (hop) и точное место сбоя. Иголка в стоге сена находится за считаные секунды.

Пример трейса в Jaeger

Рекламная пауза

Если вы не хотите разбираться в инструментах экосистемы с нуля, попробуйте Deckhouse Kubernetes Platform Community Edition — нашу готовую Open Source-платформу на базе Kubernetes. Она собрана инженерами «Фланта» из проверенных компонентов, которые не придётся обновлять вручную, и существенно сэкономит ваши ментальные ресурсы.

Реклама. Рекламодатель: АО «Флант» ИНН 7723661439, erid: 2W5zFHw9J5P