Kubernetes：外部服務不可用從Azure雲所有的爪牙

Question

我已經有了Azure雲3臺Ubuntu機器的以下羣集：

172.16.0.7 (master) 
172.16.0.4 (kube-01) 
172.16.0.5 (kube-02) 

在172.16.0.4 (kube-01)我有一個叫做出版商莢與端口暴露。爲了使提供給世界，我定義瞭如下服務：

"id": "publisher-service", 
    "kind": "Service", 
    "apiVersion": "v1beta1", 
    "port": 8181, 
    "containerPort": 8080, 
    "publicIPs": ["172.16.0.4", "172.16.0.5"], 
    "selector": { 
    "group": "abc", 
    "component": "publisher" 
    }, 
    "labels": { 
    "group": "abc" 
    } 

• 172.16.0.4和172.16.0.5是內部IP Addressess（天青換算）爲kube-01和kube-02分別

• 在172.16.0.4 (kube-01)我有將公有端口設置爲並將私有端口設置爲

定義的Azure端點

• 在172.16.0.5 (kube-02)我得設置爲以及私用端口公共端口定義的Azure的端點設置爲

有了這樣的設置，我可以用我的VM虛擬公衆成功訪問publisher-service IP（VIP）地址和端口。

但是我認爲那些是還能夠使用相同的VIP地址和端口到達publisher-service（因爲它被映射到端口上kube-02）。相反curl報告Recv failure: Connection reset by peer。

我在這裏做錯了什麼嗎？也許我對Kubernetes External Services的理解是不正確的（因此我的期望是錯誤的）？

我也注意到在/var/log/upstart/kube-proxy以下條目記錄：

E0404 17:36:33.371889 1661 proxier.go:82] Dial failed: dial tcp 10.0.86.26:8080: i/o timeout 
E0404 17:36:33.371951 1661 proxier.go:110] Failed to connect to balancer: failed to connect to an endpoint. 

這裏是172.16.0.5 (kube-02)捕獲iptables -L -t nat輸出的一部分：

Chain KUBE-PORTALS-CONTAINER (1 references) 
target  prot opt source    destination 
REDIRECT tcp -- anywhere    11.1.1.2    /* kubernetes */ tcp dpt:https redir ports 45717 
REDIRECT tcp -- anywhere    11.1.1.1    /* kubernetes-ro */ tcp dpt:http redir ports 34122 
REDIRECT tcp -- anywhere    11.1.1.221   /* publisher-service */ tcp dpt:8181 redir ports 48046 
REDIRECT tcp -- anywhere    172.16.0.4   /* publisher-service */ tcp dpt:8181 redir ports 48046 
REDIRECT tcp -- anywhere    172.16.0.5   /* publisher-service */ tcp dpt:8181 redir ports 48046 

Chain KUBE-PORTALS-HOST (1 references) 
target  prot opt source    destination 
DNAT  tcp -- anywhere    11.1.1.2    /* kubernetes */ tcp dpt:https to:172.16.0.5:45717 
DNAT  tcp -- anywhere    11.1.1.1    /* kubernetes-ro */ tcp dpt:http to:172.16.0.5:34122 
DNAT  tcp -- anywhere    11.1.1.221   /* publisher-service */ tcp dpt:8181 to:172.16.0.5:48046 
DNAT  tcp -- anywhere    172.16.0.4   /* publisher-service */ tcp dpt:8181 to:172.16.0.5:48046 
DNAT  tcp -- anywhere    172.16.0.5   /* publisher-service */ tcp dpt:8181 to:172.16.0.5:48046 

我使用Kubernetes v0.12.0。我跟着this guide設置我的羣集（即我使用法蘭絨）。

---

更新＃1：添加publisher莢狀態信息。

apiVersion: v1beta1 
creationTimestamp: 2015-04-04T13:24:47Z 
currentState: 
    Condition: 
    - kind: Ready 
    status: Full 
    host: 172.16.0.4 
    hostIP: 172.16.0.4 
    info: 
    publisher: 
     containerID: docker://6eabf71d507ad0086b37940931aa739534ef681906994a6aae6d97b8b213 
     image: xxxxx.cloudapp.net/publisher:0.0.2 
     imageID: docker://5a76329ae2d0dce05fae6f7b1216e346cef2e5aa49899cd829a5dc1f6e70 
     ready: true 
     restartCount: 5 
     state: 
     running: 
      startedAt: 2015-04-04T13:26:24Z 
    manifest: 
    containers: null 
    id: "" 
    restartPolicy: {} 
    version: "" 
    volumes: null 
    podIP: 10.0.86.26 
    status: Running 
desiredState: 
    manifest: 
    containers: 
    - capabilities: {} 
     command: 
     - sh 
     - -c 
     - java -jar publisher.jar -b $KAFKA_SERVICE_HOST:$KAFKA_SERVICE_PORT 
     image: xxxxx.cloudapp.net/publisher:0.0.2 
     imagePullPolicy: PullIfNotPresent 
     name: publisher 
     ports: 
     - containerPort: 8080 
     hostPort: 8080 
     protocol: TCP 
     resources: {} 
     terminationMessagePath: /dev/termination-log 
    dnsPolicy: ClusterFirst 
    id: "" 
    restartPolicy: 
     always: {} 
    version: v1beta2 
    volumes: null 
generateName: rc-publisher- 
id: rc-publisher-ls6k1 
kind: Pod 
labels: 
    group: abc 
namespace: default 
resourceVersion: 22853 
selfLink: /api/v1beta1/pods/rc-publisher-ls6k1?namespace=default 
uid: f746555d-dacd-11e4-8ae7-000d3a101fda 

Answer 1

一旦我使用k8s重新安裝我的集羣v0.14.2一切開始按預期工作。我跟着Brendan Burns 。

Answer 2

外部網絡實際上似乎做工精細 - 你在日誌中看到的消息是因爲KUBE-代理確實收到你發送給它的請求。

不過，失敗的原因是kube-proxy無法與您的pod進行通話。無論是法蘭絨都無法正確路由到您的吊艙IP，或者吊艙不健康。由於發送請求到172.16.0.4起作用，您的絨布設置可能有問題。您可以通過嘗試從節點2捲曲10.0.86.26:8080來確認此情況。

如果pod的運行狀況可能有問題，可以通過運行kubectl.sh get pod $POD_NAME --output=yaml來檢查其詳細狀態。

對不起，困難！