--- title: Kubernetes にデプロイする description: Helm を使用して OpenLM LicOps を Kubernetes にインストールして OpenLM Platform に接続し、必要に応じて、アノテーションを付けた Pod のライセンスを取得する Webhook も追加します。 product: OpenLM Platform --- LicOps で制御したいワークロードがクラスター内で実行される場合や、共有サービスを既にクラスターで実行している場合は、LicOps を Kubernetes にデプロイします。Router を 1 つの Helm チャートでインストールして OpenLM Platform に接続し、必要に応じて 2 つ目のチャートをインストールします。2 つ目のチャートはアドミッション Webhook で、アノテーションを付けた Pod のために admit、dispatch、release の各リクエストを送信します。 Slurm または LSF の場合、Kubernetes は必要ありません。Docker Compose でデプロイするほうが簡単です。[OpenLM LicOps をデプロイする](https://www.openlm.com/documentation/ja/cloud/deployment-operations/licops/deployment)を参照してください。 ## はじめに - [Kubernetes の要件](https://www.openlm.com/documentation/ja/cloud/deployment-operations/licops/system-requirements#kubernetes-の要件)を満たすクラスターと、そのクラスター用に構成された `kubectl` および Helm 3。 - クラスターから到達でき、[システム要件](https://www.openlm.com/documentation/ja/cloud/deployment-operations/licops/system-requirements#redis-の要件)の説明どおりに構成された 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 で、次のコマンドを実行します。 ```bash export NS=openlm-licops kubectl create namespace $NS kubectl -n $NS create secret generic openlm-generic-mongo-db-credentials \ --from-literal=MONGODB__CONNECTIONSTRING='mongodb://:@:27017/?authSource=admin' kubectl -n $NS create secret generic openlm-generic-redis-connection-credentials \ --from-literal=REDIS__CONNECTIONSTRING=':6379,abortConnect=false' kubectl -n $NS create secret tls openlm-lb-cert --cert= --key= ``` TLS シークレット `openlm-lb-cert` が必要になるのは、Traefik が HTTPS を提供する場合、つまり `traefik.enabled` と `traefik.tls.enabled` がどちらも `true`（既定値）の場合だけです。 次に、暗号化キーを作成します。この作業は、初回インストール時に 1 回だけ行います。 ```bash kubectl -n $NS create secret generic openlm-router-platform-encryption \ --from-literal=ADMISSION_PLATFORM_ENCRYPTION_KEY="$(openssl rand -base64 32)" ``` :::warning[暗号化キーは一度だけ作成し、保持する] このキーは、MongoDB に保存された OpenLM Platform の認証情報を復号します。アップグレード時にはシークレットが既に存在するため、このコマンドは失敗します。これは正しい動作なので、この手順は省略してください。エラーを回避するためにシークレットを削除して作り直さないでください。キーが置き換わり、保存された OpenLM Platform の認証情報を読み取れなくなります。 キーは、`openssl` が出力したとおりのプレーンテキストで渡してください。エンコードは `--from-literal` が行います。代わりにシークレットをマニフェストとして記述する場合は、キーを `data:` ではなく `stringData:` の下に置いてください。そうしないとキーが二重にエンコードされ、OpenLM Platform 接続を最初に保存するときに失敗します。 ::: ## Router をインストールする Router を、OpenLM Platform から管理される LicOps Router にするための values ファイル `licops-values.yaml` を作成します。 ```yaml routerapi: tag: "1.261006.0752" # olm-routerapi encryptionKey: secretName: openlm-router-platform-encryption admissionController: proxyProtocol: trustedCidrs: - 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 ``` チャートをインストールするには、次のコマンドを実行します。 ```bash 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..svc:8100` で API を使用します。 :::warning[チャートは 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 にアクセスできます。 ```bash kubectl -n $NS get pods kubectl -n $NS port-forward svc/openlm-router-api 8100:8100 ``` 別のターミナルで次のコマンドを実行します。 ```bash curl http://localhost:8100/api/v1/status ``` [OpenLM LicOps をデプロイする](https://www.openlm.com/documentation/ja/cloud/deployment-operations/licops/deployment#スタックを起動する)で説明したとおり、レスポンスには `"status": "unconfigured"` と `"shape": "serviceManaged"` が含まれます。Router は稼働していますが、OpenLM Platform に接続されていません。 ## Router を OpenLM Platform に接続する ポートフォワードを実行したまま、[OpenLM LicOps を設定する](https://www.openlm.com/documentation/ja/cloud/deployment-operations/licops/configuration)の説明に従って Router を接続します。そのページの REST コマンドは、`http://localhost:8100` に対して実行します。Traefik を有効のままにしている場合は、`https:///router-management/` で Router UI を開くこともできます。 ポートフォワードは自分のターミナル専用で、ターミナルを閉じると停止します。クラスター内のワークロードは、`localhost` ではなく、必ず Service のアドレスを使用します。 ## アドミッション Webhook をインストールする Webhook は任意です。Webhook を使用すると、Pod のイメージを変更せずに Pod のライセンスを取得できます。Webhook は、アノテーションを付けた Pod ごとに、Pod の作成時に admit を呼び出し、dispatch を行って Pod のライセンストラフィックをリダイレクトする init コンテナーを追加し、Pod の終了時にシートを解放するサイドカーを追加します。各ジョブから API を直接呼び出したい場合は、このセクションを省略し、[Kubernetes ワークロード](https://www.openlm.com/documentation/ja/cloud/deployment-operations/licops/integrations/kubernetes#ジョブから-api-を呼び出す)を参照してください。 :::warning[プレリリース] `dev-8f79e85` というタグのサイドカーと 2 つの init コンテナーは、プレリリースビルドです。Webhook のイメージ自体は、番号付きのリリースです。 ::: ```bash 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=` を指定します。どちらも指定しないと、インストールはすぐに失敗します。 - **Router のアドレス。** `router.restEndpoint` と `router.host` は必須です。`router.restEndpoint` には Service のアドレスとポートだけを指定します。API のパスは Webhook が付加するため、値の末尾に `/api/v1/admission-controller` があるとすべての admit が失敗し、オプトインしたすべての Pod が拒否されます。 :::warning[Webhook が利用できないと Pod を作成できない] Webhook は失敗ポリシー `Fail` で登録されるため、Webhook が利用できない間は、オプトインした Namespace で Pod を作成できません。これにより、Webhook の障害中に LicOps のシートなしで Pod が起動するのを防ぎます。起動させたい場合は、`--set webhook.failurePolicy=Ignore` を指定してインストールしてください。この設定が対象とするのは Webhook だけです。Webhook が動作していても LicOps に到達できない場合は、[Kubernetes ワークロード](https://www.openlm.com/documentation/ja/cloud/deployment-operations/licops/integrations/kubernetes)で説明しているとおり、Webhook は Pod をそのまま通します。 ::: チャートは、イメージ `olm-pod-sidecar`、`olm-dispatch-init`、`olm-iptables-init` をプルします。 Namespace と Pod をオプトインする方法については、[Kubernetes ワークロード](https://www.openlm.com/documentation/ja/cloud/deployment-operations/licops/integrations/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 を再起動してください。どのビルドがあるかを確認するには、[最新のビルドを確認する](https://www.openlm.com/documentation/ja/cloud/deployment-operations/licops/deployment#最新のビルドを確認する)を参照してください。暗号化キーのシークレットの作成は省略します。このシークレットは既に存在し、変更してはいけません。構成とルールは OpenLM Platform に、開いているセッションは Redis に保存されているため、アップグレード後も保持されます。