Kubernetesバージョン:
クライアントバージョン:version.Info {Major: "1"、Minor: "5"、GitVersion: "v1.5.2"、GitCommit: "08e099554f3c31f6e6f07b448ab3ed78d0520507"、GitTreeState: "clean"、BuildDate: "2017-01-12T04:57: 25Z "、GoVersion:" go1.7.4 "、コンパイラ:" gc "、プラットフォーム:" darwin / amd64 "}
サーバーバージョン:version.Info {Major: "1"、Minor: "5"、GitVersion: "v1.5.3"、GitCommit: "029c3a408176b55c30846f0faedf56aae5992e9b"、GitTreeState: "clean"、BuildDate: "2017-02-15T06:34: 56Z "、GoVersion:" go1.7.4 "、コンパイラ:" gc "、プラットフォーム:" linux / amd64 "}
マスターとミニオンのDockerバージョン:
$ docker -v
Dockerバージョン1.13.1、ビルド092cba3
環境:
uname -a
):ツールのインストール:
kubeadm
その他:
何が起こったのか:
kubeadmページを使用して、3ノードクラスターをインストールしました。
$ kc describe nodes | awk '/Addresses/ {print $2}' | awk -F',' '{print $3}'
knode-0
knode-1
knode-master
インストールされた運河ポッドネットワーク:
kubectl create -f https://raw.githubusercontent.com/tigera/canal/master/k8sinstall/kubeadm/canal.yaml
この時点では、ノード、サービス、ポッドは正常でした。 ダッシュボードに進みました
kubectl create -f https://rawgit.com/kubernetes/dashboard/master/src/deploy/kubernetes-dashboard.yaml
$ kubectl get -n kube-system services
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
canal-etcd 10.96.232.136 <none> 6666/TCP 5m
kube-dns 10.96.0.10 <none> 53/UDP,53/TCP 13h
kubernetes-dashboard 10.110.163.186 <nodes> 80:31699/TCP 1m
あなたが起こると期待したこと:
サービスドキュメントのnodePortセクションは、nodePortがすべてのnodeIPで表示される必要があることを示しています。
私の場合、すべてのnodeIPがダッシュボードのnodePort 31699でリクエストに応答し、ダッシュボードポッドに転送しているわけではありません。
ポッドをホストしているノード(またはミニオン)のみがブラウザの要求に応答しているようです。 他のノード(またはミニオン)は応答しません。
それを再現する方法(可能な限り最小限かつ正確に):
_knode-1(ミニオン)から:_
$ sudo docker ps -a | grep dashboard
79e23eff2c26 gcr.io/google_containers/kubernetes-dashboard-amd64:v1.5.1 "/dashboard --port..." 44 minutes ago Up 43 minutes
_クラスター外のダッシュボードへのcurlアクセス:_
接続が_knode-0:31699にタイムアウトしました
$ curl -m 2 -O http://knode-0:31699/#/workload?namespace=default
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- 0:00:01 --:--:-- 0curl: (28) Connection timed out after 2003 milliseconds
knodeから正常にダウンロード-1:31699
$ curl -m 2 -O http://knode-1:31699/#/workload?namespace=default
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 811 100 811 0 0 18097 0 --:--:-- --:--:-- --:--:-- 18431
* iptables * :
_knode-1から(nodePort 31699アクセス可能):_
$ sudo iptables-save | grep dashboard
-A KUBE-NODEPORTS -p tcp -m comment --comment "kube-system/kubernetes-dashboard:" -m tcp --dport 31699 -j KUBE-MARK-MASQ
-A KUBE-NODEPORTS -p tcp -m comment --comment "kube-system/kubernetes-dashboard:" -m tcp --dport 31699 -j KUBE-SVC-XGLOHA7QRQ3V22RZ
-A KUBE-SEP-4CN2KLL64AIMJOUC -s 192.168.92.6/32 -m comment --comment "kube-system/kubernetes-dashboard:" -j KUBE-MARK-MASQ
-A KUBE-SEP-4CN2KLL64AIMJOUC -p tcp -m comment --comment "kube-system/kubernetes-dashboard:" -m tcp -j DNAT --to-destination 192.168.92.6:9090
-A KUBE-SERVICES -d 10.110.163.186/32 -p tcp -m comment --comment "kube-system/kubernetes-dashboard: cluster IP" -m tcp --dport 80 -j KUBE-SVC-XGLOHA7QRQ3V22RZ
-A KUBE-SVC-XGLOHA7QRQ3V22RZ -m comment --comment "kube-system/kubernetes-dashboard:" -j KUBE-SEP-4CN2KLL64AIMJOUC
_knode-0から(nodePort 31699にアクセスできません):_
$ sudo iptables-save | grep dashboard
-A KUBE-NODEPORTS -p tcp -m comment --comment "kube-system/kubernetes-dashboard:" -m tcp --dport 31699 -j KUBE-MARK-MASQ
-A KUBE-NODEPORTS -p tcp -m comment --comment "kube-system/kubernetes-dashboard:" -m tcp --dport 31699 -j KUBE-SVC-XGLOHA7QRQ3V22RZ
-A KUBE-SEP-4CN2KLL64AIMJOUC -s 192.168.92.6/32 -m comment --comment "kube-system/kubernetes-dashboard:" -j KUBE-MARK-MASQ
-A KUBE-SEP-4CN2KLL64AIMJOUC -p tcp -m comment --comment "kube-system/kubernetes-dashboard:" -m tcp -j DNAT --to-destination 192.168.92.6:9090
-A KUBE-SERVICES -d 10.110.163.186/32 -p tcp -m comment --comment "kube-system/kubernetes-dashboard: cluster IP" -m tcp --dport 80 -j KUBE-SVC-XGLOHA7QRQ3V22RZ
-A KUBE-SVC-XGLOHA7QRQ3V22RZ -m comment --comment "kube-system/kubernetes-dashboard:" -j KUBE-SEP-4CN2KLL64AIMJOUC
私たちが知る必要がある他のこと:
同じ動作がRHEL7.3でも再現可能です。
同じ問題が発生しました。
iptables -P FORWARD ACCEPT
を実行すると、問題が解決する場合があります。 ただし、dockerv1.13.1と統合した場合のバグかどうかはわかりません
最も参考になるコメント
同じ問題が発生しました。
iptables -P FORWARD ACCEPT
を実行すると、問題が解決する場合があります。 ただし、dockerv1.13.1と統合した場合のバグかどうかはわかりません