Контейнер пишет в stdout и stderr, containerd складывает строки в /var/log/pods/ на узле, а kubelet ротирует файлы по containerLogMaxSize; агент Grafana Alloy в DaemonSet читает их, добавляет метки пода и отправляет в Loki, который индексирует только метки и хранит чанки в S3. Трассы приложение шлёт по OTLP в OpenTelemetry Collector, а тот — в Tempo; сервисы связывает заголовок traceparent. В Grafana три источника сшиваются общими метками и trace id: от exemplar на графике — к трассе, от строки лога — к трассе и обратно.
Эта статья для тех, кому нужен работающий прокси и не хочется разбираться, как он устроен. Здесь только шаги: что нажать, что вставить и что должно получиться. Объяснений нет.
В конце у вас будет свой сервер, через который идёт весь трафик компьютера и телефона, а со стороны это выглядит как обычные визиты на большой сайт. Обычно на всё уходит около получаса.
Как это работает и почему настроено именно так, разобрано в двух подробных статьях: про сервер и клиент для Windows и про клиент для Android. Если что-то пойдёт не так, начните с таблицы в конце этой статьи: она подскажет, что сделать и какой раздел читать.
В кластере два независимых контура: metrics-server каждые 15 секунд снимает с kubelet CPU и память подов и отдаёт их через API metrics.k8s.io для kubectl top и HorizontalPodAutoscaler, а Prometheus сам опрашивает /metrics у экспортёров и приложений и хранит историю на диске. HPA считает ceil(реплики × текущее / целевое), причём проценты берутся от requests, а не от лимита или ядра. Prometheus с Grafana и Alertmanager ставится чартом kube-prometheus-stack, цели добавляются объектом ServiceMonitor, алерты — PrometheusRule.
Сверху вниз — от объекта, с которым работает человек, к узлу: Deployment, события, под, контейнер, узел, — и на каждом уровне один вопрос: дошло ли дело до следующего звена. События (kubectl events --for) называют причину прямым текстом, но живут всего час; kubectl logs --previous показывает, почему контейнер упал в прошлый раз, а в образ без shell попадают эфемерным контейнером через kubectl debug, в неймспейсе restricted — с --profile=restricted. Когда API уже не помогает, остаются crictl и journalctl -u kubelet на самом узле.
Границы пода задаются полями securityContext: процесс работает не от root (runAsNonRoot), без capabilities (drop: [ALL]), без повышения прав (allowPrivilegeEscalation: false), с фильтром seccompProfile: RuntimeDefault, а privileged, hostNetwork и hostPath приложению не даются. Чтобы не помнить поля наизусть, неймспейс помечают метками Pod Security Admission: enforce=restricted не пустит нарушающий под, warn и audit только предупредят. Свои правила вроде запрета тега latest пишут на CEL в ValidatingAdmissionPolicy.
Объекта «пользователь» в Kubernetes нет: kube-apiserver извлекает имя и группы из предъявленного удостоверения — клиентского сертификата X.509 (CN и O), JWT-токена ServiceAccount или ID-токена OIDC от внешнего провайдера. Затем авторизаторы Node,RBAC решают, разрешён ли глагол на ресурс: права складываются только из разрешений в Role и ClusterRole, выданных через RoleBinding и ClusterRoleBinding, запретов нет. Людям — OIDC, сертификат нельзя отозвать до истечения срока, а create pods и list secrets фактически дают все секреты неймспейса.
В прошлой части мы собрали кластер и добавили в него машины. Теперь его нужно обслуживать: каждый месяц ставить обновления на узлы, следить, чтобы нагрузка распределялась равномерно, а копии одной службы не оказывались на одном узле, раз в несколько лет переводить кластер на новую Windows Server и разбираться, почему машины внезапно переехали. Этому и посвящена последняя часть серии.
В прошлой части мы переносили машины между одиночными хостами — но каждый перенос запускал администратор, а если хост просто сгорел, машины на нём остановились до ручного вмешательства. Отказоустойчивый кластер решает эту задачу: несколько хостов следят друг за другом, и машины упавшего узла сами запускаются на оставшихся. Разберём, что кластер даёт и чего не даёт, какое хранилище ему нужно, как устроены общие тома и кворум, как собрать кластер из PowerShell и как добавить в него машины.
До сих пор машина жила на одном хосте. Но хост нужно обновлять, ремонтировать, а однажды и заменить, и машины с него приходится переносить. Разберём все способы: экспорт и импорт, живую миграцию работающей машины между хостами без кластера, перенос файлов машины на другой том, что мешает переезду между разными процессорами, когда поднимать версию конфигурации после переезда на новую Windows Server и как держать на другом хосте копию машины на случай аварии.
Во всех предыдущих частях команды выполнялись на самом хосте. В работе так не делают: заходить на хост по RDP ради каждой машины не нужно, а на хосте с Server Core и негде открыть окно консоли. Разберём, как управлять Hyper-V с рабочей станции администратора: какие средства на неё поставить и какие права выдать, как подключиться к хосту в домене и вне домена, как открыть консоль машины и как выполнять команды внутри гостя без его сети.