содержащими в себе nginx, который отвечает именем hostname по запросу к нему.
root@kubemaster:/home/vagrant# kubectl get nodes -o wide
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
kubemaster Ready master 121m v1.19.1 100.110.0.228 <none> Ubuntu 16.04.7 LTS 4.4.0-189-generic docker://18.9.7
kubenode1 Ready <none> 119m v1.19.1 100.110.0.229 <none> Ubuntu 16.04.7 LTS 4.4.0-189-generic docker://18.9.7
kubenode2 Ready <none> 116m v1.19.1 100.110.0.230 <none> Ubuntu 16.04.7 LTS 4.4.0-189-generic docker://18.9.7
root@kubemaster:/home/vagrant# kubectl get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
my-deployment-dbd6f9659-2c9jx 1/1 Running 0 111m 10.244.1.2 kubenode1 <none> <none>
my-deployment-dbd6f9659-675mt 1/1 Running 0 111m 10.244.2.2 kubenode2 <none> <none>
Каждый из 2 pod успешно работает. При пробрасывании порта через port-forward на каждый отдельный pod, тот успешно отвечает:
root@kubemaster:/home/vagrant# kubectl port-forward my-deployment-dbd6f9659-2c9jx 8000:80
Forwarding from 127.0.0.1:8000 -> 80
Forwarding from [::1]:8000 -> 80
Handling connection for 8000
root@kubemaster:/home/vagrant# curl localhost:8000
my-deployment-dbd6f9659-2c9jx
Теперь к проблеме. Имею Service:
---
apiVersion: v1
kind: Service
metadata:
name: my-service
spec:
selector:
app: my-app
ports:
- protocol: TCP
port: 80
targetPort: 80
root@kubemaster:/home/vagrant# kubectget services -o wide
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 124m <none>
my-service ClusterIP 10.111.253.173 <none> 80/TCP 114m app=my-app
Когда я запускаю тестовый контейнер, перехожу внутрь него, чтобы проверить работу my-service, то получаю следующее:
root@kubemaster:/home/vagrant# kubectl run -t -i --rm --image amouat/network-utils test bash
If you don't see a command prompt, try pressing enter.
root@test:/#
root@test:/# curl my-servise
curl: (6) Could not resolve host: my-servise
Однако, если я обращаюсь к сервису не по имени, а по прямому IP, то 50 на 50 получаю либо ответ пода, либо ошибку:
root@test:/# curl 10.111.253.173
curl: (7) Failed to connect to 10.111.253.173 port 80: No route to host
root@test:/# curl 10.111.253.173
curl: (7) Failed to connect to 10.111.253.173 port 80: No route to host
root@test:/# curl 10.111.253.173
my-deployment-dbd6f9659-2c9jx
root@test:/# curl 10.111.253.173
curl: (7) Failed to connect to 10.111.253.173 port 80: No route to host
root@test:/# curl 10.111.253.173
curl: (7) Failed to connect to 10.111.253.173 port 80: No route to host
root@test:/# curl 10.111.253.173
my-deployment-dbd6f9659-2c9jx
root@test:/# curl 10.111.253.173
curl: (7) Failed to connect to 10.111.253.173 port 80: No route to host
root@test:/# curl 10.111.253.173
curl: (7) Failed to connect to 10.111.253.173 port 80: No route to host
root@test:/# curl 10.111.253.173
my-deployment-dbd6f9659-2c9jx
root@test:/# curl 10.111.253.173
my-deployment-dbd6f9659-2c9jx
Почему так? Я ожидаю, что, во-первых, сервис будет резолвиться по имени my-service, но он не резолвится. Во-вторых, я ожидаю, что при обращении к сервису будут корректно отвечать оба pod, но отвечает только один. Как исправить это?
CNI ставил в тот кластер, что ты имеешь?
вероятно у тебя сеть pod to pod не работает между нодами. Это объясняет чередование валидных запросов, скорее всего когда они идут на pod на той же ноде, и no route to host, когда идут на pod на другой ноде
Обсуждают сегодня