runlot ドキュメント

コントロールプレーン・Git ホスティング・ダッシュボードを Kubernetes クラスタ上に置き、データノードは VM 上にパッケージとしてインストールします。

チャートは、コントロールプレーンをクラスタにインストールします。cp-core は 1 レプリカの StatefulSet、cp-public は Ingress の背後に置く Deployment として動き、Git ホスティングも含まれます。パッケージが実行するのと同じインストールコアを実行する Job も含まれます。データノードは VM 上に残り、チャートが公開する Service を通じて参加します。これがプロファイル cp-only で、サポート対象の構成です。ノードを DaemonSet としても動かす full プロファイルも存在しますが、計測が完了していないため、チャートは本番用途での利用を拒否します。

前提条件

Kubernetes 1.30 以降。チャートによる cp-public のダウンタイムなしのアップグレードには sleep preStop ハンドラが必要で、これは 1.30 以降の機能です。
ダッシュボードと Git の名前用の Ingress コントローラと TLS Secret。
小さな ReadWriteOnce ボリューム 2 つ（cp-core の状態と Git のデータ）用の StorageClass。
チャートに同梱されるポリシーを実際に機能させたい場合は、NetworkPolicy を適用できる CNI が必要です。チャートではこれを確認できません。Calico で動作を確認しています。
クラスタから到達できる PostgreSQL 18 と S3 互換ストア。詳しくは要件をご覧ください。
クラスタの LoadBalancer または NodePort から到達できるネットワーク上のデータノード VM。

リポジトリを追加する

Terminal

helm repo add runlot https://charts.runlot.io
helm repo update
helm search repo runlot --devel

チャートのバージョンは runlot のリリースタグと一対一で対応します。runlot のリリースはすべてリリース候補のため、表示するには --devel が必要です。

作成する Secret

Terminal

kubectl create namespace runlot
kubectl -n runlot create secret generic runlot-master-key --from-literal=masterKey="$(openssl rand -hex 32)"
kubectl -n runlot create secret generic runlot-license    --from-file=license=./license
kubectl -n runlot create secret generic runlot-meta-db    --from-literal=url='postgres://runlot:…@db.acme.example:5432/runlot_meta?sslmode=require'
kubectl -n runlot create secret generic runlot-s3         --from-literal=accessKeyId=… --from-literal=secretAccessKey=…
kubectl -n runlot create secret generic runlot-smtp       --from-literal=user=… --from-literal=password=…

チャートがマスターキーやライセンスの Secret を作成することはありません。キーのコピーは私たちの手元にありません。チャートがキーの生成を拒否するのは、クラスターでもこの状態を保つためです。

values.yaml

profile: cp-only
tier: single                      # eval | single | ha

license:   { existingSecret: runlot-license }
masterKey: { existingSecret: runlot-master-key }
metaDB:    { existingSecret: runlot-meta-db }
objectStore:
  endpoint: https://s3.acme.example
  bucket: runlot
  pathStyle: true
  existingSecret: runlot-s3

domains:
  dashboard: runlot.acme.example
  git:       git.acme.example
  apps:      apps.acme.example
  wire:      wire.acme.example
  objects:   objects.acme.example

org:  { name: acme, adminEmails: [[email protected]] }
mail: { smtp: { host: smtp.acme.example, port: 587, existingSecret: runlot-smtp, from: [email protected] } }

ingress:
  className: nginx
  tls: { dashboardSecret: runlot-dash-tls, gitSecret: runlot-git-tls }

service:
  cpCoreNode: { type: LoadBalancer }   # what the VM nodes reach the control plane through

helm show values runlot/runlot --devel で、コメント付きの全設定を表示できます。values.schema.json は、誤った組み合わせをデプロイ成功後ではなく helm lint の時点で拒否します。たとえば cp-only の下の node ブロック、tier: eval 以外での eval 設定、eval 以外での空のマスターキーまたはライセンスの Secret です。

インストール

Terminal

helm install runlot runlot/runlot --devel -n runlot -f values.yaml

チャートは次の順に実行します。RBAC と専用の Secret 2 つ、preflight と install cp を実行する Job、cp-core・cp-public・Git、最後にノードの参加トークンを Secret runlot-node-join に書き込む post-install Job です。

Terminal

kubectl -n runlot get secret runlot-node-join -o jsonpath='{.data.token}' | base64 -d

VM から到達できるアドレスをノードの Service に割り当てる

VM ノードは、相互認証付きの TLS ポートで cp-core に接続します。LoadBalancer にアドレスが割り当てられたら、そのアドレスを cp-core の証明書に含める必要があります。

Terminal

kubectl -n runlot get svc runlot-cp-core-node -o jsonpath='{.status.loadBalancer.ingress[0].ip}'
helm upgrade runlot runlot/runlot --devel -n runlot -f values.yaml \
  --set service.cpCoreNode.externalAddress=<that address>

アドレスは最初のインストール後にしか存在しないため、チャートの NOTES には初回インストール後にこの行が表示されます。

ノードをパッケージでインストールする

パッケージでのインストール: 各データノードに従い、RUNLOT_CP_PRIVATE_ADDR には Service の外部アドレスを、参加トークンには上記の Secret の値を設定します。クラスターでチャートの NetworkPolicy が適用されている場合は、VM ノードのアドレスを networkPolicy.nodeCIDRs に含める必要があります。クラスターのノードサブネットも同様です。LoadBalancer はそのサブネットのアドレスに SNAT するためです。

ノードの場所を宣言する

Terminal

kubectl -n runlot exec deploy/runlot-cp-public -- \
  runlot-admin bootstrap --core http://runlot-cp-core:8081 --nodes node-1=icn/KR/do

cp-only では、ノードはチャートの起動後に参加します。そのため post-install Job には宣言の対象がなく、その旨を出力します。この事実を設定するのが、このコマンドです。

アップグレード

Terminal

helm repo update
helm upgrade runlot runlot/runlot --devel -n runlot -f values.yaml --version <new>

pre-upgrade Job は、新しいコントロールプレーンの起動前にスキーマのマイグレーションを実行します。cp-public はリクエストを落とさずにロールアウトします。cp-core はレプリカが 1 つのため再起動し、その間ダッシュボードは最後の状態を表示し、ノードは引き続き処理を続けます。その後、運用: アップグレードの手順でノードのパッケージをアップグレードします。

ライセンスの変更

Terminal

kubectl -n runlot create secret generic runlot-license --from-file=license=./license --dry-run=client -o yaml | kubectl apply -f -

コントロールプレーンは、マウントされた Secret を 1 分以内に再読み込みします。再起動は不要です。

Helm でインストールする

前提条件

リポジトリを追加する

作成する Secret

values.yaml

インストール

VM から到達できるアドレスをノードの Service に割り当てる

ノードをパッケージでインストールする

ノードの場所を宣言する

アップグレード

ライセンスの変更

このページの目次