Kubernetes にデプロイする

LicOps で制御したいワークロードがクラスター内で実行される場合や、共有サービスを既にクラスターで実行している場合は、LicOps を Kubernetes にデプロイします。Router を 1 つの Helm チャートでインストールして OpenLM Platform に接続し、必要に応じて 2 つ目のチャートをインストールします。2 つ目のチャートはアドミッション Webhook で、アノテーションを付けた Pod のために admit、dispatch、release の各リクエストを送信します。

Slurm または LSF の場合、Kubernetes は必要ありません。Docker Compose でデプロイするほうが簡単です。OpenLM LicOps をデプロイするを参照してください。

はじめに

• Kubernetes の要件を満たすクラスターと、そのクラスター用に構成された kubectl および Helm 3。
• クラスターから到達でき、システム要件の説明どおりに構成された MongoDB 7.x と Redis 7.0 以降。
• LicOps の Helm チャート。OpenLM が LicOps デプロイバンドルに含めて提供します。openlm-router は Router を、openlm-gke はアドミッション Webhook をインストールします。バンドルの入手については、OpenLM にお問い合わせください。
• クラスターの Pod ネットワークの範囲（Pod CIDR）。多くのクラスターでは、kubectl cluster-info dump | grep -m1 cluster-cidr で表示できます。

シークレットを作成する

チャートは、事前に作成したシークレットから接続文字列と証明書を読み取ります。チャートがこれらのシークレットを自動で作成することはありません。デプロイ先の Namespace で、次のコマンドを実行します。

export NS=openlm-licops

kubectl create namespace $NS

kubectl -n $NS create secret generic openlm-generic-mongo-db-credentials \
  --from-literal=MONGODB__CONNECTIONSTRING='mongodb://<user>:<password>@<mongo-host>:27017/?authSource=admin'

kubectl -n $NS create secret generic openlm-generic-redis-connection-credentials \
  --from-literal=REDIS__CONNECTIONSTRING='<redis-host>:6379,abortConnect=false'

kubectl -n $NS create secret tls openlm-lb-cert --cert=<certificate.pem> --key=<private-key.pem>

TLS シークレット openlm-lb-cert が必要になるのは、Traefik が HTTPS を提供する場合、つまり traefik.enabled と traefik.tls.enabled がどちらも true（既定値）の場合だけです。

次に、暗号化キーを作成します。この作業は、初回インストール時に 1 回だけ行います。

kubectl -n $NS create secret generic openlm-router-platform-encryption \
  --from-literal=ADMISSION_PLATFORM_ENCRYPTION_KEY="$(openssl rand -base64 32)"

暗号化キーは一度だけ作成し、保持する

このキーは、MongoDB に保存された OpenLM Platform の認証情報を復号します。アップグレード時にはシークレットが既に存在するため、このコマンドは失敗します。これは正しい動作なので、この手順は省略してください。エラーを回避するためにシークレットを削除して作り直さないでください。キーが置き換わり、保存された OpenLM Platform の認証情報を読み取れなくなります。

キーは、openssl が出力したとおりのプレーンテキストで渡してください。エンコードは --from-literal が行います。代わりにシークレットをマニフェストとして記述する場合は、キーを data: ではなく stringData: の下に置いてください。そうしないとキーが二重にエンコードされ、OpenLM Platform 接続を最初に保存するときに失敗します。

Router をインストールする

Router を、OpenLM Platform から管理される LicOps Router にするための values ファイル licops-values.yaml を作成します。

routerapi:
  tag: "1.261006.0752"  # olm-routerapi
  encryptionKey:
    secretName: openlm-router-platform-encryption
  admissionController:
    proxyProtocol:
      trustedCidrs:
        - <your-pod-CIDR>
  extraEnv:
    # Required. The Router takes its configuration and rules from the OpenLM Platform.
    - name: licOpsConfiguration__enabled
      value: "true"
    - name: LICOPSCONFIGURATION_ENABLED
      value: "true"
    # Required. Declares a LicOps Router. Fixed at the first start.
    - name: ROUTER_CONFIG_BOOTSTRAP_MODE
      value: loadBalancer
    # Keep the background-job dashboard off.
    - name: hangfire__dashboard__enabled
      value: "false"

routerui:
  tag: "1.261008.0932"  # olm-routerui

チャートをインストールするには、次のコマンドを実行します。

helm upgrade --install openlm-router ./licops-deploy/helm/openlm-router \
  -n $NS --set namespace=$NS -f licops-values.yaml

次の項目は慎重に設定してください。

• --set namespace=$NS。 チャートは、Helm に渡した Namespace に関係なく、チャート自身の values で指定された Namespace（既定は openlm）にリソースを配置します。両方に同じ Namespace を設定してください。
• tag。 チャートには既定のタグがありません。タグを指定しないと、末尾がコロンで終わるイメージ参照が生成され、イメージのプル時になって初めて失敗します。
• trustedCidrs。 Router はこの値を使って、Webhook のサイドカーが各チェックアウトとともに送信する ID を信頼します。Pod の CIDR を設定してください。リストが空の場合、Router は起動しません。Pod ネットワークをカバーしていない範囲はエラーなくこのチェックを通過しますが、その場合 Router はサイドカーが送信するジョブの ID を読み取らないため、それらの Pod からのチェックアウトはジョブと対応付けられません。
• extraEnv のエントリ。 チャートは、OpenLM Platform による管理や LicOps モードを自動では設定しません。これらがないと、LicOps Configuration で定義した内容は Router に届きません。

チャートは 2 つの Service を作成します。ポート 8100 のアドミッション API である openlm-router-api と、LicOps のリッスンポート 30001 である openlm-router-data です。クラスター内のワークロードは、http://openlm-router-api.<namespace>.svc:8100 で API を使用します。

チャートは Traefik 経由で Router を公開する

既定では、チャートはホスト名に関係なく、Traefik のエントリーポイント上の /router-management と /api/v1 を Router にルーティングします。これらのパスは Router の管理用インターフェイスにつながります。これらへのアクセスは管理用ネットワークからだけに許可し、インターネットには公開しないでください。traefik.host を管理者だけが使用するホスト名に設定してアクセスを制限するか、traefik.enabled=false を設定して kubectl port-forward で Router に接続してください。

Traefik は必須ではありません。Traefik を有効にする場合、チャートはエントリーポイント web、websecure、およびポート 30001 の TCP エントリーポイント routertcp を必要とし、routertcp は LicOps のリッスンポートをロードバランサー上で公開します。Traefik を使用しない場合、どちらの Service にもクラスター内からしか到達できません。

Router が起動したことを確認するには、次のコマンドを実行します。Router を OpenLM Platform に接続するまで、Pod は Running で Ready が 0/1 のままなので、kubectl rollout status は完了しません。その間も、ポートフォワード経由で API にアクセスできます。

kubectl -n $NS get pods
kubectl -n $NS port-forward svc/openlm-router-api 8100:8100

別のターミナルで次のコマンドを実行します。

curl http://localhost:8100/api/v1/status

OpenLM LicOps をデプロイするで説明したとおり、レスポンスには "status": "unconfigured" と "shape": "serviceManaged" が含まれます。Router は稼働していますが、OpenLM Platform に接続されていません。

Router を OpenLM Platform に接続する

ポートフォワードを実行したまま、OpenLM LicOps を設定するの説明に従って Router を接続します。そのページの REST コマンドは、http://localhost:8100 に対して実行します。Traefik を有効のままにしている場合は、https://<traefik-address>/router-management/ で Router UI を開くこともできます。

ポートフォワードは自分のターミナル専用で、ターミナルを閉じると停止します。クラスター内のワークロードは、localhost ではなく、必ず Service のアドレスを使用します。

アドミッション Webhook をインストールする

Webhook は任意です。Webhook を使用すると、Pod のイメージを変更せずに Pod のライセンスを取得できます。Webhook は、アノテーションを付けた Pod ごとに、Pod の作成時に admit を呼び出し、dispatch を行って Pod のライセンストラフィックをリダイレクトする init コンテナーを追加し、Pod の終了時にシートを解放するサイドカーを追加します。各ジョブから API を直接呼び出したい場合は、このセクションを省略し、Kubernetes ワークロードを参照してください。

プレリリース

dev-8f79e85 というタグのサイドカーと 2 つの init コンテナーは、プレリリースビルドです。Webhook のイメージ自体は、番号付きのリリースです。

helm upgrade --install openlm-gke ./licops-deploy/helm/openlm-gke -n $NS \
  --set image.tag=dev-8f79e85 \
  --set image.webhookTag=1.260819.1521 \
  --set certManager.enabled=false \
  --set router.restEndpoint=http://openlm-router-api.$NS.svc:8100 \
  --set router.host=openlm-router-data.$NS.svc

• 2 つのタグ。 image.tag はサイドカーと init コンテナーのイメージを、image.webhookTag は Webhook のイメージを指定します。これらは別々にリリースされます。
• 証明書。 Webhook には、Kubernetes API サーバーが信頼する証明書が必要です。certManager.enabled=false を指定すると、チャートは有効期間 365 日の自己署名証明書を生成します。チャートはこの helm upgrade --install コマンドを実行するたびに新しい証明書を作成し、Webhook は起動時にだけ証明書を読み込みます。そのため、実行するたびに kubectl -n $NS rollout restart deployment/openlm-gke で Webhook を再起動してください。証明書の期限が切れると、オプトインしたすべての Pod が拒否されます。生成のために Docker Hub から alpine/k8s をプルし、openssl をインストールする場合があるため、インターネットへのアクセスが必要です。本番環境では cert-manager を使用し、代わりに --set certManager.issuerRef.name=<your-issuer> を指定します。どちらも指定しないと、インストールはすぐに失敗します。
• Router のアドレス。 router.restEndpoint と router.host は必須です。router.restEndpoint には Service のアドレスとポートだけを指定します。API のパスは Webhook が付加するため、値の末尾に /api/v1/admission-controller があるとすべての admit が失敗し、オプトインしたすべての Pod が拒否されます。

Webhook が利用できないと Pod を作成できない

Webhook は失敗ポリシー Fail で登録されるため、Webhook が利用できない間は、オプトインした Namespace で Pod を作成できません。これにより、Webhook の障害中に LicOps のシートなしで Pod が起動するのを防ぎます。起動させたい場合は、--set webhook.failurePolicy=Ignore を指定してインストールしてください。この設定が対象とするのは Webhook だけです。Webhook が動作していても LicOps に到達できない場合は、Kubernetes ワークロードで説明しているとおり、Webhook は Pod をそのまま通します。

チャートは、イメージ olm-pod-sidecar、olm-dispatch-init、olm-iptables-init をプルします。

Namespace と Pod をオプトインする方法については、Kubernetes ワークロードを参照してください。

アップグレード

licops-values.yaml のタグを変更してから、同じ helm upgrade --install コマンドを実行します。アドミッション Webhook をインストールしている場合は、Webhook もアップグレードします。新しい image.tag と image.webhookTag を指定して、Webhook の helm upgrade --install コマンドを再度実行してください。自己署名証明書を使用している場合は、続けて kubectl -n $NS rollout restart deployment/openlm-gke で Webhook を再起動してください。どのビルドがあるかを確認するには、最新のビルドを確認するを参照してください。暗号化キーのシークレットの作成は省略します。このシークレットは既に存在し、変更してはいけません。構成とルールは OpenLM Platform に、開いているセッションは Redis に保存されているため、アップグレード後も保持されます。