Deploy StarRocks with Operator

Operatorを使用してStarRocksをデプロイする

このトピックでは、StarRocks Operatorを使用して、Kubernetesクラスタ上にStarRocksクラスタを自動化してデプロイおよび管理する方法について紹介します。

動作原理

開始する前に

Kubernetesクラスタを作成する

Amazon Elastic Kubernetes Service（EKS）やGoogle Kubernetes Engine（GKE）などのクラウド管理型のKubernetesサービス、またはセルフマネージドのKubernetesクラスタを使用することができます。

Amazon EKSクラスタの作成
1. 環境に次のコマンドラインツールがインストールされていることを確認します:
  1. AWS CLI(コマンドラインインターフェース)のインストールと設定を行います。
  2. EKSクラスタコマンドラインツールであるeksctlをインストールします。
  3. Kubernetesクラスタのコマンドラインツールであるkubectlをインストールします。
2. EKSクラスタを作成するには、以下のいずれかの方法を使用します:
  1. eksctlを使用して素早くEKSクラスタを作成する。
  2. AWSコンソールおよびAWS CLIを使用してEKSクラスタを手動で作成する。
GKEクラスタの作成GKEクラスタを作成する前に、前提条件をすべて完了していることを確認してください。次に、GKEクラスタを作成するための手順に従います。
セルフマネージドのKubernetesクラスタの作成セルフマネージド型のKubernetesクラスタを作成するには、kubeadmを使用したクラスタのブートストラップについての手順に従います。最小限の手順で単一ノードのプライベートKubernetesクラスタを作成する場合は、MinikubeとDocker Desktopを使用することができます。

StarRocks Operatorのデプロイ

カスタムリソース StarRocksCluster を追加します。

kubectl apply -f https://raw.githubusercontent.com/StarRocks/starrocks-kubernetes-operator/main/deploy/starrocks.com_starrocksclusters.yaml

StarRocks Operatorをデプロイします。デフォルトの設定ファイルまたはカスタムの設定ファイルを使用して、StarRocks Operatorをデプロイすることができます。
1. デフォルトの設定ファイルを使用して、StarRocks Operatorをデプロイします。
```
kubectl apply -f https://raw.githubusercontent.com/StarRocks/starrocks-kubernetes-operator/main/deploy/operator.yaml
```
  StarRocks Operatorは、名前空間starrocksにデプロイされ、すべてのネームスペースのStarRocksクラスタを管理します。
2. カスタムの設定ファイルを使用して、StarRocks Operatorをデプロイします。
  - StarRocks Operatorをデプロイするために使用される operator.yaml という名前の設定ファイルをダウンロードします。
    curl -O https://raw.githubusercontent.com/StarRocks/starrocks-kubernetes-operator/main/deploy/operator.yaml
  - 設定ファイル operator.yaml を必要に応じて編集します。
  - StarRocks Operatorをデプロイします。
    kubectl apply -f operator.yaml

StarRocks Operatorの実行状態を確認します。Podが Running の状態であり、ポッド内のすべてのコンテナが READY の状態にある場合、StarRocks Operatorは正常に実行されています。

$ kubectl -n starrocks get pods
NAME                                  READY   STATUS    RESTARTS   AGE
starrocks-controller-65bb8679-jkbtg   1/1     Running   0          5m6s

注意

StarRocks Operatorの存在するネームスペースをカスタマイズした場合は、starrocks をカスタマイズされたネームスペース名に置き換える必要があります。

StarRocksクラスタのデプロイ

StarRocksクラスタ（カスタムリソース StarRocks Cluster を使用してインスタンス化されたオブジェクト）をデプロイするために、StarRocksが提供するサンプルの設定ファイルを直接使用することができます。たとえば、starrocks-fe-and-be.yamlを使用して、3つのFEノードと3つのBEノードを含むStarRocksクラスタをデプロイすることができます。

kubectl apply -f https://raw.githubusercontent.com/StarRocks/starrocks-kubernetes-operator/main/examples/starrocks/starrocks-fe-and-be.yaml

以下の表には、starrocks-fe-and-be.yamlファイルのいくつかの重要なフィールドについて説明します。

フィールド	説明
Kind	オブジェクトのリソースタイプ。値は `StarRocksCluster`である必要があります。
Metadata	メタデータで、次のサブフィールドがネストされています: `name`: オブジェクトの名前。各オブジェクト名は、同じリソースタイプのオブジェクトを一意に識別します。 `namespace`: オブジェクトが所属する名前空間です。
Spec	オブジェクトの期待するステータスです。有効な値は `starRocksFeSpec`、`starRocksBeSpec`、および `starRocksCnSpec`です。

フィールド

説明

Kind

オブジェクトのリソースタイプ。値は StarRocksClusterである必要があります。

Metadata

メタデータで、次のサブフィールドがネストされています:

name: オブジェクトの名前。各オブジェクト名は、同じリソースタイプのオブジェクトを一意に識別します。
namespace: オブジェクトが所属する名前空間です。

Spec

オブジェクトの期待するステータスです。有効な値は starRocksFeSpec、starRocksBeSpec、および starRocksCnSpecです。

また、変更した設定ファイルを使用してStarRocksクラスタをデプロイすることもできます。サポートされるフィールドや詳細な説明については、api.mdを参照してください。

StarRocksクラスタのデプロイには時間がかかります。この間、コマンド kubectl -n starrocks get pods を使用してStarRocksクラスタの起動状態を確認することができます。すべてのポッドが Running の状態であり、ポッド内のすべてのコンテナが READY の状態にあれば、StarRocksクラスタは正常に実行されています。

注意

StarRocksクラスタが存在するネームスペースをカスタマイズした場合は、starrocks をカスタマイズされたネームスペース名に置き換える必要があります。

$ kubectl -n starrocks get pods
NAME                                  READY   STATUS    RESTARTS   AGE
starrocks-controller-65bb8679-jkbtg   1/1     Running   0          22h
starrockscluster-sample-be-0          1/1     Running   0          23h
starrockscluster-sample-be-1          1/1     Running   0          23h
starrockscluster-sample-be-2          1/1     Running   0          22h
starrockscluster-sample-fe-0          1/1     Running   0          21h
starrockscluster-sample-fe-1          1/1     Running   0          21h
starrockscluster-sample-fe-2          1/1     Running   0          22h

注意

長時間経ってもいくつかのポッドが起動しない場合は、kubectl logs -n starrocks <pod_name> コマンドを使用してログ情報を表示したり、kubectl -n starrocks describe pod <pod_name> コマンドを使用してイベント情報を表示したりして、問題の原因を特定できます。

StarRocksクラスタの管理

StarRocksクラスタへのアクセス

StarRocksクラスタのコンポーネントは、FEサービスなどの関連するサービスを介してアクセスできます。Serviceの詳細およびアクセスアドレスの詳細な説明については、api.mdおよびServicesを参照してください。

注意

デフォルトでは、FEサービスのみがデプロイされます。BEサービスとCNサービスをデプロイする場合は、StarRocksクラスタの設定ファイルで starRocksBeSpec および starRocksCnSpec を設定する必要があります。

サービスの名前はデフォルトで <クラスタ名>-<コンポーネント名>-service となります（たとえば、 starrockscluster-sample-fe-service）。各コンポーネントのspecで明示的にサービス名を指定することもできます。

Kubernetesクラスタ内からのStarRocksクラスタへのアクセス

Kubernetesクラスタ内部からは、FEサービスのClusterIPを介してStarRocksクラスタにアクセスできます。

FEサービスの内部仮想IPアドレス CLUSTER-IP とポート PORT(S) を取得します。

$ kubectl -n starrocks get svc 
NAME                                 TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)                               AGE
be-domain-search                     ClusterIP   None             <none>        9050/TCP                              23m
fe-domain-search                     ClusterIP   None             <none>        9030/TCP                              25m
starrockscluster-sample-fe-service   ClusterIP   10.100.162.xxx   <none>        8030/TCP,9020/TCP,9030/TCP,9010/TCP   25m

Kubernetesクラスタ内からMySQLクライアントを使用してStarRocksクラスタにアクセスします。
```
mysql -h 10.100.162.xxx -P 9030 -uroot
```

Kubernetesクラスタ外からのStarRocksクラスタへのアクセス

Kubernetesクラスタの外部からは、FEサービスのLoadBalancerまたはNodePortを介してStarRocksクラスタにアクセスできます。このトピックではLoadBalancerを使用して説明します。

コマンド kubectl -n starrocks edit src starrockscluster-sample を実行して、StarRocksクラスタの設定ファイルを更新し、starRocksFeSpec のServiceタイプを LoadBalancer に変更します。

starRocksFeSpec:
  image: starrocks/fe-ubuntu:3.0-latest
  replicas: 3
  requests:
    cpu: 4
    memory: 16Gi
  service:            
    type: LoadBalancer # LoadBalancerに指定します

外部に公開するFEサービスのIPアドレス EXTERNAL-IP とポート PORT(S) を取得します。

$ kubectl -n starrocks get svc
NAME                                 TYPE           CLUSTER-IP       EXTERNAL-IP                                                              PORT(S)                                                       AGE
be-domain-search                     ClusterIP      None             <none>                                                                   9050/TCP                                                      127m
fe-domain-search                     ClusterIP      None             <none>                                                                   9030/TCP                                                      129m
starrockscluster-sample-fe-service   LoadBalancer   10.100.162.xxx   a7509284bf3784983a596c6eec7fc212-618xxxxxx.us-west-2.elb.amazonaws.com   8030:30629/TCP,9020:32544/TCP,9030:32244/TCP,9010:32024/TCP   129m               ClusterIP      None            <none>                                                                   9030/TCP                                                      23h

ホストマシンにログインして、MySQLクライアントを使用してStarRocksクラスタにアクセスします。
```
mysql -h a7509284bf3784983a596c6eec7fc212-618xxxxxx.us-west-2.elb.amazonaws.com -P9030 -uroot
```

StarRocksクラスタのアップグレード

BEノードのアップグレード

次のコマンドを実行して、新しいBEイメージファイル（例：starrocks/be-ubuntu:latest）を指定します。

kubectl -n starrocks patch starrockscluster starrockscluster-sample --type='merge' -p '{"spec":{"starRocksBeSpec":{"image":"starrocks/be-ubuntu:latest"}}}'

FEノードのアップグレード

次のコマンドを実行して、新しいFEイメージファイル（例：starrocks/fe-ubuntu:latest）を指定します。

kubectl -n starrocks patch starrockscluster starrockscluster-sample --type='merge' -p '{"spec":{"starRocksFeSpec":{"image":"starrocks/fe-ubuntu:latest"}}}'

アップグレードプロセスには時間がかかります。kubectl -n starrocks get pods コマンドを実行してアップグレードの進行状況を確認することができます。

StarRocksクラスタのスケール

このトピックでは、BEクラスタとFEクラスタのスケーリングアウトを例として説明します。

BEクラスタのスケールアウト

次のコマンドを実行して、BEクラスタを9つのノードにスケーリングアウトします。

kubectl -n starrocks patch starrockscluster starrockscluster-sample --type='merge' -p '{"spec":{"starRocksBeSpec":{"replicas":9}}}'

FEクラスタのスケールアウト

次のコマンドを実行して、FEクラスタを4つのノードにスケーリングアウトします。

kubectl -n starrocks patch starrockscluster starrockscluster-sample --type='merge' -p '{"spec":{"starRocksFeSpec":{"replicas":4}}}'

スケーリングプロセスには時間がかかります。kubectl -n starrocks get pods コマンドを使用してスケーリングの進行状況を確認することができます。

CNクラスタの自動スケーリング

コマンド kubectl -n starrocks edit src starrockscluster-sample を実行して、CNクラスタの自動スケーリングポリシーを設定します。CNのリソースメトリクスとして、平均CPU使用率、平均メモリ使用量、エラスティックスケーリングの閾値、エラスティックスケーリングの上限、エラスティックスケーリングの下限を指定することができます。エラスティックスケーリングの上限と下限は、エラスティックスケーリングに許可されるCNの最大数と最小数を指定します。

注意

CNクラスタの自動スケーリングポリシーが設定されている場合、StarRocksクラスタの設定ファイルの starRocksCnSpec の replicas フィールドを削除する必要があります。

Kubernetesはまた、ビジネスシナリオに応じてスケーリング動作をカスタマイズするためのbehaviorをサポートしており、迅速なスケーリング、ゆっくりしたスケーリング、またはスケーリングを無効にすることが可能です。自動スケーリングポリシーの詳細については、Horizontal Pod Scalingを参照してください。

自動スケーリングポリシーの設定例として、StarRocksが提供するテンプレートを以下に示します。

  starRocksCnSpec:
    image: starrocks/cn-ubuntu:latest
    limits:
      cpu: 16
      memory: 64Gi
    requests:
      cpu: 16
      memory: 64Gi
    autoScalingPolicy: # CNクラスタの自動スケーリングポリシー
      maxReplicas: 10 # CNの最大数は10に設定します。
      minReplicas: 1 # CNの最小数は1に設定します。
      # オペレータは、次のフィールドに基づいてHPAリソースを作成します。
      # 詳細な情報については、https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/を参照してください。
      hpaPolicy:
        metrics: # リソースメトリクス
          - type: Resource
            resource:
              name: memory  # CNの平均メモリ使用量をリソースメトリクスとして指定します。
              target:
                # エラスティックスケーリングの閾値は60%です。
                # CNの平均メモリ使用率が60%を超えると、CNの数が増えてスケーリングアウトします。
                # CNの平均メモリ使用率が60%未満の場合は、CNの数が減ってスケーリングインします。
                averageUtilization: 60
                type: Utilization
          - type: Resource
            resource:
              name: cpu # CNの平均CPU使用率をリソースメトリクスとして指定します。
              target:
                # エラスティックスケーリングの閾値は60%です。
                # CNの平均CPU使用率が60%を超えると、CNの数が増えてスケーリングアウトします。
                # CNの平均CPU使用率が60%未満の場合は、CNの数が減ってスケーリングインします。
                averageUtilization: 60
                type: Utilization
        behavior: # ビジネスシナリオに応じたスケーリング動作をカスタマイズします。迅速なスケーリング、ゆっくりしたスケーリング、またはスケーリングを無効にすることが可能です。
          scaleUp:
            policies:
              - type: Pods
                value: 1
                periodSeconds: 10
          scaleDown:
            selectPolicy: Disabled

次の表には、いくつかの重要なフィールドについて説明します。

エラスティックスケーリングの上限と下限。

maxReplicas: 10 # CNの最大数を10と設定します。
minReplicas: 1 # CNの最小数を1と設定します。

エラスティックスケーリングの閾値。

# 例として、CNの平均CPU使用率をリソースメトリクスとして指定します。
# エラスティックスケーリングの閾値は60%です。
# CNの平均CPU使用率が60%を超えると、CNの数が増えてスケーリングアウトします。
# CNの平均CPU使用率が60%未満の場合は、CNの数が減ってスケーリングインします。
- type: Resource
  resource:
    name: cpu
    target:
      averageUtilization: 60

FAQ

問題の説明: カスタムリソースStarRocksClusterを kubectl apply -f xxx コマンドを使用してインストールすると、エラーが返されて The CustomResourceDefinition 'starrocksclusters.starrocks.com' is invalid: metadata.annotations: Too long: must have at most 262144 bytes と表示されます。

原因の分析: kubectl apply -f xxx コマンドを使用してリソースを作成または更新する場合、メタデータのアノテーション kubectl.kubernetes.io/last-applied-configuration が追加されます。このメタデータのアノテーションはJSON形式であり、last-applied-configuration を記録します。通常は kubectl apply -f xxx は適していますが、カスタムリソースの設定ファイルが非常に大きい場合など、メタデータのアノテーションのサイズが制限を超える可能性があります。

解決策: カスタムリソースStarRocksClusterを初めてインストールする場合は、kubectl create -f xxx を使用することをおすすめします。環境にすでにカスタムリソースStarRocksClusterがインストールされており、その設定を更新する必要がある場合は、kubectl replace -f xxx を使用することをおすすめします。

Operatorを使用してStarRocksをデプロイする

動作原理​

開始する前に​

Kubernetesクラスタを作成する​

StarRocks Operatorのデプロイ​

StarRocksクラスタのデプロイ​

StarRocksクラスタの管理​

StarRocksクラスタへのアクセス​

Kubernetesクラスタ内からのStarRocksクラスタへのアクセス​

Kubernetesクラスタ外からのStarRocksクラスタへのアクセス​

StarRocksクラスタのアップグレード​

BEノードのアップグレード​

FEノードのアップグレード​

StarRocksクラスタのスケール​

BEクラスタのスケールアウト​

FEクラスタのスケールアウト​

CNクラスタの自動スケーリング​

FAQ​