а вот подрубить кублет к кластеру

https://github.com/kubernetes/community/blob/master/contributors/design-proposals/self-hosted-kubernetes.md

kubelet как daemonset :)

а кто его стартанёт, если кублета нету?

запуск подов на конечном сервере осуществляет кублет

если его нету? то кто запустит контейнер, в котором кублет?

В документе все написано

Временный control plane

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

а откуда берётся временный контрол?

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

(я просто разматываю цепочку...-) есть ansible и другие способы доставки )

а что если нода ребутнётся?

демонсет не прописывает контейнеры в качестве сервисов в ОС

Bootkube Challenges This process has a number of moving parts. Most notably the hand off of control from the "host system" to the Kubernetes self-hosted system. And things can go wrong: 1. The self-hosted Kubelet is in a precarious position as there is no one around to restart the process if it crashes. The high level is that the system init system will watch for the Kubelet POSIX lock and start the system Kubelet if the lock is missing. Once the system Kubelet starts it will launch the self-hosted Kubelet. 2. Recovering from reboots of single-master installations is a challenge as the Kubelet won't have an API server to talk to to restart the self-hosted components. We are solving this today with "user space checkpointing" container in the Kubelet pod that will periodically check the pod manifests and persist them to the static pod manifest directory. Longer term we would like for the kubelet to be able to checkpoint itself without external code.

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

ехал kubelet через kubelet :)

Пока уровень 2 самый простой

А где прочитать про префикс label kubernetes.io/? Что это вообще и на что влияет?

label

это просто теги поиска...

так что он ни на что не влияет

А где прочитать про префикс label kubernetes.io/? Что это вообще и на что влияет?

можно код погрепать на эту тему

можно код погрепать на эту тему

главное не попутать по пути label и annotation -)

так что он ни на что не влияет

kubernetes.io/cluster-service: true Вот например такая метка. В логировании много, где используется. Если её убрать - каков будет результат?

логировании? Это скорее метка, что сервис работает на кластер (типо kube-dns)

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

типо kubectl get po -l kubernetes.io/cluster-service=true

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

https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/

Labels are key/value pairs that are attached to objects, such as pods. Labels are intended to be used to specify identifying attributes of objects that are meaningful and relevant to users, but do not directly imply semantics to the core system.

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

А вот аннотации уже интереснее)

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

Ну вот это самое главное. А то я для изучения вопроса их использовал, но мне они не очень помогали.

?

?

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

Но и селекторы ведь к лэйблам применяются?

Например у сервиса spec.selector

только к ним или как правило только к ним, насколько понимаю

Там есть ещё селекторы affinity

И другие штуки

https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity

или тут

http://blog.kubernetes.io/2017/03/advanced-scheduling-in-kubernetes.html

так что он ни на что не влияет

влияет. вот пример: https://github.com/kubernetes/kubernetes/blob/f542fe12837560d991218289e8297dac7362c7ba/pkg/controller/service/servicecontroller.go#L627

я в 1.5.2 мире пока ещё живу)

с лэйблами и аннотациями вообще маленький недокументированный адок

это точно)

влияет. вот пример: https://github.com/kubernetes/kubernetes/blob/f542fe12837560d991218289e8297dac7362c7ba/pkg/controller/service/servicecontroller.go#L627

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

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

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

Job тебе наверное поможет.

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

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

с лэйблами и аннотациями вообще маленький недокументированный адок

аннотации используются для альфа и бета фичей до того как попадут в полный спек объекта.

ага, особенно все AWS аннотации на сервисах :)

аннотации используются для альфа и бета фичей до того как попадут в полный спек объекта.

Особенно в nginx-controller -)

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

Это я к тому что аннотация используется к альфа/бета фичам)

В контроллере это самой что ни наесть прод фича, используемая для кастомизации nginx

В контроллере это самой что ни наесть прод фича, используемая для кастомизации nginx

да тоже верно

в доке написано, что аннтотации это метод передачи метаданных в сервисы

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

https://t.me/folderarchive — канал, где сливают платный полезный образовательный контент и курсы.

https://coreos.com/blog/kubernetes-turns-two

Подскажите про nodeSelector, пожалуйста. Если я укажу два - разворачиваться будет только в том случае, если обе метки есть у ноды(условие И)? Или по условию ИЛИ?

ERROR: S client not available

Я попробовал - вроде по условию И, но вдруг есть нюансы.

Нода должна иметь каждый из указаных селекторов

Подскажите про nodeSelector, пожалуйста. Если я укажу два - разворачиваться будет только в том случае, если обе метки есть у ноды(условие И)? Или по условию ИЛИ?

Собственно в доке так и написано > For the pod to be eligible to run on a node, the node must have each of the indicated key-value pairs as labels (it can have additional labels as well).

Это очень хорошо.

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

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

звучит хрупко

Ну вот так нужно :)

Да, можно

А как так сделать?

При шутдауне получаешь список подов своего сервиса и удаляешь их через api

но это выглядит ужасно в любом случае

Ну это понятно, я имел ввиду на уровне куба как-то связать

Через апи, самому, это не очень вариант

так это и есть на уровне куба) запрос-то в куб апи

А кто как с логированием вопрос решил? Все логи пишутся на машину, а оттуда сислогом\логстешем в кролик, или внутри подов к каждому сервису поднимать приложение и слать в него? Или какие то другие варианты?

Уже обсуждался тут вариант с filebeat

Или не здесь писал

Filebeat берёт json-file и отправляет в хранилище/очередь.

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

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

сделать livenessCheck остальных зависимым от того главного пода

А кто как с логированием вопрос решил? Все логи пишутся на машину, а оттуда сислогом\логстешем в кролик, или внутри подов к каждому сервису поднимать приложение и слать в него? Или какие то другие варианты?

Я поставил fluentd на каждую ноду и шлю логи в эластик. Очень не нравится мне этот способ - в кубернетесе не реализованы драйверы вывода логов. Всё пишется в файлы. Это дополнительные накладные расходы на IO. Хоть тут и говорят, что это ерунда и почти не почувствовать. Вопрос в другом: как ротировать файлы логов, сохранённых кубернетесом?

Флюент вроде не занимается этим сам.

А куб разве сам это не делает?

или надо daemonset какой то запускать?

Я поставил fluentd на каждую ноду и шлю логи в эластик. Очень не нравится мне этот способ - в кубернетесе не реализованы драйверы вывода логов. Всё пишется в файлы. Это дополнительные накладные расходы на IO. Хоть тут и говорят, что это ерунда и почти не почувствовать. Вопрос в другом: как ротировать файлы логов, сохранённых кубернетесом?

логами занимается docker , у него есть опции сколько логи хранить

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

логами занимается docker , у него есть опции сколько логи хранить

А по дефолту что-то у него настроено?

json

it’s recommended to use stdout and stderr directly and leave rotation and retention policies to the kubelet

https://kubernetes.io/docs/concepts/cluster-administration/logging/

json

Нет, я про занимаемое место, например.