本番環境でKubernetesの大規模な管理を自動化する7つの方法

[51CTO.com クイック翻訳] Kubernetes オープンソース コンテナ オーケストレーション エンジンは管理プラットフォームではないので、管理プラットフォームと間違えないようにしてください。オーケストレーションのポイントは、自動化されたシステムを確実に有効にして、あらゆるステップで人間の介入を必要とせずに、大規模なアプリケーションの展開と管理を容易にすることです。 Kubernetes に使用するツールが自動化をサポートしていない場合、オーケストレーションのメリットを十分に活用できていません。

[[218766]]

そのために、本番環境の Kubernetes クラスターの管理を自動化する 7 つの方法を紹介します。

1. ログ

Kubernetes の本番環境は、ログに大きく依存します。 Kenzan では、通常、プラットフォーム ログとアプリケーション ログを分離するように努めています。これは、さまざまなツールやアプリケーションを通じて実行することも、ログ自体のフィルタリングやタグ付けを通じて実行することもできます。他の分散システムと同様に、ログは、異なるマイクロサービスを対象としている場合でも、特定の呼び出しを正確に追跡するための重要な証拠を提供し、根本原因を特定できるようにします。

2. 自己治癒

私たちは、自己修復機能がなければ、特に分散環境において、システムの高稼働率を達成することはほぼ不可能だと考えています。 Kubernetes は、ポッドとコンテナの状態を定期的に監視し、発生した問題を解決するために即座にアクションを実行できます。 Kubernetes が直接認識する 2 つのオブジェクト タイプは、ポッド ステータスとコンテナ ステータスです。

コンテナ プローブ (livenessProbe および readinessProbe) を使用すると、コンテナが稼働中であり準備ができているかどうかを Kubernetes で監視する方法を定義できます。準備プローブは、プローブが失敗した場合にポッドは実際に実行され続けるものの、トラフィックは渡されないため、特に便利です。

ただし、30 分ごとに再起動するなどの自己修復機能は便利ですが、アプリケーションの問題を隠す可能性もあることに注意してください。発生した問題を検出できるほど堅牢な監視およびログ記録機能が必要です。

3. 弾性テスト

アプリケーションの要件 (例: 99.999% の稼働時間) に応じて、耐障害性テストをプラットフォームの一部にする必要があります。アプリケーションのどのレベルでも障害が発生しても、ダウンタイムが発生しないように回復可能である必要があります。私たちの経験では、開発チームが開発作業に広範な耐性テストが行​​われることを事前に知っていれば、信頼性の高いアプリケーションを開発できる可能性が高くなります。

データベースを手動でシャットダウンしたり、ポッドをランダムに強制終了するなど、最も単純な手動の方法で回復力テストを実行することもできますが、私たちの経験では、これらの方法は自動化するとはるかに効果的であることがわかっています。 Netflix の Chaos Monkey は、Amazon Web Services で実行される非常に強力で非常に便利な回復力テスト ツールですが、Kubernetes 用に構築されたものではありません。幸いなことに、Kubernetes 分野では回復力テスト フレームワークが登場しており、そのうちの 2 つは fabric8 Chaos Monkey (fabric8 IDE の一部) と kube-monkey です。

4. 定期監査

チェックとバランスをいくつ導入したとしても、Kubernetes の運用環境は定期的なメンテナンスと監査の恩恵を受けることができます。定期的な監査では、通常の監視ではカバーされない領域もカバーされます。監査は従来、手作業で行われてきましたが、この分野の自動化ツールは急速かつ劇的に改善されています。

5. 自動スケーリング

Kubernetes の場合、スケーリングとは通常、次の 2 つのいずれかを意味します。

• ポッドのスケーリング
• クラスター内のノードのスケーリング

ポッドのスケーリングは、間違いなく最も一般的なスケーリング形式です。これにより、サービス インスタンスが追加され、トラフィックの受け入れを開始する準備が整います。通常、ポッドレベルのスケーリングは、Heapster メトリックを使用して実行され、新しいインスタンスを作成する必要があるかどうかが判断されます。私たちは通常、ポッドの最小数をかなり低く設定し、Kubernetes Horizo​​ntal Pod Autoscaler にレプリカの最小数を正しく設定させます。単一障害点のシナリオを回避するために、クラスターあたりのレプリカの最小数を常に 1 つより大きく設定します。

ノードのスケーリングは比較的まれなケースですが、回復力の高いアプリケーションにとっては非常に便利なスケーリング メカニズムです。ノードを拡張するには、基盤となる IaaS (AWS、GCP など) を拡張して Kubernetes クラスターに登録する必要があります。このプロセスは手動で実行できますが、推奨されません。通常、単一のノードを自動的にスケーリングできるツールを使用します。ノード レベルのオートスケーラーは、主に 2 つのアクションを実行します。1 つ目は、必要に応じてノードを追加すること、2 つ目は、十分に活用されていないノードを削除することです。

6. リソース割り当て

リソース クォータを使用すると、Kubernetes プラットフォーム内の名前空間を制限して、1 つのアプリケーションがすべてのリソースを占有して他のアプリケーションに影響を与えないようにすることができます。リソースクォータの設定は少し難しい場合があります。私たちの経験では、名前空間を予想される負荷で分割し、比率を使用してクラスターの割合を計算するのが最も安全です。 Heapster が実行中になったら、 kubectl top {node | を使用できます。 pod} コマンドは、現在のノードまたはポッドのリソース使用量を表示し、クォータの管理に役立つ場合があります。その後、監視と監査を使用して、パーティショニングが正しいかどうかを確認します。

7. コンテナリソースの制約

単一のコンテナまたはポッドに必要なリソースの数を把握することは、ある種の芸術になっています。これまで、開発チームは実際に必要なリソースよりもはるかに多くのリソースを見積もっていました。私たちは、ある程度の負荷テストを実行し、フェイルオーバーがどのように機能するかを観察し、リソースを適切に割り当てようとしています。 Netflix はこの方法を「スクイーズ テスト」と呼んでいます。

本番環境でKubernetesを大規模に自動化する7つの方法

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