Kubernetes プラグインを拡張するにはどうすればいいですか?これら6つの側面は重要です

Kubernetes プラグインまたは拡張機能は、Kubernetes スタックの重要な部分であり、さまざまなニーズを満たし、ユーザー エクスペリエンスを向上させるのに役立ちます。実稼働レベルのデプロイメントをサポートするために、Kubernetes には、ログ記録や監視機能、セキュリティ ガバナンスなど、多くの拡張可能なコンポーネントが必要です。では、どのような側面を拡張する必要があり、どのようなプラグインを選択すればよいのでしょうか?

1. オーバーレイネットワークプラグイン

コンテナは何らかの方法で通信する必要があるため、オーバーレイ ネットワーク プラグインは非常に重要です。クラスターはオーバーレイ ネットワークとは独立して実行できますが、このオーバーレイ ネットワーク拡張機能を使用すると柔軟性が大幅に向上します。

Calico、Weave、Flannel、Canal (Calico + Flannel)、Kube Router など、カバレッジ ネットワーク プラグインは数多くあります。各クラスターは手動でインストールすることも、クラスターごとに個別にインストールすることもできます。ただし、これには時間がかかり、スケーリングが制限される可能性があります。オーバーレイ ネットワークは Kubernetes クラスターの重要な部分であるため、自動化され、Kubernetes 管理プラットフォームの一部になっていることを確認してください。

2. クラウドネイティブストレージ拡張

ほとんどのユーザーは、ステートレス アプリケーションを使用して Kubernetes を使い始めますが、すぐにステートフル アプリケーションの領域に移行します。この時点で、特定の拡張機能を使用してクラウドネイティブ ストレージを管理する方法が必要です。

Kubernetes は基本的なローカル ストレージ機能を提供します。ただし、ストレージのプロビジョニング、アクセス管理、さまざまなストレージ タイプに対する SLA などの領域では不十分な場合があります。これらの問題は半手動で対処できますが、運用チームに負担がかかり、スケーラビリティの問題が発生します。

ステートフル アプリケーションを備えたスケーラブルな Kubernetes クラスターをサポートするには、クラウド ネイティブのストレージ管理、運用、ガバナンスを自動化する必要があります。 Portworx、Storage OS、Robin など、優れたオプションがいくつかあります。オープンソース プロジェクトでは、Ceph と Rook を選択することもできます。

したがって、独自のクラウドネイティブ ストレージを構築するか、商用製品 (または商用サポート付きのオープン ソース製品) を活用するか、Kubernetes を使用してクラウドネイティブ ストレージ機能を拡張するかを選択できます。これら 3 つのオプションのうち、最初のアプローチは、独自のシステムを構築するために必要な労力とリソースがほとんどの企業にとってコスト的に無理であるため、明らかに実現可能ではありません。ベンダーが提供する既存のクラウドネイティブ ストレージ フレームワークを使用するか、Kubernetes に組み込まれているストレージ機能を使用することを検討することをお勧めします。

3. CI/CDパイプラインプラグイン

さまざまな継続的インテグレーションと継続的デリバリー (CI/CD) 拡張機能から選択できます。クラウドネイティブに特化したものもあれば、汎用的なものもあり、Kubernetes やその他のデプロイメント ツールで使用できます。これらのツールはそれぞれカスタマイズの度合いが異なります。一部には、カスタマイズが制限される事前構成されたパイプラインがパッケージ化されていますが、他のものは制限が少ないものの、セットアップに多くの作業が必要です。

オプションを検討するときは、開発チームが使用しているツールとその経験を考慮してください。 CI/CD パイプラインを Kubernetes およびクラウド ネイティブ スタックと統合するためのプラグインが利用可能です。そうでない場合は、Jenkins、Spinnaker、またはその 2 つの組み合わせなどのオープン ソース ツールの使用を検討してください。

4. セキュリティ管理とガバナンスの枠組みの拡大

セキュリティ管理とガバナンスのフレームワークは企業にとって重要ですが、課題は避けられません。さまざまなガバナンス ルールがさまざまなフレームワークを通じて実装され、これらの拡張機能は既存のセキュリティ フレームワークと重複する可能性があります。すべてのガバナンス ニーズに対応する包括的なツールがなければ、ガバナンス フレームワークの数を増やして運用チームに負担をかけずに、カバレッジを最大化するために、さまざまなツールを組み合わせる必要がある場合があります。

企業によってセキュリティ要件は異なるため、セキュリティ プラグインは同様の課題に直面します。まず、要件を定義し、適切な拡張機能を特定します。 2 番目に、必要なフレームワークを最小限に抑えながら、カバレッジを最大化します。

一部のセキュリティ フレームワークは、オーバーレイ ネットワーク拡張機能と統合したり、ネットワーク ポリシー、ポッド セキュリティ ポリシーなどの特定の Kubernetes セキュリティ機能を活用したりできます。自動化の場合、NeuVector などのソリューションは、クラスター、環境、アプリケーション全体に共通のポリシーを適用できます。

5. エントリー管理拡張機能

Ingress 管理は、外部ユーザーに Kubernetes クラスター サービスを提供できます。これを行うには、クラスター内の Ingress コントローラーを活用できます。ただし、より複雑なシナリオでは、複数のイングレス コントローラーと、NGINX や Kong などの API 管理システムとの統合が必要になる場合があります。どちらのツールも、Kubernetes、クラウドネイティブ ツール、さまざまな API 管理システムと統合されます。

6. ランタイムフレームワーク

選択できるアプリケーション ランタイム拡張機能は多数あります。サーバーレス フレームワークとサービス メッシュは Kubernetes でよく使用され、これらのフレームワークを各クラスターに自動的にデプロイする機能は非常に便利です。特に開発と品質保証向け。これらのツールを使用する場合、アプリケーションから追加のメトリック ディメンションが収集され、Kubernetes ログ収集および監視と統合する必要があることに注意することが重要です。たとえば、サービス メッシュは、さまざまな問題の監視とトラブルシューティングに役立つ貴重なトレース情報を提供できます。

イメージ レジストリは、Kubernetes のもう 1 つの重要な拡張機能です。イメージ管理またはビルド リポジトリ管理は、ビルド バイナリ、Helm パッケージ、または Docker イメージのホスティングをはるかに超えています。アプリケーションのリカバリと Kubernetes の Pod 再起動機能をサポートし、デプロイメント時間とランタイムの両方に依存します。また、各リポジトリに誰が公開できるかなど、これらのアーティファクト リポジトリに関連付けられたガバナンス ルールを考慮し、これらのルールをセキュリティ フレームワークに統合する必要があります。

要約する

Kubernetes プラグインまたは拡張機能は、あらゆる Kubernetes スタックの重要な部分です。オーバーレイ ネットワーク、クラウド ネイティブ ストレージ、CI/CD フレームワークなどの一部の機能の場合、選択は簡単です。しかし、セキュリティとガバナンスは複雑な問題を引き起こします。さまざまなツールを組み合わせる場合、単一の包括的なツールがないため、セキュリティ要件について深く考え、考慮する必要があり、これは簡単ではありません。

次に、デフォルトで主要な拡張機能を設定することで Kubernetes のセキュリティとガバナンスの課題に対処する、Kublr などのエンタープライズ グレードの Kubernetes プラットフォームの使用を検討してください。このようなプラットフォームは、ID 管理システムや RBAC とも統合されます。