там в морде в настройках нода есть инфа по подам

http://joxi.ru/1A5vGa1teb5qrE

она приблизительная, но у нас проблемы начались когда мы превысили на 50% но это в тестовой среде.

https://www.youtube.com/watch?list=PLqm7NmbgjUExeDZU8xb2nxz-ysnjuC2Mz&v=x2Lp8nktLjE

https://kubernetes.io/docs/tasks/run-application/podpreset/

такое ощущение что порты консула меняются на каждый релиз

https://www.youtube.com/watch?list=PLqm7NmbgjUExeDZU8xb2nxz-ysnjuC2Mz&v=x2Lp8nktLjE

а выступление авиты есть с кубернетисом?

avitotech на ютьюбе, там должны быть

Да)

Была ссылка выше

Благодарю

не понимаю зачем мне consul в докер сварме, какую проблему он решает? service discovery термин мутный какой-то

Но без него (SD) было никак, раньше

я как-то и без него живу

что я упускаю?

С чем?

у меня есть докер сварм кластер

все контейнеры видят друг друга

зачем мне еще что-то )?

Коллеги, пришлось обновить сертификат с ключем для api-server, использовался тот же CA. Теперь pod'ы не запускаются, которым требуется аутентификация в k8s. Помню раньше как-то решал эту проблему удалением default token'а из secrets, а теперь это не помогает. Пытаюсь загуглить похожую проблему, но пока пусто. Может кто-то помнит как правильно сертификаты обновлять?

типо если куданибудь какой нибудь мускуль переместишь чтобы не трогать env variables в docker-compose ? у меня не такой маштаб что бы об этом волноватся

где вообще сейчас находится дока по сварму? _______ компания докер уже ______ играться с именами своих продуктов

где вообще сейчас находится дока по сварму? _______ компания докер уже ______ играться с именами своих продуктов

https://docs.docker.com/engine/swarm/

> Using a Raft implementation, the managers maintain a consistent internal state of the entire swarm and all the services running on it. в docker swarm нужен был, в docker swarm mode походу уже нет. хотя там есть всякие плюшки типа деления на dc.

забавно

тогда какого черта я тут время трачу с консулом )))

мне то на три виртульки запилить сварм нужно и всего-то

вижу justification что если выносить сервисы за пределы сварма тогда нужен уже service discovery, что бы конфигурацию не переписывать в docker-compose

@kay_rus покажи конфиг контроллера

@yolkov , благодарю. перезапустил api, но не controller-manager

после перезапуска controller-manager всё ок

Выдели отдельный ключ для controller-manager --service-account-private-key-file а тут его публичный или можно тот же закрытый apiserver --service-account-key-file тогда при смене ключа и сертификата для апи не придется удалять дефолтный(да и остальные) токены и рестартовать поды

Выдели отдельный ключ для controller-manager --service-account-private-key-file а тут его публичный или можно тот же закрытый apiserver --service-account-key-file тогда при смене ключа и сертификата для апи не придется удалять дефолтный(да и остальные) токены и рестартовать поды

ok

В карго что можно было ткнуть чтобы выдало? SchedulingDisabled $ kubectl get nodes NAME STATUS AGE kub-i1 Ready 10m kub-i2 Ready 10m kub-master Ready,SchedulingDisabled 10m

В карго что можно было ткнуть чтобы выдало? SchedulingDisabled $ kubectl get nodes NAME STATUS AGE kub-i1 Ready 10m kub-i2 Ready 10m kub-master Ready,SchedulingDisabled 10m

Печалька :(

Ага

что-то пошло не так :)

Выдели отдельный ключ для controller-manager --service-account-private-key-file а тут его публичный или можно тот же закрытый apiserver --service-account-key-file тогда при смене ключа и сертификата для апи не придется удалять дефолтный(да и остальные) токены и рестартовать поды

тогда зачем вообще оно нужно если ротацию устраивать не собираетесь? выпишите сертификаты до 2037 года и живите спокойно. тем кому ротация нужна: можн указаывать несколько --service-account-key-file , туда включить публичные ключи из разных ротаций

а у кого rdb volumes и ceph kraken ? как вы обошли депрекейтед image format 1?

@rossmohax если посмотришь повнимательнее то в этих опциях вообще нет сертификатов, там реч о ключах!

и ключи для токенов ой как больно менять

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

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

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

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

Я говорил про сертификаты как о секретах которым нужна ротация. Выглядит нелогично ротировать одни (сертификаты) и не ротировать другие (токены). Если уж допустимо жить с токенами вечно ибо "слишком сложно", то можно и сертификаты оставить в покое и тогда никаких доп флагов для отдельных токенов не надо , так как дефолты просто работают

не будет работать, если у каждой ноды свой сертификат

не будет работать, если у каждой ноды свой сертификат

В смысле?

если инстансы kubelet запущены с разными сертификатами и соответственно ключами

У нас как раз так, Если они подписаны одним СА все ок

а у kube-controller-manager --service-account-private-key-file какой?

я спутал. сорри. это если у вас apiserver HA и у каждого аписервера свой сертификат/ключ

тогда дефолты не будут работать

Дефолты не для HA, да :)

С этим HA вообще сказка, кто-нибудь тестировал как оно живет если зону полностью отключить? Или все надеялся что вырулит как-нибудь само? :) мы вот надеямся, но чуток потестили, выяснили что apiserver по дефолту радостно читает из etcd без кворума

Ротация токенов: 1. Генерим ключевую пару 2. Перезапускаем все apiserver добавляя новый,публичный ключ к существующим 3. Перезапускаем все controller manager с новым приватным ключом 4. Удаляем токены из secrets из всех неймспейсов, контроллерв пересоздадут их мгновенно, аписервер будет доверять и старым и новым 5. Перезапускаем / следим за всеми подами, которые используют удаленные секреты (будет у них в volumes) 6. Когда всем переехали, удаляем старые публичные ключи и перезапускаем apiserver без них

будут если для токенов выделить отдельный ключ

для аписервера прям несколько раз опцию --service-account-key-file указываешь?

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

кто-нибудь делал аутентификацию через ldap или google openid? Смотрю dex, но не понимаю куда копать. Там требуется отдельный их example-app и вообще всё не user friendly https://github.com/coreos/dex/blob/master/Documentation/kubernetes.md#logging-into-the-cluster

примерно так apiVersion: extensions/v1beta1 kind: Deployment metadata: name: tectonic-identity namespace: tectonic-system labels: app: tectonic-identity component: identity spec: replicas: 1 # New identity pods must be healthy for 30 seconds # before they're marked as ready. minReadySeconds: 30 strategy: rollingUpdate: # During a rolling update every deployed pod must be # ready before the update terminates an existing pod. maxUnavailable: 0 template: metadata: name: tectonic-identity labels: app: tectonic-identity component: identity spec: volumes: - name: config configMap: name: tectonic-identity items: - key: config.yaml path: config.yaml - name: tectonic-identity-grpc-server-secret secret: secretName: tectonic-identity-grpc-server-secret containers: - name: tectonic-identity imagePullPolicy: IfNotPresent image: quay.io/coreos/dex:v2.3.0 command: ["/usr/local/bin/dex", "serve", "/etc/dex/config.yaml"] volumeMounts: - name: config mountPath: /etc/dex - name: tectonic-identity-grpc-server-secret mountPath: /etc/tectonic-identity-grpc-server-secret readOnly: true ports: - containerPort: 5556 protocol: TCP - containerPort: 5557 protocol: TCP livenessProbe: httpGet: path: /identity/healthz port: 5556 initialDelaySeconds: 5 timeoutSeconds: 1 resources: requests: cpu: 100m memory: 50Mi limits: cpu: 100m memory: 50Mi # For development, assume that all images we build ourselves are under a # private registry. imagePullSecrets: - name: coreos-pull-secret

@nailgunster staticClients в конфиге dex и приложение с redirect_url все равно нужны получается?

сам не знаю. это я изучаю что генерит tectonic installer и пишу свой велосипед для provisioning-га кластера. это из тектоника, сам не использовал oid

а у нас тектоника нет. Я надеялся отделаться просто dex + kubectl

он и не нужен. можно просто оттуда взять примеры манифестов

сам не знаю. это я изучаю что генерит tectonic installer и пишу свой велосипед для provisioning-га кластера. это из тектоника, сам не использовал oid

kube-aws + легонький git workflow очень хорошо работает

а мне надо bare-metal(

Vitaliy можешь тут глянуть https://github.com/coreos/tectonic-installer/tree/master/modules/tectonic/resources/manifests/identity они недавно открыли исходники, но не все

Здесь тоже ${console_callback} который делает всю магию, если я правильно понимаю. Пойду kubernetes слак почитаю...

а. ну видать он ссылается уже на проприетарный tectonic console. тогда увы..

а мне надо bare-metal(

везёт

кстати, вот он. мой велосипед. может кому пригодится https://github.com/nailgun/seedbox

Огонь )

Можно ещё сюда - @coreos_ru

запостил)

хочу фидбек)

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

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, чтобы ноды общались по зашифрованному каналу. Как то так.

👍🏻