必須の Kubernetes ツール (2021 年版)

導入

この記事では、最新かつあまり一般的ではない Kubernetes エコシステム ツールの概要をまとめます。これは、著者が気に入っており、可能性を秘めている Kubernetes ツールのリストでもあります。リストされているツールは個人的な経験に基づいているため、偏見や誤解を避けるために、この記事では各ツールの代替案を提供し、読者がニーズに応じて比較できるようにします。

[[425426]]

この記事を執筆する著者の目的は、さまざまなソフトウェア開発タスクに使用されるツールのエコシステムについて説明し、Kubernetes 環境でタスクを完了する方法についての質問に答えることです。

翻訳

K3D は、ラップトップ上で Kubernetes (K8S) クラスターを実行するための著者が推奨する方法です。 Docker を使用して K3S パッケージをデプロイし、非常に軽量かつ高速です。実行には Docker 環境のみが必要で、リソースの消費量は非常に少なくなります。唯一の欠点は、K8s と完全に互換性がないことですが、ローカル開発の場合、これは基本的に問題になりません。テスト環境で使用する場合は、kind などの他のソリューションを使用することをお勧めします。 Kind は K8s と完全に互換性がありますが、K3D ほど高速には実行されません。

代替案

• IoT K3S または Edge K3S
• KindはK8Sと完全に互換性があります
• マイクロK8S
• ミニキューブ
• *## クルー##
• Krew は Kubectl プラグインを管理するための重要なツールであり、すべての k8 ユーザーにとって必須のツールとなる可能性があります。 Krew は 145 を超えるエコロジカル プラグインの管理をサポートしています。一般的なアプリケーションは、kubens および kubectx プラグインのインストールと管理です。

レンズ

Lens は、K8 に取り組む SRE エンジニア、Ops エンジニア、ソフトウェア開発者向けの統合開発環境です。物理デプロイメントやクラウドデプロイメント環境を含むすべての Kubernetes ディストリビューションに適用できます。 Lens は高速で使いやすく、リアルタイムの観察機能を提供します。複数のクラスターを簡単に管理できるため、マルチクラスターの運用および保守担当者にとって必須のツールです。

代替案

軽量の端末を好む人にとって、K9s は Kubernetes の変更を継続的に監視し、監視対象のリソース オブジェクトと対話するための操作手順を提供するため、適切な選択肢です。

舵

言うまでもなく、Helm は Kubernetes で最も有名なパッケージ マネージャーであり、プログラミング言語を使用するのと同じ効果を提供します。 Helm はアプリケーションを Charts にパッケージ化することをサポートしており、複雑なアプリケーションを、定義、インストール、更新が容易なシンプルで再利用可能なコンポーネントに抽象化します。 Helm は非常に成熟しており、使いやすいです。強力なテンプレート エンジン、多数の定義済みチャート、強力なテクニカル サポート サービスを提供します。

代替案

Kustomize は、テンプレート エンジンを使用しない、新しく登場した潜在的な Helm 代替ツールです。代わりに、ユーザーの基本定義の上にオーバーレイ エンジンを構築して、テンプレート エンジンと同じ機能を実現します。

アルゴCD

GitOps は過去 10 年間で最高のアイデアの 1 つだと思います。ソフトウェア開発では、ソフトウェアの構築に必要なすべての動的コンポーネントを追跡するための単一の信頼できる情報源が必要です。Git はこのニーズを解決するのに最適なツールです。アイデアは、アプリケーション コードと、望ましい運用環境の状態の宣言的な記述を含む Git リポジトリと、環境を必要な状態に一致させる自動プロセスを提供することです。

GitOps: 宣言型インフラストラクチャに基づくバージョン管理された CI/CD。スクリプトを廃止し、配信を開始します。 —ケルシー・ハイタワー

ただし、Terraform や同様のツールを使用して Infrastructure as Code (IaC) を実装することも可能です。ただし、本番環境の Git で目的のステータス同期を実現することはまだできません。環境を継続的に監視し、構成のドリフトが発生しないようにする方法が必要です。 Terraform ツールを使用する場合、ユーザーは本番環境でステータス チェックを実行し、Terraform の構成ステータスと一致しているかどうかを確認するスクリプトを作成する必要がありますが、この方法は面倒で保守が困難です。

Kubernetes は、完全なプロセス制御ループという概念に基づいて構築されています。つまり、Kubernetes はクラスターの状態を 24 時間 365 日監視し、期待どおりの状態であることを確認できます。たとえば、K8s で実際に実行されているレプリカの数は、構成されたレプリカの数と等しくなります。 GitOps アプローチでは、このモデルをアプリケーションにも拡張し、ユーザーがサービスをコードとして定義できるようにします。たとえば、Helm Charts を定義し、ツールを使用して k8s 機能を活用し、アプリケーションの状態を監視し、それに応じてクラスターの状態を調整します。つまり、コード ベースまたは Helm チャートが更新されると、それに応じて本番クラスターも自動的に更新され、真の継続的デプロイメントが実現されます。

アプリケーションの展開とアプリケーションのライフサイクル管理の基本原則は、自動化、監査可能性、理解のしやすさです。著者はこれが革命的なアイデアだと信じています。適切に実装されれば、企業は自動化されたスクリプトの作成に費やす時間を減らし、ビジネス機能にさらに注力できるようになります。この概念は、ソフトウェア開発の他の領域にも拡張できます。たとえば、開発ドキュメントをコードに含めたり、変更履歴の追跡やドキュメントのタイムリーな更新を実装したり、ADR を使用してアーキテクチャ上の決定を追跡したりすることができます。

私の意見では、Kubernetes に最適な GitOps ツールは、Argo エコシステムの一部である ArgoCD です (Argo エコシステムには、後で説明する他の優れたツールも含まれています)。 ArgoCD 機能を使用すると、ユーザーは各環境をコード ベースに保存し、上記の各環境のすべての構成を定義できるため、特定のターゲット環境に必要なアプリケーション状態を自動的に展開できます。 ArgoCD の技術アーキテクチャを次の図に示します。

ArgoCD は Kubernetes コントローラーと同様に実装されており、実行中のアプリケーションを継続的に監視し、現在の状態と目的の状態を比較します (構成は Git リポジトリに保存されます)。 Argo CD は、ステータスの差異に関するレポートと視覚化を提供し、アプリケーション ステータスを予想されるステータスに自動または手動で同期することをサポートします。

代替案

• Flux の最新リリースには多くの改善が加えられており、非常に類似した機能が提供されています。

Argo WorkMows と Argo イベント

Kubernetes 環境では、バッチジョブや複雑なワークフローを実行する必要があります。アプリケーション シナリオは、データ パイプライン、非同期プロセス、または CI/CD の一部またはすべてである場合があります。さらに、特定のイベントに応答するために、イベント駆動型マイクロサービスを実行する必要がある場合もあります。たとえば、ファイルをアップロードしたり、メッセージをメッセージ キューに送信したりします。上記の要件を満たすには、Argo WorkMows および Argo Events ツールを使用できます。これらは 2 つの独立したプロジェクトですが、実際の使用では、アプリケーションはペアで展開されることがよくあります。

Argo WorkMows は、Apache AirFlow に似たオーケストレーション エンジンであり、Kubernetes のネイティブ エンジン ツールです。カスタム CRD を使用して、ステップバイステップの構成またはネイティブ YAML 有向非巡回グラフを使用して複雑な WorkMows を定義します。ユーザーフレンドリーなインターフェース、再試行メカニズム、スケジュールされたジョブ、入出力追跡などの機能を提供し、ユーザーがデータ パイプラインやバッチ ジョブなどを調整できるようにサポートします。

ユーザーは、独自のアプリケーション パイプラインを、Kafka ストリーミング エンジン、メッセージ キュー、Webhook、ディープ ストレージ サービスなどの非同期サービスと統合したい場合があります。たとえば、S3 ファイルアップロード イベントに反応します。この目的には Argo Events を使用できます。

上記の 2 つのツールを組み合わせることで、CI/CD を含むすべてのユーザー パイプラインのニーズに対応するシンプルで強力なソリューションが提供され、ユーザーは Kubernetes 環境でネイティブに CI/CD パイプラインを実行できるようになります。

代替案

• KubeMow、ML 目的のパイプライン
• CI/CD パイプライン用の Tekton

カニコ

先ほど、Argo WorkMows を使用して Kubernetes 環境でネイティブ CI/CD パイプラインを実行する方法について説明しました。一般的なタスクの 1 つは、Docker イメージを構築することです。 Kubernetes のビルド プロセスは、実際にはホストの Docker エンジンを使用してコンテナ イメージ自体を実行するものであり、非常に面倒なプロセスです。

Kaniko を使用する基本原則は、ユーザーはイメージを構築するために Docker ではなく Kaniko を使用する必要があるということです。 Kaniko は Docker デーモンに依存せず、Dockerfile の内容に従ってユーザー空間でコマンドを 1 行ずつ実行してイメージを構築します。これにより、Docker プロセスを安全かつ迅速に取得できない環境 (標準の Kubernetes クラスターなど) でもコンテナ イメージを構築できるようになります。同時に、Kaniko は K8S クラスターでイメージを構築する際のすべての問題を排除します。

イスティオ

Istio は、市場で最も有名で人気のあるオープンソース サービス メッシュ ツールです。サービス メッシュの概念について詳しく説明する必要はありません (これは非常に大きなトピックです)。ユーザーがマイクロサービスを構築する準備をしている場合、またはマイクロサービスを構築している場合、サービス通信、サービス可観測性、エラー処理、セキュリティ制御、およびマイクロサービス アーキテクチャのクロスプレーン通信を管理するためにサービス メッシュが必要です。サービス メッシュを使用すると、ロジックの重複による単一のマイクロサービスでのコード汚染を回避できます。 Istio の技術アーキテクチャを次の図に示します。

つまり、サービス メッシュは、アプリケーションに追加できる特殊なインフラストラクチャ レイヤーです。これにより、ユーザーはコードを記述することなく、可観測性、トラフィック管理、セキュリティなどの機能を透過的に追加できます。 Istio の実行と Istio を使用したマイクロサービスの実行に精通しているユーザーにとって、Kubernetes は実行に最適なプラットフォームであることが何度も証明されています。 Istio は、k8s クラスターを VM などの他のサービス環境に拡張して、ユーザー向けのハイブリッド環境を構築することもできます。これにより、アプリケーションを Kubernetes に移行しやすくなります。

代替案

• Linkerd は、より軽量で高速なサービス メッシュです。 Linkerdはもともとセキュリティのために開発され、デフォルトでmTLSを起動するなどのサービスを提供していました。
• Rust はデータプレーンを構築し、メモリセーフな言語を採用し、定期的なセキュリティ監査を実施します。
• Consul は、あらゆるランタイムおよびクラウド プロバイダー向けに構築されたサービス メッシュであり、K8s とパブリック クラウドにわたるハイブリッド展開に最適です。純粋な Kubernetes ワークロードを実行していない組織に最適です。

アルゴのロールアウト

前述したように、Kubernetes 環境では、Argo WorkMows または同様のツールを使用して CI/CD パイプラインを実行し、Kaniko を使用してコンテナ イメージを構築できます。そして次の論理的なステップは、継続的なデプロイメントに移行することです。次のステップは、リスクが高いため、現実のシナリオでは非常に困難です。これが、ほとんどの企業が継続的デリバリーで止まってしまう主な理由であり、これらの企業には自動化、手動承認、手動検証というプロセス ステップがあることも意味します。現在の状況の主な原因は、チームが自動化を完全に信頼していないことです。

では、すべての手動スクリプトを排除し、ソース コードから本番環境への展開まで完全な自動化を実現するために必要な信頼をどのように構築すればよいのでしょうか。答えは「可観測性」です。一連の指標を通じて信頼を構築するという目標を達成するためには、指標の観察に重点を置き、アプリケーションの状況を正確に表すことができるすべてのデータを収集するために、より多くのリソースを投資する必要があります。すべてのインジケーター データが Prometheus で利用可能であると仮定すると、これらのインジケーター データに基づいてアプリケーションを自動的にロールアウトし、アプリケーションの自動デプロイメントを実現できます。

つまり、K8S はすぐに使用できるローリング アップデート テクノロジーを提供します。これよりも高度なデプロイメント テクノロジが必要な場合は、段階的な配信にカナリア デプロイメントを使用する必要があります。つまり、トラフィックをアプリケーションの新しいバージョンに徐々に切り替えてから、インジケーター データを収集して分析し、事前に定義されたルールと照合し、すべてが正常であれば、より多くのトラフィックを切り替えることができます。問題がある場合は、デプロイメントをロールバックします。

Kubernetes では、Argo Rollouts がカナリア デプロイメントなどを提供します。 Kubernetes コントローラーとシステム CRD が組み込まれており、Kubernetes プログレッシブ配信のためのブルーグリーン デプロイメント、カナリア デプロイメント、カナリア分析、デプロイメント実験などの高度なデプロイメント機能を提供します。

Istio などのサービス メッシュもカナリア リリース機能を提供していますが、Argo ロールアウトは、より合理化された開発者中心のリリース プロセスを備え、この目的のために特別に構築されています。最も重要なことは、Argo Rollouts をあらゆるサービス メッシュと統合できることです。提供される機能は次のとおりです。

• ブルーグリーンアップデート戦略
• カナリアアップデート戦略
• きめ細かな重み付けによる軌道切り替え
• 自動更新とロールバック、または手動判断と実行
• カスタマイズされた指標クエリとビジネスKPI分析
• Ingress コントローラーは、NGINX、ALB などとの統合をサポートします。
• サービス メッシュは、Istio、Linkerd、SMI などとの統合をサポートします。
• 統合されている定量的指標ソースには、Prometheus、Wavefront、Kayenta、Web、Kubernetes Jobs などがあります。

代替案

• Istio は、単なるプロセス配信ツールではなく、カナリア リリース機能を備えたサービス メッシュ ツールです。 Istio は自動デプロイメントをサポートしていませんが、Argo ロールアウトと統合することで実現できます。
• Flagger は Argo Rollouts と非常によく似ており、Flux と非常によく統合されるため、Flux を使用する場合は Flagger を検討することをお勧めします。
• Spinnaker は豊富な機能を備えた最初の Kubernetes 継続的デリバリー ツールですが、その使用と構成は比較的複雑です。

クロスプレーン

Crossplane は、著者のお気に入りであり、最も関心のある k8s エコロジカル プロジェクトです。サードパーティのサービスを k8s リソースとして管理し、k8s の重要な機能を完成させます。つまり、ユーザーは YAML を使用して、K8s で AWS RDS や GCP クラウド SQL などのパブリック クラウド データベースを定義できます。

Crossplane ツールを使用すると、ユーザーはインフラストラクチャとコードを分離するためにさまざまなツールや方法論を使用する必要がなくなります。あらゆる外部サービスを K8s リソースとして定義できるため、Terraform などのツールの使用方法やデプロイ方法を個別に学習する必要がなくなります。

Crossplane はオープンソースの Kubernetes プラグインであり、プラットフォーム チームが複数のベンダーのインフラストラクチャをカプセル化し、コードを記述することなく、より高レベルのセルフサービス API をアプリケーション チームに公開できるようにします。

Crossplane は Kubernetes クラスターの機能を拡張し、あらゆるインフラストラクチャやクラウド サービスを管理するための CDR を提供します。さらに、Terraform などの他のツールとは異なり、Crossplane は既存の K8s 制御ループなどの既存の機能を使用してクラスターを継続的に監視し、実行時に構成のドリフトを自動的に検出し、完全な継続的デプロイメントを可能にします。たとえば、ユーザーが管理対象データベース インスタンスを定義したが、別のユーザーが手動で構成を変更した場合、Crossplane は自動的にイベントを検出し、構成のロールバックを実行します。このプロセスは、Infrastructure as Code と GitOps の原則も強化します。

Crossplane は Argo CD と非常によく統合されており、ソース コードを監視してコード ベースが一意で信頼できるものであることを保証できます。コードの変更はすべてクラスターと外部クラウド サービスに同期されます。 Crossplane がなければ、ユーザーは GitOps を K8s にデプロイすることしかできず、K8s とパブリック クラウド間で共有することはできません。

代替案

• Terraform は最も有名な IaC ツールですが、K8s エコシステムのネイティブ ツールではありません。ユーザーの追加スキルが必要であり、構成ドリフトの自動監視機能はありません。
• Pulumi は、開発者がテストして理解できるプログラミング言語で実行される Terraform の代替手段です。

ネイティブ

ユーザーがパブリッククラウドでアプリケーションを開発する場合、イベント駆動型パラダイム FaaS の AWS Lambda などの特定のサーバーレス コンピューティング テクノロジを使用する場合があります。サーバーレス コンピューティングについては以前に説明しているので、ここではその概念を繰り返すつもりはありません。しかし、サーバーレス コンピューティングを使用する場合の問題は、イベント駆動型アプリケーションの巨大なエコシステムを構築できるパブリック クラウドと密接に結合していることです。

Kubernetes の場合、ユーザーがイベント駆動型アーキテクチャを使用して function-as-code アプリケーションを実行したい場合、Knative が最適な選択肢になります。 Knative は、Kubernetes でサーバーレス関数を実行するために、Pod の上に抽象化レイヤーを作成するように設計されています。主な機能は次のとおりです。

• 一般的なアプリケーションの使用例向けに、より高レベルの抽象化APIを提供します。
• スケーラブルで安全、かつステートレスな第2レベル機能サービスを提供
• オンデマンド使用をサポートするために疎結合機能アーキテクチャを採用
• プラグ可能なコンポーネントは、外部のログ記録と監視、ネットワーク、サービスメッシュツールの使用をサポートします。
• コンポーネントの移植性により、ベンダー ロックインを心配することなく、あらゆる Kubernetes 環境で実行できます。
• 一般的な開発コンセプトを継承し、GitOps、DockerOps、ManualOpsなどの一般的なモードをサポートし、Django、Ruby on Rails、Springなどの一般的な開発ツールやフレームワークと互換性があります。

代替案

• argo Events は、Kubernetes 用のイベント駆動型ワークフロー エンジンを提供し、AWS Lambda などのクラウド エンジンとの統合をサポートします。 FaaSではありませんが、Kubernetes用のイベント駆動型アーキテクチャを提供します。
• オープンファアス

キベルノ

Kubernetes は、アジャイルで自律的なチームに強力な柔軟性を提供します。しかし、大きな力には大きな責任が伴います。K8s には、ワークロードが一貫性​​と一貫性のある方法で展開および管理され、このアプローチが会社のポリシーとセキュリティ仕様に準拠していることを保証するための一連のベスト プラクティスとルールが必要です。

Kyverno が登場する前は、上記の要件を実現できるツールはいくつかありましたが、Kubernetes のネイティブ ツールはありませんでした。 Kyverno は、K8s エコシステム向けに設計されたポリシー エンジンです。ポリシーは K8s のリソースとして定義され、ポリシーを記述するために新しい言語は必要ありません。 Kyverno には、ポリシー用の Kubernetes リソースを検証、進化、生成する機能があります。

Kyverno ポリシーは一連のルールです。各ルールは、一致句、オプションの除外句、検証句、変更句、または生成句で構成されます。ルール定義には、検証、ミューテーション、または生成の子ノードを 1 つだけ含めることができます。

ユーザーは、ベスト プラクティス、ネットワーク、セキュリティなどに関連するあらゆる種類のポリシーを使用できます。たとえば、すべてのサービスにラベルを付けることや、すべてのコンテナーを非ルートとして実行することを強制することができます。ユーザーはポリシーのユースケースを表示し、クラスター全体または指定された名前空間にポリシーを適用できます。また、ポリシーを監査するか、ユーザーによるリソースのデプロイを強制的にブロックするかを選択することもできます。

代替案

Open Policy Agent は、よく知られたクラウドネイティブのポリシー制御エンジンです。独自の宣言型言語を使用しており、K8s だけでなく多くの環境に適用できます。 Kyverno よりも強力ですが、管理も難しくなります。

クベベラ

K8s を使用する際の問題の 1 つは、開発者がプラットフォームとクラスターの構成を非常に明確に理解する必要があることです。多くのユーザーは、K8s の抽象化レベルが低すぎるため、アプリケーションの作成とリリースに重点を置く開発者の作業コラボレーションに多くの摩擦が生じると考えるかもしれません。

この問題を解決するために、オープン アプリケーション モデル (OAM) が誕生しました。その設計思想は、基盤となるランタイムを保護し、アプリケーションに対してより高レベルの抽象化を作成することです。

コンテナやコンテナ オーケストレーションと比較して、オープン アプリケーション モデル [OAM] はアプリケーションに重点を置いており、アプリケーションの展開にモジュール式で拡張可能かつ移植可能な設計をもたらし、より高レベルの API を提供します。

Kubevela は、OAM モデルの機能実装です。コアコンセプトはアプリケーション中心であり、ランタイム要件がなく、ネイティブのスケーラビリティを備えています。 Kubevela では、アプリケーションは K8s リソースとして定義され、最も高いデプロイメント優先度を持ちます。アプリケーションのデプロイメントは、クラスター オペレーター (プラットフォーム チーム) と開発者 (アプリケーション チーム) にとって意味が異なります。クラスター オペレーターは、コンポーネント (Helm チャートに似たデプロイ可能/定義可能なエンティティ) と機能を定義して、クラスターとさまざまな環境を管理します。開発者はコンポーネントと機能を組み立てることでアプリケーションを定義します。

プラットフォーム チーム: ターゲット環境の仕様に沿って、プラットフォーム機能をコンポーネントまたは機能としてモデル化し、管理します。

アプリケーション チーム: 環境を選択し、必要に応じてアプリケーション コンポーネントと機能を組み立てて、ターゲット環境にデプロイします。

KubeVela は、Cloud Native Computing Foundation のサンドボックス プロジェクトです。現在はまだ初期段階ですが、近い将来には K8s の使用方法が変わり、開発者が Kubernetes の専門家でなくてもアプリケーション開発に集中できるようになる可能性があります。しかし、OAM が現実世界に適用できるかどうかについては、いくつかの懸念があります。システム ソフトウェア、ML、ビッグ データ処理などのサービスの場合、基礎となる詳細に大きく依存しており、これを OAM モデルに組み込むのは難しい場合があります。

代替案

Shipa も同様のアプローチを採用しており、プラットフォーム チームと開発チームが連携して、K8s 環境にアプリケーションを簡単にデプロイできるようにします。

スニク

セキュリティは、あらゆるソフトウェア開発プロセスにおいて非常に重要な側面です。アプリケーションを K8s に移行するユーザーユニットが既存のセキュリティ原則を K8s 環境に導入することは困難であるため、セキュリティは K8s にとって大きな問題点となっています。 Snyk は、Kubernetes と簡単に統合でき、コンテナ イメージ、コード、オープン ソース プロジェクトなどのコンポーネントの脆弱性を検出できるセキュリティ フレームワークです。 K8sのセキュリティ問題を軽減するために、

代替案

Falco は、Kubernetes 環境向けのランタイムセーフなスレッド計測ツールです。

ベレロ

Kubernetes でワークロードを実行し、ボリュームを使用してデータを保存する場合は、データのバックアップを作成して管理する必要があります。 Velero は、シンプルなバックアップ/復元プロセス、災害復旧メカニズム、データ移行などの機能を提供します。

Kubernetes etcd ライブラリに直接アクセスしてバックアップと復元を実行する他のツールとは異なり、Velero は Kubernetes API を使用してクラスター リソースの状態をキャプチャし、必要に応じて復元します。さらに、Velero を使用すると、ユーザーはソフトウェア構成を実行しながら、アプリケーションの永続データをバックアップおよび復元できます。

スキーマヒーロー

ソフトウェア開発におけるもう 1 つの一般的なプロセスは、リレーショナル データベースを操作するときにスキーマの進化を管理することです。 Schema Hero は、スキーマ定義をあらゆる環境に適用できる移行スクリプトに変換するオープンソースのデータベース スキーマ移行ツールです。 Kubernetes の宣言型機能を使用して、データベース スキーマの移行を管理します。ユーザーは希望する状態を指定するだけで、残りは Schema Hero が管理します。

代替案

LiquidBase は最も注目すべき代替手段ですが、強力ではあるものの Kubernetes ネイティブではなく、操作が困難です。

ビットナミの封印された秘密

ArgoCD を含むいくつかの GitOps ツールを導入しました。これらのツールは、すべてを Git リポジトリ内に保存し、ネイティブの Kubernetes 宣言を使用して環境との同期を維持できるように設計されています。前述したように、ArgoCD ツールは Git 内のソース コードの信頼性を保証し、構成の変更を処理するための自動プロセスを提供します。

しかし、データベースのパスワードや API キーなどの秘密を Git に保存するのは困難な場合がよくあります。ユーザーはコードベースに秘密鍵情報を含めるべきではないためです。一般的な解決策は、AWS Secret Manager や HashiCorp などの外部ボールトを使用してシークレットを保存することですが、この解決策では、シークレットを処理するために追加の個別のスレッドが必要になるという不便さが生じます。理想的には、他の種類のリソースを管理するのと同じように、Git でキーを安全に保存する方法が必要です。

Sealed Secrets はこの問題を解決するツールです。強力な暗号化機能を提供し、ユーザーは機密データを Git に保存できます。 Bitnami Sealed Secrets は K8s にネイティブに統合されており、ユーザーは Kubernetes で実行されているコントローラーを通じてのみシークレットを復号化できます。コントローラーはデータを復号化し、安全に保存されるネイティブ K8S キーを作成します。これにより、ユーザーは任意のコンテンツをコードとして保存できるようになり、外部の依存関係なしに継続的なデプロイメントを安全に実行できるようになります。

Sealed Secrets は、クライアント側コントローラーとクライアント側アプリケーション Kubeseal の 2 つの部分で構成されます。キーの暗号化には非対称暗号化が使用され、コントローラーのみが復号化できます。暗号化されたキーは K8S リソースとしてカプセル化され、Git に保存できます。

代替案

• SOPSは比較的シンプルな鍵管理ツールです

• AWS シークレットマネージャー

• 金庫

カプセル

多くの企業は、さまざまな顧客を管理するためにマルチテナントを使用していますが、これはソフトウェア開発設計では一般的ですが、Kubernetes で実装するのは困難です。名前空間は、論理パーティショニングを活用してクラスター内に独立したシャードを作成するのに適した方法ですが、ユーザーを安全に分離するには不十分です。ネットワーク ポリシーやクォータの適用などの機能も必要です。ユーザーは名前空間ごとにネットワーク ポリシーとルールを作成できますが、そのプロセスは面倒で、拡張が困難です。さらに、テナントの主な制限は、名前空間間で使用できないことです。

上記の問題のいくつかを克服するために、階層継承名前空間が作成されました。設計の考え方は、各テナントに親名前空間を構築し、共通のネットワーク ポリシーとクォータを提供し、これに基づいて子名前空間を作成できるようにすることです。これは大きな改善ですが、テナントのセキュリティとガバナンスに対するネイティブの技術サポートはなく、機能はまだ本番環境で使用できる状態ではありません。バージョン1.0は来月リリースされる予定です。

この問題を解決するもう 1 つの一般的な方法は、顧客ごとにクラスターを作成することです。これにより、セキュリティが確保され、テナントに必要なものがすべて提供されますが、管理が困難になり、コストが高くなります。

Capsule は、単一の K8s クラスター内の複数のテナントの管理をネイティブにサポートするツールです。 Capsule を使用すると、ユーザーはすべてのテナントを同じクラスター内に作成できます。 Capsule は、クラスター共有の基本的な特性を隠すことで、テナントにネイティブに近いエクスペリエンス (いくつかの小さな制限のみ) を提供し、テナントが単一のクラスター内に複数の名前空間を作成し、クラスター リソースを完全に使用できるようにします。

単一のクラスターでは、Capsule コントローラーは、Kubernetes 名前空間のセットである軽量の Kubernetes 抽象化 (テナント) に複数の名前空間を集約します。各テナントでは、ユーザーは独自の名前空間を自由に作成し、割り当てられたリソースを共有することができ、ポリシー エンジンによって異なるテナント間の分離が保証されます。

「階層型名前空間」の動作メカニズムと同様に、「ネットワークとセキュリティ ポリシー」、「リソース クォータ」、「制限範囲」、「RBAC」などのテナント レベルのポリシー定義は、テナント内のすべての名前空間に自動的に継承されます。このようにして、ユーザーはクラスター管理者の介入なしにテナントを自由に管理できます。 Capsule は宣言型であり、すべての構成が Git に保存されるため、Capsule にはネイティブで GitOps 機能が備わっています。

vクラスタ

VCluster はマルチテナント管理をさらに進めます。 Kubernetes クラスター内に仮想クラスター環境を作成できます。各仮想クラスターは、完全に分離された通常の名前空間で実行されます。仮想クラスターは独自の API サービスと独立したデータ ストレージを提供するため、仮想クラスターで作成された各 K8s オブジェクトは実行中の仮想クラスター内にのみ存在します。さらに、ユーザーは通常の K8s クラスターを操作するのと同じように、仮想クラスターで kube コンテキスト命令を使用できます。

単一の名前空間でデプロイメントを作成する場合と同様に、ユーザーは仮想クラスターを作成してクラスター管理者になることができ、クラスター テナントは名前空間の作成、CRD のインストール、権限の構成などを行うことができます。

仮想クラスターを超軽量かつコスト効率の高いものにするために、vCluster では API サーバーとして k3s を使用することをお勧めします。また、k3s クラスターは K8s と 100% 互換性があるため、仮想クラスターも当然 100% 互換性があります。超軽量 (1 ポッド) 機能により、ユーザーは基盤となるクラスターにアクセスすることなく、非常に少ないリソースで任意の Kubernetes クラスター上で実行できます。 vCluster は Capsule よりもわずかに多くのリソースを消費しますが、柔軟性が高く、マルチテナントはその使用例の 1 つにすぎません。

その他のツール

• Kube-burner はストレス テストに使用されます。メトリックの監視とアラートを提供します。カオスエンジンのリトマス
• Kubewatch は監視に使用されますが、主に Kubernetes イベント (リソースの作成や削除など) のプッシュ通知に重点を置いています。 Slackなどの多くのツールとの統合をサポート
• Botkube は、Kubernetes クラスターを監視およびデバッグするためのメッセージング ボットです。 kubewatchに似ていますが、より新しく、より多くの機能を備えています
• MizuはAPIトラフィックビューアおよびデバッガーです
• Kube-medged は、Kubernetes クラスターのワーカーノード上で直接コンテナイメージのキャッシュを作成および管理する Kubernetes のアドオンです。そのため、イメージライブラリからイメージを取得する必要がなく、アプリケーション Pod を即座に起動できます。

結論は

この記事では、著者のお気に入りの Kubernetes エコシステム ツールをレビューします。著者は、あらゆる Kubernetes ディストリビューションに組み込むことができるオープンソース プロジェクトに焦点を当てています。内容が一般性を持つため、この記事では OpenShift やクラウド プロバイダーのアドオンなどの商用ソリューションについては取り上げません。しかし、ユーザーがパブリック クラウド上で Kubernetes 環境を実行したり、商用ツールを使用したりする場合は、クラウドの可能性を積極的に探求することが推奨されます。

この記事の著者の目標は、プライベートにデプロイされた Kubernetes 環境で何ができるかをユーザーに示すことです。同時に、著者は Crossplane、Argo Rollouts、Kubevela など、あまり知られていないが潜在的な可能性を秘めたツールにも注目しています。私は特に、vCluster、Crossplane、ArgoCD/WorkMows などのツールに興味があります。