ローリングアップデート中は、トラフィックを受信するために起動される前に、アップデートされたポッドの準備が整っていることを確認する必要があります。 準備ゲートを設定して、ポッドが起動される前に準備ができていることを確認できます。 Application Load Balancer (ALB) Ingressコントローラーを使用すると、準備ゲートを有効にして、Container Service for Kubernetes (ACK) クラスター内のポッドのステータスを継続的に監視できます。 ポッドのステータスが準備完了に変わると、ポッドが起動され、バックエンドサーバーグループに追加されます。 その後、トラフィックはポッドに転送されます。
前提条件
ACKマネージドクラスターまたはACKサーバーレスクラスターが作成されます。 詳細については、「ACKサーバーレスクラスターの作成」または「ACKマネージドクラスターの作成」をご参照ください。
ALB Ingressコントローラーがクラスターにインストールされています。 詳細については、「ALB Ingressコントローラーの管理」をご参照ください。
説明ALB Ingressを使用してACK専用クラスターにデプロイされたサービスにアクセスするには、まずクラスターにALB Ingressコントローラーへのアクセスを許可する必要があります。 詳細については、「ACK専用クラスターにALB Ingressコントローラーへのアクセスを許可する」をご参照ください。
kubectlクライアントがクラスターに接続されています。 詳細については、「クラスターのkubeconfigファイルを取得し、kubectlを使用してクラスターに接続する」をご参照ください。
制御ポリシー機能の動作
ACKは、アプリケーションの可用性を向上させるために、livenessプローブ、readinessプローブ、およびstartupプローブを使用してポッドのヘルスステータス、準備状況、および起動条件を確認します。 livenessプローブ、readinessプローブ、および起動プローブを設定するときに、プローブ間隔、タイムアウト期間、正常しきい値、および異常しきい値を指定できます。 これらのプローブをコマンド、TCPソケット、またはHTTPリクエストで定義して、コンテナの正常性を検証できます。 詳細については、「Liveness、Readiness、Startup Probesの設定」をご参照ください。
プローブタイプ | 説明 |
Livenessプローブ | kubeletは、livenessプローブを使用してコンテナが生きているかどうかを確認し、異常なコンテナを強制終了し、再起動ポリシーに基づいてコンテナを再起動します。 コンテナがlivenessプローブによってプローブされていない場合、kubeletは、コンテナがlivenessプローブに対してSuccessを返し、したがってコンテナが生きているとみなします。 |
準備プローブ | Readinessプローブを使用して、コンテナがリクエストを受信できるかどうかを確認します。 Ready状態のポッドのみがリクエストを受信できます。 サービスとエンドポイントの関係は、ポッドの準備状態によって異なります。
|
スタートアッププローブ | kubeletは起動プローブを使用して、コンテナがいつ起動したかを学習します。 起動プローブを使用すると、コンテナの起動後にのみlivenessプローブとreadinessプローブがコンテナに送信されるようにすることができます。 スタートアッププローブを使用して、開始が遅いコンテナに対してライブネスチェックを実行し、コンテナが開始前にkubeletによって殺されないようにすることができます。 |
準備完了プローブを使用する場合、ポッドの準備完了フィールドの値は、ポッド内のコンテナのステータスに基づいてkubeletによって決定されます。 ただし、複雑なアプリケーションでは、コンテナ内の準備サービスをきめ細かく制御する必要があります。 これを行うには、ポッドのReadyフィールドの値を制御する必要があります。
準備ゲートを使用すると、1つ以上のカスタム準備条件を設定して、ポッドの準備ができているかどうかを確認できます。 これらのカスタム条件は、外部コントローラで設定されます。 Kubernetesは、準備ゲートで指定されたすべての条件がTrueの場合にのみ、ポッドの準備ができていると見なします。
ACKクラスターがポッドのステータスを継続的に監視できるように、ALB Ingressコントローラーで準備ゲートを設定できます。 ポッドは、準備完了状態になるまで開始とは見なされません。 開始されたポッドがバックエンドサーバーグループに追加され、トラフィックがポッドに転送されます。
デプロイの準備ゲートのカスタム条件target-health.alb.k8s.alibabacloudを設定できます。 これにより、ACKクラスターはポッドのステータスを継続的に監視できます。 ACKクラスターは、ポッドの準備ができたと見なし、ALB Ingressコントローラーがポッドをバックエンドサーバーグループに追加した後にのみ、トラフィックをポッドに転送し始めます。
手順
tea-service.yamlという名前のファイルを作成し、準備ゲートのカスタム条件を設定します。
tea-service.yamlという名前のファイルを作成し、次の内容をファイルに追加して、
teaという名前のデプロイとtea-svcという名前のサービスをデプロイします。 Deployment:の準備ゲートのカスタム条件を設定しtarget-health.alb。 Kubernetes、 alibabacloudこれにより、ACKクラスターはポッドのステータスを継続的に監視できます。 ポッドは、準備完了状態になるまで開始とは見なされません。 起動したポッドがバックエンドサーバーグループに追加されます。apiVersion: apps/v1 kind: 配置 メタデータ: 名前: お茶 spec: replicas: 3 セレクタ: matchLabels: app: tea template: metadata: ラベル: app: tea 仕様: containers: - name: tea image: registry.cn-hangzhou.aliyuncs.com/acs-sample/nginxdemos:latest ポート: -containerPort: 80 # 準備ゲートの設定 readinessGates: -conditionType: target-health.alb.k8s.alibabacloud --- apiVersion: v1 種類: サービス メタデータ: 名前: tea-svc spec: ポート: - port: 80 targetPort: 80 protocol: TCP セレクタ: app: tea タイプ: NodePort次のコマンドを実行して、Deployment andServiceをデプロイします。
kubectl apply -f tea-service.yaml次のコマンドを実行して、準備ゲートの設定が有効かどうかを確認します。
kubectl get pods -o yaml | grep 'target-health'期待される出力:
-conditionType:target-health.alb.k8s.alibabacloud メッセージ: correspondingconditionofpodreadinessgate "target-health.alb.k8s.alibabacLoud"
関連ドキュメント
ALB Ingressを使用してACKクラスターのサービスにアクセスする方法の詳細については、「ALB Ingressの使用を開始する」をご参照ください。
ALB Ingressは、ACKクラスターにデプロイされたサービスへの外部ユーザーアクセスを管理し、レイヤー7の負荷分散機能を提供するために使用されるAPIオブジェクトです。 詳細については、「高度なALB Ingress設定」をご参照ください。
ALB Ingressに関連する問題のトラブルシューティング方法の詳細については、「ALB Ingressコントローラーのトラブルシューティング」および「ALB Ingress FAQ」をご参照ください。