должен быть сертификат и мгенеренный secret

Артём, а чем генерировать secret?

1) сокеты apiserver слушаются на 0.0.0.0:8080 и 0.0.0.0:6443 2) компоненты kubernetes цепляются на apiserver на порт 8080 по http через параметр —master (не могу перевести на https, так как не вижу параметры в которых можно было бы использовать https у всё тех же самых компонент) 3) сами apiserver'а обращаются к самим себе на localhost на https порт 6443 (проверено, экспериментировал с сертификатами, в которых пришлось прописать alternaivemane = localhost, чтобы исчезли сообщения об ошибках при подключении к самим себе на localhost!!!!!!!!!) 4) в конце концов постоянно вылетает сообщение "Resetting endpoints for master service "kubernetes" to &TypeMeta{Kind:,APIVersion:,}", видимо это и есть конень моих проблем

по 4-му пункту сообщение перестало выводиться на api-серверах как только указал в параметрах их запуска параметр —apiserver-count=2, где 2 - количество api-серверов в кластере!!!

он вроде сам генерит все если серты подложить

я с телефона могу ошибиться

но там создаётся service account

kubectl get secret отрабатывает

https://kubernetes.io/docs/getting-started-guides/ubuntu/

тут правда богомерзкий жужу

но чармы читаются

в целом процесс описан можно повторить

а были ещё нормальные хауту

с командами из консоли

он вроде сам генерит все если серты подложить

С secret все понятно. Начал настраивать HTTPS и столкнулся с проблемой при обращении controller-manager'ов к apiserver'ам: - на стороне apiserver выдается сообщение kube-apiserver[3657]: I0223 19:22:07.357473 3657 logs.go:41] http: TLS handshake error from .....: connection reset by peer - а на стороне controller-manager выдается сообщение error retrieving resource lock kube-system/kube-controller-manager: Get https://kube-master.infra.local:6443/api/v1/namespaces/kube-system/endpoints/kube-controller-manager: x509: certificate signed by unknown authority Сертификаты на обоих сторонах одинаковые: - на стороне apiserver используются параметры —service-account-key-file и —tls-ca-file - на стороне controller-manager используются параметры —service-account-private-key-file и —root-ca-file Они вроде должны общаться друг с другом, но... Что может быть не так? Чего еще добавить?

При обращении curl'ом и по ip-адресу и имени ошибок с https не возникает, результат запросов выдается всегда Unauthorized

https://github.com/kubernetes/kubernetes/issues/14097

где то тут ответ)

Если scheduler'а и controller-manager'а несколько, можно надеятся что при вылете одного из них кластер будет функционировать?

Короче, как я понял, проблем полно с HTTP и не во всех компонентах он нормально поддерживается. Пример тому kube-proxy!

Незавидную тем кто зачем то ставим кластер сам))

Игра в сам себе админ

Игра в получение профильной квалификации, как по мне

Незавидную тем кто зачем то ставим кластер сам))

С удовольствием выслушаю альтернативы. Без Amazon ec2 и kubeadm. Вообще- автоматизация- это прекрасно, но было бы нелишним понимать, что именно автомат творит. Иначе есть риск напороться на ошибку, лечение которой превратится в магическую процедуру.

GCP - GKE

Мы используем его

Autoscale кластера есть

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

GCP - GKE

Я правильно понимаю, что все, кто не использует gce/aws- недостойны?

не коните гоней

всё в доках есть, надо сесть и прочесть

альтернатив то нет

Короче, как я понял, проблем полно с HTTP и не во всех компонентах он нормально поддерживается. Пример тому kube-proxy!

Вообще идея использовать http в небезопасных окружениях (а они по умолчанию небезопасны, если явно не доказано иное) - не кажется мне здравой

https везде нормальная практика

можно своих нагенерить

можно за 30 уе купить

Вообще идея использовать http в небезопасных окружениях (а они по умолчанию небезопасны, если явно не доказано иное) - не кажется мне здравой

++, да и общая тенденция движется к тому, что по умолчанию все потоки данных должны быть обернуты в tls.

++, да и общая тенденция движется к тому, что по умолчанию все потоки данных должны быть обернуты в tls.

Гугл вот верил в защищенность своих линий между своими цодами. Все помнят, чем кончилось? :)

тотальным IPSec'ом, чем. ну или функционально аналогичным решением.

mitm рядом, даже если кажется, что и нет.

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

Гугл вот верил в защищенность своих линий между своими цодами. Все помнят, чем кончилось? :)

неа, я пропустил

неа, я пропустил

Кончилось MitM от NSA. Которое потом засветил Сноуден. АНБ качали данные как пожарный насос, вообще не затыкаясь.

тотальным IPSec'ом, чем. ну или функционально аналогичным решением.

Вы явно никогда не отлаживали IPSec туннель и не представляете, насколько сложная и капризная это технология. Я уж не говорю о том, что туннель предполагает частичный контроль над сетевой инфраструктурой. Список проблем в таком решении могу продолжать ещё долго.

о нет, сейчас начнутся сетевые войны, а я еще с прошлого раза ничего не прочитал по теме!

Вы явно никогда не отлаживали IPSec туннель и не представляете, насколько сложная и капризная это технология. Я уж не говорю о том, что туннель предполагает частичный контроль над сетевой инфраструктурой. Список проблем в таком решении могу продолжать ещё долго.

IPSec не обязательно требует туннелирования и несколько непрост в первичной настройке, но вообще не рокет-саенс, даже в случае тысяч нод. я сказал "функционально аналогичное решение" в том плане, что между отдельными машинами нет (или почти нет, потому что есть edge-кейсы вроде DHCP) хождения нешифрованного трафика

IPSec не обязательно требует туннелирования и несколько непрост в первичной настройке, но вообще не рокет-саенс, даже в случае тысяч нод. я сказал "функционально аналогичное решение" в том плане, что между отдельными машинами нет (или почти нет, потому что есть edge-кейсы вроде DHCP) хождения нешифрованного трафика

Ipsec вообще-то относительно простой

Ipsec вообще-то относительно простой

я об этом и говорю.

Вы явно никогда не отлаживали IPSec туннель и не представляете, насколько сложная и капризная это технология. Я уж не говорю о том, что туннель предполагает частичный контроль над сетевой инфраструктурой. Список проблем в таком решении могу продолжать ещё долго.

А что там капризного?

Там же все предельно просто: взаимная аутентификация, потоковый шифр, рекеинг

Там же все предельно просто: взаимная аутентификация, потоковый шифр, рекеинг

Даже спорить не буду- охота стрелять себе в ногу - вперёд. Желательно за свои деньги.

IPSec не обязательно требует туннелирования и несколько непрост в первичной настройке, но вообще не рокет-саенс, даже в случае тысяч нод. я сказал "функционально аналогичное решение" в том плане, что между отдельными машинами нет (или почти нет, потому что есть edge-кейсы вроде DHCP) хождения нешифрованного трафика

IPSec-mesh с соединением по требованию и инфраструктурой отзыва ключей несложен?

Даже спорить не буду- охота стрелять себе в ногу - вперёд. Желательно за свои деньги.

Ну мы стреляли. В чем сложность? Тот же stronswan смотрел?

RacoonD, strongswan, openswan, cisco vpnc, cisco anyconnect, shrew, ms ike client, nortel secure (кажется так назывался) - смотрел. Плюс железки. Нет там ничего простого. Если часть сложностей strongswan от вас скрыл - это не значит, что настраивать было просто. Это значит магию. А это плохо. Это означает неконтролируемую инфраструктуру. То есть - не понятую инфраструктуру.

Не говоря о том, что повальный IPSec не решает проблему, для которой был придуман ssl и tls

RacoonD, strongswan, openswan, cisco vpnc, cisco anyconnect, shrew, ms ike client, nortel secure (кажется так назывался) - смотрел. Плюс железки. Нет там ничего простого. Если часть сложностей strongswan от вас скрыл - это не значит, что настраивать было просто. Это значит магию. А это плохо. Это означает неконтролируемую инфраструктуру. То есть - не понятую инфраструктуру.

а зачем использовать raccon?

RacoonD, strongswan, openswan, cisco vpnc, cisco anyconnect, shrew, ms ike client, nortel secure (кажется так назывался) - смотрел. Плюс железки. Нет там ничего простого. Если часть сложностей strongswan от вас скрыл - это не значит, что настраивать было просто. Это значит магию. А это плохо. Это означает неконтролируемую инфраструктуру. То есть - не понятую инфраструктуру.

единственная сложность с ipsec - это то, что некоторые вендоры делают его криво.

а зачем использовать raccon?

затем, что на тот момент иных вариантов не было.

единственная сложность с ipsec - это то, что некоторые вендоры делают его криво.

неверно. Его все делают неправильно. Но - по-разному

затем, что на тот момент иных вариантов не было.

когда "в тот момент"? в 2003 уже был openswan/freeswan, в 2005 - strongswan.

неверно. Его все делают неправильно. Но - по-разному

кто, например и о какой версии ike речь?

народ, кто-нибудь запускал concourse.ci в кубернетесе?

Привет. Осваиваю kubernetes и docker. Всё поднято на AWS с помощью https://github.com/coreos/kube-aws, как-то работает. Проблема, что клиент (мобильный, react-native приложение) не коннектится к сокету (на обычных хостингах если сервер запущен — всё ок). Инстанс приложения в одном экземпляре, так что это видимо не из-за балансера? В каком направлении копать, в общем

начниет с kubectl get services

kubectl get ingress

Что именно я там должен увидеть? Сервис-то работает, там еще сайт - открывается, сервак бежит

kubectl get ingress

No resources found

когда вы видите что-то это ен значит что это видят другие люди

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

погадать?

начниет с kubectl get services

Вижу тут сервис который создал, на 80 и 443 портах

nodeport?

80:32506/TCP,443:31110/TCP

kctl get nodes

Вижу 2 ноды

kctl get pods Вижу свой под, могу зайти на него, смотреть логи

Извините, что вопрос немного не по теме, но может, кто-то может помочь с этим: http://stackoverflow.com/q/42443688/4193643 Это по поводу Concourse CI, собственно, тут ее и подсмотрел

⇒ kubectl describe svc fallball-connector Name: fallball-connector Namespace: default Labels: name=fallball-connector Selector: name=fallball-connector Type: NodePort IP: 10.10.23.172 Port: <unset> 80/TCP NodePort: <unset> 32544/TCP Endpoints: 10.10.3.13:5000 Session Affinity: None No events.

IP: 10.10.23.172 у вас там что?

с этого адреса будут доступны ваши порты

если нужен доступ по белому адресу - ingress

Name: *** Namespace: default Labels: name=*** tier=*** Selector: app=*** Type: LoadBalancer IP: 10.3.0.168 LoadBalancer Ingress: a391*********************.us-west-2.elb.amazonaws.com Port: http 80/TCP NodePort: http 32506/TCP Endpoints: 10.2.42.25:4000 Port: https 443/TCP NodePort: https 31110/TCP Endpoints: 10.2.42.25:4000 Session Affinity: None No events.

Через route53 сделан alias на этот ingress, сайт открывается по домену, коннекчусь к сокету тоже по нему

вот тут я пфф - тк у меня GKE

(

По ходу в AWS надо что-то подкрутить

Но я не знаю что

я бы начал смотреть как настроен a391*********************.us-west-2.elb.amazonaws.com

так вы пытаешь к домена привязанному к ip у elb a391*********************.us-west-2.elb.amazonaws.com

подключиться к 80 порту?

и я не знаю но для работы tls вам нужно аннотацию сделать ссылкой на сертификаты

Извините, что вопрос немного не по теме, но может, кто-то может помочь с этим: http://stackoverflow.com/q/42443688/4193643 Это по поводу Concourse CI, собственно, тут ее и подсмотрел

там несколько версий назад сломали ssl disable, теперь нужно настраивать с сертификатами

Привет. Осваиваю kubernetes и docker. Всё поднято на AWS с помощью https://github.com/coreos/kube-aws, как-то работает. Проблема, что клиент (мобильный, react-native приложение) не коннектится к сокету (на обычных хостингах если сервер запущен — всё ок). Инстанс приложения в одном экземпляре, так что это видимо не из-за балансера? В каком направлении копать, в общем

то, что проксирует трафик по пути к поду, умеет в upgrade?

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

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

Две строчки, смысл которых я не понимаю.

вебсокеты, о которых, насколько понимаю, идет речь, и http - это два разных протокола на одном порте, и если запрос принимается через ряд промежуточных http-роутеров, есть вероятность, что один из них не проксирует вебсокеты, а только чистый хттп

В сервисе надо было вместо http выставить tcp в service.beta.kubernetes.io/aws-load-balancer-backend-protocol: "tcp"