Kubernetes Network Issue
У меня проблема с настройкой кластера Kubernetes на компьютерах с Ubuntu 16.04, я правильно настроил:
- главный узел (IP-адрес компьютера: 10.10.1.122)
- рабочий узел (IP-адрес компьютера: 10.10.1.38)
в кластер с этой информацией:
NAME READY STATUS RESTARTS AGE
pod/coredns-86c58d9df4-78lnp 1/1 Running 0 80m
pod/coredns-86c58d9df4-lw7vl 1/1 Running 0 80m
pod/etcd-di-linux-host 1/1 Running 0 111m
pod/kube-apiserver-di-linux-host 1/1 Running 0 110m
pod/kube-controller-manager-di-linux-host 1/1 Running 0 111m
pod/kube-flannel-ds-amd64-6wvkh 1/1 Running 0 109m
pod/kube-flannel-ds-amd64-p7ftb 1/1 Running 0 110m
pod/kube-proxy-rbfvz 1/1 Running 0 109m
pod/kube-proxy-zwr7b 1/1 Running 0 111m
pod/kube-scheduler-di-linux-host 1/1 Running 0 111m
pod/kubernetes-dashboard-79ff88449c-9f8qw 1/1 Running 0 89m
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/kube-dns ClusterIP 10.96.0.10 <none> 53/UDP,53/TCP 111m
service/kubernetes-dashboard ClusterIP 10.98.188.215 <none> 443/TCP 89m
NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE
daemonset.apps/kube-flannel-ds-amd64 2 2 2 2 2 beta.kubernetes.io/arch=amd64 110m
daemonset.apps/kube-flannel-ds-arm 0 0 0 0 0 beta.kubernetes.io/arch=arm 110m
daemonset.apps/kube-flannel-ds-arm64 0 0 0 0 0 beta.kubernetes.io/arch=arm64 110m
daemonset.apps/kube-flannel-ds-ppc64le 0 0 0 0 0 beta.kubernetes.io/arch=ppc64le 110m
daemonset.apps/kube-flannel-ds-s390x 0 0 0 0 0 beta.kubernetes.io/arch=s390x 110m
daemonset.apps/kube-proxy 2 2 2 2 2 <none> 111m
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/coredns 2/2 2 2 111m
deployment.apps/kubernetes-dashboard 1/1 1 1 89m
NAME DESIRED CURRENT READY AGE
replicaset.apps/coredns-86c58d9df4 2 2 2 111m
replicaset.apps/kubernetes-dashboard-79ff88449c 1 1 1 89m
Моя информация о кластере
Kubernetes master is running at https://10.10.1.122:6443
KubeDNS is running at https://10.10.1.122:6443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy
Мои стручки
NAME READY STATUS RESTARTS AGE
guids-68898f7dc9-c65nv 1/1 Running 0 102m
Name: guids-68898f7dc9-c65nv
Namespace: default
Priority: 0
PriorityClassName: <none>
Node: gmf.com/10.10.1.38
Start Time: Sun, 16 Dec 2018 15:43:41 +0200
Labels: pod-template-hash=68898f7dc9
run=guids
Annotations: <none>
Status: Running
IP: 10.244.1.15
Controlled By: ReplicaSet/guids-68898f7dc9
Containers:
guids:
Container ID: docker://125ceccad4e572b514538292aaeaa55e22050c5e9129f834de8e01dfd452c6c1
Image: alexellis2/guid-service:latest
Image ID: docker-pullable://alexellis2/guid-service@sha256:17207f799760ccdccd0fa1e7f37838af5df915a33f9f27e97951a6eeee8c3a6f
Port: 9000/TCP
Host Port: 0/TCP
State: Running
Started: Sun, 16 Dec 2018 15:43:46 +0200
Ready: True
Restart Count: 0
Environment: <none>
Mounts:
/var/run/secrets/kubernetes.io/serviceaccount from default-token-hnwtc (ro)
Conditions:
Type Status
Initialized True
Ready True
ContainersReady True
PodScheduled True
Volumes:
default-token-hnwtc:
Type: Secret (a volume populated by a Secret)
SecretName: default-token-hnwtc
Optional: false
QoS Class: BestEffort
Node-Selectors: <none>
Tolerations: node.kubernetes.io/not-ready:NoExecute for 300s
node.kubernetes.io/unreachable:NoExecute for 300s
Events: <none>
Проблема, с которой я здесь сталкиваюсь, заключается в том, что всякий раз, когда я хочу свернуть сервис или IP-адрес модуля с главного узла, на который он никогда не попадает, в то же время, сгибание службы / модуля с рабочего узла проходит нормально, я новичок в Kubernetes, но Я не могу найти какие-либо указания, как я могу диагностировать эту проблему, любая помощь будет высоко ценится.
когда я пытаюсь свернуть открытую службу, даже я получил этот результат от мастера:
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
guids ClusterIP 10.97.160.160 <none> 9000/TCP 92m
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 139m
ubuntu@master:/$ curl http://10.97.160.160:9000/guid
curl: (7) Failed to connect to 10.97.160.160 port 9000: Connection timed out
1 ответ
IP-адрес модуля, который доступен из других узлов и кластера IP, доступен из модулей внутри кластера kubernetes.
ClusterIP службы - это не IP-адрес модуля, это виртуальный адрес, сопоставленный с IP-адресом модуля на основе правил, определенных в службе, и он управляется kube-proxy демон в кластере kubernetes.
ClusterIP особенно необходим для связи внутри кластера для доступа к модулям за службой, не заботясь о том, сколько реплик модулей присутствует или на каком модуле узла присутствует, а clusterIP статичен в отличие от IP модуля.
Если можете прочитать о том, как работает сервис IP в официальной документации
Я хотел бы, чтобы вы выполнили несколько шагов отладки:
Вы можете проверить, что имя вашей службы разрешается в ClusterIP из модуля, используя:
kubectl exec -it <pod_name> bash
nslookup <svc_name>.<namespace>.svc.cluster.local
Приведенная выше команда даст вам кластер IP вашего сервиса.
Убедитесь, что ваш рабочий узел доступен для проверки связи с вашего главного узла, если это не так, у вас есть проблемы с вашей оверлейной сетью, в вашем случае это фланелевое соединение.