Red Hat Summit設定
第1章 設定ツールの仕組み
YAML ファイルは、設定およびパラメーターを使用して MicroShift インスタンスをカスタマイズします。
kustomize マニフェスト以外のツールを使用し、MicroShif API を介して設定を変更したり、アプリケーションをデプロイしたりする場合は、greenboot ヘルスチェックが完了するまで待つ必要があります。これにより、greenboot が rpm-ostree システムを以前の状態にロールバックしても、変更が失われなくなります。
1.1. デフォルトの設定
config.yaml ファイルを作成しない場合は、デフォルト値が使用されます。次の例は、デフォルトの設定を示しています。
デフォルト値を確認するには、次のコマンドを実行します。
$ microshift show-config
YAML 形式でのデフォルト値の出力例
dns: baseDomain: microshift.example.com 1 network: clusterNetwork: - 10.42.0.0/16 2 serviceNetwork: - 10.43.0.0/16 3 serviceNodePortRange: 30000-32767 4 node: hostnameOverride: "" 5 nodeIP: "" 6 apiServer: advertiseAddress: 10.44.0.0/32 7 subjectAltNames: [] 8 debugging: logLevel: "Normal" 9
- 1
- クラスターのベースドメイン。すべての管理対象 DNS レコードは、このベースのサブドメインになります。
- 2
- Pod IP アドレスの割り当てに使用する IP アドレスのブロック。
- 3
- Kubernetes サービスの仮想 IP アドレスのブロック。
- 4
- タイプ NodePort の Kubernetes サービスに許可されるポート範囲。
- 5
- ノードの名前。デフォルト値はホスト名です。
- 6
- ノードの IP アドレス。デフォルト値は、デフォルトルートの IP アドレスです。
- 7
- API サーバーがクラスターのメンバーにアドバタイズされる IP アドレスを指定する文字列。デフォルト値は、サービスネットワークのアドレスに基づいて計算されます。
- 8
- API サーバー証明書のサブジェクト代替名 (SAN)。
- 9
- ログの詳細レベル。このフィールドの有効な値は、
Normal、Debug、Trace、またはTraceAllです。
1.2. YAML 設定ファイルの使用
MicroShift は、起動時にシステム全体の /etc/microshift/ ディレクトリーで config.yaml という名前の設定ファイルを検索します。カスタム設定を使用するには、MicroShift を起動する前に、設定ファイルを作成し、デフォルトをオーバーライドするための設定を指定する必要があります。
1.2.1. カスタム設定
カスタム設定を作成するには、MicroShift を起動または再起動する前に、/etc/microshift/ ディレクトリーに config.yaml ファイルを作成し、デフォルトをオーバーライドするための設定を変更する必要があります。
設定を変更したら、MicroShift を再起動して有効にします。config.yaml は MicroShift 起動時の読み取り専用ファイルです。
1.2.2. アドバタイズアドレスネットワークフラグの設定
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.2.3. NodePort サービスのポート範囲の拡張
serviceNodePortRange 設定では、NodePort サービスで使用できるポート範囲が拡張します。このオプションは、30000-32767 範囲内で特定の標準ポートを公開する必要がある場合に役立ちます。たとえば、クライアントデバイスは別のポートを使用できないため、デバイスはネットワーク上で 1883/tcp MQ Telemetry Transport (MQTT) ポートを公開する必要があります。
NodePort がシステムポートと重複し、システムまたは MicroShift の誤動作を引き起こす可能性があります。
NodePort サービス範囲を設定するときは、次の点を考慮してください。
-
nodePortを明示的に選択せずに NodePort サービスを作成しないでください。明示的なnodePortが指定されていない場合、このポートはkube-apiserverによってランダムに割り当てられるため、予測できません。 -
デバイスの
HostNetworkで公開するシステムサービスポート、MicroShift ポート、またはその他のサービスに対して NodePort サービスを作成しないでください。 表 1 は、ポート範囲の拡張時に避けるべきポートを示しています。
表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 スケジューラー
1.3. 関連情報
第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 ファイルの内容の例
/var/lib/microshift/resources/kubeadmin/ ├── kubeconfig 1 ├── alt-name-1 2 │ └── kubeconfig ├── 1.2.3.4 3 │ └── kubeconfig └── microshift-rhel9 4 └── 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
localhost の kubeconfig ファイルは、同じホストから API サーバーに接続するクライアントからのみ使用できます。ファイル内の証明書はリモート接続では機能しません。
2.2.1. MicroShift クラスターへのローカルアクセス
以下の手順に従って、kubeconfig ファイルを使用して MicroShift クラスターをローカルでアクセスします。
前提条件
-
ocバイナリーがインストールされている。
手順
オプション: RHEL マシンに
~/.kube/フォルダーがない場合に作成するには、次のコマンドを実行します。$ mkdir -p ~/.kube/
次のコマンドを実行して、生成されたローカルアクセス
kubeconfigファイルを~/.kube/ディレクトリーにコピーします。$ sudo cat /var/lib/microshift/resources/kubeadmin/kubeconfig > ~/.kube/config
次のコマンドを実行して、
~/.kube/configファイルの権限を更新します。$ chmod go-r ~/.kube/config
検証
次のコマンドを入力して、MicroShift が実行されていることを確認します。
$ oc get all -A
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
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
オプション: リモートアクセス
kubeconfigファイルの内容を表示できます。以下のコマンドを実行します。$ cat /var/lib/microshift/resources/kubeadmin/<hostname>/kubeconfig
重要追加のリモートアクセス
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の例dns: baseDomain: example.com node: hostnameOverride: "microshift-rhel9" 1 nodeIP: 10.0.0.1 apiServer: subjectAltNames: - alt-name-1 2 - 1.2.3.4 3
MicroShift を再起動して設定の変更を適用し、次のコマンドを実行して必要な
kubeconfigファイルを自動生成します。$ sudo systemctl restart microshift
追加のリモートアクセス
kubeconfigファイルの内容を確認するには、config.yamlにリストされている名前または IP アドレスをcatコマンドに挿入します。たとえば、次のコマンド例ではalt-name-1が使用されています。$ cat /var/lib/microshift/resources/kubeadmin/alt-name-1/kubeconfig
クラスターの接続に使用する SAN または IP アドレスを含む、使用する
kubeconfigファイルを選択します。この例では、cluster.serverフィールドに `alt-name-1` を含むkubeconfigが正しいファイルです。追加の
kubeconfigファイルの内容の例clusters: - cluster: certificate-authority-data: <base64 CA> server: https://alt-name-1:6443 1- 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) のファイアウォールポートを開きます。[user@microshift]$ sudo firewall-cmd --permanent --zone=public --add-port=6443/tcp && sudo firewall-cmd --reload
検証
user@microshiftとして次のコマンドを実行して、MicroShift が入力されていることを確認します。[user@microshift]$ oc get all -A
2.4.2. MicroShift クラスターへのリモートアクセス
以下の手順に従って、kubeconfig ファイルを使用してリモートワークステーションから MicroShift クラスターにアクセスします。
user@workstation ログインは、ホストマシンにリモートからアクセスするのに使用されます。手順の <user> 値は、user@workstation が MicroShift ホストにログインするユーザーの名前になります。
前提条件
-
ocバイナリーがインストールされている。 -
user@microshiftは、ローカルホストからファイアウォールを開いている。
手順
RHEL マシンに
~/.kube/フォルダーがない場合は、user@workstationとして、次のコマンドを実行してフォルダーを作成します。[user@workstation]$ mkdir -p ~/.kube/
user@workstationとして、次のコマンドを実行して、MicroShift ホストのホスト名の変数を設定します。[user@workstation]$ MICROSHIFT_MACHINE=<name or IP address of MicroShift machine>
user@workstationとして、次のコマンドを実行して、MicroShift を実行している RHEL マシンからローカルマシンに接続するホスト名または IP アドレスを含む生成されたkubeconfigファイルをコピーします。[user@workstation]$ ssh <user>@$MICROSHIFT_MACHINE "sudo cat /var/lib/microshift/resources/kubeadmin/$MICROSHIFT_MACHINE/kubeconfig" > ~/.kube/config
この手順で kubeconfig ファイルを生成するには、関連資料のセクションの「リモートアクセス用に追加の kubeconfig ファイルの生成」を参照してください。
user@workstationとして、次のコマンドを実行して~/.kube/configファイルのパーミッションを更新します。$ chmod go-r ~/.kube/config
検証
user@workstationとして、次のコマンドを入力して、MicroShift が実行されていることを確認します。[user@workstation]$ oc get all -A
第3章 greenboot スクリプトのステータスの確認
kustomize マニフェスト以外のツールを使用して MicroShift API を通じてアプリケーションをデプロイしたり、その他の変更を加えたりするには、greenboot ヘルスチェックが完了するまで待つ必要があります。これにより、greenboot が rpm-ostree システムを以前の状態にロールバックしても、変更が失われなくなります。
greenboot-healthcheck サービスは 1 回実行してから終了します。greenboot が終了し、システムが正常な状態になったら、設定の変更とデプロイメントを続行できます。
3.1. greenboot ヘルスチェックのステータスの確認
システムに変更を加える前、またはトラブルシューティング中に、greenboot ヘルスチェックのステータスを確認します。次のコマンドのいずれかを使用すると、greenboot スクリプトの実行が完了したことを確認できます。
手順
ヘルスチェックステータスのレポートを表示するには、次のコマンドを使用します。
$ systemctl show --property=SubState --value greenboot-healthcheck.service
-
startが出力される場合、greenboot チェックがまだ実行中であることを意味します。 -
exitedが出力される場合、チェックが合格し、greenboot が終了したことを意味します。Greenboot は、システムが正常な状態の場合、green.dディレクトリー内のスクリプトを実行します。 -
failedの出力は、チェックが合格しなかったことを意味します。システムがこの状態にある場合、Greenboot はred.dディレクトリー内のスクリプトを実行し、システムを再起動する可能性があります。
-
サービスの数値終了コードを示すレポートを表示するには、次のコマンドを使用します。
0は成功を、0 以外の値は失敗を意味します。$ systemctl show --property=ExecMainStatus --value greenboot-healthcheck.service
Boot Status is GREEN - Health Check SUCCESSなど、ブートステータスに関するメッセージを表示するレポートを表示するには、次のコマンドを使用します。$ cat /run/motd.d/boot-status
