он может быть однопоточным, но асинхронным

python -m ComplexHTTPServer

python -m FuckNginxHTTPServer 🙈

а там мне darkhttpd очень нравится

он может быть однопоточным, но асинхронным

я ж на nodejs пишу, вкурсе xD

ок, не 20 строк, а 40 - https://github.com/openshift/release/blob/e632edc6da1a72ec4d6883c314d737330816396d/ci-operator/templates/openshift/installer/cluster-launch-installer-upi-e2e.yaml#L113-L156

конкурс "rate my http server" открыт, поехали

du -hs darkhttpd 40K darkhttpd

Есть такая ошибка у автоскейлера, возникает на версии кубернетиса 11.3 и 12.5, пробовал разные версии самого скейлера везде одинаковая ошибка, могу показать yaml из которого я его деплою. Мне советовали смотреть в контейнер, но я так и не нашел куда смотреть в контейнере, чтобы понять причину ошибки. (неделю назад на версии 11.3 все работалоб сейчас ошибка с таймаутом все время)

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

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

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

чем чинить? адрес вроде пингуется но курл ничего не возвращает

i/o timeout?

увеличить время таймаута?

не знаю

узнай у амазона

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

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

Снэпшотик блок девайса с etcd.

Снэпшотик блок девайса с etcd.

в том числе и вольюмы подов? если инфа важная

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

Люди с базов кубе должны страдать 😁🤗 я насколько понимаю хочется одной командой раскатать кластер с нуля, чтобы volumes стали, бекапы накатались и массаж devopsу сделали.

Люди с базов кубе должны страдать 😁🤗 я насколько понимаю хочется одной командой раскатать кластер с нуля, чтобы volumes стали, бекапы накатались и массаж devopsу сделали.

с базами всё ок просто узнать что помимо etcd еще бэкапят

бэкапить етцд это же мем

бэкапить етцд это же мем

почему? разве это не узкое место кубера?

манифесты кубера (стейт) бэкапить куда-то - ок

сам етцд - зачем?

точнее: что ты с этим бэкапом будешь делать?

Связь с cloud api объектами потеряется.

Очень такое.

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

нормально он восстанавливается - скейлишь etcd до одного, восстанавливаешь из снапшота, скейлишь снова

а у шедулера крыша не поедет?

очевидно шедулер и апи сервер остановлены до начала процедуры, даунтайм в любом случае будет

а шедулер выключен в это время

и при этом все поды надо приложить ещё?

как минимум вычищать ненайденые контейнеры будет долго. У меня на 200 контейнеров прилично времени занимает.

это для случая поднимаем кластер с нуля

дольше, чем накатить с нуля манифесты

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

из бекапа

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

ну в принципе да. еще проще задеплоится в новый кластер

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

причём этот кластер может быть и не новым, а старым

пофиг, одинаково работает

и при этом все поды надо приложить ещё?

если они были в снапшоте зачем их вычищать?

если они были в снапшоте зачем их вычищать?

ну с момента снятия снапшота же была наверное какая-то активность

а если не было, то зачем восстанавливаться из снапшота

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

я тут писал, что у меня была идея делать вместо apply git push (в ci/cd) в промежуточный репозиторий. А там уже другой pipeline делает apply. В случае факапа просто запускается pipeline этого репа. Принидутельный backup получается.

я тут писал, что у меня была идея делать вместо apply git push (в ci/cd) в промежуточный репозиторий. А там уже другой pipeline делает apply. В случае факапа просто запускается pipeline этого репа. Принидутельный backup получается.

the easy way

Там такое было?

да, очень похоже

я тут писал, что у меня была идея делать вместо apply git push (в ci/cd) в промежуточный репозиторий. А там уже другой pipeline делает apply. В случае факапа просто запускается pipeline этого репа. Принидутельный backup получается.

можно просто запретить пушить в мастер

можно просто запретить пушить в мастер

не понял? Там манифесты же собираются из разных частей. Кейс в том, что в 100500 реп пойти руками и запустить pipeline сложно.

Манифесты плохая идея бэкапить. Не учесть всего, что может случится в контроллерах, которые следят за новыми объектами. Бэкап etcd позволяет подложить всё так, как и было обратно.

да, очень похоже

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

Манифесты плохая идея бэкапить. Не учесть всего, что может случится в контроллерах, которые следят за новыми объектами. Бэкап etcd позволяет подложить всё так, как и было обратно.

я про кейс "только stateless".

Сорри отходил, потерял нить разговора)

я про кейс "только stateless".

Service объект входит туда?

да

А в чем тогда проблема?

cloud controller пойдёт и попытается создать новую LB.

ну с момента снятия снапшота же была наверное какая-то активность

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

А она уже есть. Зачем?

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

я тут писал, что у меня была идея делать вместо apply git push (в ci/cd) в промежуточный репозиторий. А там уже другой pipeline делает apply. В случае факапа просто запускается pipeline этого репа. Принидутельный backup получается.

идея плоха тем, что кроме ci/cd у тебя наверняка будет стоять доп. софт. cert-manager, memcache, redis И прочее, что ставится из helm

идея плоха тем, что кроме ci/cd у тебя наверняка будет стоять доп. софт. cert-manager, memcache, redis И прочее, что ставится из helm

посмотри the easy way

идея плоха тем, что кроме ci/cd у тебя наверняка будет стоять доп. софт. cert-manager, memcache, redis И прочее, что ставится из helm

вот это тоже в промежуточном сидеть должно

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

там минут 10 всего

вот это тоже в промежуточном сидеть должно

секреты тоже ?

идея плоха тем, что кроме ci/cd у тебя наверняка будет стоять доп. софт. cert-manager, memcache, redis И прочее, что ставится из helm

>И прочее, что ставится из helm вот за это и не люблю helm, хотя его приложухи тоже декларативно описывать можно, см. ksonnet, Hemfile, kr8 и т.п.

посмотри the easy way

А ссылку дашь ? а то гугля вываливает очень много всего. вижу запись в блоге куба от 2017 года - это оно ?

youtube://kubernetes+the+easy+way

the easiest way, pls

секреты тоже ?

Ну да. Это не супер страшно в маленькой команде. Особенно с учетом, что ничего кроме 80/443/22 не торчит

ну heptio ark ту же задачу решает. без промежуточной прослойки в виде репо.

ну heptio ark ту же задачу решает. без промежуточной прослойки в виде репо.

Это не шаг pipeline и делать каждые 10 минут наверное не будешь бекап. Но понятно. Просто альтернативный подход. Я не тестил, больше не скажу ничего

аха. мне просто не совсем понятно каким образом деплоить доп. софт. вот щас я держу список чартов и их values в репо и хелмом ставлю.

а тут как быть. делать helm template, и класть в репо ?

привет, подскажите плиз, как по бест практис надо организовывать доступ к внутренним сервисам, типа бд, редис и тп, которые не смотрят наружу (у меня конкретно GKE, если это важно)? Не хочется делать лоад балансер на каждый сервис, и мне кажется это как-то криво. Возможно, есть какой-то вариант сделать впн внутри кластера и ходить через него на внутренние сервисы?

а тут как быть. делать helm template, и класть в репо ?

используй Helmfile или ksonnet