хочу фидбек)

Тогда нужна вводная!

1. Какие были требования? 2. Какая возникла проблема? 3. Какое появилось решение?

хочу фидбек)

Вжух

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

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

??

https://github.com/deis/workflow/blob/master/src/changelogs/v2.13.0.md

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

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

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

Пфф)

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

Зависит от подачи :)

1.6.0 доступен в GKE, теперь и в Европе ?

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

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

Это "берешь рхел атомик+опеншифт и не делаешь свои костыли"

везет тебе с количеством времени свободного на работе

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

обновляю плейграунд

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

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

там какой порядок правильный? apiservers -> scheduler -> controller manager -> kubelets?

на etcd3 переезд тоже без даунтайма?

для etcd у кореос есть же схема обновления

для GKE gcloud container clusters upgrade CLUSTER-NAME --master -z europe-west1-b --cluster-version 1.6.0 gcloud container clusters upgrade CLUSTER-NAME -z europe-west1-b --cluster-version 1.6.0 :)

Как следующий кластер обновлять буду - замерю даунтайм

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

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

там (или не там) кажется было что если etcd3 HA то будет даунтайм

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

>This process allows for zero downtime upgrades of Kubernetes.

ну или https://github.com/coreos/etcd/blob/master/Documentation/op-guide/v2-migration.md#online-migration

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

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

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

гуру, кто может пояснить: kubeadm init ....... [token] Using token: c27b85.93d17a5c4d18214e configmaps "cluster-info" already exists где этот cluster-info ?

Kubectl get configmap

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

оно хранится не в etcd?

если да, то его там найти/вычистить есть шанс?

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

попробуй в других namespaces, --all-namespaces

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

все хранится в etcd но туда лучше не лезть

kubectl delete удаляет ресурсы

dex и oidc решили отложить еще на полгодика:) Вдруг kubectl login допилят к тому времени

Кто нибудь отключал в kube-apiserver —insecure-port=0 ? Есть какие-нибудь подводные камни?

у нас scheduller и controller manager живут рядом с apiserver и ходят через этот порт к нему. если у вас что-то подобное, то сломается

ага. Для них сделаю kubeconfig и сертификаты. Здесь и в связанных pr добавляли флаг, чтобы apiserver мог делать запросы сам в себя по сертификатам. Но в 1.5+ я этих флагов уже не вижу. Вот и задумался. https://github.com/kubernetes/kubernetes/issues/13598

ошибся. всё еще есть: —tls-ca-file string If set, this certificate authority will used for secure access from Admission Controllers. This must be a valid PEM-encoded CA bundle.

А нет ли случаем подобного канала по GKE?

или даже скорее по gce

я бы подписался. или сделать?

сделать

А что за gke?

google kontainer engine

так, что-то не то

А чего вы здесь не хотите остаться?

а не, все верно

так никто и не уходит)

compute engine и с(k)ontainer engine

угу просто k сделали, чтобы от общего сервиса отличать

ну gcp это не только кубер, а мучить людей вопросами про LB, MIG и прочее тут как-то совестно

Короч, кто хочет админить - создавайте gcp_ru, никто не захочет - я создам

ну раз пока канала нет попробую немного оффтопнуть, на в gke через endpoint используем cloud sql. Внимание вопрос: Можно как то кроме скудных метрик stackdriver и самого cloud sql monitoring собирать подробную статистику с этих баз, в частности по конкретным запросам и не в общем?

Создаю

@gcp_ru налетаем

Приветсвую. А есть у кого-то реальный опыт работы с Kubernetes на Azure в Azure Container Services?

У меня была попытка, но не особо завелось. https://github.com/Azure/acs-engine/issues/96 возможно на обычном облаке будет ок

Я сам из MS русского, делаем митап 19 на белорусской про микросервисы на Azure. Там будет уже общая докер история и Windows контейнеры + Servive Fabric. Очень хочу найти кого-то с реальным опытом Kuberntes на Azure, чтобы поделился живым опытом.

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

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

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

Обзор про варианты реализации микро-сервисы в Azure - я Service Fabric в Azure - Женя Григоренко

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

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

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

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

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

Сейчас документация стала норм. Можно начать оттуда, https://docs.microsoft.com/ru-ru/azure/service-fabric/ https://docs.microsoft.com/ru-ru/azure/container-service/ https://docs.docker.com/docker-for-azure/#docker-community-edition-ce-for-azure И лаба https://github.com/azuredk/docker-on-azure-hol

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

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

Сейчас Windows Containers в превью https://azure.microsoft.com/en-us/blog/kubernetes-now-generally-available-on-azure-container-service/

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

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

ага

ОХУЕТЬ

ага

эм, поддержка Windows в Kubernetes еще в альфе.

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

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

Я и написал - превью сейчас в ACS. И вот с самим K8s, вот официальный анонс про альфа - всё так. http://blog.kubernetes.io/2016/12/windows-server-support-kubernetes.html

Привет Я туплю, но есть где-то примеры или может у кого был успешный опыт как рулить сложными зависимостями в 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 в данном случае не помогает Буду рад ответам

у нас в чате уже есть люди из мирантис, google и microsoft. а из amazon никого случайно нет? :)

У истории с отключением insecure-port в kube-apiserver итог такой: 1. В kube-apiserver нужно добавить опцию —tls-ca-file=/path/to/kube-apiserver-server-cert-ca.pem, т.к. kube-apiserver обращается сам к себе по http. И без этой опции ходит на insecure-port 2. Всем компонентам кластера нужно добавить опцию —kubeconfig с правильным конфигом. —master, —api-servers и другие опции можно выпилить. К kubelet нужно дополнительно добавить —require-kubeconfig. 3. Добавить к kube-apiserver опцию —anonymous-auth=false, чтобы он не разрешал запросы от клиентов без токена, пароля или сертификата. 4. Добавить к kube-apiserver —token-auth-file и —basic-auth-file по желанию 5. В kube-apiserver удалить —insecure-bind-address и поставить —insecure-port=0. Профит

И если вы используете сертификаты для компонентов кластера и планируете включать RBAC, то у каждого сертификата должен быть правильный CN https://kubernetes.io/docs/admin/authorization/rbac/#core-component-roles

Привет Я туплю, но есть где-то примеры или может у кого был успешный опыт как рулить сложными зависимостями в 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 в данном случае не помогает Буду рад ответам

зависимости в helm не то же самое что зависимости в yum и apt-get, если 2 чарта хотят редис, то будет 2 редиса в системе, а не один на всех. так что как минимум общие редисы и прочее должны быть отдельными helm релизами

> Стоит ли 1 сервис разбивать на несколько helm charts? стоит если оно переиспользуется. скажем можешь использовать чарты-шаблоны, которые без overrides нерабочие. Например php-fpm содержит все демоны, мониторинг, какие-нибудь крутилки, но все это без конкертных php файлов для деплоя. такому чарту в overrides прописываешь скажем тарбол или докер image откуда брать php файлы, а все остальное оно делает само

> Ну т.е. обновил я ConfigMap. А Deployment от этого не стал обновлять ReplicaSet и сами поды если конфигмапы проброшены в поды через volumes, то при обновлении конфигмапов файлы на ФС тоже обновятся. так что если pod подберет новые файлы, то ничего редиплоить не нужно. если хочется редеплоя, то можно скажем хэш или версию зависимости (в данном случае configmap) прописать в sepc.template.metadata.annotations под каким-нибудь своим ключем, тогда обнволения конфигмапа спровоцирует обновление подов в деплое

И если вы используете сертификаты для компонентов кластера и планируете включать RBAC, то у каждого сертификата должен быть правильный CN https://kubernetes.io/docs/admin/authorization/rbac/#core-component-roles

да это, печаль. у нас vault заполняет /OU=, а Kubernetes смотрит в /O=. думаем вот что патчить :)

http://blog.kubernetes.io/2017/04/rbac-support-in-kubernetes.html

Доброго вечера, друзья! новичок в к8s. Установлено все под ubuntu 16.04, через snap.Подскажите, есть профит ставить ручками по официальному ману и вообще, есть какие-то best practices на этот счёт? Спасибо.

Доброго вечера, друзья! новичок в к8s. Установлено все под ubuntu 16.04, через snap.Подскажите, есть профит ставить ручками по официальному ману и вообще, есть какие-то best practices на этот счёт? Спасибо.

Профит поставить разок по Kubernetes the Hard way

Примерно то же, что пройти Linux from scratch

Kelsey и Мирантис активно работают, чтобы жизнь была проще в этом направлении))