Всем привет. Запустил деплоймент с сервисом. Их YAML https://pastebin.com/N4sb8qGp kubectl get

svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
rr-dsign-rr-dsign-chart ClusterIP 10.100.137.210 <none> 8080/TCP,8082/TCP 8m43s

Попытка подключиться из мастера к поду curl 10.100.137.210:8082
Не подключается.

Попытка подключиться из воркера к поду curl 10.100.137.210:8082
{"timestamp":"2021-10-12T01:09:12.854+00:00","status":404,"error":"Not Found","path":"/"}
То есть подключается.

Почему мастер не видит под?

Я правильно понимаю, что когда я привяжу ингресс к этому сервису, то ингресс будет запущен на воркере и соответственно я получу доступ к поду?

Открою секрет ингресс нигде не запускается. Надо пойти и в доке глянуть страницу по ингресс и его отличию от ингресс контроллера. Так по ip вы с другой ноды подключится не сможете. Как у вас устроена сеть это вам лучше знать. Вообще стандартный путь выведения сервисов в интернет это ингресс (есть варианты и исключения)

Про ингресс ты думаешь неправильно. Ингресс контроллер это такой же под как все остальные поды, и с этого пода должен быть доступ до другого пода, который селектится сервисом, а сервис прописан в объекте ингресс. Это все можно увидеть через дескрайб ингресса. Но тебе лучше подебажить на уровне сети, проверить фаервол между воркерами. И, конечно, почитать доку про сеть в кубере, ингресс и ингресс контроллер. Да, я тоже типичный.

в общем случае ходить в сервис с ноды мастера можно. Если не работает надо смотреть детальнее

Я не могу даже игинкс контроллер установить 🤦‍♂️ В дескриб пода connection refuse. Куда копать ума не приложу. Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Scheduled 38s default-scheduler Successfully assigned nginx-ingress/nginx-ingress-nginx-ingress-5668dbf78-wrwb6 to srv-dev-rrsys-k8s-worker-01 Normal Pulled 21s (x3 over 37s) kubelet Container image "nginx/nginx-ingress:2.0.1" already present on machine Normal Created 21s (x3 over 37s) kubelet Created container nginx-ingress-nginx-ingress Normal Started 21s (x3 over 37s) kubelet Started container nginx-ingress-nginx-ingress Warning Unhealthy 19s (x6 over 36s) kubelet Readiness probe failed: Get "http://10.244.1.68:8081/nginx-ready": dial tcp 10.244.1.68:8081: connect: connection refused Warning BackOff 4s (x5 over 33s) kubelet Back-off restarting failed container

Что в логах контейнера который стартует?

I1012 05:39:46.554021 1 main.go:195] Starting NGINX Ingress controller Version=2.0.1 GitCommit=208e1384c67f64464ff96a9b76a6b6beca2f95ee Date=2021-10-08T01:02:20Z PlusFlag=false F1012 05:39:47.564556 1 main.go:284] error retrieving k8s version: Get "https://10.96.0.1:443/version?timeout=32s": dial tcp 10.96.0.1:443: connect: no route to host Не уверен, что в этом дело. curl отрабатывает, но при условии, что подставлю флаг —insecure curl --insecure https://10.96.0.1:443/version { "major": "1", "minor": "22", "gitVersion": "v1.22.1", "gitCommit": "632ed300f2c34f6d6d15ca4cef3d3c7073412212", "gitTreeState": "clean", "buildDate": "2021-08-19T15:39:34Z", "goVersion": "go1.16.7", "compiler": "gc", "platform": "linux/amd64"

Дебаж трафик между мастером и воркерами, смотри сеть

А разве дело не в том, что? curl https://10.96.0.1:443/version curl: (60) Peer's Certificate issuer is not recognized. More details here: http://curl.haxx.se/docs/sslcerts.html curl performs SSL certificate verification by default, using a "bundle" of Certificate Authority (CA) public keys (CA certs). If the default bundle file isn't adequate, you can specify an alternate file using the --cacert option. If this HTTPS server uses a certificate signed by a CA represented in the bundle, the certificate verification probably failed due to a problem with the certificate (it might be expired, or the name might not match the domain name in the URL). If you'd like to turn off curl's verification of the certificate, use the -k (or --insecure) option.

судя по ошибки проблема с сетью no route to host

+1

Нет. Что за CNI?

flannel

Очень похоже Если бы непосредственно сеть, то было бы connection error (вообщем соединение непосредственно)

Дальше логи CNI смотри. И таки фаервол между нодами

connect: no route to host

Тут connect как общее, а ошибка как route

в ошибке все написано и это типичная сетевая ошибка при запросе ip твои пакеты не знают куда им бежать, если проблема была бы с сертификатом то в ошибки выше было бы написано об этом а не то что показал автор F1012 05:39:47.564556 1 main.go:284] error retrieving k8s version: Get "https://10.96.0.1:443/version?timeout=32s": dial tcp 10.96.0.1:443: connect: no route to host

@pyToshka а это тогда как?

а это не известно откуда был сделан запрос

Да, согласен - важный нюанс

На воркере

если с ноды то все может отработать, для дебага это так себе важнее сообщение из пода

тогда проверяй cni нетворк полиси тут уже отпадают

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

Да понятно что самоподписной :-) -k классика :-)

на это можно забить

Не правильный ты контроллер ставишь.... Нерюски джун

Конечно, я ж не ты. Я - русский. Чуешь разницу?

Нашёл чем гордиться