クラシック: クラスター内のリソースにアクセスできないのはなぜですか?

クラシック・インフラストラクチャー

クラスター内のワーカー・ノードがプライベート・ネットワーク上で通信できない場合は、さまざまな症状が発生する可能性があります。

kubectl exec、attach、logs、proxy、または port-forward を実行した場合のサンプル・エラー・メッセージ:
```
Error from server: error dialing backend: dial tcp XXX.XXX.XXX:10250: getsockopt: connection timed out
```
kubectl proxy は正常に実行されたが Kubernetes ダッシュボードを使用できない場合のサンプル・エラー・メッセージ:
```
timeout on 172.xxx.xxx.xxx
```
kubectl proxy が失敗したか、サービスへの接続が失敗した場合のサンプル・エラー・メッセージ:
```
Connection refused
```
```
Connection timed out
```
```
Unable to connect to the server: net/http: TLS handshake timeout
```

クラスターのリソースにアクセスするには、ワーカー・ノードがプライベート・ネットワークで通信可能でなければなりません。 Vyatta などの別のファイアウォールをセットアップしたか、IBM Cloud インフラストラクチャー・アカウントの既存のファイアウォール設定をカスタマイズした可能性があります。

IBM Cloud Kubernetes Service では、ワーカー・ノードと Kubernetes マスター間で通信を行うには、特定の IP アドレスとポートが開いている必要があります。ワーカー・ノードが複数のゾーンに分散されている場合、VLAN スパンニングを有効にして、プライベート・ネットワーク通信を許可する必要があります。ワーカー・ノードが再ロード・ループにはまっている場合にも、ワーカー・ノード間の通信が不能になることがあります。

ワーカー・ノードの状態を確認します。

クラスター内のワーカー・ノードをリストして、ワーカー・ノードが Reloading 状態で停滞していないことを確認します。
```
ibmcloud ks worker ls --cluster <cluster_name_or_id>
```
複数ゾーン・クラスターを使用しており、アカウントで VRF が有効になっていない場合は、アカウントに対して VLAN スパンニングが有効になっていることを確認します。
Vyatta またはカスタム・ファイアウォールを設定している場合は、必要なポートが開いており、クラスターがインフラストラクチャーのリソースとサービスへのアクセスを許可されていることを確認します。
問題が解決しない場合は、サポートにお問い合わせください。サポート Case を開きます。ケースの詳細には、関連するログファイル、エラーメッセージ、コマンド出力を必ず含めてください。