Ок, попробую так. Возможно просто делит одного пода поможет

если удалит один под, только удалённый под и запустится на одной из новых нод

старые останутся на своих местах

Ну да, но хотелось удобств :)

ну нет livemigration механизма для контейнеров в принцепе

так что мигрировать под может только через свою смерть

Логично что Кубер не должен убивать Под просто потому что

Можно кластер на одну железку поставить?

а какой же это тогда кластер?)

Куберовый

мм нет)

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

Всем Дратути. Гоняет ли тут кто кафку пол кубером?

Витя Гамов, подкаст Разбор Полетов, SA в Confluent

Логично что Кубер не должен убивать Под просто потому что

Я не про лайв миргейшен. Меня устроит через смерть пода. Ну и да, я это могу реализовать сам, думал вдруг уже есть, чего зря писать.

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

ну то есть можно на одной железке запустить etcd, kube-master и kube-node?

ну то есть можно на одной железке запустить etcd, kube-master и kube-node?

Да

супер, спс

https://techcrunch.com/2017/10/17/docker-gives-into-invevitable-and-offers-native-kubernetes-support/?ncid=rss

https://techcrunch.com/2017/10/17/docker-gives-into-invevitable-and-offers-native-kubernetes-support/?ncid=rss

как раз CRI-O зарелизился

как раз CRI-O зарелизился

а как оно лучше по сравнению с обычным подходом?

как минимум в нем нет такого впечатляющего количества глюков. Судя по историям тех, кто внедрил докер в прод – попытка обновления докера напоминает ремонт самолета в полете. Одно починил – другое отвалилось

как там оверлей2, тар починили в нем?

как минимум в нем нет такого впечатляющего количества глюков. Судя по историям тех, кто внедрил докер в прод – попытка обновления докера напоминает ремонт самолета в полете. Одно починил – другое отвалилось

а оно память процесов сейвит? я правильно понимаю что инстанцы можно в таком случае полностью клонировать?

поставил через kubespray кластер на одну железку. Это нормально что ядра что-то молотят по дефолту?

ну после плейбуки еще некоторое время требуется на шедулинг и запуск подов

по-ходу это нормальное состояние

не, не нормальное. проблема с днс была

вот нормальное

а оно память процесов сейвит? я правильно понимаю что инстанцы можно в таком случае полностью клонировать?

вы с CRIU не путаете?)

Скажите, как мне рассовать существующие поды по новым машинам? Было 3 старых, стало 17. Мне надо теперь их равномерно размазать. Что-то хорошее и светлое в голову не приходит, только ручная работа.

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

Скажите, как мне рассовать существующие поды по новым машинам? Было 3 старых, стало 17. Мне надо теперь их равномерно размазать. Что-то хорошее и светлое в голову не приходит, только ручная работа.

https://github.com/kubernetes/contrib/tree/master/rescheduler

https://github.com/kubernetes/contrib/tree/master/rescheduler

Или вот скорее: https://github.com/kubernetes-incubator/descheduler

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

Правильно

А на свежей установке:

kubectl describe storageclass default Error from server (NotFound): storageclasses.storage.k8s.io "default" not found это нормально?

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

В общем лучше сделать 3 мастера сразу. Падение мастера не такой уж и страх

Без него сервисы будут работать

В общем лучше сделать 3 мастера сразу. Падение мастера не такой уж и страх

а что нужно продублировать? апи-сервера достаточно будет? или шедулер и контроллер-менеджер тоже лучше сделать в нескольких экземплярах?

держи https://kubernetes.io/docs/admin/high-availability/

Спасибо!

делаю нагрузоное, микросервисы, синхронный REST http: TLS handshake error from 172.20.3.3:31861: EOF Error syncing deployment stage/my-microservice: Operation cannot be fulfilled on deployments.extensions "my-microservice": the object has been modified; please apply your changes to the latest version and try again Сталкивались? Перегрузка по сети?

там 100500 TIME_WAIT от микросервисного общение и все начинается сыпаться, ставлю на нодах net.ipv4.tcp_max_tw_buckets=2000000,net.ipv4.tcp_tw_reuse=1,net.ipv4.tcp_fin_timeout=10, не помогает... а kops не дает поставить experimental-allowed-unsafe-sysctls для kubelet есть идеи?

можно еще net.ipv4.ip_local_port_range увеличить. но может на keepalive переходить?

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

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

job контейнеры в кубе есть

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

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

хз, как вариант повесить хелсчек и как скрипт отработает отдать ок

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

супервизором ?

не dockerway-но 😀

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

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

тот же супервизор получается

разве?

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

exec просто в конце скрипта и всё

он вытеснит текущий процесс тем, что ему будет передано

https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/

прогревай экзеком

насколько помню, официальные образы sql бд так и работают, сначала инициализируют окружение, потом через exec запускают сам процесс

прогревай экзеком

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

в прогреве можно сделать проверку, грелось уже или нет =))

если честно, не вижу большой разницы из-за временных рамок

порядок действий должен остаться тем же

в прогреве можно сделать проверку, грелось уже или нет =))

такие мысли уже были, но както костыльно :)

та хоть файл-флажок и проверка башем

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

job же предложен был

а probe пускай опирается на прогретость кэша

а readinessProbe после удачной отработки еще запускается периодически?

The kubelet uses readiness probes to know when a Container is ready to start accepting traffic. A Pod is considered ready when all of its Containers are ready. One use of this signal is to control which Pods are used as backends for Services. When a Pod is not ready, it is removed from Service load balancers.

насколько понимаю готовность для того чтобы трафик на него пустить а живучесть для того чтобы принять решение что с ним делать если не отвечает

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

Я хочу, чтобы поды взаимодействовали по внутренней сети, через физический свитч, а не через интернет. В старой версии kubespray (где calico и flannel ставились отдельным докер-контейнером) я правил темплейт systemd-юнита плагина, где указывал IP сети, поверх которой будет работать плагин. Теперь calico/flannel ставятся, как Daemonset. Внутреннюю сеть не указать... Создал ишшью: https://github.com/kubernetes-incubator/kubespray/issues/1741 Но там сделали изменение в темплейте kubelet. Типа ему указать ip адрес. Но kubespray при деплое падает с ошибкой, что не может получить ответ от etcd. Как бы это и понятно - я же ему адрес внутренней сети указываю, у которой нет доступа в интернет... Вот теперь я начинаю сомневаться: это я что-то не правильно делаю, или я хочу непонятного? Как мне пустить весь трафик через внутреннюю сеть и сделать доступными поды извне, где hostNetwork: true?

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

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

ну а если приложение в процессе своей работы временно не может принимать трафик изза проблем с БД например?

за это отвечает liveness probe, которая должна кильнуть под

но если это именно проблемы с БД, то приложение должно проходить liveness probe, потому что это не его проблемы