строка в iptables не может отвечать на icmp запросы

ip адрес пода меняется после смерти (delete pod) и воскрешения (create pod). У сервиса ровно так же. IP пода можно пробросить внутрь контейнера через даунворд апи

если айпи адрес меняется у сервиса тогда как грамотно в k8s организовать коммуникации ?

мне надо чтобы например php-fpm общался с redis

мне надо чтобы например php-fpm общался с redis

ага, а пинг здесь зачем?

если айпи адрес меняется у сервиса тогда как грамотно в k8s организовать коммуникации ?

по fqdn сервиса, который смотрит на поды

по fqdn сервиса, который смотрит на поды

тоесть если я создал deploy/php-fpm deploy/redis то коммуникации будут по именам redis и php-fpm ?

зачем именно fq?

тоесть если я создал deploy/php-fpm deploy/redis то коммуникации будут по именам redis и php-fpm ?

если ты создашь сервисы php-fpm и redis в одном неймспейсе, которые смотрят на нужные поды, то да.

если ты создашь сервисы php-fpm и redis в одном неймспейсе, которые смотрят на нужные поды, то да.

а про   fqdn  не понял , проясни немного

service.namespace.svc.cluster.local => ip сервиса "service" в неймспейсе "namespace"

service.namespace.svc.cluster.local => ip сервиса "service" в неймспейсе "namespace"

непонятны мне пока твои слова

если в рамках одного неймспейса будешь ходить, то достаточно обратиться по имени "service" чтобы получить ip сервиса "service"

непонятны мне пока твои слова

https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/

естественно непонятны, не читаешь же документацию

естественно непонятны, не читаешь же документацию

не успеваю еще, изучаю абстракции покачто и механизмы

без тебя бы пропал бы уже

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

Просто читал статьи и документацию, ничего сложного.

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

я в этот чат попал еще до того как появился kuber

я в этот чат попал еще до того как появился kuber

я боюсь тебя огорчить, но чат создали после того как появился kubernetes.

Ну как бы это как минимум по законам физики

Может это кубер в честь чатика назвали, кто знает, кто знает...

пытаюсь копсом создать кластер, вижу такую ошибку: error running task "VPC/vpc_name" (9m58s remaining to succeed): Field cannot be changed: CIDRзачем он пытается поменять CIDR в VPC, если я ему в манифесте задал какой сидр в каких подсетях и все это уже существует?

пытаюсь копсом создать кластер, вижу такую ошибку: error running task "VPC/vpc_name" (9m58s remaining to succeed): Field cannot be changed: CIDRзачем он пытается поменять CIDR в VPC, если я ему в манифесте задал какой сидр в каких подсетях и все это уже существует?

я не настоящий сварщик, но думаю что нужно ему дать только VPC id а не CIDR, подсети и т.д. - так например в kube-aws

да, я ему дал VPC id

и он пытается этот VPC попортить, а я не хочу, пусть просто пользуется

тогда по логике надо ему еще айди подсетей дать а не их cidr

чтобы он не пытался из создать

конечно, их я тоже дал

может слишком маленькие подсети?

но в манифесте, потому что он не поддержвает флаг --subnets, хоть и врет, что поддерживает

/28 например?

/18

хмм

а что он там в терраформе нагенерировал не смотрел?

а точно, можно же терраформ сгенерить, сейчас посмотрю, спасибо

не видно никаких сидров, которыми бы изменялось vpc

а может быть такое, что копс не умеет смотреть в VPC, в котором больше одного сидра? я ему задаю используй вот этот VPC и для сети вот такой-то сидр. Он смотрит в указанный VPC (а там у меня три сидра), берет первый попавшийся — не совпадает — обновляем.

kubectl delete deployment hello-node error: timed out waiting for the condition Кто знает как лечить такие ошибки при удалении деплоймента? поднял тестовый кластер из трех нод, запустил тестовый простой деплоймент и он по факту не удаляется. При врубленном дебаге(-v 8) ответы 200 возвращают. force=true не помогает. С cascade=false пишет что деплоймет удален, но в выводе get deployment он остается.

сами поды по отдельности удалил, а rs и deployment не могу=)

а может быть такое, что копс не умеет смотреть в VPC, в котором больше одного сидра? я ему задаю используй вот этот VPC и для сети вот такой-то сидр. Он смотрит в указанный VPC (а там у меня три сидра), берет первый попавшийся — не совпадает — обновляем.

а 3 сидра это как, это в каком облаке? слышал недавно амазон добавил возможность добавить втор сидр в впс но чтобы 3 - хмм

в амазоне

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

будет все равно роутить траффик

хмм хотя стоп, не уверен

по идее не должен новых клиентов на этот под роутить но открытые коннекты останутся

источник: http://blog.infracloud.io/kubernetes-pod-lifecycle/

👍

Коллеги, никто не сталкивался с частым срабатыванием APIServerLatencyHigh? Этот алерт висит чуть ли не постоянно, при этом kubectl работает довольно шустро. Kubernetes 1.9.1, разворачивался с Kubespray на метале, сеть Calico.

Коллеги, никто не сталкивался с частым срабатыванием APIServerLatencyHigh? Этот алерт висит чуть ли не постоянно, при этом kubectl работает довольно шустро. Kubernetes 1.9.1, разворачивался с Kubespray на метале, сеть Calico.

Я б etcd проверил

Он кстати не в докере крутится

Коллеги, никто не сталкивался с частым срабатыванием APIServerLatencyHigh? Этот алерт висит чуть ли не постоянно, при этом kubectl работает довольно шустро. Kubernetes 1.9.1, разворачивался с Kubespray на метале, сеть Calico.

Ага, etcd логирует долгие запросы, определенно стоит начать с этого

Похоже вы правы: Feb 23 11:52:42 kube-master1 etcd[764]: sync duration of 4.020570225s, expected less than 1s Feb 23 11:53:55 kube-master1 etcd[764]: sync duration of 3.931581155s, expected less than 1s Feb 23 11:55:39 kube-master1 etcd[764]: sync duration of 1.452525634s, expected less than 1s

Ребята подскажите а при создании persisten volume можно сразу туда данные записать чтобы при стыковке с подом там уже они были бы

Используй Init container

Ребята подскажите а при создании persisten volume можно сразу туда данные записать чтобы при стыковке с подом там уже они были бы

Dynamic provisioner может создать volume из снэпшота, если указаны лейблы. Trident так делает, можно встроенные облачные тоже умеют

а вы может знаете вот есть такой volume gitRepo в k8s как сделать так чтобы данные при создании пода из этого gitRepo попадали в persistentDisk

init container

init container

блин еще не разобрался как с этим работать

можно вот прям сейчас это сделать

Тестовый кластер из трех нод развернутый kubeadm вроде работает: поднимает поды, скейлит их кол-во, но когда решил перейти к следующему шагу - кластеризировать etcd0, то в ходе подготовки обнаружил, что "etcdctl ls --recursive /" выполняемый на поде с etcd не показывает ничего. Если вручную добавить ключ-значение, он их сохраняет и отдает. А вот работа кластера никак не отражается на содержимом etcd. Только лишь время модификации файлов в /var/lib/etcd/member/wal изменяется. В конфиге kube-apiserver etcd сервер указан, с пода kube-apiserver-docker0 etcd доступен и даже отвечает на проверку: "kubectl -n kube-system exec kube-apiserver-docker0 -- wget -O - http://127.0.0.1:2379/health" {"health": "true"} да и как, я понимаю, если бы etcd был ему не доступен, то поды не создавались бы и кластер был в ридонли? Наверняка фейлю в чем-то элементарном, но не пойму в чем. Почему etcd при работающем кластере пуст? etcd Version: 3.1.11 kubeadm GitVersion:"v1.9.3" Kubernetes v1.9.3

запускай с переменной окружения для включения апи в3

ETCDCTL_API=3

сейчас попробую

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

Похоже вы правы: Feb 23 11:52:42 kube-master1 etcd[764]: sync duration of 4.020570225s, expected less than 1s Feb 23 11:53:55 kube-master1 etcd[764]: sync duration of 3.931581155s, expected less than 1s Feb 23 11:55:39 kube-master1 etcd[764]: sync duration of 1.452525634s, expected less than 1s

Вы похоже пускаете рядом с чем то, что забивает диск. Ни etcd ни zookeeper не терпят если не могут скинуть и засинкать на диск журнал за сотенку миллисекунд)

etcd сам диск весьма прилично нагружает

Етцд тот ещё гад, мы в итоге его на отдельный ssd поставили

ребята а можно как-то чтобы env в k8s считыаались с consul

ребята а можно как-то чтобы env в k8s считыаались с consul

Через consul-template

Вау

совершенный инструмент

Похоже вы правы: Feb 23 11:52:42 kube-master1 etcd[764]: sync duration of 4.020570225s, expected less than 1s Feb 23 11:53:55 kube-master1 etcd[764]: sync duration of 3.931581155s, expected less than 1s Feb 23 11:55:39 kube-master1 etcd[764]: sync duration of 1.452525634s, expected less than 1s

Мне помогло переключить куб апи на storage-backend=v2 Хотя etcd не был нагружен и жил кластером на отдельный машинах

Добрый день, а etcd у всех матюкается на heartbeat, что не может за 100ms получить ответ? Вчера попробовал увеличить интервал на одном из, он после этого не захотел вставать в кластер обратно, да и сам кластер загрустил, пришлось вернуть.Кто как лечил медленный etcd? У меня 3.1.5 сейчас кластер всего из трех и нагрузка не сказать чтобы большая, единственное диски неторопливые

Добрый день, а etcd у всех матюкается на heartbeat, что не может за 100ms получить ответ? Вчера попробовал увеличить интервал на одном из, он после этого не захотел вставать в кластер обратно, да и сам кластер загрустил, пришлось вернуть.Кто как лечил медленный etcd? У меня 3.1.5 сейчас кластер всего из трех и нагрузка не сказать чтобы большая, единственное диски неторопливые

Ssd

Можно еще рискнуть и сказать journald держать лог только в памяти - и передавать его сразу EFK

Но это прямо очень рискнуть, а есть предположения почему ей нужно при объеме бд в 20 метров такие излишества?) Может в 3.3 или где-то они уже поработали над оптимизацией?)

О , промотал чатик чуть выше, иногда это полезно)