А зачем туннель как таковой (без учета бонусов)? Чем l3 связности между подами недостаточно?

Блин, я уже не знаю как объяснить :) нужно туннелировать так как нету L2 между нодами, взяли vxlan. Никаких других смыслов нет

Т.е. просто туннель ради туннеля? :D

Блин. Как вы протащите сеть подов 10.0.0.0/24 по сети нод 192.168.0.0/24 без L2 между нодами и и без туннелей

пропишет руками маршрутизацию на всех промежуточных роутерах. делов то....
:sarcasm:

@identw а при федерации кубера, они на сетевом уровне друг к другу должны иметь доступ? или kubefed это как-то хитро делает через контексты кластеров?

У меня просто вопрос вот в чем: есть сеть построенная на l3, там кубер, есть l3 связность между подами средствами самой сети. Зачем может понадобиться делать l2 связность между подами через vxlan, если представить, что сервисам в кубере броадкасты/мультикасты не требуются?

Привет! А сертификаты для кублета сложно обновлять? xD

Нет.

Зачем руками? На роутерах эта информация уже и так по bgp/ospf распространяется.

Так, вопрос в чем именно?
1) почему у cillium - vxlan
2) почему вообще vxlan, а не какой-то другой cni (тогда предложите свой)

Спасибо, нашел твою статью на хабре)))

Сори, опыта с  федерацией  в проде нет.  Когда ее смотрел она была совсем другая, сейчас вообще какая-то новая. Только присматриваюсь к ней. Думаю там поднимается отдельные бинари для федерации, и они выстапают в роли api сервера для тебя. Вот они точно должны иметь доступ ко всем кластерам в федерации. Ты обращаешься к api серверу федерации, а он уже там сам рулит куда какие поды запустить. Ну так раньше было по крайней мере, и не для всех типов ресурсов работало

ну значит тебе не надо. а всем остальным, у которых нет доступа к управлению промежуточными роутерами и возможности пихать приватные сетки в bgp - нужны туннели

2. Без оверлейных сетей можео по-разному сделать:
1. По сабнету на кубелет и анонсировать их с самих машин (минус - нужно настраивать динамическую маршрутизацию на нодах, а также париться с кучей сабнетов)
2. Спустить еще один влан тегом с ToR-ов и пусть маршрутизацией заморачивается сетевая инфраструктура.

+

У нас кубер, ему нужен CNI. Раз он всяко нужен - то почему б не потестить всё что есть, не выяснить, что vxlan шустрый, и не заюзать его? Собственно Cillium умеет в ipvlan еще, он быстрый, но из-за изоляции от хоста там не всё работает

обратный Resolve это DNS PTR Query

ок попытаюсь показать на пальцах
- есть Pod chi-test-011-secured-cluster-default-0-0-0
- внутри которого запущен clickhouse-server
у которого для default пользователя прописано <host_regexp>chi-test-011-secured-cluster-[^.]+\d+-\d+\.test.svc.cluster.local$</host_regexp> - это значит что коннект разрешен только с ip адресов зарезервированных для сервисов
- есть другой Pod chi-test-011-secured-cluster-default-1-0-0

- есть сервисы ClusterIP chi-test-011-secured-cluster-default-0-0 -> ведет на Pod chi-test-011-secured-cluster-default-0-0-0 и chi-test-011-secured-cluster-default-1-0 -> chi-test-011-secured-cluster-default-1-0-0

делаю

kubectl -n test exec chi-test-011-secured-cluster-default-0-0-0 -n test -- clickhouse-client -h chi-test-011-secured-cluster-default-1-0 --port=9000 -u default  --query="select 'OK'" 2>&1

получаю ошибку

Code: 195. DB::Exception: Received from chi-test-011-secured-cluster-default-1-0:9000. DB::Exception: User default is not allowed to connect from address 172.17.0.2.

при этом если сделать
```
kubectl -n test exec chi-test-011-secured-cluster-default-0-0-0 -- bash -x -c "apt update && apt install -y dnsutils; nslookup chi-test-011-secured-cluster-default-1-0; nslookup chi-test-011-secured-cluster-default-1-0-0; nslookup --type=PTR 172.17.0.2"
```

получаю
```
+ nslookup chi-test-011-secured-cluster-default-1-0
Server:              10.96.0.10
Address:     10.96.0.10#53

Name:        chi-test-011-secured-cluster-default-1-0.test.svc.cluster.local
Address: 172.17.0.10


+ nslookup chi-test-011-secured-cluster-default-1-0-0
Server:              10.96.0.10
Address:     10.96.0.10#53

** server can't find chi-test-011-secured-cluster-default-1-0-0: NXDOMAIN


+ nslookup --type=PTR 172.17.0.2
2.0.17.172.in-addr.arpa      name = 172-17-0-2.clickhouse-test-011-secured-cluster.test.svc.cluster.local.
```

то есть такое ощущение что сервис chi-test-011-secured-cluster-default-1-0
есть
но еще не нашел под по селекторам  

если чуть позже сделать
```
kubectl -n test exec chi-test-011-secured-cluster-default-0-0-0 -- bash -x -c "nslo
okup chi-test-011-secured-cluster-default-1-0; nslookup chi-test-011-secured-cluster-default-1-0-0; nslookup --type=PTR 172.17.0.2"
```

то получаю все как надо
```
+ nslookup chi-test-011-secured-cluster-default-1-0
Server:         10.96.0.10
Address:        10.96.0.10#53

Name:   chi-test-011-secured-cluster-default-1-0.test.svc.cluster.local
Address: 172.17.0.10

+ nslookup chi-test-011-secured-cluster-default-1-0-0
Server:         10.96.0.10
Address:        10.96.0.10#53

** server can't find chi-test-011-secured-cluster-default-1-0-0: NXDOMAIN

+ nslookup --type=PTR 172.17.0.2
2.0.17.172.in-addr.arpa name = chi-test-011-secured-cluster-default-0-0-0.chi-test-011-secured-cluster-default-0-0.test.svc.cluster.local.
```

вот я и спрашиваю, как отследить что сервис нашел поды на которые будет форвардить трафик?

Всем привет, может сталкивался кто, у нас etcd не был настроен как кластер, каждый мастер смотрел на https://127.0.0.1:2379
из-за этого вечто 1 мастер был перегружен
решили развернуть кластер, в лб добавил правило на *:2379 уходящее в мастера *:2379
но столкнулся с проблемой на скрине, и в целом непонимания, правильно ли делаю...

Я не про тесты, а про окончательный выбор решения для продакшена. Зачем париться с vxlan и усложненным дебагом проблем, связанных с ним, если можно просто воспользоваться l3 связностью, которую уже предоставляет сетевая инфраструктура? В кубере сеть и так устроена не самым простым образом, чтобы ее без нужды еще и оверлейными сетями усложнять.