kubernetes 1.10 で flannel を使用し、CRI として containerd を使用して kube-dns を正しく構成する方法を理解するのに苦労しています。
kube-dns の実行に失敗し、次のエラーが表示されます:
kubectl -n kube-system logs kube-dns-595fdb6c46-9tvn9 -c kubedns
I0424 14:56:34.944476 1 dns.go:219] Waiting for [endpoints services] to be initialized from apiserver...
I0424 14:56:35.444469 1 dns.go:219] Waiting for [endpoints services] to be initialized from apiserver...
E0424 14:56:35.815863 1 reflector.go:201] k8s.io/dns/pkg/dns/dns.go:192: Failed to list *v1.Service: Get https://10.96.0.1:443/api/v1/services?resourceVersion=0: dial tcp 10.96.0.1:443: getsockopt: no route to host
E0424 14:56:35.815863 1 reflector.go:201] k8s.io/dns/pkg/dns/dns.go:189: Failed to list *v1.Endpoints: Get https://10.96.0.1:443/api/v1/endpoints?resourceVersion=0: dial tcp 10.96.0.1:443: getsockopt: no route to host
I0424 14:56:35.944444 1 dns.go:219] Waiting for [endpoints services] to be initialized from apiserver...
I0424 14:56:36.444462 1 dns.go:219] Waiting for [endpoints services] to be initialized from apiserver...
I0424 14:56:36.944507 1 dns.go:219] Waiting for [endpoints services] to be initialized from apiserver...
F0424 14:56:37.444434 1 dns.go:209] Timeout waiting for initialization
kubectl -n kube-system describe pod kube-dns-595fdb6c46-9tvn9
Type Reason Age From Message
---- ------ ---- ---- -------
Warning Unhealthy 47m (x181 over 3h) kubelet, worker1 Readiness probe failed: Get http://10.244.0.2:8081/readiness: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)
Warning BackOff 27m (x519 over 3h) kubelet, worker1 Back-off restarting failed container
Normal Killing 17m (x44 over 3h) kubelet, worker1 Killing container with id containerd://dnsmasq:Container failed liveness probe.. Container will be killed and recreated.
Warning Unhealthy 12m (x178 over 3h) kubelet, worker1 Liveness probe failed: Get http://10.244.0.2:10054/metrics: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)
Warning BackOff 2m (x855 over 3h) kubelet, worker1 Back-off restarting failed container
実際、10.96.0.1 エンドポイントへのルートはありません。
ip route
default via 10.240.0.254 dev ens160
10.240.0.0/24 dev ens160 proto kernel scope link src 10.240.0.21
10.244.0.0/24 via 10.244.0.0 dev flannel.1 onlink
10.244.0.0/16 dev cni0 proto kernel scope link src 10.244.0.1
10.244.1.0/24 via 10.244.1.0 dev flannel.1 onlink
10.244.2.0/24 via 10.244.2.0 dev flannel.1 onlink
10.244.4.0/24 via 10.244.4.0 dev flannel.1 onlink
10.244.5.0/24 via 10.244.5.0 dev flannel.1 onlink
クラスター サービスのアドレス範囲と関連するルートの構成を担当するのは何ですか? コンテナー ランタイム、オーバーレイ ネットワーク (この場合はフランネル)、またはその他の何かですか? どこで構成する必要がありますか?
10-containerd-net.conflistホストとポッド ネットワーク間のブリッジを構成します。ここでもサービスネットワークを構成できますか?
cat /etc/cni/net.d/10-containerd-net.conflist
{
"cniVersion": "0.3.1",
"name": "containerd-net",
"plugins": [
{
"type": "bridge",
"bridge": "cni0",
"isGateway": true,
"ipMasq": true,
"promiscMode": true,
"ipam": {
"type": "host-local",
"subnet": "10.244.0.0/16",
"routes": [
{ "dst": "0.0.0.0/0" }
]
}
},
{
"type": "portmap",
"capabilities": {"portMappings": true}
}
]
}
編集：
2016年からこれに出くわしました：
数週間前の時点で (リリースを忘れましたが、x != 0 の 1.2.x でした) (#24429) サービス IP 宛てのノードに到着するすべてのトラフィックが次のように処理されるようにルーティングを修正しました。ノードポートに来た場合。これは、サービス クラスター IP 範囲の静的ルートを 1 つ以上のノードに設定できる必要があり、ノードがブリッジとして機能することを意味します。これは、ほとんどの人がオーバーレイをブリッジするためにフランネルで行うのと同じトリックです.
不完全ですが、機能します。将来、最適な動作 (クライアント IP を失わないこと) が必要な場合は、ルーティングをより正確にする必要があります。
それはまだ関係がありますか？サービス CIDR の静的ルートをセットアップする必要はありますか? kube-proxyそれとも、フランネルやコンテナではなく、実際に問題がありますか?
私のフランネル構成:
cat /etc/cni/net.d/10-flannel.conflist
{
"name": "cbr0",
"plugins": [
{
"type": "flannel",
"delegate": {
"hairpinMode": true,
"isDefaultGateway": true
}
},
{
"type": "portmap",
"capabilities": {
"portMappings": true
}
}
]
}
そして kube-proxy:
[Unit]
Description=Kubernetes Kube Proxy
Documentation=https://github.com/kubernetes/kubernetes
[Service]
ExecStart=/usr/local/bin/kube-proxy \
--cluster-cidr=10.244.0.0/16 \
--feature-gates=SupportIPVSProxyMode=true \
--ipvs-min-sync-period=5s \
--ipvs-sync-period=5s \
--ipvs-scheduler=rr \
--kubeconfig=/etc/kubernetes/kube-proxy.conf \
--logtostderr=true \
--master=https://192.168.160.1:6443 \
--proxy-mode=ipvs \
--v=2
Restart=on-failure
RestartSec=5
[Install]
WantedBy=multi-user.target
編集：
kube-proxyのデバッグ手順を見るkube-proxyと、マスターに接続できないようです。これが問題の大部分を占めていると思います。HAProxy ロードバランサーの背後に 3 つのコントローラー/マスター ノードがあります。これは192.168.160.1:6443、上の各マスターにバインドされ、ラウンド ロビンを転送し10.240.0.1[1|2|3]:6443ます。これは、上記の output/configs で確認できます。
ではkube-proxy.service、 を指定しています--master=192.168.160.1:6443。ポート 443 への接続が試行されるのはなぜですか? これを変更できますか? ポート フラグがないようです。何らかの理由でポート 443 にする必要がありますか?