https://dl.dropboxusercontent.com/s/pxvd9acirf0iaen/1._rootweb02-amplifr-ru__ssh_2016-08-30_22-26-59.png?dl=0

вот так это выглядит

Ребята, всем доброго времени суток. Сижу ломаю голову - у меня есть DaemonSet или RC. Как мне прокинуть node_ip внутрь контейнера? Прям очень-очень надо))) У меня агенты запускаются на каждой ноде и мне бы получать про эту ноду инфу... Сейчас полезу смотреть как это делает Prometheus

env + valueFrom?

и что ты в этот valueFrom запишешь?

окей, расширим для понятности: env + valueFrom не сработает?

ну а как ты его заполнишь?

valueFrom what?

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

спасибо

вешать докер на опеределенный ip и в контейнере просто указывать этот ip(который слушает докер)

везде будет один и тот же :)

если я конечно правильно понял вопрос

неа

DaemonSet запускается на всех нодах [где совпадает nodeSelector]

Alexander хочет в подах этого демонсета получать IP той ноды, где запущен этот под

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

то есть все поды запускать с hostNetwork: true

не

необязательно

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

ip докера везде один и тот же

и еще с kube-proxy не пересечься при этом

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

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

ip докера везде один и тот же

и? ему же вроде надо получить айпи ноды для какой-то там обработки в поде

Ребята, всем доброго времени суток. Сижу ломаю голову - у меня есть DaemonSet или RC. Как мне прокинуть node_ip внутрь контейнера? Прям очень-очень надо))) У меня агенты запускаются на каждой ноде и мне бы получать про эту ноду инфу... Сейчас полезу смотреть как это делает Prometheus

опиши задачу подробнее а то мы тут сферического коня в вакууме решаем

это да :)

я уже решил что тебе ip ноды на самом деле не надо ))

Друзья, простите был загружен весь день - только освободился. Итак. У меня есть DS, как я описал выше, в нем агент по сбору информации, не важно какой... допустим количество запущенных контейнеров (через проброшенный сокет могу это узнать). Докер - он не на IP, а на сокете висит, никакого IP у него нету. Итак, есть Nodes с уникальными именами DS запускается на каждой ноде и в итоге имеем N-подов с уникальными также именами. Мне нужно чтобы агент знал либо в каком Поде он находится (имя пода, например) а еще лучше - на какой ноде это происходит. Мы же по описанию пода можем получить имя ноды. Где-то видел как можно прокидывать метаинформацию внутрь прямо через *.yml файлы

Я вроде понял как Prometheus работает - он имеет доступ к kubernetes-api

в каждом поде есть hostname - как раз название пода

и по этим данным я могу все узнать через kuber-api

- job_name: 'kubernetes-node-exporter' tls_config: ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt insecure_skip_verify: true bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token kubernetes_sd_configs: - api_servers: - 'https://kubernetes' in_cluster: true role: node

> Где-то видел как можно прокидывать метаинформацию внутрь прямо через *.yml файлы можно через секреты: http://kubernetes.io/docs/user-guide/secrets/#using-secrets-as-environment-variables можно через конфигмапы: http://kubernetes.io/docs/user-guide/configmap/#consuming-configmap-in-pods но тебе не подходит ни то ни другое, судя по описанию задачи

вот так можно достучаться из пода до API сертификаты инджектятся в каждый контейнер (вроде)

> сертификаты инджектятся в каждый контейнер только публичная часть CA

c другой стороны, имея публичную часть CA и bearer token можно попробовать постучать в апи

зависит от того, чего разрешено этой сервисной группе

если политика авторизации отлична от AllowAll

http://blog.kubernetes.io/2016/08/security-best-practices-kubernetes-deployment.html

https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!msg/kubernetes-announce/XXq5p19HU_w/25yQMwMoCQAJ

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

Так оно само

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

кул

и как, без проблем работает?

вот пример: apiVersion: extensions/v1beta1 kind: Deployment ... spec: minReadySeconds: 10 replicas: 2 strategy: rollingUpdate: maxSurge: 1 maxUnavailable: 0 type: RollingUpdate template: ...

type: RollingUpdate говорит кубернетесу, что сначала надо запускать, а потом убивать

параметр spec.strategy.rollingUpdate.maxUnavailable: 0 указывает, что сначала нужно запустить хотя бы один новый, чтобы можно было начать убивать старые

что спасает нас от убийства старых подов в случае фальстарта новых

вот Максим добрый

?

ну я б на такой вопрос к доке для начала отправил :) если видно, что попробовал и что-то не получается, тогда конечно помогаю

да ты тут хоть кого-то видел, кто пробовал читать?

ну, из тех, кто вопросы задает

)))

вообще кстати, эти maxSurge и maxUnavailable с первого раза немного поставили меня в тупик

http://kubernetes.io/docs/user-guide/deployments/#max-unavailable

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

нужно всегда думать за баланс :D

спасибо! плюс в карму

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

Сделай три

Либо крути maxsurge

нене, даже с одной работает

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

и даже они без даунтайма рестартуют

С дефолтными стратегиями?

maxUnavailable: 0

пока новый не стартанет, старый не умрет

У меня на 1.2.4 он смело клал две реплики сразу

Может конечно что то путаю, но помоему так я обнаружил этот раздел про strategy,иначе нне полез бы туда)

ну у меня сейчас нет 1.2, негде проверить

на 1.3 работает железобетонно

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

Вот он точно прилегал

@pipopolam Я тут поднимаю addons руками, хотел попробовать add-on manager

Хотел спросить ты сперва тестишь addon руками пока не заработают ? А потом подкладываешь их под менеджер ?

ну примерно так, да