а почему под потыкать не поднять пару вм-ок?

мне вполне хватало 3х вмок, чтобы получить мастер+инфру+воркер ноду

на бесплатном gcp аккаунте надо было запросить еще IP (тут в чате обсуждали) и тогда работало - выходило около ~$200 в месяц на дефолтах, но думаю можно ужать до 150

а так же следить за развитием https://github.com/openshift/enhancements/pull/504

спс

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

Привет, вкатил OLM на ванильный куб, apiserver не может достучаться к packageserver:

1 available_controller.go:437] v1.packages.operators.coreos.com failed with: failing or missing response from https://10.103.42.53:5443/apis/packages.operators.coreos.com/v1: bad status from https://10.103.42.53:5443/apis/packages.operators.coreos.com/v1: 401

лог packageserver подсказвает что что-то не так с сертификатом:

12 authentication.go:53] Unable to authenticate the request due to an error: [x509: subject with cn=microservices-kubernetes-pki-front-proxy-client is not in the allowed list, x509: certificate signed by unknown authority]

подскажите, в какую сторону копать?

1 available_controller.go:437] v1.packages.operators.coreos.com failed with: failing or missing response from https://10.103.42.53:5443/apis/packages.operators.coreos.com/v1: bad status from https://10.103.42.53:5443/apis/packages.operators.coreos.com/v1: 401

12 authentication.go:53] Unable to authenticate the request due to an error: [x509: subject with cn=microservices-kubernetes-pki-front-proxy-client is not in the allowed list, x509: certificate signed by unknown authority]

отдаленно похоже на https://bugzilla.redhat.com/show_bug.cgi?id=1880928, проверь cabundle в apiserver?

Если ты про чеин для front-proxy-client (тот с которым apiserver ломится к packageserver, то он выдан отдельным front-proxy-ca, который больше нигде не фигурирует.

в опеншифте не так?

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

А если ты про .spec.caBundle в apiservice/v1.packages.operators.coreos.com, то CA, который там имеется не матчится с тем на который слушает packageserver, а слушает он вообще на self signed certificate o__O

насколько я понял caBundle - это CA которым кубапи подписывает реквесты

не, кубапи подписывает свои реквесты сертом front-proxy-client, а caBundle указанный для apiservice содержит CA, которым подписан сертификат с которым слушает packageserver

Это нужно чтобы apiserver мог доверять ему при попытке подключения

мне кажется проблема в том что packageserver не доверяет apieserver по какой-то причине

Всем привет. Начал  работать с openshift 3.11 кластером развернутым до меня. Есть 3 мастер и 4 воркер ноды. Обнаружил что на воркер нодах не запущен kube-proxy и все запросы к подам в кластере идут через мастеров. Это нормально вообще? Работал до этого с rancher и там на каждом воркере был kube-proxy c 80 и 443 портом. Чтобы не дергать каждый раз мастер ноды. А как правильно для openshift только разбираюсь. Если это не нормально , то как запустить kube-proxy (по информации о воркере kube-proxy вроде как есть) ?

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

Подам не нужен мастер и запросы к подам идут через SDN, в который обычно впилен kube-proxy

я понимаю, но этот kube-proxy по итогу на мастер ноде

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