Yandex Cloud
Поиск
Связаться с намиПодключиться
  • Документация
  • Блог
  • Все сервисы
  • Статус работы сервисов
    • Популярные
    • Инфраструктура и сеть
    • Платформа данных
    • Контейнеры
    • Инструменты разработчика
    • Бессерверные вычисления
    • Безопасность
    • Мониторинг и управление ресурсами
    • Машинное обучение
    • Бизнес-инструменты
  • Все решения
    • По отраслям
    • По типу задач
    • Экономика платформы
    • Безопасность
    • Техническая поддержка
    • Каталог партнёров
    • Обучение и сертификация
    • Облако для стартапов
    • Облако для крупного бизнеса
    • Центр технологий для общества
    • Облако для интеграторов
    • Поддержка IT-бизнеса
    • Облако для фрилансеров
    • Обучение и сертификация
    • Блог
    • Документация
    • Контент-программа
    • Мероприятия и вебинары
    • Контакты, чаты и сообщества
    • Идеи
    • Истории успеха
    • Тарифы Yandex Cloud
    • Промоакции и free tier
    • Правила тарификации
  • Документация
  • Блог
Проект Яндекса
© 2025 ООО «Яндекс.Облако»
Yandex Managed Service for Kubernetes
  • Сопоставление с другими сервисами Yandex Cloud
  • Начало работы
    • Взаимосвязь ресурсов сервиса
    • Релизные каналы и обновления
    • Шифрование
    • Сеть в Managed Service for Kubernetes
    • Сетевые настройки и политики кластера
    • Автоматическое масштабирование
    • Политика аудита
    • Внешние узлы кластера
    • Квоты и лимиты
    • Рекомендации по использованию Managed Service for Kubernetes
  • Управление доступом
  • Правила тарификации
  • Справочник Terraform
  • Метрики Monitoring
  • Аудитные логи Audit Trails
  • История изменений
  • Обучающие курсы

В этой статье:

  • Интеграция с балансировщиками
  • Calico
  • Cilium
  • Сетевые политики allow-all и deny-all
  • Политики для входящих подключений
  • Политики для исходящих подключений
  • Требования к кластеру для включения сетевых политик
  1. Концепции
  2. Сетевые настройки и политики кластера

Сетевые политики кластера Kubernetes

Статья создана
Yandex Cloud
Обновлена 24 апреля 2025 г.
  • Интеграция с балансировщиками
  • Calico
  • Cilium
  • Сетевые политики allow-all и deny-all
    • Политики для входящих подключений
    • Политики для исходящих подключений
  • Требования к кластеру для включения сетевых политик

Сетевые политики Kubernetes позволяют настроить сетевое взаимодействие между группами подов и узлами сети. Вы можете создать сетевые политики с помощью Kubernetes Network Policy API, который задает правила фильтрации трафика на уровне подов. Правила определяют, какие поды и сервисы в кластере Kubernetes могут получить доступ друг к другу.

Для управления сетевыми политиками в Managed Service for Kubernetes используются контроллеры Calico и Cilium.

Сетевой контроллер Calico использует правила iptables, а Cilium — технологию eBPF.

Важно

Вы можете включить использование сетевых политик только при создании кластера.

Интеграция с балансировщикамиИнтеграция с балансировщиками

Важно

Из-за архитектурных особенностей Yandex Cloud в Managed Service for Kubernetes нельзя использовать параметр loadBalancerSourceRanges при настройке контроллеров сетевых политик. Для разрешения трафика через Yandex Network Load Balancer или Yandex Application Load Balancer используйте NetworkPolicy.

Пошаговые инструкции по настройке доступа к приложению с помощью NetworkPolicy приведены на странице Обеспечение доступа к приложению, запущенному в кластере Kubernetes.

CalicoCalico

Calico позволяет настраивать базовые политики безопасности кластера Kubernetes.

Пошаговые инструкции по его настройке приведены на странице Настройка контроллера сетевых политик Calico.

CiliumCilium

По сравнению с Calico, контроллер Cilium обладает более широкими возможностями и позволяет:

  • Использовать одни и те же диапазоны подсетей для подов и сервисов в разных кластерах.
  • Создавать более функциональные сетевые политики, например, фильтровать трафик между подами на прикладном уровне L7 или на основании DNS-имени внешнего ресурса.
  • Применять встроенный инструмент Hubble для мониторинга сетевых событий.

Cilium в кластере Managed Service for Kubernetes работает в туннельном режиме. Этот режим реализует сетевую связанность объектов кластера на базе технологии VxLAN с помощью Cilium CNI.

Туннельный режим Cilium позволяет:

  • Создавать кластеры с пересекающимися IP-адресами в одной сети.
  • Использовать расширенный диапазон адресов для подов и сервисов кластера вплоть до /8.
  • Создавать в два раза больше узлов в кластерах (в сравнении с Calico).

Для использования туннельного режима сервисному аккаунту кластера требуется роль k8s.tunnelClusters.agent.

В разделе Создание кластера Managed Service for Kubernetes описано, как включить туннельный режим.

Сетевые политики allow-all и deny-allСетевые политики allow-all и deny-all

Важно

Используйте эти политики только для задач отладки. В остальных случаях гранулярно настраивайте политики для решения конкретных задач.

Политики для входящих подключенийПолитики для входящих подключений

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

Пример:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-all-ingress
spec:
  podSelector: {}
  ingress:
  - {}
  policyTypes:
  - Ingress

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

Пример:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
spec:
  podSelector: {}
  policyTypes:
  - Ingress

Политики для исходящих подключенийПолитики для исходящих подключений

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

Пример:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-all-egress
spec:
  podSelector: {}
  egress:
  - {}
  policyTypes:
  - Egress

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

Пример:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-egress
spec:
  podSelector: {}
  policyTypes:
  - Egress

Подробнее о NetworkPolicy см. в разделе Поля и аннотации ресурса NetworkPolicy.

Требования к кластеру для включения сетевых политикТребования к кластеру для включения сетевых политик

Для включения сетевых политик в кластере Kubernetes необходимо достаточное количество ресурсов в группах узлов. Применение сетевых политик требует дополнительных ресурсов памяти и vCPU.

Рекомендуется включать контроллер сетевых политик только в кластере минимум из двух узлов.

Была ли статья полезна?

Предыдущая
Сеть в Managed Service for Kubernetes
Следующая
Автоматическое масштабирование
Проект Яндекса
© 2025 ООО «Яндекс.Облако»