VR
Size: a a a
2020 February 26
U
Не сохранилось ссылочки?
k
Блин. Как вы протащите сеть подов 10.0.0.0/24 по сети нод 192.168.0.0/24 без L2 между нодами и и без туннелей
Роутингом же, почти все cni прописывают маршруты от ноды до ноды, в зависимости от pidCIDR
MK
IPinIP инкапсюляция же
k
Роутингом же, почти все cni прописывают маршруты от ноды до ноды, в зависимости от pidCIDR
Но это не будет работать если включена antispoofing protection на нодах
k
В этом случае нужен оверлейный vxlan, да
EP
Шикарно! Спасибо
U
интересно, а это на сертфикации спрашивают? :) просто тут от одного перечисления на память начнет глаз дергаться
k
интересно, а это на сертфикации спрашивают? :) просто тут от одного перечисления на память начнет глаз дергаться
Сеть?
U
ну вот эти все калики и прочее, что когда лучше применять и прочее
L
ну вот эти все калики и прочее, что когда лучше применять и прочее
это вопрос на уровне архитектора проекта...
U
спасибо, я просто больше как обычный пользователь с кубером, ну чуть продвинутее
S
господа, такой вопрос, вот я сейчас завел два кластера по этой доке https://github.com/kubernetes-sigs/kubefed и по этой джоинил кластера https://github.com/kubernetes-sigs/kubefed/blob/master/docs/cluster-registration.md#joining-clusters , только со своими контекстами
команда
при деплое или создании сущности они появляются только на одном кластере(который main)
кто траил федерацию, в чем может быть дело? API кластеров доступны публично
команда
kubectl -n kube-federation-system get kubefedclusters
в контексте --host-cluster-context в котором находится main/master кластер для другого кластера выводит что оба кластера Trueпри деплое или создании сущности они появляются только на одном кластере(который main)
кто траил федерацию, в чем может быть дело? API кластеров доступны публично
S
ну вообще в кубе есть readyness пробы, обычно ими делают проверки, если надо подождать, пока что-то где-то запустится и т.п.
ну как бы pod запущен, readiness говорит что ок
проблема именно в том, что этот pod сразу не резолвится по DNS из другого Pod
и вот надо отследить именно момент когда начнет резолвится
оно данные из apiserver берет 😞
то есть endpoint для service есть, хосты в нем есть
а kube-dns все еще резолвит не правильно
проблема именно в том, что этот pod сразу не резолвится по DNS из другого Pod
и вот надо отследить именно момент когда начнет резолвится
kubectl get ep не помоглооно данные из apiserver берет 😞
то есть endpoint для service есть, хосты в нем есть
а kube-dns все еще резолвит не правильно
S
хххы. оказывается оно есть и работает )))
dig @10.100.0.3 -x 10.0.1.127
127.1.0.10.in-addr.arpa. 5 IN PTR 10-0-1-127.tiller-deploy.kube-system.svc.slurm.local.
dig @10.100.0.3 -x 10.0.1.127
127.1.0.10.in-addr.arpa. 5 IN PTR 10-0-1-127.tiller-deploy.kube-system.svc.slurm.local.
если бы его не было, дофига софта перестало бы работать, который проверяет hostname входящих подключений (PostgreSQL например)
S
если под есть в ендпойнтах двух сервисов, то обратка пропишется по имени первого созданного сервиса.
создание второго сервиса не изменит уже существующую запись
но если помянять селектор в первом сервисе, так чтобы под не попадал под него - то обратка пода поменяется на p2.svc....
а если потом вернуть селектор в первом поде - то обратка опять поменяется на p1...
странная логика, ну такоэ.... забавный факт в общем. почему кликхуус строит на свою безопасность на записях в DNS зонах - я вообще в шоке.
создание второго сервиса не изменит уже существующую запись
но если помянять селектор в первом сервисе, так чтобы под не попадал под него - то обратка пода поменяется на p2.svc....
а если потом вернуть селектор в первом поде - то обратка опять поменяется на p1...
странная логика, ну такоэ.... забавный факт в общем. почему кликхуус строит на свою безопасность на записях в DNS зонах - я вообще в шоке.
как долго PTR прописывается для endpoint?
не понимаю почему у меня сразу не резолвится как только endpoint появился в etcd
hostname входящего TCP соединения не только clickhouse проверяет
https://www.postgresql.org/docs/current/auth-pg-hba-conf.html
вот например
не понимаю почему у меня сразу не резолвится как только endpoint появился в etcd
hostname входящего TCP соединения не только clickhouse проверяет
https://www.postgresql.org/docs/current/auth-pg-hba-conf.html
вот например
ВЕ
ну как бы pod запущен, readiness говорит что ок
проблема именно в том, что этот pod сразу не резолвится по DNS из другого Pod
и вот надо отследить именно момент когда начнет резолвится
оно данные из apiserver берет 😞
то есть endpoint для service есть, хосты в нем есть
а kube-dns все еще резолвит не правильно
проблема именно в том, что этот pod сразу не резолвится по DNS из другого Pod
и вот надо отследить именно момент когда начнет резолвится
kubectl get ep не помоглооно данные из apiserver берет 😞
то есть endpoint для service есть, хосты в нем есть
а kube-dns все еще резолвит не правильно
Ты знаешь таймаут, с которым кубднс ходит. Поставь sleep 2*таймаут
LB
Alexander
Я не про тесты, а про окончательный выбор решения для продакшена. Зачем париться с vxlan и усложненным дебагом проблем, связанных с ним, если можно просто воспользоваться l3 связностью, которую уже предоставляет сетевая инфраструктура? В кубере сеть и так устроена не самым простым образом, чтобы ее без нужды еще и оверлейными сетями усложнять.
Если связность подов уже есть через другой CNI, то можно поверх него https://docs.cilium.io/en/v1.7/gettingstarted/cni-chaining-aws-cni/
c
если под есть в ендпойнтах двух сервисов, то обратка пропишется по имени первого созданного сервиса.
создание второго сервиса не изменит уже существующую запись
но если помянять селектор в первом сервисе, так чтобы под не попадал под него - то обратка пода поменяется на p2.svc....
а если потом вернуть селектор в первом поде - то обратка опять поменяется на p1...
странная логика, ну такоэ.... забавный факт в общем. почему кликхуус строит на свою безопасность на записях в DNS зонах - я вообще в шоке.
создание второго сервиса не изменит уже существующую запись
но если помянять селектор в первом сервисе, так чтобы под не попадал под него - то обратка пода поменяется на p2.svc....
а если потом вернуть селектор в первом поде - то обратка опять поменяется на p1...
странная логика, ну такоэ.... забавный факт в общем. почему кликхуус строит на свою безопасность на записях в DNS зонах - я вообще в шоке.
можно еще раз метками чтобы вывести из зоны лап RC
DR
привет всем, кто настраивал интеграцию calico с выше-стоящими рутерами с использованием rout reflector внутри кластера?