та все норм на убунте. Мне потребовалось сделать минимум изминений чтобы на 20.04 все работало. А centos 8 до сих пор все плохо, как я понял.

с заменой kube-proxy (global.kubeProxyReplacement=strict) ?

с тем же успехом (и даже большим) я б на сусе мигрировал

выпилить systemd-resolved? :D

я сусе трогал. Там до сих пор zypper? В целом обычный rpm-based дистр показался

вроде да

на 20.04 переехал ?

я сусе трогал. Там до сих пор zypper? В целом обычный rpm-based дистр показался

Я на 20.04 в проде 5 месяцев ужо

Я на 20.04 в проде 5 месяцев ужо

Я на 20.04 в проде 5 месяцев ужо

А почему так быстро переехал

Сервер редакция ?

Сервер редакция ?

ты же кстати и на cilium давно?
Слушай мб подскажешь по вопросу: https://t.me/kubernetes_ru/314910
Это я туплю, или так и нужно делать?

Ребят вопрос к использующим cilium.

Не могу понять эта баг или фича.

Накатил свою обычную сетевую потилтику для kube-system: https://pastebin.com/ZJqF0FHq
А у меня вся сеть отвалилась для запросов внутри kube-system. cilium агенты начинают перезапускаться по livenessProbe, так как не могут подключиться к etcd. Начал смотреть хаблом, вижу такое

10.245.2.79:8920 -> kube-system/coredns-f9fd979d6-4x7fq:53 Policy denied DROPPED (TCP Flags: SYN)

Не нахожу pod'ов c таким ip адресом (10.245.2.79) . Но затем нахожу такой ip адрес на ноде в аннотациях: io.cilium.network.ipv4-cilium-host: 10.245.2.79. Cilium работает в режиме туннелинга vxlan. Удивляюсь что внутренний ip ноды выдается из podCIDR ну да ладно. Пусть будет так.

Далее захожу в pod cilium агент'а который висит на том же хосте что и coredns-f9fd979d6-4x7fq. И в cilium monitor наблюдаю:

xx drop (Policy denied) flow 0x0 to endpoint 311, identity 6->9326168: 10.245.2.79:8920 -> 10.245.0.145:53 tcp SYN
identity 6 это reserved: remote-host

делаю трассировку политики для 6 => 9326168 (https://pastebin.com/RLrKdAmQ)
получаю denied.

Окей. Добавляю политику CiliumNetworkPolicy для label'а reserved: remote-host : https://pastebin.com/jpKmrNNt
Все заработало.

Но меня смущают два момента:
1) Что network policy куба которое работало на других cni, в cilium теперь не работает. А чтобы оно работало пришлось добавить дополнитульную политику CiliumNetworkPolicy. В которой к тому же я не очень уверен
2) Меня смущает мое правило в CiliumNetworkPolicy. Я разрешил по сути с внутреннего адреса всех нод подключаться к подам из kube-system. Вроде ничего страшного, из других namespace доступ к kube-system не проходит. Но возможно тут могут быть какие-то проблемы и под reserved: remote-host попадет не то чему следует - может быть это паранойя.

И второй вопрос. Можно ли в hubble выводить identity, чтобы потом смотреть по ним трассировки policy? А то получается сейчас я вижу например дропы пакетов в hubble. Но непонятно по какому правилу. И приходится потом идти в конкретный cilium агент на ноде и там через cilium monitor грепать ip адреса которые я словил в hubble и извлекать их identity для трасировки - как-то муторно

Ребят вопрос к использующим cilium.

Не могу понять эта баг или фича.

Накатил свою обычную сетевую потилтику для kube-system: https://pastebin.com/ZJqF0FHq
А у меня вся сеть отвалилась для запросов внутри kube-system. cilium агенты начинают перезапускаться по livenessProbe, так как не могут подключиться к etcd. Начал смотреть хаблом, вижу такое

10.245.2.79:8920 -> kube-system/coredns-f9fd979d6-4x7fq:53 Policy denied DROPPED (TCP Flags: SYN)

Не нахожу pod'ов c таким ip адресом (10.245.2.79) . Но затем нахожу такой ip адрес на ноде в аннотациях: io.cilium.network.ipv4-cilium-host: 10.245.2.79. Cilium работает в режиме туннелинга vxlan. Удивляюсь что внутренний ip ноды выдается из podCIDR ну да ладно. Пусть будет так.

Далее захожу в pod cilium агент'а который висит на том же хосте что и coredns-f9fd979d6-4x7fq. И в cilium monitor наблюдаю:

xx drop (Policy denied) flow 0x0 to endpoint 311, identity 6->9326168: 10.245.2.79:8920 -> 10.245.0.145:53 tcp SYN
identity 6 это reserved: remote-host

делаю трассировку политики для 6 => 9326168 (https://pastebin.com/RLrKdAmQ)
получаю denied.

Окей. Добавляю политику CiliumNetworkPolicy для label'а reserved: remote-host : https://pastebin.com/jpKmrNNt
Все заработало.

Но меня смущают два момента:
1) Что network policy куба которое работало на других cni, в cilium теперь не работает. А чтобы оно работало пришлось добавить дополнитульную политику CiliumNetworkPolicy. В которой к тому же я не очень уверен
2) Меня смущает мое правило в CiliumNetworkPolicy. Я разрешил по сути с внутреннего адреса всех нод подключаться к подам из kube-system. Вроде ничего страшного, из других namespace доступ к kube-system не проходит. Но возможно тут могут быть какие-то проблемы и под reserved: remote-host попадет не то чему следует - может быть это паранойя.

И второй вопрос. Можно ли в hubble выводить identity, чтобы потом смотреть по ним трассировки policy? А то получается сейчас я вижу например дропы пакетов в hubble. Но непонятно по какому правилу. И приходится потом идти в конкретный cilium агент на ноде и там через cilium monitor грепать ip адреса которые я словил в hubble и извлекать их identity для трасировки - как-то муторно

Что-то я запутался.... Похоже, что-то у меня не так с разрешением имен в кластере.....
Вот мой кластер:

└─# kubectl get nodes
NAME          STATUS   ROLES         AGE    VERSION
cuba-kub-01   Ready    etcd,master   2d5h   v1.18.10+rke2r1
cuba-kub-02   Ready    etcd,master   2d1h   v1.18.10+rke2r1
cuba-kub-03   Ready    etcd,master   2d     v1.18.10+rke2r1
cuba-kub-04   Ready    node          2d     v1.18.10+rke2r1
cuba-kub-05   Ready    node          47h    v1.18.10+rke2r1
cuba-kub-06   Ready    node          47h    v1.18.10+rke2r1
✓ ��[ admin@cuba-kub-01 ]��[ 10.8.4.24 172.17.0.1 10.42.0.0 ]─[ 16:58:16 ]

Обратите внимания, что имена хостов все "короткие", они соответствуют хостнеймам машин. Поэтому пинг по короткому имени не пройдет, например, ping cuba-kub-02 вызовет ошибку. Во внутреннем DNS для этих хостов созданы записи, поэтому пинг по FQDN пройдет нормально:

└─# ping cuba-kub-02.haulmont.com
PING cuba-kub-02 (10.8.4.28) 56(84) bytes of data.
64 bytes from cuba-kub-02 (10.8.4.28): icmp_seq=1 ttl=64 time=0.263 ms

Теперь, собственно, проблема..... Я установил в кластер Прометеус, пытаюсь просто сделать port-forward для Grafana, находясь на первом мастере:

└─# kubectl -n monitoring port-forward prometheus-grafana-59bfb6b6bf-b476f 3000:3000
error: error upgrading connection: error dialing backend: dial tcp: lookup cuba-kub-06 on 10.5.0.3:53: server misbehaving
✗ ��[ admin@cuba-kub-01 ]��[ 10.8.4.24 172.17.0.1 10.42.0.0 ]─[ 17:05:53 ]


10.5.0.3 - это доменный DNS. Получается, Кубер ругается на то, что не может найти в DNS адреса cuba-kub-06.... Но там короткого и нет! Там есть FQDN - cuba-kub-06.haulmont.com

Я решил попробовать иначе - просто сделал Service, который пробросит порт 3000 нужного пода на NodePort. Сделал. У меня три воркера, по идее, Grafana должна быть доступна на любой рабочей ноде.... И по netstat я вижу, что нужный порт открылся на всех трех рабочих нодах....
Но! Реально загружается веб морда Графаны только на той рабочей ноде, где крутится под с Графаной, т.е., на cuba-kub-06 при попытке сменить ноду для подключения, браузер долго висит, а потом отваливается по таймауту.
Да и в Графане не открывается ни один дашбоард - говорит, что ошибка сервиса.
Такое ощущение, что отсутствует роутинг между рабочими нодами.....
Как быть?