設定
第1章 MicroShift 設定ファイルの使用 リンクのコピーリンクがクリップボードにコピーされました!
YAML ファイルは、優先設定、設定、およびパラメーターを使用して MicroShift インスタンスをカスタマイズします。
1.1. Red Hat Device Edge の設定 リンクのコピーリンクがクリップボードにコピーされました!
MicroShift と Red Hat Enterprise Linux (RHEL)は連携して、軽量で単一ノードの Kubernetes をエッジに提供します。この組み合わせは、コントロールプレーンとワーカーの両方である単一ノードがあることを意味します。また、オペレーティングシステムが多くの機能を処理することも意味します。オプションの RPM または Operator をインストールして機能を追加します。多くの場合、MicroShift サービスに加えて、オペレーティングシステムまたはその他のリソースを設定する必要があります。
これらの多くの部分を一緒に取り込むことは、MicroShift 設定ファイル config.yaml です。MicroShift 設定ファイルは、アプリケーションプラットフォームをカスタマイズし、多くの高度な機能を有効にできます。以下に例を示します。
- Ingress はデフォルトで利用可能ですが、MicroShift 設定ファイルのパラメーターを使用して、TLS やルート受付仕様などの高度な機能を追加できます。
-
ストレージが必要ない場合は、MicroShift 設定ファイルを使用してビルトインストレージプロバイダーを無効にできます。ビルトインストレージプロバイダーを使用する場合は、
lvmd.configファイルで調整を行う必要があります。この場合の MicroShift 設定ファイルのロールは、デフォルトのストレージプロバイダーを使用するかどうかを設定します。 - 複数ネットワークを使用するなどの高度なネットワーク機能Multus パッケージはインストール可能な RPM ですが、MicroShift 設定ファイルを使用してパラメーターを設定してアクセスを設定します。さらに、ホストを介してネットワーク上のネットワーク設定を設定する必要があります。
便利なように、config.yaml.default ファイルが自動的にインストールされます。このファイル config.yaml をコピーして名前を変更し、これを独自のカスタム設定の開始点として使用できます。
MicroShift config.yaml ファイルに、設定なしで動作する機能を追加することもできます。たとえば、MicroShift を設定せずにアプリケーション管理用に GitOps をインストールおよび設定できます。
kustomize マニフェスト以外のツールを使用し、MicroShift API を介して設定を変更したり、アプリケーションをデプロイしたりする場合は、greenboot ヘルスチェックが完了するまで待つ必要があります。これにより、greenboot が rpm-ostree システムを以前の状態にロールバックしても、変更が失われなくなります。
1.2. MicroShift YAML 設定ファイル リンクのコピーリンクがクリップボードにコピーされました!
起動時に、MicroShift はシステム全体の /etc/microshift/ ディレクトリーで、config.yaml という名前の設定ファイルをチェックします。ディレクトリー内に設定ファイルが存在しない場合は、組み込みのデフォルト値を使用してサービスを起動します。
MicroShift 設定ファイルは、ホストと、場合によってはアプリケーションおよびサービス設定と組み合わせて使用する必要があります。MicroShift クラスターの設定を調整するときは、必要に応じて、必要に応じて各関数を設定してください。
便利なように、入力に使用できる config.yaml.default ファイルが自動的にインストールされます。
1.2.1. デフォルトの設定 リンクのコピーリンクがクリップボードにコピーされました!
config.yaml ファイルを作成しない場合は、デフォルト値が使用されます。次の例は、デフォルトの設定を示しています。
デフォルト値を確認するには、次のコマンドを実行します。
microshift show-config
$ microshift show-configCopy to Clipboard Copied! Toggle word wrap Toggle overflow YAML 形式でのデフォルト値の出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
1.3. カスタム設定の使用 リンクのコピーリンクがクリップボードにコピーされました!
カスタム設定を作成するには、/etc/microshift/ ディレクトリーで提供される config.yaml.default ファイルのコピーを作成し、config.yaml という名前を付けます。このファイルを /etc/microshift/ ディレクトリー保存し、MicroShift を起動または再起動する前に、デフォルトをオーバーライドすることが予想されるサポート対象の設定を変更できます。
設定を変更したら、MicroShift を再起動して有効にします。config.yaml ファイルは、MicroShift の起動時にのみ読み取られます。
1.3.1. 個別の再起動 リンクのコピーリンクがクリップボードにコピーされました!
MicroShift クラスターで使用されるアプリケーションおよびその他のオプションサービスも、クラスター全体で設定の変更を適用するには、個別に再起動する必要がある場合があります。たとえば、特定のネットワーク設定に変更を加える場合は、サービスおよびアプリケーション Pod を停止して再起動し、それらの変更を適用する必要があります。詳細は、完了するタスクのそれぞれの手順を参照してください。
必要な設定をすべて一度に追加すると、システムの再起動を最小限に抑えることができます。
1.3.2. MicroShift config.yaml ファイルのパラメーターと値 リンクのコピーリンクがクリップボードにコピーされました!
次の表は、MicroShift 設定 YAML パラメーターとそれぞれの有効な値を説明しています。
| フィールド | 型 | 説明 |
|---|---|---|
|
|
| API サーバーがクラスターのメンバーにアドバタイズされる IP アドレスを指定する文字列。デフォルト値は、サービスネットワークのアドレスに基づいて計算されます。 |
|
|
|
ログファイルが自動的に削除されるまでの保存期間。 |
|
|
|
デフォルトでは、 |
|
|
| 保存されるログファイルの合計数。デフォルトでは、MicroShift は 10 個のログファイルを保持します。余分なファイルが作成されると、最も古いものが削除されます。この値は設定可能です。 |
|
|
|
読み取りおよび書き込み要求のメタデータのみをログに記録します。OAuth アクセストークン要求を除く要求の本文はログに記録されません。このフィールドを指定しない場合は、 |
|
|
| カスタム認証局を使用して、外部で生成された証明書およびドメイン名を定義します。 |
|
|
| 証明書への完全パス。 |
|
|
| 証明書キーへの完全パス。 |
|
|
| オプション: 明示的な DNS 名のリストを追加します。ワイルドカードは、先頭に指定できます。名前が指定されていない場合は、暗黙名が証明書から抽出されます。 |
|
|
完全修飾ドメイン名 (FQDN)、 | API サーバー証明書のサブジェクト代替名 (SAN)。SAN は、証明書で保護されたすべてのドメイン名および IP アドレスを示します。 |
|
|
|
ログの詳細レベル。デフォルトは |
|
|
| クラスターのベースドメイン。管理されるすべての DNS レコードはこのベースのサブドメインです。 |
|
|
|
デフォルトでは、 |
|
| IP アドレス、NIC 名、またはその複数。 | デフォルト値は、ホストのネットワーク全体になります。有効な設定可能な値は、単一の IP アドレスまたは NIC 名、あるいは複数の IP アドレスと NIC 名のリストです。 |
|
|
|
デフォルトのポートが表示されます。設定可能です。有効な値は、1-65535 の範囲内の単一の一意のポートです。 |
|
|
|
デフォルトのポートが表示されます。設定可能です。有効な値は、1-65535 の範囲内の単一の一意のポートです。 |
|
|
|
複数の namespace のホスト名要求の処理方法を記述します。デフォルトでは、複数の namespace にまたがって、ルートが同じホスト名の異なるパスを要求することを許可します。 |
|
|
|
ルーターのステータス。デフォルトは |
|
| MicroShift の低レイテンシーの手順を参照してください | kubelet ノードエージェントのパススルー設定のパラメーター。低レイテンシー設定に使用されます。デフォルト値は null です。 |
|
|
|
マニフェストをロードするために使用する |
|
| IP アドレスブロック |
Pod IP アドレスの割り当てに使用する IP アドレスのブロック。IPv4 がデフォルトです。デュアルスタックエントリーはサポートされています。このフィールドの最初のエントリーは、MicroShift の起動後は変更できません。デフォルトの範囲は |
|
| IP アドレスブロック |
Kubernetes サービスの仮想 IP アドレスのブロック。サービスの IP アドレスプール。IPv4 がデフォルトです。デュアルスタックエントリーはサポートされています。このフィールドの最初のエントリーは、MicroShift の起動後は変更できません。デフォルトの範囲は |
|
|
|
|
|
|
| ノードの名前。デフォルト値はホスト名です。空でない場合、この文字列はホスト名ではなく、ノードを識別するために使用されます。この値は、MicroShift の起動後は変更できません。 |
|
| IPv4 アドレス | ノードの IPv4 アドレス。デフォルト値は、デフォルトルートの IP アドレスです。 |
|
| IPv6 アドレス | デュアルスタック設定のノードの IPv6 アドレス。IPv4 または IPv6 のいずれかのシングルスタックでは設定できません。デフォルトは空の値または null です。 |
|
|
| デフォルト値は空です。空の値または null フィールドのデフォルトは LVMS デプロイメントです。 |
|
|
|
デフォルト値は null または空の配列です。null または空の配列はデフォルトで |
1.3.3. アドバタイズアドレスネットワークフラグの設定 リンクのコピーリンクがクリップボードにコピーされました!
apiserver.advertiseAddress フラグは、API サーバーをクラスターのメンバーにアドバタイズする IP アドレスを指定します。このアドレスは、クラスターから到達可能である必要があります。ここでカスタム IP アドレスを設定できますが、その IP アドレスをホストインターフェイスに追加する必要もあります。このパラメーターをカスタマイズすると、MicroShift がデフォルトの IP アドレスを br-ex ネットワークインターフェイスに追加しなくなります。
advertiseAddress IP アドレスをカスタマイズする場合は、ホストインターフェイスに IP アドレスを追加して、MicroShift の起動時にクラスターからその IP アドレスに到達できることを確認してください。
設定されていない場合、デフォルト値はサービスネットワークのすぐ後のサブネットに設定されます。たとえば、サービスネットワークが 10.43.0.0/16 の場合、advertiseAddress は、10.44.0.0/32 に設定されます。
1.3.4. NodePort サービスのポート範囲の拡張 リンクのコピーリンクがクリップボードにコピーされました!
serviceNodePortRange 設定では、NodePort サービスで使用できるポート範囲が拡張します。このオプションは、30000-32767 範囲内で特定の標準ポートを公開する必要がある場合に役立ちます。たとえば、クライアントデバイスは別のポートを使用できないため、デバイスはネットワーク上で 1883/tcp MQ Telemetry Transport (MQTT) ポートを公開する必要があります。
NodePort がシステムポートと重複し、システムまたは MicroShift の誤動作を引き起こす可能性があります。
NodePort サービス範囲を設定するときは、次の点を考慮してください。
-
nodePortを明示的に選択せずに NodePort サービスを作成しないでください。明示的なnodePortが指定されていない場合、このポートはkube-apiserverによってランダムに割り当てられるため、予測できません。 -
デバイスの
HostNetworkで公開するシステムサービスポート、MicroShift ポート、またはその他のサービスに対して NodePort サービスを作成しないでください。 表 1 は、ポート範囲の拡張時に避けるべきポートを示しています。
Expand 表1.2 回避するポート ポート 説明 22/tcp
SSH ポート
80/tcp
OpenShift Router HTTP エンドポイント
443/tcp
OpenShift Router HTTPS エンドポイント
1936/tcp
現在公開されていない openshift-router のメトリクスサービス
2379/tcp
etcd ポート
2380/tcp
etcd ポート
6443
kubernetes API
8445/tcp
openshift-route-controller-manager
9537/tcp
cri-o metrics
10250/tcp
kubelet
10248/tcp
kubelet healthz ポート
10259/tcp
kube スケジューラー
第2章 IPv6 シングルまたはデュアルスタックネットワークの設定 リンクのコピーリンクがクリップボードにコピーされました!
シングルスタックまたはデュアルスタックネットワークモードのいずれかで、IPv6 ネットワークプロトコルを使用できます。
2.1. MicroShift を使用した IPv6 ネットワーク リンクのコピーリンクがクリップボードにコピーされました!
MicroShift サービスのデフォルトはクラスター全体の IPv4 アドレスファミリーです。ただし、サポート対象のプラットフォームでは、IPv6 シングルスタックおよび IPv4/IPv6 デュアルスタックネットワークを利用できます。
- MicroShift 設定ファイルで IPv6 の値を設定してサービスを再起動すると、OVN-Kubernetes ネットワークプラグインによって管理される設定が自動的に更新されます。
- デュアルスタックネットワークへの移行後に、新規および既存の Pod の両方でデュアルスタックネットワークが有効化されます。
- コントロールプレーンおよびその他のサービスなど、クラスター全体の IPv6 アクセスが必要な場合は、以下の設定例を使用します。MicroShift Multus Container Network Interface (CNI) プラグインは、Pod の IPv6 を有効化できます。
- デュアルスタックネットワークの場合、各 MicroShift クラスターネットワークとサービスネットワークは、クラスターおよびサービスネットワーク設定パラメーター内で最大 2 つの値をサポートします。
MicroShift を初めて起動する前に IPv6 を計画します。クラスターを異なる IP ファミリー間で切り替えることは、デフォルトのシングルスタックからデュアルスタックネットワーキングに移行する場合を除き、サポートされていません。
IPv6 シングルスタックまたは IPv4/IPv6 デュアルスタックのいずれかのネットワークを設定する場合は、アプリケーション Pod とサービスを再起動する必要があります。再起動しない場合、Pod とサービスはデフォルトの IP ファミリーで設定されたままとなります。
2.2. IPv6 シングルスタックネットワークの設定 リンクのコピーリンクがクリップボードにコピーされました!
MicroShift サービス設定ファイルを更新することで、IPv6 ネットワークプロトコルを使用できます。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 - クラスターへの root アクセス権限がある。
- クラスターが OVN-Kubernetes ネットワークプラグインを使用している。
- ホストには、デフォルトを含む IPv6 アドレスおよび IPv6 ルートがある。
手順
-
/etc/microshift/ディレクトリーにある指定されたconfig.yaml.defaultファイルのコピーを作成し (まだ作成していない場合)、config.yamlという名前を付けます。 新しい MicroShift の
config.yamlを/etc/microshift/ディレクトリーに保持します。config.yamlファイルは、MicroShift サービスが起動するたびに読み取られます。注記これを作成すると、
config.yamlファイルは組み込み設定よりも優先されます。MicroShift YAML の
networkセクションのデフォルト値を、有効な値に置き換えます。シングルスタック IPv6 ネットワーク設定の例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
64未満の CIDR 値でclusterNetworkを指定します。- 2
- 接頭辞が
112である IPv6 CIDR を指定します。Kubernetes は最低レベルの 16 ビットのみを使用します。接頭辞が112の場合、IP アドレスは112から128ビットに割り当てられます。 - 3
- ノード IP アドレスの例。有効な値は、IPv6 アドレスファミリーの IP アドレスです。IPv4 ネットワークも存在する場合に限り、IPv6 アドレスを指定する必要があります。IPv4 ネットワークが存在しない場合、MicroShift サービスは再起動時にこの値を自動的に入力します。
その他の必要な設定を完了してから、次のコマンドを実行して MicroShift を起動します。
sudo systemctl start microshift
$ sudo systemctl start microshiftCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
次のコマンドを実行して、ノードリソースで定義されたネットワークを取得します。
oc get node -o jsonpath='{.items[].spec.podCIDRs[]}'$ oc get node -o jsonpath='{.items[].spec.podCIDRs[]}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
fd01::/48
fd01::/48Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、Pod のステータスを取得します。
oc get pod -A -o wide
$ oc get pod -A -o wideCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、サービスのステータスを取得します。
oc get svc -A
$ oc get svc -ACopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.3. MicroShift 起動前の IPv6 デュアルスタックネットワークの設定 リンクのコピーリンクがクリップボードにコピーされました!
サービスを起動する前に設定ファイルを使用して、IPv4 および IPv6 アドレスファミリーをサポートするデュアルスタックネットワークで実行するように MicroShift クラスターを設定できます。
- 設定の最初の IP ファミリーは、クラスター内のプライマリー IP スタックです。
- クラスターがデュアルスタックネットワークで実行された後に、それらを再起動して、デュアルスタック用のアプリケーション Pod およびアドオンサービスを有効化します。
OVN-Kubernetes ネットワークプラグインでは、IPv4 と IPv6 の両方のデフォルトルートが同じネットワークデバイスに存在する必要があります。別のネットワークデバイス上の IPv4 および IPv6 のデフォルトルートはサポートされていません。
IPv6 を必要とするデュアルスタックネットワークを使用する場合、::FFFF:198.51.100.1 などの IPv4 にマッピングされた IPv6 アドレスは使用できません。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 - クラスターへの root アクセス権限がある。
- クラスターが OVN-Kubernetes ネットワークプラグインを使用している。
- ホストには、それぞれのデフォルトを含む、IPv4 と IPv6 の両方のアドレスとルートがあります。
- ホストには、少なくとも 2 つの L3 ネットワーク (IPv4 と IPv6) があります。
手順
-
/etc/microshift/ディレクトリーにある指定されたconfig.yaml.defaultファイルのコピーを作成し (まだ作成していない場合)、config.yamlという名前を付けます。 新しい MicroShift の
config.yamlを/etc/microshift/ディレクトリーに保持します。config.yamlファイルは、MicroShift サービスが起動するたびに読み取られます。注記これを作成すると、
config.yamlファイルは組み込み設定よりも優先されます。MicroShift を起動していない場合は、MicroShift YAML の
networkセクションのデフォルト値を有効な値に置き換えます。ネットワーク割り当てを使用したデュアルスタック IPv6 ネットワーク設定の例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 必要なその他の MicroShift 設定を完了してから、次のコマンドを実行して MicroShift を起動します。
sudo systemctl start microshift
$ sudo systemctl start microshiftCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 必要に応じてアプリケーション Pod とサービスの IP ファミリーポリシーをリセットし、それらのアプリケーション Pod とサービスを再起動してデュアルスタックネットワークを有効化します。簡単な例は、「アプリケーション Pod およびサービスの IP ファミリーポリシーのリセット」を参照してください。
検証
次の手順に従って、すべてのシステムサービスと Pod に 2 つの IP アドレス (ファミリーごとに 1 つずつ) があることを確認できます。
次のコマンドを実行して、ノードリソースで定義されたネットワークを取得します。
oc get pod -n openshift-ingress router-default-5b75594b4-w7w6s -o jsonpath='{.status.podIPs}'$ oc get pod -n openshift-ingress router-default-5b75594b4-w7w6s -o jsonpath='{.status.podIPs}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
[{"ip":"10.42.0.4"},{"ip":"fd01:0:0:1::4"}][{"ip":"10.42.0.4"},{"ip":"fd01:0:0:1::4"}]Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、ホストネットワーク Pod によって定義されたネットワークを取得します。
oc get pod -n openshift-ovn-kubernetes ovnkube-master-2fm2k -o jsonpath='{.status.podIPs}'$ oc get pod -n openshift-ovn-kubernetes ovnkube-master-2fm2k -o jsonpath='{.status.podIPs}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
[{"ip":"192.168.113.117"},{"ip":"2001:db9:ca7:ff::1db8"}][{"ip":"192.168.113.117"},{"ip":"2001:db9:ca7:ff::1db8"}]Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.4. MicroShift クラスターの IPv6 デュアルスタックネットワークへの移行 リンクのコピーリンクがクリップボードにコピーされました!
MicroShift 設定ファイルのサービスおよびクラスターネットワークパラメーターに 2 つのエントリーを設定することで、シングルスタッククラスターを IPv4 および IPv6 アドレスファミリーをサポートするデュアルスタッククラスターネットワークに変換できます。
- 設定の最初の IP ファミリーは、クラスター内のプライマリー IP スタックです。
- MicroShift システム Pod とサービスは、MicroShift の再起動時に自動的に更新されます。
- クラスターがデュアルスタックネットワークに移行し、再起動したら、それらを再起動して、デュアルスタックネットワーク用のワークロード Pod とサービスを有効化します。
OVN-Kubernetes ネットワークプラグインでは、IPv4 と IPv6 の両方のデフォルトルートが同じネットワークデバイスに存在する必要があります。別のネットワークデバイス上の IPv4 および IPv6 のデフォルトルートはサポートされていません。
IPv6 を必要とするデュアルスタックネットワークを使用する場合、::FFFF:198.51.100.1 などの IPv4 にマッピングされた IPv6 アドレスは使用できません。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 - クラスターへの root アクセス権限がある。
- クラスターが OVN-Kubernetes ネットワークプラグインを使用している。
- ホストには、それぞれのデフォルトを含む、IPv4 と IPv6 の両方のアドレスとルートがあります。
- ホストには、少なくとも 2 つの L3 ネットワーク (IPv4 と IPv6) があります。
手順
-
/etc/microshift/ディレクトリーにある指定されたconfig.yaml.defaultファイルのコピーを作成し (まだ作成していない場合)、config.yamlという名前を付けます。 新しい MicroShift の
config.yamlを/etc/microshift/ディレクトリーに保持します。config.yamlファイルは、MicroShift サービスが起動するたびに読み取られます。注記これを作成すると、
config.yamlファイルは組み込み設定よりも優先されます。有効な値を使用して、MicroShift YAML の
networkセクションに IPv6 設定を追加します。警告再起動と移行後も同じ最初のエントリーを保持する必要があります。これは、シングルスタックからデュアルスタック、またはデュアルスタックからシングルスタックへの移行など、あらゆる移行に当てはまります。最初のエントリーへの変更が必要な場合は、etcd データベースの完全な消去が必要になります。これにより、アプリケーションデータの損失が発生する可能性があり、サポートされていません。
-
有効な値を使用して、MicroShift YAML の
networkセクションにある 2 番目のネットワークの IPv6 設定を追加します。 MicroShift
config.yamlのnetworkセクションにネットワーク割り当てを追加して、IPv6 をセカンダリーネットワークとして使用するデュアルスタックを有効化します。ネットワーク割り当てによるデュアルスタック IPv6 設定の例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- IPv6 ノードアドレス:
- 2
- IPv4 ネットワーク:
24未満の CIDR 値でclusterNetworkを指定します。 - 3
- IPv6 ネットワーク:
64未満の CIDR 値でclusterNetworkを指定します。 - 4
- 接頭辞が
112である IPv6 CIDR を指定します。Kubernetes は最低レベルの 16 ビットのみを使用します。接頭辞が112の場合、IP アドレスは112から128ビットに割り当てられます。 - 5
- ノード IP アドレスの例。以前の IPv4 IP アドレスを維持します。
- 6
- ノード IP アドレスの例。IPv6 アドレスファミリーである必要があります。
-
有効な値を使用して、MicroShift YAML の
必要なその他の設定を完了してから、次のコマンドを実行して MicroShift を再起動します。
sudo systemctl restart microshift
$ sudo systemctl restart microshiftCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 必要に応じてアプリケーション Pod とサービスの IP ファミリーポリシーをリセットし、それらのアプリケーション Pod とサービスを再起動してデュアルスタックネットワークを有効化します。簡単な例は、「アプリケーション Pod およびサービスの IP ファミリーポリシーのリセット」を参照してください。
検証
次の手順に従って、すべてのシステムサービスと Pod に 2 つの IP アドレス (ファミリーごとに 1 つずつ) があることを確認できます。
次のコマンドを実行して、Pod のステータスを取得します。
oc get pod -A -o wide
$ oc get pod -A -o wideCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、OVN-K ネットワークプラグインによって定義されたネットワークを取得します。
oc get pod -n openshift-ovn-kubernetes ovnkube-master-bltk7 -o jsonpath='{.status.podIPs}'$ oc get pod -n openshift-ovn-kubernetes ovnkube-master-bltk7 -o jsonpath='{.status.podIPs}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
[{"ip":"192.168.113.117"},{"ip":"2001:db9:ca7:ff::1db8"}][{"ip":"192.168.113.117"},{"ip":"2001:db9:ca7:ff::1db8"}]Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、ノードリソースで定義されたネットワークを取得します。
oc get pod -n openshift-ingress router-default-5b75594b4-228z7 -o jsonpath='{.status.podIPs}'$ oc get pod -n openshift-ingress router-default-5b75594b4-228z7 -o jsonpath='{.status.podIPs}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
[{"ip":"10.42.0.3"},{"ip":"fd01:0:0:1::3"}][{"ip":"10.42.0.3"},{"ip":"fd01:0:0:1::3"}]Copy to Clipboard Copied! Toggle word wrap Toggle overflow
シングルスタックネットワークに戻すには、ネットワークの 2 番目のエントリーを削除し、デュアルスタックに移行する前に設定されたシングルスタックに戻ることができます。
2.5. アプリケーション Pod およびサービスの IP ファミリーポリシーのリセット リンクのコピーリンクがクリップボードにコピーされました!
デフォルトの ipFamilyPolicy 設定値 PreferSingleStack は、MicroShift 設定をデュアルスタックネットワークに更新した後、すべてのサービスで自動的に更新されません。サービスおよびアプリケーション Pod でデュアルスタックネットワークを有効化するには、ipFamilyPolicy 値を更新する必要があります。
前提条件
-
MicroShift
config.yamlを使用して、IPv6 アドレスファミリーを含むデュアルスタックネットワークを定義している。
手順
以下の例を使用して、
spec.ipFamilyPolicyフィールドをサービスまたは Pod 内のデュアルスタックネットワークの有効な値に設定します。サービスのデュアルスタックネットワーク設定の例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 必須。デュアルスタックネットワークの有効な値は、
PreferDualStackとRequireDualStackです。設定する値は、アプリケーションの要件によって異なります。PreferSingleStackは、ipFamilyPolicyフィールドのデフォルト値です。
-
hostNetworkが定義されていないアプリケーション Pod を再起動します。hostNetworkが定義されている Pod は、ipFamilyPolicy値を更新するために再起動する必要はありません。
ipFamilyPolicy 値が更新されると、MicroShift システムサービスと Pod が自動的に更新されます。
2.6. OVN-Kubernetes IPv6 とデュアルスタックの制限 リンクのコピーリンクがクリップボードにコピーされました!
OVN-Kubernetes ネットワークプラグインには、次の制限があります。
デュアルスタックネットワーク用に設定されたクラスターの場合、IPv4 と IPv6 の両方のトラフィックはデフォルトゲートウェイと同じネットワークインターフェイスを使用する必要があります。
この要件が満たされない場合には、
ovnkube-nodeデーモンセットのホストにある Pod は、CrashLoopBackOff状態になります。oc get pod -n openshift-ovn-kubernetes -l app=ovnkube-node -o yamlなどのコマンドで Pod を表示すると、以下の出力のように、statusフィールドにはデフォルトゲートウェイに関する複数のメッセージが表示されます。I1006 16:09:50.985852 60651 helper_linux.go:73] Found default gateway interface br-ex 192.168.127.1 I1006 16:09:50.985923 60651 helper_linux.go:73] Found default gateway interface ens4 fe80::5054:ff:febe:bcd4 F1006 16:09:50.985939 60651 ovnkube.go:130] multiple gateway interfaces detected: br-ex ens4
I1006 16:09:50.985852 60651 helper_linux.go:73] Found default gateway interface br-ex 192.168.127.1 I1006 16:09:50.985923 60651 helper_linux.go:73] Found default gateway interface ens4 fe80::5054:ff:febe:bcd4 F1006 16:09:50.985939 60651 ovnkube.go:130] multiple gateway interfaces detected: br-ex ens4Copy to Clipboard Copied! Toggle word wrap Toggle overflow 唯一の解決策は、両方の IP ファミリーがデフォルトゲートウェイに同じネットワークインターフェイスを使用するように、ホストネットワークを再設定することです。
デュアルスタックネットワーク用に設定されたクラスターの場合、IPv4 と IPv6 の両方のルーティングテーブルにデフォルトゲートウェイが含まれている必要があります。
この要件が満たされない場合には、
ovnkube-nodeデーモンセットのホストにある Pod は、CrashLoopBackOff状態になります。oc get pod -n openshift-ovn-kubernetes -l app=ovnkube-node -o yamlなどのコマンドで Pod を表示すると、以下の出力のように、statusフィールドにはデフォルトゲートウェイに関する複数のメッセージが表示されます。I0512 19:07:17.589083 108432 helper_linux.go:74] Found default gateway interface br-ex 192.168.123.1 F0512 19:07:17.589141 108432 ovnkube.go:133] failed to get default gateway interface
I0512 19:07:17.589083 108432 helper_linux.go:74] Found default gateway interface br-ex 192.168.123.1 F0512 19:07:17.589141 108432 ovnkube.go:133] failed to get default gateway interfaceCopy to Clipboard Copied! Toggle word wrap Toggle overflow 唯一の解決策として、両方の IP ファミリーにデフォルトゲートウェイが含まれるようにホストネットワークを再設定できます。
-
クラスターの
MachineConfigカスタムリソース (CR) のkernelArgumentセクションでipv6.disableパラメーターを1に設定すると、OVN-Kubernetes Pod がCrashLoopBackOff状態になります。さらに、Network Operator がDegraded状態のままであるため、クラスターを新しいバージョンの Red Hat build of MicroShift に更新すると失敗します。Red Hat はクラスターの IPv6 アドレスの無効化をサポートしていないため、ipv6.disableパラメーターを1に設定しないでください。
第3章 kubeconfig を使用したクラスターアクセス リンクのコピーリンクがクリップボードにコピーされました!
MicroShift デプロイメントで kubeconfig ファイルがどのように使用されるかを説明します。CLI ツールは、kubeconfig ファイルを使用してクラスターの API サーバーと通信します。これらのファイルには、クラスターの詳細、IP アドレス、および認証に必要なその他の情報が含まれています。
3.1. クラスターアクセスを設定するための Kubeconfig ファイル リンクのコピーリンクがクリップボードにコピーされました!
MicroShift で使用される kubeconfig ファイルの 2 つのカテゴリーは、ローカルアクセスとリモートアクセスです。MicroShift が起動するたびに、API サーバーへのローカルおよびリモートアクセスのための kubeconfig ファイルのセットが生成されます。これらのファイルは、既存の設定情報を使用して /var/lib/microshift/resources/kubeadmin/ ディレクトリーに生成されます。
各アクセスタイプには、異なる認証局 (CA) によって署名された異なる認証証明書が必要です。複数の kubeconfig ファイルを生成することで、このニーズに対応できます。
それぞれの場合に必要なアクセスタイプに適切な kubeconfig ファイルを使用して、認証の詳細を提供できます。MicroShift kubeconfig ファイルの内容は、デフォルトの組み込み値または config.yaml ファイルによって決まります。
クラスターにアクセスするには、kubeconfig ファイルが存在する必要があります。値は、組み込みのデフォルト値、または config.yaml (作成されている場合) から適用されます。
kubeconfig ファイルの内容の例
3.2. ローカルアクセスの kubeconfig ファイル リンクのコピーリンクがクリップボードにコピーされました!
ローカルアクセスの kubeconfig ファイルは /var/lib/microshift/resources/kubeadmin/kubeconfig に書き込まれます。この kubeconfig ファイルは、localhost を使用した API サーバーへのアクセスを提供します。クラスターをローカルに接続する場合は、このファイルを選択します。
ローカルアクセス用の kubeconfig の内容例
clusters:
- cluster:
certificate-authority-data: <base64 CA>
server: https://localhost:6443
clusters:
- cluster:
certificate-authority-data: <base64 CA>
server: https://localhost:6443
localhost の kubeconfig ファイルは、同じホストから API サーバーに接続するクライアントからのみ使用できます。ファイル内の証明書はリモート接続では機能しません。
3.2.1. MicroShift クラスターへのローカルアクセス リンクのコピーリンクがクリップボードにコピーされました!
以下の手順に従って、kubeconfig ファイルを使用して MicroShift クラスターをローカルでアクセスします。
前提条件
-
ocバイナリーがインストールされている。
手順
オプション: Red Hat Enterprise Linux (RHEL) マシンに
~/.kube/フォルダーがない場合は、次のコマンドを実行してフォルダーを作成します。mkdir -p ~/.kube/
$ mkdir -p ~/.kube/Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、生成されたローカルアクセス
kubeconfigファイルを~/.kube/ディレクトリーにコピーします。sudo cat /var/lib/microshift/resources/kubeadmin/kubeconfig > ~/.kube/config
$ sudo cat /var/lib/microshift/resources/kubeadmin/kubeconfig > ~/.kube/configCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、
~/.kube/configファイルの権限を更新します。chmod go-r ~/.kube/config
$ chmod go-r ~/.kube/configCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
次のコマンドを入力して、MicroShift が実行されていることを確認します。
oc get all -A
$ oc get all -ACopy to Clipboard Copied! Toggle word wrap Toggle overflow
3.3. リモートアクセスの kubeconfig ファイル リンクのコピーリンクがクリップボードにコピーされました!
MicroShift クラスターが外部ソースから API サーバーに接続する場合は、SAN フィールド内のすべての代替名を持つ証明書が検証に使用されます。MicroShift は、hostname 値を使用して外部アクセス用のデフォルトの kubeconfig を生成します。デフォルトは、デフォルトの kubeconfig ファイルの <node.hostnameOverride>、<node.nodeIP>、および api.<dns.baseDomain> パラメーター値に設定されます。
/var/lib/microshift/resources/kubeadmin/<hostname>/kubeconfig ファイルは、マシンの hostname、またはオプションが設定されている場合は node.hostnameOverride を使用して、API サーバーにアクセスします。kubeconfig ファイルの CA は、外部からアクセスされたときに証明書を検証できます。
リモートアクセス用の kubeconfig デフォルトファイルの内容例
clusters:
- cluster:
certificate-authority-data: <base64 CA>
server: https://microshift-rhel9:6443
clusters:
- cluster:
certificate-authority-data: <base64 CA>
server: https://microshift-rhel9:6443
3.3.1. リモートアクセスのカスタマイズ リンクのコピーリンクがクリップボードにコピーされました!
異なる IP アドレスまたはホスト名でクラスターにアクセスするために、複数のリモートアクセス kubeconfig ファイル値を生成できます。apiServer.subjectAltNames パラメーターのエントリーごとに追加の kubeconfig ファイルが生成されます。IP 接続中にホストからリモートアクセス kubeconfig ファイルをコピーし、それを使用して他のワークステーションから API サーバーにアクセスできます。
3.4. リモートアクセス用の追加の kubeconfig ファイルの生成 リンクのコピーリンクがクリップボードにコピーされました!
デフォルトのリモートアクセスファイルが提供するものより多くのホスト名または IP アドレスが必要な場合は、追加の kubeconfig ファイルを生成して使用できます。
設定の変更を実装するには、MicroShift を再起動する必要があります。
前提条件
-
MicroShift の
config.yamlが作成されている。
手順
オプション:
config.yamlの内容を表示できます。以下のコマンドを実行します。cat /etc/microshift/config.yaml
$ cat /etc/microshift/config.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow オプション: リモートアクセス
kubeconfigファイルの内容を表示できます。以下のコマンドを実行します。cat /var/lib/microshift/resources/kubeadmin/<hostname>/kubeconfig
$ cat /var/lib/microshift/resources/kubeadmin/<hostname>/kubeconfigCopy to Clipboard Copied! Toggle word wrap Toggle overflow 重要追加のリモートアクセス
kubeconfigファイルには、Red Hat build of MicroShiftconfig.yamlファイルにリストされているサーバー名のいずれかを含める必要があります。追加のkubeconfigファイルも検証に同じ CA を使用する必要があります。追加の DNS 名、SAN、または外部 IP アドレス用に追加の
kubeconfigファイルを生成するには、必要なエントリーをapiServer.subjectAltNamesフィールドに追加します。次の例では、使用される DNS 名はalt-name-1、IP アドレスは1.2.3.4です。追加の認証値を含む
config.yamlの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow MicroShift を再起動して設定の変更を適用し、次のコマンドを実行して必要な
kubeconfigファイルを自動生成します。sudo systemctl restart microshift
$ sudo systemctl restart microshiftCopy to Clipboard Copied! Toggle word wrap Toggle overflow 追加のリモートアクセス
kubeconfigファイルの内容を確認するには、config.yamlにリストされている名前または IP アドレスをcatコマンドに挿入します。たとえば、次のコマンド例ではalt-name-1が使用されています。cat /var/lib/microshift/resources/kubeadmin/alt-name-1/kubeconfig
$ cat /var/lib/microshift/resources/kubeadmin/alt-name-1/kubeconfigCopy to Clipboard Copied! Toggle word wrap Toggle overflow クラスターの接続に使用する SAN または IP アドレスを含む、使用する
kubeconfigファイルを選択します。この例では、cluster.serverフィールドに `alt-name-1` を含むkubeconfigが正しいファイルです。追加の
kubeconfigファイルの内容の例clusters: - cluster: certificate-authority-data: <base64 CA> server: https://alt-name-1:6443clusters: - cluster: certificate-authority-data: <base64 CA> server: https://alt-name-1:64431 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
/var/lib/microshift/resources/kubeadmin/alt-name-1/kubeconfigファイルの値は、apiServer.subjectAltNames設定値からのものです。
これらのパラメーターはすべて、API サーバーの外部提供証明書に共通名 (CN) およびサブジェクト代替名 (SAN) として含まれています。
3.4.1. MicroShift クラスターへのリモートアクセス用にファイアウォールを開く リンクのコピーリンクがクリップボードにコピーされました!
リモートユーザーが MicroShift クラスターにアクセスできるように、次の手順を使用してファイアウォールを開きます。この手順は、ワークステーションユーザーがリモートでクラスターにアクセスする前に完了する必要があります。
この手順では、user@microshift は、MicroShift ホストマシン上のユーザーであり、別のワークステーション上のリモートユーザーがアクセスできるようにそのマシンをセットアップする責任があります。
前提条件
-
ocバイナリーがインストールされている。 - クラスター管理者の権限がある。
手順
MicroShift ホストの
user@microshiftとして、次のコマンドを実行して、Kubernetes API サーバー (6443/tcp) のファイアウォールポートを開きます。sudo firewall-cmd --permanent --zone=public --add-port=6443/tcp && sudo firewall-cmd --reload
[user@microshift]$ sudo firewall-cmd --permanent --zone=public --add-port=6443/tcp && sudo firewall-cmd --reloadCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
user@microshiftとして次のコマンドを実行して、MicroShift が入力されていることを確認します。oc get all -A
[user@microshift]$ oc get all -ACopy to Clipboard Copied! Toggle word wrap Toggle overflow
3.4.2. MicroShift クラスターへのリモートアクセス リンクのコピーリンクがクリップボードにコピーされました!
以下の手順に従って、kubeconfig ファイルを使用してリモートロケーションから MicroShift クラスターにアクセスします。
user@workstation ログインは、ホストマシンにリモートからアクセスするのに使用されます。手順の <user> 値は、user@workstation が MicroShift ホストにログインするユーザーの名前になります。
前提条件
-
ocバイナリーがインストールされている。 -
user@microshiftは、ローカルホストからファイアウォールを開いている。
手順
user@workstationとして、Red Hat Enterprise Linux (RHEL) マシンに~/.kube/フォルダーがない場合は、次のコマンドを実行してフォルダーを作成します。mkdir -p ~/.kube/
[user@workstation]$ mkdir -p ~/.kube/Copy to Clipboard Copied! Toggle word wrap Toggle overflow user@workstationとして、次のコマンドを実行して、MicroShift ホストのホスト名の変数を設定します。MICROSHIFT_MACHINE=<name or IP address of MicroShift machine>
[user@workstation]$ MICROSHIFT_MACHINE=<name or IP address of MicroShift machine>Copy to Clipboard Copied! Toggle word wrap Toggle overflow user@workstationとして、次のコマンドを実行して、MicroShift を実行している RHEL マシンからローカルマシンに接続するホスト名または IP アドレスを含む生成されたkubeconfigファイルをコピーします。ssh <user>@$MICROSHIFT_MACHINE "sudo cat /var/lib/microshift/resources/kubeadmin/$MICROSHIFT_MACHINE/kubeconfig" > ~/.kube/config
[user@workstation]$ ssh <user>@$MICROSHIFT_MACHINE "sudo cat /var/lib/microshift/resources/kubeadmin/$MICROSHIFT_MACHINE/kubeconfig" > ~/.kube/configCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注記この手順の
kubeconfigファイルを生成するには、リモートアクセス用の kubeconfig ファイルの追加生成 を参照してください。user@workstationとして、次のコマンドを実行して~/.kube/configファイルのパーミッションを更新します。chmod go-r ~/.kube/config
$ chmod go-r ~/.kube/configCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
user@workstationとして、次のコマンドを入力して、MicroShift が実行されていることを確認します。oc get all -A
[user@workstation]$ oc get all -ACopy to Clipboard Copied! Toggle word wrap Toggle overflow
第4章 カスタム認証局の設定 リンクのコピーリンクがクリップボードにコピーされました!
MicroShift サービスでは、カスタム証明局 (CA) を使用して接続を暗号化できます。
4.1. MicroShift でのカスタム認証局の仕組み リンクのコピーリンクがクリップボードにコピーされました!
デフォルトの API サーバー証明書は、内部の MicroShift クラスター認証局 (CA) によって発行されます。デフォルトでは、クラスター外部のクライアントは API サーバー証明書を検証できません。この証明書は、クライアントが信頼するカスタム CA によって外部的に発行されたカスタムサーバー証明書に置き換えることができます。次の手順は、MicroShift のワークフローを示しています。
- 証明書とキーをホストオペレーティングシステムの優先ディレクトリーにコピーします。ファイルに root のみがアクセスできることを確認してください。
MicroShift
/etc/microshift/config.yaml設定ファイルで証明書名と新しい完全修飾ドメイン名 (FQDN) を指定して、各カスタム CA の MicroShift 設定を更新します。各証明書設定には、以下の値を含めることができます。
- 証明書ファイルの場所は必須の値です。
API サーバーの DNS と IP アドレスまたは IP アドレス範囲を含む単一の共通名。
ヒントほとんどの場合、MicroShift は、指定した IP アドレスまたは範囲を含むカスタム CA の新しい
kubeconfigを生成します。例外は、IP アドレスにワイルドカードが指定されている場合です。この場合、MicroShift はサーバーのパブリック IP アドレスを使用してkubeconfigを生成します。ワイルドカードを使用するには、特定の詳細でkubeconfigファイルを更新する必要があります。- API サーバーの DNS と IP アドレス、またはワイルドカード証明書を含む複数のサブジェクト別名 (SAN)。
- 各証明書に追加の DNS 名を指定できます。
-
MicroShift サービスが再起動した後、生成された
kubeconfigファイルをクライアントにコピーする必要があります。 - クライアントシステムで追加の CA を設定します。たとえば、Red Hat Enterprise Linux (RHEL) トラストストア内の CA バンドルを更新できます。
- 証明書と鍵は、ホスト上の指定されたファイルの場所から読み取られます。設定のテストおよび検証はクライアントから行われます。
- 外部サーバー証明書は自動的に更新されません。外部証明書を手動でローテーションする必要があります。
検証に失敗した場合、MicroShift サービスはカスタム設定をスキップし、デフォルトの証明書を使用して起動します。サービスを中断せずに継続することが最優先事項です。MicroShift は、サービスの開始時にエラーを記録します。一般的なエラーには、証明書の期限切れ、ファイルの欠落、IP アドレスの誤りなどがあります。
カスタムサーバー証明書は、ホストオペレーティングシステムの信頼ルートに設定された CA データに対して検証する必要があります。詳細は、システム全体のトラストストア を参照してください。
4.2. カスタム認証局の設定 リンクのコピーリンクがクリップボードにコピーされました!
カスタム証明局 (CA) を使用して外部で生成された証明書とドメイン名を設定するには、それらを MicroShift の /etc/microshift/config.yaml 設定ファイルに追加します。ホストオペレーティングシステムの信頼ルートも設定する必要があります。
外部で生成された kubeconfig ファイルは /var/lib/microshift/resources/kubeadmin/<hostname>/kubeconfig ディレクトリーに作成されます。外部で生成された設定に加えて localhost を使用する必要がある場合は、元の kubeconfig ファイルをデフォルトの場所に保持します。localhost kubeconfig ファイルは、自己署名認証局を使用します。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 - クラスター管理者のロールを持つユーザーとしてクラスターにアクセスできる。
- 認証局がカスタム証明書を発行している。
-
MicroShift の
/etc/microshift/config.yaml設定ファイルが存在する。
手順
- 追加するカスタム証明書を MicroShift ホストの信頼ルートにコピーします。証明書と秘密鍵に MicroShift のみがアクセス可能であることを確認します。
必要なカスタム CA ごとに、次の例を使用して、
namedCertificatesというapiServerセクションを/etc/microshift/config.yamlMicroShift 設定ファイルに追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、MicroShift を再起動し、証明書を適用します。
systemctl microshift restart
$ systemctl microshift restartCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
システムが再起動してカスタムサーバーが適用されるまで数分間待ちます。新しい
kubeconfigファイルは/var/lib/microshift/resources/kubeadmin/ディレクトリーに生成されます。 -
kubeconfigファイルをクライアントにコピーします。IP アドレスにワイルドカードを指定した場合は、kubeconfigを更新してサーバーのパブリック IP アドレスを削除し、その IP アドレスを使用する特定のワイルドカード範囲に置き換えます。 クライアントからは、次の手順を実行します。
次のコマンドを実行して、使用する
kubeconfigを指定します。export KUBECONFIG=~/custom-kubeconfigs/kubeconfig
$ export KUBECONFIG=~/custom-kubeconfigs/kubeconfig1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- コピーした
kubeconfigファイルの場所をパスとして使用します。
次のコマンドを使用して、証明書が適用されていることを確認します。
oc --certificate-authority ~/certs/ca.ca get node
$ oc --certificate-authority ~/certs/ca.ca get nodeCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
oc get node NAME STATUS ROLES AGE VERSION dhcp-1-235-195.arm.example.com Ready control-plane,master,worker 76m v1.30.3
oc get node NAME STATUS ROLES AGE VERSION dhcp-1-235-195.arm.example.com Ready control-plane,master,worker 76m v1.30.3Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、新しい CA ファイルを $KUBECONFIG 環境変数に追加します。
oc config set clusters.microshift.certificate-authority /tmp/certificate-authority-data-new.crt
$ oc config set clusters.microshift.certificate-authority /tmp/certificate-authority-data-new.crtCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、新しい
kubeconfigファイルに新しい CA が含まれていることを確認します。oc config view --flatten
$ oc config view --flattenCopy to Clipboard Copied! Toggle word wrap Toggle overflow 外部で生成された
kubeconfigファイルの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 外部で生成された
kubeconfigファイルには、certificate-authority-dataセクションが存在しません。これは、以前使用したoc config setコマンドで追加されます。
次のコマンドを実行して、カスタマイズされた API サーバー認証局の
subjectとissuerを確認します。curl --cacert /tmp/caCert.pem https://${fqdn_name}:6443/healthz -v$ curl --cacert /tmp/caCert.pem https://${fqdn_name}:6443/healthz -vCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 重要生成された
kubeconfigファイル内のcertificate-authority-dataを新しいrootCAに置き換えるか、certificate-authority-dataをオペレーティングシステムの信頼ルートに追加します。両方の方法を使用しないでください。オペレーティングシステムの信頼ルートで追加の CA を設定します。たとえば、クライアントシステム上の RHEL クライアントトラストストア内などです。詳細は、システム全体のトラストストア を参照してください。
- CA を含む設定で証明書バンドルを更新することを推奨します。
-
証明書バンドルを設定しない場合は、代わりに
oc login localhost:8443 --certificate-authority=/path/to/cert.crtコマンドを使用することもできますが、この方法は推奨されません。
4.3. カスタム証明書の予約名の値 リンクのコピーリンクがクリップボードにコピーされました!
次の証明書の問題により、MicroShift は証明書を動的に無視し、エラーをログに記録します。
- 証明書ファイルがディスク上に存在しないか、読み取り可能ではありません。
- 証明書は解析できません。
-
証明書は、
SubjectAlternativeNames(SAN) フィールドの内部証明書の IP アドレスまたは DNS 名をオーバーライドします。SAN を設定するときは予約名を使用しないでください。
| アドレス | 型 | コメント |
|---|---|---|
|
| DNS | |
|
| IP Address | |
|
| IP Address | クラスターネットワーク |
|
| IP Address | サービスネットワーク |
| 169.254.169.2/29 | IP Address | br-ex ネットワーク |
|
| DNS | |
|
| DNS | |
|
| DNS |
4.4. カスタム証明書のトラブルシューティング リンクのコピーリンクがクリップボードにコピーされました!
カスタム証明書の実装のトラブルシューティングを行うには、次の手順を実行します。
手順
MicroShift から、次のコマンドを実行して、証明書が
kube-apiserverによって提供されていることを確認し、証明書パスが--tls-sni-cert-keyフラグに追加されていることを確認します。journalctl -u microshift -b0 | grep tls-sni-cert-key
$ journalctl -u microshift -b0 | grep tls-sni-cert-keyCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Jan 24 14:53:00 localhost.localdomain microshift[45313]: kube-apiserver I0124 14:53:00.649099 45313 flags.go:64] FLAG: --tls-sni-cert-key="[/home/eslutsky/dev/certs/server.crt,/home/eslutsky/dev/certs/server.key;/var/lib/microshift/certs/kube-apiserver-external-signer/kube-external-serving/server.crt,/var/lib/microshift/certs/kube-apiserver-external-signer/kube-external-serving/server.key;/var/lib/microshift/certs/kube-apiserver-localhost-signer/kube-apiserver-localhost-serving/server.crt,/var/lib/microshift/certs/kube-apiserver-localhost-signer/kube-apiserver-localhost-serving/server.key;/var/lib/microshift/certs/kube-apiserver-service-network-signer/kube-apiserver-service-network-serving/server.crt,/var/lib/microshift/certs/kube-apiserver-service-network-signer/kube-apiserver-service-network-serving/server.key
Jan 24 14:53:00 localhost.localdomain microshift[45313]: kube-apiserver I0124 14:53:00.649099 45313 flags.go:64] FLAG: --tls-sni-cert-key="[/home/eslutsky/dev/certs/server.crt,/home/eslutsky/dev/certs/server.key;/var/lib/microshift/certs/kube-apiserver-external-signer/kube-external-serving/server.crt,/var/lib/microshift/certs/kube-apiserver-external-signer/kube-external-serving/server.key;/var/lib/microshift/certs/kube-apiserver-localhost-signer/kube-apiserver-localhost-serving/server.crt,/var/lib/microshift/certs/kube-apiserver-localhost-signer/kube-apiserver-localhost-serving/server.key;/var/lib/microshift/certs/kube-apiserver-service-network-signer/kube-apiserver-service-network-serving/server.crt,/var/lib/microshift/certs/kube-apiserver-service-network-signer/kube-apiserver-service-network-serving/server.keyCopy to Clipboard Copied! Toggle word wrap Toggle overflow クライアントから次のコマンドを実行して、
kube-apiserverが正しい証明書を提供していることを確認します。openssl s_client -connect <SNI_ADDRESS>:6443 -showcerts | openssl x509 -text -noout -in - | grep -C 1 "Alternative\|CN"
$ openssl s_client -connect <SNI_ADDRESS>:6443 -showcerts | openssl x509 -text -noout -in - | grep -C 1 "Alternative\|CN"Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.5. カスタム証明書のクリーンアップおよび再作成 リンクのコピーリンクがクリップボードにコピーされました!
MicroShift サービスを停止するには、カスタム証明書をクリーンアップし、カスタム証明書を再作成するには、次の手順を使用します。
手順
次のコマンドを実行して、MicroShift サービスを停止し、カスタム証明書をクリーンアップします。
sudo microshift-cleanup-data --cert
$ sudo microshift-cleanup-data --certCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Stopping MicroShift services Removing MicroShift certificates MicroShift service was stopped Cleanup succeeded
Stopping MicroShift services Removing MicroShift certificates MicroShift service was stopped Cleanup succeededCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、MicroShift サービスを再起動し、カスタム証明書を再作成します。
sudo systemctl start microshift
$ sudo systemctl start microshiftCopy to Clipboard Copied! Toggle word wrap Toggle overflow
4.6. 関連情報 リンクのコピーリンクがクリップボードにコピーされました!
第5章 greenboot スクリプトのステータスの確認 リンクのコピーリンクがクリップボードにコピーされました!
kustomize マニフェスト以外のツールを使用して MicroShift API を通じてアプリケーションをデプロイしたり、その他の変更を加えたりするには、greenboot ヘルスチェックが完了するまで待つ必要があります。これにより、greenboot が rpm-ostree システムを以前の状態にロールバックしても、変更が失われなくなります。
greenboot-healthcheck サービスは 1 回実行してから終了します。greenboot が終了し、システムが正常な状態になったら、設定の変更とデプロイメントを続行できます。
5.1. greenboot ヘルスチェックのステータスの確認 リンクのコピーリンクがクリップボードにコピーされました!
システムに変更を加える前、またはトラブルシューティング中に、greenboot ヘルスチェックのステータスを確認します。次のコマンドのいずれかを使用すると、greenboot スクリプトの実行が完了したことを確認できます。
手順
ヘルスチェックステータスのレポートを表示するには、次のコマンドを使用します。
systemctl show --property=SubState --value greenboot-healthcheck.service
$ systemctl show --property=SubState --value greenboot-healthcheck.serviceCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
startが出力される場合、greenboot チェックがまだ実行中であることを意味します。 -
exitedが出力される場合、チェックが合格し、greenboot が終了したことを意味します。Greenboot は、システムが正常な状態の場合、green.dディレクトリー内のスクリプトを実行します。 -
failedの出力は、チェックが合格しなかったことを意味します。システムがこの状態にある場合、Greenboot はred.dディレクトリー内のスクリプトを実行し、システムを再起動する可能性があります。
-
サービスの数値終了コードを示すレポートを表示するには、次のコマンドを使用します。
0は成功を、0 以外の値は失敗を意味します。systemctl show --property=ExecMainStatus --value greenboot-healthcheck.service
$ systemctl show --property=ExecMainStatus --value greenboot-healthcheck.serviceCopy to Clipboard Copied! Toggle word wrap Toggle overflow Boot Status is GREEN - Health Check SUCCESSなど、ブートステータスに関するメッセージを表示するレポートを表示するには、次のコマンドを使用します。cat /run/motd.d/boot-status
$ cat /run/motd.d/boot-statusCopy to Clipboard Copied! Toggle word wrap Toggle overflow
第6章 監査ロギングポリシーの設定 リンクのコピーリンクがクリップボードにコピーされました!
設定値を使用して、MicroShift 監査ログファイルのローテーションと保持を制御できます。
6.1. 監査ログファイルの制限設定について リンクのコピーリンクがクリップボードにコピーされました!
設定値を使用して MicroShift 監査ログファイルのローテーションと保持を制御すると、ファーエッジデバイスの限られたストレージ容量を超えないようにすることができます。このようなデバイスでは、ログデータの蓄積によってホストシステムまたはクラスターのワークロードが制限され、デバイスの動作が停止する可能性があります。監査ログポリシーを設定すると、重要な処理スペースを継続して利用できるようにします。
MicroShift 監査ログを制限するために設定した値を使用すると、監査ログバックアップのサイズ、数、保存期間の制限を適用できます。フィールド値は、優先順位を付けずに、互いに独立して処理されます。
フィールドを組み合わせて設定し、保持されるログの最大ストレージ制限を定義できます。以下に例を示します。
-
ログストレージの上限を作成するには、
maxFileSizeとmaxFilesの両方を設定します。 -
maxFileAge値を設定すると、maxFiles値に関係なく、ファイル名のタイムスタンプより古いファイルが自動的に削除されます。
6.1.1. デフォルトの監査ログ値 リンクのコピーリンクがクリップボードにコピーされました!
MicroShift には、次のデフォルトの監査ログローテーション値が含まれています。
| 監査ログパラメーター | デフォルト設定 | 定義 |
|---|---|---|
|
|
| ログファイルが自動的に削除されるまでの保持期間。デフォルト値は、経過時間をベースにしてログファイルが削除されないという意味です。この値は設定可能です。 |
|
|
| 保持されるログファイルの合計数。デフォルトでは、MicroShift は 10 個のログファイルを保持します。余分なファイルが作成されると、最も古いものが削除されます。この値は設定可能です。 |
|
|
|
デフォルトでは、 |
|
|
|
|
ファイルが 10 個以下の場合、監査ログの保持の最大デフォルトストレージ使用量は 2000 Mb です。
フィールドに値を指定しない場合は、デフォルト値が使用されます。以前に設定したフィールド値を削除すると、次回の MicroShift サービスの再起動後にデフォルト値が復元されます。
アプリケーション Pod によって生成されるログは、Red Hat Enterprise Linux (RHEL) で監査ログの保持およびローテーションを設定する必要があります。これらのログはコンソールに出力され、保存されます。MicroShift クラスターの健全性を維持するために、RHEL /var/log/audit/audit.log ファイルにログ設定が設定されていることを確認してください。
関連情報
- 環境を保護するための auditd の設定
- Audit ログファイルについて
- How to use logrotate utility to rotate log files (2024 年 8 月 7 日付けのソリューション記事)
6.2. 監査ログポリシープロファイルについて リンクのコピーリンクがクリップボードにコピーされました!
監査ログプロファイルは、OpenShift API サーバーおよび Kubernetes API サーバーに送信されるリクエストをログに記録する方法を定義します。
MicroShift は、次の定義済み監査ポリシープロファイルをサポートしています。
| Profile | 説明 |
|---|---|
|
| 読み取りおよび書き込み要求のメタデータのみをログに記録します。OAuth アクセストークン要求を除く要求の本文はログに記録されません。これはデフォルトポリシーになります。 |
|
|
すべてのリクエストのメタデータのログに加えて、API サーバーへのすべての書き込みリクエスト ( |
|
|
すべての要求のメタデータをロギングする以外にも、API サーバーへの読み取りおよび書き込み要求ごとに要求の本文をログに記録します ( |
|
| OAuth アクセストークン要求や OAuth 承認トークン要求などの要求はログに記録されません。 警告
問題のトラブルシューティング時に有用なデータが記録されないリスクを完全に理解していない限り、 |
-
Secret、Route、OAuthClientオブジェクトなどの機密リソースは、メタデータレベルでのみログ記録されます。
デフォルトでは、MicroShift は Default の監査ログプロファイルを使用します。リクエスト本文もログに記録する別の監査ポリシープロファイルを使用することもできますが、CPU、メモリー、I/O などのリソース使用量が増加することに注意してください。
6.3. 監査ログ値の設定 リンクのコピーリンクがクリップボードにコピーされました!
MicroShift サービス設定ファイルを使用して、監査ログ設定を指定できます。
手順
-
指定されている
config.yaml.defaultファイルのコピーを/etc/microshift/ディレクトリーに作成し、名前をconfig.yamlに変更します。作成した新しい MicroShiftconfig.yamlを/etc/microshift/ディレクトリーに保存します。MicroShift サービスが開始されるたびに、新しいconfig.yamlが読み取られます。これを作成すると、config.yamlファイルは組み込み設定よりも優先されます。 YAML の
auditLogセクションのデフォルト値を必要な有効な値に置き換えてください。デフォルトの
auditLog設定の例Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- ログファイルが保持される最大時間を日数で指定します。この制限よりも古いファイルは削除されます。この例では、ログファイルは 7 日以上経過すると削除されます。ライブログが
maxFileSizeフィールドで指定された最大ファイルサイズに達したかどうかに関係なく、ファイルは削除されます。ファイルの有効期限は、ローテーションされたログファイルの名前に書き込まれたタイムスタンプによって決定されます (例:audit-2024-05-16T17-03-59.994.log))。値が0の場合、制限は無効になります。 - 2
- 監査ログファイルの最大サイズ (メガバイト単位)。この例では、ライブログが 200 MB の制限に達するとすぐにファイルがローテーションされます。値を
0に設定すると、制限は無効になります。 - 3
- 保持されるローテーションされた監査ログファイルの最大数。制限に達すると、ログファイルは古いものから順に削除されます。この例では、値
1を指定すると、現在のアクティブログに加えて、maxFileSizeサイズのファイル 1 つだけが保持されます。値を0に設定すると、制限は無効になります。 - 4
- 読み取りおよび書き込み要求のメタデータのみをログに記録します。OAuth アクセストークン要求を除く要求の本文はログに記録されません。このフィールドを指定しない場合は、
Defaultプロファイルが使用されます。
オプション: ログ用の新しいディレクトリーを指定するには、MicroShift を停止し、
/var/log/kube-apiserverディレクトリーを目的の場所に移動します。次のコマンドを実行して MicroShift を停止します。
sudo systemctl stop microshift
$ sudo systemctl stop microshiftCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行して、
/var/log/kube-apiserverディレクトリーを目的の場所に移動します。sudo mv /var/log/kube-apiserver <~/kube-apiserver>
$ sudo mv /var/log/kube-apiserver <~/kube-apiserver>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<~/kube-apiserver>は、使用するディレクトリーへのパスに置き換えます。
ログの新規ディレクトリーを指定した場合、次のコマンドを実行して、
/var/log/kube-apiserverにカスタムディレクトリーへのシンボリックリンクを作成します。sudo ln -s <~/kube-apiserver> /var/log/kube-apiserver
$ sudo ln -s <~/kube-apiserver> /var/log/kube-apiserver1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<~/kube-apiserver>は、使用するディレクトリーへのパスに置き換えます。これにより、SOS レポートでのログの収集が可能になります。
実行中のインスタンスで監査ログポリシーを設定する場合は、次のコマンドを入力して MicroShift を再起動します。
sudo systemctl restart microshift
$ sudo systemctl restart microshiftCopy to Clipboard Copied! Toggle word wrap Toggle overflow
6.4. 監査ログ設定のトラブルシューティング リンクのコピーリンクがクリップボードにコピーされました!
カスタム監査ログ設定とファイルの場所のトラブルシューティングを行うには、次の手順に従います。
手順
次のコマンドを実行して、現在設定されている値を確認します。
sudo microshift show-config --mode effective
$ sudo microshift show-config --mode effectiveCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
auditLog: maxFileSize: 200 maxFiles: 1 maxFileAge: 7 profile: AllRequestBodiesauditLog: maxFileSize: 200 maxFiles: 1 maxFileAge: 7 profile: AllRequestBodiesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、
audit.logファイルのパーミッションを確認します。sudo ls -ltrh /var/log/kube-apiserver/audit.log
$ sudo ls -ltrh /var/log/kube-apiserver/audit.logCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
-rw-------. 1 root root 46M Mar 12 09:52 /var/log/kube-apiserver/audit.log
-rw-------. 1 root root 46M Mar 12 09:52 /var/log/kube-apiserver/audit.logCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、現在のログディレクトリーの内容をリスト表示します。
sudo ls -ltrh /var/log/kube-apiserver/
$ sudo ls -ltrh /var/log/kube-apiserver/Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
total 6.0M -rw-------. 1 root root 2.0M Mar 12 10:56 audit-2024-03-12T14-56-16.267.log -rw-------. 1 root root 2.0M Mar 12 10:56 audit-2024-03-12T14-56-49.444.log -rw-------. 1 root root 962K Mar 12 10:57 audit.log
total 6.0M -rw-------. 1 root root 2.0M Mar 12 10:56 audit-2024-03-12T14-56-16.267.log -rw-------. 1 root root 2.0M Mar 12 10:56 audit-2024-03-12T14-56-49.444.log -rw-------. 1 root root 962K Mar 12 10:57 audit.logCopy to Clipboard Copied! Toggle word wrap Toggle overflow
第7章 LVMS CSI プロバイダーまたは CSI スナップショットの無効化 リンクのコピーリンクがクリップボードにコピーされました!
MicroShift を設定して、組み込みの Logical Volume Manager Storage (LVMS) Container Storage Interface (CSI) プロバイダーまたは CSI スナップショット機能を無効にし、RAM、CPU、ストレージなどのランタイムリソースの使用を減らすことができます。
7.1. CSI スナップショット実装を実行するデプロイメントの無効化 リンクのコピーリンクがクリップボードにコピーされました!
以下の手順に従って、CSI 実装 Pod のインストールを無効にします。
この手順は、MicroShift をインストールして実行する前に設定ファイルを定義するユーザーを対象としています。MicroShift がすでに開始されている場合、CSI スナップショット実装が実行されます。ユーザーは、アンインストール手順に従って手動で削除する必要があります。
MicroShift は、CSI スナップショット実装 Pod を削除しません。起動プロセス中に CSI スナップショット実装 Pod のインストールを無効化するように MicroShift を設定する必要があります。
手順
/etc/microshift/config.yamlの MicroShift 設定ファイルのstorageセクションで、optionalCsiComponents値を入力して、CSI スナップショットコントローラーのインストールを無効化します。# ... storage: {} # ...# ... storage: {}1 # ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 許可される値は次のとおりです。
-
optionalCsiComponentsは定義しません。 -
optionalCsiComponentsフィールドを空の値 ([]) または単一の空の文字列要素 ([""]) で指定します。 許可される値 (
snapshot-controller、snapshot-webhook、またはnone) のいずれかでoptionalCsiComponentsを指定します。noneは、他のすべての値と相互に排他的です。注記optionalCsiComponents値が空または null の場合、MicroShift はデフォルトで snapshot-controller および snapshot-webhook をデプロイします。
-
optionalCsiComponentsフィールドがconfig.yamlのサポートされている値で指定された後、次のコマンドを実行して MicroShift を起動します。sudo systemctl start microshift
$ sudo systemctl start microshiftCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注記MicroShift は、再起動後に無効化されたコンポーネントを再デプロイしません。
7.2. CSI ドライバー実装を実行するデプロイメントの無効化 リンクのコピーリンクがクリップボードにコピーされました!
以下の手順に従って、CSI 実装 Pod のインストールを無効にします。
この手順は、MicroShift をインストールして実行する前に設定ファイルを定義するユーザーを対象としています。MicroShift がすでに起動されている場合、CSI ドライバー実装が実行されます。ユーザーは、アンインストール手順に従って手動で削除する必要があります。
MicroShift は、CSI ドライバー実装 Pod を削除しません。起動プロセス中に CSI ドライバー実装 Pod のインストールを無効化するように MicroShift を設定する必要があります。
手順
/etc/microshift/config.yamlの MicroShift 設定ファイルのstorageセクションの下にdriver値を入力して、CSI ドライバーのインストールを無効化します。# ... storage driver: - "none" # ...
# ... storage driver: - "none"1 # ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 有効な値は
noneまたはlvmsです。
注記デフォルトでは、
driver値は空または null で、LVMS がデプロイされています。次のコマンドを実行して、
driverフィールドが、/etc/microshift/config.yamlファイルでサポートされている値で指定された後に MicroShift を開始します。sudo systemctl enable --now microshift
$ sudo systemctl enable --now microshiftCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注記MicroShift は、再起動操作後に無効化されたコンポーネントを再デプロイしません。
第8章 低レイテンシーの設定 リンクのコピーリンクがクリップボードにコピーされました!
8.1. 低レイテンシーの設定 リンクのコピーリンクがクリップボードにコピーされました!
低レイテンシー機能を設定してチューニングすることで、エッジデバイスでアプリケーションのパフォーマンスを向上させることができます。
8.1.1. MicroShift アプリケーションのレイテンシーの短縮 リンクのコピーリンクがクリップボードにコピーされました!
レイテンシーは、イベントからそのイベントへの応答までの時間として定義されます。エッジデバイスが外部イベントに迅速に応答する必要がある、運用上またはソフトウェア定義の制御システムで実行されている MicroShift クラスターで、低レイテンシー設定およびチューニングを使用できます。MicroShift の設定とオペレーティングシステムのチューニングとワークロードのパーティション分割を組み合わせることで、低レイテンシーのパフォーマンスを完全に最適化できます。
MicroShift サービス、OVS、CRI-O、MicroShift Pod、分離されたコアなどの管理アプリケーションの CPU セットには、すべてのオンライン CPU が含まれている必要があります。
8.1.1.1. MicroShift アプリケーションの低レイテンシーを設定するためのワークフロー リンクのコピーリンクがクリップボードにコピーされました!
MicroShift クラスターで実行されているアプリケーションの低レイテンシーを設定するには、次のタスクを完了する必要があります。
- 必須
-
microshift-low-latencyRPM をインストールします。 - ワークロードのパーティション分割を設定します。
-
/etc/microshift/ディレクトリーにあるconfig.yamlファイルのkubeletセクションを設定します。 - TuneD プロファイルを設定してアクティブ化します。TuneD は、ホストシステムを監視し、特定のワークロードでパフォーマンスを最適化する Red Hat Enterprise Linux (RHEL) のサービスです。
- ホストを再起動します。
-
- 任意
- x86_64 アーキテクチャーを使用している場合は、Red Hat Enterprise Linux for Real Time 9 をインストールできます。
8.1.2. MicroShift の低レイテンシー RPM パッケージのインストール リンクのコピーリンクがクリップボードにコピーされました!
MicroShift をインストールする際に、低レイテンシー RPM パッケージはデフォルトでインストールされません。低レイテンシー RPM は、オプションのパッケージとしてインストールできます。
前提条件
- MicroShift RPM をインストールしている。
- MicroShift のワークロードのパーティション分割を設定している。
手順
次のコマンドを実行して、低レイテンシーの RPM パッケージをインストールします。
sudo dnf install -y microshift-low-latency
$ sudo dnf install -y microshift-low-latencyCopy to Clipboard Copied! Toggle word wrap Toggle overflow ヒントTuneD プロファイルがアクティブ化されるのを待ってから、ホストを再起動します。ホストを再起動することで MicroShift と CRI-O が再起動され、低レイテンシーマニフェストが適用され、TuneD プロファイルがアクティブ化されます。
次のステップ
-
MicroShift
config.yamlで、低レイテンシー用の kubelet パラメーターを設定します。 - オペレーティングシステムを調整してください。たとえば、TuneD プロファイルを設定してアクティブ化します。
- オプション: TuneD プロファイルの自動アクティブ化を設定します。
- オプション: x86_64 アーキテクチャーを使用している場合は、Red Hat Enterprise Linux for Real Time (リアルタイムカーネル) をインストールします。
- 低レイテンシー用にワークロードを準備します。
8.1.3. MicroShift での kubelet パラメーターおよび値の設定 リンクのコピーリンクがクリップボードにコピーされました!
MicroShift クラスターへの低レイテンシーを有効化するための最初の手順は、MicroShift config.yaml ファイルに設定を追加することです。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 - クラスターへの root アクセス権限がある。
-
/etc/microshift/ディレクトリーにある指定されたconfig.yaml.defaultファイルのコピーを作成し、config.yamlという名前を付けている。
手順
kubelet 設定を MicroShift
config.yamlファイルに追加します。パススルー
kubelet設定の例Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- kubelet 設定で CPU またはメモリーマネージャーを変更する場合は、以前の設定をキャッシュするファイルを削除する必要があります。ホストを再起動してそれらを自動的に削除するか、
/var/lib/kubelet/cpu_manager_stateファイルおよび/var/lib/kubelet/memory_manager_stateファイルを手動で削除します。 - 2
- 使用するポリシーの名前。有効な値は
noneおよびstaticです。CPUManagerフィーチャーゲートを有効化する必要があります。デフォルト値はnoneです。 - 3
CPUManagerポリシーの動作を微調整する追加のオプションを設定するためのkey=valueペアのセット。デフォルト値はnullです。CPUManagerとCPUManagerPolicyOptions機能ゲートの両方を有効化する必要があります。- 4
- Memory Manager が使用するポリシーの名前。大文字と小文字を区別します。デフォルト値は
noneです。MemoryManagerフィーチャーゲートを有効化する必要があります。 - 5
- 必須。
reservedSystemCPUsの値は、オフライン化された CPU の逆数である必要があります。なぜなら、これら両方を合わせた値は、システム上のすべての CPU を考慮する必要があるためです。このパラメーターは、管理およびアプリケーションワークロードを分割する上で不可欠です。このパラメーターを使用して、ホストレベルのシステムおよび Kubernetes デーモン、さらに割り込みやタイマーのための静的 CPU セットを定義します。その後、システム上の残りの CPU はワークロード専用に使用できます。 - 6
- この例の
reservedMemory[0].limits.memory、1100Mi の値は、kubeReserved.memory+systemReserved.memory+evictionHard.memory.availableに相当します。 - 7
evictionHardパラメーターは、kubelet が Pod をエビクトする条件を定義します。evictionHardスタンザの 1 つのみのパラメーターのデフォルト値を変更する場合、他のパラメーターのデフォルト値は継承されず、ゼロに設定されます。1 つだけ変更したい場合でも、すべてのしきい値を指定します。- 8
imagefsは、コンテナーランタイムがコンテナーイメージとコンテナーの書き込み可能な階層を保存するために使用するファイルシステムです。この例では、evictionHard.imagefs.availableパラメーターは、イメージファイルシステムで利用可能な領域が 15% 未満の場合に Pod がエビクトされることを意味します。- 9
- この例では、
evictionHard.memory.availableパラメーターは、ノードの利用可能なメモリーが 100 MiB 未満の場合に Pod がエビクトされることを意味します。 - 10
- この例では、
evictionHard.nodefs.availableパラメーターは、ノードのメインファイルシステムに空き容量が 10% 未満になると Pod がエビクトされることを意味します。 - 11
- この例では、
evictionHard.nodefs.inodesFreeパラメーターは、ノードのメインファイルシステムの inode のうち 15% 強が使用されている場合に Pod がエビクトされることを意味します。 - 12
- コンテナーのガベージコレクションの場合: エビクションプレッシャー状態から移行するまでの待機時間。
evictionPressureTransitionPeriodパラメーターを0に設定すると、デフォルト値の 5 分が設定されます。
検証
-
次のステップを完了してホストを再起動したら、root-access アカウントを使用して、設定が
/var/lib/microshift/resources/kubelet/config/ディレクトリーのconfig.yamlファイルにあることを確認できます。
次のステップ
- ワークロードのパーティション分割を有効化します。
- オペレーティングシステムを調整します。たとえば、TuneD プロファイルを設定およびアクティブ化します。
- オプション: TuneD プロファイルの自動有効化を設定します。
- オプション: x86_64 アーキテクチャーを使用している場合は、Red Hat Enterprise Linux for Real Time (リアルタイムカーネル) をインストールできます。
- 低レイテンシー用に MicroShift ワークロードを準備します。
8.1.4. Red Hat Enterprise Linux 9 のチューニング リンクのコピーリンクがクリップボードにコピーされました!
Red Hat Enterprise Linux (RHEL) システム管理者は、TuneD サービスを使用して、さまざまなユースケースに対して RHEL のパフォーマンスプロファイルを最適化できます。TuneD は、レイテンシーのパフォーマンスを含む、特定のワークロードでシステムパフォーマンスを監視し、最適化します。
- TuneD プロファイルを使用して、低レイテンシーの MicroShift クラスターのデプロイなど、さまざまなユースケースに合わせてシステムを調整します。
- 各プロファイルに定義されたルールを変更し、特定のデバイスのチューニングをカスタマイズできます。
- 別のプロファイルに切り替えたり、TuneD を非アクティブ化すると、以前のプロファイルがシステム設定に加えた変更はすべて、元の状態に戻ります。
- また、TuneD を設定してデバイスの使用状況の変化に対応し、設定を調整して、アクティブなデバイスのパフォーマンスを向上させ、非アクティブなデバイスの消費電力を削減することもできます。
8.1.4.1. MicroShift TuneD プロファイルの設定 リンクのコピーリンクがクリップボードにコピーされました!
microshift-low-latency RPM パッケージをインストールした後、Red Hat Enterprise Linux (RHEL) /etc/tuned/ host ディレクトリーで提供される microshift-baseline-variables.conf 設定ファイルを使用して、MicroShift ワークロードで低レイテンシーを使用するようにホストの TuneD プロファイルを設定します。
前提条件
- クラスターへの root アクセス権限がある。
-
microshift-low-latencyRPM パッケージをインストールしている。 - RHEL ホストに TuneD がインストールされている。TuneD のスタートガイド (RHEL ドキュメント) を参照してください。
手順
/etc/tuned/ディレクトリープロファイルでデフォルトのmicroshift-baseline-variables.confTuneD プロファイルを使用するか、独自のチューニングを作成してチューニングをさらに追加できます。microshift-baseline-variables.confTuneD プロファイルの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 分離する必要のあるコアを制御します。MicroShift では、ハウスキーピング用にソケットごとに 1 コアがデフォルトで予約されています。他のコアは分離されます。有効な値はコアリストまたは範囲です。任意の範囲 (例:
isolated_cores=2,4-7またはisolated_cores=2-23) を分離できます。重要isolated_cores=変数を 1 つだけ維持する必要があります。注記Kubernetes CPU マネージャーは、kubelet 設定で定義された予約済み CPU を除き、任意の CPU を使用してワークロードを実行できます。このような理由から、以下が最善となります。
- kubelet の予約 CPU と分離されたコアの合計には、すべてのオンライン CPU が含まれます。
- 分離されたコアは、kubelet 設定で定義された予約済み CPU に補完されます。
- 2
- hugepages のサイズ。有効な値は 2M または 1G です。
- 3
- 追加のカーネル引数 (
additional_args=console=tty0 console=ttyS0,115200など) - 4
- オフラインに設定された CPU。重要
isolated_coresと重複することはできません。
次のコマンドを実行して、プロファイルを有効化するか、変更をアクティブにします。
sudo tuned-adm profile microshift-baseline
$ sudo tuned-adm profile microshift-baselineCopy to Clipboard Copied! Toggle word wrap Toggle overflow - ホストを再起動して、カーネル引数をアクティブにします。
検証
オプション: 起動時に現在実行中のカーネルに指定された引数を含む
/proc/cmdlineファイルを読み取ることができます。cat /proc/cmdline
$ cat /proc/cmdlineCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
BOOT_IMAGE=(hd0,msdos2)/ostree/rhel-7f82ccd9595c3c70af16525470e32c6a81c9138c4eae6c79ab86d5a2d108d7fc/vmlinuz-5.14.0-427.31.1.el9_4.x86_64+rt crashkernel=1G-4G:192M,4G-64G:256M,64G-:512M rd.lvm.lv=rhel/root fips=0 console=ttyS0,115200n8 root=/dev/mapper/rhel-root rw ostree=/ostree/boot.1/rhel/7f82ccd9595c3c70af16525470e32c6a81c9138c4eae6c79ab86d5a2d108d7fc/0 skew_tick=1 tsc=reliable rcupdate.rcu_normal_after_boot=1 nohz=on nohz_full=2,4-5 rcu_nocbs=2,4-5 tuned.non_isolcpus=0000000b intel_pstate=disable nosoftlockup hugepagesz=2M hugepages=10
BOOT_IMAGE=(hd0,msdos2)/ostree/rhel-7f82ccd9595c3c70af16525470e32c6a81c9138c4eae6c79ab86d5a2d108d7fc/vmlinuz-5.14.0-427.31.1.el9_4.x86_64+rt crashkernel=1G-4G:192M,4G-64G:256M,64G-:512M rd.lvm.lv=rhel/root fips=0 console=ttyS0,115200n8 root=/dev/mapper/rhel-root rw ostree=/ostree/boot.1/rhel/7f82ccd9595c3c70af16525470e32c6a81c9138c4eae6c79ab86d5a2d108d7fc/0 skew_tick=1 tsc=reliable rcupdate.rcu_normal_after_boot=1 nohz=on nohz_full=2,4-5 rcu_nocbs=2,4-5 tuned.non_isolcpus=0000000b intel_pstate=disable nosoftlockup hugepagesz=2M hugepages=10Copy to Clipboard Copied! Toggle word wrap Toggle overflow
次のステップ
- 低レイテンシー用に MicroShift ワークロードを準備します。
- オプション: TuneD プロファイルの自動有効化を設定します。
- オプション: x86_64 アーキテクチャーを使用している場合は、Red Hat Enterprise Linux for Real Time (リアルタイムカーネル) をインストールできます。
8.1.4.2. MicroShift TuneD プロファイルを自動的に有効化する リンクのコピーリンクがクリップボードにコピーされました!
microshift-low-latency RPM パッケージには、システムの起動時に TuneD プロファイルを自動的に有効化するように設定可能な systemd サービスが含まれています。この機能は、大量のデバイスに MicroShift をインストールする場合に特に便利です。
前提条件
- ホストに microshift-low-latency RPM パッケージをインストールしている。
-
MicroShift の
config.yamlで低レイテンシーを有効化している。 - TuneD プロファイルを作成している。
-
microshift-baseline-variables.confファイルを設定している。
手順
/etc/microshift/ディレクトリーでtuned.yamlを設定します。次に例を示します。tuned.yaml の例
profile: microshift-baseline reboot_after_apply: True
profile: microshift-baseline1 reboot_after_apply: True2 Copy to Clipboard Copied! Toggle word wrap Toggle overflow 重要ホストは、
microshift-tuned.serviceの実行時に再起動されますが、新しいコミットのデプロイ時にシステムは再起動されません。ホストを再起動して新しいコミットを有効化する必要があります。その後、起動時にmicroshift-tuned.serviceが実行され、プロファイルと変数への変更が検出されたときに、システムが再び起動します。この二重ブートはロールバックに影響を及ぼす可能性があります。自動プロファイルアクティブ化の使用時に、ロールバック前に許可される greenboot での再起動の回数を調整してください。たとえば、greenboot でロールバック前に 3 回の再起動が許可されている場合、その回数を 4 回に増やします。詳細は、「関連情報」のリストを参照してください。
次のコマンドを入力して、
microshift-tuned.serviceが各システムの起動時に実行できるようにします。sudo systemctl enable microshift-tuned.service
$ sudo systemctl enable microshift-tuned.serviceCopy to Clipboard Copied! Toggle word wrap Toggle overflow 重要reboot_after_applyをTrueに設定する場合は、TuneD プロファイルがアクティブであること、および他のプロファイルが MicroShift サービス外でアクティブ化されていないことを確認してください。そのように設定されずにmicroshift-tuned.serviceを起動すると、ホストが再起動します。次のコマンドを実行して、
microshift-tuned.serviceを起動します。sudo systemctl start microshift-tuned.service
$ sudo systemctl start microshift-tuned.serviceCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注記microshift-tuned.serviceは、収集したチェックサムを使用して、一部の TuneD プロファイルと変数への変更を検出します。ディスクにチェックサムがない場合は、サービスは TuneD プロファイルをアクティブ化し、ホストを再起動します。microshift-tuned.serviceの初めて起動する際は、ホストの再起動が必要です。
次のステップ
- オプション: x86_64 アーキテクチャーを使用している場合は、Red Hat Enterprise Linux for Real Time (リアルタイムカーネル) をインストールできます。
8.1.5. Red Hat Enterprise Linux for Real-Time の使用 リンクのコピーリンクがクリップボードにコピーされました!
ワークロードが割り込み処理やプロセススケジューリングなど、マイクロ秒 (μs) 単位の低レイテンシーかつ決定論的なコアカーネル機能を厳密に求める場合、Red Hat Enterprise Linux for Real Time (リアルタイムカーネル) を使用できます。リアルタイムカーネルの目的は、予測可能な応答時間を提供する、一貫性のある低レイテンシーの決定論です。
システムのチューニングを検討する際には、以下の要素を考慮してください。
- リアルタイムカーネルを使用する場合でも、標準カーネルと同様にシステムのチューニングは重要です。
- RHEL 9 リリースの一部として提供される標準カーネルを実行する未チューニングのシステムに、リアルタイムカーネルをインストールしても、目立った利点はありません。
- 標準カーネルを調整することで、達成可能なレイテンシー改善の 90% が得られます。
- リアルタイムカーネルは、最も要求の厳しいワークロードで必要とされる、レイテンシー改善の最後の 10% を提供します。
8.1.5.1. Red Hat Enterprise Linux for Real Time (リアルタイムカーネル) のインストール リンクのコピーリンクがクリップボードにコピーされました!
低レイテンシーのワークロードにはリアルタイムカーネルは必要ありませんが、リアルタイムカーネルを使用すると低レイテンシーのパフォーマンスを最適化できます。RPM パッケージを使用してホストにインストールし、Red Hat Enterprise Linux for Edge (RHEL for Edge) イメージのデプロイメントに追加することができます。
前提条件
- Red Hat Enterprise Linux for Real Time (リアルタイムカーネル) を含む Red Hat サブスクリプションがある。たとえば、ホストマシンが登録され、Red Hat Enterprise Linux (RHEL) が RHEL for Real Time サブスクリプにアタッチされています。
- x86_64 アーキテクチャーを使用している。
手順
次のコマンドを実行して、リアルタイムカーネルリポジトリーを有効化します。
sudo subscription-manager repos --enable rhel-9-for-x86_64-rt-rpms
$ sudo subscription-manager repos --enable rhel-9-for-x86_64-rt-rpmsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、リアルタイムカーネルをインストールします。
sudo dnf install -y kernel-rt
$ sudo dnf install -y kernel-rtCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、リアルタイムカーネルのバージョンをクエリーします。
RTVER=$(rpm -q --queryformat '%{version}-%{release}.%{arch}' kernel-rt | sort | tail -1)$ RTVER=$(rpm -q --queryformat '%{version}-%{release}.%{arch}' kernel-rt | sort | tail -1)Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、リアルタイムカーネルをデフォルトのカーネルとして指定する GRUB に永続的な変更を加えます。
sudo grubby --set-default="/boot/vmlinuz-${RTVER}+rt"$ sudo grubby --set-default="/boot/vmlinuz-${RTVER}+rt"Copy to Clipboard Copied! Toggle word wrap Toggle overflow - ホストを再起動して、リアルタイムカーネルをアクティブ化します。
次のステップ
- 低レイテンシー用に MicroShift ワークロードを準備します。
- オプション: ブループリントを使用して、RHEL for Edge イメージにリアルタイムカーネルをインストールします。
Image Builder を使用して、RHEL for Edge イメージデプロイメントにリアルタイムカーネルを含めることができます。次のブループリントセクションの例には、MicroShift クラスターの低レイテンシーを設定するために必要だった前の手順で収集した参照が含まれています。
前提条件
- Red Hat Enterprise Linux for Real Time (リアルタイムカーネル) を含むホストで Red Hat サブスクリプションを有効化している。
- x86_64 アーキテクチャーを使用している。
-
kernel-rtリポジトリーを使用するようにosbuildを設定している。
リアルタイムカーネルを含むサブスクリプションは、コミットのビルドに使用するホストで有効化する必要があります。
手順
RHEL for Edge イメージにリアルタイムカーネルをインストールするための完全なインストールブループリントに、以下の例のブループリントセクションを追加してください。
リアルタイムカーネルのブループリントスニペットの例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
次のステップ
- イメージのビルドプロセスを完了します。
- MicroShift クラスターの低レイテンシーを有効化するための以前の手順を完了していない場合は、今すぐ完了してください。これらの手順で収集された情報を使用してブループリントを更新します。
- ワークロードのパーティション分割を設定していない場合は、今すぐ設定してください。
- 低レイテンシー用に MicroShift ワークロードを準備します。
8.1.6. リアルタイムカーネルを使用した Red Hat Enterprise Linux for Edge (RHEL for Edge) イメージのビルド リンクのコピーリンクがクリップボードにコピーされました!
ビルドプロセスを完了するには、RHEL for Edge イメージに MicroShift を埋め込む以下の手順から開始します。次に、RHEL for Edge イメージに MicroShift をインストールするためのインストールドキュメントの残りの手順を完了します。
8.1.7. 低レイテンシーに対する MicroShift ワークロードの準備 リンクのコピーリンクがクリップボードにコピーされました!
低レイテンシーを利用するには、MicroShift で実行されるワークロードでは、RuntimeClass 機能を使用して microshift-low-latency コンテナーのランタイム設定を行う必要があります。CRI-O RuntimeClass オブジェクトは microshift-low-latency RPM でインストールされるため、Pod アノテーションのみを設定する必要があります。
前提条件
-
microshift-low-latencyRPM パッケージをインストールしている。 - ワークロードのパーティション分割を設定している。
手順
以下の例を使用して、Pod 仕様で次のアノテーションを設定します。
cpu-load-balancing.crio.io: "disable" irq-load-balancing.crio.io: "disable" cpu-quota.crio.io: "disable" cpu-load-balancing.crio.io: "disable" cpu-freq-governor.crio.io: "<governor>"
cpu-load-balancing.crio.io: "disable" irq-load-balancing.crio.io: "disable" cpu-quota.crio.io: "disable" cpu-load-balancing.crio.io: "disable" cpu-freq-governor.crio.io: "<governor>"Copy to Clipboard Copied! Toggle word wrap Toggle overflow oslatテストを実行する Pod の例:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Pod の CPU 負荷分散を無効化します。
- 2
- Pod の割り込み処理 (IRQ) をオプトアウトします。
- 3
- Pod の実行時に CPU Completely Fair Scheduler (CFS) のクォータを無効にします。
- 4
- 各 CPU の C- 状態を有効化または無効化します。優先順位の高い Pod で最高のパフォーマンスを提供するには、値を
disableに設定します。 - 5
- 各 CPU の
cpufreqガバナーを設定します。performanceガバナーは、優先度の高いワークロードに推奨されます。 - 6
runtimeClassNameは、クラスターで設定したパフォーマンスプロファイルの名前と一致している必要があります。たとえば、microshift-low-latencyです。
注記CPU マネージャーの静的ポリシーが有効化され、CPU 全体を使用する Guaranteed QoS を持つ Pod に対してのみ、CPU 負荷分散を無効化します。これ以外の場合に CPU 負荷分散を無効にすると、クラスター内の他のコンテナーのパフォーマンスに影響する可能性があります。
重要Pod が
GuaranteedQoS クラスを持つには、要求と制限で CPU およびメモリーの値が同じである必要があります。Guaranteed (Kubernetes アップストリームのドキュメント) を参照してください。
8.1.8. RHEL for Edge イメージに Red Hat Enterprise Linux for Real Time (リアルタイムカーネル) をインストールするための参照ブループリント リンクのコピーリンクがクリップボードにコピーされました!
イメージのブループリントは、複数のビルドを作成できる必要なイメージのカスタマイズの永続的な定義です。各イメージビルドのブループリントを再設定する代わりに、ブループリントからイメージを継続的に再ビルドできるように、ブループリントを編集、再ビルド、削除、および保存できます。
RHEL for Edge イメージにリアルタイムカーネルをインストールするために使用されるブループリントの例
8.2. ワークロードのパーティション分割 リンクのコピーリンクがクリップボードにコピーされました!
ワークロードのパーティション分割は、ノードの CPU リソースを個別の CPU セットに分割します。主な目的は、ユーザーのワークロード用に残りのデバイス CPU リソースを予約するすべてのコントロールプレーンコンポーネントの CPU 使用率を制限することです。
ワークロードのパーティション分割は、予約済みの CPU セットを MicroShift サービス、クラスター管理ワークロード、およびインフラストラクチャー Pod に割り当て、クラスターデプロイメント内の残りの CPU が変更されずに、プラットフォーム以外のワークロード専用になるようにします。
8.2.1. ワークロードのパーティション分割の有効化 リンクのコピーリンクがクリップボードにコピーされました!
MicroShift でワークロードのパーティション分割を有効化するには、次の設定変更を行います。
-
MicroShift
config.yamlファイルを更新して、kubelet 設定ファイルを含めます。 - CRI-O systemd および設定ファイルを作成します。
- MicroShift および CRI-O サービスの systemd 設定ファイルをそれぞれ作成および更新します。
手順
MicroShift
config.yamlファイルを更新して、kubelet 設定ファイルを含め、ワークロードの CPU マネージャーを有効化して設定します。パス
/etc/kubernetes/openshift-workload-pinningに kubelet 設定ファイルを作成します。kubelet 設定は、容量および割り当て可能な CPU に基づいてノードリソースを変更するように kubelet に指示します。kubelet 設定の例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
cpusetは、8 つの VCPU (4 コア) を搭載したマシンに適用され、ドキュメント全体で有効です。
パス
/etc/microshift/config.yaml内の MicroShift config.yaml ファイルを更新します。MicroShiftconfig.yamlファイルに kubelet 設定を埋め込んで、ワークロードの CPU マネージャーを有効化して設定します。MicroShift の
config.yamlの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow
CRI-O systemd および設定ファイルを作成します。
パス
/etc/crio/crio.conf.d/20-microshift-workload-partition.confに CRI-O 設定ファイルを作成します。このファイルは、11-microshift-ovn.confファイルにすでに存在するデフォルト設定をオーバーライドします。CRI-O 設定の例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow パス
/etc/systemd/system/crio.service.d/microshift-cpuaffinity.confに CRI-O の systemd ファイルを作成します。CRI-O systemd 設定の例
# ... [Service] CPUAffinity=0,6,7 # ...
# ... [Service] CPUAffinity=0,6,7 # ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow
MicroShift および CRI-O サービスの
CPUAffinity値を使用して、systemd 設定ファイルを作成および更新します。パス
/etc/systemd/system/microshift.service.d/microshift-cpuaffinity.confに MicroShift サービスの systemd ファイルを作成します。MicroShift は、systemdCPUAffinity値を使用して固定されます。MicroShift サービスの systemd 設定の例
# ... [Service] CPUAffinity=0,6,7 # ...
# ... [Service] CPUAffinity=0,6,7 # ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow パス
/etc/systemd/system/ovs-vswitchd.service.d/microshift-cpuaffinity.confの MicroShift ovs-vswitchd systemd ファイルのCPUAffinity値を更新します。MicroShift ovs-vswitchd systemd 設定の例
# ... [Service] CPUAffinity=0,6,7 # ...
# ... [Service] CPUAffinity=0,6,7 # ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow パス
/etc/systemd/system/ovsdb-server.service.d/microshift-cpuaffinity.confの MicroShift ovsdb-server systemd ファイルのCPUAffinity値を更新します。MicroShift ovsdb-server systemd 設定の例
# ... [Service] CPUAffinity=0,6,7 # ...
# ... [Service] CPUAffinity=0,6,7 # ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow