через шаблонизацию? а ткните в доку(

Ребят, помогите, что то забуксовал совсем я. есть кластер кубера, написал первую таску. Есть несколько вопросов 1) Как вставить таймаут между стартами контейнеров, и строго ли по списку кубер контейнеры стартует, если не строго то как сделать строго, ни как не могу даже упоминания об этом в доке найти. 2) Не понятность: мне нужно крутануть контейнер который инициализирует предыдущий запущенный контейнер(аля батч). Можно ли такое вообще сделать ? 3) DNS и CONFIGMAP- не понятно как реализован поиск контейнеров, везда указал name контейнеров (старт подов описан в деплойменте), но получаю в ответ host not found. Вообще кейс поиска сервисов как реализован, очень не понятно, одни описывают через сервис и поиск как публичных служб, другие описывают прямо IP адреса служб (как я могу узнать их если они в динамике). Короче вообще не понятки.

1) приложения не должны расчитывать на какой то порядок. если тебе нужен порядок старта - пилишь entrypoint который дожидается каких то события и потом стартует апп 2) обычно initcontainer преднастраивает. но вообще есть такая вещь как postStart hook, можно через него выполнить что то после старта https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/

1) приложения не должны расчитывать на какой то порядок. если тебе нужен порядок старта - пилишь entrypoint который дожидается каких то события и потом стартует апп 2) обычно initcontainer преднастраивает. но вообще есть такая вещь как postStart hook, можно через него выполнить что то после старта https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/

как я запилю entrypoint, если стартуют разные контейнеры

Ребят, помогите, что то забуксовал совсем я. есть кластер кубера, написал первую таску. Есть несколько вопросов 1) Как вставить таймаут между стартами контейнеров, и строго ли по списку кубер контейнеры стартует, если не строго то как сделать строго, ни как не могу даже упоминания об этом в доке найти. 2) Не понятность: мне нужно крутануть контейнер который инициализирует предыдущий запущенный контейнер(аля батч). Можно ли такое вообще сделать ? 3) DNS и CONFIGMAP- не понятно как реализован поиск контейнеров, везда указал name контейнеров (старт подов описан в деплойменте), но получаю в ответ host not found. Вообще кейс поиска сервисов как реализован, очень не понятно, одни описывают через сервис и поиск как публичных служб, другие описывают прямо IP адреса служб (как я могу узнать их если они в динамике). Короче вообще не понятки.

3) самый простой способ дискаверить сервисы в к8с - через днс. ищешь по именам сервисов. service может быть headless - тоесть будет резолвится во все адреса подов. вариантов много на самом деле.

как я запилю entrypoint, если стартуют разные контейнеры

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

1) приложения не должны расчитывать на какой то порядок. если тебе нужен порядок старта - пилишь entrypoint который дожидается каких то события и потом стартует апп 2) обычно initcontainer преднастраивает. но вообще есть такая вещь как postStart hook, можно через него выполнить что то после старта https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/

блин опять хуки. А политик старта ни каких нет ? Они же пильнули для statefull вроде как, я думал и для stateless есть.

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

да, я пока стартую их все как stateless, просто хочу разобратся какие есть трюки, и как их крутить если что то понадобиться не обычное.

через шаблонизацию? а ткните в доку(

пока не шаблонизируешь ничего?

пока не шаблонизируешь ничего?

Да даже не могу найти ссылки на какие переменные есть для шаблонизатора, и если они есть (особенно ссылки на секреты и порты и хосты) Я буду очень рад )

я просто термин такой не знаю) если про то что написать yaml - то конечно я все так делаю просто у меня же реплика сет и там foo-1.bar foo-2.bar и тд - не хочется все это писать руками

блин опять хуки. А политик старта ни каких нет ? Они же пильнули для statefull вроде как, я думал и для stateless есть.

такой нет функциональности. если ты в докере пробовал запускать свои аппы, то наверняка уже видел всякие wait-for-it.sh для того чтобы запускать апп после того, как база будет доступна

такой нет функциональности. если ты в докере пробовал запускать свои аппы, то наверняка уже видел всякие wait-for-it.sh для того чтобы запускать апп после того, как база будет доступна

Это понятно, там немного для другого логика батчей - там лдап и версии. Потому при обновлении приложеньки хочется батчем докатывать версию

А батчу скармливать конфигом чего докатывать.

Получится отвязатся от версий конфигов для разных версий в гите, жестко это вымораживает

Да даже не могу найти ссылки на какие переменные есть для шаблонизатора, и если они есть (особенно ссылки на секреты и порты и хосты) Я буду очень рад )

вот вот господин меня понял)

Ладно с инициализацией пока на потом. Мне бы помочь с шаблонизатором для Config MAP. И DNS, указал для приложеньки в качестве хоста то что указал в name - получил отбой что хост не найден. Я описал старт через Deployment. В доке кубера указано что бы пользоваться hostname нужно испльзовать POD. Тогда как деплой то описывать ) https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/ . Однако если я это пробую использовать в spec Deployment - получаю ошибку синтаксиса

Может проще - как вы сами в своих конфигах контейнеры находите ? Генерируете через шаблонизатор (списки IP адресов), DNS (как там с TTL тогда дела обстоят), если DNS то получается порты уже в динамике нельзя использовать, то есть 1 контейнер на 1 ноду, не очень это хорошо

Как правильно публиковать свое приложение? Баре метал. Ингресс nginx от k8s. Необходимо опубликовать на 80 порт. В сервисе приложения выбирать ноде порт, а этот нод порт закреплять за бекендом ингреса?

Если ингресс уже есть - через него

Ну то есть, определить сервис без всяких NodePort, на который и натравлять ингресс

А в чём, собственно, проблема?

Ну то есть, определить сервис без всяких NodePort, на который и натравлять ингресс

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

Может проще - как вы сами в своих конфигах контейнеры находите ? Генерируете через шаблонизатор (списки IP адресов), DNS (как там с TTL тогда дела обстоят), если DNS то получается порты уже в динамике нельзя использовать, то есть 1 контейнер на 1 ноду, не очень это хорошо

ну сервис раздает днс имена - не понял вопроса

А в чём, собственно, проблема?

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

bare metal - только NodePort, либо как я вчера - через hostNetwork: true

ну сервис раздает днс имена - не понял вопроса

Вопрос следующий, есть контейнер, для него есть в конфиг, в конфиге мне нужно указать ему для общения другие контейнеры, публиковать мне эти контейнеры не надо, пускай работают через внутреннюю сеть. Вопрос как это сделать ? Забыл написать - конфиг отдаю через Config Map

bare metal - только NodePort, либо как я вчера - через hostNetwork: true

Тоесть на 80 порт не могу опубликовать?

В случае NodePort понадобится секция externalIPs: в описании сервиса ingress-nginx

В ней - список ip-адресов узлов, где надо слушать 80,443

Вопрос следующий, есть контейнер, для него есть в конфиг, в конфиге мне нужно указать ему для общения другие контейнеры, публиковать мне эти контейнеры не надо, пускай работают через внутреннюю сеть. Вопрос как это сделать ? Забыл написать - конфиг отдаю через Config Map

да собственно в этом и есть вопрос вот например для настройки zk ручками прописывают https://github.com/Yolean/kubernetes-kafka/blob/master/zookeeper/10zookeeper-config.yml#L24

Тоесть на 80 порт не могу опубликовать?

apiVersion: v1 kind: Service metadata: name: ingress-nginx namespace: ingress-nginx spec: type: NodePort ports: - name: http port: 80 targetPort: 80 protocol: TCP - name: https port: 443 targetPort: 443 protocol: TCP selector: app: ingress-nginx externalIPs: - x.x.x.88 - x.x.x.30

С дефолтным mandatory.yaml вполне работает

pzoo-0.pzoo - это имя как получилось. Что нужно указать для deployment что бы получилось имя. Ну и это костыльно, очень костыльно. Нет возможности как более элегантно искать другие сервисы, что бы не было привзяки к нодам и портам. Или если кубер создает отдельный IP на каждый контейнер - то в принципер норм, если порт всегда будет одинаковым

Но есть грабля - в логах отражается ип узла из externalIPs, куда пришел запрос

Гм... Где это имя получилось (где увидел)?

server.1=pzoo-0.pzoo:2888:3888:participant Из гита ссылка же

pzoo-0.pzoo - вот этот кусок из чего складывается. Ну например pzoo-0 - это metadata:name, а pzoo - это container:name. Я пример привел, не знаю как оно в реалн

я как то теряю диалог))) вот это генерит pzoo-0.pzoo:2888:3888:participant https://github.com/Yolean/kubernetes-kafka/blob/master/zookeeper/20pzoo-service.yml

я как то теряю диалог))) вот это генерит pzoo-0.pzoo:2888:3888:participant https://github.com/Yolean/kubernetes-kafka/blob/master/zookeeper/20pzoo-service.yml

Блин, у него в конфигах нету pzoo-0, нету 0, откуда взялся 0 вот о чем я спрашиваю, это кубер прибавляет ? В service он описал pzoo, без тире и нулей. На выхлопе получилось pzoo-0.pzoo. Вот из чего состоит имя, как оно генерируется (какие переменные)

а)) ну это стейтфул сет с репликацией https://github.com/Yolean/kubernetes-kafka/blob/master/zookeeper/50pzoo.yml#L12 кубер сам прибавляет номера для каждой реплики вот тут это написано https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/

а)) ну это стейтфул сет с репликацией https://github.com/Yolean/kubernetes-kafka/blob/master/zookeeper/50pzoo.yml#L12 кубер сам прибавляет номера для каждой реплики вот тут это написано https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/

спасибо, ситуация начинает прояснятся. Блин хочу деплоймент с динамической нагрузкой (вырубать контейнеры если нагрузки нет), потому нужно что бы конфиг лежащий в config map генерировался по определенным параметрам. Есть ли такая возможность ?

Может я ошибочно пытаюсь логику работы nomad натянуть на кубера? У номад есть шаблонизаторы и поиск служб, просто поиск. Видимо у кубера свои подходы, просто не понятно какие, в документации создаются службы в вакууме, общающиеся только с внешним миром, а как организовать взаимосвязанную работу примеров особо нет.

никто в профильных чатах не отвечает (

А мануал почитать?

Может я ошибочно пытаюсь логику работы nomad натянуть на кубера? У номад есть шаблонизаторы и поиск служб, просто поиск. Видимо у кубера свои подходы, просто не понятно какие, в документации создаются службы в вакууме, общающиеся только с внешним миром, а как организовать взаимосвязанную работу примеров особо нет.

Нормальные там примеры. Если без разницы, к какому поду ходить - просто сделать сервис, который указывает на нужный деплоймент и ходить в него. Остальное (реплики и т.п.) разруливать через деплоймент.

Нормальные там примеры. Если без разницы, к какому поду ходить - просто сделать сервис, который указывает на нужный деплоймент и ходить в него. Остальное (реплики и т.п.) разруливать через деплоймент.

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

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

10 лет назад за это на форумах обычно унижали

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

Ну так надо эти доки таки читать и, желательно, пробовать. Пробовать частично можно в онлайне (помнится, где-то в туториале было)

вот пример из доки. pod-ip-address.my-namespace.pod.cluster.local - сущность pod, я описал deployment, внутри deploument будут поды, но будут ли они видны так же. Дело в том что metadata поле у меня одно на два пода.

Сделай сервис и ходи через днс на него. Это проще всего будет.

Публиковать сервис наружу необязательно

Сервис менее выгоден с точки зрения маршрутизации. Там стык будет через выход за пределы vxlan сети. что не есть хорошо, зачем это делать если они напрямую могут друг с другом взаимодействовать. Другое дело что если за сервисом несколько подов, то через балансер я найду 1. Вот блин и ответ

спасибо ))

Теперь дошло, пока писал дошло

Там тех потерь - за пределами точности измерения в нормальных условиях.

Там тех потерь - за пределами точности измерения в нормальных условиях.

ды сыкотно с этими контраками. ну да ладно

Ну так если нужен доступ снаружи (у меня на работе - это единственная возможность получить заметную нагрузку на conntrack) - в любом случае надо ставить внешний лоадбалансер, в котором заодно использовать всякие mod-security, limit-rate и т.п.

Ну так если нужен доступ снаружи (у меня на работе - это единственная возможность получить заметную нагрузку на conntrack) - в любом случае надо ставить внешний лоадбалансер, в котором заодно использовать всякие mod-security, limit-rate и т.п.

это да, тут тачки разнородные очень, от очень слабых, до нормальных. А куда улетит контейнер не известно и это правильно, но в целом внутренняя кухня должна быть за внешим балансером. А то и в каскаде (haproxy -> nginx -> nginx (per service)) типа того

Ещё вопрос, а можно секрет засунуть перменной в конфигмап ?

Кто на ком стоял?

По-моему, configMap создаётся не из секретов.

Если надо в одном месте хранить и конфги и секреты - делайте projected volume

По-моему, configMap создаётся не из секретов.

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

Проще таки для прода другой секрет подцепить.

Проще таки для прода другой секрет подцепить.

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

юзай темплейт, куда при старте из энва клади

отцы, подскажите. вот есть свежий 1.11 кластер. сертификаты конечно на 1 год сгенерировались kubeadm-ом. вроде бы kubelet настроен на авторотейт при "скором протухании, <180d" сертификата. Но вот как дела обстоят с control-plane сертами? они тоже умеют автообновляться или надо что-то делать руками для этого? туплю

юзай темплейт, куда при старте из энва клади

Блин, ну такое… Доп логика на старт… костыльненько

щито поделать десу

Если надо в одном месте хранить и конфги и секреты - делайте projected volume

Да вот это прям мое походу, спасибо

apiVersion: v1 kind: Service metadata: name: ingress-nginx namespace: ingress-nginx spec: type: NodePort ports: - name: http port: 80 targetPort: 80 protocol: TCP - name: https port: 443 targetPort: 443 protocol: TCP selector: app: ingress-nginx externalIPs: - x.x.x.88 - x.x.x.30

Спасибо, понял, помогло. Единственное, как по правильному работаь с экстернал айпи. Повесить вирт айпи чтоб между мастерами гулял и вписать его в экстернал айпи?

externalIps тут - адреса, привязанные к внешним интерфейсам узлов, где будет открыт 80-й порт

Мне проще было сделать запись в днс вида *.kubernetes.domain.tld и потом прописывать нужное имя в ingress для соответсвующего сервиса

Это для доступа снаружи. Изнутри всё работает по короткому имени

Это для доступа снаружи. Изнутри всё работает по короткому имени

Понял, спасибо. Это вообще тру путь для публикации во вне на баре метал??)

А хз, мне просто было так проще перетаскивать сервисы из docker swarm

добрый день, прошу помощи и прояснения (просветления даже) с prometheus operator, не получается до конца осознать концепцию, а если точнее, то не ясно как влиять на параметры конфигурации прометея, которые задаются не динамически.

добрый день, прошу помощи и прояснения (просветления даже) с prometheus operator, не получается до конца осознать концепцию, а если точнее, то не ясно как влиять на параметры конфигурации прометея, которые задаются не динамически.

плюсую, тоже бы узнать:)

добрый день, прошу помощи и прояснения (просветления даже) с prometheus operator, не получается до конца осознать концепцию, а если точнее, то не ясно как влиять на параметры конфигурации прометея, которые задаются не динамически.

https://github.com/coreos/prometheus-operator/blob/master/Documentation/custom-configuration.md https://github.com/coreos/prometheus-operator/blob/master/Documentation/api.md#prometheusrule динамически создаешь PrometheusRule, который подхватывается оператором и рестартует прометеус

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

Подскажите пожалуйста создал через cert-manager LE серт, пытаюсь его прикрутить через ingress. Но мне отдается 503 ошибка apiVersion: extensions/v1beta1 kind: Ingress metadata: annotations: ingress.kubernetes.io/ssl-passthrough: "true" nginx.ingress.kubernetes.io/secure-backends: "true" kubernetes.io/tls-acme: "true" certmanager.k8s.io/issuer: letsencrypt-production name: devsite selfLink: /apis/extensions/v1beta1/namespaces/default/ingresses/devsite spec: rules: - host: my.domain.com http: paths: - backend: serviceName: my-frontend servicePort: 8181 path: / - host: my.domain.com http: paths: - backend: serviceName: my-backend servicePort: 3000 path: /api tls: - hosts: - my.domain.com secretName: my-domain-com-tls status: loadBalancer: {}