Примерно так должно быть

Примерно так должно быть

я понял. но не до конца догоняю если я хочу PVC, разве обязательно нужно создавать PV?

скорее всего, т.к. он отрезает от него куски, насколько я понял

Т.е. для кубера создается pv, а для сервисов(подов) нарезаются pvc

понял идею, спасибо

и последний вопрос. а как происходит авторизация? только по volume id? или куда-то пропихивается access и secret keys?

не отрезает ?

биндинг PV <-> PVC one to one

это динамический провижионинг отрезает

Если у меня не gce, и я буду использовать nginx-ingress-controller gce-0.9.6 (который помечен, как релиз), всё будет работать на baremetal?

кубер и все будет работать - сомневаюсь)

Если у меня не gce, и я буду использовать nginx-ingress-controller gce-0.9.6 (который помечен, как релиз), всё будет работать на baremetal?

да, у нас так

только он не 0.9.6 ?

0.9.0-beta.11 последний для nginx

0.9.6 - это GLB как раз

биндинг PV <-> PVC one to one

а каким образом этот биндинг происходит?

а каким образом этот биндинг происходит?

в статике, когда есть свободный созданый PV подходящего размера

в динамике, когда есть работающий StorageClass

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

https://github.com/kubernetes-incubator/external-storage

у меня работает

я не до конца понимаю каким образом мой storageclass узнает об моем аккаунте на amazone определен он стандартно по документации, я только зону поменял https://hastebin.com/ozuximixoc.lua

просто по дефолту сторадж класс из dynamic provisioning

pvc оттуда нарезает куски автоматом

@takama я правильно понимаю, что при правильном подходе, динамический провижининг будет сам ходить в aws и делать там нужного размера volumы?

да должен ходить и нарезать

У каждого StorageClass свои настройки, у нас Ceph, там прописываются все адреса, пароли явки

@takama я правильно понимаю, что при правильном подходе, динамический провижининг будет сам ходить в aws и делать там нужного размера volumы?

верно

ага, я читаю документацию, и в описании storageclass указывается только AZ для aws никаких ключей и токенов не вижу

поэтому и фрустрирую

в AWS точно не скажу, скорее всего при установке k8s есть специфика, поддерживающая провижионинг для AWS

0.9.0-beta.11 последний для nginx

С ним проблема. Вот эта:

Ребята. Сталкивался ли кто-нибудь с таким? Обычно под вечер (но бывало и с утра) переставал работать nginx-ingress-controller. При попытке войти на сайты с https, происходила очень долгая попытка загрузки, которая ничем не заканчивалась. Просто белый экран и никаких ошибок ни в логах контроллера, ни в логах куба. Вход на http давал ответ 301. Есть предположение, что, поскольку 443 порт слушает не nginx, а контроллер (и дальше направляет трафик на 442 порт nginx'а), то проблема именно в этом месте. Помогите советом, что глянуть.

ага, я читаю документацию, и в описании storageclass указывается только AZ для aws никаких ключей и токенов не вижу

там роль может на инстанс требоваться

там роль может на инстанс требоваться

а где об этом можно почитать

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

сейчас у меня картина такая: в амазон консоли я должен навесить на свои инстансы IAM роли, для того что бы когда создаю storageclass с provision: aws-ebd запросы от этих инстансов в amazon были валидны

немного дичь выходит

а где об этом можно почитать

я сетапил через kube-aws, там для kube-apiserver идет флаг —cloud-provider=aws. Там своя магия, пока не разбирался. Почитать думаю можно тут: https://kubernetes.io/docs/getting-started-guides/scratch/

я сетапил через kube-aws, там для kube-apiserver идет флаг —cloud-provider=aws. Там своя магия, пока не разбирался. Почитать думаю можно тут: https://kubernetes.io/docs/getting-started-guides/scratch/

вот да, уже не первый раз наталкиваюсь на этот флаг --cloud-provider=aws но я использую kubespray для деплоя

передеплоивать чтоле...

Ребята. Сталкивался ли кто-нибудь с таким? Обычно под вечер (но бывало и с утра) переставал работать nginx-ingress-controller. При попытке войти на сайты с https, происходила очень долгая попытка загрузки, которая ничем не заканчивалась. Просто белый экран и никаких ошибок ни в логах контроллера, ни в логах куба. Вход на http давал ответ 301. Есть предположение, что, поскольку 443 порт слушает не nginx, а контроллер (и дальше направляет трафик на 442 порт nginx'а), то проблема именно в этом месте. Помогите советом, что глянуть.

nginx-ingress-controller обычно запускают на нодах, которые не мастер, там 443 свободен обычно

nginx-ingress-controller обычно запускают на нодах, которые не мастер, там 443 свободен обычно

Порт-то свободен. На той ноде, кроме контроллера, больше ничего нет.

он и слушает 443 и направляет на сервис согласно ingess rules

также слушает на 80

еще default-http-backend отдаёт 404 если сервиса нет

он и слушает 443 и направляет на сервис согласно ingess rules

В конфиге nginx нет listen 443. Только listen 442. Слушает сам контроллер.

ну да, контроллер

у нас стоит последняя бета, проблем не замечено

Или не знаю, кто там слушает 443, но в nginx.go есть такой код: n := &NGINXController{ binary: ngx, configmap: &api_v1.ConfigMap{}, isIPV6Enabled: isIPv6Enabled(), resolver: h, proxy: &proxy{ Default: &server{ Hostname: "localhost", IP: "127.0.0.1", Port: 442, ProxyProtocol: true, }, }, },

кстати про этот 442

для whitelist-source-range нужен use-proxy-protocol чтоб адрес не локалхоста был, но в таком случае из-за фигни в proxy procotol не работает http. кто-то решал эту проблему?

есть такая проблема, прищлось временно отключить use-proxy-protocol

а как тогда фильтровать по айпи

из гугла с наскоку никто так и не починил

ну или лишится 80 порта

мы не фильтруем по IP

если ест внешний балансер, можно обойтись без 80 порта

внешний балансер форвардит http -> https например

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

так бы да, работало

т.е. k8s торчит наружу?

да

в паблик сеть

ERROR: S client not available

ну да, ингресс это точка входа в сеть

ой, мы пока не решаемся на такое, на приватке всё идёт через HAProxy в GCE через их балансеры

мы пока разбираемся с интеграцией k8s+aws

ну там ELB можно подружить вероятно

ну пока не подружили, надо чтоб нжинкс нормально работал)) а болт походу

так, стало немного яснее, на инстансы где я хочу PVC с AWS-EBD нужно навесить такие AIM роли ec2:AttachVolume ec2:DetachVolume ec2:DescribeInstances ec2:DescribeVolumes https://github.com/kubernetes/examples/blob/master/staging/volumes/aws_ebs/README.md

да, и у меня не установлен volume plugin для aws_ebd find /var/lib/kubelet/plugins/ -type f | wc -l 0

@takama а вы не могли бы проверить команду выше? ^^^^

у меня не AWS

ну и плагинов тоже нет

ну и плагинов тоже нет

на обычных виртуалках/baremetal установлено?

да

для whitelist-source-range нужен use-proxy-protocol чтоб адрес не локалхоста был, но в таком случае из-за фигни в proxy procotol не работает http. кто-то решал эту проблему?

Эту проблему я решил так: В темплейте у "listen 80" я убрал proxy_protocol

собирался это сделать, и ничего не поломалось?)

интересно зачем изначально она там была, в таком случае

хотя судя по гиту официального ингресса и его форков - git workflow темплейта и контроллера мягко говоря не оч организован

Ну, как сказать... Запросы на http отрабатывают нормально. Но уже третий день наблюдаются тормоза https - просто колом встаёт и ни один сайт не работает. Через некоторое время gataway timeout, однако ни в одном логе ничего не сказано про это. Вряд ли это с этим связано, конечно, но она там есть во всех версиях.

listen 80{{ if $cfg.UseProxyProtocol }} proxy_protocol {{ end }} у меня так не работает, empty response. в логах broken header: " *тут весь оригинальный запрос* " while reading PROXY protocol

Не представляю, в чём дело, но подозреваю, что если было бы просто: ... listen 80; ... listen 443 ssl proxy_protocol; ... То всё было бы нормально. Но на деле там listen 442 ssl proxy_protocol; для SNI. И не понятно, если выпилю - будет ли работать несколько сайтов по https на одном айпи. Без кубера такая схема работала с обычным nginx.

щас уберу посмотрю

listen 80{{ if $cfg.UseProxyProtocol }} proxy_protocol {{ end }} у меня так не работает, empty response. в логах broken header: " *тут весь оригинальный запрос* " while reading PROXY protocol

Да. То же самое было.

убрал proxyprotocol с http, стало работать норм

все равно непонятно зачем его всунули в темплейт, если оно заранее нерабочее

может не тестировали в кейсе когда нет x-forwarded-for...

может не тестировали в кейсе когда нет x-forwarded-for...

а тестировали ли вооще?)

ху из sni серевер Оо

server name indication, самая забавная штука в TLS, нивелирующая половину самого смысла TLS

https://thenewstack.io/github-goes-kubernetes-tells/

отличная новость!

коллеги, а порейтингуйте книг по кубернетесу?

от себя: крайне НЕ рекомендую kubernetes microservices in docker, автор Deepak Vohra. в принципе имя уже подсказывает, что будет дальше. Книга во-первых очень старая (куб 1.01), во-вторых ужасно написана (я не преувеличиваю)

читаю kubernetes in action издательство manning