Pull to refresh

Comments 9

Решение с ingress и hostNetwork интересное, но deployment. Что будет если gw-2 на долго улетит в ребут или еще чего и второй под воскреснет на gw-1? Может быть лучше daemonset?

Вы правы, вероятно, лучше так сделать. Для меня эта система пока не в полной мере понятна. Я почитаю об этом подробнее. Или можно, anti-affinity применить.

Для 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}, чтобы проверить, что кластер остается в работоспособном состоянии.

Альтернативы:


  1. Раскатывать на все узлы кластера haproxy, указывать в нем список мастеров, а в качестве контрол плейн эндпойнта — 127.0.0.1
  2. Использовать внешний балансировщик по аналогии с 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 — это возможно избыточно, к тому же эта область вообще очень новая ) Но вот хотя бы отключить анонимные доступы, включить логирование действий, энфорснуть сетевые политики (да, фланнель в них не умеет) необходимо сделать.

Проблем с несколькими интерфейсами нет. Манифест flannel позволяет это сделать.
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 он не запустится.

с любым возможно запустить
Sign up to leave a comment.

Articles