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

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

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

@pro_ansible кажется

угадал!

спасибо)

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

Началось

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

Да ну

Наоборот

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

Потому как 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?

да

ERROR: S client not available

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

kubectl describe storageclasses slow

они переезжали с аннотаций на ключи полноценные, может переименовали чего.

root@app1 ~ # kubectl describe storageclass slow Name: slow IsDefaultClass: No Annotations: <none> Provisioner: kubernetes.io/rbd Parameters: adminId=admin,adminSecretName=ceph-secret-admin,adminSecretNamespace=kube-system,monitors=172.16.0.1:6789,172.16.0.2:6789,172.16.0.3:6789,pool=kube,userId=kube,userSecretName=ceph-secret-user Events: <none>

вообще динамический провизионинг работает если rbd утилита присутствует там, где apiserver

она присутсвует, это точно

apiserver запущен как сервис на хосте или в статическом поде?

сервис.

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

он тоже не работает, но иначе. В какой момент должен создаваться rbd image? на pv, claim или при утилизации?

смотреть так же полезно с помощью describe сам claim

kind: PersistentVolume apiVersion: v1 metadata: name: rbd-prometheus-volume labels: kubernetes.io/cluster-service: "true" spec: capacity: storage: 8Gi accessModes: - ReadWriteOnce rbd: monitors: {% for item in k8s_storage_hosts %} - {{ item }}:{{ ceph_monitor_port }} {% endfor %} pool: rbd image: prometheus user: admin keyring: /etc/ceph/ceph.client.admin.keyring secretRef: name: ceph-secret fsType: xfs readOnly: false persistentVolumeReclaimPolicy: {{ k8s_volume_reclaim_policy }} ---

вот намирмер для такого имидж создается заранее и форматируется xfs

rbd create prometheus --size 8G --pool rbd --image-feature layering rbd map prometheus mkfs.xfs /dev/rbd/rbd/prometheus rbd unmap /dev/rbd/rbd/prometheus

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

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

но убедиться - проверить что все работает лучше на нём

значит надо создать для тестов и отформатировать, потом смотреть что с динамикой

Извиняюсь, мне нужно идти, надеюсь чем-то помог :)

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

по идее должен сам при создании pvc, но там сейчас есть проблема, если версия ceph более или менее свежая она выдает предупреждение при попытке создать rbd c image-format=1, а кубер считает это ошибкой создания. image-format 2 пока не поддерживается, но уже есть нужный патч, который пока не вошел ни в один из релиов

как то так

https://github.com/kubernetes/kubernetes/commit/e4ec433470bb8d23e750a477d22657e3a4a53b83

https://habrahabr.ru/company/flant/blog/326414/

Я пытаюсь из CI напрямую helm использовать, но не понятно, как безопасно к tiller серверу подключиться. Есть идеи? Кто-то пытался?

Ключевой момент - не использовать k8s credentials

ingress для него c TLS

И TLS клиент серт?