Продолжая тему helm vs kubectl apply, сделал скрипт, запускающий helm template (не хочется тратить время на переделывание шаблонов под что бы там ни было), собирающий yaml, далее запускающий хук джобы оттуда через обычный kubectl apply, далее статусчеки, соответственно я теперь наглядно вижу прогресс выполнения хука, далее удаление хука kubectl delete, и далее применение всего остального через kubectl apply. Пока что работает без нареканий. Само собой, автовычищения при серьёзных шатаниях шаблонов нет. И был ещё подводный камень с тем что конфигмапы надо перед хуками разворачивать. Появилась возможность снести тиллер, не морочиться с релизами и как-то в целом всё побыстрее стало.

И ещё вопрос хотел задать. Чем отличается вручную/терраформно настроенный ELB + Service Type NodePort от Service Type LoadBalancer? Внутренняя реализация такая же подозреваю?

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

Хорошая политика. Упрощает жизнь

то есть тебе нравиться идея с тем чтобы namespace в какой то мере был независим?

https://github.com/kubernetes/kubernetes/issues/72257

А может тогда подскажите как ревизии имаждей в гитлабе чистить?

Должно быть больно. Ваше?

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

https://github.com/kubernetes/kubernetes/issues/72257

я надеюсь он тролил факт того, что "программеры решили"

Storage как раз важно какой. Локальная ФС обычно используется эксклюзивно и код может писаться соответственно, тогда как в S3 ничего кроме положить ключ/прочитать ключ и нет и соответственно 2 инстанса registry вполне могут плохо работать с одним диском, но хорошо с одним S3 бакетом. (Сам не проверял)

мощная вещь, " As a result, images are removed but their data (the image layers) are still stored on disk"

Ну так gitlab-ctl registry-garbage-collect снесет остальное

Всем привет! Мы запускаем корпоративный курс обучения основам работы с Kubernetes для системных инженеров и администраторов. Мы изучим концепты Куба, научим разворачивать свой кластер, запускать и мониторить приложения. Можем провести курс у нас или у вас в офисе, график обсуждается. Если есть особые пожелания по курсу, можем дополнить программу. Буду рад ответить на ваши вопросы! https://kubernetes-course.exonlab.ru

Напарывался с логами эластик, перешел с hostPath на local volume и поимел проблем

Научите как лайв миграцию подов делать?

Научите как лайв миграцию подов делать?

Научите как лайв миграцию подов делать?

это что вообще?

Научите как лайв миграцию подов делать?

Мечты о CRIU в кубере

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

А подробнее можно?

Пушим имаджи с тэгом $CI_COMMIT_REF_NAME. Каждую ночь по крону запускается gitlab-registry-cleanup, затем gitlab-ctl registry-garbage-collect. Никаких проблем с удалением устаревших имаджей не испытываем.

Ничего интересного юзал эластик +nodeSelector +hostPath - все было норм, решил попробовать localVolume - так как он привязывается к хосту, что боле логично, в любой непотятной ситуации я люблю дропать ноды, не помню толььи после дропа, толи после редеплоя - пропала часть логов

Кто в этой схеме тег удаляет и как оно знает, что тег не используется?

Да я серьезно, что все думают, что я шучу :) если б под с базой при kubectl drain переезжал на другую ноду без единого разрыва я б точно пользовался

Proxmox так умеет, мигрировать сторадж, вместе с LXC контейнером

https://github.com/kubernetes/kubernetes/issues/72257

Я так и не понял что у него произошло то, он использовал local volume на root device, почему проверка то не сработала?

Варенье, local не привязывается к нодам как к таковым, а имеет nodeAfinity при дропании ноды волум останется существовать

Там даже в комментах к функции указано что на bindmount не сработает

Кстати работает, но это очень порочная практика. Этот issue тому подтверждение

Всем привет! Мы запускаем корпоративный курс обучения основам работы с Kubernetes для системных инженеров и администраторов. Мы изучим концепты Куба, научим разворачивать свой кластер, запускать и мониторить приложения. Можем провести курс у нас или у вас в офисе, график обсуждается. Если есть особые пожелания по курсу, можем дополнить программу. Буду рад ответить на ваши вопросы! https://kubernetes-course.exonlab.ru

Т.е., грубо говоря, баг фиксится удалением 6 символов в одной строке

если очень хочется, то можно :) mount -o bind /data/myvolume /data/myvolume

Что случается с pvc когда уменьшают количество реплик в стейтфулсете? Может оно и так должно было пропасть ?

Что случается с pvc когда уменьшают количество реплик в стейтфулсете? Может оно и так должно было пропасть ?

serverless безполезная фигня, исключая кейсы, когда оплата за call, а не ресурсы cpu/mem.

ну или так: fallocate -l 10G ./myvolume.img mkfs.ext4 ./myvolume.img mount -o loop ./myvolume.img /data/myvolume cat /proc/mounts | grep /data/myvolume >> /etc/fstab

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

подскажите плиз я правильно понимаю что istio-cni удобнее, тк мне не придется менять конфиги приложений вообще? https://github.com/istio/cni

kubeless генерит deployment для каждой функции? Какой смысл, самому написать не сложнее. Кривая реализация?

а, я не про реализацию knative, не смотрел пока, а про концпецию serverless в кластерах вообще

Т.е., грубо говоря, баг фиксится удалением 6 символов в одной строке

А ты уверен что здесь есть именно баг?

Вы сделаете много добра если расскажете на курсе как организовать деплои с jsonnet, можно взять пример kube-prometheus , большой и развесистый деплой, при этом удивительно гибкий из-за jsonnet

Прям чтоб уверен - нет, но то, что пишет автор issue выглядит вполне убедительно

подскажите плиз я правильно понимаю что istio-cni удобнее, тк мне не придется менять конфиги приложений вообще? https://github.com/istio/cni

Ого, удобно

--set istio-cni.cniBinDir=/home/kubernetes/bin а как istio-cni в values.yaml прописать? там такого нет https://github.com/istio/istio/blob/master/install/kubernetes/helm/istio/values.yaml https://github.com/istio/cni#gke-setup

В сервисмониторе для coredns поменяй лейблы.