Kubernetes は、その境界内のすべてをリソースとして抽象化します。主要部分は、Deployment と StatefulSet に代表されるワークロード ワークロード コントローラーであり、その他のさまざまなリソースがこれらの主要なリソースの周りで機能します。これらのリソースを組み合わせることで、IT 技術者向けのワークロード中心のモデルを提示できます。Kubernetes のすべてのリソースは、宣言型の構成ファイルを介して編集および記述され、Yaml フィールド定義は 1 つずつ定義されます。これにより、IT 技術者に最大の自由度が与えられるだけでなく、技術者の能力に対して非常に高い要件が提示されます。
アプリケーション モデルを使用して Kubernetes の管理を簡素化する
チームがネイティブ Kubernetes をしばらく使用していると、すべての IT 技術者が複雑な Kubernetes 宣言型構成ファイル (YAML) の記述に長けているわけではないことに気付くでしょう。特にビジネス開発を主な責務とする開発者にとって、YAML の学習と記述は負担を増大させ、YAML の使用に抵抗することさえあります。
オープン ソース プロジェクトの Rainbond は、アプリケーション中心の設計パターンを使用するクラウド ネイティブのアプリケーション管理プラットフォームです。この設計パターンに基づいて、ワークロードよりも上位のアプリケーション モデルが再抽象化されます。使用経験から YAML を学習して記述する必要はなく、ビジネス アプリケーションの完全なライフ サイクル管理を実現します。アプリケーションは独立して管理できる複数のサービス部品から構成される完全な業務システムに対応しており、業務コンポーネントをデプロイする際に、ソースコードやコンテナイメージからドラッグ＆ドロップでサービス呼び出し関係を編集することができます。各サービス コンポーネントは、グラフィカル インターフェイスに基づいて、いくつかの一般的な運用および保守機能を定義して使用できます。これに基づいて、ユーザーはアプリケーションモデルのコアコンセプトを使用して、アプリケーションテンプレートの形式でビジネスシステム全体を公開するなど、より高度な操作を実行することもでき、ビジネスシステムはワンクリックでインストール/アップグレードできます。テンプレート。ソフトウェア配信の分野では、この機能は非常に便利で、最終的な配信環境がオンラインであろうとオフラインであろうと、アプリケーション テンプレートに基づいて迅速に配信でき、さらにはパーソナライズされた配信も可能です。
Rainbond が使用するアプリケーション モデルにより、開発者はアプリケーションとビジネス自体に集中しやすくなります。切断後に保持されている運用および保守機能は、グラフィカル インターフェイスを介して表示および操作されるため、使用の難易度が大幅に低下します。
Kubernetes YAML をアプリケーション モデルに変換する
変換プロセス全体は、次の 3 つのステップに要約できます。
- For the most common workloads by developers, they can automatically generate from source code and container images in a wizard-like way, or by importing existing YAML and running applications. インポート プロセスは、すべての変換可能なワークロード タイプ リソースを自動的に識別します。 StatefulSet、Job、および CronJob タイプ。これらのリソースはアプリケーション モデルに変換され、サービス コンポーネントとして実行されます。
- 生成されたサービス コンポーネントをインポートした後、環境変数、ミラー アドレスなどの基本的なワークロード プロパティをインターフェイスを介して表示および編集できます。変換プロセス中に、特定された高度なワークロード プロパティがサービス コンポーネントに追加され、キー/値または Yaml の形式で表示および管理できます。
- Secret、ServiceAccount、Role、およびその他のリソースなどの非ワークロード リソース タイプは、オペレーターがインタラクティブなエクスペリエンスで編集できるように、分類、識別され、アプリケーション インターフェイスの
k8s资源ページ。
管理および変換できる高度なワークロード プロパティには、次のものがあります。
| プロパティ名 | 効果 |
|---|---|
| ノードセレクター | ノード セレクター: 特定のタイプのノード スケジューリングを指定するときに使用します。 |
| ラベル | ラベル: セレクターが使用するサービス コンポーネントのラベルをカスタマイズするために使用されます。 |
| ボリューム | ストレージ ボリューム: Rainbond によって管理されないタイプのボリュームを定義するために使用されるマウント。 |
| ボリュームマウント | ボリュームのマウント: ボリュームと組み合わせて使用して、ボリュームをコンテナーにマウントします。 |
| 親和性 | アフィニティ: ノード アフィニティやポッド アフィニティなど、より高度なスケジューリング方法。 |
| 寛容 | Tolerance: ノード taint と組み合わせて使用すると、指定された許容値を持つ Pod を指定されたノードにスケジュールできます。 |
| サービスアカウント名 | サービス アカウント名: サービス コンポーネントの既存の SA を指定して、対応する Pod が特定の権限を持つようにします。 |
| 特権的な | 特権モード: 真の構成であり、必要な場合以外はオンにしないでください。 |
| 環境 | 環境変数: Rainbond によって管理されない環境変数を定義し、参照操作をサポートするために使用されます。 |
拡張 RAM モデルはアプリケーション テンプレートとして引き続き公開できるため、ビジネス システム全体をワンクリックでインストール/アップグレード/配布できることに注意してください。
既存の Kubernetes アプリケーションのインポートのテストと実践
以下のテストは Rainbond v5.8 に基づいています. Kubernetes で既存のアプリケーションのインポートをテストするwpためWordpressに、名前空間にデプロイされているステーション ビル システムを使用してインポート テストを実行する予定です。システムは、次のリソースで構成されています。
[root@localhost ~]# kubectl get secret,service,deployment,statefulset,pod -n wp
NAME TYPE DATA AGE
secret/default-token-nq5rs kubernetes.io/service-account-token 3 27m
secret/mysql-secret Opaque 2 27m
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/wordpress NodePort 10.43.157.40 <none> 8080:30001/TCP 5m19s
service/wp-mysql ClusterIP 10.43.132.223 <none> 3306/TCP 27m
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/wordpress 1/1 1 1 5m19s
NAME READY AGE
statefulset.apps/wp-mysql 1/1 27m
NAME READY STATUS RESTARTS AGE
pod/wordpress-66bc999449-qv97v 1/1 Running 0 5m19s
pod/wp-mysql-0 1/1 Running 0 27m
Visit Rainbond and select Import at the cluster. このページでは、名前空間を選択してリソースをインポートできますwp。プラットフォームは、ラベルに従ってリソースをグループ化します。
Rainbond は、リソース定義に従ってアプリケーションlabelを. たとえば、図の 2 つの異なるアプリケーションに一致する、またはapp.kubernetes.io/name:wp-mysql 配布されるリソース. 上記のリソースが使用できない場合、それらはグループ化されていないアプリケーションに一様に分割されます. アプリケーション モデルの高度なアプリケーションはアプリケーション全体を対象としているため、アプリケーションの分割は非常に重要です。そのため、インポートする前に慎重に計画し、適切なものを追加する必要があります。app:wordpresslabellabel
インポート プロセス中に、Rainbond は管理用に拡張モデルにさまざまなプロパティを割り当てます. 運用および保守操作のほとんどは非常に使いやすくなり、残りの部分は Kubernetes プロパティ ページによって管理されます.
インポートするwordpressと、Rainbond を使用してwp-mysql両方のアプリケーションを管理できます。
- ポート管理
wordpressインポートする前に、外部公開のNodePortタイプServiceますが、Rainbond 管理をインポートした後、ゲートウェイを使用して、独自のポート 80 を外部に公開できます。アクセス ポリシーを有効にするには、wordpressサービス。
一部のサービスでは、アクセス エントリは動的な指定をサポートしていないため、新しいアクセス エントリに適応するためにビジネス側でいくつかの変更が必要になります。Wordpressの場合、一般オプションのサイト アドレスを再定義する必要があります。
- ストレージ管理
私が導入したwordpressシステムはhostpath、すべてのコンポーネントにストレージのモードを使用しています. この構成は単純ですが、ドリフトPodする可能性のある大規模な Kubernetes 環境に. Rainbond をデプロイすると、使いやすい共有ストレージが提供され、複数の Pod 間でのデータ共有とホスト間での Pod の移行がサポートされます。元のホストパス ストレージは再定義できます。再定義されたストレージ パスは空になるため、忘れずに新しいパスと古いパスを見つけてデータ移行を実行してください。
実用的な意味
アプリケーション モデルを通じて、IT 技術者は、基盤となる複雑なツールの使用ではなく、ビジネス自体により多くの注意を払うことができます。最終的な効果は、運用コストと理解の難しさを単純化し、Kubernetes を実装しやすくすることです。