Там в k8s доке есть статья про траблшутинг сервисов. Может поможет

То есть, за установку правильных маршрутов в iptables отвечает kube-proxy, я правильно понял?

рализовать в приложении перечитывание конфигов при их изменении

вываливается ошибка: May 28 11:27:15 kube-master1 kernel: [ 196.074966] etcd invoked oom-killer: gfp_mask=0x24000c0, order=0, oom_score_adj=0 May 28 11:27:15 kube-master1 kernel: [ 196.074970] etcd cpuset=64aee0c535498766036b1b9f1138cd62c9bbdde2a5d68841f044c9c303ec4619 mems_allowed=0 May 28 11:27:15 kube-master1 kernel: [ 196.074982] CPU: 3 PID: 3394 Comm: etcd Not tainted 4.4.0-119-generic #143-Ubuntu May 28 11:27:15 kube-master1 kernel: [ 196.075168] [ 3394] 0 3394 2757699 133213 287 6 0 0 etcd May 28 11:27:15 kube-master1 kernel: [ 196.075171] Memory cgroup out of memory: Kill process 3394 (etcd) score 1018 or sacrifice child May 28 11:27:15 kube-master1 kernel: [ 196.075242] Killed process 3394 (etcd) total-vm:11030796kB, anon-rss:523764kB, file-rss:9088kB May 28 11:27:16 kube-master1 systemd[1]: etcd.service: Main process exited, code=exited, status=137/n/a

Дык прям в тексте - не хватает памяти, пришёл оом и пристрелил etcd.

это я понял. но не могу понять почему. работал кластер месяц и сегодня перестал. на этом хосто только мастер кубера крутится

То есть, за установку правильных маршрутов в iptables отвечает kube-proxy, я правильно понял?

Потребление памяти линейно зависит от количества данных. etcd, я так понимаю, в кубере. Какие лимиты выставлены?

делал все по дефолту, разворачивал через kubespray

Мне это говорит ровно ни о чем. Либо у вас стоит лимит на etcd, либо не хватает памяти на машине. Свопить etcd - очень плохая идея.

за привоз правил на ноду

правила iptables для hostnames при этом есть на всех нодах (и мастере, и миньонах)

правила iptables для hostnames при этом есть на всех нодах (и мастере, и миньонах)

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

Что используешь?

calico использую, настраивал по официальной инструкции

А интернет то в подах есть?

8.8.8.8 пингуется

Глупый вопрос, а что в resolv.conf в поде?

Значит, подозрение на то, что tcp на 53й порт что-то зарубает.

Да, становится и правда яснее. kuber@kube-master:~$ kubectl get service —all-namespaces | grep kube-dns kube-system kube-dns ClusterIP 10.96.0.10 <none> 53/UDP,53/TCP 20d home:~$ nc -vv 10.73.64.167 53 DNS fwd/rev mismatch: cfg != cfg.crptech.local cfg [10.73.64.167] 53 (domain) open любой хост: any-host:~$ nc -vv 10.96.0.10 53 <завис/пусто> однако если через udp: any-host:~$ nc -uvv 10.96.0.10 53 Connection to 10.96.0.10 53 port [udp/domain] succeeded! С мастера (где поднят kube-dns): kube-master:~$ nc -vv 192.168.221.203 10053 (внутренний ip контейнера) Connection to 192.168.221.203 10053 port [tcp/*] succeeded! kube-master:~$ nc -vv 10.96.0.10 53 (clusterIP сервиса) Connection to 10.96.0.10 53 port [tcp/domain] succeeded!

Пофиг на tcp. Главное чтобы udp ходило

дебажить неработающий dns в k8s это давнишняя народная забава

Не легче hosts прибить?

Я их руками пишу и стараюсь не допускать дублирования

То есть, если у меня 5 сред, то и ямлов для деплоймента тоже 5? Не кажется слабо масштабируемым решением?

Коллеги, добрый день. Есть такой архитектурный вопрос. Изучаю микросервисы, пытаюсь понять, как их правильно организовать. Стек простой: golang+cockroachdb. Итого у меня есть три варианта: 1) Контейнер приложения и контейнер базы лежат в одном поде внутри стейтфул-сета. 2) приложение и база в разных подах, база в стейтфул-сете, у базы отдельно есть балансировщик. 3) базу вообще вынести из кубов. Как организовать все кошерно/феншуйно?

Ок. Опишу более детально. Есть около 40 сервисов (часть своих, часть легаси). У каждого из них есть свои конфиги (свои можно переписать на ENV, но это будет долго). Сейчас есть сервис хранения и раздачи конфигов. При подъеме сервиса дергаем курлом конфиг и поднимаемся. Вроде все отлично, но меня смущает безопасность и сама идеология. Хотелось бы отказаться от этого сервиса с конфигами и хранить их как-то более правильно.

Ваще если конфиг никогда во время жизни приложения не меняется, то конфигмапы ок

база в statefulset+сервис, приложение в отдельном деплойменте (возможно с HPA - если надо скейлить) и ходит в базу через сервис

В нашем случае конфиг статический и меняется сильно редко. Дергаем при старте из сервиса и сохраняем внутри контейнера.

я бы предложил следующее: 1. сделать helm chart на каждый сервис 2. каждый helm chart должен все что надо этому сервису получать через values.yaml 3. прокидывать значения из values.yaml в deployment через env (+ env value from secret и секреты для секретов) 4. дальше в контейнере(рах) каждого деплоймента в entrypoint.sh из этих переменных окружения генерить конфиги

+1, в таком случае можно весь конфиг этот передать через values.yaml и потом хелмом создать конфигмап и данные из values положить в конфигмап

И еще момент, никто не извращался так: нужно поднять еще один кластер монги, есть мысль добавить worker ноды и на них не через куб поставить монгу. Профит - легко подключить к мониторингу, минусы …?

Имеется в виду ситуация, когда deployment потребляет конфиг, конфиг меняется, а deployment (точнее, поды) нужно передёргивать руками

а можно ли прикрутить s3 bucket как shared storage?

Народ, странная ситуация: я только что обнаружил, что резолвинг dns не работает из подов. Проверил первым делом, что kube-dns запущен: kuber@kube-master:~$ kubectl get svc —namespace=kube-system | grep dns kube-dns ClusterIP 10.96.0.10 <none> 53/UDP,53/TCP 19d Убедился, что запущен по всем нодам (их три): kuber@kube-master:~$ kubectl get pods —namespace=kube-system -l k8s-app=kube-dns | grep dns kube-dns-86f4d74b45-bzp88 3/3 Running 1 19d Запустил busybox, проверяю, получается вот что: kuber@kube-master:~$ kubectl exec -ti busybox — nslookup kubernetes.default Server: 10.96.0.10 Address 1: 10.96.0.10 nslookup: can't resolve 'kubernetes.default' Пока смотрю в сторону iptables. Но может есть другие соображения? Буду очень признателен за любую подсказку, давно бьюсь.

по поводу aws ebs - как то криво получается у меня типа красиво multi az а ebs коннектится только в своей az чет не могу понять как нормально сделать

Кстати, а сколько рекомендуется памяти на мастере при, скажем, 200 подах

Правильное переиспользование в 90% случаев эффективнее, КМК.

Что за value.yaml? Можно подробнее?

Спасибо... Helm я чет пока не осилил. Какое-то оно слишком перемудреное, ИМХО.

Извиняюсь что вмешиваюсь Вы как отдаете values.yaml хэлму? Обычным способом?

4 гиг должно хватать же?

Ладно. Со временем разберусь

Там все