:推奨されるワークロード設定

各ポッドの要求リソース (リクエストと制限)

ACKクラスタでは、過剰なポッドが1つのノードにスケジュールされ得る。 これにより、ノードがオーバーロードされ、ノードはサービスを提供できなくなります。

この問題を回避するには、ポッドをクラスターにデプロイするときに、ポッドのリソース要求とリソース制限を指定します。 これにより、十分なアイドルリソースを持つノードにポッドがデプロイされます。 次の例では、NGINXポッドには1 vCPUと1,024 MBのメモリが必要です。 ポッドが実行中の場合、リソース使用量の上限は2 vCPU、メモリ4,096 MBです。

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx
    resources: # Resource claim.
      requests:
        memory: "1024Mi"
        cpu: "1000m"
      limits:
        memory: "4096Mi"
        cpu: "2000m"

ACKは、静的リソーススケジューリング方法を使用し、以下の式を使用することによって各ノード上の残りのリソースを計算する。残りのリソース=ノード上の総リソース − 割り当てられたリソース。 割り当てられたリソースは、使用されるリソースと同等ではありません。 リソースを消費するプログラムを手動で実行する場合、ACKはプログラムによって使用されるリソースを認識しません。

すべてのポッドのリソースを要求する必要があります。 リソースクレームがないポッドの場合、ノードにスケジュールされた後、ポッドで使用されているリソースはノードの合計リソースから差し引かれません。 その結果、過剰なポッドがノードにスケジューリングされる可能性がある。

ACKで提供されるリソースプロファイリング機能を使用して、リソース使用量の履歴データに基づいてコンテナーのリソース構成の提案を取得できます。 これにより、リソース要求の設定とコンテナの制限が大幅に簡素化されます。 詳細については、「リソースプロファイリング」をご参照ください。

起動中にアプリケーションを終了するのではなく、依存関係の準備が整うまで待ちます

一部のアプリケーションは、外部依存性を有し得る。 たとえば、アプリケーションは、データベースからデータを読み取るか、別のサービスのインターフェースを呼び出す必要がある場合があります。 ただし、アプリケーションが起動すると、データベースまたはインターフェースが準備できていない可能性があります。 手動O&Mでは、外部依存関係の準備ができていない場合、アプリケーションは終了します。 これはフェイルファーストとして知られています。 この戦略はACKクラスターには適していません。 ACKのほとんどのO&Mアクティビティは自動化されています。 たとえば、アプリケーションを手動でデプロイしたり、選択したノードでアプリケーションを起動したり、アプリケーションが失敗したときにアプリケーションを再起動したりする必要はありません。 ACKクラスターのアプリケーションは、障害時に自動的に再起動されます。 水平ポッドオートスケーラー (HPA) を使用してポッドの数をスケーリングし、負荷の増加に対処することもできます。

例えば、アプリケーションAはアプリケーションBに依存しており、両方のアプリケーションが同じノード上で実行される。 何らかの理由でノードが再起動します。 ノードが再起動された後、アプリケーションAは起動され、アプリケーションBは起動されない。 この場合、アプリケーションAの依存関係は準備ができていない。 従来の方法は、この場合、アプリケーションAを終了する。 アプリケーションBの起動後、アプリケーションAを手動で起動する必要があります。

ACKの最良の方法は、依存関係がラウンドロビン方式で準備できているかどうかをチェックし、アプリケーションを終了するのではなく、すべての依存関係が準備できるまで待つことです。 これを行うには、Init Containerを使用します。

再起動ポリシーの設定

ポッド内で実行されているアプリケーションプロセスを閉じることは一般的です。 コードのバグ、過剰なメモリ使用、またはその他の理由により、アプリケーションプロセスが終了する可能性があります。 プロセスが終了すると、ポッドが失敗します。 ポッドのrestartPolicyパラメーターを設定できます。 これにより、障害時にポッドを自動的に再起動できるようになります。

apiVersion: v1
kind: Pod
metadata:
  name: tomcat
spec:
  containers:
  - name: tomcat
    image: tomcat
    restartPolicy: OnFailure 

restartPolicyパラメーターの有効な値:

• 常に: すべての場合に自動的にポッドを再起動します。

• OnFailure: 障害時にポッドを自動的に再起動します (閉じたプロセスの状態は0ではありません) 。

• Never: ポッドを再起動しません。

livenessプローブとreadinessプローブの設定

ポッドが [実行中] 状態であっても、ポッドがサービスを提供できない場合があります。 実行中のポッド内のプロセスがロックされる可能性があります。 したがって、ポッドはサービスを提供できません。 ただし、ポッドはまだ実行されているため、Kubernetesはこのようなポッドを再起動しません。 したがって、クラスター内のすべてのポッドに対してlivenessプローブを設定する必要があります。 プローブは、ポッドが生きていてサービスを提供できるかどうかをチェックします。 livenessプローブがポッド内の例外を検出すると、ポッドは自動的に再起動されます。

準備完了プローブを使用して、ポッドが外部サービスを提供する準備ができているかどうかを判断します。 起動時にアプリケーションの初期化のために時間がかかります。 初期化中、アプリケーションが実行されるポッドは外部サービスを提供できません。 準備完了プローブは、ポッドがネットワークトラフィックを受信する準備ができているかどうかをIngressまたはServicesに通知するために使用されます。 準備完了プローブによってポッドエラーが検出されると、Kubernetesはポッドへのネットワークトラフィックの転送を停止します。

apiVersion: v1
kind: Pod
metadata:
  name: tomcat
spec:
  containers:
  - name: tomcat
    image: tomcat
    livenessProbe:
      httpGet:
        path: /index.jsp
        port: 8080
      initialDelaySeconds: 3
      periodSeconds: 3
    readinessProbe:
      httpGet:
        path: /index.jsp
        port: 8080

各コンテナで1つのプロセスのみを実行

コンテナーサービスを初めて使用するユーザーは、通常、コンテナーをVMとして使用し、1つのコンテナーで複数のプロセスを実行します。 プロセスには、モニタリングプロセス、ロギングプロセス、sshdプロセス、およびsystemdが含まれます。 これにより、次の2つの問題が発生します。

• ポッドのリソース使用量を判断するのは複雑になります。 リソース要求と制限の実装も困難になります。

• 各コンテナで1つのプロセスのみを実行すると、コンテナエンジンがプロセスの失敗を検出し、失敗ごとにコンテナを再起動できるようになります。 コンテナに複数のプロセスが含まれている場合、プロセスの1つが終了してもコンテナは影響を受けません。 外部コンテナエンジンは、終了したプロセスを認識せず、したがって、コンテナに対していかなるアクションも実行しない。 しかしながら、容器は、この場合、期待されるように機能することができない場合がある。

ACKを使用すると、複数のプロセスを共同で実行できます。 たとえば、NGINXとphp-fpmがUNIXドメインソケットを使用して相互に通信する場合は、2つのコンテナーを含むポッドを使用できます。 次に、UNIXドメインソケットを2つのコンテナーで共有するボリュームに格納します。

Eliminate single points of failure (SPOF)

アプリケーションが1つのECS (Elastic Compute Service) インスタンスのみを使用している場合、障害時にECSインスタンスが再起動されている期間中、アプリケーションは使用できなくなります。 アプリケーションは、アップグレードされたとき、または新しいバージョンがリリースされたときにも使用できなくなります。 したがって、ポッドでアプリケーションを直接実行しないことをお勧めします。 代わりに、DeploymentsまたはStatefulSetsを使用してアプリケーションをデプロイし、アプリケーションごとに3つ以上のポッドを使用します。

参照

ACKを使用すると、アプリケーションのカナリアリリースと青緑色リリースを実行できます。 詳細については、「アプリケーションのデプロイ」をご参照ください。

アプリケーション管理のベストプラクティスの詳細については、「アプリケーション管理のベストプラクティス」をご参照ください。

実行中のアプリケーションポッドでエラーをトラブルシューティングする方法の詳細については、「ポッドのトラブルシューティング」および「アプリケーションに関するFAQ」をご参照ください。