@ivan4th, а скажи, в чем такая большая проблема отдавать побольше данных в downward API?

@pipopolam а ты в какой версии пытаешься этот status.hostIP использовать?

1.3.7

странно. spec.nodeName должен работать

очень странно.

https://github.com/kubernetes/kubernetes/blob/v1.3.7/pkg/api/validation/validation.go#L1098 - здесь нет. это tag 1.3.7

а здесь есть. это branch 1.3.7 https://github.com/kubernetes/kubernetes/blob/1.3.7/pkg/api/validation/validation.go#L1320

ну сборка-то по тегу делалась скорее всего

@ivan4th, а скажи, в чем такая большая проблема отдавать побольше данных в downward API?

там вроде в коментах уже написали, node name доступен в 1.4. резолвишь и вот тебе IP. а так “It is sometimes useful for a container to have information about itself, but we want to be careful not to over-couple containers to Kubernetes.” (via http://kubernetes.io/docs/user-guide/downward-api/)

а резолвить в пре-ините?

можно init containers заюзать, чтобы получить ip и положить куда надо, да

ну да, я про init-container

ну да, там. или если сам image собираешь, то можешь уже и в нём самом

вот блин Hockin тролль, а...

Это thockin-то троль? До smarterclayton’а ему как до луны

ггг

ну я спросил "а чобы нет", он ответил "чтобы нет"

ну не тролль?

ну он наверное как раз имел в виду, что чрезмерное увлечение downward api - запашок

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

чем меньше контейнеры в pod’е осознают, что ими рулит именно k8s, тем лучше - в этом идея

кроме случаев, когда без этого совсем никак

а есть ли простой способ отобразить поды ,которые запущены на определенном хосте?

имаджи запущенных контейнеров можно

$ kubectl get no <node> -o jsonpath='{.status.images[*].names[0]}'

echo -e $(kubectl get pods —all-namespaces -o jsonpath="{range .items[?(.spec.nodeName==\"ubuntu3\")]}{.metadata.name}\n{end}")

вставлю и свой вариант kubectl get --all-namespaces pod -o wide | grep nodename

твой вариант мне больше нравится. спасибо

https://www.weave.works/prometheus-and-kubernetes-monitoring-your-applications/

да когда вы читать вообще успеваете D:

вообще говоря - никогда обычно

хватает времени только ссылки копипастить

а я обычно читаю только команды и их вывод :))

Кто что использует в качестве reverse proxy c k8s?

nginx

я бы удивился если бы кто сказал apache :))

есть еще traefik

ELB ?

+ ingress

а ingress для кого у вас конфиги генерит ? кто-нить юзает ingress+ipvs(keepalived) ?

нжинкс + tls

есть тут кто-нибудь, кто может помочь с параметрами к duplicity?

что это еще такое

это быкапилка такая ;)

про traefik не знал, спасибо

как тебя угораздило?

он уже год поднимает хайп

i'm not superman

:(

ingress + nginx вроде то что нужно, осталось только раскурить тему

kubernetes на aws. ноды в autoscaling group. добавляю/убиваю ноды и вижу в ‘kubectl get nodes’ результат где-то через 10-15 минут только. там наверно какие-нибудь интервалы для health checks можно сконфигурировать?

да

а где? )

первое место - ключи кьюблета

--node-status-update-frequency=4s

второе ща найду

вот, нашел

https://github.com/evilmartians/chef-kubernetes/commit/b5365fce4df5b9fe1d24fc7e6d0dc5de94a1c2fd

с шести минут до 46-ти секунд

Возможно еще это понадобится kube-controller-manager --pod-eviction-timeout=5m0s: The grace period for deleting pods on failed nodes.

ingress + nginx вроде то что нужно, осталось только раскурить тему

Если нужны реальные ip в логах то не совсем то

Возможно еще это понадобится kube-controller-manager --pod-eviction-timeout=5m0s: The grace period for deleting pods on failed nodes.

у меня там полминуты

+ - --node-monitor-period=2s + - --node-monitor-grace-period=16s + - --pod-eviction-timeout=30s

ок, спасибо, буду ковырять

ERROR: S client not available

то есть два места: 1. ключи kubelet'a тут надо добавить --node-status-update-frequency 2. ключи controller-manager'a тут их целых три: - —node-monitor-period - —node-monitor-grace-period - —pod-eviction-timeout

дальше можешь либо читать ман (предпочтительный вариант)

либо скопипастить мои цыфирьки

я довел время обнаружения до сорока с чем-то секунд

@vmakhaev ^^^

хорошо, спасибо

у кого-нибудь получилось подружить ingress и namespaces?

у меня

у меня в default namespace живет ingress controller. а всё остальное он вытаскивает из остальных namespace

оно так by default работает

круто

а по подробнее как это настроить?

так всё дефолтно

https://github.com/kubernetes/contrib/blob/master/ingress/controllers/nginx/examples/default/rc-default.yaml

@sclif13 ты проще расскажи, что конкретно у тебя НЕ получилось

а затем в своих namespace создаешь ingress instance

пока не пробовал, пока изучаю

в aws k8s создаёт для каждого сервиса свой ELB, домен которого можно использовать как CNAME запись для домена приложения. У нас будет крутиться много приложений/сервисов и не хочется для каждого прописывать dns, а хочется один раз указать один раз для всех поддоменов, типа *.k8s-apps.com идите туда-то по CNAME. Как-то это можно сделать?

роут53 прикрути

все-равно ж его юзаешь, раз в амазоне

домены зарегистрированы где-то в другом месте заказчиком и мы к ним доступа не имеем. Я уже им предлагал перенести в route53, но они как-то проигнорили :-)

я не о клиентских доменах

у тебя ж есть k8s-домен

его в роут53

а клиент у себя пускай cname'ы лепит

ок, понял

вот есть работающее решение: https://github.com/wearemolecule/route53-kubernetes

вот два issue, которые надо форсить:

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

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

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