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

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

при этом kubectl get nodes работает только на master01

у вас kubelet в мастеры как ходит?

на воркерах через балансер

у kubelet раньше даже пингов не было, чтобы отвалившийся apiserver поймать. сейчас вроде сделали, так что worker01 должен скоро появиться

привет, простите за нубский вопрос, только недавно начала разбираться вот у меня есть сервис, он по запросу на определённый порт (положим 8765) возвращает маленький json со статусом. Когда я захожу через kubectl exec ... -it sh в сам сервис и вызываю там curl localhost:8765, то возвращается то что нужно теперь пытаюсь создать ингресс чтобы сделать доступ извне. Создала ингресс-контроллер, создала ингресс. Чтобы проверить, работает ли, захожу опять в контейнер и вызываю теперь уже айпи:порт. Курл молчит. А теперь мой вопрос: как бы мне последовательно проверить, какие из этих штук (сервис, ингресс, контроллер) работают как надо?

сервис у вас какого типа?

привет, простите за нубский вопрос, только недавно начала разбираться вот у меня есть сервис, он по запросу на определённый порт (положим 8765) возвращает маленький json со статусом. Когда я захожу через kubectl exec ... -it sh в сам сервис и вызываю там curl localhost:8765, то возвращается то что нужно теперь пытаюсь создать ингресс чтобы сделать доступ извне. Создала ингресс-контроллер, создала ингресс. Чтобы проверить, работает ли, захожу опять в контейнер и вызываю теперь уже айпи:порт. Курл молчит. А теперь мой вопрос: как бы мне последовательно проверить, какие из этих штук (сервис, ингресс, контроллер) работают как надо?

1) kubectl exec вы делали в конкретный контейнер в поде. сервис это надстройка над множеством подов, на которые она раскидывает трафик (через DNAT по IP или DNS round robin или вообще внешний балансер в облаках). порт в контейнере в общем случае может отличаться от порта в сервисе 2) проверить, что ингрес контроллер работает просто - постучитесь в него извне куба по какому нибудь имени, о котором он точно незнаетт, должны получить "404 - default backend"

сервис у вас какого типа?

LoadBalancer

чтобы в целом разобраться в вопросе, я бы порекомендовал (в довесок к документации) цикл статей, которые про это рассказывают: https://medium.com/google-cloud/understanding-kubernetes-networking-pods-7117dd28727 там три статьи, последняя как раз про ингресс. Теоретически, вы могли ошибиться где угодно. Проверьте, что сервис доступен по ip ноды, порт должен быть другим.

спасибо!

если у вас Load Balancer и есть внешний IP, то он уже должен был быть доступен без ingress, это тоже можно проверить

▫️Какой у вас проект или где работаете? Игровой проект, Vizor Games ▫️В чём вы специалист? разработка 3д игр, веб-разработка, Arduino ▫️Чем можете быть интересны или полезны сообществу? пока не в курсе ▫️Чем интересно сообщество вам? информацией о kubernetes ▫️Откуда вы? Минск ▫️Как узнали про группу? от коллеги #whois

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

сейчас weave, но вроде CNI тоже будет. Я там не сетями занимаюсь, и только начал, так что многого не знаю пока

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

▫Какой у вас проект или где работаете? API for compex distributed system ▫В чём вы специалист? java backend, services, architecture ▫Чем можете быть интересны или полезны сообществу? время покажет ▫Чем интересно сообщество вам? новости, опыт использования ▫Откуда вы? Spb ▫Как узнали про группу? ссылка на habr #whois

господа, кто нибудь кубеспреем ставил докер на devicemapper'e?

ок, как мне кубеспрей заставить конфигурить devicemapper вместо overlay

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

А почему ты хочешь именно дм?

Потому что вот https://bugs.openjdk.java.net/browse/JDK-8165852

Потому что вот https://bugs.openjdk.java.net/browse/JDK-8165852

если там написана правда, то оно и в chroot работать не будет

Debian в ядром из Jessie на btrfs?

думаю что тут надо не об overlayfs vs. devicemapper стоит задуматься

etcd-0 Unhealthy Get https://192.168.117.101:2379/health: x509: certificate signed by unknown authorityкуда копать?

etcd-0 Unhealthy Get https://192.168.117.101:2379/health: x509: certificate signed by unknown authorityкуда копать?

https://github.com/moby/moby/issues/8849 Get cacert.pem from http://curl.haxx.se/docs/caextract.html Copy the cacert.pem file to /etc/pki/trust/anchors/ sudo update-ca-certificates sudo systemctl docker stop sudo systemctl docker start

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

etcd-0 Unhealthy Get https://192.168.117.101:2379/health: x509: certificate signed by unknown authorityкуда копать?

Это кто говорит?

kubectl get componentstatuses

можно как-то проверить один etcd в отрыве от куба?

etcdctl cluster-health

$ openssl s_client -connect 192.168.117.101:2379 ... verify error:num=20:unable to get local issuer certificate verify return:1 ...

$ etcdctl cluster-health failed to check the health of member 1d7b8e70f80b643a on https://192.168.117.101:2379: Get https://192.168.117.101:2379/health: x509: certificate signed by unknown authority member 1d7b8e70f80b643a is unreachable: [https://192.168.117.101:2379] are all unreachable cluster is unhealthy

Ну можно подложить сертификат свой к другим корневым...

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

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

рискну предположить, что тебе нужно тогда не тот что в урле показан, а свой root ca положить и передернуть update-ca-certificate

куда положить?