События системного журнала#

В DropApp системным журналом является Kubelet Logs. Kubelet Logs или журналы kubelet можно просмотреть, чтобы убедиться в работоспособности nodes кластера DropApp.

В системах на базе systemd возможно использовать утилиту journalctl вместо ручной проверки файлов журналов. Для изучения журналов осуществите вход на соответствующий узел. Далее приведено расположение файлов журналов.

Журналы nodes управляющего слоя:

/var/log/kube-apiserver.log - журналы сервера API, отвечающий за обслуживание API;
/var/log/kube-scheduler.log - журналы планировщика, отвечающий за принятие решений по планированию;
/var/log/kube-controller-manager.log — журналы компонента, который запускает большинство встроенных контроллеров kubernetes, за исключением планирования (kube-scheduler).

Журналы worker nodes:

/var/log/kubelet.log — журналы kubelet, отвечающего за запуск контейнеров на node;
/var/log/kube-proxy.log — журналы kube-proxy, который отвечает за направление трафика на endpoint сервисов.

Так как kubelet работает, как systemd services, можно получить доступ к этим журналам с помощью команды journalctl на хосте операционной системы. Для того чтобы посмотреть события Kubelet Logs, запустите аудит Kubelet при помощи команды: journalctl -xeu kubelet.
Посмотрите log-файлы системных pods:
- etcd при помощи команды: kubectl logs etcd-control-plane -n kube-system;
- API сервера при помощи команды: kubectl logs kube-apiserver-control-plane -n kube-system;
- контроллера при помощи команды: kubectl logs kube-controller-manager-control-plane -n kube-system;
- scheduler при помощи команды: kubectl logs kube-scheduler-control-plane -n kube-system.

Логирование всех модулей, поставляемых в составе дистрибутива предоставляет хронологический набор записей, важных для безопасности, документирующих последовательность действий в кластере. Кластер проверяет действия, генерируемые пользователями, приложениями, использующими API Kubernetes, и самой плоскостью управления.

Записи начинают свой жизненный цикл внутри компонента kube-apiserver. Каждый запрос на каждом этапе его выполнения генерирует событие, которое затем предварительно обрабатывается в соответствии с определенной политикой и записывается. Политика записей системного журнала определяет, что записывается, а серверные части сохраняют записи. Текущие реализации серверной части включают файлы журналов и webhook.

Каждый запрос может быть записан с соответствующим этапом:

RequestReceived — этап для событий, генерируемых, как только обработчик аудита получает запрос, и до того, как он будет делегирован по цепочке обработчиков;
ResponseStarted — после отправки заголовков ответа, но до отправки тела ответа (этот этап создается только для длительных запросов, например, просмотра);
ResponseComplete — тело ответа завершено и больше байты отправляться не будут;
Panic — события, генерируемые при возникновении критических ошибок.

Настройка записи событий системного журнала#

Политика записей системного журнала определяет правила относительно того, какие события следует фиксировать и какие данные они должны включать. Структура объекта политики аудита определяется в audit.k8s.io группе API. Когда событие обрабатывается, оно сравнивается со списком правил по порядку. Первое правило соответствия устанавливает уровень события.

Перечень уровней:

None — не регистрировать события, соответствующие этому правилу;
Metadata — регистрировать метаданные запроса (запрашивающий пользователь, метку времени, ресурс, команду и т. д.), но не тело запроса или ответа;
Request — регистрировать метаданные события и тело запроса, но не тело ответа. Это не относится к запросам, не связанным с ресурсами;
RequestResponse — регистрировать метаданные событий, тела запросов и ответов. Это не относится к запросам, не связанным с ресурсами.

Передать файл с политикой с kube-apiserver возможно с помощью флага --audit-policy-file. Если флаг пропущен, события не регистрируются. Обратите внимание, что это поле rules должно быть указано в файле политики системного журнал. Политика без правил 0 считается небезопасной.

Существует возможность настроить политику записей системного журнала, которая будет использоваться при регистрации запросов.

Настроить политику может только пользователь с ролью cluster-admin:

Отредактируйте APIServer с помощью команды:
```
kubectl edit apiserver cluster
```

Измените поле spec.audit.profile:

apiVersion: config.k8s.io/v1
kind: APIServer
metadata:
...
spec:
    audit:
    profile: WriteRequestBodies

Сохраните файл, подтвердив внесение изменений.
Подождите, пока pods API-сервера Kubernetes обновятся. Это может занять несколько минут.
Просмотрите состояние NodeInstallerProgressing для API-сервера, чтобы убедиться, что на всех pods внесены последние изменения.
```
kubectl get kubeapiserver -o=jsonpath='{range .items[0].status.conditions[?(@.type=="NodeInstallerProgressing")]}{.reason}{"\n"}{.message}{"\n"}'
```
Вывод команды AllNodesAtLatestRevision свидетельствует об успешном обновлении:
```
AllNodesAtLatestRevision
3 nodes are at revision 12
```
Если в выводе команды отображается одно из следующих сообщений, необходимо подождать несколько минут и повторить попытку:
```
3 nodes are at revision 11; 0 nodes have achieved new revision 12`;
2 nodes are at revision 11; 1 nodes are at revision 12`.
```