Из требований - развернуть k8s на baremetal и использовать coreos в качестве базовой системы. Зачем - это другой вопрос. можно считать, что для эксперимента. Проблема возникла в самом начале - мало документации как это сделать. Готовых инструментов тоже сразу не нашлось, кроме matchbox. Проблема matchbox в том что примеры в папке examples работают со скрипом и чтобы в них разобраться пришлось потратить кучу времени, т.к. они никак не разделены на модули. В итоге оказалось, что тестовый кластер развернутый через matchbox маячит наружу открытыми etcd портами. Вообщем стало понятно, что это нерабочие примеры. Кроме того, если не поднимать какую то серьезную PKI инфраструктуру, тяжело работать с сертификатами нод и пользователей. В итоге родился seedbox. Все началось с легковесной PKI. Потом скопировал конфиги из matchbox, разложил по папочкам. Каждая папочка отвечает за один компонент. Потом заметил tectonic-installer, который заявлен как production-grade. Взял несколько идей оттуда, а также подчистил конфигурацию. На etcd повесил tls, чтобы ноды общались по зашифрованному каналу. Как то так.

Почти тема для lighting talk на следующем Kubernetes митапе))

> Пфф) это типо "кул" или "сакс"? :)

кто-нибудь на GKE уже обновлялся? че-то стремненько

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

https://coreos.com/blog/migrating-applications-etcd-v3.html

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

я играюсь с кубернетесом.. почти нуб. сношу, ставлю и т.п. после kubeadm reset оно вроде бы должно все вычистить... делаю init и вот такое получаю. kubectl get configmap No resources found.

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

а кто докладчик если не секрет?

Потенциальный про Микросервисы на винде - Андрей Зорин из БинБанк Диджитал Они там круто сделали, хотя и с единой базой (не на контейнерах)

а где бы просто почитать про service fabric и конейтеры в азуре?

а там выходит только линуксовые контейнеры?

эм, то есть кубик будет рулить виндовыми контейнерами?!

ага

https://github.com/kubernetes/features/issues/116

Привет Я туплю, но есть где-то примеры или может у кого был успешный опыт как рулить сложными зависимостями в helm? Не зависимости уровня "Вордпрес", а что-то более сложное. Ну вот например есть у меня 5 микросервисов (на самом деле нет) на PHP. Например каждый сервис состоит из контейнеров: nginx, php-fpm, memcached, 3-10 воркеров которые слушают очередь. А еще есть общие редис кластер, rabbitmq, postgres, etc. Вопросы: 1) Стоит ли 1 сервис разбивать на несколько helm charts? или все пихать в один? Ведь все компоненты сервиса будут обновляться в одно время при деплое 2) Стоит ли описывать зависимости между сервисами и между сервисом и бд, редис кластером и т.д? 3) Насколько я понял имя релиза уникальное в kubernetes namespace. Тогда как называть релизы? stable/trunk/staging уже не подходят, а т.к. имя релиза идет в названии сервиса то как-то сложно будет поддерживать все эти зависимости когда например после релиза адрес бд поменяется 4) Как при helm upgrade обновлять что-то кроме deployments? Ну т.е. обновил я ConfigMap. А Deployment от этого не стал обновлять ReplicaSet и сами поды. Ключ --recreate-pods в данном случае не помогает Буду рад ответам