а в environments, вообще отдельным файлом globals.libsonnet

сложно как-то сильно. как деплоить то?

блин, я был неправ. ему обязательно надо указывать --env=default, даже если это default

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

Red Hat introduces first Kubernetes-native IDE https://www.zdnet.com/article/red-hat-introduces-first-kubernetes-native-ide/ Red Hat CodeReady Workspaces https://developers.redhat.com/products/codeready-workspaces/overview/

Red Hat introduces first Kubernetes-native IDE https://www.zdnet.com/article/red-hat-introduces-first-kubernetes-native-ide/ Red Hat CodeReady Workspaces https://developers.redhat.com/products/codeready-workspaces/overview/

подписан на @count0ru а на этот канал не подписан, нихарашо

подписан на @count0ru а на этот канал не подписан, нихарашо

так оттуда и взято (форвард был до митапа)

https://developers.redhat.com/products/codeready-workspaces/overview/

https://github.com/kubernetes-incubator/external-dns всем привет, а вот эту штуку кто нибудь использовал?

Ребят, если я создал сервайс и селектор по лейблу, и а этот лейбл есть в нескольких деплойментсах. Должен ли он так работать или нет ?

Сервис смотрит в поды, а не в деплойменты

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

сервайс

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

ну ты сделай get pods с указанными лейблами и проверь, что они реально есть

может они у тебя не запущены или фейлят хелсчеки

может они у тебя не запущены или фейлят хелсчеки

Кстати а не поделитесь способом траблшутить хелсчеки? Грубо говоря нужно курлить / трассировать ip-pod/урла до хелса с сервера куба не так ли?

хелсчеки локально для пода дёргаются

https://github.com/kubernetes-incubator/external-dns всем привет, а вот эту штуку кто нибудь использовал?

Да, под роут53 заточил

хелсчеки локально для пода дёргаются

Внутри пода опрашивается локалхост (в мане ip) да?

примерно так

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

по-моему в документации хорошо было описано

Однако поды были помечены как не здоровые

сделай describe и посмотри

по-моему в документации хорошо было описано

Там вроде только описано что юзается IP и часть про http get очень слабо документирована как по мне

сделай describe и посмотри

Естественно там тайм-аут реквеств

ну ты сделай get pods с указанными лейблами и проверь, что они реально есть

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

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

Селектор криво написан

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

потому что ты его в template не указал

Естественно там тайм-аут реквеств

ну значит таймаут

сделай get pod <pod-name> -o yaml и посмотри

чо гадать-то

ну значит таймаут

Ну вот внутри пода все очень резво однако пришлось повысить таймаутсекондс до 5. Из хелс все лишнего выкинули

сделай get pod <pod-name> -o yaml и посмотри

Ну конфигурации деплоймента я и так знаю я же их правил:) если это ко мне

потому что ты его в template не указал

а как его в темплейт добавить ?)

Тут вопрос именно в том что разрабы что то такое сделали с апоикашкой что загубили хелс, хотя внутри пода хелсчек вполне в пределах дефоллтной секунды отдает статус 200

а как его в темплейт добавить ?)

берёшь короче, открываешь твой текстовый редактор (я предпочитаю GNU/Emacs), вписываешь туда нужные параметры и потом делаешь kubectl apply -f

дык он есть

в манифесте

этот лейбл

Тут вопрос именно в том что разрабы что то такое сделали с апоикашкой что загубили хелс, хотя внутри пода хелсчек вполне в пределах дефоллтной секунды отдает статус 200

ну я возможно наврал и дёргается ip пода, а не локалхост внутри этого пода

этот лейбл

в метаданных деплоймента или в темплейте пода?

в метданные деплоймента

воооот

apiVersion: apps/v1 kind: Deployment metadata: labels: k8s-app: test app: hazelcast

это метаданные деплоймента

не подов которые этот деплоймент создаст

а еще тогда тупой вопрос, почему данный лейбл передает "k8s-app: test" а этот не передает "app: hazelcast"

ну я возможно наврал и дёргается ip пода, а не локалхост внутри этого пода

Вот меня это тоже смущает. Дёргается ип внутри пода или все таки ип снаружи пода. Вот это для меня непонятно из мануала

а еще тогда тупой вопрос, почему данный лейбл передает "k8s-app: test" а этот не передает "app: hazelcast"

куда?

с деплоймента в под

Да, под роут53 заточил

а как оно себя ведет в случае split-brain? ну то есть, будет пушить в DNS все ip с каждой стороны сплит-брейна?

Вот меня это тоже смущает. Дёргается ип внутри пода или все таки ип снаружи пода. Вот это для меня непонятно из мануала

HTTPGetAction: Performs an HTTP Get request against the Container’s IP address on a specified port and path. The diagnostic is considered successful if the response has a status code greater than or equal to 200 and less than 400.

For an HTTP probe, the kubelet sends an HTTP request to the specified path and port to perform the check. The kubelet sends the probe to the pod’s IP address, unless the address is overridden by the optional host field in httpGet

вроде чётко описано

(две разные странички про описание хелсчеков и около них)

а как оно себя ведет в случае split-brain? ну то есть, будет пушить в DNS все ip с каждой стороны сплит-брейна?

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

куда?

Спасибо тебе большое, я разобрался и понял где я натупил

For an HTTP probe, the kubelet sends an HTTP request to the specified path and port to perform the check. The kubelet sends the probe to the pod’s IP address, unless the address is overridden by the optional host field in httpGet

Видимо мой уровень английского мне не даёт понять. Где конкретно запускается гет запрос: внутри пода или снаружи:)

Описали то они четко но не понятно где...

Видимо мой уровень английского мне не даёт понять. Где конкретно запускается гет запрос: внутри пода или снаружи:)

кубелет его посылает на ip-адрес пода, если специально не указано другое

> The kubelet sends the probe to the pod’s IP address, unless the address is overridden by the optional host field in httpGet

кубелет это демон на нодах

кубелет его посылает на ip-адрес пода, если специально не указано другое

Внутри пода тоже есть IP. Кубелет умеет посылать только запрос снаружи внутрь не умеет? Я просто пытаюсь понять сорян за тупежку

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

кубелет живёт не в контейнере обычно

что такое "ip внутри пода"?

Ок спасибо. Значит как я и предпологал надо траблшутить посылая запрос с ноды на под

что такое "ip внутри пода"?

Ну он же прописывает свой ип и полученный хостнейм в etc hosts

Значит может и внутри по айпшнику своему ходить считай как локалхост:)

зачем?

Ну вот теперь понятно что незачем:)

Спасибо буду копать запросами с ноды

это было бы очень неявно

ты можешь делать хелсчек на какой-то внешний сервис, который знает о состоянии твоего демона

если очень хочешь

это было бы очень неявно

Просто как по мне так было бы более изолированно

ты хочешь изоляцию для хелсчеков?

То есть реально проверяется чё там в поде творится а не насколько быстро моя нода опрашивает под

или мне показалось?