почитал там описано про версию 3.6 ... с ней как раз проблем не было они начали появляться, когда я в том чарте, сменил версию образа на 4.0.3 в чем принципиальная разница в процессе развертывания, я пока не понял

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

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

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

У меня пока такой задачи не было. Но в чем проблема rbac'om зарезать доступ на уровне ns?

Если есть права запускать под, то этот под может замонтировать любой секрет и любой PVC в этом неймспейсе и даже любой PV во всем кластере

Warning FailedScheduling 51m (x2 over 51m) default-scheduler pod has unbound PersistentVolumeClaims (repeated 2 times)

Этого не может быть. Вы либо смотрите на разные поды либо показываете результаты с разных попыток либо просто выбрали какой то старый евент, который уже разрешился и проигнорировали все последующие. Если FailedSchedulling то никаких контейнеров нигде не стартует по-определению

Этого не может быть. Вы либо смотрите на разные поды либо показываете результаты с разных попыток либо просто выбрали какой то старый евент, который уже разрешился и проигнорировали все последующие. Если FailedSchedulling то никаких контейнеров нигде не стартует по-определению

так они и не запустились, отработала только стадия Init

Если есть стадия init то есть запущенный pod, значит все ошибки планировщика разрешились, например для pvc нашлись (создались) pv

Вам надо посмотреть kubectl logs имяпода

Добавьте -с имяинитконтейнера

алсо кто-нибудь юзает weave scope стендэлоун?

или может есть альтернативы?

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

сейчас все совсем запуталось. если вы конектитесь к постгресу внутри кластера - используйте service type clusterip например

потому что service type nodeport - это запаблишить для внешнего доступа, для клиентов вне кластера

потому что service type nodeport - это запаблишить для внешнего доступа, для клиентов вне кластера

ему с внешки надо подключиться

я потерял нить рассуждений

а стоп, я сам что то перепутал (

сорян

https://events.linuxfoundation.org/events/kubecon-cloudnativecon-europe-2019/cfp/

Добрый день. Подскажите, а как можно запустить ингресс контроллер на определенной ноде и после этого запретить на этой ноде запускать что-либо еще?

Добрый день. Подскажите, а как можно запустить ингресс контроллер на определенной ноде и после этого запретить на этой ноде запускать что-либо еще?

https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/

не пойму. вот есть сервис для ингресса https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/provider/baremetal/service-nodeport.yaml что в него нужно добавить?

Извиняюсь, за глупый вопрос

В сервисе - ничего

а где?

Извиняюсь, за глупый вопрос

Нужно toleration указывать в спецификации ingress-nginx

В контроллере

а где?

Смотри, на воркере, где нехочочешь что бы поды запускались пишешь: kubectl taint nodes %kube_node% node-role=ingress-nginx:NoSchedule

а где?

В спецификации самого ingress-nginx.yaml указываешь tolerations: - key: "node-role" operator: "Equal" value: "ingress-nginx" effect: "NoSchedule"

и он запустится на этой ноде, к которой taint применили?)

и он запустится на этой ноде, к которой taint применили?)

Да

и он запустится на этой ноде, к которой taint применили?)

Тоже самое что я тебе скинул, есть в доке https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/#concepts Которую тебе выше кинули)

наткнулся тут на забавный баг в systemd centos 7.4, systemd-219-42.el7_4.10 k8s установлен через кубспрей - 3 мастера. etcd запущен как отдельный контейнер скриптом /usr/local/bin/etcd (ну как кубспрей делает это по дефолту) После команды systemctl restart systemd-journald через 3 минуты systemd решает, что etcd умер и ребутает его. Помогло обновление systemd до последней версии. Проверялось на трех инсталляциях. У кого есть возможность - можете попробовать, повторяется или нет ?

аналогично ставил через kubespray, но ОС у меня CoreOS проблем таких не замечал

прод крутится уже пару месяцев

аналогично ставил через kubespray, но ОС у меня CoreOS проблем таких не замечал

я в корос не очень. там есть системд ? systemctl restart systemd-journald пробовали на одном из мастеров ?

да там есть systemd

systemd "решает что etcd умер" - это как?

могу попробовать но вечером

Версии какие? Там и там

systemd "решает что etcd умер" - это как?

скорее всего наоборот

systemd "решает что etcd умер" - это как?

в логах это выглядит так: Nov 20 23:58:08 master-3 systemd: etcd.service: main process exited, code=exited, status=141/n/a Nov 20 23:58:10 master-3 docker: etcd3 Nov 20 23:58:10 master-3 systemd: Unit etcd.service entered failed state. Nov 20 23:58:10 master-3 systemd: etcd.service failed. Nov 20 23:58:25 master-3 systemd: Cannot add dependency job for unit docker.socket, ignoring: Unit not found. Nov 20 23:58:25 master-3 docker: etcd3

у вас etcd вышел с кодом 141

у вас etcd вышел с кодом 141

нуу докер контейнер с etcd завершился с кодом 141

а вот из логов контейнера

2018-11-20 20:58:08.012733 I | mvcc: store.index: compact 60625497 2018-11-20 20:58:08.015286 I | mvcc: finished scheduled compaction at 60625497 (took 2.194345ms) 2018-11-20 20:58:08.035774 N | pkg/osutil: received terminated signal, shutting down... WARNING: 2018/11/20 20:58:08 grpc: addrConn.resetTransport failed to create client transport: connection error: desc = "transport: Error while dialing dial tcp 172.20.2.4:2379: getsockopt: connection refused"; Reconnecting to {172.20.2.4:2379 0 <nil>} WARNING: 2018/11/20 20:58:08 grpc: addrConn.resetTransport failed to create client transport: connection error: desc = "transport: Error while dialing dial tcp 127.0.0.1:2379: getsockopt: connection refused"; Reconnecting to {127.0.0.1:2379 0 <nil>} 2018-11-20 20:58:09.036065 I | etcdserver: skipped leadership transfer for stopping non-leader member

172.20.2.4 - адрес узла.

141 - это pipe fail, то есть ваш контейнер фейланулся писать лог через пайп

что неудивительно, если log-driver установлен на journald

docker info Logging Driver: json-file

в общем, суть в том что у вас упал etcd при записи в какой-то файл через пайп. Связан ли с этим рестарт journald - это большой вопрос

господа, а weave scope работает, если сеть на flannel? или нужен weave net?

в общем, суть в том что у вас упал etcd при записи в какой-то файл через пайп. Связан ли с этим рестарт journald - это большой вопрос

ну я б не стал просто так утверждать ))) если оно работало месяцами в трех разных местах, и стабильно падает через 3 минуты после рестарта journald - то я думаю связь можно предположить с большой долей вероятности. особенно, что вылечивается все после обновления systemd

Не подскажите, а через kubespray можно удалить кластер?

или как-то сбросить настройки ?

Ща буду плакать от этого кубера. с сетью печаль беда. Разварачиваю кластер на bare-metal, без локальной сети, настраиваю calico. POD_CIDR=10.200.x.0/24. calico-node пишет: Readiness probe failed: calico/node is not ready: BIRD is not ready: BGP not established with 10.200.0.1

почему BIRD пытается соединяться по 10.200.0.1?

calico-kube-controllers пишет: Readiness probe failed: Error reaching apiserver: <nil> with http status code: 0

есть предположение что недопступен api из нутри кластера

с наружи хожу kubectl по IP:6443, всё ок

Не подскажите, а через kubespray можно удалить кластер?

конечно! и на этот вопрос легком можно ответить самостоятельно если просто зяглунть в репо kubespray!

Ща буду плакать от этого кубера. с сетью печаль беда. Разварачиваю кластер на bare-metal, без локальной сети, настраиваю calico. POD_CIDR=10.200.x.0/24. calico-node пишет: Readiness probe failed: calico/node is not ready: BIRD is not ready: BGP not established with 10.200.0.1

я помню запарился с bare-metall и flannel. Задеплоил weave и все встало нормально 😕

Если нет острой необходимости в calico - поставь weave и все

Ща буду плакать от этого кубера. с сетью печаль беда. Разварачиваю кластер на bare-metal, без локальной сети, настраиваю calico. POD_CIDR=10.200.x.0/24. calico-node пишет: Readiness probe failed: calico/node is not ready: BIRD is not ready: BGP not established with 10.200.0.1

а yaml можешь сказать откуда взял? что в них? =)

а yaml можешь сказать откуда взял? что в них? =)

от сюда брал https://docs.projectcalico.org/v3.3/getting-started/kubernetes/installation/calico неизменённый https://docs.projectcalico.org/v3.3/getting-started/kubernetes/installation/rbac.yaml а тут сеть подправил https://docs.projectcalico.org/v3.3/getting-started/kubernetes/installation/hosted/calico.yaml

это который из методов установки кластера? с kubeadm?

- name: CALICO_IPV4POOL_CIDR value: "10.200.0.0/16

это который из методов установки кластера? с kubeadm?

который Installing with the etcd datastore

я имел в виду который метод деплоя кластера

деплой кластера по the-hard-way

/24 как-то маловато будет ?

/24 на одну ноду

чего жадничать то в оверлее =)

ну пока не знаю потребностей. и в calico не оверлей

ок, как будешь дебажить?

Ща буду плакать от этого кубера. с сетью печаль беда. Разварачиваю кластер на bare-metal, без локальной сети, настраиваю calico. POD_CIDR=10.200.x.0/24. calico-node пишет: Readiness probe failed: calico/node is not ready: BIRD is not ready: BGP not established with 10.200.0.1

фаервол не закрывает BGP?

179 вроде порт

фаервол не закрывает BGP?

нет, BGP пытается ходить по локальному айпишнику, который должен быть внутри сети calico

10.200.1.0/24 такая сеть у подов должна быть

я не понимаю, должно ли быть так или нет, может BGP подразумевает что calico уже сделало сеть

меня вот эта ошиба сильно смущает Readiness probe failed: Error reaching apiserver: <nil> with http status code: 0

это от calico-kube-controllers