они - офф дока кубернетиса. You will run docker, kubelet, and kube-proxy outside of a container, the same way you would run any system daemon, so you just need the bare binaries. For etcd, kube-apiserver, kube-controller-manager, and kube-scheduler, we recommend that you run these as containers, so you need an image to be built. т.е. я не знаю почему, но они пишут что можно или надо запускать kube-proxy вне контейнера, а все остальное в нем

я пока что не понял как работает прокся, ведь запускаю свой первый инстанс кубика 🙂 Так что я пока сам к таким выводам не пришел бы.

Спасибо за пояснение.

Дока очень большая и до этой ссылки я еще не дошел 🙂 спасибо.

к сожалению пока я так и учусь 🙁 Офф дока с первого раза не дает понимание, приходиться перечитывать и собирать формулировки одного и того же с разных источников. Вот я прочел про кубе прокси. Я понял что он делает, но я не понял зачем он это делает и какую задачу решает. И вот фиг знает какой теории мне не хватает 🙂

Благодарю за копипаст, но в этом тексте я не увидел описание существующей проблемы с которой я столкнусь в ближайшем будущем и способа ее решения которое предлагает kube-proxy. Прошу учесть, что я с кубернетисом всего 4-й вечер 🙂 И прокся это единственный компонент смысл и задачи которого я не понимаю 🙂 Все остальное уже вкурил

Всем ку, есть какие либо реккомендации по количеству мастеров относительно нод?

Всем ку, есть какие либо реккомендации по количеству мастеров относительно нод?

1-3-5

(количество, которое вы готовы потерять) + 1

etcd - (количество, которое вы готовы потерять) * 2 + 1

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

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

Обращаться можно к любому апи серверу

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

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

Обращаться можно к любому апи серверу

Эт другое

Ну да, обычно мастера не скеилятся

Отсюда и ограничение на количество нод

Но это не точно

Как я помню 5к нод в 1.8

На больших кластерах сплит-брейна не будет?

Зависит от количества etcd серверов :)

А сколько безопасно?) 3-5?

Начните с 3

Зависит от количества etcd серверов :)

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

А федерацию кто-нибудь заводил?

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

Ну если разделить сеть, будут голосовать за новый мастер

В каждой сети свой

а сплит-брейн здесь где?

А сколько безопасно?) 3-5?

даже 1 безопасно

потому что кластер будет работать и без мастера

вопрос только как долго)

а сплит-брейн здесь где?

ну теперь в одной части добавь ноды и вдругой

а потом востанови сеть

ну теперь в одной части добавь ноды и вдругой

зачем мне добавлять ноды?

пока что это идет по пути уранового лома

Ребят, застрял на сертификатах CA_CERT put in on node where apiserver runs, for example in /srv/kubernetes/ca.crt. MASTER_CERT signed by CA_CERT put in on node where apiserver runs, for example in /srv/kubernetes/server.crt MASTER_KEY put in on node where apiserver runs, for example in /srv/kubernetes/server.key KUBELET_CERT optional KUBELET_KEY optional ничерта не понимаю и не могу найти где сказано для чего какой сертификат и самое главное где их взять? Можно ли тут использовать Let`s Encrypt как-то и что если пока для АПИ нет домена, а обращения только по IP?

зачем мне добавлять ноды?

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

А федерацию кто-нибудь заводил?

???

Что?

Что?

Почитай что такое сплит-брейн, при разделении кластера рано или поздно состояние раздельных частей будет отличатся

в ответ предлагаю почитать про эффект даннига-крюгера и мои предыдущие ответы

и еще спеку рафта

Нашел доку https://rootsquash.com/2016/05/10/securing-the-kubernetes-api/ но я не догоняю что делать если у меня нету домена для мастера. Подскажите что делать?

А вот это вообще юзают? Или etcd может решить все задачи?https://github.com/thesandlord/kubernetes-pod-ip-finder

нужно получить список ip по лейблам

Нужен список всех хостов в под лейблом

как правильно его получить из пода? (будь то хост или айпи)

я в теории это понимаю. но как мне получить это и передать в переменную окружения?

(не дописал)

Мб кому пригодится detailed tutorial on how to deploy an HA Kubernetes Cluster inside an VPC on AWS..... https://www.youtube.com/watch?v=saXjuWG4PeU

есть 3 реплики, и каждая должна знать список

вот этого ,наприме рhttps://hub.docker.com/r/erlio/docker-vernemq/ там один из вариантов клатеризации - discovery node., т.е. нужно передать адресок первой ноды.

можно порпобовать с именем пока думаю должно сработать

Это доп. сервис? Или тип моего сервиса должен быть таким, вс смысле

ок

хендлес != headleass 😄

Как мне это поможет? Как они найдут друг друга? единственный clusterIP будет типа дискавери?

а между собой у них что, нат?

Whaaat? )

Да. Спасибо. Нашёл ещё по монге похожее

Да. Зукиперовская модель вполне. Теперь опять вопрос стораджа

Я так и не дошёл

Можно просто вольюм дать Куберу создать?

Я пока этого не понимаю до конца.

Да, я помню.

Можно его попросить создать вольюм на время жизни пода?

Удалён под- умерли данные

я сравниваю с подходом docker compose

Ну хорошо, начнем с обратного. Чарт Зукипера хочет PersistentVolume support

https://github.com/kubernetes/charts/tree/master/incubator/zookeeper

Это для меня что значит? Нужно как минимум вручную будет создавать вольюмы, да?

вот, например, тип local

или hostPath

я более глобально не могу понять подход к локальным вольюмам.

@p8sih вот emptyDir мне подойдет?

Ну даавай вслух порассуждаем

вот зукипер делает volumeClaimTemplates

как мне подсунуть emptyDir?

буду тогд смотреть на emptyDir

Ну судя по всему это то что надо в моем случае

https://kubernetes.io/docs/tasks/configure-pod-container/configure-volume-storage/