Kubernetes で絶対にしてはいけない 10 の間違い

DevOps 開発モデルの普及により、Kubernetes はテクノロジーの世界を急速に席巻しています。オープンソースのコンテナ オーケストレーション システムとして、コンテナ アプリケーションの展開、拡張、管理を自動化できます。 Kubernetes は、分散コンテナ クラスター向けの経済的で強力かつ信頼性の高い管理ツールであるため、ある程度の複雑さを伴います。開発者が注意を払わなかったり、不適切に構成したりすると、本番環境でさまざまな障害が発生する可能性があります。

潜在的な落とし穴や間違いを避けるために、この記事では、Kubernetes のデプロイメントでよくある間違いとその根拠、そしてそれを修正するための簡単なヒントをいくつか紹介します。

Kubernetesの基礎

画像ソース: Kubernetes.io

Kubernetes は、一連の API とコマンドライン ツールを使用して、クラスター内のコンテナを管理します。そのアーキテクチャは、マスター ノードと複数のサブノード、つまり作業ノードで構成されます。マスターノードは、クラスターのステータスとサブノードのアクティビティを担当し、サブノードのワークロードを管理し、コンテナをスケジュールし、コンテナに適切なリソースを割り当てます。サブノードは物理マシンや仮想マシンに限定されませんが、Kubernetes クラスターを操作するには、すべてのサブノードが Docker エンジンと kubelet サービスにアクセスする必要があります。さらに、ノードは相互間のデータ転送を実現するために他のノードと接続する必要があります。

Kubernetes は宣言型構成モデルを使用して、予想される変更と予期しない変更の両方に対応できるスケーラブルなシステムを簡単に設計します。この宣言的な構成により、Kubernetes はさまざまなコンテナやクラスター操作の根本的な複雑さをより簡単に処理できるようになり、高可用性、スケーラビリティ、セキュリティを備えたクラスターを簡単に構築できるようになります。

もちろん、Kubernetes アプリケーションは本質的に複雑な展開であるため、次のようなエラーが発生することがよくあります。

1. ヘルスチェックを無視する

画像出典: Kaizenberglabs

上の図に示すように、Kubernetes にサービスをデプロイする場合、サービスが期待どおりに実行されるようにするには、ポッドの状態と Kubernetes クラスターの全体的な健全性を理解することが非常に重要です。これを行うには、スタートアップ プローブ、ライブネス プローブ、および準備プローブを使用できます。その中で、スタートアップ プローブは、Pod の正常な起動と作成を保証できます。アクティビティ プローブを使用すると、アプリケーションがアクティブかどうかをテストするのに便利です。準備状況プローブは、アプリケーションがトラフィックを受信する準備ができているかどうかを判断するために使用されます。

2. コンテナにホストファイルシステムをマウントする

コンテナにホスト ファイル システムをマウントすることは、データが永続的なシナリオでよく使用される一般的なアンチパターンです。最も簡単な方法は、ホストのローカル ディレクトリをコンテナー ファイル システム内のディレクトリとしてマウントすることです。したがって、このディレクトリに書き込まれたものはすべてホスト上に保存されます。ただし、この動きにより、次のような潜在的な結果が生じる可能性があります。

• 複数のコンテナ間で状態を共有する方法はありません (つまり、2 つの異なるホストに 2 つの異なるディレクトリをマウントすることはできません)。
• ホスト ファイル システムで行われた変更は、他のコンテナーには表示されません。
• 所有権を変更せずにマウントされたディレクトリ上のファイルを管理することはできません。

したがって、上記の問題を回避するには、データの永続化を目的とする場合を除き、ホストのファイルシステムをコンテナーにマウントしないでください。

3. 「最新」タグを使用する

本番環境で Latest タグを使用する場合、バージョンの説明が明確でないと混乱を招く可能性があるため、本番環境ではこのようなタグの使用はお勧めしません。たとえば、サービスが中断し、できるだけ早く復旧する必要がある場合、「最新」タグが新しくプッシュされたイメージ バージョンを指していないことがわかります。つまり、実行されていたアプリケーションの特定のバージョンを知ることができません。したがって、意味のある Docker タグを引き続き使用する必要があります。

4. 間違ったKubernetesノードにサービスをデプロイする

前述のように、ワーカーノードはマスターノードによって割り当てられたタスクのみを実行できます。その後、間違ったノードにサービスをデプロイすると、サービスが正しく動作しなくなる可能性があります。さらに、新しいコンテナを起動すると、利用可能なスケジューラがタスクを割り当てるまで待機する必要があり、予想よりも時間がかかることがよくあります。

この状況を回避するには、サービスをデプロイする前に、サービスをマスター ノードで実行する必要があるのか​​、ワーカー ノードで実行する必要があるのか​​を把握する必要があります。コンテナを起動する前に、ポッドが通信する必要があるクラスター内の他のポッドに到達できることも確認する必要があります。

5. 既成のデプロイメントパターンを使用しない

Kubernetes を使用すると、開発者は多数のデプロイメント テクノロジーを使用してアプリケーションを簡単にデプロイできます。下の図に示すように、Kubernetes では、新しいソフトウェアのデプロイメントによってユーザーがダウンタイムやサービスの中断に遭遇しないように、Blue-Green、Canary、Rolling などのデプロイメント戦略を使用することを推奨しています。

• ローリング デプロイメント戦略は Kubernetes のデフォルトの戦略であり、古いポッド バージョンを新しいバージョンのポッドに徐々に置き換えます。
• ブルーグリーン モデルでは、ブルー バージョンとグリーン バージョンが同時にデプロイされますが、一度にアクティブになるのは 1 つのバージョンだけです。青を古いバージョン、緑を新しいバージョンと見なすと、最初にすべてのトラフィックをデフォルトで青バージョンに送信できます。最新のグリーン バージョンがすべての要件を満たすと、古いバージョンのトラフィックを新しいバージョンに移動できます (つまり、ブルーからグリーンへ)。
• カナリア展開戦略は、A/B テストや「ダーク」ローンチに使用できます。これはブルーグリーン アプローチと非常に似ていますが、唯一の違いはバージョン A と B が同時にサービスを提供してリクエストを受け入れるという点です。ユーザー トラフィックをバックグラウンドで管理および制御し、バージョン A からバージョン B にゆっくりと転送できます。

6. 繰り返し展開

同じ状態のコピーを複数作成し、それらを異なるクラスターに並行してデプロイすると、重複したデプロイが発生する可能性があります。たとえば、クラスターに障害が発生した場合、別のクラスターがデプロイメント要求の処理を継続します。ただし、回復するか、新しいクラスターが参加すると、実行中の 2 つのレプリカがリクエストを 2 倍にし、基盤となるホストの CPU とメモリのリソースをオーバーサブスクライブします。このため、ヘッドレス サービスやデーモン セットなどのサービス タイプを使用して、一度に 1 つのデプロイメント バージョンのみが実行されるようにすることをお勧めします。

7. 本番環境ではコンテナを 1 つだけ使用する (つまりステートレス)

多くの人は、すべてのコンテナは同じであると誤解しています。実際、それらの間には大きな違いがあります。その中でも、ステートフル コンテナーを使用すると、ディスクなどの永続的なストレージ メディアにデータを保存して、データの損失を防ぐことができます。一方、ステートレス コンテナーは、実行中のみデータを保持し、終了するとデータを破棄します (追加でバックアップしない限り)。したがって、ステートフル コンテナーとステートレス コンテナーの両方を使用する必要があります。

8. 監視とログ記録の要件を考慮せずにアプリケーションを展開する

監視とログ記録の必要性を考慮しないと、開発者はコードやアプリケーションが本番環境でどのように実行されているかを把握できなくなることがよくあります。このような欠陥を回避するには、アプリケーションを展開する前に監視システムとログ集約サーバーを確立し、アプリケーションのパフォーマンスを把握して、変更や最適化が必要な場所を見つける必要があります。

ただし、サードパーティのソリューションではなく、Kubernetes 自体が提供するサービスとツールのみを使用すると、ベンダー ロックインの問題が発生する可能性があります。たとえば、CRI コンテナ ランタイム インターフェイスを使用してコンテナをデプロイする場合、Docker コンテナや RKT コンテナは使用できません。さらに、多くの開発者は、クラスター容量の不足や不適切なタイミングでのアプリケーションのデプロイによって生じる非効率性と混乱に遭遇します。

9. セキュリティ設定なしでアプリケーションをデプロイする

開発者は、クラスターの外部からアクセス可能なエンドポイントを使用する際に、キーの保護や特権コンテナを安全に実行する方法などの問題を見落としがちです。したがって、Kubernetes の次のセキュリティ面に注意する必要があります。

• 承認- 認証と承認は、Kubernetes クラスター内のリソースへのアクセスを制御するために重要です。
• ネットワーキング- Kubernetes ネットワーキングでは、オーバーレイ ネットワークとサービス エンドポイントを管理して、コンテナー間のトラフィックがクラスター内で安全にルーティングされるようにします。
• ストレージ- Kubernetes API サーバーには保存されているすべての情報にアクセスできる REST インターフェースがあるため、ユーザーは API に HTTP リクエストを送信するだけで、API に保存されているすべての情報にアクセスできます。権限のないユーザーやプロセスが機密データにアクセスするのを防ぐために、ユーザー名/パスワードまたはトークンベースの認証方法をサポートするように API サーバーを構成できます (下の図を参照)。

さらに、ロールベースのアクセス制御 (RBAC) ポリシーを構成することで、Kubernetes クラスターを保護できます。つまり、ユーザーに「管理者」や「オペレーター」などのロールを割り当て、ロールのリソースへのアクセスを制限することで、Kubernetes クラスターを保護します。管理者ロールには完全なアクセス権がありますが、オペレーター ロールにはクラスター内の限られたリソースへのアクセス権のみがあります。

10. リソース使用制限を設定していない

リソースの使用率と請求額の両方が急上昇していることに気付いた場合は、サービスのリソース使用状況を再検討する時期です。アプリケーションに対してストレス テストを実行することで、コンテナーの CPU とメモリの制限を設定できます。このため、Kubernetes では、リソース使用率のカテゴリに「リクエスト」と「制限」を定義しています。 「要求」はアプリケーションの実行に必要な最小リソースを表し、「制限」は最大リソースを定義します。デプロイメント YAML でリソース制限を指定できます。

上の図からわかるように、Harness Cloud Cost Management (CCM) は、さまざまなワークフロー負荷の CPU とメモリの使用状況を計算して分析し、さまざまなリソースの最適化の可能性をヒストグラムの形式で表示し、Kubernetes クラスターにさまざまな提案を提供することで、毎月の費用を削減します。

まとめ

上記では、Kubernetes のデプロイメント プロセスでよくある 10 個のエラーとその解決策を紹介しました。これらが、より完全なアプリケーションとサービスを効果的に提供するために役立つことを願っています。

翻訳者について

51CTO コミュニティの編集者である Julian Chen 氏は、IT プロジェクトの実装において 10 年以上の経験を持っています。社内外のリソースとリスクの管理に長けており、ネットワークと情報セキュリティの知識と経験の普及に注力しています。彼は、ブログ投稿、特別トピック、翻訳の形で最先端のテクノロジーと新しい知識を共有し続けています。彼はオンラインとオフラインで情報セキュリティのトレーニングや講義を頻繁に行っています。

原題: Kubernetes で絶対にやってはいけない 10 の間違い、著者: Pavan Belagatti