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

понял) У меня задача научиться разворачивать готовый к продакшену HA кластер для запуска приложений. Сейчас нагрузки минимальны. Кластер просто должен надежно и стабильно работать. Вторым этапом я планирую научиться создавать компоненты приложения каждый из которых будет пригоден к горизонтальному масштабированию. Это касается php-fpm, nginx, redis, rabbitmq, memcache и прочих, кроме PostgreSQL\MySQL который для продакшена в контейнерах лучше не хранить. Третим этапом я должен научиться автоматизировать сборку и выкатку приложения используя GitLab CI\Helm\dapp и подобное. Сейчас это задачи чисто образовательного характера. После получения знаний я буду строить приложения уже готовые к запуску в кубернетес, что является большим плюсом и определенным level up. Для выполнения первого этапа я сейчас читаю всю документацию по кубернетес и вникаю в концепт и каждый компонент, чтобы полностью понимать, что от чего зависит и как общается. В конце этапа я должен уметь создавать рабочий продакшен кластер руками, без всяких kubespray и прочей магии. Это нужно для того, чтобы уметь не только поднять но и починить\отдебажить проблему оперативно. Для второго этапа я изучил Docker и его идеологию, а так же на практике освоил пакование приложения и запуск его через docker-compose. Для тертьего этапа я разобрался с GitLab CI и настраивал простенькие и медленные сценарии сборки имеджей, тестов и прочего, без доставки на прод. Осталось заполнить некоторые пробелы по знаниям и profit! ? так норм?

впоследние время тут много интересных личностей появляется, видимо k8s серьезно набирает обороты :)

штука крутая, чего бы не научится ей пользоваться ?

я вижу это иначе. Кобрать кластер можно сотней способов и десятком конфигураций. Это понятно из документации. Мне пока не ясно два вопроса: 1. Здесь собрались профи и новичкам не рады? 2. Какие темы здесь принято обсуждать и для чего этот чат в принципе? Так как пока мои вопросы у некоторых вызывают только негатив.

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

надеюсь что вы восприймите мой совет в конструктивном ключе и приложите свою энергию к освоению kubernetes the hard way, а не написанию простыней в чатах.

"kubernetes the hard way" это рекомендованная точка старта?

бл*, как etcd перезапустить нормально?

а lfs - точка старта для знакомства с линуксом ?

Ну знакомство с Ubuntu не сделает из тебя хорошего админа, а вот LFS сильно приблизит

сервис etcd показывается что не может подконнектиться к другой ноде и поэтому не стартует, а на другой ноде показывает тоже самое, и они не стартуют каждый сам по себе и не дають стартовать другим

а lfs - точка старта для знакомства с линуксом ?

Доктор, может быть хотя бы Gentoo?

LFS для старта, это Эребор...

не надо флудить. Почитайте цели автора вопроса, которому я это отвечал.

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

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

и они запоминают соседей по ip адресам и ждут что те ответят

пока связь между большинством не появится etcd работать не будет

ну тоесть он работает, но отвечать никому ни на что не будет

ну я знаю что нужен кворум,но как его запустить, если они не хоят запускаться из-за этого?

падает процесс?

должн ждать пока не ответят (я как то etcd на стенде сломал, видел как выглядит)

процесс запустится если хотя бы один из уже узлов доступен ETCD_INITIAL_CLUSTER="СПИСОК_УЗЛОВ" ETCD_INITIAL_CLUSTER_STATE=new

другое дело если они одновременно запускаются и при этом никто из узлов не знает кто мастер среди них

ETCD_INITIAL_CLUSTER_STATE=new - не уничтожет то что было в кластере?

ETCD_INITIAL_CLUSTER_STATE=new - не уничтожет то что было в кластере?

постоянно перезапускаю так, но возможно у меня нет большой нагрузки на etcd в плане запросов

тоже изучал этот вопрос... помню нашел yaml-файл для запуска кластера etcd внутри kubernetes! там был именно такой параметр

да процессы запускаются и висят, но порты не доступны( curl -k https://10.135.74.89:2380 висит и не отвечает даже сам с себя

да процессы запускаются и висят, но порты не доступны( curl -k https://10.135.74.89:2380 висит и не отвечает даже сам с себя

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

Unable to register node "kube-master-1" with API server: Post https://127.0.0.1:6443/api/v1/nodes: dial tcp 127.0.0.1:6443: getsockopt: connection refused

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

нет, э то сам кубернтес

Unable to register node "kube-master-1" with API server: Post https://127.0.0.1:6443/api/v1/nodes: dial tcp 127.0.0.1:6443: getsockopt: connection refused

может фаервол блочит?

а что он бличить будет? не блочил - я просто на digitalocean resize дроплета сделал, а он не захотел запускаться после этого

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

Спасибо за конструктив. С "kubernetes the hard way" уже начал знакомиться.

может черех kubespray можное етсд перезапустить?

может черех kubespray можное етсд перезапустить?

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

сервис etcd показывается что не может подконнектиться к другой ноде и поэтому не стартует, а на другой ноде показывает тоже самое, и они не стартуют каждый сам по себе и не дають стартовать другим

Если они все пытаются стартануть, то кто же работает тогда? :) если кворум потерян, то,на сайте есть пошаговая инструкция восстановления

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

А вообще, я бы конечно посмотрел логи k8s и после логи etcd для начала

блин, iptables пустой, а его же docker докер стартует

Unable to register node "kube-master-1" with API server: Post https://127.0.0.1:6443/api/v1/nodes: dial tcp 127.0.0.1:6443: getsockopt: connection refused

слушай, это kubeletовые логи похоже, он с апи не может общаться изза того что etcd недоступен

слушай, это kubeletовые логи похоже, он с апи не может общаться изза того что etcd недоступен

верно!

https://docs.bitnami.com/kubernetes/how-to/using-kubecfg-with-atlassian-bamboo-to-deploy-kubernetes-workloads-on-gke/ кто нить использует kubecfg? =)

за одно вопрос который я так и не постиг! чем отличаются GCE и GKE?

https://docs.bitnami.com/kubernetes/how-to/using-kubecfg-with-atlassian-bamboo-to-deploy-kubernetes-workloads-on-gke/ кто нить использует kubecfg? =)

Использую потихоньку его родственника - ksonnet

чет даже не знаю, jsonnet действительно такой удобный? или это все изза хейтинга helm? =)

докер как-то криво стартует - не запускает iptables, соответственно нет проброса портов на контейнер etcd

Nov 22 10:05:31 kube-master-1 systemd[1]: Started Docker Application Container Engine. Nov 22 10:05:31 kube-master-1 env[1158]: time="2017-11-22T10:05:31.599938109Z" level=info msg="API listen on /var/run/docker.sock" Nov 22 10:05:36 kube-master-1 env[1158]: time="2017-11-22T10:05:36.702670757Z" level=error msg="Handler for GET /v1.24/containers/db76ee297b85/json returned error: No such container: db76ee297b85" Nov 22 10:05:36 kube-master-1 env[1158]: time="2017-11-22T10:05:36.738380755Z" level=error msg="Handler for GET /v1.24/containers/db76ee297b85/json returned error: No such container: db76ee297b85"

в логах только эти ошибки

у тебя кластер kubespray поставил? etcd там стартует из systemd, который просто запускает контейнер

который слушает на host network помоему

из кубестрея

я знаю, он ии тсартует, но не к нему нет доступа

смотри вообще все правила iptables, дампани трафик, ходит ли вообще что то

там вообще пустой iptables

причем тут докер?

gjnvje xnj jy tuj ljk;ty cnfhnjdfnm

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

iptables это cli утилита для управления netfilter, который в ядре и который как то особенно запускать не нужно. если на то пошло, kube-proxy набивать правила должен вместе с cni

ну факт в том что netfiler пустой

core@kube-master-1 ~ $ sudo iptables -nvL Chain INPUT (policy ACCEPT 437K packets, 37M bytes) pkts bytes target prot opt in out source destination 437K 37M KUBE-FIREWALL all — * * 0.0.0.0/0 0.0.0.0/0 Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 443K packets, 59M bytes) pkts bytes target prot opt in out source destination 443K 59M KUBE-FIREWALL all — * * 0.0.0.0/0 0.0.0.0/0 Chain KUBE-FIREWALL (2 references) pkts bytes target prot opt in out source destination 0 0 DROP all — * * 0.0.0.0/0 0.0.0.0/0 /* kubernetes firewall for dropping marked packets */ mark match 0x8000/0x8000

вот из-за этого к ETCD нет доступа

как его поправить? руками что ли правила писать?

ERROR: S client not available

ты это как то подтвердил? тут один всего DROP и там 0 packets

ну добавь вручную, раз уверен

логи контейнеров etcd посмотри уж наконец

ну ,дроп для маркированных пакетов, других правил нет, т.е. дефолт - дроп будет

2018-01-22 08:38:11.329314 I | raft: b6e881dc193a9c22 received MsgVoteResp from b6e881dc193a9c22 at term 498 2018-01-22 08:38:11.329386 I | raft: b6e881dc193a9c22 [logterm: 11, index: 8994531] sent MsgVote request to 78b1e82276163c68 at term 498 2018-01-22 08:38:11.329429 I | raft: b6e881dc193a9c22 [logterm: 11, index: 8994531] sent MsgVote request to c29ff22666434736 at term 498 2018-01-22 08:38:13.840914 W | rafthttp: health check for peer c29ff22666434736 could not connect: dial tcp 10.135.72.139:2380: i/o timeout 2018-01-22 08:38:13.841003 W | rafthttp: health check for peer 78b1e82276163c68 could not connect: dial tcp 10.135.74.168:2380: i/o timeout 2018-01-22 08:38:17.579104 I | raft: b6e881dc193a9c22 is starting a new election at term 498 2018-01-22 08:38:17.579200 I | raft: b6e881dc193a9c22 became candidate at term 499 2018-01-22 08:38:17.579248 I | raft: b6e881dc193a9c22 received MsgVoteResp from b6e881dc193a9c22 at term 499 2018-01-22 08:38:17.579281 I | raft: b6e881dc193a9c22 [logterm: 11, index: 8994531] sent MsgVote request to 78b1e82276163c68 at term 499 2018-01-22 08:38:17.579298 I | raft: b6e881dc193a9c22 [logterm: 11, index: 8994531] sent MsgVote request to c29ff22666434736 at term 499 2018-01-22 08:38:18.841437 W | rafthttp: health check for peer 78b1e82276163c68 could not connect: dial tcp 10.135.74.168:2380: i/o timeout 2018-01-22 08:38:18.841551 W | rafthttp: health check for peer c29ff22666434736 could not connect: dial tcp 10.135.72.139:2380: i/o timeout 2018-01-22 08:38:23.682833 E | etcdserver: publish error: etcdserver: request timed out 2018-01-22 08:38:23.842625 W | rafthttp: health check for peer c29ff22666434736 could not connect: dial tcp 10.135.72.139:2380: i/o timeout 2018-01-22 08:38:23.842732 W | rafthttp: health check for peer 78b1e82276163c68 could not connect: dial tcp 10.135.74.168:2380: i/o timeout 2018-01-22 08:38:27.078916 I | raft: b6e881dc193a9c22 is starting a new election at term 499 2018-01-22 08:38:27.079016 I | raft: b6e881dc193a9c22 became candidate at term 500 2018-01-22 08:38:27.079065 I | raft: b6e881dc193a9c22 received MsgVoteResp from b6e881dc193a9c22 at term 500 2018-01-22 08:38:27.079097 I | raft: b6e881dc193a9c22 [logterm: 11, index: 8994531] sent MsgVote request to 78b1e82276163c68 at term 500 2018-01-22 08:38:27.079141 I | raft: b6e881dc193a9c22 [logterm: 11, index: 8994531] sent MsgVote request to c29ff22666434736 at term 500 2018-01-22 08:38:28.842962 W | rafthttp: health check for peer 78b1e82276163c68 could not connect: dial tcp 10.135.74.168:2380: i/o timeout 2018-01-22 08:38:28.843040 W | rafthttp: health check for peer c29ff22666434736 could not connect: dial tcp 10.135.72.139:2380: i/o timeout 2018-01-22 08:38:33.843544 W | rafthttp: health check for peer c29ff22666434736 could not connect: dial tcp 10.135.72.139:2380: i/o timeout 2018-01-22 08:38:33.843708 W | rafthttp: health check for peer 78b1e82276163c68 could not connect: dial tcp 10.135.74.168:2380: i/o timeout 2018-01-22 08:38:35.079046 I | raft: b6e881dc193a9c22 is starting a new election at term 500 2018-01-22 08:38:35.079118 I | raft: b6e881dc193a9c22 became candidate at term 501 2018-01-22 08:38:35.079162 I | raft: b6e881dc193a9c22 received MsgVoteResp from b6e881dc193a9c22 at term 501 2018-01-22 08:38:35.079178 I | raft: b6e881dc193a9c22 [logterm: 11, index: 8994531] sent MsgVote request to 78b1e82276163c68 at term 501 2018-01-22 08:38:35.079190 I | raft: b6e881dc193a9c22 [logterm: 11, index: 8994531] sent MsgVote request to c29ff22666434736 at term 501 2018-01-22 08:38:38.683855 E | etcdserver: publish error: etcdserver: request timed out 2018-01-22 08:38:38.844487 W | rafthttp: health check for peer 78b1e82276163c68 could not connect: dial tcp 10.135.74.168:2380: i/o timeout 2018-01-22 08:38:38.844566 W | rafthttp: health check for peer c29ff22666434736 could not connect: dial tcp 10.135.72.139:2380: i/o timeout 2018-01-22 08:38:40.329200 I | raft: b6e881dc193a9c22 is starting a new election at term 501 2018-01-22 08:38:40.329338 I | raft: b6e881dc193a9c22 became candidate at term 502

2018-01-22 08:38:40.329366 I | raft: b6e881dc193a9c22 received MsgVoteResp from b6e881dc193a9c22 at term 502 2018-01-22 08:38:40.329387 I | raft: b6e881dc193a9c22 [logterm: 11, index: 8994531] sent MsgVote request to c29ff22666434736 at term 502 2018-01-22 08:38:40.329428 I | raft: b6e881dc193a9c22 [logterm: 11, index: 8994531] sent MsgVote request to 78b1e82276163c68 at term 502

да нет в логах ничего, кроме того что нет связи

хм, хотя контейнеры etcd к сети хоста привязаны

вот как делаю я: останавливаю все сервисы: kube-proxy, docker, iptables, а после в обратном порядке стартую. возможно что-то еще надо запустить

у меня cni+flannel

cni+flannel тоже есть, до куберстпрей их только на воркеры ставит

чет даже не знаю, jsonnet действительно такой удобный? или это все изза хейтинга helm? =)

Jsnnet удобный, ksonnet не очень пока. Может вот kubecfg попробовать, он поближе к голому jsonnet. В целом очень удобно оперировать объектами, а не текстом, можно удобные api для пользователей сделать , ассерты всякие чтобы читаемые ошибки девелоперам в лицо кидать, по-настоящему можно перетянуть финальные значения из одного компонента в другой без всяких соглашений и условностей.

cni+flannel тоже есть, до куберстпрей их только на воркеры ставит

ясно, в моем кластере все ноды являются мастер+воркерами

Jsnnet удобный, ksonnet не очень пока. Может вот kubecfg попробовать, он поближе к голому jsonnet. В целом очень удобно оперировать объектами, а не текстом, можно удобные api для пользователей сделать , ассерты всякие чтобы читаемые ошибки девелоперам в лицо кидать, по-настоящему можно перетянуть финальные значения из одного компонента в другой без всяких соглашений и условностей.

Можно простыню проверок на внутренние правила накатать и не писать свой admission plugin для этого.

ну ,дроп для маркированных пакетов, других правил нет, т.е. дефолт - дроп будет

в твоем листинге везде policy accept. ты это, не кидай сюда простыни логов. итак видна проблема - etcd не видит соседей. разберись почему

Можно простыню проверок на внутренние правила накатать и не писать свой admission plugin для этого.

тоесть описываем все в коде, потом превращает в json и кормим в kubectl? helm не нужен?

ну ,дроп для маркированных пакетов, других правил нет, т.е. дефолт - дроп будет

кстати, у меня была проблема с iptables и kubernetes. писал сюда, так как сам не понимал что проиходит. в итоге запускаю docker дополняя скрипт systemd вот таким образом: [Service] ExecStartPost=/usr/sbin/iptables -P FORWARD ACCEPT

кстати, у меня была проблема с iptables и kubernetes. писал сюда, так как сам не понимал что проиходит. в итоге запускаю docker дополняя скрипт systemd вот таким образом: [Service] ExecStartPost=/usr/sbin/iptables -P FORWARD ACCEPT

можно еще docker --iptables=false сделать

кстати, у меня была проблема с iptables и kubernetes. писал сюда, так как сам не понимал что проиходит. в итоге запускаю docker дополняя скрипт systemd вот таким образом: [Service] ExecStartPost=/usr/sbin/iptables -P FORWARD ACCEPT

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

можно еще docker --iptables=false сделать

думал об этом. только нужно ли это делать обязательно для правильной так сказать работы kubernetes?

kubespray так делает. в к8с правилами уже cni & kube-proxy управляют

тоесть описываем все в коде, потом превращает в json и кормим в kubectl? helm не нужен?

Имено, ksonnet может и сам в куб ходить, но после хелма я только kubectl apply доверяю, производственная травма :)

фигня какая-то... всё равно не хочет стартовать etcd

а одна нода вообще, постоянно падает... Jan 22 10:31:38 kube-master-3 etcd[1738]: 2018-01-22 10:31:38.043160 I | rafthttp: started streaming with peer b6e881dc193a9c22 (writer) Jan 22 10:31:38 kube-master-3 etcd[1738]: 2018-01-22 10:31:38.043902 I | rafthttp: started streaming with peer b6e881dc193a9c22 (stream MsgApp v2 reader) Jan 22 10:31:38 kube-master-3 etcd[1738]: 2018-01-22 10:31:38.045108 I | rafthttp: started streaming with peer b6e881dc193a9c22 (stream Message reader) Jan 22 10:31:39 kube-master-3 systemd[1]: etcd.service: Main process exited, code=exited, status=137/n/a Jan 22 10:31:39 kube-master-3 systemd[1]: etcd.service: Unit entered failed state. Jan 22 10:31:39 kube-master-3 systemd[1]: etcd.service: Failed with result 'exit-code'. Jan 22 10:31:54 kube-master-3 systemd[1]: etcd.service: Service hold-off time over, scheduling restart. Jan 22 10:31:54 kube-master-3 systemd[1]: Stopped etcd docker wrapper. Jan 22 10:31:54 kube-master-3 systemd[1]: Starting etcd docker wrapper... Jan 22 10:31:54 kube-master-3 docker[2035]: etcd3 Jan 22 10:31:54 kube-master-3 systemd[1]: Started etcd docker wrapper.

Привет! Кто-нить знает как можно перезапустить контейнеры пода?

Привет! Кто-нить знает как можно перезапустить контейнеры пода?

* рестарт всей поды * хэндлинг сигналов в контейнере

Привет! Кто-нить знает как можно перезапустить контейнеры пода?

штатных стредств нет, - или зайти на хост и докером рестатрануть или зайти в контейнер и kill -9 1 сделать

спасибо, чёт неправильно начал мыслить) попробовал просто удалить под, деплоймен его перезапустил)

надо был мыслить чуть выше