у нас было 40 ядер и 256гб памяти и симптомы ровно те же были

на конфе цепанул рецепт в виде нарезания жирной ноды на виртуалке kvm'ом

это как раз наши красавчики придумали костылик

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

да, именно так делают, например, в авито

я правда там уже не работаю

(не авито)

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

верным путём пошли :)

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

ummutable infrastructure рулит для такого

но с дешевым мжелезом на тестовой среде пришли падения нод, с которыми я собсно и пришел в этот канал)

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

Потому ещ одну и ещё одну=)

Ну 2 из 3х у вас падение на свапе

Так что ищет ошибки памяти

ummutable infrastructure рулит для такого

ну да, но клауд дорого пока для нас

Так что ищет ошибки памяти

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

А вы его тюнили? или используете дефолтовые значения?

А вы его тюнили? или используете дефолтовые значения?

что именно тюнили?

скорость переспределения нод

нет, дефолтное все

1. Запускаю вот такой деплоймент и попадаю в sh alpine: $ kubectl run sh --image=alpine -it --command -- sh 2. Выхожу (exit) и вижу такую подсказку: Session ended, resume using 'kubectl attach sh-69f846b4b7-8cxr5 -c sh -i -t' command when the pod is running 3. Выполняю подсказку, и действительно опять попадаю в sh alpine. 4. Опять выхожу (exit) и опять вижу ту же подсказку. 5. Выполняю подсказку, но второй раз вот такое: error: unable to upgrade connection: container sh not found in pod sh-69f846b4b7-8cxr5_default и $ kubectl get po NAME READY STATUS RESTARTS AGE sh-69f846b4b7-8cxr5 0/1 Completed 1 25s Что такое Completed и почему первый раз я смог вернуться, а второй — нет?

Есть несколько интерфейсов: eth0 Link encap:Ethernet HWaddr 36:f5:64:24:c5:a7 inet addr:202.154.192.122 Bcast:207.154.207.255 Mask:255.255.240.0 eth1 Link encap:Ethernet HWaddr 3e:03:d1:5c:2c:96 inet addr:10.135.78.185 Bcast:10.135.255.255 Mask:255.255.0.0 КАК повесить nginx на public ip? Вот сервис ...Type: LoadBalancer IP: 10.106.169.46 Port: <unset> 443/TCP TargetPort: 443/TCP NodePort: <unset> 32481/TCP Endpoints: 192.168.217.249:443,192.168.82.166:443 Session Affinity: None External Traffic Policy: Cluster Events: <none> ... экспорт ... ports: - nodePort: 32481 port: 443 protocol: TCP targetPort: 443 selector: io.kompose.service: front sessionAffinity: None type: LoadBalancer status: ...

А что, ExternalIP не прокатило?

я сделал: helm fetch test/service --untar helm install ./service -n test-deploy helm upgrade test-deploy ./service все норм то есть проблема именно при апгрейде с 1.0.0 (в котором нет `initialDelaySeconds`) на 1.0.1 (в котором я добавил это свойство) вот и спрашиваю: я чего-то не понимаю, или он должен был мне обновить деплоймент?

Повторю еще раз, мне не сложно. Бегите с хелма, максимум что можно - helm template | kubectl apply -f -

заработало, только не могу понять, почему с таким конфигом и двумя nginx (реплика: 2) ports: - name: http port: 80 targetPort: 80 protocol: TCP - name: https nodePort: 32481 port: 443 protocol: TCP targetPort: 443 selector: io.kompose.service: front sessionAffinity: None externalIPs: - y.y.y.y - x.x.x.x - z.z.z.z type: LoadBalancer делаю curl y.y.y.y и убиваю одну из под, запросы виснут, на вторую поду не идут.... why? почему LoadBalancer не отрабатывает?

Так а лоадбалансер есть вообще?

Повторю еще раз, мне не сложно. Бегите с хелма, максимум что можно - helm template | kubectl apply -f -

Буду всячески благодарен, если есть аргументы или кто-то статью написал про это. Сейчас как раз решаем за хелм, я постоянно слышу про "максимум helm template | kubectl apply -f -", но в итоге понимания, а почему же, так и нет.

Потому что фигня подходит тодько длч малого окркжения

New Year Sale! Every Programming Course is 93% off! https://reactdom.com/sale

helm template | istioctl | kubectl apply :)

Повторю еще раз, мне не сложно. Бегите с хелма, максимум что можно - helm template | kubectl apply -f -

Альтернатив то нет

Повторю еще раз, мне не сложно. Бегите с хелма, максимум что можно - helm template | kubectl apply -f -

а куда бежать?)

complited значит команда в контейнеры выполнилась и вернула 0

-)

а куда бежать?)

ни куда. ручками делать и свои системы придумывать

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

logentries (никому не рекомендую, прост общее наследованное решение по логгингу)

ни куда. ручками делать и свои системы придумывать

а в чем причина что хелм не стиот пользовать?

Ребят, а кто как решает HA для докер регистри?

Сейчас ислледуем Ceph для PV и видимо будем запускать registry в кубе

для бутстрапа режистри надо будет запустить режистри

Ну это в ситуации если нет других реджистри

Сейчас ислледуем Ceph для PV и видимо будем запускать registry в кубе

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

Ну делайте резервную копию на другой сервак

в случае факапа - просто другой инстанс за DNS

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

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

Еще поищу истрию и объеденю под тагом #helmговно для будущих поколений

Никого Helm не бесит? :)

Оно сегодня при удалении релиза удалило то, что в релиз не входило :)

Любой чарт может перезаписать любой template , в итоге никогда не знаешь что твой собственный template тебе вернет. Оправдание этому в доке какое то детское

Ну package manager должен уж как то гарантировать корректность

Еще эта идея публиковать тарболы в стиле 90х, брр

Еще из неподтвержденых: похоже что если в чарте есть namespace, и оно не совпадает с namespace релиза, то хелм его конечно поставит, но вот удалить забудет :))

Helm.sh/post-upgrade хук: Если это job то следующий апгрейд релиза провалится, так как оно не сможет его создать.

Еще этот tiller, нафига? Все равно все пишет в configmap, а атомарность create позволяет делать лок на конекретный редиз, так что тиллер вполне себе мог бы жить в клиенте

Просто кому то хотелось в grpc поиграться :)

нет, это кривой kubectl apply с блэкджеком

никакой транзакционности и роллбэков. может посчитать что изменений нет,хотя если сравнить оъект в helm get release и в kubectl get XXX -o yaml они будут разными

все подвязано на labels и selectors ,от этого ты можешь установить новый релиз, удалить его, а оно с собой утянит что-то что было до этого. просто потому что labels совпали :)

базовые вещи поломаны: релиз может "усыновить" ресурсы которые уже были, в итоге сам релиз фэйлится и пользователь скажем решает его удалить. оно удаляет и то, что реально не было установлено :) или скажем оно забывает про любые ресурсы, в которых явно прописан namespace. ну или самый ад: upgrade after failure, оно делает совсем не то, что кажется - там внутри идет генерация патча на каждый апгрейд, при этом база для патча - последний релиз, неважно зафэйлин он был или нет. в итоге скажем в релизе изменили A, B при этом B сломало релиз, пользователь делает B' и ожидает получить в кубе и A и B', а получает только B' :)

зато rudder плагины пилят и другие шашечки, проблемы выше даже, как bug не помечают. для них bug это когда panic в их коде :)

тьфу, я думал спам пришел)

Надо какой то Wiki уже сделать ))

Надо какой то Wiki уже сделать ))

+1

в случае факапа - просто другой инстанс за DNS

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

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

Ну тут надо взвесит все вероятности и понять нужно ли это делать до того как вы пойдете в прод

Еще поищу истрию и объеденю под тагом #helmговно для будущих поколений

helm.sh уже есть, осталось дописать к нему .it и можно туда все это сложить

ну и ссылку с основного сайта "Наши друзья: helm.sh.it"

Ребят, а кто как решает HA для докер регистри?

bintray как вариант.

ну и ссылку с основного сайта "Наши друзья: helm.sh.it"

:D

Всем привет, а я тут продолжаю всякими непотребствами заниматься: https://github.com/kvaps/kube-lustre/

Всем привет. Прошу пнуть в нужную сторону, не знаю с чего начать и что читать в сторону kubernetes. Есть 4 тачки на которых настроен к8с 1 мастер и 3 слейва (Bare Metal). Всё функционирует. Говорил с разрабами, они хотят, что бы всё у них поднималось автоматически (SaltStack, Ansible и т.п.). Может есть у кого, примеры/статейки/инструкции как собирать кластер на к8с для продакшн целей. Всем спасибо

https://puppet.com/blog/new-supported-puppet-modules-make-kubernetes-deployments-easier свежак

>> Говорил с разрабами, они хотят, что бы всё у них поднималось автоматически (SaltStack, Ansible и т.п.) это как?

>> Говорил с разрабами, они хотят, что бы всё у них поднималось автоматически (SaltStack, Ansible и т.п.) это как?

всё что бы поднималось автоматически с помощью скриптов соли или ансибла, к тому же автоматически пересобиралось, если что-то упало

возможно, вы хотели написать “боли” вместо “соли”? :)

админской

возможно, вы хотели написать “боли” вместо “соли”? :)

что-то в этом есть

похоже автор вообще не знает что ему надо

"всё" это что?

"всё" это что?

насколько я понял, поды