вот скоро возобновим эксперименты с кубером, пока вариантов кроме deb 9 нету

мне тут на днях советовали coreOS и typhoon

https://github.com/poseidon/typhoon

а на убунте что не так было (вы 16.04 использовали же ?)

coreos мне вообще кажется странным

периодическая течка памяти, кернел паники и т.д.

может конечно руки не от туда, но все же

тоже бывали паники

периодическая течка памяти, кернел паники и т.д.

постоянно на убунте

вот вот

пока так и не удалось победить их, тоже думали о переходе

на дебе 9 эти проблемы решились ?

ну поскольку инфраструктура на ubuntu была еще не большой, решили пока не поздно сменить )

на дебе 9 эти проблемы решились ?

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

Я вот упоролся, и хочу сделать некий аналог aws. По этому уже запилили OpenNebula, куда я запилю темплейт coreOS в которых буду вертеть kubernetes. Но кошерно ли вертеть кластер внутри кластера?

coreos вообще странная тема, получается продакшен окружение будет всегда отличаться от дев

ну и после всех страданий с докером, точно будем без него начинать, на cri-o

@podmogov хосты без кубера (кое где даже с докером, но не много) у нас тоже стабильно себя ведут, а вот в связке куб+докер +контейнеров побольше (штук 60-70 на хост в среднем) уже начинаются проблемы

тоже возлагаю надежды на cri-o, смотрю у них уже пакеты для разных осей появились, не нужно руками собирать

буквально неделю назад на гитлаб раннере, AUFS в один момент превратилась в тыкву ) так что для нас докер мертв )

А зачем вы используете aufs? Уже давно рекомендуется overlay2

давно использовали )

до рекомендаций )

ну вот тоже на overlay2 надежда, в дебиане 9 она вроде дефолтом идет

ну вот тоже на overlay2 надежда, в дебиане 9 она вроде дефолтом идет

а какая версия докера кстати была на паникующих хостах ?

давно это было, точно до их смены версионирования

типа 1.10 или типа того

понятно, у нас с 17.03 такие же проблемы

похоже что самая стабильная 1.13

нас добило в тот момент, что кубер отказался запускаться с 17* версией, объясняя это тем что не могу распарсить версию докера )

1.8+ работает с 17.03 докером

Господа, есть следующая задача: необходимо передавать в pod в качестве переменной окружения его порядковый номер (некий instanceId), при этом сохраняя этот номер при пересоздании pod'а. Подскажите, это вообще реально реализовать? В какую сторону копать? Пример для иллюстрации: создаем deploy из трех pod'ов, при этом каждому из них передается переменная окружения instanceId(1,2 и 3 соответственно). В случае, если какой-то из pod'ов был пересоздан, instanceId у него сохраняется.

Господа, есть следующая задача: необходимо передавать в pod в качестве переменной окружения его порядковый номер (некий instanceId), при этом сохраняя этот номер при пересоздании pod'а. Подскажите, это вообще реально реализовать? В какую сторону копать? Пример для иллюстрации: создаем deploy из трех pod'ов, при этом каждому из них передается переменная окружения instanceId(1,2 и 3 соответственно). В случае, если какой-то из pod'ов был пересоздан, instanceId у него сохраняется.

передавать его в config-map ?

Господа, есть следующая задача: необходимо передавать в pod в качестве переменной окружения его порядковый номер (некий instanceId), при этом сохраняя этот номер при пересоздании pod'а. Подскажите, это вообще реально реализовать? В какую сторону копать? Пример для иллюстрации: создаем deploy из трех pod'ов, при этом каждому из них передается переменная окружения instanceId(1,2 и 3 соответственно). В случае, если какой-то из pod'ов был пересоздан, instanceId у него сохраняется.

stateful set?

etki - ну можно custom entrypoint который выцепит из АПИ все что ему нужно а потом запустит под

Удобный - ksonnet. Эдакий jq на стероидах с готовыми объектами под все сущности кубернетеса. От всей души советовать не могу, т.к. пока сам шишки набиваю, но выглядит хорошо

дайте знать плз, когда перейдете в фазу enjoy (или hate)

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

вот допустим есть микросервис, который конектится там к dynamodb. Для этого ему нужны специфические iam права. Генерим ключи, запихиваем в k8s секерты. Не прикольно. Есть варианты чтобы сделать ротацию iam ключей (разных для каждого микросервиса) на регулярной основе, и делать это без даунтайма?

вот допустим есть микросервис, который конектится там к dynamodb. Для этого ему нужны специфические iam права. Генерим ключи, запихиваем в k8s секерты. Не прикольно. Есть варианты чтобы сделать ротацию iam ключей (разных для каждого микросервиса) на регулярной основе, и делать это без даунтайма?

vault?

в теории да. На практике делали через него такое? Плюс дополнительная потенциальная SPOF и боль.

minikube боль

прикрепите кто-нить эти великие слова

буквально неделю назад на гитлаб раннере, AUFS в один момент превратилась в тыкву ) так что для нас докер мертв )

А ничего что в cri-O почти все из докера ? Ну было. Надо сейчас сделать бы diff на overlay2 посмотреть, хоть что-то свое появилось ли

А зачем вы используете aufs? Уже давно рекомендуется overlay2

а там tar починили уже? Максим из Марсиан крупно на этом прокололся

Всем привет! Настраиваю доступ из куба до приватного docker registry, но получаю ошибку скачивания контейнера. Исходные данные такие - в реджистри можно авторизоваться как по логину паролю, так и по сертификату. Если я с машины где стоит куб делаю docker pull - все работает, скачивается и запускается(авторизация через сертификаты). Если я делаю по статье https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/ - получаю ошибку скачивания.

Быть может нужно как то этот сертификат в кубер впихнуть, сейчас он лежит в etc/docker/certs.d/{url registry}/cert.cert

а что за ошибка?

логи кублета почитай

и что за сертификат лежит в etc/docker/certs.d/{url registry}/cert.cert

Это CA pki? или сертифкат регистра?

вторая часть лежить на docker registry, и можно пулить без ввода паролей

но как это все запихать в кубер я не понимаю( он выдает такую ошибку:

а там tar починили уже? Максим из Марсиан крупно на этом прокололся

напомните, что с ним было?

но как это все запихать в кубер я не понимаю( он выдает такую ошибку:

???

Ты лог Кублета посмотри!

если можешь, потому как там написана вся соль

ок

Насколько я понимаю, если нет отдельного конфига на пулл, то кублет даёт просто команду docker pull оставляя вопросы авторизации на докере

в мануалах написано что ему нужно секрет создать

я создал, но там на примере авторизации с паролями

имхо удали нафиг секрет, и позволь докеру самому разобраться с аутентификацией

Мож кто ещё подскажет...

к гитлабовсккому регистри например надо дважды серкрет создавать, первый раз к fqdn гитлаба, второй раз к fqdn регистри

а как делать docker login с сертом? в хелпе про это чот ниче не видно docker login --help Usage: docker login [OPTIONS] [SERVER] Log in to a Docker registry Options: -p, --password string Password --password-stdin Take the password from stdin -u, --username string Username

в конфиг json добавить tlscert

к гитлабовсккому регистри например надо дважды серкрет создавать, первый раз к fqdn гитлаба, второй раз к fqdn регистри

Это как? Зачем докеру знать про сам гитлаб, а не его регистри?

Все получилось, я забыл положить сертификат на nod'ы, сейчас положил - все ок. Работает даже без использования секрета, только не сертификатах.

Регистри редиректит сам на страницу гитлаба

imagePullSecret то один. Я с одним живу 100% работает

Ну у меня не кубернетес, а openshift там вот такой воркараунд необходим

Ванильным кубернетесом пользовались? Как opeshift по сравнению?

Ванильным пользовался 1.2 где то и не на полную катушку, openshift.... да явно ряд стабильностей привнес, лишил сложных выборов это как плюс и минус, добавил кучу нон критикал багов при инсталяции которые надо победить, вообще этот smartclayton на самом деле тупой, своих наработок в сравнении с 1.2 изкаробки, RBAC уже давно, регистри, дополнитейтный in-tree DeploymentConfig, контроллер который создает и версионирует деплойменты, ImageStream / собственный ci/cd pipeline, debug контейнеры и прочее, цикл разработки не такой частый, а сейчас еще и оттает жутко

ах, да вместо ingresscontrolle nginx - haproxy и f5

Прикол в том что 1.9 уже оеализовало почти весь стак OpenShift)

Ну а регистри и ci/cd pipe line не задача оркестрации

Ну и если OpenShift Enterprice то есть большой вендор, которого можно пинать и все 0-day и Mission Crititcal свалить на него -) ЧТо для Эксплуатационных подразделений оч важно

Ну а регистри и ci/cd pipe line не задача оркестрации

Может быть ии так. Но вот иметь монстра который умеет все и всех я б хотел

Она в OO весьма странная, реализована на их s2i коде

ну и хорошо работает только с продуктами RHEL-)