kubernetesサービスのIPに到達できません

Question

だから、Kubernetes on CoreOS Manual Installation Guideを使ってkubernetsクラスタを稼働させています。

$ 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てきました。ビジーボックスやカールコンテナがIPを取得すると、Podネットワークはうまくいくように見えます。しかし、サービスネットワークには問題があります。もともと私はkube-dnsを配備するときにこれに遭遇しました。サービスIP 10.3.0.1に到達できませんでした。そのため、kube-dnsはすべてのコンテナを開始できず、DNSは最終的には機能しませんでした。

[ root@curl-2421989462-h0dr7:/ ]$ curl https://10.3.0.1 
curl: (7) Failed to connect to 10.3.0.1 port 443: No route to host 

[ root@curl-2421989462-h0dr7:/ ]$ 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 

コンテナ内の唯一のデフォルトルートがあることをOKらしい：カールポッド内から

は、私は、問題を再現することができます。私が理解しているように、（デフォルトルートへの）リクエストはワーカーノード上の kube-proxyによって傍受され、IPがiptables経由でマスター公開IPに変換されるマスターノードのプロキシに転送されます。

ありブリッジ/ netfilterののsysctlの設定と共通の問題のようですが、それは私のセットアップで罰金だ：

core@coreos-worker-1 ~ $ sysctl net.bridge.bridge-nf-call-iptables 
net.bridge.bridge-nf-call-iptables = 1 

私は理解が不足しているとして、私は、トラブルシューティングするために本当の苦労を抱えていますサービスIPがどのように使用されているか、トラフィックフローの観点からサービスネットワークがどのように動作するのか、そしてこれを最適にデバッグする方法について説明します。

だから私は持っている質問をhere're：サービスネットワーク（この場合は10.3.0.1）の第一IPが使用され

• 何？
• トラフィックフローの説明は正しいですか？そうでない場合、コンテナがサービスIPに到達するためにはどのようなステップが必要ですか？
• トラフィックフローの各ステップをデバッグする最適な方法は何ですか。 （私は何がログから間違っているのか分からない）

ありがとう！

Answer 1

サービスネットワークは、サービスに対して固定IPを提供します。ルーティング可能なネットワークではありません（ip roには何も表示する予定もなく、pingを行う予定はありません）。各ノードでkube-proxyによって管理されるiptablesルールのコレクションです（Podではなくノードのiptables -L; iptables -t nat -Lを参照）。これらのvirtual IPs（写真参照）は、通常、サービスで定義されている特定のラベルセットを持つ（常にではありませんが）ポッドのポートであるエンドポイント（kubectl get ep）のロードバランシングプロキシとして機能します。

サービスネットワーク上の最初のIPは、kube-apiserver自体に到達するためのものです。それはポート443（kubectl describe svc kubernetes）でリッスンしています。

トラブルシューティングは、ネットワーク/クラスタの設定によって異なります。私は一般的にチェックします：

• 各ノードでkube-proxyが実行されていますか？いくつかの設定ではsystemd経由で実行され、他の設定では各ノードのPodをスケジュールするDeamonSetがあります。セットアップ時には、kubeletsによって作成された静的ポッドとして/etc/kubernetes/manifests/kube-proxy.yaml
• に配置され、手がかりを見つけることができます（いくつか投稿できますか？）
• kube-proxyをuserspaceモードに変更します。繰り返しますが、詳細は設定によって異なります。あなたのために、私は上記のファイルにあります。 --proxy-mode=userspaceをパラメータとしてを各ノードに追加
• オーバーレイ（ポッド）ネットワークは機能していますか？

あなたがコメントを残した場合、私はあなたに戻って取得します。..

Answer 2

私は、同じ問題を持っていた私が持っていた「マスター」のパラメータについてKUBE-proxy.yamlにおける構成の問題であることが判明IPアドレスは--master = 192.168.3.240と同じですが、実際には次のようなURLにする必要があります。--master = https://192.168.3.240

FYI my kube-proxyは正常に--proxy-mode = iptables（v1.6。 x）

Answer 3

私はこの同じ問題を抱えていました。私にとっては究極の解決策は、すべてのノードでIP転送を有効にしていたことです私は怠け者だった。

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

その後、サービスIPとDNSがすぐに開始されました。