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

Глянь логи 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

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

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

Да всё будет 🙂 У нас пока ещё нет человека, который помогал бы нам фотографии/видеозаписи обрабатывать/сортировать

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

Как бы все хорошо, но почему-то если confimap нету, то он всеравно перезатирает файлик

Но как появится, сразу наверстаем всё:)

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

https://kubernetes.io/docs/concepts/

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

https://www.youtube.com/watch?v=pdAXKkMc8ls

https://www.youtube.com/watch?v=pdAXKkMc8ls

не в курсе, записи будут ?

https://kubernetes.io/docs/concepts/

Ну вот как раз идея "что читать после для комплексного и всестороннего погружения")

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

Ну вот как раз идея "что читать после для комплексного и всестороннего погружения")

ну хрен знает)

Но как появится, сразу наверстаем всё:)

спасибо, все очень ждут:)

хуки helm на деплойменте сработают?

или только на джобе?

Как бы все хорошо, но почему-то если confimap нету, то он всеравно перезатирает файлик

тоесть поверх пустая директория монтируется? попробуй конкретные ключи исопльзовать и монтировать с subpath (ну я хз, варианты есть еще)

тоесть поверх пустая директория монтируется? попробуй конкретные ключи исопльзовать и монтировать с subpath (ну я хз, варианты есть еще)

Неее, я монтирую файлик, но такого ключа в configmap нету, он в итоге перезатирает файл на пусто...

Неее, я монтирую файлик, но такого ключа в configmap нету, он в итоге перезатирает файл на пусто...

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

+

Всем привет. На Gitlab CI наконец добрался до указания конкретного образа, вместо latest при делое и реализовал вот так, но может есть какие-то варианты получше? kubectl apply -f dev.yaml --record=true && kubectl patch -f dev.yaml -p '{"spec":{"template":{"spec":{"containers":[{"name":"nginx-app","image":"'$CONTAINER_IMAGE:$CI_COMMIT_SHA'"}]}}}}' --record=true Первый шаг обновляет в том числе переменные из env: ..., если они менялись и в самом dev.yaml указан image: registry.gitlab.onlinepay.com/onlinepay/nginx:latest, т.к. пока не представляю как пробросить внутрь yaml $CONTAINER_IMAGE:$CI_COMMIT_SHA, а далее уже делается patch, который непосредственно указывает на нужный образ $CONTAINER_IMAGE:$CI_COMMIT_SHA. И получается 2 deployment'а в kubectl rollout history. Как бы это сделать в 1 шаг, чтобы и deployment был 1 в kubectl rollout history? Спасибо

1) получаешь sha256 digest с помощью docker \ skopeo 2) заменяешь nginx:latest на nginx@sha256:... в dev.yaml 3) деплоишь без патчинга после

1) получаешь sha256 digest с помощью docker \ skopeo 2) заменяешь nginx:latest на nginx@sha256:... в dev.yaml 3) деплоишь без патчинга после

Я и так автоматом получаю sha256 из $CI_COMMIT_SHA. Хотелось бы не добавлять его вручную в dev.yaml. Хотя может делать как-то типа echo $CI_COMMIT_SHA > dev.yaml ну или чем-то более нативного для yaml? Или я вас не так понял..?

Я и так автоматом получаю sha256 из $CI_COMMIT_SHA. Хотелось бы не добавлять его вручную в dev.yaml. Хотя может делать как-то типа echo $CI_COMMIT_SHA > dev.yaml ну или чем-то более нативного для yaml? Или я вас не так понял..?

есть тысяча способов как изменить yaml - начиная от темплейтов, заканчивая sed. Все способы плохие по своему

к ingress есть решения по ingress.kubernetes.io/affinity c JWT?

ну кроме как своего кастомного балансера перед ingress, который будет кастомно перекладывать JWT в cookie

не в курсе, записи будут ?

yes

Да всё будет 🙂 У нас пока ещё нет человека, который помогал бы нам фотографии/видеозаписи обрабатывать/сортировать

Мб в чатике официально клич бросить?

есть тысяча способов как изменить yaml - начиная от темплейтов, заканчивая sed. Все способы плохие по своему

Тем не менее, в оф доках не брезгуют sed'ом https://kubernetes.io/docs/reference/kubectl/cheatsheet/ sed 's/\(image: myimage\):.*$/\1:v4/'

Может есть что-то более yaml нативное, типа https://github.com/0k/shyaml/blob/master/README.rst но с write?

да, gitlab вырос в такого монстра... ci, autodevops и тп. Когда его начинали, помню, никто не верил 💪

Хоть бы что-то нормально делать научился, и тут говно и там тоже. Куча недофич

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

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

а так у меня даже докер файла от него нет

Но образ то есть? FROM поделие:образ ... погнал фиксить

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

Сервису можно указать айпи при создании и он будет статический. Но в целом вопрос непонятен, как передать fqdn сервиса? Через переменные окружения, как всегда

Сервису можно указать айпи при создании и он будет статический. Но в целом вопрос непонятен, как передать fqdn сервиса? Через переменные окружения, как всегда

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

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

Если я правильно понимаю вопрос то вам нужен headless service

Если я правильно понимаю вопрос то вам нужен headless service

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

headless service = statefull ?

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

Нужно сделать сайдкар контейнер который будет в цикле бесконечно резолвить headless сервис и перегенерировать конфиг если что

Нужно сделать сайдкар контейнер который будет в цикле бесконечно резолвить headless сервис и перегенерировать конфиг если что

ооо это больно эпичные костыли. Нет более красивого метода ?

Вообще предыстория следующая, номад у нас хорошо работает, но хочется по пробовать нового + у номад нет зависимостей между контейнерами, такой дизайн такой что по другому ни как (шина, базы). Проблема нет пока когда идет штатное обслужинвание кластера, но для дев сред и тестов я полностью собираю новое окружение (базы, очереди, приложения) и вот тут начинаются прыжки с бубном, приложение может инициализироваться минут по 30, пока все зависимости скачаются и запустяться, сделано я это очень грубо (тупо бесконечный рестарт). От того что сделано грубо - дев среда пытается собратсья до последнего, даже если там есть фатальные ошибки в самом начале.

Я надеялся что кубер решит это. И надесь что решит, но собственно вот что я решаю

Вообще предыстория следующая, номад у нас хорошо работает, но хочется по пробовать нового + у номад нет зависимостей между контейнерами, такой дизайн такой что по другому ни как (шина, базы). Проблема нет пока когда идет штатное обслужинвание кластера, но для дев сред и тестов я полностью собираю новое окружение (базы, очереди, приложения) и вот тут начинаются прыжки с бубном, приложение может инициализироваться минут по 30, пока все зависимости скачаются и запустяться, сделано я это очень грубо (тупо бесконечный рестарт). От того что сделано грубо - дев среда пытается собратсья до последнего, даже если там есть фатальные ошибки в самом начале.

- у нас dev среда на docker-compose, почему так не делаете? Какая разница кто оркестрирует? - есть опыт использования nomad на мелких проектах? Насколько просто и гибко?

А вообще, если приложение без труда и проблем развертывается в любом окрестраторе это хороший знак и нужно к нему идти. Так?

- у нас dev среда на docker-compose, почему так не делаете? Какая разница кто оркестрирует? - есть опыт использования nomad на мелких проектах? Насколько просто и гибко?

compose - локально разрабы у себя. А у меня CI версионный, храним несколько версий всего (базы, шины, приложения). Ну и сборки разные с разными версиями. Потому нужна гибкость и зависиомости, в номад этого нет. Но я бы и не сказал что кубер такой же гибкий, все те проблемы что есть у меня в номад - есть и в кубере. Хотя statefull с инитами + волюм (разные драйверы) - реально киллер фича кубера

А вообще, если приложение без труда и проблем развертывается в любом окрестраторе это хороший знак и нужно к нему идти. Так?

переезжаете с mysql 5.6 на 10 марийку ? Без тестов ? Ну ок ) Кому как

Что значит развернуть - д

что значит развернуть - тупо запустить, да не беда, все запускается. Запустить с проверками и зависимостями. мониторингами и откатами в случае краха - вот тут и начинается все веселье.

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

С какими приверками нужно запускать?

С какими приверками нужно запускать?

запускать - если шина и база жива, после запуска проверить что запустилось, да желательно не внутреннией проверкой, а снаружи зайти ping-pong. Если все ок - вешать метки, которые прометей забирает. Ну классически, все как у всех собственно

У меня все приложение рестартятся, пока не дождуться нужных ответов. Все приложения если получают через ENV ссылку на influxdb, то скидывают туда ивенты мониторинга. Откат в случае краха это деплой старого релиза. всякие database rollback не делаются

У меня все приложение рестартятся, пока не дождуться нужных ответов. Все приложения если получают через ENV ссылку на influxdb, то скидывают туда ивенты мониторинга. Откат в случае краха это деплой старого релиза. всякие database rollback не делаются

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

Я хочу контролировать эту самую последовательность )

Мне может проще. Я и пишу сервисы и разворачиваю их в кластере. Если сервис напряжно будет развернуть - буду делать так, чтобы было ненапряжно.

То есть зачем поднимать шину, приложение, прокси, пока блин база качается. Зачем все делать одновременно. У номад обещают исправить в 9-10 версии (может вернемся к нему). А пока кубер, уж больно замороченный он, есть ощущение что гибкости по больше

Я год не решался залезь в кубер, сейчас фиг с него слезу, слишком удобно.

Мне может проще. Я и пишу сервисы и разворачиваю их в кластере. Если сервис напряжно будет развернуть - буду делать так, чтобы было ненапряжно.

вот коллеги тоже самое говорят. Но пока все не понятно, а после логики номада - все вообще "вверх дном". Ещё мезос есть, там точно зависимсти есть, но он ещё мудренее

k8s жирный. Только один минус. Поэтому думаю пробовать nomad для мелких vps за $10-20 которые. Работали с ним в этом ключе? По первому вгляду nomad на порядок легче.

k8s жирный. Только один минус. Поэтому думаю пробовать nomad для мелких vps за $10-20 которые. Работали с ним в этом ключе? По первому вгляду nomad на порядок легче.

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

Но идеологически очень хорош, связка с ваулт и консул и шаблонизатором - киллер фича.

и terraform... да, это понимаю. С vault и consul работал.

и terraform... да, это понимаю. С vault и consul работал.

терраформ оверкилл. Только если саму среду готовить... Потом шатануть все одной ошибкой - ну такое...

терраформ оверкилл. Только если саму среду готовить... Потом шатануть все одной ошибкой - ну такое...

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

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

Есть ощущение, что вы пытаетесь натянуть сову на глобус. А точнее свой много сервисный монолит запихнуть в кубер

И сталкиваетесь с закономерной болью

> Есть ощущение, что вы пытаетесь натянуть сову на глобус 2 минуты уже представляю как это выглядит

> Есть ощущение, что вы пытаетесь натянуть сову на глобус 2 минуты уже представляю как это выглядит

Знаете как курицу на ростер иногда сложно натянуть. А тут сова на глобус

https://williams-oliver.ru/assets/images/uploads/00010581844_2.jpg