важно понимать почему рекомендация именно такая

вот мне интересно почему они так рекомендуют)

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

сбой в кубере или калико - удаляет все данные из etcd от /, разнеся базы на разные кластеры - геморой получаешь только в одном месте

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

Всем привет! Нужна помощь по кубернетовскому апи-серверу! У меня с ним серьёзные проблемы. Я не понимаю, в чём дело, но он у меня не поднимается никак. Делал и по ручному мануалу и по готовым скриптам, которые сами всё поднимают - результат один и тот же всегда. Поднимаю на короси, которая заливается по PXE. етсд, фланел и докер стартуют нормально. далее стартую кублет, он подтягивает конфиги и запускает аписервер, контроллер, прокси и шедулер. контейнер с апи-сервером постоянно перезапускается. в логах ноды ничего осмысленного: 1427 reflector.go:190] k8s.io/kubernetes/pkg/kubelet/kubelet.go:382: Failed to list *v1.Service: Get http://127.0.0.1:8080/api/v1/services?resourceV 1427 reflector.go:190] k8s.io/kubernetes/pkg/kubelet/config/apiserver.go:46: Failed to list *v1.Pod: Get http://127.0.0.1:8080/api/v1/pods?fieldSele 1427 reflector.go:190] k8s.io/kubernetes/pkg/kubelet/kubelet.go:390: Failed to list *v1.Node: Get http://127.0.0.1:8080/api/v1/nodes?fieldSelector=m 1427 kubelet_node_status.go:230] Setting node annotation to enable volume controller attach/detach ну типа он сам к себе подключиться не может. в логах контейнера тоже фигня E0922 07:37:47.729469 1 status.go:62] apiserver received an error that is not an metav1.Status: rpc error: code = 13 desc = transport is closing E0922 07:37:50.553370 1 status.go:62] apiserver received an error that is not an metav1.Status: rpc error: code = 13 desc = transport: write tcp 10.1.29.11:52106->10.1.29.12:2379: write: connection reset by peer но вот что нашёл интересное - в каком то мануале заметил проверку того, что контейнер с апи-сервером жив, таким образом: curl http://127.0.0.1:8080/healthz так вот, у меня оно (пока контейнер не упал) выдаёт всегда следующее: [+]ping ok [-]poststarthook/bootstrap-controller failed: reason withheld [+]poststarthook/extensions/third-party-resources ok [-]poststarthook/rbac/bootstrap-roles failed: reason withheld [+]poststarthook/ca-registration ok healthz check failed я так подозреваю, что тут надо копать глубоко в кишки апи-сервера, но какой либо инфы я на эту тему вообще не нашёл.

ну с копс по факту тоже можно подредачить клоудформейшин что он создает

кому интересно - решил проблему. оказывается в kube-apiserver.yaml нехватало опции - —storage-backend=etcd2 ?

Это не решение проблемы. Скорее всего у вас просто etcd2. Кубер с версии 1.6 рекомендует использовать etcd3. А данная опция добавлена для совместимости

вместо решения проблемы - делаем костыль

думается там просто etcd2 стоит

по умоляанию в последней короси на борту идёт 2 етцд.

у кого есть опыт: вот допустим случилось ужасное, мастер-ноды легли (скажем конективити или просто они дохнут все разом). ясно что kubelet/kubectl и прочее важное не работает... но что происходит с приложениями/подами уже запущенными в кластере? что должно ожидаемо отвалиться?

у кого есть опыт: вот допустим случилось ужасное, мастер-ноды легли (скажем конективити или просто они дохнут все разом). ясно что kubelet/kubectl и прочее важное не работает... но что происходит с приложениями/подами уже запущенными в кластере? что должно ожидаемо отвалиться?

послезавтра выпил в новых версиях

у меня Атомик) етцд в контейнере

яж и говорю что не работает.. именно в этом плане (все статично) но то что сам процесс работает - эт ясно

КорьОСЬ - это косяк

у меня Атомик) етцд в контейнере

Вы ее еще накушаетесь)

не понял

я против вообще пускания чего либо в докер если надо privileged

нахера мне тогда контейнер, если мне надо дать контейнеру привилигированный дсотуп к системе

ну как, одной строчкой запустить мониторинг везде (daemonset) , удобно же.

у нас weave.. хорошо что пофиг... но таки это размышления или опыт?

чем оно удобнее нативного клиента системы мониторинга в системе, который доставляется системой управления конфигурациями?

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

окей мне perf top тоже из под привилигированного контейнера предлагаете запустить?