Ребятки, а кто может сказать с Flannel я могу создавать мастер и ноду в разных подсетях? Мастер 172.32.1.85, а нода 172.32.2.55? Если кластер инициилизировать kubeadm init --pod-network-cidr=172.32.0.0/16

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

Как же достал этот терминатор ужо!

Люди не кто не в курсе где можно прочитать по 3-й хэлм? Что будет нового, что исправят в старом фунционале и т.п

Люди не кто не в курсе где можно прочитать по 3-й хэлм? Что будет нового, что исправят в старом фунционале и т.п

https://sweetcode.io/a-first-look-at-the-helm-3-plan/ немного есть тут

Ребятки, а кто может сказать с Flannel я могу создавать мастер и ноду в разных подсетях? Мастер 172.32.1.85, а нода 172.32.2.55? Если кластер инициилизировать kubeadm init --pod-network-cidr=172.32.0.0/16

Нет

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

Какая версия куба и дашборды?

https://sweetcode.io/a-first-look-at-the-helm-3-plan/ немного есть тут

спасибо!

Ребятки, а кто может сказать с Flannel я могу создавать мастер и ноду в разных подсетях? Мастер 172.32.1.85, а нода 172.32.2.55? Если кластер инициилизировать kubeadm init --pod-network-cidr=172.32.0.0/16

Хотя должно работать :)

в helm в зависимые объектые в аннотации добавляют хэши отрендеренных объектов. в итоге например деплоймент обновится, когда изменишь конфиг мап и поедет роллинг апдейт

Это что-то как package.lock для ноды, для воспроизводимости билдов? Накат-откат одной командой? Полезная вещь? Я хельм пока стороной обходил, настраивал все через гуи.

Через какие гуи?) в helm есть requirements, но то, о чем я говорил выше, совсем другое и не требует хелм, можно самому любым шаблонизатором сделать

с кем можно поговорить по поводу организации CD в кубер без остановки приложения при миграции баз?

с кем можно поговорить по поводу организации CD в кубер без остановки приложения при миграции баз?

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

ну вот надо в комплексе - как организуют репо, как собирают helm, скрипты апдейтов, как накатывают, как следят за накатом и прочее

кстати, если секса пока мало - можете поробовать ubuntj kubernetes - в 18.04 встроен вроде

И как он? Классика или...

И как он? Классика или...

Так пока не пробовал, вот думаю может у кого есть резерв времени)

кто выигрывает?

Те которые в красных шлемах :)

ну вот надо в комплексе - как организуют репо, как собирают helm, скрипты апдейтов, как накатывают, как следят за накатом и прочее

Обычная схема в три шага: код который работает и с обеими версиями схемы данных, миграция через job, новый код только для новой версии схемы. Job из CI можно дергать ручками

А чо не в жёлтых штанах ? )

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

+1

Так пока не пробовал, вот думаю может у кого есть резерв времени)

Таже фигня. А интересно же :)

А чо не в жёлтых штанах ? )

Это из другого фильма, темболее малиновые штаны круче.

с кем можно поговорить по поводу организации CD в кубер без остановки приложения при миграции баз?

если приложение поддерживает миграцию без downtime, просто запихай в инит скрипт в образе

Привет! Выкатили в опен сорс софт Cоntainterum, работает поверх Kubernetes, дает удобный UI, CI/CD pipelines, командную работу над проектами, revision control. https://github.com/containerum/containerum/ для развития проекта, нужны звезды в репозитории, если не сложно, буду очень благодарен)

с кем можно поговорить по поводу организации CD в кубер без остановки приложения при миграции баз?

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

если приложение поддерживает миграцию без downtime, просто запихай в инит скрипт в образе

не лучше ли post-upgrade helm hook'ом?

Народ, а для CI в k8s кто нибуть использует сторонние инструменты, кромн хелма?

codefresh

helmfile

chamber (для секретов) но мы на aws )

С ksonnet был у кого опыт?

helmfile

Спасибо. И как без глюков работает?

базовый функционал да

но вообще есть "особенности"

это ж обертка над helm и все его пороки прилагаются

например проблема с типами данных которые передаются через --set

счас починили более менее сделали какой то ---set-string

вообщем вполне живой

вообщем вполне живой

Спасибо поразбираюсь. Думаю это самое то, для тех кто юзает helm базовым для CI

Народ, а кто нибуть дружил эту штуку с консулом? https://github.com/skuid/helm-value-store

Все привет. ТАкая вот проблемка

куб кластер 1 мастер и 2 воркера грохнул одного воркера под, который там крутился, в состоянии unknown удаляю этот под - уже минут 15 висит

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

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

ща минуту

куб кластер 1 мастер - хорошая рифма

:)

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

kubectl delete pods $POD --grace-period=0 --force

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

Где $POD вставляй имя пода

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

Если не поможет то вот так попробуй kubectl patch pod $POD -p '{"metadata":{"finalizers":null}}'

@denyasmail Спасибо огромное ща буду пробовать

Вот к примеру следующая последовательность изменений: 1. Запуск джобы, которая запускает миграцию, которая добавляет новую колонку в таблицу 2. Деплой через helm приложения, которое работает со старой колонкой, но умеет писать в новую колонку 3. Запуск джобы, которая заполняет новую колонку 4. Деплой через helm приложения, которое работает только с новой колонкой 5. Запуск джобы, которая удаляет старую колонку Итого три миграции и два деплоя приложения в строгой последовательности. Кто как для этого случая организует репо, артефакты, как выкатывает? @mxssl @im_xray33 @gorilych @yurik687 @shursh @StalkerNOVA

куб кластер 1 мастер и 2 воркера грохнул одного воркера под, который там крутился, в состоянии unknown удаляю этот под - уже минут 15 висит

если у вас погасла нода, kubernetes сочтет хорошим тоном если вы удалите ее из кластера kubectl delete node <NodeName> и перераспределит ваш под. Когда нода снова зажжется, она сама добавится в кластер, если с ней все (стало) ок.

если у вас погасла нода, kubernetes сочтет хорошим тоном если вы удалите ее из кластера kubectl delete node <NodeName> и перераспределит ваш под. Когда нода снова зажжется, она сама добавится в кластер, если с ней все (стало) ок.

Благодарю за инфу. Не знал тоже этого

еще https://github.com/kubernetes-incubator/descheduler/blob/master/README.md может быть полезен

@denyasmail Спасибо Денис ПОМОГЛО! kubectl delete pods $POD --grace-period=0 --force

@denyasmail Спасибо Денис ПОМОГЛО! kubectl delete pods $POD --grace-period=0 --force

?

Какая версия куба и дашборды?

Dashboard Version: v1.8.3 Kubernetes: v1.10.4

всем привет. в эфире снова любознательный куберовод. 3 ноды на baremetal. Хочу сделать Deployment (replicas: 3) с общим стораджем. раскатал rook-ceph. Создал PV с типом ReadWriteMany, вписал монтирование pv в Deployment, но запускается только 1 экземпляр, остальные 2 висят ждут. ЧЯДНТ ?

Вот к примеру следующая последовательность изменений: 1. Запуск джобы, которая запускает миграцию, которая добавляет новую колонку в таблицу 2. Деплой через helm приложения, которое работает со старой колонкой, но умеет писать в новую колонку 3. Запуск джобы, которая заполняет новую колонку 4. Деплой через helm приложения, которое работает только с новой колонкой 5. Запуск джобы, которая удаляет старую колонку Итого три миграции и два деплоя приложения в строгой последовательности. Кто как для этого случая организует репо, артефакты, как выкатывает? @mxssl @im_xray33 @gorilych @yurik687 @shursh @StalkerNOVA

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

всем привет. подскажите такой момент - с поды стучусь на ингресс с самоподписанным сертом, но вместо сгенеренного мной серта мне отдаётся другой - Kubernetes Ingress Controller Fake Certificate. при этом с мира отдаётся мой серт. почему подам отдаётся не тот серт что я выдал ingress? не могу найти описание этой логики в доках. я так понимаю если серт будет валидный загружен с поды он всё равно будет фейк виден, и она будет на него ругаться ...

Dashboard Version: v1.8.3 Kubernetes: v1.10.4

https://github.com/kubernetes/dashboard/wiki/Compatibility-matrix ничего неизвестно о поддержке 1.10 куба в борде 1.8

всем привет. в эфире снова любознательный куберовод. 3 ноды на baremetal. Хочу сделать Deployment (replicas: 3) с общим стораджем. раскатал rook-ceph. Создал PV с типом ReadWriteMany, вписал монтирование pv в Deployment, но запускается только 1 экземпляр, остальные 2 висят ждут. ЧЯДНТ ?

Посмотри тут на табличку: https://kubernetes.io/docs/concepts/storage/persistent-volumes/#persistent-volumes RBD не поддерживает ReadWriteMany

всем привет. подскажите такой момент - с поды стучусь на ингресс с самоподписанным сертом, но вместо сгенеренного мной серта мне отдаётся другой - Kubernetes Ingress Controller Fake Certificate. при этом с мира отдаётся мой серт. почему подам отдаётся не тот серт что я выдал ingress? не могу найти описание этой логики в доках. я так понимаю если серт будет валидный загружен с поды он всё равно будет фейк виден, и она будет на него ругаться ...

Ингресс-ресурс в студию и по одинаковым ли доменам стучишься

Привет! Выкатили в опен сорс софт Cоntainterum, работает поверх Kubernetes, дает удобный UI, CI/CD pipelines, командную работу над проектами, revision control. https://github.com/containerum/containerum/ для развития проекта, нужны звезды в репозитории, если не сложно, буду очень благодарен)

Привет, в чем от ранчера отличается? Или это только ci/cd?

Люди, а кто кубспреем добавлял вокреров? Прогнал по докам cluster.yml с измененным инвентори , на новом ноде все установилось , кублет настроенный, но машина в кластер не присоеденна

Ингресс-ресурс в студию и по одинаковым ли доменам стучишься

apiVersion: extensions/v1beta1 kind: Ingress metadata: annotations: nginx.ingress.kubernetes.io/secure-backends: "true" creationTimestamp: 2018-07-24T07:40:50Z generation: 3 name: helm-test namespace: test uid: e2f7f6a7-8f14-11e8-a8c8-0a58ac1f004f spec: backend: serviceName: test servicePort: 443 rules: - host: test.test http: paths: - backend: serviceName: test servicePort: 443 path: / tls: - hosts: - test.test secretName: test выглядит он так в поде прописан этот домен через hosts, указан внешний IP ингресса

Посмотри тут на табличку: https://kubernetes.io/docs/concepts/storage/persistent-volumes/#persistent-volumes RBD не поддерживает ReadWriteMany

пнятно.. а как-то вообще можно обеспечить общий сторадж для подов?

там же написано: gluster, cephfs...

я почему-то подумал, что раз rook создал ceph-кластер, то это и есть cephFS

у ceph'а есть RBD, cephfs, RADOS GW

cephfs ~= NFS

apiVersion: extensions/v1beta1 kind: Ingress metadata: annotations: nginx.ingress.kubernetes.io/secure-backends: "true" creationTimestamp: 2018-07-24T07:40:50Z generation: 3 name: helm-test namespace: test uid: e2f7f6a7-8f14-11e8-a8c8-0a58ac1f004f spec: backend: serviceName: test servicePort: 443 rules: - host: test.test http: paths: - backend: serviceName: test servicePort: 443 path: / tls: - hosts: - test.test secretName: test выглядит он так в поде прописан этот домен через hosts, указан внешний IP ингресса

вообще, тот дефолтный серт выдается в двух случаях 1) нет tls сикрета 2) домен не подходит под hosts в tls

вообще, тот дефолтный серт выдается в двух случаях 1) нет tls сикрета 2) домен не подходит под hosts в tls

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

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

у нас аналогично, только этот под создается из job и все это завернуто в хелм чарт. Т.е. запуск миграций это одна команда на инстал хелм чарта (сам скрипт миграции пишет свой прогресс в слак т.к. миграция может бежать много часов а то и дней)

Вот к примеру следующая последовательность изменений: 1. Запуск джобы, которая запускает миграцию, которая добавляет новую колонку в таблицу 2. Деплой через helm приложения, которое работает со старой колонкой, но умеет писать в новую колонку 3. Запуск джобы, которая заполняет новую колонку 4. Деплой через helm приложения, которое работает только с новой колонкой 5. Запуск джобы, которая удаляет старую колонку Итого три миграции и два деплоя приложения в строгой последовательности. Кто как для этого случая организует репо, артефакты, как выкатывает? @mxssl @im_xray33 @gorilych @yurik687 @shursh @StalkerNOVA

обычно сначала всегда идет деплой кода который умеет работать со старой и новой (и/или переходной) схемой

и тогда пункты 1, 3 и 5 можно объединить в одну джобу

всем привет. подскажите такой момент - с поды стучусь на ингресс с самоподписанным сертом, но вместо сгенеренного мной серта мне отдаётся другой - Kubernetes Ingress Controller Fake Certificate. при этом с мира отдаётся мой серт. почему подам отдаётся не тот серт что я выдал ingress? не могу найти описание этой логики в доках. я так понимаю если серт будет валидный загружен с поды он всё равно будет фейк виден, и она будет на него ругаться ...

а как стучитесь? надо же правильный Host header указать наверное

А подскажите по helm. У меня RBAC и я собираюсь установить тиллер с сервисным аккаунтом metadata: name: tiller namespace: kube-system - оно сможет ставить приложения в любые неймспейсы или только в kube-system?

А подскажите по helm. У меня RBAC и я собираюсь установить тиллер с сервисным аккаунтом metadata: name: tiller namespace: kube-system - оно сможет ставить приложения в любые неймспейсы или только в kube-system?

В любые

спасибо!

А подскажите по helm. У меня RBAC и я собираюсь установить тиллер с сервисным аккаунтом metadata: name: tiller namespace: kube-system - оно сможет ставить приложения в любые неймспейсы или только в kube-system?

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

--- apiVersion: rbac.authorization.k8s.io/v1beta1 kind: ClusterRoleBinding metadata: name: tiller roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: cluster-admin subjects: - kind: ServiceAccount name: tiller namespace: kube-system

тогда в любые, потому что у вас прибинден cluster-admin

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

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

А другие доступные воркеры есть?

ну еще 2 ноды да

А кто-то пробовал поставить локально kubernetes? Почему scheduler не может раздать ip для пода? default-scheduler 0/1 nodes are available: 1 node(s) had taints that the pod didn't tolerate.

причем потом он сам без каких то действий особых просирается и раскидывает по ним

но довольно долго тупит

ну еще 2 ноды да

своп выключен?