Kubernetesデプロイメントのアンチパターン10選 第2章

今回はKubernetesデプロイメントのアンチパターンをご紹介します。長い記事なので、パターンを２つずつ５回に分けて投稿いたします。今回は2回目です。

3. 物事を特定の順序でデプロイする。

ディペンデンシーの準備ができていないからといって、アプリケーションがクラッシュするのではいけません。従来の開発では、アプリケーションを起動する際の起動タスクと停止タスクには特定の順序があります。この考え方をコンテナオーケストレーションに持ち込まないことが重要です。KubernetesやDockerなどでは、これらのコンポーネントが同時に起動するため、起動の順番を定義することができません。アプリケーションが起動して稼働していても、そのディペンデンシーが失敗したり、マイグレーションされたりして、さらなる問題を引き起こす可能性があります。また、Kubernetesでは、ディペンデンシーに到達できない通信障害の潜在的なポイントが無数にあるのが現実で、その間にポッドがクラッシュしたり、サービスが利用できなくなったりする可能性があります。信号が弱かったり、ネットワーク接続が途切れたりするようなネットワークレイテンシーは、通信障害の一般的な原因です。

簡単にするために、インベントリデータベースとストアフロント UI という 2 つのサービスを持つ仮想ショッピングアプリケーションを見てみましょう。アプリケーションを起動する前に、バックエンドサービスが起動し、すべてのチェック項目を満たし、実行を開始しなければなりません。その後、フロントエンドサービスが起動し、そのチェック項目を満たし、実行を開始することができます。

例えば、 kubectl waitコマンドを使って、以下のように強制的にデプロイの順番を決めたとします。

kubectl wait — for=condition=Ready pod/serviceA

しかし、条件が満たされないと次のデプロイメントが進まず、処理が途切れてしまいます。

*デプロイメント命令がどのようなものかという単純な流れです。

Kubernetesはセルフヒーリング（自己回復）するシステムです。標準的なアプローチは、アプリケーション内のすべてのサービスを同時に起動させ、すべてのサービスが起動するまでコンテナをクラッシュさせて再起動させることです。私はサービスAとBを独立して起動させていますが(デカップリングされたステートレスなクラウドネイティブアプリケーションがそうであるように)、ユーザーエクスペリエンスのために、サービスAの準備が整うまでUI(サービスB)にきれいなローディングメッセージを表示するように指示することもできますが、サービスBの実際の起動はサービスAの影響を受けるべきではありません。