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

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

より優れたソリューションを持つKubernetesデプロイメントにおける共通のプラクティス

コンテナの導入と利用が増え続ける中、Kubernetes （K8s）はコンテナオーケストレーションのための主要なプラットフォームとなっています。これは、315社以上の企業から数万人のコントリビューターが参加するオープンソースのプロジェクトで、拡張性とクラウドに依存しないことを意図しており、すべての主要なクラウドプロバイダーの基盤となっています。

本番環境でコンテナを稼働させている場合、本番環境は災害を回避するために可能な限り安定していて回復力のあるものにしたいものです（ブラックフライデーのオンラインショッピングのような状況を考えてみてください）。コンテナがダウンしたときは、それが昼間のどの時間帯であろうと夜の早朝であろうと、別のコンテナが起動して代わりのコンテナを稼働させる必要があります。Kubernetesは、スケーリングからフェイルオーバー、ロードバランシングなど、分散システムを弾力的に実行するためのフレームワークを提供します。また、Kubernetesとインテグレートしてニーズを満たすためのツールが多数あります。

ベストプラクティスは時間とともに進化するので、Kubernetes開発のためのより良い方法を継続的に研究し、実験することは常に良いことです。まだまだ新しい技術なので、私たちは常に理解と使用方法の改善に努めています。

今回の記事では、Kubernetesのデプロイにおいて、より良いソリューションを高いレベルで実現している10の共通プラクティスを検証していきます。カスタム実装はユーザーによって異なる可能性があるので、ベストプラクティスについてはあまり詳しい紹介はしません。

1. コンフィグレーションファイルをDockerイメージの中/横に置く
2. Helmなどのテンプレを使わない
3. 物事を特定の順序でデプロイする。(ディペンデンシーの準備ができていないからといって、アプリケーションがクラッシュするのはいけません)
4. メモリやCPUの制限を設定せずにポッドをデプロイする
5. 本番のコンテナで最新のタグをプルする
6. 再起動プロセス中に新しいDockerイメージをプルするようにポッドをキルすることで新しいアップデート/修正をデプロイする
7. 同一クラスタ内で本番と非本番の両方のワークロードを混在させること
8. 青/緑やカナリアをミッションクリティカルなデプロイに使用しないこと(Kubernetesのデフォルトのローリングアップデートは必ずしも十分ではない)
9. デプロイが成功したかどうかを把握するためのメトリクスがない。(ヘルスチェックにはアプリケーションのサポートが必要)