☰

Kubernetes サービスが異なるワーカーのポッドにアクセスする際にタイムアウトする

tag-icon • tag-icon amazon-web-services kubernetes kubeadm
Kubernetes サービスが異なるワーカーのポッドにアクセスする際にタイムアウトする

EC2 インスタンス上に Kubernetes ワーカーのペアを立ち上げようとしていますが、サービスが認識できるはずのポッドのすべてを「認識」できないという問題が発生しています。

私の環境は、AWS Snowball RedとBlueのペアで、クラスターはcontrol、、、worker-redおよび[1]のようになります。ポート8080でGETを待ち、ローカルホスト名で応答するダミーのPythonサーバーをデプロイしています。両方と少なくとも1つのポッドを持つworker-blue十分なレプリカを設定しました。最後に、次のようなサービスを作成しました。worker-redworker-blue

spec:
    type: NodePort
    selector:
        app: hello-server
    ports:
        - port: 8080
          targetPort: 8080
          nodePort: 30080

ポッドが起動していることを確認できるようになりました

kubectl get pods -o wide
NAME                                      READY   STATUS    RESTARTS   AGE   IP              NODE          NOMINATED NODE   READINESS GATES
hello-world-deployment-587468bdb7-hf4dq   1/1     Running   0          27m   192.168.1.116   worker.red    <none>           <none>
hello-world-deployment-587468bdb7-mclhm   1/1     Running   0          27m   192.168.1.126   worker.blue   <none>           <none>

今、私はそれらをカールさせようとしています

curl worker-red:30080
greetings from hello-world-deployment-587468bdb7-hf4dq

curl worker-blue:30080
greetings from hello-world-deployment-587468bdb7-mclhm

これが約半分の時間で発生します。残りの半分の時間では、curl はタイムアウト エラーで失敗します。具体的には、worker-red を curling すると hf4dq からの応答のみが得られ、worker-blue を curling すると mclhm からの応答のみが得られます。worker-blue を閉鎖してドレインし、両方のポッドが worker-red で実行されるようにすると、タイムアウトは発生せず、両方のポッドが応答します。

NodePort サービスは、私が curling しているホスト上にないポッドに到達していないようです。私の理解では、これはサービスが動作する仕組みではありません。何が足りないのでしょうか?

[1] 2つのワーカーを両方ともRedに設定すると、私が説明したのと同じ問題が発生しますが、これが私の主な使用例なので、これに集中します。

答え1

ここで何が問題なのかを簡単に言うのは難しいですが、問題のトラブルシューティングを行うために実行できる手順がいくつかあります。

  1. デバッグポッド特に、ログに何か疑わしい点がないか確認してください。

  • kubectl logs ${POD_NAME} ${CONTAINER_NAME}

  • kubectl logs --previous ${POD_NAME} ${CONTAINER_NAME}

  1. デバッグサービスたとえば、次の点を確認します。

  • サービスは存在しますか?

  • サービスは DNS 名で機能しますか?

  • サービスは IP によって機能しますか?

  • サービスは正しく定義されていますか?

  • サービスにはエンドポイントがありますか?

  • kube-proxy は動作していますか?

これらの手順を実行すると、問題の原因を見つけるのに役立ち、サービスの背後にある仕組みをより深く理解できるようになります。

答え2

タイプ サービスを使用しているNodePort場合、観察されている内容は非常に予想どおりです。

サービスは、2つの異なるノードで実行されている2つのポッドをマッチングしています。サービスはタイプであるためNodePort、サービスのポッドとそれが実行されているノードの間には固有の関連付けがあります。エンドポイントをcurlするとworker-red、のみポッドからの応答を取得できませんworker-red。これは、他のポッドが別のエンドポイントに関連付けられておりworker-blue:<node-port>、エンドポイントからアクセスできないためですworker-red。はい、これは同じサービスですが、それぞれ異なるホスト名を持つ 2 つのエンドポイントによってサポートされています。

基本的にサービスはこのようにNodePort機能します。

同じノードに両方をバンドルすると、両方のポッドが同じノードホスト名からアクセス可能になるため、両方をcurlすると機能します。これで、両方のエンドポイントが異なるポートにマップされますが、同じホスト名。

これをさらに理解するには、サービス タイプを に変更してみてください。そうすると、スケジュールされている場所に関係なく、同じホスト名を使用して両方のポッドにアクセスできることがわかります。このホスト名/IP アドレスは、サービス内のすべてのポッドに共通するLoadBalancerのアドレスになります。LoadBalancer

これであなたの混乱が解消されることを願っています!

関連情報