Kubernetesポッドを展開しますか?あなたに5つのトリックを教えてください!

Kubernetesでは、ポッドが基本的な展開ユニットです。論理エンティティとしてパッケージ化および展開された1つ以上のコンテナを含めることができます。Kubernetesで実行されているクラウドネイティブアプリケーションには、各マイクロサービスに1つずつマップされた複数のポッドが含まれている場合があります。ポッドはKubernetesの拡張ユニットでもあります。

以下は、Kubernetesにポッドを展開する前に従うべき5つの最も基本的なベストプラクティスです。

1)最適なKubernetesコントローラーを選択します              

コンテナイメージを(汎用ポッドとして)デプロイして実行するのは魅力的ですが、ワークロードの特性に基づいて正しいコントローラタイプを選択する必要があります。Kubernetesにはコントローラーと呼ばれるプリミティブがあり、これはワークロードの主要な特性と一致しています。Deployment、StatefulSet、およびDaemonSetは、Kubernetesで最も一般的に使用されるコントローラーです。             

ステートレスポッドを展開するときは、常に展開コントローラーを使用してください。これにより、拡張、展開履歴、およびロールバック機能を通じて、PaaSのような機能がポッドにもたらされます。デプロイメントが最低2つのレプリカ数で構成されている場合、Kubernetesは、少なくとも2つのポッドが常に実行されていることを保証します。これにより、障害耐性がもたらされます。コピーが1つしかないポッドをデプロイする場合でも、通常のポッド仕様ではなく、デプロイメントコントローラーを使用することを強くお勧めします。     

データベースクラスターなどのワークロードの場合、StatefulSetコントローラーは、予測可能な命名規則を使用して、可用性の高いポッドのセットを作成します。高可用性を必要とするステートフルワークロード(Cassandra、Kafka、ZooKeeper、SQL Serverなど)は、KubernetesにStatefulSetとしてデプロイされます。

クラスターの各ノードでポッドを実行する必要がある場合は、DaemonSetコントローラーを使用する必要があります。Kubernetesは、新しく構成されたワーカーノードでDaemonSetを自動的にスケジュールするため、ワークロード用にノードを構成および準備するための理想的な候補です。たとえば、ワークロードを展開する前に既存のNFSまたはGLUSTERファイル共有をノードにインストールする場合は、ポッドをパッケージ化してDaemonSetとして展開します。    

ポッドを展開する前に、最適なコントローラータイプを選択してください。   

2)ポッドのヘルスチェックを構成します              

デフォルトでは、実行中のすべてのポッドの再起動ポリシーが常にに設定されています。つまり、コンテナでエラーが発生すると、ノードで実行されているkubeletが自動的にポッドを再起動します。

ヘルスチェックは、コンテナプローブの概念を通じて、kubeletのこの機能を拡張します。ポッドごとに構成できるプローブには、準備、活性、起動の3つがあります。      

ポッドは実行されているが、準備完了列に0/1が表示される状況が発生する場合があります。これは、ポッドがリクエストを受け入れる準備ができていないことを意味します。準備プローブは、ポッドを開始する前に前提条件が満たされていることを確認します。たとえば、機械学習モデルを提供するポッドは、推論を提供する前にモデルの最新バージョンをダウンロードする必要があります。準備プローブは、ポッドを準備完了状態に移行する前に、ファイルの存在を常にチェックします。同様に、CMSポッドの準備プローブは、データストアがインストールされてアクセス可能であることを確認します。           

活性プローブは定期的にコンテナの状態をチェックし、kubeletに報告します。このヘルスチェックが失敗すると、ポッドはトラフィックを受信しません。活性プローブが正常な状態を報告するまで、サービスはこのポッドを無視します。たとえば、MySQLポッドには、データベースエンジンのステータスを継続的にチェックする活性プローブが含まれている場合があります。             

バージョン1.16以降、起動プローブはまだアルファ版であるため、コンテナはヘルスチェックを活性プローブに渡すまでの待機時間が長くなります。これは、異常な起動時間を必要とするレガシーアプリケーションをKubernetesに移植するときに非常に役立ちます。             

上記のヘルスチェックはすべて、コマンド、HTTPプローブ、およびTCPプローブを介して構成できます。

3)Initコンテナでポッドを準備します             

場合によっては、コンテナを準備する前に初期化する必要があります。ポッドが準備完了状態に移行する前に、初期化を別のコンテナに移動して基本的な作業を完了することができます。initコンテナは、ファイルのダウンロード、ディレクトリの作成、ファイルのアクセス許可の変更などに使用できます。

initコンテナを使用して、ポッドが特定の順序で開始されるようにすることもできます。たとえば、WordPressポッドを開始する前に、InitコンテナはMySQLポッドが使用可能になるまで待機します。   

ポッドには複数の初期化コンテナを含めることができ、各コンテナは特定の初期化タスクを実行します。            

4)ノード/ポッドのアフィニティルールと非アフィニティルールを適用します

Kubernetesスケジューラーは、ポッドのリソース要件とクラスター内のリソース消費に応じて、関連するノードにポッドを適切に配置します。ただし、ポッドがノードでどのようにスケジュールされるかを制御する必要がある場合があります。Kubernetesは、ノードアフィニティ/アンチアフィニティとポッドアフィニティ/アンチアフィニティの2つのメカニズムを提供します。

ノードアフィニティは、すでに強力なnodeSelectorルールを拡張して、他のシナリオをカバーします。Kubernetesアノテーションがラベル/セレクターをより表現力豊かで拡張可能にするように、ノードアフィニティは追加のルールを通じてnodeSelectorをより表現力豊かにします。ノードアフィニティにより、特定の条件を満たすノードでポッドがスケジュールされます。たとえば、SSDに接続されたノードでステートフルデータベースポッドを強制的にスケジュールすることができます。同様に、ノードの非親和性は、問題を引き起こす可能性のあるノードでポッドをスケジュールすることを回避するのに役立ちます。            

ノードの親和性はポッドとノード間で一致しますが、パフォーマンスまたはコンプライアンスを取得するためにポッドを同じ場所に配置する必要があるシナリオが存在する場合があります。ポッドアフィニティは、同じノードを共有する必要があるポッドを配置するのに役立ちます。たとえば、Nginx Webサーバーポッドは、Redisポッドもあるノードでスケジュールする必要があります。これにより、Webアプリケーションとキャッシュ間の待ち時間が短くなります。また、同じノードで2つのポッドを実行することを避けたい場合もあります。HAワークロードを展開する場合、同じポッドの2つのインスタンスを同じノードで実行しないように強制することができます。ポッドの非親和性は、この可能性を防ぐためのルールを適用します。       

ワークロードを分析して、ノードとポッドのアフィニティ戦略を使用する必要があるかどうかを評価します。

5)オートスケーラーを使用する              

AWS、Microsoft Azure、Google Cloud Platformなどのハイパースケールクラウドプラットフォームには、平均リソース消費量または外部指標に基づいてVMグループをスケーリングできる自動スケーリングエンジンが組み込まれています。             

Kubernetesには、水平ポッドオートスケーラー(HPA)、垂直ポッドオートスケーラー(VPA)、およびクラスターオートスケールの展開で同様の自動スケーリング機能があります。

水平ポッドオートスケーラーは、観測されたCPU使用率に基づいて、レプリケーションコントローラー、デプロイメント、レプリカセット、または状態セット内のポッドの数を自動的にスケーリングします。HPAは、Kubernetesではオブジェクトとして表されます。つまり、HPAは、kubectlCLIによって制御されるYAMLファイルを介して宣言できます。IaaS自動スケーリングエンジンと同様に、HPAは、CPUしきい値、最小および最大ポッドインスタンス、冷却サイクル、さらにはカスタムインジケーターの定義をサポートします。             

垂直ポッド自動スケーリングにより、ポッドのCPUおよびメモリ構成の定義に伴う当て推量が排除されます。このオートスケーラーは、CPUとメモリの要求と制限に適切な値を推奨したり、これらの値を自動的に更新したりできます。自動更新フラグは、既存のポッドを削除するか、古い構成で実行を継続するかを決定します。VPAオブジェクトを照会すると、上限と下限を介して最適なCPUおよびメモリ要求が表示されます。             

HPAおよびVPAが展開とポッド拡張を拡張する場合、クラスターオートスケーラーはワーカーノードプールのサイズを拡張および縮小します。これは、現在の使用率に基づいてKubernetesクラスターのサイズを調整できる独立したツールです。リソースが不足しているために現在のノードでスケジュールできないポッドがある場合、または新しいノードを追加するとクラスターリソースの全体的な可用性が向上する場合、オートスケーラーはクラスターのサイズを増やします。舞台裏では、Cluster Autoscalerは基盤となるIaaSプロバイダーとネゴシエートして、ノードを追加または削除します。HPAとクラスターオートスケーラーの組み合わせにより、ワークロードに最大のパフォーマンスと最大の可用性が提供されます。

おすすめ

転載: blog.csdn.net/k8scaptain/article/details/104410971