вроде бы больше ничего он сверху не делает, только генерирует yaml файлы и из апдейтит

чет я перезапустил etcd 3.2.4 и получил на одной из трех нод: 2018-03-14 12:02:08.120838 I | etcdserver: recovered store from snapshot at index 500005 2018-03-14 12:02:08.124146 I | mvcc: restore compact to 461605 2018-03-14 12:02:08.128636 C | mvcc: store.keyindex: put with unexpected smaller revision [{4 0} / {4 0}] panic: store.keyindex: put with unexpected smaller revision [{4 0} / {4 0}]

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

и перед рестартом бэкапить =)

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

не, для изменения некоторых параметров StatefulSet'а надо пересоздание этого сета

не вспомню щас про какие параметры было

либо может это я что-то не так делал

да, я тоже сталкивался, но это ограничение куба а не хелма

да я не предъявляю претензии к хелму щас

мне интересно есть ли инструмент который умеет это обрабатывать

Всем привет, а есть какие-нибудь советы как должны быть распределены limit\request ресурсов? Например, request должен быть равен или в два раза меньше чем limit и т.д.

зависит от твоего приложения

и от твоих ресурсов

и вообще ап ту ю

Как хотишь. ТОлько учти, что request это ещё и вес приложения при конкуренции

https://kubernetes.io/docs/tasks/administer-cluster/out-of-resource/#node-oom-behavior вот это ещё стоит прочитать

мне интересно есть ли инструмент который умеет это обрабатывать

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

Спасибо

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

да хрен его знает :)

у меня нет идей про то как должен работать подобный инструмент

Ну он же stateful...

ну это же будет какой-то треш и угар

опа и удалит мне этот инструмент стейтфулсет? и хорошо если еще вольюмы не автоматом удалятся

ну если мне такой параметр так и так менять, то вариантов всё равно немного

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

а не узнать вдруг в результате апдейта что стейтфулсет пересоздался а PV claim template был кривой и вольюмы старые пропали

не ну проблемы понятны и очевидны конечно

Хы

А кубер крутой-)

Пофиг что докеру прописан add-registry всё равно полезу за образом на docker.io

да же плевать что образ pull командой уже давно выкачен с локалького реестра, пофиг мне нужен docker.io

Либо гони аутентификацию

Интерсно что курили разрабы

проблемы плохого CRI бэкенда вряд ли относятся к куберу

Это не от бекэнда

как дела, чятик?

Это kubelet делает не pull <name> , а pull docker.io/<name>

Кто его просит указывать префикс не понятно.

и едиственный спсоб избежать захренчить ему секере docker-registry

проблемы плохого CRI бэкенда вряд ли относятся к куберу

Это явно отголосок вот этого https://github.com/kubernetes/kubernetes/issues/57427

Это kubelet делает не pull <name> , а pull docker.io/<name>

kubelet так делает томущо находит .docker/config.json

плохо сконфигуренный докер будет лезть на docker.io при любом удобном случае

ну при прямом pull он такого не делает)

если сказать docker pull он всё нормально видит и не рыпается до docker.io

если сказать docker pull он всё нормально видит и не рыпается до docker.io

видимо где-то креденшиалзы к регистри видны только докеру, но не кубелету

Если кому интересно, storageos не взлетел на scaleway. По словам разраба какие-то проблемы с nbd вкомпиленным в ядро и centos.

Народ, а автокомплит у kubectl умеет подставлять имена подов, ns, pvc, sc...?

Неймспейсы точно может

Народ, а автокомплит у kubectl умеет подставлять имена подов, ns, pvc, sc...?

Умеет

А как правильно мапить папку с конфигами которые внутри содержат другие папки? типа ├── config │ ├── app1 │ │ └── a │ │ └── b │ │ └── c │ ├── app2 │ │ └── a │ │ └── b │ │ └── c │ └── app3 │ └── a │ └── b │ └── c

т.е. как запихнуть в configmap один файл - понятно

как запихнуть папку с файлами - понятно

ну то есть конкретно меня интересует как вы конфиги nginx засовываете в куб. билдите контейнер с ними или pv монтируете? или configmap?

subpath

а можешь ткнуть ссылкой на где почитать?

https://kubernetes.io/docs/concepts/storage/volumes/#using-subpath

Блин, а я обрадовался что можно фс дерево маунтить :(

ну это опять же через pv решается

но тоже полезно, спасибо

привет всем, а чем удобно деплоить k8s на bare-metal?

bykva , используешь в контейнере такое: volumeMounts: - name: projected-config-mount mountPath: {{ .Values.nginx.configPath }} readOnly: false а потом описываешь этот volume: volumes: - name: projected-config-mount projected: sources: - configMap: name: {{ .Release.Name }}-something items: - key: key_in_configmap path: some/relative/path тоесть тебе нужен projected https://kubernetes.io/docs/concepts/storage/volumes/#projected я не туда дал ссылку сначала

но в любом случае каждая директория с файлами - отдельный configmap?

Кто нибудь Romana использует?

Чет я никак не найду как изменить network topology

но в любом случае каждая директория с файлами - отдельный configmap?

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

но в любом случае каждая директория с файлами - отдельный configmap?

нет. ты можешь ключи распихать как тебе удобно

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

да, в этом. тогда ясно, спасибо.

я логически объединял в configmaps тех, кто на одном уровне должен быть и потом с range их запихивал по нужным path в шаблоне helm

вообще весь конфиг nginx можно в один файл уместить

ingress так и делает

по-умолчанию

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 вольюм с ноды Б

заапдейтил свою лабу через kubespray из master, получил local-volume-provisioner v2 и feature gates PersistentLocalVolumes=True,VolumeScheduling=True,MountPropagation=True и теперь local-storage класса вольюмы выделяются подам на той же машине, куда под зашедулился. просто праздник какой то

правда на ровном месте etcd сломался от перезапуска и в calico изменилось именование нод - стали по fqdn. пришлось удалить ноды из calico конфигурации и все стало на места

для куба это норма 😃

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

да я удивился если честно что все прошло гладко =)

Это был минорный апгрейд, верно?

я из tag v2.4.0 до этого раскатывал. релизов свежее нет пока =) прост переживал что из мастера все разнесет

вообще кажется ничего нового не получил кроме local volume provisioner