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

кроме ютрека особо терять нечего. конфигурации в teamcity меняются редко, sentry больше как лог ошибок не более того. а вообще про бекапы согласен. как раз думал как это сделать до того как все посыпалось

бакулу натравите сырые диски срезать и всё тут :) ну если денег много можно акронис

@nailgunster, тот же новоразвернутый через kubeadm. Стабильненько падает kube-dns в 1/3 2/3. Может ещё какое-нибудь дополнительное действие было там? :)

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

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

а это тебе не хостер случяаем ноды ребутит?

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

я мониторинг отключил

знаю эту тему)

ну тогда вот https://github.com/coreos/docs/blob/master/os/collecting-crash-logs.md

cпасибо, не знал

но там пусто(

походу железо не поддерживает эту фичу

Since this mechanism is just an abstraction, it depends on hardware support to actually persist the data across reboots. If the hardware support is absent, the pstore will remain empty. хотя On AMD64 machines, pstore is typically backed by the ACPI error record serialization table (ERST).

должно бы быть

нашел на одной ноде

https://pastebin.com/HURRr1tR

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

что-нибудь почитать или носом тыкнуть

бакулу натравите сырые диски срезать и всё тут :) ну если денег много можно акронис

Отличный совет, особенно - для нагруженных бд

не ну малоль для чего :)

для бд конечно другие вещи нужны

Ребят, а как можно запретить подам доступ к внутренней сети? А то у нас такая проблема, что из пода можно стучаться напрямую к etcd по ip. etcd настроен на другой сети. Нам нужно либо как-то засекьюрить etcd, либо сделать так, чтобы из подов нельзя было до туда достучаться. Подскажте возможные решения

Ребят, а как можно запретить подам доступ к внутренней сети? А то у нас такая проблема, что из пода можно стучаться напрямую к etcd по ip. etcd настроен на другой сети. Нам нужно либо как-то засекьюрить etcd, либо сделать так, чтобы из подов нельзя было до туда достучаться. Подскажте возможные решения

1. в etcd слушать только localhost у 2379, если etcd и kube-apiserver на одной ноде 2. включить авторизацию по сертификатам в etcd

У нас etcd кластер поднят на 3 нодах, с сертификатами мучаемся уже 3 день, с ними, почемуто, не поднимается canal нормально. dns под постоянно ребутается.

Привет. Ребят, помогите решить проблему, пытаюсь поставить кластер etcd с сертификатами на куб, в итоге все встает, но когда ставлю Network Policy - canal, dns не поднимается, пишет что RUNNING 2/3 . В контейнере kube-dns пишет что не может подключиться к kube-api - https://gist.github.com/25b9e6f058caebf35e0ba5b37c7f9e71 Куб 1.6.6, etcd 3.2.1, поднят кластер из 3 машин, без etcd сертификатов все работает

Вот, собственно, тоже, вечно 1/2, 2/3, изредка ready проскакивал.

Тоже три ноды.

у нас canal нет, но как я помню в calico можно kube-apiserver как хранилище вместо etcd использовать

товарищи, какие best practices есть для деплоя подов с сервисами, которые будут path/domain-based роутинг выполнять в неймспейсе? вот есть перепиленный nginx, хотелось бы красиво через configmap определить статические конфиг. параметры, и возможно дописывать параметры для индивидуальных vhost'ов. это через annotations делается, если есть такие параметры в конфиг. темплейте? то есть это надо вообще все параметры темплейтезировать? если поставить кратко вопрос - каким образом kind ingress подставляет секции server{} и выносит инклуды с upstream{}'ами?

господа, кто нибудь разбирается в coredump логах ядра? я так понял тут https://pastebin.com/raw/HURRr1tR только второй кусок дампа. к сожалению первого почему то в pstore нет. по этому куску не понять где произошла ошибка?

сделал это на каждой ноде: mount -o remount,kmsg_bytes=100000 /sys/fs/pstore возможно в следующий раз сохранится больше данных

у нас canal нет, но как я помню в calico можно kube-apiserver как хранилище вместо etcd использовать

А у вас мультимастер или нет? По идее же kube-apiserver на одной ноде запущен, и если она упадет, то остальные не смогут ничего подтянуть. Для этого у нас кластер etcd, если упадет 1 мастер, то все будет продолжать работать. У нас мультимастер, 3 мастера.

Вот, собственно, тоже, вечно 1/2, 2/3, изредка ready проскакивал.

а describe что говорит?

товарищи, какие best practices есть для деплоя подов с сервисами, которые будут path/domain-based роутинг выполнять в неймспейсе? вот есть перепиленный nginx, хотелось бы красиво через configmap определить статические конфиг. параметры, и возможно дописывать параметры для индивидуальных vhost'ов. это через annotations делается, если есть такие параметры в конфиг. темплейте? то есть это надо вообще все параметры темплейтезировать? если поставить кратко вопрос - каким образом kind ingress подставляет секции server{} и выносит инклуды с upstream{}'ами?

Я решал эту задачу через traefik

@nailgunster, https://hastebin.com/hahabareja

Собственно, dashboard тоже в CrashLoopBackOff, и, как понимаю, все беды из-за kube-dns.

Я решал эту задачу через traefik

не важно, что будет. haproxy/linkerd/..., выбираться будет kubernetes.io/ingress.class как я понял. я о менеджменте самого ингресс-сервиса.

https://github.com/kubernetes/ingress/blob/master/controllers/nginx/rootfs/etc/nginx/template/nginx.tmpl

Добавил в iptables -A INPUT -i flannel.1 -j ACCEPT -A INPUT -i cni0 -j ACCEPT kube-dns починился. :)

А что за интерфейс cni0?

А у вас мультимастер или нет? По идее же kube-apiserver на одной ноде запущен, и если она упадет, то остальные не смогут ничего подтянуть. Для этого у нас кластер etcd, если упадет 1 мастер, то все будет продолжать работать. У нас мультимастер, 3 мастера.

Я немного запутался во всех этих мастерах. В идеальном варианте доступ к etcd должен быть только у apiserver. Наверно поэтому flannel, canal, calico умеет работать без etcd (сам не проверял)

@mastanggt Моя нуб, моя не знает, какой-то там container network interface, судя по всему. Просто посмотрел, какие есть интерфейсы и добавил те, что похожи на нужные. :)

Теперь пытаюсь заставить dashboard работать. Там ведь достаточно kubectl create -f https://git.io/kube-dashboard или всё-таки что-то для rbac нужно прописывать дополнительно?

Я немного запутался во всех этих мастерах. В идеальном варианте доступ к etcd должен быть только у apiserver. Наверно поэтому flannel, canal, calico умеет работать без etcd (сам не проверял)

flannel в 0.9 вроде начучилась слать данные в аписервер а не в етсд

flannel в 0.9 вроде начучилась слать данные в аписервер а не в етсд

А там не 0.7.1 сейчас?)

это смотря где)

flannel в 0.9 вроде начучилась слать данные в аписервер а не в етсд

Да --kube-subnet-mgr: Contact the Kubernetes API for subnet assignment instead of etcd.

https://github.com/coreos/flannel/blob/master/Documentation/configuration.md

image: quay.io/coreos/flannel:v0.7.0 Вот наш

хм, значит туплю с версиями уменя вообще акя то древняя стоит..

у меня 0.5.3 значит фичу я видел в апдейте дл 0.6

Не работает dashboard, просто /ui отваливается по таймауту. Следую https://github.com/kubernetes/dashboard/blob/master/docs/user-guide/troubleshooting.md Там предлагают проверить, проходит ли авторизация вообще, но у меня в принципе kubectl exec test-701078429-s5kca -- curl -k https://10.0.0.1 не завершается. Из-за чего такое вообще может происходить? Адрес подставляю нужный, из get services.

Не работает dashboard, просто /ui отваливается по таймауту. Следую https://github.com/kubernetes/dashboard/blob/master/docs/user-guide/troubleshooting.md Там предлагают проверить, проходит ли авторизация вообще, но у меня в принципе kubectl exec test-701078429-s5kca -- curl -k https://10.0.0.1 не завершается. Из-за чего такое вообще может происходить? Адрес подставляю нужный, из get services.

Ходят ли пинги между всем нодами по адресу который в сети flannel, у меня было похожее из-за неправильной настройки. Часть flanneld смотрела на etcd часть через apiserver

@notxcain, имеется в виду подключиться к разным docker-flannel-ds-... и попинговать адреса из flennel.1?

Попинговал, всё ходит. :( Разворачивал просто kubeadm, без прибамбасов.

попробуй в веб уи указать явно апи сервер: - —apiserver-host=

ну заходишь на ноду, неважно мастер или воркер, и пингуешь другие по адресу из flannel.1

Все пингуют всех. :(

Адрес, что у пода kube-apiserver-... на flannel.1? Пробовал. Из kube-apiserver адрес dashboard во flannel.1, кстати, не пингуется.

попробуй в веб уи указать явно апи сервер: - —apiserver-host=

В общем, между людыми созданными не kubeadm подами связи не было с flannel. :( Пока на weave в итоге. Может кто-нибудь из пользователей kubeadm на досуге опишет список дополнительных манипуляций, при помощи которых удавалось завести flannel?

В общем, между людыми созданными не kubeadm подами связи не было с flannel. :( Пока на weave в итоге. Может кто-нибудь из пользователей kubeadm на досуге опишет список дополнительных манипуляций, при помощи которых удавалось завести flannel?

Сети в кубере вообще работают очень своеобразно. Например, я не смог запустить weave через kargo - причём сначала он завёлся, а при попытке его перенастроить мгновенно умер

кто-нибудь сталкивался с этой мессагой? навскидку на что может ругаться? StatefulSet in version "v1beta1" cannot be handled as a StatefulSet: quantities must match the regular expression '^([+-]?[0-9.]+)([eEinumkKMGTP]*[-+]?[0-9]*)$' https://pastebin.com/Z6QzF7Cy

Gb точно можно? вроде ж Gi?

да, ты прав

Ребят, а как можно запретить подам доступ к внутренней сети? А то у нас такая проблема, что из пода можно стучаться напрямую к etcd по ip. etcd настроен на другой сети. Нам нужно либо как-то засекьюрить etcd, либо сделать так, чтобы из подов нельзя было до туда достучаться. Подскажте возможные решения

calico Policy позволяют все это гибко и централизованно настраивать

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

оно потупит, потом будет NodeNotReady (или как-то так), потом еще немного потупит, потом начнется переезд подов с этой проблемной ноды. таймауты наверняка настраиваемы

оно потупит, потом будет NodeNotReady (или как-то так), потом еще немного потупит, потом начнется переезд подов с этой проблемной ноды. таймауты наверняка настраиваемы

последний раз я ждал минут 20

ноды в статус NotReady переходит?

daemonSet'ы в NodeLost уходили, а обычные подки в Unknown

ноды в статус NotReady переходит?

да

https://kubernetes.io/docs/concepts/architecture/nodes/ pod-eviction-timeout

60s выставлял

есть одно небольшое но. Я не знаю как бы себя вёл кубер на стандартной поставке и сборке через kubeadm

у меня кластер собран через kubeadm и из него собрал HA на трёх мастерах

флажки компонентам выставлял по HA-докам кубера, но не уверен что все поставил и правильно ли

вот еще: https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#per-pod-configurable-eviction-behavior-when-there-are-node-problems-alpha-feature

ну и вот еще по первой ссылке: In versions of Kubernetes prior to 1.5, the node controller would force delete these unreachable pods from the apiserver. However, in 1.5 and higher, the node controller does not force delete pods until it is confirmed that they have stopped running in the cluster. One can see these pods which may be running on an unreachable node as being in the “Terminating” or “Unknown” states. In cases where Kubernetes cannot deduce from the underlying infrastructure if a node has permanently left a cluster, the cluster administrator may need to delete the node object by hand. Deleting the node object from Kubernetes causes all the Pod objects running on it to be deleted from the apiserver, freeing up their names.