Вопрос или проблема
У меня есть кластер AKS версии 1.29.2 с политикой сети Calico. У меня есть выходная политика сети, которая должна разрешать исходящий трафик в интернет, но блокировать весь трафик в диапазоне RFC_1918.
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: egress-allow
namespace: production
spec:
egress:
- ports:
- port: 53
protocol: UDP
to:
- namespaceSelector:
matchLabels:
kubernetes.io/metadata.name: kube-system
podSelector:
matchLabels:
k8s-app: kube-dns
- to:
- ipBlock:
cidr: 0.0.0.0/0
except:
- 172.16.0.0/12
- 10.0.0.0/8
- 192.168.0.0/16
podSelector:
matchLabels:
app.kubernetes.io/name: prodbindms
policyTypes:
- Egress
Но когда я пытаюсь подключиться к IP службы другого микросервиса в том же кластере в том же диапазоне RFC_1918 (nc -vz 172.20.217.17 8080) из пода prodbindms, он может подключиться. Как только я удаляю весь ipBlock, соединение не удается, но тогда я не могу подключиться ни к какому публичному IP. В основном, весь исходящий трафик, кроме подключения к kube-dns, начинает сбоить.
Похоже, что except в ipBlock вообще не работает. Я попробовал все возможности, но не смог это заставить работать. Та же политика сети работает нормально в кластере AWS EKS. В чем может быть причина того, что это не работает в Azure AKS.
Детали AKS:
az aks show: “networkMode”: null, “networkPlugin”: “kubenet”, “networkPluginMode”: null, “networkPolicy”: “calico”,
Ответ или решение
Из вашего вопроса видно, что вы столкнулись с проблемой настройки сетевой политики в кластере AKS (Azure Kubernetes Service) с использованием Calico. Ваша цель — разрешить исходящий трафик на интернет, но заблокировать трафик к адресам по RFC 1918. Давайте рассмотрим вашу конфигурацию и возможные причины проблемы.
Анализ проблемы
-
Сетевые плагины и политики:
Вы используетеkubenet
в сочетании с Calico для сетевой политики. Важно отметить, что в зависимости от конфигурации сети, поведение сетевых политик может отличаться от поведения в других облачных провайдерах, таких как AWS. -
Использование
ipBlock
сexcept
:
Согласно вашей конфигурации, вы хотите разрешить весь исходящий трафик за исключением диапазонов IP, определённых вexcept
. Однако, если вы сталкиваетесь с тем, что трафик все равно разрешается в диапазоне RFC 1918, это может указывать на несколько возможных проблем:- Неправильное сопоставление сетевых меток (labels).
- Конфликты сетевых политик, когда другие политики разрешают или блокируют трафик.
- Специфика работы Calico и его интеграции с AKS, которая может влиять на обработку сетевых политик.
Предложения по решению
-
Проверьте настройки сетевых политик:
Убедитесь, что в вашей конфигурации не существует других сетевых политик, которые могут конфликтовать с вашей политикойegress-allow
. Все сетевые политики, которые применяются к вашему поду, будут проверяться, и если хотя бы одна из них разрешает трафик, ваше ограничение может не сработать. -
Перепроверьте, работает ли
except
:
Попробуйте изменить вашу политику, чтобы точно проверить, работает ли ключевое словоexcept
. Возможно, стоит временно изменить CIDR на более узкий диапазон, чтобы визуально проверить блокировку:- to: - ipBlock: cidr: 0.0.0.0/0 except: - 172.20.0.0/16 # Пробуйте указать более узкие диапазоны
-
Проверка логов Calico:
Вы можете включить логи для Calico, чтобы посмотреть, что происходит в сетевом трафике. Логи могут помочь вам понять, как обрабатываются сетевые политики. -
Проверка конфигурации кластера:
Проверьте настройки вашего кластера AKS, чтобы убедиться, что он настроен правильно. Например, попробуйте следующие команды:az aks show --resource-group <your-resource-group> --name <your-cluster-name> --query "networkProfile"
Убедитесь, что
networkPolicy
и другие параметры настроены так, как вы ожидаете. -
Валидация и тестирование:
Поскольку ваши настройки работают в AWS EKS, вы можете использовать аналогичные тесты, чтобы провести сравнение. Если на EKS всё работает, тогда вопрос может быть в совместимости или в конкретных настройках в Azure.
Заключение
Сетевые политики могут быть сложными, и различия между облачными провайдерами, такими как AWS и Azure, могут привести к различному поведению. Следуйте указанным шагам, чтобы проверить вашу конфигурацию и убедиться, что нет конфликтов или проблем с настройкой. Если проблема не разрешится, возможно, вам следует обратиться в поддержку Azure для более глубокой диагностики проблемы.