У нас под SDLC отдельный прямо биллинговый проект с постоянно создаваемыми и удаляемыми кластерами в которых стенды тестируются

нет ну если кластер именно для CI это ж другое дело

centos не пошел совсем, не рекомендую

Почему?

много нод? Заранее спасибо за ответы

https://cloudplatform.googleblog.com/2018/03/introducing-Agones-open-source-multiplayer-dedicated-game-server-hosting-built-on-Kubernetes.html (может было, ещ ене дочитал чат)

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

centos 7. Проблем было очень много, мне надоело воевать с мельницами. Ubuntu 16 LTS

лаборатория, 8 нод

а почему на дебиан 9? core os пробовали?

а почему на дебиан 9? core os пробовали?

стабильность + достаточно свежие версии ПО. Специфика лаборатории не позволяет мне использовать загрузку по сети, по этому CoreOS я использовать не могу

Спасибо! будем думать)

Но может есть автомагический путь

баш скриптом выгребать имена эндпоинтов из headless сервиса, вот только в случае statefull set под стартуют один за других и поэтому и в headless они будут один за другим регаться. Какой-то магии встроенной нет (да и как она может быть, ведь statefull set может динамически менять количество членов?), только в каком-то скрипте или самому приложению поллить этот headless сервис и менять конфиг

Спасибо! будем думать)

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

apiVersion: extensions/v1beta1 kind: Ingress metadata: name: kubernetes-dashboard namespace: kube-system annotations: ingress.kubernetes.io/ssl-rediret: "true" ingress.kubernetes.io/force-ssl-redirect: "true" kubernetes.io/ingress.class: "nginx" ingress.kubernetes.io/ssl-passthrough: "true" spec: rules: - host: ui.site.com http: paths: - path: /* backend: serviceName: kubernetes-dashboard servicePort: 80

для nginx не /* а / надо же (как в обычном нжиксе), это для GKE нужно звезду добавлять

Скоро 18.04 выйдет ещё

баш скриптом выгребать имена эндпоинтов из headless сервиса, вот только в случае statefull set под стартуют один за других и поэтому и в headless они будут один за другим регаться. Какой-то магии встроенной нет (да и как она может быть, ведь statefull set может динамически менять количество членов?), только в каком-то скрипте или самому приложению поллить этот headless сервис и менять конфиг

Скрипту ещё доступ давать на чтение апи кубера, ну нафиг

В общем прямщас оно работает

мне не нравится нестабильность убунты. По этому я хочу от нее отказаться в пользу дебиана

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

только учтите что в случае ЦПУ это CFS квота, поэтому может быть всякое в теории если есть какие-то процессы на хосте которые управляют CFS. Но в общем случае CFS должен дать столько ЦПУ сколько написано в requests или больше если есть свободные циклы

Скрипту ещё доступ давать на чтение апи кубера, ну нафиг

разве нельзя из headless service чреез dns выгрести адреса?

Не знаю

А зачем дашборды в конфигмапе хранить, они ж в базе хранятся?

как зачем? обычно их генерируют а не вручную накликивают

VolumeScheduling: Enable volume topology aware scheduling and make the PersistentVolumeClaim (PVC) binding aware of scheduling decisions. It also enables the usage of local volume type when used together with the PersistentLocalVolumes feature gate. в 1.9 появился такой feature gate и я как то сразу столкнулся с тем что моему поду на машине А выдали localstorage вольюм с ноды Б

может мне раньше везло, я хз

Скрипту ещё доступ давать на чтение апи кубера, ну нафиг

хардкод вс давать readonly доступ скрипту - ну тат каждый решает сам

ну можно и без api обойтись запросами к dns. я так понял что для headless должны адреса подов возвращаться

только это будет состояние на момент старта

хардкод норм =)

разве нельзя из headless service чреез dns выгрести адреса?

кстати, если количество нод динамически не меняется то можно вот такой скрипт юзать (я для монги юзаю) ## ## Generate statefulset peer hostnames in the form $(statefulset name)-$(ordinal) ## and from host names and knowing service name generate pod dns names. ## I.e. for replicas=3 pod hostnames will be: ## $(statefulset name)-0 ## $(statefulset name)-1 ## $(statefulset name)-2 ## and pod dns names will be: ## $(statefulset name)-0.$(service name).$(namespace name).svc.cluster.local ## $(statefulset name)-1.$(service name).$(namespace name).svc.cluster.local ## $(statefulset name)-2.$(service name).$(namespace name).svc.cluster.local ## ## Links: ## https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/#pod-identity ## https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/#deployment-and-scaling-guarantee ## https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/#srv-records ## function get_peers() { local stateful_set_name=${1:?} local service_name=${2:?} local replicas=${3:?} local my_dns_name=${4:?} local namespace_name=${5:?} local peers_dns_names="" for i in $(seq 0 $(($replicas - 1))); do local peers_dns_name="$stateful_set_name-$i.$service_name.$namespace_name.svc.cluster.local" if [[ "$peers_dns_name" != "$my_dns_name" ]]; then peers_dns_names="$peers_dns_names $peers_dns_name" fi done echo "$peers_dns_names" }

VolumeScheduling: Enable volume topology aware scheduling and make the PersistentVolumeClaim (PVC) binding aware of scheduling decisions. It also enables the usage of local volume type when used together with the PersistentLocalVolumes feature gate. в 1.9 появился такой feature gate и я как то сразу столкнулся с тем что моему поду на машине А выдали localstorage вольюм с ноды Б

о, прямо то что я вчера описывал для 1.4-1.5 😃

когда знаешь какие имена ожидаются, для statefulset, почему б и нет. ну такой хардкод тоже =)

только это будет состояние на момент старта

Ну первый сервис и должен подняться, чтобы хоть что-то вернулось

ну +- да, тут просто эти все переменные прокидываются у меня через ENV внутрь пода а генерируется хелмом

centos 7. Проблем было очень много, мне надоело воевать с мельницами. Ubuntu 16 LTS

А что за проблемы или уровня "как это делать в центосе не знаем"?

А что за проблемы или уровня "как это делать в центосе не знаем"?

многие инструменты деплоймента ломаются, чинить долго. Странное поведение докера (вплоть до крэша хоста). Странное поведение сети. Неделю я боролся – потом мне надоело. С CentOS я общаюсь с 4-й версии (как и с ее побратимом SciLinux), так что в принципе тыркать ее умею. Просто конкретно центось конкретно 7-я с докером не особенно дружить, это надо иметь ввиду

centos не пошел совсем, не рекомендую

Простите не пошёл для k8s?

Почему у меня дружит при нагрузке ~30 подов/нода?

дефолтно оно всё дружит, тут скорее вопрос что за докер, что за нагрузки, номера багов

сейчас у меня 10 форкеров 3 мастера

30 подов/нода

Простите не пошёл для k8s?

у меня – не пошел. Я же писал выше – надо пробовать.

Cenot OS7.3

Полёт в штатном режиме. на работы по выхам ещё ниразу не ездил. полёт длится уже месяцев 9

Я его да же с 1.5.2 до 1.9.3 обновил в полёте без даун тайма.

впечатляет. а как etcd обновили?

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

Сначала было на —compabilty

а потом перекинул базёнку и переключил api

-2 минуты жизни кластера-)

то есть даунтайм все-таки был. А то я уж совсем удивился

А вы etcd в кубе что ли держите?

Народ, посоветуйте какой дистриб os лучше использовать под разворачивание кубика... на данный момент под 1.9

Свежие ядра с ништяками в CoreOS и ProjectAtomic

в 18.04 тоже свежее ядро будет %)

многие инструменты деплоймента ломаются, чинить долго. Странное поведение докера (вплоть до крэша хоста). Странное поведение сети. Неделю я боролся – потом мне надоело. С CentOS я общаюсь с 4-й версии (как и с ее побратимом SciLinux), так что в принципе тыркать ее умею. Просто конкретно центось конкретно 7-я с докером не особенно дружить, это надо иметь ввиду

полет в нескольких продакшенах - все дружит

в debian 9 - 4.9.0, вполе свежее

можем устроить опрос, как вариант :)

полет в нескольких продакшенах - все дружит

начиная с какой версии центоси?

стабильность + достаточно свежие версии ПО. Специфика лаборатории не позволяет мне использовать загрузку по сети, по этому CoreOS я использовать не могу

Без сети тоже можно же

с докером - с 7

в 7.1-7.3 было грустно

7.2

а, вру, даже 7.1

и какая там версия ядра и какое хранилище под докером?

ядро какое шло рядом, то и было

хранилища - оверлей

потом dm-thinpool

у нас было всё грустно до перехода на ядро из elrepo

но это без кубов все

чистый докер

кубы как бы ваще пофигу

у нас было всё грустно до перехода на ядро из elrepo

бомбический факт!

ну после перехода на ядро из elrepo тоже было грустно, но по-другому

говорят в 7.3+ что-то бэкпортили в ядро и стало норм

в debian 9 - 4.9.0, вполе свежее

В последних, xfs copy on write вывели из экспериментального состояния, с последними изменениями в docker vfs драйвере должна быть бомба - самый лучший, самый простой, самый надежный, самый эффективный и самый быстрый storage driver

vfs ftw

В последних ядрах, 4.16 кажется

а его кстати задокументировали?

а сломаный tar в xfs + overlayfs2 починили уже?

он был недокументированым раньше

а сломаный tar в xfs + overlayfs2 починили уже?

Ну если у вас номер баги есть, можете и сюда кинуть и сами заглянуть проверить :) вы на центосе пробовали? Там требования к xfs же есть, , которые только в 7.4 бэкпортнули

я спрошу у Максима, он на этом круто обжегся

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