YAML を記述せずに Kubernetes アプリケーションを管理するにはどうすればよいでしょうか?

Kubernetes は、その境界内にあるすべてをリソースとして抽象化します。主要部分は、Deployment と StatefulSet によって表されるワークロード コントローラーです。他の種類のリソースは、これらのメイン リソースを中心に機能します。これらのリソースを組み合わせることで、IT 技術スタッフ向けのワークロード中心のモデルが実現します。 Kubernetes 内のすべてのリソースは、宣言型構成ファイルを通じて編集および記述されます。 Yaml フィールド定義は IT 技術者に最大限の自由を与えますが、同時にその能力に極めて高い要求を課します。

アプリケーションモデルでKubernetes管理を簡素化

チームがネイティブ Kubernetes をしばらく使用している場合、すべての IT 技術者が複雑な Kubernetes 宣言型構成ファイル (YAML) の作成に長けているわけではないことに気付くでしょう。特に、ビジネス開発を主な責任とする開発者にとって、YAML を学習して記述することは負担を増大させ、YAML の使用を躊躇させる原因にもなります。

オープンソース プロジェクト Rainbond は、アプリケーション中心の設計パターンを使用するクラウドネイティブ アプリケーション管理プラットフォームです。この設計パターンに基づいて、ワークロードよりも高いレベルのアプリケーション モデルが抽象化されます。ユーザーエクスペリエンスの観点からは、YAML を学習して記述する必要がなく、ビジネス アプリケーションの完全なライフサイクル管理を実現できます。アプリケーションは、個別に管理できる複数のサービス コンポーネントで構成される完全なビジネス システムに対応します。ビジネス コンポーネントをデプロイするときに、ソース コードとコンテナー イメージから「ドラッグ アンド ドロップ」することで、サービス呼び出し関係を編集できます。各サービス コンポーネントは、グラフィカル インターフェイスに基づいて、いくつかの共通の操作および保守機能を定義して使用できます。これを基に、ユーザーはアプリケーション モデルのコア概念を使用して、ビジネス システム全体をアプリケーション テンプレートの形式で公開するなど、より高度な操作を実行することもできます。また、テンプレートに基づいてビジネス システムをワンクリックでインストール/アップグレードすることもできます。ソフトウェア配信の分野では、この機能は非常に役立ちます。最終的な配信環境がオンラインかオフラインかに関係なく、アプリケーション テンプレートに基づいて迅速な配信やパーソナライズされた配信を実行できます。

Rainbond が使用するアプリケーション モデルにより、開発者はアプリケーションとビジネス自体に集中できるため、人々に受け入れられやすくなります。トリミング後も保持される操作およびメンテナンス機能は、グラフィカル インターフェイスを通じて表示および操作されるため、使用の難しさが大幅に軽減されます。アプリケーション テンプレートを使用すると、ほとんどの開発者は複雑な宣言型構成ファイルを編集することなく、Kubernetes をスムーズに使用できます。

Kubernetes YAMLをアプリケーションモデルに変換する

変換プロセス全体は、次の 3 つのステップに要約できます。

1. 開発者が最もよく使用するワークロードについては、ウィザードのような方法でソース コードとコンテナー イメージから自動的に生成したり、既存の YAML にインポートしてアプリケーションを実行したりできます。インポート プロセスでは、Deployment、StatefulSet、Job、CronJob タイプなど、変換可能なすべてのワークロード タイプ リソースが自動的に識別されます。これらのリソースはアプリケーション モデルに変換され、サービス コンポーネントとして実行されます。
2. 生成されたサービス コンポーネントをインポートした後、環境変数、イメージ アドレスなどの基本的なワークロード プロパティをインターフェイスを通じて表示および編集できます。変換プロセス中に、識別された高度なワークロード プロパティがサービス コンポーネントに追加され、キー/値または YAML の形式で表示および管理できます。
3. Secret、ServiceAccount、Role などの非ワークロード リソース タイプは分類および識別され、アプリケーション インターフェイスの k8s リソース ページに読み込まれ、オペレーターがインタラクティブなエクスペリエンスで編集できるようになります。

管理および変換できる高度なワークロード属性には次のものがあります。

拡張された RAM モデルは、その後のビジネス システム全体のワンクリック インストール/アップグレード/配信用のアプリケーション テンプレートとして公開できることは注目に値します。

既存のKubernetesアプリケーションのテストとプラクティスをインポートする

以下のテストは、Rainbond v5.8 に基づいています。既存のアプリケーションのKubernetesへのインポートをテストするために、wp名前空間にデプロイされているWordpressのWebサイト構築システムを使用してインポートテストを実行する予定です。このシステムは次のリソースで構成されています。

 [ root @localhost ~ ] # kubectl get secret 、 service 、 deployment 、 statefulset 、 pod - n wp
 名前タイプデータ年齢
シークレット/ デフォルト- トークン- nq5rs kubernetes .io / サービス- アカウント- トークン3 27 m
 シークレット/ mysql - シークレット不透明2 27 分
名前タイプクラスタ- IP 外部- IP ポート( S ) 年齢
サービス/ wordpress NodePort 10.43 .157 .40 < なし> 8080 : 30001 / TCP 5 分19秒
サービス/ wp - mysql ClusterIP 10.43 .132 .223 < なし> 3306 / TCP 27 分
名前準備完了最新利用可能年齢​ ​
 展開。 アプリ/ wordpress 1 / 1 1 1 5 分19秒
名前年齢​
 statefulset.apps / wp - mysql 1/1 27 m
 名前準備完了ステータス再起動年齢
pod / wordpress - 66 bc999449 - qv97v 1 / 1 実行中0 5 分19秒
pod / wp - mysql - 0 1 / 1 実行中0 27 分

Rainbond にアクセスし、クラスターで [インポート] を選択します。このページでは、リソースをインポートする名前空間​wp​​ ​ を選択できます。プラットフォームは、ラベルに従ってリソースをグループ化します。

Rainbond は、リソースで定義されたラベルに基づいてアプリケーションを分割します。たとえば、app.kubernetes.io/name:wp-mysql または app:wordpress に一致するリソースは、図の 2 つの異なるアプリケーションに分散されますが、上記のラベルを持たないリソースは、グループ化されていないアプリケーションに均一に分割されます。アプリケーション モデルの高度な適用はアプリケーション全体を対象としているため、アプリケーションの分割は非常に重要です。そのため、インポートする前に慎重に計画し、適切なラベルを追加する必要があります。

インポート プロセス中、Rainbond は拡張モデルを通じてさまざまな属性を管理します。運用・保守操作の大部分は非常に使いやすくなっており、残りの部分は Kubernetes 属性ページによって管理されます。

インポートが完了すると、WordPress と wp-mysql の両方のアプリケーションを Rainbond を使用して管理できるようになります。

• 港湾管理

インポートする前は、WordPress は NodePort タイプのサービスを通じて外部に公開されていました。ただし、Rainbond 管理をインポートした後は、ゲートウェイを使用して独自のポート 80 を公開できます。アクセス ポリシーを有効にするには、WordPress サービス コンポーネントを 1 回再起動する必要があることに注意してください。

一部のビジネスでは、アクセス エントリが動的な仕様をサポートしていないため、ビジネス側で新しいアクセス エントリに適応するために何らかの変更を加える必要があります。 Wordpress の場合は、一般オプションでサイト アドレスを再定義する必要があります。

• ストレージ管理

私が導入した WordPress システムでは、すべてのコンポーネントがストレージにホストパス モードを使用します。この構成はシンプルですが、Pod がドリフトする可能性がある大規模な Kubernetes 環境には適していません。 Rainbond を導入すると、複数の Pod 間でのデータ共有やホスト間での Pod の移行をサポートする、使いやすい共有ストレージが提供されます。元のホストパス ストレージを再定義できます。再定義されたストレージ パスは空になるため、新しいパスと古いパスを見つけてデータ移行を実行することを忘れないでください。

実用的な意義

このモデルを適用することで、IT 技術者は、基盤となる複雑なツールの使用ではなく、ビジネスそのものに重点を置くことができます。最終的な効果は、運用コストと理解の難しさが簡素化され、Kubernetes の実装が容易になることです。