прятать не от кого

кстати

а как сейчас модно etcd бэкапить?

а как сейчас модно etcd бэкапить?

Не доверяешь кластеру?)

+ etcdctl backup иногда

etcdctl backup - это же только для v2?

а кто-нибудь уже перешел с v2 на v3?

А кто как организовал хранение секретов? В GitHub repo? Или что-то вроде Vault используете от HashiCorp?

гитхаб + gpg. Распаковка админским ключем при доставке на целевую машину

это прямо в Поде (в контейнере) осуществляется? Или перед деплоем ноды? мы храним пока в Secrets, которые хранятся в приватном репозитории. Деплой на кластер через kubectl. Подключаем либо в качестве монтируемого вольюма, либо напрямую в переменные окружения (все зависит от применимости, например ключи к приватным registry монтируем KubernetesSecrets -> файлы с ключами)

а вы какую проблему-то решаете?

от кого вы прячете secret'ы?

у нас все проще - у нас вся конфигурация во внешку не выходит, нам не надо прятать. в Secrets храним данные для Oauth, пароли, токены к API

а что значит "вся конфигурация во внешку не выходит"?

(простите, я не очень умный :( )

репозиторий с настройками Kubernetes приватный, хранить секреты отдельно нет смысла, как и использовать Vault или какое-то шифрование

аааа

ну вот я об этом и спрашивал там выше

Поэтому нам лично достаточно базовой функциональности

в данном-то случае все эти vault'ы нужны только когда от других коллег их прятать надо

просто механизм Secrets и его монтирование в переменные окружения/вольюмы довольно прикольный и удобнй

да, верно

и при этом еще как-то надо запретить тем коллегам делать kubectl get secret supadupasecret -o yaml

я читал http://kubernetes.io/docs/admin/authorization, но пока было не надо, поэтому заюзать повода не было

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

дане, судя по доке можно почти точечно

http://kubernetes.io/docs/admin/authorization/#request-payloads

например вот

Любопытно

А кто-нибудь использует ingress на локальной установке без облаков?

Вы используете внешние балансировщики или как выводите сервис наружу?

у меня kube-dns присутствует в /etc/hosts, и nginx, установленный на фронтенд-хостах, обращается прямо к кубе-сервисам

Фронты не в кластере?

нет

там куча всего не контейнеризировано

поэтому фронты пока отдельно

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

а пока приходится извращаться немношк

А как тогда доступен куб-днс снаружи?

всмысле?

откуда "снаружи?"

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

видит

я не понимаю, где проблема? ;)

kube-proxy на хосте надежно решает эту проблему посредством iptables

# iptables-save | grep -i dns -A KUBE-SEP-AGF24HBSCHVRB2IM -s 192.168.0.4/32 -m comment --comment "kube-system/kube-dns:dns" -j KUBE-MARK-MASQ -A KUBE-SEP-AGF24HBSCHVRB2IM -p udp -m comment --comment "kube-system/kube-dns:dns" -m udp -j DNAT --to-destination 192.168.0.4:53 -A KUBE-SEP-CF3CVUYBRRNMUR2I -s 192.168.0.4/32 -m comment --comment "kube-system/kube-dns:dns-tcp" -j KUBE-MARK-MASQ -A KUBE-SEP-CF3CVUYBRRNMUR2I -p tcp -m comment --comment "kube-system/kube-dns:dns-tcp" -m tcp -j DNAT --to-destination 192.168.0.4:53 -A KUBE-SERVICES -d 10.222.222.222/32 -p udp -m comment --comment "kube-system/kube-dns:dns cluster IP" -m udp --dport 53 -j KUBE-SVC-TCOU7JCQXEZGVUNU -A KUBE-SERVICES -d 10.222.222.222/32 -p tcp -m comment --comment "kube-system/kube-dns:dns-tcp cluster IP" -m tcp --dport 53 -j KUBE-SVC-ERIFXISQEP7F7OF4 -A KUBE-SVC-ERIFXISQEP7F7OF4 -m comment --comment "kube-system/kube-dns:dns-tcp" -j KUBE-SEP-CF3CVUYBRRNMUR2I -A KUBE-SVC-TCOU7JCQXEZGVUNU -m comment --comment "kube-system/kube-dns:dns" -j KUBE-SEP-AGF24HBSCHVRB2IM

и так на каждом хосте

не руками, естественно

все эти правила динамически формирует kube-proxy

который запущен на всех хостах

таким образом я могу прямо на bare-metal машине использовать кластерный днс (ну и любые другие endpoint'ы)

Я через nodeport обычно прокидывал сервисы

а зачем?

приходится прокси перенастраивать

чтобы он другой рейнж портов мог юзать

Ну это меня и смущало

А как у тебя описание сервиса выглядит?

https://gist.github.com/Bregor/5d27a6d0cb722d743bb7f17da132edfd

это тыптыщеконфиг

а сервисы как обычно

ща

Я что то не понял про то как указать cluster ip на bare

а зачем?

ты же имя в сервисе пишешь

и по имени к нему и обращаешься

разрешение имени в адрес делает kube-dns

А доступен он также на всех нодах?

Как нодпорт?

ну на всех, где kube-proxy есть

или руками iptables настроен ;)

добавил сервис в гист: https://gist.github.com/Bregor/5d27a6d0cb722d743bb7f17da132edfd

Ясно, видимо меня смутила фраза в доке, что cluster ip предоставляется сервис провайдером

Спасибо за экскурс)

это когда у тебя type: LoadBalancer

и над тобой GCE или LBE

тогда айпи тебе выдает провайдер

а на bare metal тебе сам черт не брат :D

:)

собственно адреса для сервисов выдаются аписервером

ориентируется он при этом на --service-cluster-ip-range=10.222.0.0/16

ну в смысле это у меня там 10.222.0.0/16

не помню, что там по-умолчанию

Хм, так это дополнительный адрес? Или что это за range?

хехе

об это я бился головой дня три

(ну я там выше говорил уже, что я не очень умный)

короче

адреса для сервисов и адреса для подов - это два никак не пересекающихся множества

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

они нигде не терминируются

и нужны только для роутинга до нижележащих ресурсов (подов)

а вот адреса подов имеют под собой некоторое "физическое" отображение

и должны кем-то выдаваться

это может быть CNI, docker-networking, etc

А мы про адреса сервисов

Да , про них я знаю)

Я думал мы продолжаем тему внешних

нене

Думаю какой там еще ренж вроде все только прояснилось)

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