ну да

странно

обновил и ничего

пробую apiserver.pem и apiserver-key.pem обновить

эээ

а что ты до этого обновлял?

уи

думал да

только ca будет достаточно, учитесь на моих ошибках =)

kubectl заработало

Я ещё вот что подумал) может Chef всё-таки внедрить

если у тебя кореос, то шеф тебе не поможет

всмысле - не заработает он там

учи анзибель

Я думал он может cloud-config централизованно обновлять

Генерируя при этом ключи уникальные для каждого миньона

У меня тако вопрос, может быть дурацкий: может ли сервис указывать на другой сервис? Я сейчас пытаюсь разбить всю инфру по неймспейсам, и в идеале из неймспейсов должны торчать отдельные сервисы, а уже неймспейс routing ответственен за то, чтобы пробросить определенный сервис наружу.

Если торчат tcp-порты, то почему бы нет? У меня в разных неймспейсах сервисы друг друга видят по FDQN У тебя же есть DNS внутренний (по-идее) попробуй внутри nslookup <svc-name>.<namespace>.svc или nslookup <svc-name>.<namespace>.svc.cluster.local Соотвественно по-сети сервисы друг друга отлично видят

http://kubernetes.io/docs/admin/dns/

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

Угу, я знаю что их видно с указанием ns. Я просто хочу сделать схему externally-available.routing -> locally-available.internal без добавления промежуточного контейнера, который будет принимать запросы из первого и направлять их во второй.

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

брррр

а что мешает екстернал-сервис ткнуть носом в кубе-днс?

подробнее

# cat /etc/nginx/sites-enabled/blog-apps-frontend.conf upstream kube-blog-app { server blog.apps.svc.kubernetes.local:4000; } ... location / { ... proxy_pass http://kube-blog-app; } ... }

NGINX, использующий этот конфиг, бежит прямо на железе

вне всяких контейнеров

мы пока явно из куба вылезать не будем

так а тогда где проблема-то?

под external service подразумевается просто проброс сервиса наружу. сейчас чуть подробнее опишу.

Есть некий namespace, пусть это backend. В нем есть база данных, которая светит портами: порт для клиентов, порт внутренней коммуникации, еще какой-нибудь порт. Все это дело светится только внутри кластера. В то же время я могу захотеть выбросить наружу порт для клиентов, на время или постоянно, и для этого хотелось бы в отдельном неймспейсе роутинга завести сервис, единственная цель которого - выдача внутреннего сервиса наружу, чтобы к нему можно было обратиться оп айпишнику кластера.

Это можно втупую реализовать с еще одним промежуточным деплойментом с nginx/haproxy, но если можно без - хотелось бы узнать такой способ

Что-то пока без идей...

да это не факт что вообще возможно, может я зря ленюсь через контейнер все бросать

Присоединиться

В блоге Kubernetes опубликовали подробный рассказ о Kubernetes Namespaces: что это такое, зачем они нужны и для чего их не стоит использовать. Учитывая скупость и разрозненность документации, этот пост может сослужить хорошую службу тем, кто только начинает работать с этой системой. http://amp.gs/8sws

баян

уже больше недели статье

:))

коллеги

я тут практически монетку кидаю

RBAC или ABAC?

ABAC + проще менеджить (один JSONL file) - каждое изменение - это рестарт аписервера - дока туманно намекает на мертворожденность и deprecation on alpha stage

RBAC + все менеджится как любой другой k8s-ресурс - с помощью манифестов + вроде как планируется поддержка и развитие - правила адски-зубодробительные - формат будет меняться - проеб админского аккаунта влечет потерю кластера по причине того, что ключ --authorization-rbac-super-user будет упразднен

короче, я прямо весь в сомнениях

А можешь вкратце расшифровать?

Я что-то упустил этот момент. Что значит RBAC? Что ABAC?

https://habrahabr.ru/company/custis/blog/248649/ Наверно так

@asigatchov там в конце табличка про сравнение выглядит несколько странно судя по кубернетесодокам (я понимаю, что там не про кубернетес), плюсики и минусики надо поменять местами

@pipopolam я за то чтобы реализовать ABAC и опубликовать доку по результатам (как делал, впечатления по использованию) - жутко интересно

А почему не rbac?

Судя по доке, rbac выглядит более "родным"

ну роли это стандартно как-то, да и негибко

Там все внутри

В виде манифестов

А abac - внешний файл

Каждое изменение = рестарт аписервера

ну вот и говорю: там проще, а сложное решение интересно посмотреть, особенно если кто-то другой сделает :)

Мне-то как-раз abac проще - у меня chef

Доставка файла и рестарт сервиса при его изменении - его работа

я так понимаю вся суть атрибут-бейсед в том что атрибуты проверяются _в момент запроса авторизации_ а не в момент настройки?

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

?

Не понял последней сентенции

ну я по статье сужу, может невнимательно прочитал предположим, создаем правило "предоставить доступ фредди если сейчас пятница 13-е и он админ" условие даты не зависит от chief

или ты что-то другое имел ввиду? тогда сорян

Chef - это система автоматизации конфигураций

http://chef.io

да я знаю что такое чиф, ансибль и пуппет (сори фор май инглиш :)

Он вообще с кубернетесом никак не связан

Мне-то как-раз abac проще - у меня chef

ты первый начал, я просто заметил что чиф поидее не влияет

Он просто приносит изменения в файл и рестартит аписервер

Ну и вся инфраструктура у меня шефом менеджится

В этом смысле abac - проще

Для него весь бэкграунд уже готов

например?

Ну система по доставке конфига и рестарту сервиса у меня уже есть

Не придется велосипедить

А вот в rbac каждый чих - три манифеста