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, потому что это не его проблемы

БД от этого не заработает и оно будет его килять до победного конца?

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

Это readness probe

БД от этого не заработает и оно будет его килять до победного конца?

Это readness probe и под будет исключен из endpoint для сервисов

но после того как pod становится ready эта проба больше не выполняется

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

но после того как pod становится ready эта проба больше не выполняется

Разве?

ну я ради интереса прибил index.php в запущенном контейнере, начало отдавать 404, но состояние пода никак не изменилось

Насколько мне известно они работают всегда

readness с момента старта liveness с момент ready

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

да keep-alive везде включен но php-fpm все равно генерит кучу и не делает reuse...

судя по всему, все-таки я был неправ, и readinessProbe выполняется постоянно, только если liveness проверяет, не закрашился ли под (и надо ли его пересоздать), то readiness проверяет, в рабочем ли режиме приложение (и надо ли слать на него трафик)

да keep-alive везде включен но php-fpm все равно генерит кучу и не делает reuse...

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

судя по всему, все-таки я был неправ, и readinessProbe выполняется постоянно, только если liveness проверяет, не закрашился ли под (и надо ли его пересоздать), то readiness проверяет, в рабочем ли режиме приложение (и надо ли слать на него трафик)

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

судя по всему, все-таки я был неправ, и readinessProbe выполняется постоянно, только если liveness проверяет, не закрашился ли под (и надо ли его пересоздать), то readiness проверяет, в рабочем ли режиме приложение (и надо ли слать на него трафик)

Именно)

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

я имею ввиду когда php-fpm делает новый curl, он игнорит Connection: Keep-alive и открвает новое соедининие... попробую щас apache+mod_php...

а, ой. я не знаю вот, он сможет такое вообще

судя по всему, все-таки я был неправ, и readinessProbe выполняется постоянно, только если liveness проверяет, не закрашился ли под (и надо ли его пересоздать), то readiness проверяет, в рабочем ли режиме приложение (и надо ли слать на него трафик)

да выполняется постоянно, просто проверил опытным путем - https://pastebin.com/vPLY56JQ

я имею ввиду когда php-fpm делает новый curl, он игнорит Connection: Keep-alive и открвает новое соедининие... попробую щас apache+mod_php...

никакой разницы не будет

никакой разницы не будет

так а шо делать?

запросы можно не только курлом делать, как минимум там еще всякие stream_*-штуки есть

https://stackoverflow.com/a/982556/2908793 судя по всему, надо просто осторожней с ним обращаться, и он будет переиспользовать коннекты

нашел таки способ запускать чтото асинхронно с самим контейнером - postStart хендлер https://kubernetes.io/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/

но зачем оно сделано так?

но зачем оно сделано так?

Я думаю, чтоб сварм дальше не пилить

Ноды менеджется свормом, поды - кубером

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

а нафига ноды свормом менеджить?

зачем такой гомункул нужен?

мне больеш думается, что сварм похоронят

swarm хорошо когда у тебя одна нода

или вообще, они пилят cri-containerd и тут интеграция с кубером, может в опенсторсе только и останется что контейнерд, ранс, либнетвокр

Пока они уверяют, что сворм рано хоронить

Дык столько ресурсов спалили

конечно рано

запросы можно не только курлом делать, как минимум там еще всякие stream_*-штуки есть

А stream transport таки помог... Но еще остались TIME_WAIT от nginx ingress контролера родного... https://github.com/kubernetes/ingress-nginx/issues/986 из-за мапинга отсутсвующего Connection: хедера в Connection: close. Нужно поставить тот что от nginxinc, там все гуд судя по template: https://github.com/nginxinc/kubernetes-ingress/blob/master/nginx-controller/nginx/templates/nginx.ingress.tmpl#L62

nginx-ingress тоже на keepalive натсроить можно через конфигмап и аннотации

upstream-keepalive-connections у него есть опция

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

спасибо, щас гляну

А stream transport таки помог... Но еще остались TIME_WAIT от nginx ingress контролера родного... https://github.com/kubernetes/ingress-nginx/issues/986 из-за мапинга отсутсвующего Connection: хедера в Connection: close. Нужно поставить тот что от nginxinc, там все гуд судя по template: https://github.com/nginxinc/kubernetes-ingress/blob/master/nginx-controller/nginx/templates/nginx.ingress.tmpl#L62

https://github.com/kubernetes/ingress-nginx/blob/master/docs/user-guide/configmap.md тут есть описание всего, немного кашей конечно upstream-keepalive-connections по умолчанию 0

https://github.com/kubernetes/ingress-nginx/blob/master/docs/user-guide/configmap.md тут есть описание всего, немного кашей конечно upstream-keepalive-connections по умолчанию 0

в upstream модуль оно keepalive добавило, но все равно приходит Connection: close а тут https://www.nginx.com/blog/tuning-nginx/ сказано что бы Connection был все же пустой: To enable keepalive connections to upstream servers you must also include the following directives in the configuration: proxy_http_version 1.1; proxy_set_header Connection "";

так что нужно таки пробовать от nginxinc

Я помню что проверял конфиг и все было норм, может ещё какую опцию нужно

в upstream модуль оно keepalive добавило, но все равно приходит Connection: close а тут https://www.nginx.com/blog/tuning-nginx/ сказано что бы Connection был все же пустой: To enable keepalive connections to upstream servers you must also include the following directives in the configuration: proxy_http_version 1.1; proxy_set_header Connection "";

https://github.com/kubernetes/ingress-nginx/blob/master/rootfs/etc/nginx/template/nginx.tmpl#L147 https://github.com/kubernetes/ingress-nginx/blob/master/rootfs/etc/nginx/template/nginx.tmpl#L753 {{/* Whenever nginx proxies a request without a "Connection" header, the "Connection" header is set to "close" */}} {{/* when making the target request. This means that you cannot simply use */}} {{/* "proxy_set_header Connection $http_connection" for WebSocket support because in this case, the */}} {{/* "Connection" header would be set to "" whenever the original request did not have a "Connection" header, */}} {{/* which would mean no "Connection" header would be in the target request. Since this would deviate from */}} {{/* normal nginx behavior we have to use this approach. */}} # Retain the default nginx handling of requests without a "Connection" header map $http_upgrade $connection_upgrade { default upgrade; '' close; } .... proxy_set_header Connection $connection_upgrade; тоесть если заголовка в запросе не было, то Connection: close прилетит к вашему сервису внутри.

по поводу kubeadm, кто нить разбирался как после установки кластера сделать HA мастер? вижу что изменения в манифесты вносить нужно чтобы etcd кластеризовать и адреса etcd указать в остальных компонентах. что еще?

Почти на дефолтных настройках kubespray поднял кластер, с helm установил nginx-ingress, получил что контроллер не подымается из-за rbac или другой авторизации. Какие будут мнения?

It seems the cluster it is running with Authorization enabled (like RBAC) and there is no permissions for the ingress controller.

я так поднимаю при включенном RBAC: $ helm install —namespace=kube-system —name lb stable/nginx-ingress —set controller.hostNetwork=true,controller.kind=DaemonSet

по поводу kubeadm, кто нить разбирался как после установки кластера сделать HA мастер? вижу что изменения в манифесты вносить нужно чтобы etcd кластеризовать и адреса etcd указать в остальных компонентах. что еще?

вроде все... там же есть статья по HA

https://github.com/kubernetes/ingress-nginx/blob/master/rootfs/etc/nginx/template/nginx.tmpl#L147 https://github.com/kubernetes/ingress-nginx/blob/master/rootfs/etc/nginx/template/nginx.tmpl#L753 {{/* Whenever nginx proxies a request without a "Connection" header, the "Connection" header is set to "close" */}} {{/* when making the target request. This means that you cannot simply use */}} {{/* "proxy_set_header Connection $http_connection" for WebSocket support because in this case, the */}} {{/* "Connection" header would be set to "" whenever the original request did not have a "Connection" header, */}} {{/* which would mean no "Connection" header would be in the target request. Since this would deviate from */}} {{/* normal nginx behavior we have to use this approach. */}} # Retain the default nginx handling of requests without a "Connection" header map $http_upgrade $connection_upgrade { default upgrade; '' close; } .... proxy_set_header Connection $connection_upgrade; тоесть если заголовка в запросе не было, то Connection: close прилетит к вашему сервису внутри.

Есть Upgrade хедера нет: то Connection: close.

Есть Upgrade хедера нет: то Connection: close.

еще кстати такое есть: https://github.com/kubernetes/ingress-nginx/blob/master/rootfs/etc/nginx/template/nginx.tmpl#L770 # Custom headers to proxied server {{ range $k, $v := $all.ProxySetHeaders }} proxy_set_header {{ $k }} "{{ $v }}"; {{ end }} https://github.com/kubernetes/ingress-nginx/blob/9fc28366c289eef1c63bc52264b2aaec0be40f04/docs/user-guide/configmap.md#proxy-set-headers

еще кстати такое есть: https://github.com/kubernetes/ingress-nginx/blob/master/rootfs/etc/nginx/template/nginx.tmpl#L770 # Custom headers to proxied server {{ range $k, $v := $all.ProxySetHeaders }} proxy_set_header {{ $k }} "{{ $v }}"; {{ end }} https://github.com/kubernetes/ingress-nginx/blob/9fc28366c289eef1c63bc52264b2aaec0be40f04/docs/user-guide/configmap.md#proxy-set-headers

тогда не будет работать websocketы:)

чет вроде речь про rest api была =)))

ну там и то и это.. забыл сказать

я так поднимаю при включенном RBAC: $ helm install —namespace=kube-system —name lb stable/nginx-ingress —set controller.hostNetwork=true,controller.kind=DaemonSet

kube-system eponymous-mandrill-nginx-ingress-controller-2sbwl 0/1 CrashLoopBackOff 5 4m

kube-system eponymous-mandrill-nginx-ingress-controller-2sbwl 0/1 CrashLoopBackOff 5 4m

есть положительный опыт с kubespray+helm+nginx-ingress?

kube-system eponymous-mandrill-nginx-ingress-controller-2sbwl 0/1 CrashLoopBackOff 5 4m

а в логе что??

до лога не добирается

kubectl logs eponymous-mandrill-nginx-ingress-controller-2sbwl Error from server (NotFound): pods "eponymous-mandrill-nginx-ingress-controller-2sbwl" not found

это у меня что-то глючит видать

describe?

да то же самое. что-то сломалось

поставил с 0 кубер через kubespray. helm install stable/nginx-ingress —namespace kube-system —set controller.hostNetwork=true,controller.kind=DaemonSet kubectl get pods —all-namespaces NAMESPACE NAME READY STATUS RESTARTS AGE kube-system boiling-saola-nginx-ingress-controller-wrwvb 0/1 CrashLoopBackOff 4 2m kubectl logs boiling-saola-nginx-ingress-controller-wrwvb Error from server (NotFound): pods "boiling-saola-nginx-ingress-controller-wrwvb" not found

-n kube-system

поставил с 0 кубер через kubespray. helm install stable/nginx-ingress —namespace kube-system —set controller.hostNetwork=true,controller.kind=DaemonSet kubectl get pods —all-namespaces NAMESPACE NAME READY STATUS RESTARTS AGE kube-system boiling-saola-nginx-ingress-controller-wrwvb 0/1 CrashLoopBackOff 4 2m kubectl logs boiling-saola-nginx-ingress-controller-wrwvb Error from server (NotFound): pods "boiling-saola-nginx-ingress-controller-wrwvb" not found

pods "boiling-saola-nginx-ingress-controller-wrwvb" not found в нэймспейсе default

pods "boiling-saola-nginx-ingress-controller-wrwvb" not found в нэймспейсе default

спс! It seems the cluster it is running with Authorization enabled (like RBAC) and there is no permissions for the ingress controller. Please check the configuration

helm update давно делали?

Обязательно использовать helm? Я просто кубеспреем ставлю. Сегодня на тестовом стенде раз 15 с нуля поставил. Пробовал всякое. Нормально ставится, в том числе, версия 1.8.

ну и плюс https://github.com/kubernetes/charts/blob/master/stable/nginx-ingress/values.yaml#L202

--set rbac.create True

Обязательно использовать helm? Я просто кубеспреем ставлю. Сегодня на тестовом стенде раз 15 с нуля поставил. Пробовал всякое. Нормально ставится, в том числе, версия 1.8.

не обязательно. я ищу самый простой вариант

По-моему, просто kubespray и есть самый простой вариант. kubespray deploy - и поехали.

в шаблоны если зайти в которых rbac роли создаются и тд: {{- if .Values.rbac.create -}} а по умолчанию он выключен

я думал helm самое популярное решение)

Смотря для чего

На сколько я понимаю, это типа пакетного менеджера.

ага

он Типо умеет поднимать несколько подов сразу

и сервисы к ним

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

По-моему, просто kubespray и есть самый простой вариант. kubespray deploy - и поехали.

а есть вариант подня например owncloud в одно касание без helm?

нету

а есть вариант подня например owncloud в одно касание без helm?

Ну, если есть рабочий кластер, то я бы просто написал манифесты: деплой, сервис, ингресс.

в шаблоны если зайти в которых rbac роли создаются и тд: {{- if .Values.rbac.create -}} а по умолчанию он выключен

helm install stable/nginx-ingress —namespace kube-system —set controller.hostNetwork=true,controller.kind=DaemonSet —set rbac.create=true Error: release busted-otter failed: the API version in the data (rbac.authorization.k8s.io/v1beta1) does not match the expected API version (rbac.authorization.k8s.io/v1)

ну разница api

в пакету устаревшая)