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

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

я просто термин такой не знаю) если про то что написать 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: {}

Как поправить, а то весь мозг себе взорвал

Глянь логи nginx

kubectl get pod —namespace kube-system | grep nginx-ingress kubectl logs nginx-ingress-controller-g29gs —namespace kube-system

Я ничего такого не указываю 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 зачем?

Там отдельные ещё есть ресурсы Issuer и Certificate. Последний делает my-domain-com-tls

Народ, а такой вопрос, когда монтирую в Pod configmap за что отвечает параметр optional?

Народ, а такой вопрос, когда монтирую в Pod configmap за что отвечает параметр optional?

https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.10/#configmapvolumesource-v1-core

специально открыл апи референс и заглянул в описание. референс довольно неплох, кстати

Друзья, а мы продолжаем искать докладчика на следующий Kubernetes-митап, который состоится уже совсем скоро на площадке Mail.Ru Group! Есть чем поделиться или рассказать интересно, готовы исповедаться или прочитать проповедь? Будем рады! Сделаем сообщество веселей и опытней вместе. Напишите на events@axept.co или в ЛС напишите. ?

https://www.meetup.com/Moscow-Kubernetes-Meetup/events/253451195/ Когда: четверг, 9 августа 2018, 19:30 - 22:15 Где: Москва, Ленинградский проспект 39, стр. 79 (офис Mail.Ru Group) Друзья, жаркое лето в Москве ещё больше подогревает интерес к Kubernetes со стороны русскоговорящего сообщества. Прошёл всего месяц с момента предыдущего митапа, наш Telegram-чат-канал про Kubernetes ( https://t.me/kubernetes_ru ) уже вырос почти до 2000 человек, а вместе с ним продолжают расширяться и области применения Kubernetes, как и масштаб проблем, которые успешно решаются с его помощью. Облака спускаются на землю в следующий четверг, ведь мы снова встречаемся и на этот раз мы будем делать это вместе с Mail.Ru Group! ПРОГРАММА: 19:30 - 19:50 Socializing, встречаемся, общаемся, shake it! 19:50 - 20:05 Welcome & digest (Денис Измайлов, Axept) 20:05 - 20:45 Подводные камни при production-эксплуатации Kubernetes (Дмитрий Лазаренко, Mail.Ru Cloud Solutions, менеджер продукта) Изначально Kubernetes был спроектирован для работы stateless-приложений. Однако сейчас все больше и больше компаний пытаются размещать в нем stateful-сервисы, требующие надежного хранения. Помогая клиентам Mail.Ru Cloud Kubernetes, мы обнаружили много неочевидных особенностей, прежде всего связанных с persistent-хранением данных и поведением Kubernetes при выходе из строя оборудования. Как Persistent Volumes работают в штатных и нештатных ситуациях? Например, если вы выключите ноду или она аварийно остановится (падение хоста, гипервизора или Kubelet)? Какие проблемы бывают при эксплуатации RWX PVС? Как правильно дружить с облачным балансировщиком нагрузки? Всё это Дмитрий раскроет в своем докладе для вас. Био: Дмитрий Лазаренко возглавляет PaaS-направление Mail.Ru Cloud Solutions, включая контейнерные решения на базе Kubernetes. До Mail.Ru Group в течение 6 лет отвечал за разработку и развитие контейнерной PaaS-платформы Jelastic. Более 10 лет занимается созданием высоконагруженных сервисов. 20:45 - 21:15 История разработки Production-ready сборки Kubernetes (Константин Феофантов, Exon Lab, CTO) Доклад основывается на истории разработки [предположительно] первого в России Docker-хостинга. Константин расскажет про опыт с Kubernetes и проблемы, с которыми он с командой столкнулся в ходе разработки и эксплуатации. В докладе обосновывается выбор компонентов и плагинов Kubernetes при создании собственного production-ready кластера, а также варианты развертывания Kubernetes и рекомендации по ним. Био: Константин программирует с 2012 года, писал на C, затем на C#. Потом начал изучать веб-разработку (Node.js, HTML5, SaSS) и вот уже в 2015 году перевел всё на Golang. В 2017 стал техническим директором, основал проект Containerum и основательно занялся изучением Kubernetes. 21:15 - 21:35 Кофе-брейк, чай-пати, горячие дискуссии 21:35 - 22:15 Turing Pi – кластерный компьютер на базе Kubernetes для граничных вычислений и интернета вещей (Константин Шмойлов-Александров, Jelastic, сооснователь) Рынок IoT бурно развивается, но в основном он наполнен крайне простыми устройствами с ограниченным диапазоном применения. Мы создали компактное кластерное устройство с Kubernetes и Docker на борту, воплощающее идею вычислительного узла IoT-сети нового типа. В нем сочетается множество разнотипных одноплатных компьютеров, соединенных сетью в рамках единой материнской платы. Этот кластер предназначен для граничных вычислений: в частности, для размещения приложений машинного обучения не в облаке, а локально – в месте, где необходимо собирать, хранить, анализировать данные и управлять окружающими устройствами. В докладе мы расскажем, что под капотом этого устройства и как контейнеры и Kubernetes могут эффективно работать не только на огромных серверах, но и на мини-устройствах.

Друзья, а мы продолжаем искать докладчика на следующий Kubernetes-митап, который состоится уже совсем скоро на площадке Mail.Ru Group! Есть чем поделиться или рассказать интересно, готовы исповедаться или прочитать проповедь? Будем рады! Сделаем сообщество веселей и опытней вместе. Напишите на events@axept.co или в ЛС напишите. ?

Био: Константин Шмойлов-Александров – сооснователь Jelastic, компании, производящей софт для автоматизации развертывания приложений на базе контейнерной виртуализации. Продуктом пользуется около 350 000 клиентов. Он продается по всему миру через 57+ компаний из хостинговой индустрии, включая несколько телекомов. 22:15 - 06:00 Afterparty УСЛОВИЯ УЧАСТИЯ: 1. Мероприятие бесплатное. 2. Регистрация обязательна. Зарегистрироваться можно по ссылке: https://corp.mail.ru/ru/press/events/496/ (торопитесь! регистрация закрывается 7 августа в 23:59 или раньше, если закончатся места) 3. ВНИМАНИЕ! В день мероприятия, пожалуйста, обязательно возьмите с собой паспорт или права. Они понадобятся вам при входе. ВОПРОСЫ? Появились вопросы или готовы выступить с докладом на следующем митапе? Пишите в Telegram: https://t.me/DenisIzmaylov Или на email: events@axept.co

Био: Константин Шмойлов-Александров – сооснователь Jelastic, компании, производящей софт для автоматизации развертывания приложений на базе контейнерной виртуализации. Продуктом пользуется около 350 000 клиентов. Он продается по всему миру через 57+ компаний из хостинговой индустрии, включая несколько телекомов. 22:15 - 06:00 Afterparty УСЛОВИЯ УЧАСТИЯ: 1. Мероприятие бесплатное. 2. Регистрация обязательна. Зарегистрироваться можно по ссылке: https://corp.mail.ru/ru/press/events/496/ (торопитесь! регистрация закрывается 7 августа в 23:59 или раньше, если закончатся места) 3. ВНИМАНИЕ! В день мероприятия, пожалуйста, обязательно возьмите с собой паспорт или права. Они понадобятся вам при входе. ВОПРОСЫ? Появились вопросы или готовы выступить с докладом на следующем митапе? Пишите в Telegram: https://t.me/DenisIzmaylov Или на email: events@axept.co

запись прошлого то получается уже не ждать?)

Будет тут - https://t.me/kubernetesMSK

Будет тут - https://t.me/kubernetesMSK

будет тут следующего или прошедшего?