Главная мысль
Разделяйте учётные данные пользователей и приложений, выдавайте минимальные права Kubernetes RBAC, ограничивайте сетевые связи пространств имён и выбирайте категории журналов AKS с учётом стоимости и расследований.
Кластер Kubernetes состоит из уровня управления и рабочих узлов
Уровень управления (control plane) принимает запросы API, хранит состояние кластера и распределяет pod по узлам. На узлах kubelet и среда выполнения контейнеров запускают приложения; сетевые компоненты направляют трафик сервисов. Декларативные манифесты описывают желаемое состояние, а контроллеры приводят фактическое состояние к нему. Автоматизация поддерживает восстановление и масштабирование, но не устраняет риски открытого API, избыточных прав сервисных учётных записей, широкого сетевого доступа и устаревших образов.
Разделяйте управление платформой AKS и ответственность за приложения
AKS — управляемая служба Kubernetes в Azure. Microsoft управляет компонентами control plane; обязанности по узлам, приложениям, учётным записям, сети, хранилищам, данным и настройкам безопасности и мониторинга зависят от режима и конфигурации кластера. AKS Automatic автоматизирует больше операций с узлами и предоставляет готовые настройки мониторинга, а AKS Standard оставляет оператору больше возможностей конфигурации. Проверяйте распределение обязанностей в актуальной документации для выбранного режима, региона, версии и включённых функций.
Разделяйте учётные данные пользователей и pod
Связывайте аутентификацию пользователей Kubernetes API с ролевыми разрешениями (RBAC); избегайте постоянной выдачи роли cluster-admin и регулярно пересматривайте права. Microsoft Entra ID связывает вход пользователей AKS с централизованной политикой доступа. Kubernetes RBAC и Azure RBAC for Kubernetes authorization — разные модели разрешений: выясните, какая включена в кластере. Для доступа pod к сервисам Azure используйте федерацию идентификации рабочих нагрузок (workload identity): токен сервисной учётной записи обменивается на токен доступа, поэтому не требуется хранить постоянный секрет приложения в образе или манифесте. Защищайте и эти токены. Ограничьте аварийный доступ и регистрируйте его использование.
Настраивайте сетевые политики и проверки состояния по назначению
Начните с запрета входящих и исходящих соединений для выбранных pod, затем разрешите необходимые связи внутри и между пространствами имён. Убедитесь, что сетевой модуль CNI поддерживает сетевые политики. Ограничьте сетевой доступ к API-серверу доверенными административными путями и не публикуйте kubelet. При достижении порога неудачных liveness-проверок kubelet перезапускает контейнер. Readiness исключает неготовый pod из получателей нового трафика Kubernetes Service, но не блокирует весь сетевой доступ. Проверка внешней зависимости в liveness может вызвать массовые перезапуски и усилить отказ. Для медленного запуска задайте startup-проверку, а readiness настройте отдельно. Включите в процесс выпуска проверку образов, обновления, запуск без root, минимальный набор привилегий Linux capabilities и лимиты ресурсов.
Startup
Ждёт завершения запуска до проверок liveness и readiness.
Liveness
При достижении порога неудачных проверок вызывает перезапуск контейнера.
Readiness
Исключает неготовый pod из получателей нового трафика Kubernetes Service.
Включите телеметрию и контролируйте стоимость сбора
Не оценивайте состояние кластера только по одной панели. Метрики платформы, журналы приложений, журналы аудита уровня управления и трассировки отвечают на разные вопросы. Журналы ресурсов control plane AKS сохраняются после настройки диагностической отправки в Log Analytics или другое хранилище. Возможности Container insights, Prometheus и Grafana зависят от режима и конфигурации AKS. Выбирайте категории аудита с учётом чувствительных операций, стоимости и конфиденциальности; оцените необходимость объёмных событий get/list. Сопоставляйте развёртывания, перезапуски узлов, изменения масштаба и ошибки приложения на общей временной шкале.
Сравнивайте Mesos исторически, а не как современную альтернативу
Kubernetes управляет нагрузками через декларативную модель, pod, обнаружение сервисов и контроллеры. Apache Mesos был универсальным менеджером ресурсов кластера: фреймворки планирования получали от master предложения CPU и памяти, а Marathon управлял долгоживущими сервисами. Развитие Apache Mesos прекращено. Для действующего Mesos назначьте ответственных за версии, обновления безопасности, зависимости фреймворков и план миграции. При выборе новой платформы учитывайте активную поддержку и эксплуатационные требования команды.
Mesos сегодня — равная альтернатива Kubernetes?
Нет. Проект Apache завершён; сравнение полезно для понимания истории архитектуры и существующей устаревшей среды.
AKS берёт на себя всё управление кластером?
Microsoft управляет уровнем управления. Команда отвечает за приложения, данные и правила доступа; распределение обязанностей по узлам, сети и мониторингу проверяйте для выбранного режима AKS.