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

а чем это отличается от бэкапа прямо с инстанса?

контейнер будет который бакапит

зачем мне вообще что-то на инстансе делать

инстанс будет уничтожатся тут постоянно все автоматизированно

ну во я дурень забыл же backslash

Товарищи, а как вы рассчитываете примерно ресурсы для кластера, перед поднятием? Сколько, нужно будет места на нодах, если, скажем, у меня планируется порядка 2000 контейнеров? :) может у кого формула интересная есть

у меня формула такая: начинают поды валиться - смотрю что память закончилась и oom-killer срабатывает, подгорает пердак и добавляю еще один комп ну, это приближенная формула... :)

оффтоп: а че, есть инфа когда примерно 1.6.0 в гугле выйдет?

1.6.1 текущая

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

ооо, тоогда не скоро, в 1.6 слишком много мажорных изменений

тут на bare metal не понятно как без последствий 1.5 -> 1.6 обновить

у меня формула такая: начинают поды валиться - смотрю что память закончилась и oom-killer срабатывает, подгорает пердак и добавляю еще один комп ну, это приближенная формула... :)

Вот аналогичная схема? но хотелось бы чтото спрогнозировать, ибо планируем перекатится на это все

Если в облаках, то "Интересная формула" - cluster autoscaler

https://github.com/kubernetes/contrib/tree/master/cluster-autoscaler

Если в облаках, то "Интересная формула" - cluster autoscaler

увы, не облака(

Тогда ставить алерты на память и место на диске и добавлять ноды по мере необходимости

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

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