;)

в дефолт-неймспейсе

Максим, всё отлично в итоге вышло, мы запустили всё в обновленной версии, теперь работает красиво и даже dashboard новый с одной команды поставился. Хоть этот апдейт был с проблемами и далось большой ценой, оно того стоило. Хочу поблагодарить тебя, что был рядом этим выходные и помогал шаг за шагом с этим справиться. Чтобы хоть как-то компенсировать то, что я забрал тебя у семьи на все выходные и компенсировать это, хочу вам с супругой подарить билеты в Большой Театр, вы как, нормально к театру относитесь?

мы к театру вообще отлично

жаль только, не в москве живем ;)

ээ

Питер? :)

да

Можешь мне помочь подобрать тогда театр и спектакль? Для меня это важно :)

как-то неожиданно ты с этим

не хочется, чтобы люди подумали, что я за ништяки помогаю

:)

в любом случае, спасибо за предложение

Так, понял, гоу в личку)

Понятно, что ты это делал от сердца и это было мега очевидно)

и это ещё ценней в наше время

так

а между тем я подебил ABAC

и авторизацию по токенам

теперь вместо users: - name: ololo user: key: <long-unreadable-x509-key-here> cert: <long-unreadable-x509-cert-here>

можно написать: users: - name: ololo user: token: short-and-pretty-token

это про токены

а вот ABAC: # cat /etc/kubernetes/authorization-policy.jsonl {"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"user": "*", "nonResourcePath": "*", "readonly": true}} {"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"user": "admin","namespace": "*", "resource": "*", "apiGroup": "*"}} {"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"user": "scheduler","namespace": "*", "resource": "*", "apiGroup": "*"}} {"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"user": "kubelet", "namespace": "*", "resource": "*", "apiGroup": "*"}} {"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"group": "system:serviceaccounts", "namespace": "*", "resource": "*", "apiGroup": "*", "nonResourcePath": "*"}} ...

чортов телеграм :(

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 можно попробовать постучать в апи

ERROR: S client not available

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

если политика авторизации отлична от 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

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

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