2017-03-09 171 views
2

所以我有一個kubernets集羣啓動並運行使用Kubernetes on CoreOS Manual Installation Guidekubernetes服務IP無法訪問

$ kubectl get no 
NAME    STATUS      AGE 
coreos-master-1 Ready,SchedulingDisabled 1h 
coreos-worker-1 Ready      54m 

$ kubectl get cs 
NAME     STATUS MESSAGE    ERROR 
controller-manager Healthy ok 
scheduler   Healthy ok 
etcd-0    Healthy {"health": "true"} 
etcd-2    Healthy {"health": "true"} 
etcd-1    Healthy {"health": "true"} 

$ kubectl get pods --all-namespaces -o wide 
NAMESPACE  NAME          READY  STATUS RESTARTS AGE  IP    NODE 
default  curl-2421989462-h0dr7      1/1  Running 1   53m  10.2.26.4  coreos-worker-1 
kube-system busybox         1/1  Running 0   55m  10.2.26.3  coreos-worker-1 
kube-system kube-apiserver-coreos-master-1   1/1  Running 0   1h  192.168.0.200 coreos-master-1 
kube-system kube-controller-manager-coreos-master-1 1/1  Running 0   1h  192.168.0.200 coreos-master-1 
kube-system kube-proxy-coreos-master-1    1/1  Running 0   1h  192.168.0.200 coreos-master-1 
kube-system kube-proxy-coreos-worker-1    1/1  Running 0   58m  192.168.0.204 coreos-worker-1 
kube-system kube-scheduler-coreos-master-1   1/1  Running 0   1h  192.168.0.200 coreos-master-1 

$ kubectl get svc --all-namespaces 
NAMESPACE NAME   CLUSTER-IP EXTERNAL-IP PORT(S) AGE 
default  kubernetes 10.3.0.1  <none>  443/TCP 1h 

與指導,我設置一個服務網絡10.3.0.0/16和吊艙網絡10.2.0.0/16。 Pod網絡看起來很好,因爲busybox和curl容器獲得IP。但服務網絡存在問題。起初,我在部署kube-dns時遇到過這種情況:無法訪問服務IP 10.3.0.1,因此kube-dns無法啓動所有容器,並且DNS最終無法運行。

來自卷邊吊艙內,我可以重現該問題:

[ [email protected]:/ ]$ curl https://10.3.0.1 
curl: (7) Failed to connect to 10.3.0.1 port 443: No route to host 

[ [email protected]:/ ]$ ip route 
default via 10.2.26.1 dev eth0 
10.2.0.0/16 via 10.2.26.1 dev eth0 
10.2.26.0/24 dev eth0 src 10.2.26.4 

這似乎確定,有隻有在容器中的缺省路由。據我瞭解,請求(到默認路由)應該由工作者節點上的kube-proxy攔截,轉發給主節點上的代理,IP通過iptables轉換爲主節點公共IP。

似乎有與橋/ netfilter的sysctl的設置一個共同的問題,但似乎在我的設置罰款:

[email protected] ~ $ sysctl net.bridge.bridge-nf-call-iptables 
net.bridge.bridge-nf-call-iptables = 1 

我有一個真正艱難的時間來解決,因爲我缺乏理解服務IP用於什麼,服務網絡如何按照流量工作以及如何最好地進行調試。

所以我這裏還有我有問題:

  • 是什麼(在這種情況下10.3.0.1)的服務網絡的第一個IP用來做什麼?
  • 以上描述的交通流量是否正確?如果不是,容器要達到服務IP需要採取哪些步驟?
  • 調試流量中每一步的最佳方法是什麼? (我不明白日誌裏有什麼不對)

謝謝!

回答

4

服務網絡爲服務提供固定IP。它不是一個可路由的網絡(因此不要指望ip ro顯示任何內容,也不會ping工作),而是在每個節點上由kube-proxy管理的集合iptables規則(請參閱節點上的iptables -L; iptables -t nat -L,而不是Pods)。這些virtual IPs(請參閱圖片!)充當端點(kubectl get ep)的負載均衡代理,它們通常是Pod(但不總是)端口的端口,並帶有服務中定義的特定標籤集。

服務網絡上的第一個IP用於到達kube-apiserver本身。它正在監聽端口443(kubectl describe svc kubernetes)。

故障排除在每個網絡/羣集設置上有所不同。我通常會檢查:

  • kube-proxy是否在每個節點上運行?在某些設置中,它通過systemd運行,在其他設備上有一個DeamonSet,用於在每個節點上調度Pod。在你的設置上,它被部署爲由kubelets自己創建的靜態莢從/etc/kubernetes/manifests/kube-proxy.yaml
  • 找到kube-proxy的日誌並找到線索(你可以發佈一些?)
  • 將kube-proxy更改爲userspace模式。同樣,細節取決於您的設置。對你來說,它在我上面提到的文件中。在每個節點上追加--proxy-mode=userspace作爲參數
  • 覆蓋(pod)網絡是否正常工作?

如果你留言我會盡快給你..

+0

感謝您的描述,它幫助我調試和解決問題!如前所述,日誌顯示沒有什麼特別的(基本上它報告了添加的iptables規則)。所以我檢查了iptabels -j LOG語句,如果DNAT正在工作,並且如果答覆也到達了他們所做的,那麼我就結束了一個本地的forwading-conatiner問題。看看節點路由表,我看到'docker0'和'cni0'有相同的子網。檢查指南,我錯過了'docker_opts_cni.env'部分。糾正後,'docker0'有另一個子網,一切都開始運作。謝謝! – grasbueschel

+0

做好調試吧!我的回答有點難以理解..我在手機上編寫了它。對不起:) –

1

我有同樣的問題,竟然是在KUBE-proxy.yaml配置問題對於「大師」的參數我有ip地址在 - --master = 192.168.3.240,但它實際上需要是一個url像 - --master = https://192.168.3.240

FYI我的kube代理成功地使用--proxy-mode = iptables(v1.6。 x)

1

我有這個相同的問題,最終的解決方案,我工作是在所有節點上啓用IP轉發我忽略了這一點。

$ sudo sysctl net.ipv4.ip_forward=1 
net.ipv4.ip_forward = 1 

服務IP和DNS在之後立即開始工作。