И стоит ли это делать в проде?

а кто запретит?

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

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

Спасибо.

А быть может кто поделится годной схемой архитектуру кубера на проде

берёшь короче амазон или гугл и живёшь в них

берёшь короче амазон или гугл и живёшь в них

Ажур забыл!

а у них разве есть хостед кубер?

Ажур забыл!

И ibm

ты ещё скажи про яндекс

ещё redhat

ты ещё скажи про яндекс

У яндекса нет

как раз над этим я и работаю

К стати оно с CNI дружит ? calico в KVM пробрасывается ?

кто-то делал the hard way? что вот это за айпишник 10.32.0.1 вот здесь: https://github.com/kelseyhightower/kubernetes-the-hard-way/blob/master/docs/04-certificate-authority.md ? (не знаю как дать ссылку на строчку в markdown файл, можно поиском по странице, он там один такой)

кто-то делал the hard way? что вот это за айпишник 10.32.0.1 вот здесь: https://github.com/kelseyhightower/kubernetes-the-hard-way/blob/master/docs/04-certificate-authority.md ? (не знаю как дать ссылку на строчку в markdown файл, можно поиском по странице, он там один такой)

--service-cluster-ip-range=10.32.0.0/24 \\

https://github.com/kelseyhightower/kubernetes-the-hard-way/blob/master/docs/08-bootstrapping-kubernetes-controllers.md

а что это значит?

для сервисов которые выделяются?

--service-cluster-ip-range ipNet A CIDR notation IP range from which to assign service cluster IPs. This must not overlap with any IP ranges assigned to nodes for pods.

то есть это сам куб будет из этой подсети выбирать айпишники для сервисов, а потом kube-proxy прописывать их в netfilter?

то есть это сам куб будет из этой подсети выбирать айпишники для сервисов, а потом kube-proxy прописывать их в netfilter?

да

ok, спасибо

Можно ли в кубере использовать etcd для хранения своих данных?

не, не стоит. слишком велик риск. ни один инсталер не использует роли в etcd, слишком много придется перенастраивать руками. в etcd нету толковой изоляции, так что ваше приложение вполне может засрать etcd , что весь кластер развалится, вам оно надо?

кто-то делал the hard way? что вот это за айпишник 10.32.0.1 вот здесь: https://github.com/kelseyhightower/kubernetes-the-hard-way/blob/master/docs/04-certificate-authority.md ? (не знаю как дать ссылку на строчку в markdown файл, можно поиском по странице, он там один такой)

это айпишник который заберет себе АПИ кубера, он будет ДНАТится на ендпоинты

почему он фигурирует в сертификате?

почему он фигурирует в сертификате?

потому что изнутри на куб АПИ ходят по SSL

Кто он?

10.254.0.1 ?

10.254.0.1 ?

10.32.0.1

потому что изнутри на куб АПИ ходят по SSL

так ходят все, а айпишник один

почему он фигурирует в сертификате?

ПОтому что согласно pki все возможные имена и ip Сервера должны быть перечисленны в SAN. По умолчанию первый адресс в сети сервисов отводится под APIserver. И APIserver будет на нём отвечать, при чём по ssl протоколу, соответвенно что бы сертифкат был верен этот адрес должен быть в SAN

Это часть pki стандарта сертификации.

стандарт мне ясен, мне не совсем ясно, кто такой этот 10.32.0.1, что именно он будет ходить в API

это первый сервис кубернетиса, его ендпоинт это АПИСевер

он и есть апи

kubernets.default

стандарт мне ясен, мне не совсем ясно, кто такой этот 10.32.0.1, что именно он будет ходить в API

Он не будет ходить в АПИ, и стандарт вам явно не ясен. Это И есть Адресс Аписервера (один из его Альтернативных адрессова). И Он должен быть в сертифкате, что бы сертификат был Валидным

так ходят все, а айпишник один

Нет их может быть много. все Альтернативные имена сервера должны быть указаны в разделе SAN сертифката.

у апи сервера минимум три имени с ходу. ip накотором оно весит, kubernetes.default и первый ip из сети сервисов

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

Есть три мастера на 1.9.1, на каждом etcd. Жестко вырубаю одну из нод, оба оставшихся аписервера перестают отвечать на некоторые запросы (timeout exceeded), помогает только рестарт apiserver. Кто нибудь видел такое?

то есть мы можем сходить на апи по: 1) kubernetes.default 2) внутреннему айпишнику сервиса, который представляет kubernetes.default 3) айпишнику ноды, на которой запущен апи-сервер 4) внешнему айпишнику 5) локально для этого все эти ребята прописаны в сертификат апи-сервера. Я все верно теперь понимаю?

да

ок, спасибо

Все это должно быть в SAN иначе сертификат будет не валиден для одного из адрессов

у апи сервера минимум три имени с ходу. ip накотором оно весит, kubernetes.default и первый ip из сети сервисов

и просто kubernetes

Есть три мастера на 1.9.1, на каждом etcd. Жестко вырубаю одну из нод, оба оставшихся аписервера перестают отвечать на некоторые запросы (timeout exceeded), помогает только рестарт apiserver. Кто нибудь видел такое?

перестают отвечать на запросы изнутри куба?

Есть три мастера на 1.9.1, на каждом etcd. Жестко вырубаю одну из нод, оба оставшихся аписервера перестают отвечать на некоторые запросы (timeout exceeded), помогает только рестарт apiserver. Кто нибудь видел такое?

два etcd не смогут договориться

перестают отвечать на запросы изнутри куба?

Да, при этом в логах контроллеров тишина практически (v=4)

два etcd не смогут договориться

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

два etcd не смогут договориться

смогут quorum=2

Да, при этом в логах контроллеров тишина практически (v=4)

добро пожаловать в https://github.com/kubernetes/kubernetes/pull/56690

и просто kubernetes

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

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

Забыл сказать что используется reconciler новый. Там тоже интересно. Из двух оставшихся аписерверов только один остается в masterleases

добро пожаловать в https://github.com/kubernetes/kubernetes/pull/56690

я рпоблему решил, натравив этот сервис на lb так что с точки зрения кубера у меня один аписервер

а как HA LB реализовано?

Забыл сказать что используется reconciler новый. Там тоже интересно. Из двух оставшихся аписерверов только один остается в masterleases

а, если новые reconciler то это не 56690

а как HA LB реализовано?

миротворцем

pace != peace

но тоже склоняюсь попробовать через LB

Хм не замечал, что оно пишется не как peace

-)

миротворцем

тогда "ходотворцем"

а, если новые reconciler то это не 56690

А как reconciler решает эту проблему?

он оставляет только рабочие адреса в DNS сервиса, а значит session affinity не может помешать

ок, значит я неправильно думал про то как session affinity работает

Еще интересно что если через SIGKILL убить все мастер процессы и etcd то все продолжает работать, мрет именно когда виртуалку убиваю

Еще интересно что если через SIGKILL убить все мастер процессы и etcd то все продолжает работать, мрет именно когда виртуалку убиваю

poweroff?

да

надо бы тоже попробовать

а etcd какой версии? убивать надо ту, что с текущим лидером etcd да?

а etcd какой версии? убивать надо ту, что с текущим лидером etcd да?

я убивал ту где был лидер контроллера. etcd судя по логам норм там переизберается.

3.2.4

да и контроллер тоже переизберается

все равно до 3.2.15 обновите уж )

Убил нелидера

та же херня

убил master02, он с собой забрал еще пару нод # kubectl get nodes NAME STATUS ROLES AGE VERSION test-kube02-master01 Ready master 1d v1.9.2+coreos.0 test-kube02-master02 NotReady master 1d v1.9.2+coreos.0 test-kube02-master03 NotReady master 1d v1.9.2+coreos.0 test-kube02-worker01 NotReady node 1d v1.9.2+coreos.0 test-kube02-worker02 Ready node 1d v1.9.2+coreos.0

жесть какая то