本番環境で実践できるKubernetesのベストプラクティス

[51CTO.com クイック翻訳] ガートナーの予測によると、2022 年までに世界中の組織の 75% 以上がコンテナ化されたアプリケーションを本番環境で実行するようになります (現在、その割合は 30% 未満です)。 2025年までにこの割合は85%を超えるでしょう。クラウドネイティブ アプリケーションではインフラストラクチャの高度な自動化が求められるため、現在、Docker や Kubernetes に代表される DevOps 実装プラットフォームにより、より多くの企業がコンテナ オーケストレーション ツールの形でソフトウェア製品をより迅速に構築、リリース、提供できるようになりました。

一般的に、Kubernetes は、自動拡張、ゼロダウンタイムのデプロイメント、サービス検出、自動デプロイメント、ロールバックのサポートなど、優れた豊富な機能を備えているため、大規模なコンテナのデプロイメントと管理に非常に適しています。 Kubernetes はリソースとワークロードを柔軟に割り当てることができますが、学習曲線は複雑で急峻です。時間と労力を節約するために、もちろん KaaS プロバイダーにアウトソーシングすることもできます。ただし、本番環境で Kubernetes を包括的に制御する必要がある場合は、Kubernetes の可観測性、ログ記録、クラスター監視、セキュリティ構成を習得するために時間を費やす必要があります。

同時に、本番環境でコンテナを実行するには多くのコンピューティング リソースと機能が必要になることが多いため、さまざまなクラウドベースのオーケストレーション プラットフォームが選択されています。ただし、セキュリティ上の問題が発生する可能性もあります。たとえば、Kubernetes Pod はあらゆるインフラで素早く起動できますが、Pod 間の内部トラフィックが増加すると、Kubernetes の攻撃対象領域が徐々に拡大し、それに応じてセキュリティリスクも増大します。さらに、Kubernetes の本質的に非常に動的で一時的な運用環境は、従来のセキュリティ ツールとうまく統合されないことがよくあります。ストレージ セキュリティ、ネットワークの監視とガバナンス、コンテナのライフサイクル管理、プラットフォームの選択のニーズを満たす Kubernetes 構成戦略を早急に開発する必要があります。

以下では、本番環境で実行できるさまざまな Kubernetes のベスト プラクティスと調査について説明します。

準備完了プローブとライブプローブを使用したヘルスチェック

オンラインビジネスにとって、サービスの正常かつ安定した運用を確保することは最も重要です。障害のあるサービスをタイムリーに処理し、ビジネスへの影響を回避し、迅速に回復することは、常に DevOps の難しさでした。大規模で分散されたシステムを管理する場合、アプリケーション インスタンスの正常な動作を保証するために、事前に Kubernetes ヘルス チェックを設定する必要があります。

ターゲット環境と要件に基づいて、さまざまなヘルスチェック項目を作成およびカスタマイズできます。たとえば、WeaveWorks を使うことができます。複数のホストに展開された Docker コンテナに接続する仮想ネットワークをネットワーク スイッチの形で作成できるため、アプリケーションがポート マッピングやリンク情報を 1 つ 1 つ設定する必要がありません。詳細については、https://www.weave.works/blog/resilient-apps-with-liveness-and-readiness-probes-in-kubernetes を参照してください。

これらの準備プローブにより、アプリケーションがトラフィックに対応するサービスを提供できる準備ができているかどうかを Kubernetes に知らせることができる点に注目すべきです。つまり、Kubernetes は、サービスを割り当ててトラフィックを Pod に送信する前に、常に正常な準備プローブがあることを確認する必要があります。

では、申請の有効性はどうすればわかるのでしょうか?ここでは、アプリケーションに障害が発生すると、Kubernetes がすぐに古い Pod を削除して新しい Pod に置き換えるように、ライブネス プローブを使用する必要があります。

上記の Kubernetes のヘルスチェックにより、検出された障害のあるサービスを適切なタイミングで自動的にシャットダウンまたは再起動し、サービスが自動的に回復するようにすることができます。

リソース管理

通常、単一のコンテナに対するリソース要求の数を指定または制限し、Kubernetes 環境をさまざまなチーム、部門、アプリケーション、顧客が使用できるように異なる名前空間に分割する必要があります。詳細については、http://blog.kubecost.com/blog/requests-and-limits/ を参照してください。

ここでの Kubernetes リソース使用量は、実稼働環境のコンテナと Kubernetes Pod によって使用されるリソースの数を指すことに注意してください。これを基に、変換に必要なコストを合理的に制御できます。さらに、運用チームは通常、現在の Kubernetes 実稼働環境が最適な状態にあるかどうかを判断するために、コンテナの平均 CPU 使用率と Pod によって消費されるリソースの割合を知る必要があります。

RBACを有効にする

RBAC (ロールベースのアクセス制御) は、ユーザーやアプリケーションによるシステムやネットワークへのアクセスを許可または制限する方法です。 Kubernetes はバージョン 1.8 以降で RBAC を導入しました。 rbac.authorization.k8s.io API グループを使用して、さまざまな承認ポリシーを作成し、対象の本番環境とクラスターにアクセスできるユーザーとプロセスを制限できます。

RBAC は Kubernetes クラスターにセキュリティの層を追加すると言えます。 Kubernetes 内の特定のアカウントの権限を追加または削除し、特定のアクセス ルールを設定できます。詳細については、https://medium.com/@danielckv/what-is-rbac-in-kubernetes-c54457eff2dc をご覧ください。

クラスタ構成と負荷分散

実稼働環境レベルを満たすには、Kubernetes アーキテクチャに高可用性、マルチマスター、マルチ etcd クラスターなどの機能が必要です。実際のアプリケーションでは、クラスターを構成するために Terraform や Ansible などのツールがよく使用されます。

すべてのクラスターをセットアップし、実行中のアプリケーション用のポッドを作成したら、これらのポッドのロード バランサーを構成して、ネットワーク トラフィックを適切なサービスにルーティングすることを検討する必要があります。ただし、オープンソースの Kubernetes プロジェクトでは、デフォルトではロードバランサーが提供されません。そのため、負荷分散機能を実装するには、NGINX Ingress コントローラー、HAProxy、ELB などのツールや、Kubernetes のプラグインと統合する必要があります。詳細については、https://medium.com/avmconsulting-blog/external-ip-service-type-for-kubernetes-ec2073ef5442 をご覧ください。

Kubernetes オブジェクトにラベルを付ける

Pod などのオブジェクトに、キー/値のペアなどのラベルを属性として添付できます。実稼働環境では、ラベルを使用して、Kubernetes オブジェクトを識別、グループ化、バッチクエリ、およびその他の操作を実行できます。たとえば、コンテナを、それが属するアプリケーションごとにグループ化できます。もちろん、チームは事前に任意の数のラベル付け規則を確立できます。詳細については、https://theithollow.com/2019/01/31/kubernetes-services-and-labels/ を参照してください。

ネットワークポリシーの設定

ネットワーク ポリシーを使用すると、明示的なステートメントを通じてどのトラフィックが通過できるかを決定できるため、Kubernetes はすべての非準拠トラフィックや不要なトラフィックをブロックできます。たとえば、基本的なセキュリティ対策として、クラスター内の特定のネットワーク トラフィックを定義して制限することができます。

実際、Kubernetes の各ネットワーク ポリシーは、承認された接続のリストとして定義できます。作成されたネットワーク ポリシーに基づいて、条件を満たす Pod のみが確立された接続を受け入れることができます。つまり、ネットワーク ポリシーは、ホワイトリストに基づいて、Pod からの接続または Pod への接続を承認および許可します。詳細については、https://theithollow.com/2019/10/21/kubernetes-network-policies/ をご覧ください。

クラスターの監視とログ記録

クラスターの監視は、本番環境での Kubernetes の構成、パフォーマンス、トラフィックのセキュリティを確保するために重要です。同時に、システムアーキテクチャのすべてのレイヤーにログ機能を設定する必要があります。生成されたログは、セキュリティ ツールを通じて分析および監査機能を実行するのに役立ちます。ログ記録と監視がなければ、発生した問題を診断し、コンプライアンスを確保することはできないと言えます。詳細については、https://dzone.com/articles/logging-amp-monitoring-of-kubernetes-applications を参照してください。

ステートレスアプリケーションから始める

ステートレス アプリケーションの実行はステートフル アプリケーションの実行よりもはるかに簡単なので、Kubernetes を使い始めたばかりのチームでは、ステートレス バックエンドを使用して、長時間の接続を確立することなく、ビジネス ニーズに応じてオンデマンドで簡単に移行および柔軟に拡張できます。さらに、ステートレス性を利用することで、開発者はダウンタイムなしでアプリケーションをより効率的にデプロイすることもできます。

オートスケーラーを有効にする

Kubernetes は、デプロイメント向けに、水平ポッド自動スケーリング (HPA)、垂直ポッド自動スケーリング (VPA)、クラスター自動スケーリングの 3 種類の自動スケーリング機能を提供します。で：

• Horizo​​ntal Pod Autoscaling プラグインは、認識された CPU 使用率に基づいて、デプロイメント、レプリケーション コントローラー、レプリカ セット、およびステートフル セットの数を自動的にスケーリングします。
• Vertical Pod Autoscaling プラグインは、CPU とメモリのリクエストと制限に適切な値を設定し、これらの値を自動的に更新できます。
• クラスターの自動スケーリングでは、ワーカー ノード プールのサイズを拡大および縮小し、現在の使用率に基づいて Kubernetes クラスターのサイズを調整できます。

実行時間を制御するさまざまなソース

Pod がパブリック ソースからイメージをプルすることのみを許可する場合、ランタイムについて何もわからない可能性があります。したがって、クラスター内のすべてのコンテナをソース管理する必要があります。レジストリにポリシーを適用することで、信頼できるレジストリから安全で認定されたイメージを取得できます。

継続的な評価

対象アプリケーションの状態と設定の合理性を常に評価する必要があります。たとえば、コンテナのメモリ使用量の履歴を確認することで、より小さいながらも適切な量のメモリを割り当てることができ、長期的にはコストを節約できます。

重要なサービスを守る

Pod の優先度を使用すると、さまざまなサービスの重要度を設定できます。たとえば、安定性を高めるために RabbitMQ Pod を他のアプリケーション Pod よりも重要になるように設定したり、ユーザー向けサービスの可用性を維持するために Ingress Controller Pod をデータ処理 Pod よりも重要になるように設定したりできます。

ダウンタイムゼロ

可用性について言えば、クラスターとサービスに HA (高可用性) を設定することで、ダウンタイムゼロを確保することもできます。たとえば、Pod アンチアフィニティを使用すると、Pod の複数のコピーが異なるノードに分散され、計画的および計画外のクラスターノードの停止を通じてサービスの可用性を確保できます。

さらに、ポッド中断予算を使用することで、レプリカの数を最小限に抑えることもできます。

まとめ

要約すると、スムーズで信頼性の高いアプリケーション サービスを提供するために、可用性、スケーラビリティ、セキュリティ、負荷分散、リソース管理、監視の観点から、本番環境で従うことができるさまざまな Kubernetes のベスト プラクティスについて詳しく説明しました。

原題: Kubernetes in Production: Best Practices to Follow、著者: Pavan Belagatti

[51CTOによる翻訳。パートナーサイトに転載する場合は、元の翻訳者と出典を51CTO.comとして明記してください。