Микола Борода в свое время довел devops_ru до белого каления

Вдруг это правильный Алик

А не. Правильный - это Курдюков :)

Микола Борода в свое время довел devops_ru до белого каления

Вот-вот, @devops_ru жесть, я присоединился и через час вышел. Там нездоровая атмосфера, будто под метом

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

Кстати а как вы чекаете успешность обновления deployments в CI? С репликами все просто, они на месте обновляются и сразу выдают результат все хорошо или не очень. А deployments запускает обновление и все. bash'ем чекать статус обновления в цикле до полкчения статуса или есть другие варианты?

Вот-вот, @devops_ru жесть, я присоединился и через час вышел. Там нездоровая атмосфера, будто под метом

У меня такой же опыт со слак каналом под таким же названием.

коллеги, подскажите пжлст, в скринах dashboard присутствуют красивые графики нагрузки на узлы. Я правильно понимаю, что эти графики можно получить только через хипстер?

нет, не только через хипстер.. это, как я понял, дефолтный путь =)

можно ссылку на доку, где описывается, как настроить графики?

именно внутри дэша

https://github.com/kubernetes/kubernetes/tree/master/cluster/addons/cluster-monitoring

вот тут, если я тебя правильно понял

если я правильно понял - это совсем не то меня интересуют вот эти графики в дэшборде - https://raw.githubusercontent.com/kubernetes/dashboard/master/docs/dashboard-ui.png вопрос - откуда дэш их получает? Возможно ли настроить источник?

если я правильно понял - это совсем не то меня интересуют вот эти графики в дэшборде - https://raw.githubusercontent.com/kubernetes/dashboard/master/docs/dashboard-ui.png вопрос - откуда дэш их получает? Возможно ли настроить источник?

https://github.com/kubernetes/heapster

то есть все-таки хипстер и инфлакс. Спасибо

да, хипстер.. там по ссылке, что я дал, есть немного доки

а есть рабочий пример нгинковского ingress.kubernetes.io/rewrite-target ?

я че-то ваще не понял как он работает

а, забейте, посмотрел конфиг - лажа оказалась

все равно отдельный nginx придется как ни крути

все равно отдельный nginx придется как ни крути

для чего?

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

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

мне надо запросы на /head/* редиректить на /xxx/yyy/* сервиса B, учитывая что в ингрессе /* обслуживает сервис A насколько я понял ingress.kubernetes.io/rewrite-target умеет работать только с одним сервисом на ингресс или я ошибаюсь?

в общем суть задачи: в 5-м эластике запретили плагины работающие с вебом, а нужен - поэтому ставлю так :) http://pastebin.com/NQah9Qhu

rules: - host: elastic.staging.***.com http: paths: - backend: serviceName: elasticsearch servicePort: 9200 path: / - backend: serviceName: elasticsearch-head servicePort: 80 path: /head

http://blog.kubernetes.io/2016/12/container-runtime-interface-cri-in-kubernetes.html

везет вам, я нихрена не понял

а podAntiAffinity уже вышла в бету или еще нет?

лимиты прометеуса: 400m лимиты монги + редиса + остальное: 500m + 50m + 10m вопрос: почему прометеус никуда не может влезть? NAME CPU(cores) CPU% MEMORY(bytes) MEMORY% gke-staging-default-pool-516b6ce3-pwh9 64m 6% 2100Mi 56% gke-staging-default-pool-516b6ce3-yivx 65m 6% 479Mi 12% gke-staging-default-pool-516b6ce3-g101 60m 6% 1913Mi 51% NAME READY STATUS RESTARTS AGE IP NODE elasticsearch-head-296748745-c4fh1 1/1 Running 1 16h 10.84.2.65 gke-staging-default-pool-516b6ce3-yivx mongo1-921847446-m6z6j 1/1 Running 1 3h 10.84.2.63 gke-staging-default-pool-516b6ce3-yivx mongo2-1423001240-u56bt 1/1 Running 0 3h 10.84.1.26 gke-staging-default-pool-516b6ce3-pwh9 mongo3-1924155034-nbhyd 1/1 Running 1 3h 10.84.0.24 gke-staging-default-pool-516b6ce3-g101 prometheus-3139428739-cs0ak 0/1 Pending 0 2m <none> redis-3026001500-pryka 1/1 Running 1 2h 10.84.2.64 gke-staging-default-pool-516b6ce3-yivx NAME CPU(cores) MEMORY(bytes) mongo1-921847446-m6z6j 6m 39Mi mongo3-1924155034-nbhyd 7m 1658Mi elasticsearch-head-296748745-c4fh1 0m 1Mi redis-3026001500-pryka 2m 2Mi mongo2-1423001240-u56bt 11m 1876Mi 42s 26s 2 {default-scheduler } Warning FailedScheduling pod (prometheus-3139428739-cs0ak) failed to fit in any node fit failure on node (gke-staging-default-pool-516b6ce3-yivx): Insufficient cpu fit failure on node (gke-staging-default-pool-516b6ce3-g101): Insufficient cpu fit failure on node (gke-staging-default-pool-516b6ce3-pwh9): Insufficient cpu

у тебя дэшборд и прочее говно наверняка цпу жрет

я сто лет этим всем не пользовался, там можно посмотреть, что висит на ноде и сумму запросов по железу?

потому что он явно говорит, что ему цпухи не хватает

из kubectl - нет, можно запустить прометеус+графана которые собственно и пытаюст запустить :)

а дэшборд?

ладно, видимо ось

в общем, как-то эту инфу вытянуть можно http://kubernetes.io/kubernetes/third_party/swagger-ui/#!/api%2Fv1/listLimitRange я думаю, у тебя прямо в кластере еще что-то валяется, что ты нам не показываешь (другие неймспейсы?), и поэтому равномерное распределение вещей по кластеру добило лимиты на каждой ноде до 600+

когда я со всем этим возился, по умолчанию в system был heapster + dashboard + еще что-то, поэтому это реально

Кто там спрашивал? https://twitter.com/googlecloud/status/811232191531323392

уже 1.5.1 вышел

Какой у вас workflow на CI для апдейта deployment (измнения текущего имаджа)? В соответствующем deployment файле заменить image tag и сделать kubectl apply -f?

Какой у вас workflow на CI для апдейта deployment (измнения текущего имаджа)? В соответствующем deployment файле заменить image tag и сделать kubectl apply -f?

Хороший вопрос, как нуб в #k8s поддержу развернутый ответ от людей использующих kubernetes в prod'е

там вроде не надо лезть в конфиг даже

kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1

kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1

Те таг вручную надо ставить? А как реализовать CD, только средствами #k8s это делается как-нибудь. Есть ли проверенные варианты «по-феншую»?

это автоматизируется ровно одной строчкой

ну как сказать... если набрать "gcloud container clusters upgrade staging —master" то пишет: Master of cluster [staging] will be upgraded from version [1.4.7] to version [latest]. и в результате версия остается 1.4.7 если явно указать 1.5.1 то на него будет обновляться... но че-то я очкую обновляться не на релиз

1.5.1 - релиз вообще-то

она даже в репо уже такая

в GKE/GCE в течении недели-двух релиз появляется обычно после официального... надо ж все адаптировать под гугль, настроить чтоб корпоративному сектору ничего не сломать и тп: они кубернетес предоставляют как сервис (например, etcd вообще находится за пределами зоны контроля и тп)

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

хотел с стейтфулсетами поиграться, только у них оказалось "extensions/v1beta1" отключено... так что решил подождать когда в консоли появися флажок "обнови меня" :)

BTW замержили мой монго пуллрек https://github.com/kubernetes/charts/pull/223

BTW замержили мой монго пуллрек https://github.com/kubernetes/charts/pull/223

а это какой образ? как называется? Можно ли там нормально mongod failover делать?

а это какой образ? как называется? Можно ли там нормально mongod failover делать?

Да, я даже с конфигкластером мультишард делал

доки нет пока?

Нет, на это ещё не делал, но есть родная монго дока на шардед кластер

ты в альфе чтоли?

В альфе на 1.4.х

прям в продакшне? oO

народ, сегодня у меня такие вопросы: 1) кто-нибудь деплоит свои сервисы из helm? 2) кто-нибудь логгирует через fluentd? 3) кто-нибудь уже поставил 1.5.1 в гугле?

4) кто-нибудь понял что я сказал? :)

прям в продакшне? oO

Неа, только в тесте

1.5.0 нет как такового

Сразу после выхода 1.5.0 нашли критическую уязвимость и на следующий день выпустили 1.5.1

То есть по факту, нужно иметь ввиду 1.5.1 когда говорим о 1.5

а кто про 1.5.0 говорит?

уже 1.5.1 вышел

Я к этой фразе

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

Стоит ли helm использовать? Серьезно помогает?

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

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

имхо kubectl сильно не хватает шаблонизатора

типа "kubectl create -f deployment.yaml -v variables.yaml" :)

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

вот иммутабильная комманда для инсталяции апргрейда параметров helm upgrade super-mongo stable/mongodb --install -f my-values.yml --version 1.1.1

если не сервиса то создает его, и если что-то изменилось в параметрах (my-values) применит измненения

честно говоря я вообще не понимаю, зачем нужен helm, но я пока начинающий кубовод

ну вот все что нужно чтобы например поднять mongo это файл mongo-params.yml и команда 'helm upgrade super-mongo stable/mongodb —install -f mongo-params.yml —version 0.4.2`