Comments 9
Для Flannel категорически важно использовать --pod-network-cidr=10.244.0.0/16. С другим адресным пространством для POD-ов K8S он не запустится.
Типичная история, когда сеть подов пересекается с какой-либо из сетей в корпоративной сети из любого набора адресов (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16).
Безопасно можно брать только 100.64.0.0/10
На данном этапе у нас есть реализация отказоустойчивого Control Plane K8S. Я рекомендую несколько раз поочередно перезагружать k8s-{1,2,3}, чтобы проверить, что кластер остается в работоспособном состоянии.
Альтернативы:
- Раскатывать на все узлы кластера haproxy, указывать в нем список мастеров, а в качестве контрол плейн эндпойнта — 127.0.0.1
- Использовать внешний балансировщик по аналогии с gw-1/gw-2 для апи сервера.
Дополнительно отмечу, что п.1 закрывает только проблему доступа к апи серверу с воркер узлов. Но не для внешнего клиента АПИ
Ещё очень жаль, что в статье не объяснён принципе kube-vip — он все-таки поверх кубернетес leader election работает или реализует vrrp протокол?
Ещё чего не хватает — харденинга кластера. Если на свежезасетапленном кластере прогнать утилиту kube-bench, то можно очень неприятно удивиться. Она генерирует отчёт, в котором указано какие дополнительные флаги надо передать при инициализации кластера, чтобы он стал минимально секьюрным
1. Честно говоря, Haproxy + 127.0.0.1 мне не нравится, но этот способ вполне рабочий, конечно.
2. Так тоже можно.
> Ещё очень жаль, что в статье не объяснён принципе kube-vip — он все-таки поверх кубернетес leader election работает или реализует vrrp протокол?
Судя по тому, как сформулирован вопрос, для вопрошающего и так все ясно. Работает без VRRP, через leader-election. На это намекает манифест, в котором видно, что kube-vip хочет получить доступ к админ-конфигу кластера. Я об этом действительно не упомянул. Подробнее о всех фичах kube-vip можно краем глаза подсмотреть здесь.
> Ещё чего не хватает — харденинга кластера.
У меня single-tenant кластер в приватной сети. Я думаю, что если полноценно к этому вопросу подходить, то надо смотреть и в сторону Calico, а не Flannel. Так ведь?
У меня single-tenant кластер в приватной сети. Я думаю, что если полноценно к этому вопросу подходить, то надо смотреть и в сторону Calico, а не Flannel. Так ведь?
это не отменяет необходимость защиты. Честно скажу — лет 5 назад я думал, что можно взять опеншифт и вообще не ломать голову и все будет защищено. Как бы не так! Даже в однотенантном кластере, если взломают одно приложение внутри, то злоумышленники могут вылезти за пределы него, повысить привилегии, убежать из песочницы и т.д. Панацеи нет, но получается, что нужен комплекс мер, включая установку runtime monitoring, чтобы обеспечить максимальную прозрачность работы кластера для оператор — чтобы было понятно что, где и когда происходит. Я не говорю про anomaly detection — это возможно избыточно, к тому же эта область вообще очень новая ) Но вот хотя бы отключить анонимные доступы, включить логирование действий, энфорснуть сетевые политики (да, фланнель в них не умеет) необходимо сделать.
args:
- --iface=eth1
- --ip-masq
- --kube-subnet-mgrДля flannel совсем не обязательно использовать 10.244.0.0/16 сеть. Все это задается в ConfigMap самого flannel и в ClusterConfiguration. Вообщем, проблем с этим нет.
Для Flannel категорически важно использовать --pod-network-cidr=10.244.0.0/16. С другим адресным пространством для POD-ов K8S он не запустится.
с любым возможно запустить
Настройка отказоустойчивого кластера Kubernetes на серверах с публичной и приватной сетью с помощью Kubeadm