если он меньше, чем живых apiservers -> они постоянно пытаются добавить себя и обновляют эту запись если себя не видят,при этом выкидывая одну из записей которая там уже есть

если он больше, чем живых apiservers -> все живые добавляют себя и не парятся, а лишние "мертвые" записи так и висят, и периодически отдаются клиентам, клиенты в этом случае не могут свзяться с apiserver и спамят в лог

тоесть, для 3х-нодового сетапа мастеров, мне достаточно манифест подсунуть с этим параметром=3? если он просто менеджит кол-со записей но не сами контейнеры с апи.

вобщем если хотите настоящий HA то не ставьте этот параметр и терпите вечный трафик в etcd на обновление этой записи каждые N секунд. в противном случе если apiserver упадет (или будет выключен для обновления скажем), то 1/X коннектов к apiserver будут с ошибкой, где X - количетсво apiservers

ок, понял. А если я хочу ему передать параметр bind (не равный advertise) и на "advertise-нный" адрес повесить балансер (nginx к примеру) то можно будет не терпеть?

ок, понял. А если я хочу ему передать параметр bind (не равный advertise) и на "advertise-нный" адрес повесить балансер (nginx к примеру) то можно будет не терпеть?

не все поды могут (должны) покидать kube, для доступа к балансеру придется, если вам это не страшно и вы считаете, что балансер у вас HA, то должно сработать

мы для себя решили незамечать проблему и оставить как есть --apiserver-count=1 :)

эт значит что клиенты будут ходить в разные api, постоянно. а если они в разных DC? на сколько вообще (по вашему опыту) критично время отклика api?

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

но это теория :)

в etcd всё равно пишется в лидера, а лидер один и если он в другом DC, то может получится 2 хопа между DC: client (dc1) -> apiserver (dc2) -> etcd leader (dc3)

кстати я не знал этого про etcd. я дцумал что принимает "принявший" и потом уже они внутри синхронизируются. мало знаю про это. спасибо

моя косноязычна, сорри.

ТОгда были бы коолизии...

И нужно было бы изобретать механизм их разрешения

еще вопрос: на какой адрес должен адвертайзиться апи? бест праксис какой?

адрес по которому он доступен :)

ну это в обзем понятно.... но после фразы "не все поды могут (должны) покидать kube, для доступа к балансеру придется" но если я привяжу апи к "внешнему адресу" то в чем разница с просто nginx на том-же адресе/порте?

Это что промт перевод?

нет :)

Ну мой мозг поломатый после такой фразы)

я так плохо сказал?

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

немного оффтопик - у кого нибудь есть ссылка на чатик про ансибл?

@pro_ansible кажется

угадал!

спасибо)

https://deis.com/blog/2017/deis-to-join-microsoft/

Началось

Хана deis-у теперь. Закопают.

Да ну

Наоборот

Deis теперь может быть следующим слоем

Потому как Kubernetes не даёт полноценного Git Workflow

так и не должен :)

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

Потому как Kubernetes не даёт полноценного Git Workflow

Родина им OpenShift дала, нет, мы обмажемся хельмом, сверху повесим DIES, будем говорить, что кактус горький и колючий, но кроваво красный энтерпрайз не будем использовать)

не могу остановиться)

https://deis.com/blog/2017/deis-to-join-microsoft/

NOOOOO!

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

Почему ты так думаешь? Очень в этом сомневаюсь

Почему ты так думаешь? Очень в этом сомневаюсь

богатый опыт, увы

Во-первых, у Microsoft большие надежды и планы на Kubernetes. Люди уровня Brendan Burns не переходят в никуда. Во-вторых, даже если Microsoft и угробит разработку Helm внутри компании, из комьюнити Helm никуда не денется - это полноценный официальный проект Kubernetes.

Во-первых, у Microsoft большие надежды и планы на Kubernetes. Люди уровня Brendan Burns не переходят в никуда. Во-вторых, даже если Microsoft и угробит разработку Helm внутри компании, из комьюнити Helm никуда не денется - это полноценный официальный проект Kubernetes.

вы не понимаете, как это делается. Майкрософт будет постепенно вносить правки в работу хелма и в конце концов окажется, что пользоваться продуктом невозможно. И тогда он умрет. Комьюнити тут не поможет. В такой ситуации может помочь или форк или модератор, который будет пресекать попытки испортить продукт

Я-то прекрасно понимаю как это делается в нашем комьюнити.

Хелм - это не проект Майкрософта. Это проект Kubernetes. Нет репозитория microsoft/helm, есть kubernetes​/helm. И все стратегические решения, которые могут повлиять на Helm, будут приниматься не Майкрософтом. К счастью, я один из тех людей, которые имеют представление и влияние на подобные решения, так что я понимаю о чем я говорю.

Хелм - это не проект Майкрософта. Это проект Kubernetes. Нет репозитория microsoft/helm, есть kubernetes​/helm. И все стратегические решения, которые могут повлиять на Helm, будут приниматься не Майкрософтом. К счастью, я один из тех людей, которые имеют представление и влияние на подобные решения, так что я понимаю о чем я говорю.

хочется в это верить, но опыт убеждает меня в обратном. Будем смотреть.

Господа, помогите понять. Я хочу чтобы мой докер всегда обращался к приватному регистри. я в /etc/docker/daemon.json прописываю registry-mirrors: ["fqdn:port"] и... как только я делаю pull с моим тегом без указание регистри - оно не работает. если сделать pull с указанием регистри то работает

тож самое для кубернетеса. создал секрет с указанием сервера.... тот-же эффект

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

https://www.google.ru/search?q=docker+default+registry https://github.com/docker/docker/issues/11816 десять секунд на составление запроса к гуглу

docker в coreos перестал отвечать вообще что можно сделать? docker ps стакается

docker в coreos перестал отвечать вообще что можно сделать? docker ps стакается

учитывая философию корос - думаю - ресет

учитывая философию корос - думаю - ресет

а можно где-то в логах увидеть почему упал докер?

а у вас сислог не настроен?

а у вас сислог не настроен?

я не знаю лол

я не работал ни разу с coreos

объясните мне, пожалуйста, как проверять

Лучше в @docker_ru :)

Лучше в @docker_ru :)

они же тут coreos'ники

А, тебе эти люди нужны, тогда в @coreos_ru

учитывая философию корос - думаю - ресет

плюсую)

коллеги, есть ли тут кто-нибудь, кто использует ceph rbd как хранилище данных? Нужна консультация

@SinTeZoiD

Но вообще даже @ceph_ru есть :)

и ты там есть, ага)

и там даже есть те кто это делал

Шах и мат

и запихивал ceph в докер

И выпихивал?

И выпихивал?

а это не спрашивали

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

коллеги, есть ли тут кто-нибудь, кто использует ceph rbd как хранилище данных? Нужна консультация

Мы умеем, спроси @takama

сейчас споткнулся вот о такую ошибку: ProvisioningFailed storageclass.storage.k8s.io "slow" not found

при этом storageClass присутствует: apiVersion: storage.k8s.io/v1beta1 kind: StorageClass metadata: name: slow provisioner: kubernetes.io/rbd parameters: monitors: 172.16.0.1:6789,172.16.0.2:6789,172.16.0.3:6789 adminId: admin adminSecretName: ceph-secret-admin adminSecretNamespace: "kube-system" pool: kube userId: kube userSecretName: ceph-secret-user

claim: kind: PersistentVolumeClaim apiVersion: v1 metadata: name: myclaim spec: accessModes: - ReadWriteOnce resources: requests: storage: 10Mi storageClassName: slow

1.6?

да

там где-то синтаксис поменялся?

kubectl describe storageclasses slow