KubeVela の基本: 知っておくべきことすべて

KubeVela は、ハイブリッドクラウド環境でのアプリケーション配信をよりシンプルかつ高速にする、すぐに使用できる最新のアプリケーション配信および管理プラットフォームです。これは Open Application Model (OAM) の実装なので、まず OAM を理解する必要があります。

OAM の紹介

OAM (Open Application Model) は、Alibaba と Microsoft が共同でオープンソース化したクラウドネイティブアプリケーション仕様モデルです。 OAM の本質は、ソフトウェア設計における利益の分離の原則に基づいて、責任ある DevOps プロセスを高度に抽象化してカプセル化することです。これはアプリケーション中心の K8s API レイヤーです。このモデルの目的は、クラウドネイティブアプリケーションの標準を定義することです。

オーム

OAM の名前が示すように、これはオープンアプリケーションモデルです。

オープン: 基盤となるレイヤーに関係なく、異種プラットフォーム、コンテナランタイム、スケジューリングシステム、クラウドプロバイダー、ハードウェア構成などをサポートします。
アプリケーション: クラウドネイティブアプリケーション
モデル: 基盤となるプラットフォームに依存しない標準を定義します

OAM モデルが必要な理由は何ですか?

現在、アプリケーション管理には 2 つの主な課題があります。

アプリケーション開発の場合、Kubernetes の API は単純なアプリケーションには複雑すぎ、複雑なアプリケーションには使いにくいです。
アプリケーションの運用と保守において、Kubernetes のスケーラビリティを管理するのは困難です。 Kubernetes のネイティブ API はすべてのクラウドリソースをカバーしているわけではありません。

一般的に、主な課題は、Kubernetes に基づく真のアプリケーション管理プラットフォームを提供し、R&D と運用および保守がアプリケーション自体にのみ集中できるようにすることです。

たとえば、以下は典型的な K8s リソースリストファイルです。 YAML ファイルは簡素化されましたが、それでもまだかなり長いです。

k8s ヤム

上から下まで、大まかに 3 つの部分に分けることができます。

1 つは、スケーリングとローリングアップグレードに関連するパラメーターであり、これは通常、運用および保守担当者にとって重要なものです。
中央の部分は、イメージ、ポート、および起動パラメータに関連しています。この部分は開発者にとってより重要な部分です。
最後の部分は全く理解できないかもしれません。もちろん、ほとんどの場合、それを理解する必要はありません。一般的に言えば、これは K8s プラットフォームレイヤーの学生が注意を払う必要があるものです。

このような YAML ファイルを見ると、フィールドを内部にカプセル化して、公開する必要があるものだけを公開する必要があると考えるのは簡単です。現時点では、アプリケーション管理プラットフォームを開発し、ユーザーに約 5 つのフィールドのみを公開して、ユーザー向けの美しいフロントエンドインターフェイスを作成できます。これにより、ユーザーが K8s を理解するための精神的負担が大幅に軽減されることは明らかです。基礎となる実装では、テンプレートのような方法を使用して、これら 5 つのフィールドを完全な YAML ファイルにレンダリングします。

 image: quay.io/coreos/prometheus-operator:v0.34.0 args: - --logtostderr=true ports: - containerPort: 8080 name: http protocol: TCP envs: - name: INNER-KEY value: app volumes: - name: cache-volume emptyDir: {}

この方法は、単純なステートレスアプリケーションに非常に効果的であり、API を合理化することで K8s の敷居を大幅に下げることができます。しかし、大規模なビジネスが出現すると、多くの複雑なアプリケーションに遭遇することになり、その際に PaaS アプリケーションプラットフォームの能力が十分でないことが発覚します。たとえば、ZK マルチインスタンスマスター選出とマスター/スレーブ切り替えのロジックは、これらの 5 つのフィールドで記述するのは困難です。多数のフィールドをマスクするとインフラストラクチャ自体の機能が制限され、K8s は非常に強力で柔軟性が高いため、シンプルさのために K8s の強力な機能を放棄することはできません。

ミドルウェアエンジニアは、「Zookeeper を持っていますが、それに接続するにはどの K8s ワークロードを使用すればよいですか?」と尋ねました。もちろん、Operator を使わせようと思ったので、彼らは混乱し、「Operator とは何ですか?」と尋ねました。

次に、CRD、コントローラー、インフォーマー、リフレクター、インデクサーなどの関連する概念を丁寧に説明しました。もちろん、彼らはさらに混乱していましたし、もちろん、理論的には、彼らはそれらを理解する必要がありませんでした。ビジネス側はビジネスそのものにもっと注力するべきであり、もちろん私たちは彼らがこのコントローラーを書くのを手伝わなければなりません。このため、アプリケーション管理に対する R&D の要求に対応する統一モデルが必要です。

研究開発面の問題に加え、運用・保守面でも課題は数多くあります。

K8s の CRD オペレーターメカニズムは非常に柔軟かつ強力です。 CRD オペレーターを記述することで複雑なアプリケーションを実装できるだけでなく、グレースケールリリース、トラフィック管理、エラスティックスケーリングなどの運用および保守機能もオペレーターを通じて拡張できます。

たとえば、あるケースでは、HPA 範囲を定期的に設定するための CronHPA CRD が開発されました。しかし、アプリケーションの運用保守担当者は、CRD がネイティブ HPA と競合することを知らなかったため、当然ながら障害が発生しました。この痛い教訓は、私たちに事前チェックを行う必要があることを思い出させます。 K8s のメカニズムに精通しているので、各 Operator に Admission Webhook を追加することは容易に考えられます。この Admission Webhook は、アプリケーションにバインドされているすべての運用・保守機能とアプリケーション自体の動作モードを取得し、統一された検証を実行する必要があります。これらの運用・保守機能が 1 つの当事者によって提供されるのであれば問題ありません。しかし、2 社または 3 社によって拡張機能が提供される場合、情報を取得するための統一された方法がなくなります。

さらに深く考えてみると、これらの複雑な拡張機能を調整し管理するには、統一されたモデルが必要であることがわかります。

クラウドネイティブアプリケーションの主な特徴は、データベース、ネットワーク、負荷分散、キャッシュ、その他のリソースなどのクラウドリソースに依存することが多いことです。

Helm を使用してパッケージングするなど、アプリケーションを配信する場合、K8s ネイティブ API のみをターゲットにすることができ、RDS データベースも起動したい場合はさらに困難になります。データベース操作ページに移動せずに K8s API を通じて管理したい場合は、CRD を記述して定義し、Operator を通じて実際のクラウドリソースの API を呼び出す必要があります。

この成果物のセット全体は、実際にはアプリケーションの完全な説明であり、これを「アプリケーション定義」と呼びます。この定義方法では、すべての構成が最終的に 1 つの YAML ファイルに積み重ねられますが、これは前述のオールインワンの問題と同じです。さらに、これらのアプリケーション定義は最終的にはブラックボックスになります。該当するプロジェクト自体を除いて、他のシステムは基本的に再利用できません。

実際、多くの企業やチームも、独自のビジネスニーズに基づいて独自のアプリケーション仕様を定義しています。たとえば、Pinterest で定義されているアプリケーション仕様は次のとおりです。

PinterestCRD

アプリケーション定義は実際にはアプリケーションの配信/配布に不可欠な部分であるため、十分にオープンで再利用可能なアプリケーションモデルを定義できるかどうかを検討できます。

アプリケーション定義は、使いやすいだけでなく、柔軟性も必要であり、ブラックボックスであってはなりません。アプリケーション定義もオープンソースエコシステムと密接に統合される必要があります。エコシステムなしでのアプリケーション定義には将来性がなく、当然、継続的に反復して進化させることは困難になります。

これが、OAM を詳細に理解する必要がある理由です。！！

上で述べたさまざまな問題は、最終的には、K8s の All in One API がプラットフォームプロバイダー向けに設計されているという事実に起因します。下の図の左側に示すように、アプリケーション開発チームと運用保守チームが K8s チームと同じ API に直面することは許されません。

オールインワンAPI

適切なアプリケーションモデルには、ユーザーロールを区別し、操作機能と保守機能をモジュール形式でカプセル化する階層構造が必要です。上の図の右側に示すように、異なるロールで異なる API を使用できるようにします。

OAM モデルの定義

上記では、OAM モデルが必要な理由はわかりましたが、OAM モデルはどのように定義されるのでしょうか?

最新の API バージョン v0.3.0 (core.oam.dev/v1beta1) では、OAM は以下を定義します。

ComponentDefiniton: OAM の最も基本的な単位であるコンポーネントモデル。アプリケーション内の各マイクロサービスは、コンポーネントとして記述できます。実際には、単純なコンテナ化されたワークロード、Helm Chart、またはクラウドデータベースをコンポーネントとして定義できます。
WorkloadDefiniton: ワークロードは特定のコンポーネント定義の重要な特性であり、ユーザーがプラットフォームを検査して使用可能なワークロードタイプを理解できるようにプラットフォームによって提供されます。ワークロードタイプでは、エンドユーザーが新しいワークロードタイプを作成できないことに注意してください (プラットフォームプロバイダーのみ)。
TraitDefinition: コンポーネントワークロードインスタンスに追加された操作特性。これにより、オペレーターはコンポーネント構成に関する具体的な決定を下すことができます。たとえば、サイドカー特性は、WordPress Helm Chart ワークロードにサイドカーコンテナーを挿入します。機能とは、負荷分散戦略、ネットワーク入力ルーティング、サーキットブレーカー、レート制限、自動拡張戦略、アップグレード戦略など、単一のコンポーネントに適用可能な分散アプリケーションの任意の構成です。機能は運用担当者の焦点です。
アプリケーションスコープ: アプリケーションスコープは、さまざまな形式のアプリケーション境界と同じ動作のグループを提供することで、コンポーネントを論理アプリケーションにグループ化します。アプリケーションスコープは、コンポーネントを同じアプリケーションスコープタイプの複数のインスタンスに同時にデプロイできるかどうかを決定します。
アプリケーション: アプリケーションは、アプリケーションがデプロイされるときにインスタンス化されるコンポーネントのリストを定義します。

したがって、アプリケーションは、いくつかの操作特性を持つコンポーネントのセットで構成され、1 つ以上のアプリケーション境界に限定されます。

OAM モデル

特定のモデル定義仕様の詳細については、OAM 仕様ドキュメントを参照してください。ただし、現在の KubeVela 仕様は OAM 仕様とまったく同じではないことに注意してください。

KubeVelaの紹介

KubeVela は OAM 仕様の実装です (実際、OAM 仕様は KubeVela で使用される仕様よりも遅れています)。これは、ハイブリッドクラウド環境でのアプリケーション配信をよりシンプルかつ高速にする、すぐに使用できる最新のアプリケーション配信および管理プラットフォームです。 KubeVela を使用するソフトウェア開発チームは、クラウドネイティブ機能を使用してオンデマンドでアプリケーションを構築し、チーム規模の拡大やビジネスシナリオの変化に応じて機能を拡張し、アプリケーションを一度構築してどこでも実行することができます。

キューブベラ

コア機能

KubeVela には次のコア機能があります。

コードとしてのアプリケーションデプロイメント (Deployment as Code) では、アプリケーション配信の最上位レベルの抽象化として OAM を使用して、配信プロセス全体を完全に定義します。このアプローチにより、アプリケーション配信プロセス全体を宣言的に記述し、CI/CD および GitOps システムを自動的に統合し、CUE を通じて配信プロセスを簡単に拡張または書き換えることができます。
セキュリティ、コンプライアンス、監視可能性をすべて備えたエンタープライズレベルの統合を自然にサポートします。マルチクラスターの認証と承認をサポートし、K8s RBAC と統合します。コミュニティのプラグインセンターには、複数のユーザーシステム (LDAP など) の統合、マルチテナント権限制御、セキュリティ検証とスキャン、アプリケーションの監視、その他多くのエンタープライズレベルの機能を含む、すぐに使用できるプラットフォーム拡張機能も多数用意されています。
マルチクラウド、マルチクラスター、ハイブリッド環境を対象とした豊富なアプリケーション配信および管理機能は、カナリア、ブルーグリーン、マルチ環境の差別化構成など、さまざまなマルチクラスター/ハイブリッド環境の継続的配信戦略をネイティブにサポートします。クロス環境配信もサポートします。これらの配信戦略は、分散配信プロセスに十分な効率性とセキュリティの保証を提供します。
さまざまなエンタープライズシナリオのカスタマイズされたニーズを満たす軽量で拡張性の高いアーキテクチャ
KubeVela の最小のデプロイメントモードでは、数千のアプリケーションをデプロイするのに 1 つのポッド (0.5 コアと 1G メモリ) のみが必要です。マイクロカーネルと高度にスケーラブルなアーキテクチャにより、拡張とカスタマイズのニーズに簡単に対応でき、企業の内部許可システム、マイクロサービス、トラフィックガバナンス、構成管理、可観測性、その他のモジュールを接続できます。それだけでなく、コミュニティには、選択して使用できるプラグインマーケットが急速に成長しており、コミュニティの豊富な機能モジュールに貢献して再利用することができます。

関心の分離

関心の分離は KubeVela の中心的な概念です。それが KubeVela の設計哲学であり、KubeVela を他と異なるものにしているのです。 KubeVela ユーザーは当然 2 つの役割に分かれており、社内の 2 つのチーム (または個人) がそれぞれ担当します。

プラットフォームチーム<br>プラットフォームエンジニアで構成され、アプリケーションの展開環境を準備し、安定性と信頼性のあるインフラストラクチャ機能 (MySQL オペレーターなど) を維持し、インフラストラクチャ機能を KubeVela モジュール定義としてクラスターに登録する必要があります。彼らには広範なインフラストラクチャ経験が必要です。
エンドユーザー<br>エンドユーザーはビジネスアプリケーションの開発者です。プラットフォームを使用する場合、まずデプロイメント環境を選択し、次に機能モジュールを選択し、ビジネスパラメータを入力して、KubeVela アプリケーションに組み立てます。インフラストラクチャの詳細について心配する必要はありません。

関心の分離

コアコンセプト

KubeVela は OAM 仕様に準拠しており、Application オブジェクトを使用して、配信されるコンポーネント、関連する運用および保守機能、配信パイプライン、その他のコンテンツを含むマイクロサービスアプリケーションの完全な配信プロセスを宣言します。提供されるすべてのコンポーネント、運用および保守アクション、パイプラインの各ステップは、OAM 仕様に従って独立したプラグ可能なモジュールとして設計されており、ユーザーは独自のニーズに応じてそれらを組み合わせたりカスタマイズしたりできます。

基本的に、Application オブジェクトはエンドユーザーが知っておく必要がある唯一のオブジェクトであり、マイクロサービスアプリケーションのデプロイメントプランを表します。 OAM 仕様に従って、アプリケーション展開計画 (アプリケーション) は、コンポーネント (コンポーネント)、運用および保守特性 (特性)、展開ワークフロー (ワークフロー)、およびアプリケーション実行ポリシー (ポリシー) の 4 つの部分で構成されます。これらのコンポーネントは、プラットフォームビルダーによって管理されるプログラム可能なモジュールです。この抽象メソッドは、拡張性とカスタマイズ性に優れています。

成分
コンポーネントは、マイクロサービスアプリケーションを構成する基本単位です。アプリケーションには複数のコンポーネントを含めることができます。ベストプラクティスとしては、アプリケーションにはメインコンポーネント (コアビジネス) と補助コンポーネント (強く依存または排他的なミドルウェア、運用および保守コンポーネントなど) が含まれます。 KubeVela には、Helm Chart、コンテナイメージ、CUE モジュール、Terraform モジュールなど、複数のタイプのコンポーネント配信に対するサポートが組み込まれています。また、プラットフォーム管理者は、CUE 言語の形式で他のタイプのコンポーネントをカスタマイズすることもできます。
運用特性（特性）
運用および保守機能は、レプリカ数の調整、データの永続性、ゲートウェイポリシーの設定、DNS 解決の自動設定など、いつでも展開するコンポーネントにバインドできるモジュール式のプラグ可能な運用および保守機能です。ユーザーは、コミュニティから成熟した機能を取得するか、独自の機能を定義できます。
ワークフロー
ワークフローは複数のステップで構成されており、ユーザーは特定の環境でアプリケーションの配信プロセスをカスタマイズできます。一般的なワークフロー手順には、手動レビュー、データ配信、マルチクラスター公開、通知などが含まれます。
ポリシーの適用
アプリケーションポリシーは、マルチクラスター展開の差別化された構成、セキュリティグループポリシー、ファイアウォールルールなど、指定されたアプリケーションの配信に関するポリシーを定義する役割を担います。

全体的な定義は次のとおりです。

 apiVersion: core.oam.dev/v1beta1 kind: Application metadata: name: <应用名称> spec: components: - name: <组件名称1> type: <组件类型1> properties: <组件参数> traits: - type: <运维特征类型1> properties: <运维特征类型> - type: <运维特征类型2> properties: <运维特征类型> - name: <组件名称2> type: <组件类型2> properties: <组件参数> policies: - name: <应用策略名称> type: <应用策略类型> properties: <应用策略参数> workflow: - name: <工作流节点名称> type: <工作流节点类型> properties: <工作流节点参数>

配信されるコンポーネントが Helm Chart であるかクラウドデータベースであるか、またターゲットインフラストラクチャが Kubernetes クラスターであるかクラウドプラットフォームであるかに関係なく、KubeVela は、Application などの統合された上位レベルの配信記述ファイルを通じてユーザーと対話し、複雑な基盤インフラストラクチャの詳細を漏らすことなく、ユーザーがアプリケーションの開発と配信に完全に集中できるようにします。

キューブベラ

実際の使用では、ユーザーは上記のアプリケーションオブジェクトを使用して、プリセットコンポーネント、運用および保守機能、アプリケーションポリシー、ワークフローノードモジュールを参照し、これらのモジュールによって公開されるユーザーパラメーターを入力して、アプリケーション配信のモデリングを完了します。

もちろん、上記のタイプの背後には、特定の機能を提供するためのモジュール定義と呼ばれるプログラム可能なモジュールのセットがあります。 KubeVela は、K8s API に基づいてインフラストラクチャ定義の抽象化を定義し、さまざまな機能を組み合わせる接着剤のような役割を果たします。

定義された OAM モジュールと基盤となる K8s CRD コントローラーを組み合わせることで、KubeVela アドオンプラグインを形成できます。コミュニティにはすでに、完全かつ拡大を続けるプラグインマーケットがあります。たとえば、terraform プラグインはクラウドリソースの供給を提供し、fluxcd プラグインは GitOps 機能などを提供します。プラグインを検出して配布するためのプラグインリポジトリを提供できる Helm と同様に、ニーズに応じてプラグインを独自に開発できます。

KubeVela アーキテクチャ

KubeVela の全体的なアーキテクチャは次のとおりです。

KubeVela アーキテクチャ

KubeVela は、アプリケーションの配信および管理のコントロールプレーンです。これは、Kubernetes クラスターやクラウドプラットフォームなどのインフラストラクチャ上に構築され、OAM を使用して、コンポーネント、クラウドサービス、運用および保守機能、配信ワークフローを統一的にオーケストレーションして配信します。 KubeVela の設計はインフラストラクチャ自体から完全に分離されており、ハイブリッドクラウド/マルチクラウド/マルチクラスターインフラストラクチャ向けのアプリケーションの提供と管理を容易に行うことができます。

あらゆる CI パイプラインや GitOps ツールとシームレスに統合できるように、KubeVela の API は宣言型で完全にアプリケーション中心になるよう設計されており、次のような特徴があります。

ユーザーがアプリケーション配信計画を定義するのに役立つアプリケーションオブジェクト
プラットフォーム管理者が CUE 言語を通じてプラットフォーム機能と ComponentDefinition や TraitDefinition などの抽象 X-Definition オブジェクトを定義するのに役立ちます。

具体的な実装に関しては、KubeVela は実行に独立した Kubernetes クラスターに依存しています。具体的には、KubeVela は主に以下の部分で構成されています。

KubeVela コアコントローラー: システム全体のコア制御ロジックを提供し、アプリケーションとワークフローのオーケストレーション、リビジョンスナップショット、ガベージコレクションなどの基本ロジックを完了します。
クラスターゲートウェイコントローラー: 統合されたマルチクラスターアクセスインターフェイスと操作を提供します。
プラグインシステム: CRD コントローラーや関連モジュール定義など、KubeVela の拡張機能を登録および管理します。たとえば、よく使用されるプラグインをいくつか紹介します。

VelaUX プラグインは、KubeVela の Web UI です。さらに、そのアーキテクチャは、フル機能の「アプリケーション配信プラットフォーム」に似ており、特定の API でビジネスロジックを結合し、k8s に精通していないビジネス開発者にすぐに使用できるプラットフォームエクスペリエンスを提供します。
ワークフロープラグインは、複数のアプリケーションやその他の操作をデプロイするための統合パイプラインとして実行できるスタンドアロンのワークフローエンジンです。従来の Pipeline と比較すると、各ステップでコンテナ (またはポッド) を実行する代わりに、主に CUE を使用して IaC ベースの API を駆動します。 KubeVela コアコントローラーのアプリケーションワークフローと同じメカニズムを使用します。
Vela Prism プラグインは、Kubernetes Aggregated API メカニズムに基づいて構築された、KubeVela 用の拡張 API サーバーです。 Grafana ダッシュボード作成などのサードパーティサービス API を Kubernetes API にマッピングできるため、ユーザーは IaC を通じてサードパーティリソースを Kubernetes ネイティブリソースとして簡単に管理できます。
Terraform プラグインを使用すると、ユーザーは Terraform を使用して Kubernetes カスタムリソースを通じてクラウドリソースを管理できます。
さらに、KubeVela には成長を続けるプラグインマーケットプレイスがあり、ArgoCD、FluxCD、Backstage、OpenKruise、Dapr、Crossplane、Terraform、OpenYurt など、すでに 50 を超える統合用コミュニティプラグインが含まれています。

まだ Kubernetes クラスターをお持ちでない場合は、k3s と k3d 上に構築された VelaD ツールを使用すると、これらすべてをワンクリックで起動できます。 KubeVela を Kubernetes コントロールプレーンと統合し、開発/テスト環境の構築に非常に役立ちます。

もう一つの非常に重要な点は KubeVela はプログラム可能です。現実の世界では、アプリケーションの配信は複雑なプロセスになることがよくあります。比較的一般的な配信プロセスであっても、シナリオ、環境、ユーザー、さらにはチームによって大きく異なる場合があります。そのため、KubeVela は初日から配信モデルを実装するためのプログラム可能なアプローチを採用しており、これにより、KubeVela はこれまでにない柔軟性でアプリケーション配信シナリオに適応できます。

KubeVelaのインストール

K8s 環境がない場合は、VelaD を使用して KubeVela を個別にインストールすることもできます。これは、KubeVela の最小限のインストールと VelaUX を使用するためのすべての依存関係を実行可能ファイルにパッケージ化するコマンドラインツールです。 VelaD は、Kubernetes クラスターの自動管理のために K3s と k3d を統合します。

もちろん、既存の K8s クラスターに基づいて KubeVela をインストールすることを選択します。クラスターバージョン >= v1.19 && <= v1.26 が必要です。

まず、KubeVela コマンドラインツールをインストールする必要があります。 KubeVela CLI は、一般的なクラスターおよびアプリケーション管理機能を提供します。次のコマンドを使用して直接インストールできます。

 curl -fsSl https://kubevela.io/script/install.sh | bash

インストールが完了したら、vela version コマンドを使用してバージョン情報を表示できます。

 $ vela version CLI Version: 1.9.6 Core Version: GitRevision: git-9c57c098 GolangVersion: go1.19.12

次に、次のコマンドを使用して KubeVela コントロールプレーンをインストールします。

 vela install

インストールが完了すると、vela-system 名前空間が作成され、対応する Pod リストは次のようになります。

 $ kubectl get pods -n vela-system NAME READY STATUS RESTARTS AGE kubevela-cluster-gateway-b689d74dc-mtzrh 1/1 Running 0 134m kubevela-vela-core-85fd59d846-49q22 1/1 Running 0 134m kubevela-vela-core-admission-patch-8x9lv 0/1 Completed 0 131m kubevela-vela-core-cluster-gateway-tls-secret-patch-xjcw9 0/1 Completed 0 129m

もちろん、Helm の使用に慣れている場合は、次の Helm コマンドを使用して VelaCore のインストールとアップグレードを完了することもできます。

 helm repo add kubevela https://charts.kubevela.net/core helm repo update helm upgrade --install --create-namespace -n vela-system kubevela kubevela/vela-core --wait

上記では、KubeVela コントロールプレーンのみがインストールされます。通常は、KubeVela の UI コンソールである VelaUX もインストールします。ブラウザからアクセスできます。もちろん、インストールしないことも選択できます。これはオプションです。

インストールも非常に簡単です。 velaux プラグインを有効にするには、次のコマンドを実行します。

 vela addon enable velaux

VelaUX には認証アクセスが必要です。デフォルトのユーザー名は admin で、デフォルトのパスワードは VelaUX12345 です。初回ログイン後は必ず新しいパスワードをリセットし、安全に保管してください。

また、デフォルトでは、VelaUX はポートを公開しません。ポート転送を使用すると、プロキシ方式でローカルポートを介して VelaUX コンソールにアクセスできます。

 vela port-forward addon-velaux -n vela-system

選択 > ローカル |ヴェロー |ポート転送を有効にするにはvelauxを使用します。

VelaUX コンソールプラグインは、Kubernetes サービスと同じ 3 つのサービスアクセス方法 (ClusterIP、NodePort、LoadBalancer) をサポートしています。デフォルトのサービスアクセス方法は ClusterIP です。 VelaUX コンソールのアクセス方法は、次の方法で変更できます。

 vela addon enable velaux serviceType=LoadBalancer # 或者vela addon enable velaux serviceType=NodePort

サービスアクセスメソッドを LoadBalancer または NodePort として指定すると、vela status を実行してアクセスアドレスを取得できます。

 vela status addon-velaux -n vela-system --endpoint

期待される出力は次のとおりです。

 +----------------------------+----------------------+ | REF(KIND/NAMESPACE/NAME) | ENDPOINT | +----------------------------+----------------------+ | Service/vela-system/velaux | http://<IP address> | +----------------------------+----------------------+

クラスター内に利用可能なイングレスとドメイン名がある場合は、次のようにしてデプロイ中に VelaUX のドメイン名を指定できます。

 $ vela addon enable velaux domain=vela.k8s.local Addon velaux enabled successfully. Please access addon-velaux from the following endpoints: +---------+---------------+-----------------------------------+--------------------------------+-------+ | CLUSTER | COMPONENT | REF(KIND/NAMESPACE/NAME) | ENDPOINT | INNER | +---------+---------------+-----------------------------------+--------------------------------+-------+ | local | velaux-server | Service/vela-system/velaux-server | velaux-server.vela-system:8000 | true | | local | velaux-server | Ingress/vela-system/velaux-server | http://vela.k8s.local | false | +---------+---------------+-----------------------------------+--------------------------------+-------+ To open the dashboard directly by port-forward: vela port-forward -n vela-system addon-velaux 8000:8000 Please refer to https://kubevela.io/docs/reference/addons/velaux for more VelaUX addon installation and visiting method.

さらに、VelaUX はデータベースとして Kubernetes と MongoDB をサポートしています。デフォルトのデータベースは Kubernetes です。実稼働環境のエクスペリエンスを強化するために、MongoDB を使用することを強くお勧めします。

 vela addon enable velaux dbType=mongodb dbURL=mongodb://<MONGODB_USER>:<MONGODB_PASSWORD>@<MONGODB_URL>

ベラUX

これで、http://vela.k8s.local から VelaUX コンソールにアクセスできるようになりました。初めてアクセスするときに、管理者アカウント情報を設定できます。

ベラウイ

VelaUX は、企業がすぐに使用できるクラウドネイティブのアプリケーション配信および管理プラットフォームである KubeVela のプラグインです。同時に、企業での使用に必要な概念もいくつか追加されています。

ベラUX

プロジェクト

KubeVela プラットフォーム上で人員とリソースを編成するビジネスキャリアとして、プロジェクトはメンバー、権限、アプリケーション、割り当て環境を設定できます。外部コードライブラリとアーティファクトライブラリをプロジェクトディメンションに統合して、完全な CI/CD パイプラインを実現します。外部の需要管理プラットフォームを統合してプロジェクトの需要管理を提示します。マイクロサービスガバナンスを統合して、複数環境のビジネス共同デバッグと統合ガバナンス機能を提供します。このプロジェクトは、ビジネスレベルのリソース分離機能を提供します。

デフォルトでは、VelaUX は default という名前のプロジェクトを作成します。プロジェクト管理でさらに多くのプロジェクトを作成できます。

プロジェクト

環境

環境とは、通常の意味での開発、テスト、および運用環境のビジネス記述を指し、複数の配信ターゲットを含めることができます。環境は、上位層アプリケーションと基盤となるインフラストラクチャ間の対応関係を調整します。異なる環境は、管理および制御クラスターの異なる Kubernetes 名前空間に対応します。同じ環境内のアプリケーションのみが内部アクセスおよびリソース共有機能を持つことができます。

また、デフォルトでは、VelaUX は default という名前の環境を作成します。環境管理でさらに多くの環境を作成できます。

環境

アプリケーションはリリース時に複数の環境にバインドすることができ、環境ごとに環境レベルのデプロイメントの違いを設定できます。

配送先

配信ターゲットは、Kubernetes クラスターまたはクラウドのリージョン (Region) とプライベートネットワーク (VPC) に対応して、アプリケーションの関連リソースが実際にデプロイされる物理スペースを表すために使用されます。一般的なアプリケーションの場合、コンポーネントレンダリングによって生成されたリソースは、配信ターゲットによって指定された Kubernetes クラスター (指定されたクラスターの名前空間に正確に一致する場合があります) に作成されます。クラウドサービスの場合、リソースが作成される際、配信先に指定されたクラウドベンダーのパラメータに従って、対応するリージョンとプライベートネットワークにリソースが作成され、生成されたクラウドリソース情報は、配信先に指定されたKubernetesクラスターに配信されます。単一の環境を複数の配信ターゲットに関連付けることができるため、その環境ではマルチクラスター配信が必要になります。 1 つの配信ターゲットは 1 つの環境にのみ対応します。

配送先

応用

アプリケーションは、マイクロサービスビジネスユニットを定義する製品 (バイナリ、Docker イメージ、Helm Chart など) またはクラウドサービスの配信と管理の要件です。コンポーネント、運用および保守機能、ワークフロー、アプリケーション戦略で構成されます。アプリケーションライフサイクル操作には次のものが含まれます。

作成する アプリケーションはメタデータを作成しますが、実際にリソースを展開したり実行したりすることはありません。
展開する 指定されたワークフローを実行し、特定の環境でアプリケーションをインスタンス化することを指します。
リサイクル 特定の環境にデプロイされたアプリケーションのインスタンスを削除し、それが占有しているリソースを回収します。
アプリケーションを削除すると、そのメタデータも削除されます。ただし、アプリケーションインスタンスが削除される前に完全にリサイクルされている必要があります。

VelaUX アプリケーションのその他の概念は、KubeVela コントローラーの概念とまったく同じです。

最初のKubeVelaアプリケーション

KubeVela をインストールしたので、これを使用して最初のアプリケーションをデプロイし始めることができます。

以下では、ステートレスサービスコンポーネントと運用および保守特性を含む単純な OAM アプリケーションを定義し、3 つのデプロイメント戦略とワークフロー手順を定義します。このアプリケーションの説明は、サービスを 2 つのターゲット名前空間にデプロイし、最初のターゲットがデプロイされた後、手動レビューを待ってから 2 番目のターゲットにデプロイし、2 つのインスタンスを 2 番目のターゲットにデプロイすることを意味します。

 # first-vela-app.yaml apiVersion: core.oam.dev/v1beta1 kind: Application metadata: name: first-vela-app spec: components: - name: express-server type: webservice # webservice 是一个内置的组件类型properties: # 组件参数image: oamdev/hello-world ports: - port: 8000 expose: true traits: # 组件运维特征- type: scaler properties: replicas: 1 policies: - name: target-default type: topology # topology 是一个内置的应用策略类型，它可以将应用部署到多个目标properties: clusters: ["local"] # local 集群即Kubevela 所在的集群namespace: "default" - name: target-prod type: topology properties: clusters: ["local"] namespace: "prod" # 此命名空间需要在应用部署前完成创建- name: deploy-ha type: override # override 是一个内置的应用策略类型，它可以覆盖组件的参数properties: components: - type: webservice traits: - type: scaler properties: replicas: 2 workflow: # 应用工作流steps: - name: deploy2default type: deploy # deploy 是一个内置的工作流类型，它可以将应用部署到指定的目标properties: policies: ["target-default"] - name: manual-approval type: suspend # suspend 是一个内置的工作流类型，它可以暂停工作流的执行- name: deploy2prod type: deploy properties: policies: ["target-prod", "deploy-ha"]

最初にPROD名空間を作成するには、VELA env Initコマンドを使用するか、kubectl create nsコマンドを直接使用できます。

 # 此命令用于在管控集群创建命名空间vela env init prod --namespace prod

次に、最初のKubevelaアプリケーションを開始できます。

 $ vela up -f first-vela-app.yaml Applying an application in vela K8s object format... ✅ App has been deployed 🚀🚀🚀 Port forward: vela port-forward first-vela-app -n prod SSH: vela exec first-vela-app -n prod Logging: vela logs first-vela-app -n prod App status: vela status first-vela-app -n prod Endpoint: vela status first-vela-app -n prod --endpoint Application prod/first-vela-app applied.

Vela Upコマンドは、説明に従って上記のアプリケーションオブジェクトを対応するK8Sリソースオブジェクトに翻訳およびレンダリングします。展開が完了したら、Velaの関連コマンドを使用して、アプリケーションの関連情報を理解できます。

まず、VELAステータスコマンドを使用して、アプリケーションの現在のステータスを表示できます。上記のアプリケーションで定義されているワークフローは、最初にアプリケーションをローカルクラスターのデフォルトの名前空間に展開し、次に2番目のステップに入るため、サスペンドタイプのワークフローです。したがって、通常の状況では、アプリケーションは、最初のターゲット展開を完了した後、一時停止状態（左側のワークフローシング状態）に入ります。

 $ vela status first-vela-app -n prod About: Name: first-vela-app Namespace: prod Created at: 2023-10-10 16:50:17 +0800 CST Status: workflowSuspending Workflow: mode: StepByStep-DAG finished: false Suspend: true Terminated: false Steps - id: kkotnerd76 name: deploy2default type: deploy phase: succeeded - id: axtmf24jcx name: manual-approval type: suspend phase: suspending message: Suspended by field suspend Services: - Name: express-server Cluster: local Namespace: default Type: webservice Healthy Ready:1/1 Traits: ✅ scaler

ワークフローを継続するには、2番目のターゲット展開のアプリケーションを承認するために、手動レビュー（左に示されている2番目のステップ）が必要です。次のコマンドを使用するだけです。

 vela workflow resume first-vela-app

もちろん、Velaxuxコンソールでアプリケーションのステータスを確認することもできます。また、コンソールで直接手動レビュー操作を実行することもできます。

Velaxuxの承認

承認後、Target-ProdおよびDeploy-HA戦略を適用するために、3番目のステップDeploy2Prodが実行されます。

上記のワークフロー全体の後、アプリケーションは最終的にデフォルトの名前空間の下にポッドを作成し、2つのレプリカポッドがProd Namesスペースの下に作成されます。

 $ kubectl get pods -n prod NAME READY STATUS RESTARTS AGE express-server-5447567596-jcpnh 1/1 Running 0 72s express-server-5447567596-lgqdz 1/1 Running 0 72s $ kubectl get pods NAME READY STATUS RESTARTS AGE express-server-5447567596-clbgb 1/1 Running 0 7m36s

また、Velauxコンソールでアプリケーションステータスを確認することもできます。

Velauxアプリケーション

これにより、最初のKubevelaアプリケーションの展開プロセスが完了します。

<<: クラウドゲートウェイに基づくディープパケットインスペクション技術についての簡単な説明

>>: フォレスターが2023年のクラウドコンピューティングのトップ10トレンドを発表