非常に奇妙な問題があります。 kubectl cli は VPN 内のクラスタに接続できません。
私の背景：
- オペレーティングシステムarchlinux
- kubectlクライアントバージョン：v1.28.1（最新）
- 私のコンピュータでは、APIエンドポイントのカールが正しく機能します。
- ブラウザでAPIを開くこともできます
- go_client転送を使用する小さなgoモジュールも書いていますが、それも機能します。
- リモートクラスタのバージョンと一致するようにkubectlクライアントをダウングレードしようとしましたが、機能しませんでした。
すべてが大丈夫だと思います。とは別にKubeker。
kubectl get pods --request-timeout='5s' -n my-ns -v=99
I0913 17:43:34.500572 60035 loader.go:395] Config loaded from file: /home/alexander/.config/kube/config
I0913 17:43:34.501699 60035 round_trippers.go:466] curl -v -XGET -H "Accept: application/json;g=apidiscovery.k8s.io;v=v2beta1;as=APIGroupDiscoveryList,application/json" -H "User-Agent: kubectl/v1.28.1 (linux/amd64) kubernetes/8dc49c4" 'https://172.16.10.10:6443/api?timeout=5s'
I0913 17:43:34.556074 60035 round_trippers.go:510] HTTP Trace: Dial to tcp:172.16.10.10:6443 succeed
I0913 17:43:39.503205 60035 round_trippers.go:553] GET https://172.16.10.10:6443/api?timeout=5s in 5001 milliseconds
I0913 17:43:39.503231 60035 round_trippers.go:570] HTTP Statistics: DNSLookup 0 ms Dial 43 ms TLSHandshake 47 ms Duration 5001 ms
I0913 17:43:39.503241 60035 round_trippers.go:577] Response Headers:
E0913 17:43:39.503298 60035 memcache.go:265] couldn't get current server API group list: Get "https://172.16.10.10:6443/api?timeout=5s": net/http: request canceled (Client.Timeout exceeded while awaiting headers)
I0913 17:43:39.503312 60035 cached_discovery.go:120] skipped caching discovery info due to Get "https://172.16.10.10:6443/api?timeout=5s": net/http: request canceled (Client.Timeout exceeded while awaiting headers)
I0913 17:43:39.503398 60035 round_trippers.go:466] curl -v -XGET -H "Accept: application/json;g=apidiscovery.k8s.io;v=v2beta1;as=APIGroupDiscoveryList,application/json" -H "User-Agent: kubectl/v1.28.1 (linux/amd64) kubernetes/8dc49c4" 'https://172.16.10.10:6443/api?timeout=5s'
私のIPテーブルには、172.17と172.18の範囲を使用するいくつかの「docker」関連の設定が含まれていますが、「curl」とブラウザが正常に動作するため、これが何に関連しているかわかりません。
IPルーティングもよさそうです。トラフィックはVPNの「トン」インターフェイスを介してルーティングされます。
default via 192.168.91.249 dev tun0 proto static metric 50
default via 192.168.10.254 dev enp5s0 proto dhcp src 192.168.10.134 metric 100
default via 192.168.10.254 dev wlp3s0 proto dhcp src 192.168.10.119 metric 600
172.16.100.0/24 via 192.168.91.249 dev tun0 proto static metric 50
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1
172.18.0.0/16 dev br-53500e17974d proto kernel scope link src 172.18.0.1
172.19.0.0/16 dev br-c1725b2d64cd proto kernel scope link src 172.19.0.1 linkdown
172.28.0.0/16 dev br-788b95918c9a proto kernel scope link src 172.28.0.1
192.168.10.0/24 dev enp5s0 proto kernel scope link src 192.168.10.134 metric 100
192.168.10.0/24 dev wlp3s0 proto kernel scope link src 192.168.10.119 metric 600
192.168.10.254 dev enp5s0 proto static scope link metric 50
192.168.91.1 via 192.168.91.249 dev tun0 proto static metric 50
192.168.91.249 dev tun0 proto kernel scope link src 192.168.91.250 metric 50
196.179.246.130 via 192.168.10.254 dev enp5s0 proto static metric 50
ベストアンサー1
多くの悩みの終わりに、私たちはサーバーへのUDPネットワーク接続がブロックされていることを発見しました。修正 1400「クライアント構成で問題が解決しました。
私が正しく理解した場合、この値はパケットサイズがトンネルを通過するように強制し、私たちの場合は問題を解決しました。
多くの人が推奨する「フラグメント」変数もありますが、サーバー側ではアクティブではありません。
詳細は：https://openvpn.net/community-resources/reference-manual-for-openvpn-2-4/