ну CNI уже есть. Только оно в альфа

CNI есть, но каким боком он к LXC? LXC - это к CRI

Мне интересно, как будет rkt vs docker, насколько оно того стоило

Конкуренция и разнообразие точно на пользу)

да, прошу прощения, CRI

https://www.distelli.com а этой штукой кто-нибудь пользовался?

Вопрос. А кто какой вариант с сетью для выдачи external ip использует в своих self hosted решениях с кубером?

https://github.com/Mirantis/k8s-externalipcontroller

> @etkee а этой штукой кто-нибудь пользовался? попробуй, расскажешь

D:

https://www.youtube.com/watch?v=BcjkUvaIdAg

ахаха, как ты четко щас описал то чем на канале этом занимаемся :)

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

kube-aws?

kops?

Формально оба варианта подходят)

у меня проблема: я получил аккаунт в китайском амазоне, и там нет некоторых вещей на которые опираются эти модные скрипты (kube-aws хочет kms а там такого нет, kops не умеет зону cn и тп) если идти по kubernetes hard way то там некоторых нужных вещей мне нет (балансировщик, явно заточен на обучение а не на продакшн) что посоветуете? :)

@vkfont https://github.com/kubernetes/charts/pull/349#issuecomment-270519468 говорят можно в стейбл. Ты уже проверял?

я до 1.5.1 не обновился еще на гугле... после праздников хочу заняться, сори

А, сорри, праздники :) я тут про них забываю :)

@kalevas явился =)

@kalevas явился =)

о привет

https://github.com/Mirantis/k8s-externalipcontroller

Так и не удалось завести это дело.

Уперся в то, что сервер реджектит запрос от контроллера на создание адреса на интерфейсе

Кто-нибудь решил это?

I0105 15:10:17.770171 1 reflector.go:284] github.com/Mirantis/k8s-externalipcontroller/vendor/k8s.io/client-go/1.5/tools/cache/reflector.go:109: forcing resync I0105 15:10:17.770487 1 controller.go:110] Received update event. Old ipclaim 172-24-26-28-24 - , New ipclaim 172-24-26-28-24 - -4959 I0105 15:10:17.770535 1 controller.go:110] Received update event. Old ipclaim 172-24-26-30-24 - , New ipclaim 172-24-26-30-24 - -4962 I0105 15:10:17.770604 1 controller.go:142] Processing claim 172.24.26.28/24 with node and uid kube002 I0105 15:10:17.770660 1 netutils.go:135] Removing addr 172.24.26.28/24 from link eth0 I0105 15:10:17.771749 1 controller.go:142] Processing claim 172.24.26.30/24 with node and uid kube002 I0105 15:10:17.771767 1 netutils.go:135] Removing addr 172.24.26.30/24 from link eth0 E0105 15:10:18.241981 1 controller.go:166] Error creating node kube002: the server rejected our request due to an error in our request (post ipnodes.ipcontroller.ext) E0105 15:10:18.742517 1 controller.go:166] Error creating node kube002: the server rejected our request due to an error in our request (post ipnodes.ipcontroller.ext) E0105 15:10:19.245324 1 controller.go:166] Error creating node kube002 : the server rejected our request due to an error in our request (post ipnodes.ipcontroller.ext)

Каких-то еще сторонних контроллеров я тоже не нашел. Почитал про calico, но там у них не приметил поддержки какой-то выдачи внешних адресов.

Как я понял, тут чятег в основном gce/aws пользует для работы с k8s.

Так и не удалось завести это дело.

Заведи багу на гитхабе, посмотрим

Хорошо, в ближайшее время сделаю. Спасибо

Как я понял, тут чятег в основном gce/aws пользует для работы с k8s.

Мы selfhosted хуярим - спрашивай @takama

А что и как мы хуярите?

*вы

@xSTASiANx мы не используем NAT и ExternalIP routing, врядли смогу помочь с пробросом траффика до NAT

https://twitter.com/nixcraft/status/816358052823601152

:D

@takama так а что у вас? (безотносительно исходного вопроса)

private cloud, real IPs

Что касается балансинга - перед k8s стоит HAProxy на внешний траффик

Что касается балансинга - перед k8s стоит HAProxy на внешний траффик

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

Все внутренние сервисы ходят на 443/tcp, но через HAProxy по acl

Схемы две: 1. service-name.domain:443 2. domain:443/service-name

Сама HAproxy деплоится там же на k8s или же на отдельных серверах с public ips?

На отдельных серверах

У подов не важно какой порт, в конечном счете у них у всех exposed 443 через Ingress

А, т.е. у каждого пода ingress является точкой входа.

да

А как haproxy сообщаете, что новый под поднялся? Через что-то самописное или chef/ansible?

только не у каждого пода, а у каждого сервиса

По схеме domain:443/service-name у HAProxy никаких изменений не делается

А изоляция сервисов посредством calico?

flannel

Спасибо за ответы. Попробую в эту сторону еще покопать.

А никто не пробовал прикрутить что-нибудь вроде openstack lbaas в качестве опенсорсного лоадбалансера?

Пожалуйста

А никто не пробовал прикрутить что-нибудь вроде openstack lbaas в качестве опенсорсного лоадбалансера?

Были потуги..

Тут немного есть https://github.com/kubernetes/kubernetes/issues?utf8=%E2%9C%93&q=is%3Aopen%20is%3Aissue%20label%3Asig%2Fopenstack%20lbaas

Кстати, в 1.6 будет etcd v3 дефолтный https://groups.google.com/d/msgid/kubernetes-dev/CALM%2Bqp_4nmTasM4eBjsNYwop_%3Dxx4hTP%3DNKMP10sN%3DAiQdG%2BBA%40mail.gmail.com

коллеги, а существует простой способ сбросить статистику в kubectl? в частности - restarts count?

коллеги, а существует простой способ сбросить статистику в kubectl? в частности - restarts count?

создать под заново?

Присоединяюсь к вопросу )

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

Я не знаю как. Опишите ламеру шаги плиз как счетчик сбросить?

ERROR: S client not available

не, я имею в виду в чем проблема в ненулевом счетчике?

Иногда полезно чтоб знать были ли косяки после деплоя

Oom kill например, мать его за ногу

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

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

Ну если сложные решения имплементить то да... но вопрос то в частности

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

ну в результате я его просто пересоздал, да

несколько непривычный концепт

я давно дашборд не глядел, но там нет чего-нибудь типа running N seconds?

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

есть

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

А если у тебя подов не один десяток? Вообще зачем все это глазами смотреть, когда прикручивается мониторилка и ты уже получаешь алерты по факту, если так надо уж. Никаких ручных дел

как-то вот так

Мой юзкейс такой: куда-нибудь глянуть и посмотреть сколько раз за день сервисы перезапускались. Если 1-2 то норм, если 10 то где-то косяк

возраст с момента создания, не запуска если был рестарт - возраст останется старым

Про мониторилку давай подробнее, актуально

Собирать лог по рестартам в какой-нибудь грейлог и алерты по стримам

А если у тебя подов не один десяток? Вообще зачем все это глазами смотреть, когда прикручивается мониторилка и ты уже получаешь алерты по факту, если так надо уж. Никаких ручных дел

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

Тот же прометеус ваще мало раскрыт в плане кубика (

Про мониторилку давай подробнее, актуально

тебе просто нужно собирать общее количество рестартов и делать по ним график

Тот же прометеус ваще мало раскрыт в плане кубика (

честно написано, что альфа. Можно писать Шальваку, он поправит

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

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

или, еще проще - ловить ивенты куба (нет, не знаю как это делать) и на них алерты ставить. умер под -> скинуть сообщение

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

прометеус тоже должен уметь

Про прометеус не скажу, а грейлог да. Просто и понятно там все настраивается.

Ибо прометеус рассматривал при еще не релизнутом алертменеджере и забил. Может сейчас стало все лучше и приятнее.

алертменеджер не релизнут до сих пор.