設定
第1章 MicroShift 設定ファイルの使用 リンクのコピーリンクがクリップボードにコピーされました!
YAML ファイルは、優先設定、設定、およびパラメーターを使用して MicroShift インスタンスをカスタマイズします。
kustomize マニフェスト以外のツールを使用し、MicroShift API を介して設定を変更したり、アプリケーションをデプロイしたりする場合は、greenboot ヘルスチェックが完了するまで待つ必要があります。これにより、greenboot が rpm-ostree システムを以前の状態にロールバックしても、変更が失われなくなります。
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 をインストールおよび設定できます。
1.2. デフォルトの設定 リンクのコピーリンクがクリップボードにコピーされました!
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
- API サーバーがクラスターのメンバーにアドバタイズされる IP アドレスを指定する文字列。デフォルト値は、サービスネットワークのアドレスに基づいて計算されます。
- 2
- ログファイルが自動的に削除されるまでの保存期間。
maxFileAgeパラメーターのデフォルト値0に設定すると、ログファイルが経過時間をベースに削除されなくなります。この値は設定可能です。 - 3
- デフォルトでは、
audit.logファイルがmaxFileSizeの制限に達すると、audit.logファイルがローテーションされ、MicroShift は新しいaudit.logファイルへの書き込みを開始します。この値は設定可能です。 - 4
- 保存されるログファイルの合計数。デフォルトでは、MicroShift は 10 個のログファイルを保持します。余分なファイルが作成されると、最も古いものが削除されます。この値は設定可能です。
- 5
- 読み取りおよび書き込み要求のメタデータのみをログに記録します。OAuth アクセストークン要求を除く要求の本文はログに記録されません。このフィールドを指定しない場合は、
Defaultプロファイルが使用されます。 - 6
- API サーバー証明書のサブジェクト代替名。
- 7
- ログの詳細レベル。このフィールドの有効な値は、
Normal、Debug、Trace、またはTraceAllです。 - 8
- デフォルトでは、
etcdはシステムの負荷を処理するために必要な量のメモリーを使用します。ただし、メモリー制約のあるシステムでは、etcdが特定の時点で使用できるメモリーの量を制限することが望ましいか、または制限する必要がある場合があります。 - 9
- クラスターのベースドメイン。管理されるすべての DNS レコードはこのベースのサブドメインです。
- 10
ingress.listenAddressの値は、デフォルトでホストのネットワーク全体に設定されます。有効な設定可能な値は、単一の IP アドレスまたは NIC 名、あるいは複数の IP アドレスと NIC 名のリストです。- 11
- デフォルトのポートが表示されます。設定可能です。両方のポートエントリーの有効な値は、1 - 65535 の範囲にある単一の一意のポートです。
ports.httpおよびports.httpsフィールドの値は、同じにすることはできません。 - 12
- 複数の namespace のホスト名要求の処理方法を記述します。デフォルトでは、ルートが、複数の namespace においてホストが同じ名前でパスが異なる要求を許可します。有効な値は
StrictおよびInterNamespaceAllowedです。Strictを指定すると、namespace が異なるルートが、同じホスト名を要求しなくなります。カスタマイズされた MicroShift のconfig.yamlで値が削除されると、InterNamespaceAllowed値が自動的に設定されます。 - 13
- デフォルトのルーターステータスは、
ManagedまたはRemovedのいずれかになります。 - 14
- マニフェストをロードするために使用する
kustomizationファイルをスキャンするファイルシステム上の場所。パスのリストを設定すると、それらのパスのみをスキャンします。マニフェストの読み込みを無効にするには、空のリストに設定します。リスト内のエントリーは、複数のサブディレクトリーに一致する glob パターンに指定できます。 - 15
- Pod IP アドレスの割り当てに使用する IP アドレスのブロック。このフィールドは、インストール後は不変です。
- 16
- Kubernetes サービスの仮想 IP アドレスのブロック。サービスの IP アドレスプール。単一のエントリーがサポートされます。このフィールドは、インストール後は不変です。
- 17
NodePortタイプの Kubernetes サービスに許可されるポート範囲。指定しない場合、デフォルトの範囲の 30000-32767 が使用されます。NodePortが指定されていないサービスは、この範囲から自動的に割り当てられます。このパラメーターは、クラスターのインストール後に更新できます。- 18
- ノードの名前。デフォルト値はホスト名です。空でない場合、この文字列はホスト名ではなく、ノードを識別するために使用されます。MicroShift の初回起動後に、この不変設定を変更することはできません。
- 19
- ノードの IP アドレス。デフォルト値は、デフォルトルートの IP アドレスです。
1.3. YAML 設定ファイルの使用 リンクのコピーリンクがクリップボードにコピーされました!
起動時に、MicroShift はシステム全体の /etc/microshift/ ディレクトリーで、config.yaml という名前の設定ファイルをチェックします。ディレクトリー内に設定ファイルが存在しない場合は、組み込みのデフォルト値を使用してサービスを起動します。
MicroShift 設定ファイルは、ホストと、場合によってはアプリケーションおよびサービス設定と組み合わせて使用する必要があります。MicroShift クラスターの設定を調整するときは、必要に応じて、必要に応じて各関数を設定してください。
便利なように、入力に使用できる config.yaml.default ファイルが自動的にインストールされます。
1.3.1. アドバタイズアドレスネットワークフラグの設定 リンクのコピーリンクがクリップボードにコピーされました!
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.2. 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.1 回避するポート ポート 説明 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章 kubeconfig を使用したクラスターアクセス リンクのコピーリンクがクリップボードにコピーされました!
MicroShift デプロイメントで kubeconfig ファイルがどのように使用されるかを説明します。CLI ツールは、kubeconfig ファイルを使用してクラスターの API サーバーと通信します。これらのファイルには、クラスターの詳細、IP アドレス、および認証に必要なその他の情報が含まれています。
2.1. クラスターアクセスを設定するための Kubeconfig ファイル リンクのコピーリンクがクリップボードにコピーされました!
MicroShift で使用される kubeconfig ファイルの 2 つのカテゴリーは、ローカルアクセスとリモートアクセスです。MicroShift が起動するたびに、API サーバーへのローカルおよびリモートアクセスのための kubeconfig ファイルのセットが生成されます。これらのファイルは、既存の設定情報を使用して /var/lib/microshift/resources/kubeadmin/ ディレクトリーに生成されます。
各アクセスタイプには、異なる認証局 (CA) によって署名された異なる認証証明書が必要です。複数の kubeconfig ファイルを生成することで、このニーズに対応できます。
それぞれの場合に必要なアクセスタイプに適切な kubeconfig ファイルを使用して、認証の詳細を提供できます。MicroShift kubeconfig ファイルの内容は、デフォルトの組み込み値または config.yaml ファイルによって決まります。
クラスターにアクセスするには、kubeconfig ファイルが存在する必要があります。値は、組み込みのデフォルト値、または config.yaml (作成されている場合) から適用されます。
kubeconfig ファイルの内容の例
2.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 サーバーに接続するクライアントからのみ使用できます。ファイル内の証明書はリモート接続では機能しません。
2.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
2.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
2.3.1. リモートアクセスのカスタマイズ リンクのコピーリンクがクリップボードにコピーされました!
異なる IP アドレスまたはホスト名でクラスターにアクセスするために、複数のリモートアクセス kubeconfig ファイル値を生成できます。apiServer.subjectAltNames パラメーターのエントリーごとに追加の kubeconfig ファイルが生成されます。IP 接続中にホストからリモートアクセス kubeconfig ファイルをコピーし、それを使用して他のワークステーションから API サーバーにアクセスできます。
2.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) として含まれています。
2.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
2.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
第3章 カスタム認証局の設定 リンクのコピーリンクがクリップボードにコピーされました!
MicroShift サービスでは、カスタム証明局 (CA) を使用して接続を暗号化できます。
3.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 データに対して検証する必要があります。詳細は、システム全体のトラストストア を参照してください。
3.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.29.2
oc get node NAME STATUS ROLES AGE VERSION dhcp-1-235-195.arm.example.com Ready control-plane,master,worker 76m v1.29.2Copy 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コマンドを使用することもできますが、この方法は推奨されません。
3.3. カスタム証明書の予約名の値 リンクのコピーリンクがクリップボードにコピーされました!
次の証明書の問題により、MicroShift は証明書を動的に無視し、エラーをログに記録します。
- 証明書ファイルがディスク上に存在しないか、読み取り可能ではありません。
- 証明書は解析できません。
-
証明書は、
SubjectAlternativeNames(SAN) フィールド内の内部証明書の IPAddress/DNSNames を上書きします。SAN を設定するときは予約名を使用しないでください。
| アドレス | 型 | コメント |
|---|---|---|
|
| DNS | |
|
| IP Address | |
|
| IP Address | クラスターネットワーク |
|
| IP Address | サービスネットワーク |
| 169.254.169.2/29 | IP Address | br-ex ネットワーク |
|
| DNS | |
|
| DNS | |
|
| DNS |
3.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
3.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
3.6. 関連情報 リンクのコピーリンクがクリップボードにコピーされました!
第4章 greenboot スクリプトのステータスの確認 リンクのコピーリンクがクリップボードにコピーされました!
kustomize マニフェスト以外のツールを使用して MicroShift API を通じてアプリケーションをデプロイしたり、その他の変更を加えたりするには、greenboot ヘルスチェックが完了するまで待つ必要があります。これにより、greenboot が rpm-ostree システムを以前の状態にロールバックしても、変更が失われなくなります。
greenboot-healthcheck サービスは 1 回実行してから終了します。greenboot が終了し、システムが正常な状態になったら、設定の変更とデプロイメントを続行できます。
4.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
第5章 監査ロギングポリシーの設定 リンクのコピーリンクがクリップボードにコピーされました!
設定値を使用して、MicroShift 監査ログファイルのローテーションと保持を制御できます。
5.1. 監査ログファイルの制限設定について リンクのコピーリンクがクリップボードにコピーされました!
設定値を使用して MicroShift 監査ログファイルのローテーションと保持を制御すると、ファーエッジデバイスの限られたストレージ容量を超えないようにすることができます。このようなデバイスでは、ログデータの蓄積によってホストシステムまたはクラスターのワークロードが制限され、デバイスの動作が停止する可能性があります。監査ログポリシーを設定すると、重要な処理スペースを継続して利用できるようにします。
MicroShift 監査ログを制限するために設定した値を使用すると、監査ログバックアップのサイズ、数、保存期間の制限を適用できます。フィールド値は、優先順位を付けずに、互いに独立して処理されます。
フィールドを組み合わせて設定し、保持されるログの最大ストレージ制限を定義できます。以下に例を示します。
-
ログストレージの上限を作成するには、
maxFileSizeとmaxFilesの両方を設定します。 -
maxFileAge値を設定すると、maxFiles値に関係なく、ファイル名のタイムスタンプより古いファイルが自動的に削除されます。
5.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 日付けのソリューション記事)
5.2. 監査ログポリシープロファイルについて リンクのコピーリンクがクリップボードにコピーされました!
監査ログプロファイルは、OpenShift API サーバーおよび Kubernetes API サーバーに送信されるリクエストをログに記録する方法を定義します。
MicroShift は、次の定義済み監査ポリシープロファイルをサポートしています。
| Profile | 説明 |
|---|---|
|
| 読み取りおよび書き込み要求のメタデータのみをログに記録します。OAuth アクセストークン要求を除く要求の本文はログに記録されません。これはデフォルトポリシーになります。 |
|
|
すべてのリクエストのメタデータのログに加えて、API サーバーへのすべての書き込みリクエスト ( |
|
|
すべての要求のメタデータをロギングする以外にも、API サーバーへの読み取りおよび書き込み要求ごとに要求の本文をログに記録します ( |
|
| OAuth アクセストークン要求や OAuth 承認トークン要求などの要求はログに記録されません。 警告
問題のトラブルシューティング時に有用なデータが記録されないリスクを完全に理解していない限り、 |
-
Secret、Route、OAuthClientオブジェクトなどの機密リソースは、メタデータレベルでのみログ記録されます。
デフォルトでは、MicroShift は Default の監査ログプロファイルを使用します。リクエスト本文もログに記録する別の監査ポリシープロファイルを使用することもできますが、CPU、メモリー、I/O などのリソース使用量が増加することに注意してください。
5.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 microsohift
$ sudo systemctl restart microsohiftCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.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