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

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

7. 同一クラスタ内で本番と非本番の両方のワークロードを混在させること

Kubernetesはネームスペース機能に対応しており、ユーザーは同じ物理クラスタ内で異なる環境(仮想クラスタ)を管理することができます。ネームスペースは、単一の物理クラスタ上で異なる環境を管理する費用対効果の高い方法です。例えば、ステージング環境と本番環境を同じクラスタで実行することで、リソースとコストを節約することができます。しかし、開発環境でKubernetesを実行するのと本番環境でKubernetesを実行するのでは、大きなギャップがあります。

同じクラスタ上で本番環境と非本番環境のワークロードを混在させる場合、考慮すべき要素はたくさんあります。例えば、本番環境のパフォーマンスが損なわれないようにリソースの制限を考慮しなければなりません (一般的には、本番用のネームスペースにはクォータを設定せず、非本番用のネームスペースにはクォータを設定するのが一般的です)。

また、分離も考慮する必要があります。開発者は本番環境よりも多くのアクセス権とパーミッションを必要とします。ネームスペースは互いに隠されていますが、デフォルトでは完全に隔離されていません。つまり、開発者用のネームスペースにあるアプリがテスト、ステージング、本番環境にあるアプリを呼び出す可能性があります (またはその逆もあります)。これはベストプラクティスではありません。もちろん、NetworkPolicies を使用してネームスペースを分離するルールを設定することもできます。

しかし、リソースの制限、パフォーマンス、セキュリティ、信頼性を徹底的にテストするのは時間がかかるため、本番環境のワークロードを非本番環境のワークロードと同じクラスタで実行することはお勧めできません。本番用ワークロードと非本番用ワークロードを同じクラスタに混在させるよりも、開発/テスト/本番用に別々のクラスタを使用した方が、分離性とセキュリティが向上します。また、ヒューマンエラーの可能性を減らすために、CI/CDやプロモーションのためにできる限りの自動化を行うべきです。本番環境は可能な限り強固なものである必要があります。

8. 青/緑やカナリアをミッションクリティカルなデプロイに使用しないこと

最近のアプリケーションの多くは、1ヶ月以内に数回の変更を行うものから、1日で複数のデプロイを行うものまであり、頻繁にデプロイが行われています。マイクロサービスアーキテクチャでは、さまざまなコンポーネントがシームレスに動作するように連携している限り、さまざまなサイクルで開発、管理、リリースを行うことができるため、これは確かに実現可能です。そしてもちろん、アプリケーションを24時間365日稼働させておくことは、アップデートをロールアウトする際には、大変重要なことであることは言うまでもありません。

Kubernetesのデフォルトのローリングアップデートだけでは必ずしも十分ではありません。アップデートを実行するための一般的な戦略としては、デフォルトのKubernetesのローリングアップデート機能を使用というこ…