Если никаких дефолтных фаерволов не включено, самый простой способ перепривезти правильные правила — перезагрузиться.

Если эндпоинты доступны — проблема с сервисами. Наверняка какие-нить iptables-правила либо от предыдущих установок остались, либо это какой-нить firewalld считает себя самым умным и привозит говна.

Флашу всё подчистую. Сравнивал правила - ничего. В первую очередь дропы

# yes | kubeadm reset && rm -rf /etc/kubernetes && rm -rf /etc/ssl/etcd/ /var/lib/etcd/ && systemctl disable etcd && systemctl stop etcd && iptables -F && iptables -t nat -F && iptables -t mangle -F && iptables -X && reboot

Хз зачем я их затираю перед ребутом. "Так исторически сложилось"

Ах вот оно как... И всё же, где можно про это НОРМАЛЬНО почитать? А то как-то отрывками по конференциям и всё что-то не то

Где-то в документации это было прям хорошо описано.

Понял, почитаю там тогда

# yes | kubeadm reset && rm -rf /etc/kubernetes && rm -rf /etc/ssl/etcd/ /var/lib/etcd/ && systemctl disable etcd && systemctl stop etcd && iptables -F && iptables -t nat -F && iptables -t mangle -F && iptables -X && reboot

Это я на 3х машинах делаю. А потом снова kubespray. Со свежими настройками

Вкратце, для сервисов с ClusterIP выделяется ip из сети сервисов, он присваивается dummy-интерфейсу на каждой ноде; на каждой ноде конфигурится ipvs с бакендами из подов, которые попадают под селектор в описании сервиса, всё. Ну и обычно этим занимается kube-proxy.

ipvs как-то меня обошёл. Спасибо большущее, буду обмазываться

# yes | kubeadm reset && rm -rf /etc/kubernetes && rm -rf /etc/ssl/etcd/ /var/lib/etcd/ && systemctl disable etcd && systemctl stop etcd && iptables -F && iptables -t nat -F && iptables -t mangle -F && iptables -X && reboot

Погоди, ты сетапишь кубспреем, а ресетишь кубадмом? Не надо так.

Есть же reset.yml

ipvs как-то меня обошёл. Спасибо большущее, буду обмазываться

Ю ар велкам)

Есть же reset.yml

Уууу, сейчас заживём

Надо на курсы повышения квалификации гугления записаться

ipvsadm -l охренеть как медленно работает на этой машине. С -n мгновенно. Роутинг корректный, какая-то шляпа всё ещё происходит. Большое спасибо за помощь, дальше сам ночью продолжу

ipvsadm -l охренеть как медленно работает на этой машине. С -n мгновенно. Роутинг корректный, какая-то шляпа всё ещё происходит. Большое спасибо за помощь, дальше сам ночью продолжу

dns

Угу. Там вообще всё не слава богу даже меж машин с установкой соединений. Сетевое оборудование недоступно для меня

если днссломан или не верен то кубик пытается отрезовить имя а ему никто не отвчает делается три запроса с ожиданием в 5 секунд. Можно указать любой рабочий главное отвечал быстро.

Там около 3 секунд резолв. Пока на opendns пропишу, потом разберусь

я забил на попытки поднять в графане метрики(sidecar proxy работал, но все поды падали на healthcheck), стер istio и поставил его через gke console там istio в настройках кластера есть, теперь у меня вопрос, почему на видео у них есть топология, а у меня нет? https://app.google.stackdriver.com/topology https://youtu.be/wCJrdKdD6UM?t=778 удобнее ли метрики stackdriver чем графана? и как теперь мне еще добавить тулзы типа kiali, отдельно их ставить через helm?

Ребят, у нас есть проект, который представляет собой обертку над kubernetes api. Как лучше всего организовать локальные dev environments для разработчиков? minikube?

чтобы можно было одной командой поднять локальный kube-кластер с нашими daemonsets и прогонять тесты на нем, например

Да

Да

А в миникубе возможно несколько виртуальных нод запустить?

Не пробовал

чтобы можно было одной командой поднять локальный kube-кластер с нашими daemonsets и прогонять тесты на нем, например

Создаёшь неймспейс, прогоняешь, удаляешь неймспейс.

По-моему, куда проще.

Создаёшь неймспейс, прогоняешь, удаляешь неймспейс.

думал об этом, не подходит это нам(

Видимо, иметь возможность без последствий поломать кластер?

А в миникубе возможно несколько виртуальных нод запустить?

Наверное, можно просто разных кластеров насоздавать. Я хотел предложить с --vm-driver=none несколько параллельно запускать в локальном докере, но там мб какие-нить конфликты портов будут или типа того.

Видимо, иметь возможность без последствий поломать кластер?

да, например

Господа, а я правильно понимаю, что на один куб может быть один ингресс контроллер и соответственно один лб?

нет, может быть сколько угодно

Сколько угодно контроллеров?

Сколько угодно контроллеров?

да, но это не сильно нужно

Господа, а я правильно понимаю, что на один куб может быть один ингресс контроллер и соответственно один лб?

Глупость говоришь

Глупость говоришь

Возможно, я не настоящий сварщик, я только учусь

Но на один контроллер - один лб, так?

что в твоём понимании "лб"?

лоад балансер, например гугловый, который сам создается при создании контроллера

если отностительно ингресс контроллеров, то да

если про service type loadbalancer, то может быть много

то есть, если я хочу несколько Ип привязать к кубу, то я должен сделать несколько ингресс контроллеров?

К одному контроллеру можно много сервисов и любых.

Просто селекторы одинаковые укажи.

пример не покажите?

Это ipvs-сервис, ipvsadm -l.

Короче, вообще хз. ipvsadm -ln показывает постоянно одно активное соединение. ipvsadm -lnc с ss говорят, что это kube-controller, причём, судя по -lnc, он висит 30 секунд, потом сбрасывается и создаётся новое соединение. Правила везде одинаковые -A -t 10.233.0.1:443 -s rr -a -t 10.233.0.1:443 -r 10.1.0.218:6443 -m -w 1 -a -t 10.233.0.1:443 -r 10.1.0.243:6443 -m -w 1 -a -t 10.233.0.1:443 -r 10.1.0.251:6443 -m -w 1 все 3 точки курлятся отлично. Сам балансер - нет, сразу рвётся. Жопа яро полыхает, но хочу докопаться до истины, это отличный способ узнать о внутренностях немного больше обычного

Кажется, что следующий этап - пересборка ядра с CONFIG_IP_VS_DEBUG

Кажется, что следующий этап - пересборка ядра с CONFIG_IP_VS_DEBUG

в contrack соединения есть?

tcp 6 86381 ESTABLISHED src=10.1.0.243 dst=10.233.0.1 sport=37824 dport=443 src=10.1.0.251 dst=10.1.0.243 sport=6443 dport=37824 [ASSURED] mark=0 use=1

На соседних машинах, где 10.233.0.1:443 отвечает нормально, такого зависшего соединения нет

днс за сколько отвечает?

Там около 3 секунд резолв. Пока на opendns пропишу, потом разберусь

Тут я немного перебрал, хех. Быстро он отвечает, доли секунды

Попробую из контроллера сейчас

и в контейнере?

Вот да, минуту, проверю

вот и мы туда наступили. но у нас это быстрее проявилось. у нас было до 1000+ висящих соединений. поды активно общались с api серверром

Ну тут что-то, кажется, иное. Потому что контейнер с coredns тоже валится: E1222 21:17:11.275513 1 reflector.go:205] github.com/coredns/coredns/plugin/kubernetes/controller.go:313: Failed to list *v1.Endpoints: Get https://10.233.0.1:443/api/v1/endpoints?limit=500&resourceVersion=0: dial tcp 10.233.0.1:443: connect: connection refused

Вообще интересно, почему kubespray сетапит всего один под с DNS на три мастера

должен 3 делать

Но не делает

Блин, а других нодах тоже не работает 10.233.0.1:443

Работал же. Вроде...

Попробую kube_proxy_mode поменять на iptables, раз уж с ipvs не идёт

Попробую kube_proxy_mode поменять на iptables, раз уж с ipvs не идёт

;)

Ну, короче, вот...

ipvs nat?

Хз что не так с ipvs, через iptables заработало

kube_proxy_mode: iptables

в том что был до преустановки

Прошу прощения, вопроса не понял. nat причём?

ipvs умеет работать с режиме nat gatway ipip

http://kb.linuxvirtualserver.org/wiki/Ipvsadm forwarding methods (NAT, tunneling, and direct routing), and eight load

Да, NAT. Правила были такие: -A -t 10.233.0.1:443 -s rr -a -t 10.233.0.1:443 -r 10.1.0.218:6443 -m -w 1 -a -t 10.233.0.1:443 -r 10.1.0.243:6443 -m -w 1 -a -t 10.233.0.1:443 -r 10.1.0.251:6443 -m -w 1 -A -t 10.233.0.3:53 -s rr -a -t 10.233.0.3:53 -r 10.233.99.5:53 -m -w 1 -A -t 10.233.0.3:9153 -s rr -a -t 10.233.0.3:9153 -r 10.233.99.5:9153 -m -w 1 -A -t 10.233.7.84:80 -s rr -A -t 10.233.37.10:443 -s rr -A -t 10.233.50.248:443 -s rr -A -t 10.233.52.3:44134 -s rr -a -t 10.233.52.3:44134 -r 10.233.102.6:44134 -m -w 1 -A -u 10.233.0.3:53 -s rr -a -u 10.233.0.3:53 -r 10.233.99.5:53 -m -w 1

У меня на виртуалках та же проблема была, кстати. Возможно это даже не косячные инстансы, а баг. В течение недели попробую зарепрольюсить на чистых машинах и зарепорчу

многие ошибки где в логах указано dial tcp 10.233.0.1:443: connect: connection refused это баг https://github.com/kubernetes/kubernetes/issues/71071 временное решение - kube_proxy_mode: iptables

установил cert-manager helm install stable/cert-manager \ --namespace certmanager \ --name cert-manager \ --set createCustomResource=false \ --set ingressShim.defaultIssuerName=letsencrypt-prod \ --set ingressShim.defaultIssuerKind=ClusterIssuer \ --set rbac.create=false \ --set serviceAccount.create=false как в уже установленном поменять значение createCustomResource=false на createCustomResource=true? делаю helm upgrade install stable/cert-manager \ --namespace certmanager \ --name cert-manager \ --set createCustomResource=true \ --set ingressShim.defaultIssuerName=letsencrypt-prod \ --set ingressShim.defaultIssuerKind=ClusterIssuer \ --set rbac.create=false \ --set serviceAccount.create=false пишет Error: unknown flag: --name

helm upgrade [RELEASE] [CHART] [flags]

там не ни субкомманды install ни параметра —name

helm upgrade [RELEASE] [CHART] [flags]

читал ток не могу понять от куда значение [RELEASE] [CHART] брать убрал —name и добавил CHART (cert-manager-v0.5.0) helm upgrade install cert-manager-v0.5.0 stable/cert-manager \ --namespace certmanager \ --set createCustomResource=true \ --set ingressShim.defaultIssuerName=letsencrypt-prod \ --set ingressShim.defaultIssuerKind=ClusterIssuer \ --set rbac.create=false \ --set serviceAccount.create=false но пока говорит Error: This command needs 2 arguments: release name, chart path