Как запустить kube-bench в кластере?

  1. Зайдите внутрь пода Deckhouse:

    kubectl -n d8-system exec -ti svc/deckhouse-leader -c deckhouse -- bash

  2. Выберите, на каком узле запустить kube-bench.

    • Запуск на случайном узле:

      curl -s https://raw.githubusercontent.com/aquasecurity/kube-bench/main/job.yaml | kubectl create -f -

    • Запуск на конкретном узле, например на control-plane:

      curl -s https://raw.githubusercontent.com/aquasecurity/kube-bench/main/job.yaml | kubectl apply -f - --dry-run=client -o json | jq '.spec.template.spec.tolerations=[{"operator": "Exists"}] | .spec.template.spec.nodeSelector={"node-role.kubernetes.io/control-plane": ""}' | kubectl create -f -

  3. Проверьте результат выполнения:

    kubectl logs job.batch/kube-bench

В Deckhouse установлен срок хранения логов — 7 дней. Однако, в соответствии с требованиями безопасности указанными в kube-bench, логи должны храниться не менее 30 дней. Используйте отдельное хранилище для логов, если вам необходимо хранить логи более 7 дней.

Как собрать информацию для отладки?

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

  1. Выполните следующую команду, чтобы собрать необходимые данные:

    kubectl -n d8-system exec svc/deckhouse-leader -c deckhouse \
  -- deckhouse-controller collect-debug-info \
  > deckhouse-debug-$(date +"%Y_%m_%d").tar.gz

  2. Отправьте получившийся архив команде Deckhouse для дальнейшего расследования.

Данные, которые будут собраны:

Категория Собираемые данные
Deckhouse
  • Состояние очереди Deckhouse
  • Deckhouse values (за исключением значений kubeRBACProxyCA и registry.dockercfg)
  • Данные о текущей версии пода deckhouse
  • Все объекты DeckhouseRelease
  • Логи подов Deckhouse
  • Манифесты контроллеров и подов из всех пространств имен Deckhouse
Объекты кластера Все объекты следующих ресурсов:
  • NodeGroup
  • NodeGroupConfiguration
  • Node
  • Machine
  • Instance
  • StaticInstance
  • MachineDeployment
  • ClusterAuthorizationRule
  • AuthorizationRule
  • ModuleConfig
А также Events из всех пространств имен
Модули и их состояния
  • Список включенных модулей
  • Список объектов ModuleSource в кластере
  • Список объектов ModulePullOverride в кластере
  • Список модулей в режиме maintenance
Логи и манифесты контроллеров Логи следующих компонентов:
  • machine-controller-manager
  • cloud-controller-manager
  • csi-controller
  • cluster-autoscaler
  • Vertical Pod Autoscaler admission controller
  • Vertical Pod Autoscaler recommender
  • Vertical Pod Autoscaler updater
YAML-файлы следующих контроллеров:
  • capi-controller-manager
  • caps-controller-manager
  • machine-controller-manager
Мониторинг и алерты
  • Логи Prometheus
  • Все горящие уведомления в Prometheus
  • Список всех подов, которые не находятся в состоянии Running, кроме подов в состояниях Completed и Evicted
Сеть
  • Все объекты из пространства имен d8-istio
  • Все кастомные ресурсы istio
  • Конфигурация Envoy для istio
  • Логи istio
  • Логи istio ingress gateway
  • Логи istio users
  • Состояние соединения Cilium (cilium health status)

Как отлаживать проблемы в подах с помощью ephemeral containers?

Выполните следующую команду:

kubectl -n <namespace_name> debug -it <pod_name> --image=ubuntu <container_name>

Подробнее можно почитать в официальной документации.

Как отлаживать проблемы на узлах с помощью ephemeral containers?

Выполните следующую команду:

kubectl debug node/mynode -it --image=ubuntu

Подробнее можно почитать в официальной документации.