- 概要
- 要件
- デプロイ テンプレート
- 手動: インストールを準備する
- 手動: インストールを準備する
- 手順 2: オフライン インストール用に OCI 準拠レジストリを設定する
- 手順 3: 外部 ObjectStore を構成する
- 手順 4: High Availability Add-on を構成する
- 手順 5: SQL データベースを構成する
- 手順 6: ロード バランサーを構成する
- 手順 7: DNS を構成する
- 手順 8: ディスクを構成する
- 手順 9: カーネルと OS レベルの設定を構成する
- 手順 10: ノード ポートを構成する
- 手順 11: その他の設定を適用する
- 手順 12: 必要な RPM パッケージを検証してインストールする
- 手順 13: cluster_config.json を生成する
- 証明書の設定
- データベースの構成
- 外部 ObjectStore の構成
- 署名済み URL の構成
- Kerberos 認証の構成
- 外部の OCI 準拠レジストリの設定
- Disaster Recovery - アクティブ/パッシブおよびアクティブ/アクティブの構成
- High Availability Add-on の構成
- Orchestrator 固有の設定
- Insights 固有の構成
- Process Mining 固有の構成
- Document Understanding 固有の構成
- Automation Suite ロボット固有の構成
- 監視の構成
- 任意: プロキシ サーバーを構成する
- 任意: マルチノードの HA 対応の運用クラスターにおけるゾーン障害に対する復元設定を有効化する
- 任意: カスタムの Resolv.con を渡す
- 任意: フォールト トレランスを向上させる
- install-uipath.sh パラメーター
- GPU がサポートされた専用のエージェント ノードを追加する
- Task Mining 専用のエージェント ノードを追加する
- Task Mining アプリケーションを接続する
- Automation Suite ロボット専用のエージェント ノードを追加する
- 手順 15: オフライン インストール用に一時的な Docker レジストリを設定する
- 手順 16: インストールの前提条件を検証する
- 手動: インストールを実行する
- インストール後
- クラスターの管理
- 監視とアラート機能
- 移行とアップグレード
- 製品固有の設定
- ベスト プラクティスとメンテナンス
- トラブルシューティング
- インストール時にサービスをトラブルシューティングする方法
- クラスターをアンインストールする方法
- オフライン成果物をクリーンアップしてディスク領域を改善する方法
- Redis データをクリアする方法
- Istio ログを有効化する方法
- ログを手動でクリーンアップする方法
- sf-logs バケットに保存されている古いログをクリーンアップする方法
- AI Center のストリーミング ログを無効化する方法
- 失敗した Automation Suite インストールをデバッグする方法
- アップグレード後に古いインストーラーからイメージを削除する方法
- TX チェックサム オフロードを無効化する方法
- Automation Suite 2022.10.10 および 2022.4.11 から 2023.10.2 にアップグレードする方法
- ArgoCD のログ レベルを手動で Info に設定する方法
- AI Center のストレージを拡張する方法
- 外部レジストリーのエンコードされたpull_secret_valueを生成する方法
- TLS 1.2 で弱い暗号に対処する方法
- 証明書の操作方法
- アプリケーション ログを Splunk に転送する方法
- レジストリ ポッドから未使用の Docker イメージをクリーンアップする方法
- クラスター内の ObjectStore (Ceph) を使用して DU の使用状況データを収集する方法
- エアギャップ環境に RKE2 SELinux をインストールする方法
- NFS サーバー上の古い差分バックアップをクリーンアップする方法
- RHEL 8.4 OS でオフライン インストールを実行できない
- バンドルのダウンロード中のエラー
- バイナリがないため、オフライン インストールが失敗する
- オフライン インストールでの証明書の問題
- Longhorn のセットアップ中に最初のインストールが失敗する
- SQL 接続文字列の検証エラー
- selinux iscsid モジュールの前提条件の確認が失敗する
- Azure ディスクが SSD としてマークされない
- 証明書の更新後のエラー
- ウイルス対策が原因でインストールの問題が発生する
- OS のアップグレード後に Automation Suite が動作しない
- Automation Suite で backlog_wait_time を 0 に設定する必要がある
- ワークロードの準備ができていないためボリュームをマウントできない
- サポート バンドルのログ収集の失敗
- Test Automation SQL の接続文字列は無視されます
- DNS 設定が CoreDNS によって受け入れられない
- Automation Suite のアップグレード後に Insights を再インストールまたはアップグレードするとデータが失われる
- シングルノードのアップグレードがファブリック ステージで失敗する
- 2021.10 からの自動アップグレード後にクラスターが異常になる
- Ceph の異常によりアップグレードが失敗する
- 領域の問題のために rke2 が開始しない
- ボリュームがマウントできず、アタッチ/デタッチ ループ状態のまま
- Orchestrator データベース内のクラシック オブジェクトが原因でアップグレードが失敗する
- Ceph クラスターがサイドバイサイド アップグレード後に機能低下ステートで検出される
- 異常な Insights コンポーネントが原因で移行が失敗する
- Apps のサービス アップグレードの失敗
- インプレース アップグレードのタイムアウト
- Docker レジストリの移行が PVC の削除段階でスタックする
- v2023.10 以降へのアップグレード後に AI Center のプロビジョニングが失敗する
- オフライン環境でアップグレードが失敗する
- アップグレード中に SQL の検証が失敗する
- アップグレード後に snapshot-controller-crds ポッドが CrashLoopBackOff ステートになる
- Longhorn REST API エンドポイントのアップグレード/再インストール エラー
- Insights の PVC サイズが上書きされたためにアップグレードが失敗する
- サービス スクリプトの実行中にサービスのアップグレードが失敗する
- 管理ポータルのタイムアウト期間を設定する
- 移行後に認証が機能しない
- Kinit: Cannot find KDC for realm <AD Domain> while getting initial credentials
- kinit: Keytab contains no suitable keys for *** while getting initial credentials
- 無効なステータス コードが原因で GSSAPI 操作が失敗した
- Alarm received for failed kerberos-tgt-update job
- SSPI Provider: Server not found in Kerberos database
- アカウントが無効なため AD ユーザーのログインに失敗した
- ArgoCD へのログインに失敗した
- 基になるディレクトリ接続を更新する
- サンドボックス イメージを取得できない
- ポッドが ArgoCD UI に表示されない
- Redis プローブの障害
- RKE2 サーバーの起動に失敗する
- UiPath 名前空間でシークレットが見つからない
- 初回インストール後に ArgoCD が進行中ステートになる
- クラスターの復元またはロールバック後にサービスが異常になる
- Init:0/X でポッドがスタックする
- Ceph-rook のメトリックが監視ダッシュボードに表示されない
- プロキシ環境でポッドが FQDN と通信できない
- アップグレード後にメール アラートを設定できない
- アップストリームに正常な問題はありません
- オフライン環境でエージェント ノードを追加できない
- FQDN にアクセスすると RBAC: アクセス拒否エラーが返されます
- Process Mining で高可用性を実行する
- Kerberos を使用してログインすると、Process Mining を取り込むことができなかった
- 障害復旧後、Dapr が Process Mining に対して正しく機能しない
- クラスター モードで Redis を使用した Dapr を構成する
- pyodbc 形式の接続文字列を使用して AutomationSuite_ProcessMining_Warehouse データベースに接続できない
- Airflow のインストールが「sqlalchemy.exc.ArgumentError: Could not parse rfc1738 URL from string ''」で失敗する
- SQL Server ポート 1433 を使用する IP テーブル ルールを追加する方法
- CData Sync を実行しているサーバーの Automation Suite の証明書が信頼されない
- 診断ツールを実行する
- Automation Suite サポート バンドルを使用する
- ログを確認する
- 要約されたテレメトリを確認する

Linux の Automation Suite のインストール ガイド
証明書を管理する
インストール プロセスによって、ユーザーに代わって自己署名証明書が生成されます。これらの証明書は FIPS に準拠しており、90 日で有効期限が切れます。インストールが完了したら、信頼された証明機関 (CA) によって署名された証明書にすみやかに置換する必要があります。
証明書を更新しないと、90 日でインストールが動作を停止します。 Automation Suite を FIPS が有効化されたホストにインストールした後で証明書を更新する場合は、その証明書が FIPS に対応していることを確認してください。
インストール バンドルでは、インストール後に証明書を更新できるクラスター管理ツールを提供しています。このツールにアクセスするには、インストーラー バンドルの保存場所に移動します。
cd /opt/UiPathAutomationSuite/
cd /opt/UiPathAutomationSuite/
証明書署名要求 (CSR) と秘密キーを生成する
CSR および秘密キーを生成するには、次のコマンドを実行します。
# copy the machine openssl configuration locally
cp /etc/pki/tls/openssl.cnf ./openssl.tmp.cnf
# Replace the [AUTOMATION_SUITE_FQDN] value. For example, "automationsuite.corp.com"
AS_FQDN=[AUTOMATION_SUITE_FQDN]
cat >> ./openssl.tmp.cnf <<EOF
[SAN]
subjectAltName=DNS:$AS_FQDN,DNS:alm.$AS_FQDN,DNS:monitoring.$AS_FQDN,DNS:registry.$AS_FQDN,DNS:objectstore.$AS_FQDN,DNS:insights.$AS_FQDN
EOF
# create the certificate request
openssl req -new -sha256 -newkey rsa:2048 -nodes -keyout server.key -subj "/C=xx/ST=xx/O=xx/OU=xx/CN=$AS_FQDN" -reqexts SAN -config openssl.tmp.cnf -out ${AS_FQDN}.csr
# copy the machine openssl configuration locally
cp /etc/pki/tls/openssl.cnf ./openssl.tmp.cnf
# Replace the [AUTOMATION_SUITE_FQDN] value. For example, "automationsuite.corp.com"
AS_FQDN=[AUTOMATION_SUITE_FQDN]
cat >> ./openssl.tmp.cnf <<EOF
[SAN]
subjectAltName=DNS:$AS_FQDN,DNS:alm.$AS_FQDN,DNS:monitoring.$AS_FQDN,DNS:registry.$AS_FQDN,DNS:objectstore.$AS_FQDN,DNS:insights.$AS_FQDN
EOF
# create the certificate request
openssl req -new -sha256 -newkey rsa:2048 -nodes -keyout server.key -subj "/C=xx/ST=xx/O=xx/OU=xx/CN=$AS_FQDN" -reqexts SAN -config openssl.tmp.cnf -out ${AS_FQDN}.csr
IT チームが、取得した値を使用して署名証明書を生成します。生成された秘密キーはローカルのままです。
サーバー証明書を管理する
サーバー証明書の詳細情報を表示するには、次のコマンドを実行します。
sudo ./configureUiPathAS.sh tls-cert --help
sudo ./configureUiPathAS.sh tls-cert --help
出力:
************************************************************************************
Manage cluster tls and server certificate
Usage:
configureUiPathAS.sh tls-cert [command]
configureUiPathAS.sh tls-cert [flags]
Available Commands:
update Update the tls / server certificate
get Get the tls / server certificate
Flags:
-h|--help Display help
************************************************************************************
************************************************************************************
Manage cluster tls and server certificate
Usage:
configureUiPathAS.sh tls-cert [command]
configureUiPathAS.sh tls-cert [flags]
Available Commands:
update Update the tls / server certificate
get Get the tls / server certificate
Flags:
-h|--help Display help
************************************************************************************
以降のセクションでは、./configureUiPathAS.sh tls-cert コマンドを使用して実行できる操作について説明します。
サーバー証明書を更新する
オンライン インストール: サーバー証明書の確認方法
証明書は Istio レベルでシークレットとして保存されます。証明書は、istio-system 名前空間内に istio-ingressgateway-certs という名前で確認できます。
証明書ファイルについては、以下のリストをご覧ください。
- サーバー TLS 証明書は
tls.crtとして保存されます。 - サーバー TLS 秘密キーは
tls.keyとして保存されます。 - CA バンドルは
ca.crtとして保存されます。
次のコマンドを使用して、シークレットを確認できます。
kubectl -n istio-system get secrets istio-ingressgateway-certs -o yaml
kubectl -n istio-system get secrets istio-ingressgateway-certs -o yaml
証明書は UiPath 名前空間にも保存されます。これは、受信呼び出しを信頼するために証明書情報を必要とするすべての UiPath® 製品に適用されます。詳細については、「証明書に関連するコンテナー アーキテクチャを理解する」をご覧ください。
オフライン インストール: サーバー証明書の確認方法
オフライン デプロイには、 オンライン デプロイに必要な証明書のほかに、同じ rootCA.crt と tls.crtを使用する 2 つの場所 (ArgoCD と Docker レジストリ) があります。その後、証明書は Docker と ArgoCD の両方の名前空間に保存されます。
次のコマンドを使用して、シークレットを確認できます。
# For docker registry
kubectl -n docker-registry get secrets docker-registry-tls -o yaml
# For Argocd
argocd login alm.cluster_fqnd --username argocd_username --password argocd_password
argocd cert list --cert-type https
# For docker registry
kubectl -n docker-registry get secrets docker-registry-tls -o yaml
# For Argocd
argocd login alm.cluster_fqnd --username argocd_username --password argocd_password
argocd cert list --cert-type https
サーバー証明書の更新方法
サーバー証明書を更新する前に、証明書キーを復号する必要があります。復号手順をスキップすると、エラーが発生します。
証明書キーを復号するには、次のコマンドを実行します。
# replace /path/to/encrypted/cert/key to absolute file path of key
# replace /path/to/decrypt/cert/key to store decrypt key
# Once prompted, please entry the passphrase or password to decrypt the key
openssl rsa -in /path/to/encrypted/cert/key -out /path/to/decrypt/cert/key
# replace /path/to/encrypted/cert/key to absolute file path of key
# replace /path/to/decrypt/cert/key to store decrypt key
# Once prompted, please entry the passphrase or password to decrypt the key
openssl rsa -in /path/to/encrypted/cert/key -out /path/to/decrypt/cert/key
以下に示すように、configureUiPathAS.sh スクリプトを実行し、証明書を更新します。3 つの証明書ファイルのそれぞれに対するパスが必要です。証明書ファイルは、いずれも PEM 形式である必要があります。
- 証明機関バンドル - このバンドルには TLS サーバー証明書への署名に使用するチェーン証明書のみを含める必要があります。チェーンの制限は最大 9 個の証明書です。
- サーバー証明書 - 公開サーバー証明書です。
- 秘密キー - サーバー証明書の秘密キーです。
sudo ./configureUiPathAS.sh tls-cert update --ca-cert-file /path/to/cacert --tls-cert-file /path/to/tlscert --tls-key-file /path/to/tlskeysudo ./configureUiPathAS.sh tls-cert update --ca-cert-file /path/to/cacert --tls-cert-file /path/to/tlscert --tls-key-file /path/to/tlskey
下記のファイルは、/directory/path/to/store/certificate に保存されます。
TLS 証明書にアクセスする
証明書ファイルを出力するには、証明書が保存されているディレクトリを指定して、次のコマンドを実行します。
sudo ./configureUiPathAS.sh tls-cert get --outpath /directory/path/to/store/certificate
sudo ./configureUiPathAS.sh tls-cert get --outpath /directory/path/to/store/certificate
CA 証明書をホスト信頼ストアに追加する
生成された証明書が信頼できることを確認するのはユーザーの責任です。
証明書をホスト仮想マシンの信頼ストアに追加するには、クラスター内のすべてのノードで次のコマンドを実行します。
# 1. Copy the certificate file to the /usr/share/pki/ca-trust-source/anchors/ or the /etc/pki/ca-trust/source/anchors/ directory
cp /path/to/the/ca-cert /usr/share/pki/ca-trust-source/anchors/
# 2. Update the trust store configuration
update-ca-trust
# 1. Copy the certificate file to the /usr/share/pki/ca-trust-source/anchors/ or the /etc/pki/ca-trust/source/anchors/ directory
cp /path/to/the/ca-cert /usr/share/pki/ca-trust-source/anchors/
# 2. Update the trust store configuration
update-ca-trust
追加の CA 証明書を管理する
追加の CA 証明書の詳細情報を表示するには、次のコマンドを実行します。
./configureUiPathAS.sh additional-ca-certs --help
./configureUiPathAS.sh additional-ca-certs --help
出力:
***************************************************************************************
Manage additional CA certificates, this can be used to add sql server CA
Usage:
configureUiPathAS.sh additional-ca-certs [command]
configureUiPathAS.sh additional-ca-certs [flags]
Available Commands:
update Update the additional trusted CA certificates.
get Get the additional trusted CA certificates
Flags:
-h|--help Display help
***************************************************************************************
***************************************************************************************
Manage additional CA certificates, this can be used to add sql server CA
Usage:
configureUiPathAS.sh additional-ca-certs [command]
configureUiPathAS.sh additional-ca-certs [flags]
Available Commands:
update Update the additional trusted CA certificates.
get Get the additional trusted CA certificates
Flags:
-h|--help Display help
***************************************************************************************
以降のセクションでは、./configureUiPathAS.sh additional-ca-certs コマンドを使用して実行できる操作について説明します。
CA 証明書を更新する
このコマンドにより、既存の構成済み CA 証明書を更新または置換できます。
./configureUiPathAS.sh additional-ca-certs update --ca-cert-file /path/to/ca/certs
./configureUiPathAS.sh additional-ca-certs update --ca-cert-file /path/to/ca/certs
上記のコマンドは、既存の証明書のリストに新しい証明書を追加します。以前に構成した証明書をすべて置き換える場合は、必ず末尾に --replace を付加してください。
CA 証明書バンドル ファイルは有効な .pem 形式である必要があり、複数の証明書を含めることができます。
CA 証明書にアクセスする
設定済みの CA 証明書をダウンロードするには、次のコマンドを実行します。
./configureUiPathAS.sh additional-ca-certs get --outpath /path/to/download/certs
./configureUiPathAS.sh additional-ca-certs get --outpath /path/to/download/certs
CA 証明書をホスト信頼ストアに追加する
生成された証明書が信頼できることを確認するのはユーザーの責任です。
証明書をホスト仮想マシンの信頼ストアに追加するには、クラスター内のすべてのノードで次のコマンドを実行します。
# 1. Copy the certificate file to the /usr/share/pki/ca-trust-source/anchors/ or the /etc/pki/ca-trust/source/anchors/ directory
cp /path/to/the/ca-cert /usr/share/pki/ca-trust-source/anchors/
# 2. Update the trust store configuration
update-ca-trust
# 1. Copy the certificate file to the /usr/share/pki/ca-trust-source/anchors/ or the /etc/pki/ca-trust/source/anchors/ directory
cp /path/to/the/ca-cert /usr/share/pki/ca-trust-source/anchors/
# 2. Update the trust store configuration
update-ca-trust
Windows 環境の場合は、この ガイド を参照して信頼されたルート証明書をインストールしてください。
ID トークン署名証明書を管理する
追加の ID トークン署名証明書の詳細情報を表示するには、次のコマンドを実行します。
sudo ./configureUiPathAS.sh identity token-cert --help
sudo ./configureUiPathAS.sh identity token-cert --help
出力:
************************************************************************************
Manage Identity token signing certificate
Usage:
configureUiPathAS.sh identity token-cert [command]
configureUiPathAS.sh identity token-cert [flags]
Available Commands:
update Update secondary certificate to signing
the authentication token
rotate Switch secondary certificate as a primary
token signing certificate
get Get token signing certificate
Flags:
-h|--help Display help
************************************************************************************
************************************************************************************
Manage Identity token signing certificate
Usage:
configureUiPathAS.sh identity token-cert [command]
configureUiPathAS.sh identity token-cert [flags]
Available Commands:
update Update secondary certificate to signing
the authentication token
rotate Switch secondary certificate as a primary
token signing certificate
get Get token signing certificate
Flags:
-h|--help Display help
************************************************************************************
次のセクションでは、./configureUiPathAS.sh identity token-cert コマンドを使用して実行できる操作について詳しく説明します。
証明書を更新する
新しい証明書をアップロードしてトークンに署名するには、次のコマンドを実行します。
次のコマンドでは、既存のトークン署名証明書は置換されません。
指定する証明書が .pem 形式であることを確認します。
sudo ./configureUiPathAS.sh identity token-cert update --cert-file-path /path/to/cert --cert-key-file-path /path/to/certkey
sudo ./configureUiPathAS.sh identity token-cert update --cert-file-path /path/to/cert --cert-key-file-path /path/to/certkey
証明書をローテーションする
古い証明書をローテーションしたり、新しい証明書に置換したりするには、次のコマンドを実行します。
sudo ./configureUiPathAS.sh identity token-cert rotate
sudo ./configureUiPathAS.sh identity token-cert rotate
証明書の更新とローテーションの間には、約 24 - 48 時間のリード タイムが必要です。
このリード タイムは、キャッシュされている、古い証明書によって署名されたトークンの認証を引き続きサポートするために必要となります。
キャッシュ トークンの有効期限の満了を待たずに証明書をローテーションすると、ダウンタイムが発生する場合があります。さらに、すべてのロボットの再起動が必要になる可能性もあります。
証明書の緊急ローテーション
以下の手順は緊急時専用です。証明書は、有効期限前にローテーションする必要があります。
証明書の緊急更新を実行するには、次の手順に従います。
-
新しい証明書を取得するか、自己署名証明書を作成して、次のローテーション手順を実行するために使用するクラスター サーバー ノードにコピーします。新しい自己署名証明書を作成するには、次のコマンドを実行します。
openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 -keyout identityserver.key -out identityserver.crt openssl pkcs12 -export -out identityserver.pfx -inkey identityserver.key -in identityserver.crtopenssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 -keyout identityserver.key -out identityserver.crt openssl pkcs12 -export -out identityserver.pfx -inkey identityserver.key -in identityserver.crt -
IdentityServer1.pfxの有効期限が切れている場合は、証明書をローテーションおよび更新します。手順については、「証明書をローテーションする」をご覧ください。 -
IdentityServer2.pfxの有効期限が切れている場合は、証明書を更新します。 -
両方の証明書の有効期限が切れている場合は、更新してローテーションし、もう一度更新します。
-
すべてのデプロイを再起動します。手順については、「トラブルシューティング」をご覧ください。
-
すべてのブラウザー キャッシュをクリアします。シークレット モードまたはプライベート モードで実行する場合、この手順はスキップできます。
-
Firefox の場合は、 Ctrl + Shift + DEL キーを押し、[ キャッシュ] を選択して [ OK] を選択します。

-
Chrome の場合は、 CTRL+SHIFT+DEL キーを押し、[キャッシュされた 画像とファイル] を選択して、[ データの消去] を選択します。

証明書にアクセスする
現在のトークン署名証明書をダウンロードするには、次のコマンドを実行します。
sudo ./configureUiPathAS.sh identity token-cert get --outpath /directory/path/to/store/certificate
sudo ./configureUiPathAS.sh identity token-cert get --outpath /directory/path/to/store/certificate
RKE2 証明書を管理する
既定では、RKE2 証明書は 12 か月で有効期限が切れます。有効期限の 90 日前に RKE2 を再起動すると、証明書がローテーションされます。
詳細については、「 RKE2 - Advanced Options - Certificate rotation」をご覧ください。
RKE2 証明書の有効期限を確認する
RKE2 証明書の有効期限を確認するには、任意のノードで次のコマンドを実行します。
if [[ -d "/var/lib/rancher/rke2/server/tls" ]]; then
dir="/var/lib/rancher/rke2/server/tls"
elif [[ -d "/var/lib/rancher/rke2/agent/tls" ]]; then
dir="/var/lib/rancher/rke2/agent/tls"
else
dir="/var/lib/rancher/rke2/agent/"
fi
# Loop through each .crt file in the directory
for file in "$dir"/*.crt; do
# Extract the expiry date from the certificate
expiry=$(openssl x509 -enddate -noout -in "$file" | cut -d= -f 2-)
# Get the file name without the path
filename=$(basename "$file")
# Print the filename and expiry date in a pretty format
printf "%-30s %s\n" "$filename:" "$expiry"
done
if [[ -d "/var/lib/rancher/rke2/server/tls" ]]; then
dir="/var/lib/rancher/rke2/server/tls"
elif [[ -d "/var/lib/rancher/rke2/agent/tls" ]]; then
dir="/var/lib/rancher/rke2/agent/tls"
else
dir="/var/lib/rancher/rke2/agent/"
fi
# Loop through each .crt file in the directory
for file in "$dir"/*.crt; do
# Extract the expiry date from the certificate
expiry=$(openssl x509 -enddate -noout -in "$file" | cut -d= -f 2-)
# Get the file name without the path
filename=$(basename "$file")
# Print the filename and expiry date in a pretty format
printf "%-30s %s\n" "$filename:" "$expiry"
done
得られる出力は、次の画像のようになります。

RKE2 証明書をローテーションする
既定では、RKE2 証明書は 12 か月で有効期限が切れます。有効期限の 90 日前に RKE2 を再起動すると、証明書がローテーションされます。ただし、証明書の有効期間が 90 日を超える場合は、「 RKE2 - Advanced Options - Certificate rotation」に記載されている手順に従って証明書を手動でローテーションする必要があります。
特定の要件を満たすように RKE2 証明書の有効期限をカスタマイズする場合は、サーバー ノードとエージェント ノードの両方で RKE2 サービスを再起動する前にカスタマイズできます。
RKE2 の証明書をローテーションするには、最初にサーバー ノードで一連の操作を実行してから、エージェント ノードでいくつかの手順を続行します。
サーバー ノードで次の手順を実行します。
- RKE2 サーバーを停止します。
systemctl stop rke2-server.servicesystemctl stop rke2-server.service - 残りの RKE2 プロセスをすべてクリアします。
rke2-killall.shrke2-killall.sh /var/lib/rancher/rke2/server/tls/にあるdynamic-cert.jsonファイルを削除します。- RKE2 証明書の有効期限をカスタマイズするには、次のコマンドを使用します。 この例では有効期間を 1000 日に設定していますが、この値は要件に基づいて変更できます。
SERVICE_NAME="rke2-server.service" conf_file_path="/etc/systemd/system/${SERVICE_NAME}.d/cert.conf" mkdir -p /etc/systemd/system/"${SERVICE_NAME}".d/ cat > "$conf_file_path" <<EOF [Service] Environment="CATTLE_NEW_SIGNED_CERT_EXPIRATION_DAYS=1000" EOF systemctl daemon-reloadSERVICE_NAME="rke2-server.service" conf_file_path="/etc/systemd/system/${SERVICE_NAME}.d/cert.conf" mkdir -p /etc/systemd/system/"${SERVICE_NAME}".d/ cat > "$conf_file_path" <<EOF [Service] Environment="CATTLE_NEW_SIGNED_CERT_EXPIRATION_DAYS=1000" EOF systemctl daemon-reload - RKE2 サーバーを再起動します。
systemctl start rke2-server.servicesystemctl start rke2-server.service注:クラスターに複数のサーバー ノードがある場合、手順 1 から 4 を完全には実行できないことがあります。これは etcd がリーダーの選出を完了できないためです。この場合は、他のサーバー ノードで手順 1 から 4 を繰り返します。
kube-system名前空間からrke2-servingシークレットを削除します。kubectl delete secret -n kube-system rke2-servingkubectl delete secret -n kube-system rke2-serving注:マルチノード デプロイでは、必要な数のサーバー ノードで最初の 4 つの操作を完了するまで、
kubectlコマンドを実行できない場合があります。これは、etcd クォーラム要件を満たすためです。rke2-servingシークレットは、RKE2 サーバーが起動したらすぐに削除できます。
etcd がクォーラムに達すると、RKE2 サーバーは残りのコントロール プレーン ポッドを起動できます。すると、kubectl get nodes コマンドが正常に実行されたことを確認できます。サーバー ノードの準備ができたら、エージェント ノードの操作に進んで証明書を再生成できます。
エージェント ノードで次の手順を実行します。
- RKE2 サーバーを停止します。
systemctl stop rke2-agent.servicesystemctl stop rke2-agent.service - 残りの RKE2 プロセスをすべてクリアします。
rke2-killall.shrke2-killall.sh - RKE2 証明書の有効期限をカスタマイズするには、次のコマンドを使用します。 この例では有効期間を 1000 日に設定していますが、この値は要件に基づいて変更できます。
SERVICE_NAME="rke2-agent.service" conf_file_path="/etc/systemd/system/${SERVICE_NAME}.d/cert.conf" mkdir -p /etc/systemd/system/"${SERVICE_NAME}".d/ cat > "$conf_file_path" <<EOF [Service] Environment="CATTLE_NEW_SIGNED_CERT_EXPIRATION_DAYS=1000" EOF systemctl daemon-reloadSERVICE_NAME="rke2-agent.service" conf_file_path="/etc/systemd/system/${SERVICE_NAME}.d/cert.conf" mkdir -p /etc/systemd/system/"${SERVICE_NAME}".d/ cat > "$conf_file_path" <<EOF [Service] Environment="CATTLE_NEW_SIGNED_CERT_EXPIRATION_DAYS=1000" EOF systemctl daemon-reload - RKE2 サーバーを再起動します。
systemctl start rke2-agent.servicesystemctl start rke2-agent.service
外部 OCI 準拠レジストリ証明書のを管理する
インストール後に外部 OCI 準拠レジストリの証明書を更新するには、次の手順を実行します:
cluster_config.jsonファイルのregistry_ca_certフラグを更新します。詳しくは、「外部の OCI 準拠レジストリの設定」を参照してください。- すべてのノードで次のコマンドを実行して、外部 OCI 準拠レジストリで使用されるルート CA を更新します。
./bin/uipathctl rke2 generate-registries cluster_config.json --current-config-path /etc/rancher/rke2/registries.yaml > /etc/rancher/rke2/registries.yaml.tmp mv -f /etc/rancher/rke2/registries.yaml.tmp /etc/rancher/rke2/registries.yaml systemctl restart rke2-server || systemctl restart rke2-agent./bin/uipathctl rke2 generate-registries cluster_config.json --current-config-path /etc/rancher/rke2/registries.yaml > /etc/rancher/rke2/registries.yaml.tmp mv -f /etc/rancher/rke2/registries.yaml.tmp /etc/rancher/rke2/registries.yaml systemctl restart rke2-server || systemctl restart rke2-agent - 外部 OCI 準拠レジストリの ArgoCD の信頼された CA 証明書を更新します。
./bin/uipathctl config argocd ca-certificates update --cacert [PATH]./bin/uipathctl config argocd ca-certificates update --cacert [PATH]