Amazon EKS クラスターで Kubernetes Service にアクセスした際に表示される、HTTP 503 (サービス利用不可) エラーを解決するにはどうすればよいですか?

最終更新日: 2022 年 7 月 19 日

Amazon Elastic Kubernetes Service (Amazon EKS) クラスターで実行されている Kubernetes サービスに接続すると、HTTP 503 (サービス利用不可) エラーが発生します。

簡単な説明

HTTP 503 エラーはサーバー側のエラーです。ロードバランサー用の設定が行われた Amazon EKS クラスター内の、Kubernetes Service ポッドに接続した場合に発生します。

HTTP 504 エラーのトラブルシューティングについては、「Amazon EKS で HTTP 504 エラーを解決する方法を教えてください。」を参照してください。

HTTP 503 エラーのトラブルシューティングを行うには、以下のステップを完了します。

解決方法

ポッドのラベルと Kubernetes Service セレクタで指定された値が、一致しているかどうかを確認する

1.    以下のコマンドを実行して、セレクタの値を取得します。

$ kubectl describe service service_name -n your_namespace

注: service_name は実際のサービス名に、your_namespace はサービスの名前空間に置き換えます。

出力例:

Name:                     service-name
Namespace:                pod-name
Labels:                   none
Annotations:              none
Selector:                 app.kubernetes.io/name=namespace
Type:                     NodePort
IP Families:              none
IP:                       10.100.17.189
IPs:                      10.100.17.189
Port:                     unset  80/TCP
TargetPort:               80/TCP
NodePort:                 unset  31560/TCP
Endpoints:                none
Session Affinity:         none
External Traffic Policy:  Cluster
Events:                   none

上記の例では、サンプルセレクタの値は app.kubernetes.io/name=namespace として出力されています。

2.    app.kubernetes.io/name=namespace というラベルの付いたポッドがあるかどうかを確認します。

$ kubectl get pods -n your_namespace -l "app.kubernetes.io/name=namespace"

出力例:

No resources found in your_namespace namespace.

検索した値を持つリソースが見つからないのであれば、HTTP 503 エラーの原因となっています。

Kubernetes Service 用に定義されたポッドが実行中であることを確認する

Kubernetes Service セレクタのラベルを使用して、ポッドが存在し「 Running」状態であることを確認します。

$ kubectl -n your_namespace get pods -l "app.kubernetes.io/name=your_namespace"

出力:

NAME                               READY   STATUS             RESTARTS   AGE
POD_NAME                           0/1     ImagePullBackOff   0          3m54s

Kubernetes デプロイの readiness プローブを、ポッドが通過できるかどうかを確認する

1.    readiness プローブを、アプリケーションのポッドが通過可能であることを確認します。詳細については、Kubernetes ウェブサイトの「Configure liveness, readiness, and startup probes」を参照してください。

2.    ポッドの readiness プローブを確認します。

$ kubectl describe pod pod_name -n your_namespace | grep -i readiness

注:pod_name は実際のポッド名に、your_namespace は実際の名前空間に置き換えます。

出力例:

Readiness:      tcp-socket :8080 delay=5s timeout=1s period=2s #success=1 #failure=3
Warning  Unhealthy  2m13s (x298 over 12m)  kubelet            Readiness probe failed:

前の出力では、readiness プローブが失敗したことがわかります。

注: このステップでは、アプリケーションが正しいパスとポートでリッスンしている場合にのみ、有用な出力が得られます。curl-Ivk コマンドを使用して curl 出力をチェックし、サービスレベルで定義されたパスが有効な応答を得ていることを確認します。例えば、200 ミリ秒は応答時間としては適切です。

Classic Load Balancer の容量を確認する

断続的な HTTP 503 エラーが発生した場合、Classic Load Balancer ではリクエストを処理するための容量が不足します。この問題を解決するには、Classic Load Balancer に十分な容量があり、ワーカーノードがリクエストレートに対応できることを確認します。

インスタンスが登録済みであることを確認する

また、登録済みのインスタンスがない場合も HTTP 503 エラーが発生します。この問題を解決するには、以下の操作を試します。

  • ワーカーノードのセキュリティグループに、ノードポート上のワーカーノードへのポートアクセスを許可するインバウンドルールがあることを確認します。また、ノードポートの範囲でネットワークトラフィックをブロックしている NAT ルールが存在しないことを確認します。
  • Classic Load Balancer に指定されているカスタムセキュリティグループに、ワーカーノード上のインバウンドアクセスが許可されていることを確認します。
  • サブネットで指定されている、すべてのアベイラビリティーゾーンにワーカーノードがあることを確認します。