ставлю на виртуалке, так что пробовал откат и заново с разными параметрами helm init ***. Всегда один результат

sudo cat /sys/class/dmi/id/product_uuid этот айди должен быть уникальным на каждой ноде

sudo cat /sys/class/dmi/id/product_uuid этот айди должен быть уникальным на каждой ноде

да, он уникальный... вот думаю может быть дело в RBAC... как-то он ограничивает доступ из namespace kube-system в namespace default

я ставил через kubespray, и заливал через хелм без проблем и откатывал релизы

ок, тогда попробую весь кластер поставить через kubespray... хотелось официальными средствами, чтобы потом избежать проблем при обновлении

helm ставили тоже скриптом https://raw.githubusercontent.com/helm/helm/master/scripts/get?

потом helm init без дополнительных параметров?

кстати, это пробовали? https://stackoverflow.com/a/46688254/1262176

да, пробовал... так же

helm ставили тоже скриптом https://raw.githubusercontent.com/helm/helm/master/scripts/get?

я на маке, и ставил через brew install kubernetes-helm

ясно... спасибо за помощь... пошел разворачивать кластер через kubespray

удачно все развернуть

да, пробовал... так же

https://github.com/helm/helm/issues/4020#issuecomment-390472404

тут неожиданно понял что метрика container_memory_working_set_bytes содержит в себе memory.stat total_inactive_file, да вообще все содержит в себе =) я то до этого думал что fs cache глобальный, а он оказывается в рамках cgroup живет. кто нить алерт по приближению к memory limit пилил? так получается что container_memory_usage_bytes - container_memory_cache похоже соответствует тому набору ram, за которым нужно следить.

немного не в тему этого чата вопрос :)

немного не в тему этого чата вопрос :)

но его тут уже обсуждали, кстати)

ну это скорее в церковь метрик, чем про кубернетис

эт метрики кубера, вопрос его лимитов

это метрики из cadvisor'а

они не кубер-специфичны

ага, а он часть kubelet

ну это скорее в церковь метрик, чем про кубернетис

Согласен, но тем не менее именно с таким вопросом я уже офтопил тут некоторое время назад. @f84anton можешь глянуть через поиск, может страое обсуждение поможет.

ага, а он часть kubelet

а библиотека prometheus-client - часть cadvisor, значит?

ну это скорее в церковь метрик, чем про кубернетис

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

вот именно!

Согласен, но тем не менее именно с таким вопросом я уже офтопил тут некоторое время назад. @f84anton можешь глянуть через поиск, может страое обсуждение поможет.

алерт по ram в итоге на что ориентируется?

У меня - на usage

алерт по ram в итоге на что ориентируется?

container_memory_usage_bytes - мутная метрика, в двух словах. В мануале по cgroup пишут дословно так: If you want to know more exact memory usage, you should use RSS+CACHE(+SWAP) value in memory.stat(see 5.2).

Привет. А тут есть те, кто юзает local-provisioner?

я

Есть вопрос. 95% времени всё работает ОК. Но иногда pvc из стейтфулсета начинают роутиться на одну и ту же ноду, и соответственно podы по affinity не могут запуститься. В логах все как бы как обычно, ничего такого, просто допустим 12 pvc из 15 ушли на одну ноду. Как такого избегать и почему такое может случаться вообще?

*при создании стейтфулсета

local-provisioner же не создает сам pv

он как раз создает pv (у меня создает )))

*при создании стейтфулсета

в предыдущих версиях было поведение, когда шедулинг не учитывал расположение pv. потом нужно было feature gate включать чтобы шедулер сначала нашел где pv находится

он как раз создает pv (у меня создает )))

я чет упустил, каким образом?

и допустим на каждой ноде висит по 10 свободных pv. Но при создании statefulseta pvc решает все pvc для парочки нод отправить допустим на четвертую

запускаются поды провижнера, смотрят директорию, находят точки монтирования, создают PV

У меня - на usage

в контейнере писали здоровенный файл. процессы памяти жрали мало, но total_inactive_file вырос до лимита. usage не плох, конечно, но нафига алертить когда файловый кэш съедает рам

в предыдущих версиях было поведение, когда шедулинг не учитывал расположение pv. потом нужно было feature gate включать чтобы шедулер сначала нашел где pv находится

у меня 1.10, щас посмотрю, а какой параметр feature gate не помнишь случайно?

запускаются поды провижнера, смотрят директорию, находят точки монтирования, создают PV

local volume provisioner? он же постоянно должен быть запущен

ну это я выразилась не очень. Они постоянно и работают, и ищут точки монтирования

https://github.com/kubernetes-incubator/external-storage/tree/master/local-volume

здесь все полностью описано

Creating a StorageClass (1.9+) To delay volume binding until pod scheduling and to handle multiple local PVs in a single pod, a StorageClass must to be created with volumeBindingMode set to WaitForFirstConsumer.

в 1.9 требовалось такое KUBE_FEATURE_GATES="PersistentLocalVolumes=true,VolumeScheduling=true,MountPropagation=true"

в 1.10 уже такого не просят

блин, дичь написала

ок, local volume provisioner превращает точки монтирования в /mnt/disks в pv. так ведь? и это забота админа намутить точек монтирования

на какой машине смонтировано, там pv и создастся

Кто знает если у меня нода ушла в даун - когда сменится node.podcidr?

1) я сделала точки монитрования, всё ок. Кубер нашел их. Допустим на 4 серверах 2) я запустила создание стейтфулсета с pod antiaffinity и 5pvc 3) кубер решил отправить все pvc только на ноду 01 и 04 (или любые другие, тут без разницы) 4) в стейтфулсете должно быть три пода. в итоге могут запуститься только два, PVC для которых ушли на 01 и 04.

Кто знает если у меня нода ушла в даун - когда сменится node.podcidr?

эт все на откуп cni насколько я понял

то есть нужно еще pvc affinity или что-то в этом роде, а вот тут уже не понятно

эт все на откуп cni насколько я понял

я почему-то думал что он берет то что прилетело на ноду

часть из этого будет в 1.12 емнип - https://github.com/kubernetes/kubernetes/pull/67556

то есть нужно еще pvc affinity или что-то в этом роде, а вот тут уже не понятно

local volume provisioner эт частный случай для неудачников на bare metal. k8s не предполагает что pv может быть привязан к ноде

я почему-то думал что он берет то что прилетело на ноду

я про calico

вроде полноценные клаудпровайдеры умеют это лучше, local вряд ли приоритет

local volume provisioner эт частный случай для неудачников на bare metal. k8s не предполагает что pv может быть привязан к ноде

не неудачники, а мастера костылей ?

маунтить папку в папку дешевле облака ?

Костыли... Вот у нас ща - костыли... В кубернетес на проде не готовы, а сварм уже пришлось развалить...

local volume provisioner эт частный случай для неудачников на bare metal. k8s не предполагает что pv может быть привязан к ноде

На берметал можно rook запустить :)

Костыли... Вот у нас ща - костыли... В кубернетес на проде не готовы, а сварм уже пришлось развалить...

swarm сам по себе разваливается, даже если не трогать...

не неудачники, а мастера костылей ?

не согласен, какая абстракция может быть быстрее отсутствия абстраций?

swarm сам по себе разваливается, даже если не трогать...

Когда его поднимали, на эти грабли ещё не наступили...

Когда его поднимали, на эти грабли ещё не наступили...

я как поднял, ещё некоторое время рассказывал, что нафиг учить k8s, если swarm раз два и поднялся... пару месяцев назад выдохнул с облегчением, когда его убил.

А боль была с самого начала почти. Когда нельзя было на localhost забиндить сервис, только 0.0.0.0

И в iptables он лез так, что закруть доступ снаружи у меня не вышло.

Не, мне в этом смысле было проще - с сетью заранее подумали, как правильно давать/не давать доступ. Точнее, соорудили нечто на nginx... Там в другом месте проблемы были...

На берметал можно rook запустить :)

тут вопрос такой, этот сервис потребует ресурсы, и не только cpu\ram. с производительностью непонятно. локально писать на диск всегда будет лучше. ну и большинство stateful умеет свои данные сами реплицировать, подымаешь реплику на другой ноде, настриваешь бэкапинг и вроде как все норм

#whois ▫️Какой у вас проект или где работаете? Web приложения на dotnet core и angular6, ▫️В чём вы специалист? web frontend/backend, dotnet/java, angular/vue, android ▫️Чем можете быть интересны или полезны сообществу? Стараюсь задавать обдуманные вопросы ▫️Чем интересно сообщество вам? Активно продвигаю тему k8s и контейнеризации в компании, подстматриваю тут best practices ▫️Откуда вы? Тула ▫️Как узнали про группу? не помню, гуглил доки, искал что-то и наткнулся

На берметал можно rook запустить :)

я бы и не против rook намутить, но разве в него посадишь базу бд на 600гб которая итак почти упирается в диск по iops?

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

если bare metal и нет внешнего стораджа, то, вероятно, это единственный вариант

У меня распределенный кластер k8s между континентами. Как красиво сделать так, чтобы ingress ходил на поды через сервис, которые в том же датацентре?

хостнейм один и тот же

омг

сделать разные кластеры - не вариант?

не хочется к этому прибегать

как-то taint можно притянуть сюда?

Почему все обсуждают local provisioner? Ведь local-provisioner, local-volumes и nodeAffinity для persistentVolumes - это три разные вещи. Мне не нравится local-provisioner, но я активно использую nodeAffinity для persistentVolumes, при этом смысла в local-volumes я вообще не понимаю, т.к. local-volumes - это тоже самое что и hostPath с nodeAffinity и type: Directory

я бы и не против rook намутить, но разве в него посадишь базу бд на 600гб которая итак почти упирается в диск по iops?

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

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

размывать иопсы и по local volumes можно, профита будет все равно больше чем от цефа

Почему все обсуждают local provisioner? Ведь local-provisioner, local-volumes и nodeAffinity для persistentVolumes - это три разные вещи. Мне не нравится local-provisioner, но я активно использую nodeAffinity для persistentVolumes, при этом смысла в local-volumes я вообще не понимаю, т.к. local-volumes - это тоже самое что и hostPath с nodeAffinity и type: Directory

не совсем точно. local volumes из local volume provisioner отличаются от hostPath во первых ты можешь управлять политикой, разрешить многократно монтировать или нет, грубо говоря во вторых ты увидишь метрики, например kubelet_volume_stats_capacity_bytes в третьих ты всетаки изображаешь будто бы у тебя нормальный провижонинг, можешь съехать на такой в случае чего в четвертых local volume provisioner может очищать volume после удаления pvc, как это делают взрослые дяди

кроме того он на порядок безопаснее hostPath

не совсем точно. local volumes из local volume provisioner отличаются от hostPath во первых ты можешь управлять политикой, разрешить многократно монтировать или нет, грубо говоря во вторых ты увидишь метрики, например kubelet_volume_stats_capacity_bytes в третьих ты всетаки изображаешь будто бы у тебя нормальный провижонинг, можешь съехать на такой в случае чего в четвертых local volume provisioner может очищать volume после удаления pvc, как это делают взрослые дяди

> управлять политикой, разрешить многократно монтировать или нет, грубо говоря > ты увидишь метрики, например kubelet_volume_stats_capacity_bytes спасибо, хоть кто-то дал внятный ответ > local volume provisioner может очищать volume после удаления pvc, как это делают взрослые дяди того же самого можно добиться и с hostPath (используя finalizers)

кроме того он на порядок безопаснее hostPath

почему? - обоснуйте

почему? - обоснуйте

selinux, например

использование selinux автоматически делает вашу систему безопасной!

ну и всякие вещи типа access control, хотя бы по gid

ну и всякие вещи типа access control, хотя бы по gid

А оно разве не kubelet'ом обрабатывается после маунта и непосредственно перед запуском пода - т.е. независимо от бэкенда?

Я лично не использую selinux и access control для волюмов, так что точно сказать не могу, но мне интересно, может вы в курсе?

А оно разве не kubelet'ом обрабатывается после маунта и непосредственно перед запуском пода - т.е. независимо от бэкенда?

макнт не причем, дело в пермишшенах кому писать а кому нет https://kubernetes.io/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#access-control

макнт не причем, дело в пермишшенах кому писать а кому нет https://kubernetes.io/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#access-control

> When a Pod consumes a PersistentVolume that has a GID annotation, the annotated GID is applied to all Containers in the Pod in the same way that GIDs specified in the Pod’s security context are. Every GID, whether it originates from a PersistentVolume annotation or the Pod’s specification, is applied to the first process run in each Container. А, ну так это же и для любых других PV работать будет, в том числе и для hostPath

я имею ввиду если оформить hostPath как persistentVolume, а не цеплять напрямую в под