13.4. インストーラーでプロビジョニングされるインストール後の設定
インストーラーでプロビジョニングされるクラスターを正常にデプロイしたら、以下のインストール後の手順を考慮してください。
13.4.1. (オプション) 非接続クラスターの NTP 設定
OpenShift Container Platform は、クラスターノードに chrony Network Time Protocol (NTP) サービスをインストールします。以下の手順を使用して、コントロールプレーンノードで NTP サーバーを設定し、デプロイメントが正常に完了した後にコントロールプレーンノードの NTP クライアントとしてワーカーノードを設定します。
OpenShift Container Platform ノードは、正しく実行するために日時について合意する必要があります。ワーカーノードがコントロールプレーンノードの NTP サーバーから日付と時刻を取得すると、ルーティング可能なネットワークに接続されていないクラスターのインストールおよび操作が有効になるため、上位の stratum の NTP サーバーにアクセスできなくなります。
手順
コントロールプレーンノードの
chrony.confファイルのコンテンツを含む Butane 設定 (99-master-chrony-conf-override.bu) を作成します。注記Butane の詳細は、Butane を使用したマシン設定の作成を参照してください。
Butane 設定例
variant: openshift version: 4.10.0 metadata: name: 99-master-chrony-conf-override labels: machineconfiguration.openshift.io/role: master storage: files: - path: /etc/chrony.conf mode: 0644 overwrite: true contents: inline: | # Use public servers from the pool.ntp.org project. # Please consider joining the pool (https://www.pool.ntp.org/join.html). # The Machine Config Operator manages this file server openshift-master-0.<cluster-name>.<domain> iburst 1 server openshift-master-1.<cluster-name>.<domain> iburst server openshift-master-2.<cluster-name>.<domain> iburst stratumweight 0 driftfile /var/lib/chrony/drift rtcsync makestep 10 3 bindcmdaddress 127.0.0.1 bindcmdaddress ::1 keyfile /etc/chrony.keys commandkey 1 generatecommandkey noclientlog logchange 0.5 logdir /var/log/chrony # Configure the control plane nodes to serve as local NTP servers # for all worker nodes, even if they are not in sync with an # upstream NTP server. # Allow NTP client access from the local network. allow all # Serve time even if not synchronized to a time source. local stratum 3 orphan- 1
<cluster-name>はクラスターの名前に置き換え、<domain>は完全修飾ドメイン名に置き換える必要があります。
Butane を使用して、コントロールプレーンノードに配信される設定が含まれる
MachineConfigオブジェクトファイル (99-master-chrony-conf-override.yaml) を生成します。$ butane 99-master-chrony-conf-override.bu -o 99-master-chrony-conf-override.yaml
コントロールプレーンノードの NTP サーバーを参照するワーカーノードの
chrony.confファイルのコンテンツを含む Butane 設定 (99-worker-chrony-conf-override.bu) を作成します。Butane 設定例
variant: openshift version: 4.10.0 metadata: name: 99-worker-chrony-conf-override labels: machineconfiguration.openshift.io/role: worker storage: files: - path: /etc/chrony.conf mode: 0644 overwrite: true contents: inline: | # The Machine Config Operator manages this file. server openshift-master-0.<cluster-name>.<domain> iburst 1 server openshift-master-1.<cluster-name>.<domain> iburst server openshift-master-2.<cluster-name>.<domain> iburst stratumweight 0 driftfile /var/lib/chrony/drift rtcsync makestep 10 3 bindcmdaddress 127.0.0.1 bindcmdaddress ::1 keyfile /etc/chrony.keys commandkey 1 generatecommandkey noclientlog logchange 0.5 logdir /var/log/chrony- 1
<cluster-name>はクラスターの名前に置き換え、<domain>は完全修飾ドメイン名に置き換える必要があります。
Butane を使用して、ワーカーノードに配信される設定が含まれる
MachineConfigオブジェクトファイル (99-worker-chrony-conf-override.yaml) を生成します。$ butane 99-worker-chrony-conf-override.bu -o 99-worker-chrony-conf-override.yaml
99-master-chrony-conf-override.yamlポリシーをコントロールプレーンノードに適用します。$ oc apply -f 99-master-chrony-conf-override.yaml
出力例
machineconfig.machineconfiguration.openshift.io/99-master-chrony-conf-override created
99-worker-chrony-conf-override.yamlポリシーをワーカーノードに適用します。$ oc apply -f 99-worker-chrony-conf-override.yaml
出力例
machineconfig.machineconfiguration.openshift.io/99-worker-chrony-conf-override created
適用された NTP 設定のステータスを確認します。
$ oc describe machineconfigpool
13.4.2. インストール後のプロビジョニングネットワークの有効化
ベアメタルクラスター用のアシステッドインストーラーおよびインストーラーでプロビジョニングされるインストールは、provisioning ネットワークなしでクラスターをデプロイする機能を提供します。この機能は、概念実証クラスターや、各ノードのベースボード管理コントローラーが baremetal ネットワークを介してルーティング可能な場合に Redfish 仮想メディアのみを使用してデプロイするなどのシナリオ向けです。
Cluster Baremetal Operator (CBO) を使用してインストール後に provisioning ネットワークを有効にすることができます。
前提条件
- すべてのワーカーノードおよびコントロールプレーンノードに接続されている専用の物理ネットワークが存在する必要があります。
- ネイティブのタグなしの物理ネットワークを分離する必要があります。
-
provisioningNetwork設定がManagedに設定されている場合、ネットワークには DHCP サーバーを含めることはできません。 -
OpenShift Container Platform 4.10 の
provisioningInterface設定を省略して、bootMACAddress設定を使用できます。
手順
-
provisioningInterface設定を設定する場合、まずクラスターノードのプロビジョニングインターフェイス名を特定します。たとえば、eth0またはeno1などです。 -
クラスターノードの
provisioningネットワークインターフェイスで Preboot eXecution Environment (PXE) を有効にします。 provisioningネットワークの現在の状態を取得して、これをプロビジョニングカスタムリソース (CR) ファイルに保存します。$ oc get provisioning -o yaml > enable-provisioning-nw.yaml
プロビジョニング CR ファイルを変更します。
$ vim ~/enable-provisioning-nw.yaml
provisioningNetwork設定までスクロールダウンして、これをDisabledからManagedに変更します。次に、provisioningNetwork設定の後に、provisioningIP、provisioningNetworkCIDR、provisioningDHCPRange、provisioningInterface、およびwatchAllNameSpaces設定を追加します。各設定に適切な値を指定します。apiVersion: v1 items: - apiVersion: metal3.io/v1alpha1 kind: Provisioning metadata: name: provisioning-configuration spec: provisioningNetwork: 1 provisioningIP: 2 provisioningNetworkCIDR: 3 provisioningDHCPRange: 4 provisioningInterface: 5 watchAllNameSpaces: 6- 1
provisioningNetworkは、Managed、Unmanaged、またはDisabledのいずれかになります。Managedに設定すると、Metal3 はプロビジョニングネットワークを管理し、CBO は設定済みの DHCP サーバーで Metal3 Pod をデプロイします。Unmanagedに設定すると、システム管理者は DHCP サーバーを手動で設定します。- 2
provisioningIPは、DHCP サーバーおよび ironic がネットワークのプロビジョニングために使用する静的 IP アドレスです。この静的 IP アドレスは、DHCP 範囲外のprovisioning内でなければなりません。この設定を設定する場合は、provisioningネットワークがDisabledの場合でも、有効な IP アドレスが必要です。静的 IP アドレスは metal3 Pod にバインドされます。metal3 Pod が失敗し、別のサーバーに移動する場合、静的 IP アドレスも新しいサーバーに移動します。- 3
- Classless Inter-Domain Routing (CIDR) アドレス。この設定を設定する場合は、
provisioningネットワークがDisabledの場合でも、有効な CIDR アドレスが必要です。例:192.168.0.1/24 - 4
- DHCP の範囲。この設定は、
Managedプロビジョニングネットワークにのみ適用されます。provisioningネットワークがDisabledの場合は、この設定を省略します。例:192.168.0.64, 192.168.0.253 - 5
- クラスターノードの
provisioningインターフェイス用の NIC 名。provisioningInterface設定は、ManagedおよびUnmanagedプロビジョニングネットワークにのみ適用されます。provisioningネットワークがDisabledの場合に、provisioningInterface設定が省略されます。代わりにbootMACAddress設定を使用するようにprovisioningInterface設定を省略します。 - 6
- metal3 がデフォルトの
openshift-machine-apinamespace 以外の namespace を監視するようにするには、この設定をtrueに設定します。デフォルト値はfalseです。
- 変更をプロビジョニング CR ファイルに保存します。
プロビジョニング CR ファイルをクラスターに適用します。
$ oc apply -f enable-provisioning-nw.yaml
13.4.3. 外部ロードバランサーの設定
OpenShift Container Platform クラスターを設定し、デフォルトのロードバランサーの代わりに外部ロードバランサーを使用することができます。
前提条件
- ロードバランサーでは、システムの任意のユーザーが TCP をポート 6443、443、および 80 が利用できる必要があります。
- それぞれのコントロールプレーンノード間で API ポート 6443 を負荷分散します。
- すべてのコンピュートノード間でアプリケーションポート 443 と 80 を負荷分散します。
- ロードバランサーでは、Ignition 起動設定をノードに提供するために使用されるポート 22623 はクラスター外に公開されません。
ロードバランサーはクラスター内のすべてのマシンにアクセスできる必要があります。このアクセスを許可する方法には、以下が含まれます。
- ロードバランサーをクラスターのマシンのサブネットに割り当てます。
- ロードバランサーを使用するマシンに Floating IP アドレスを割り当てます。
手順
ポート 6443、443、および 80 でロードバランサーからクラスターへのアクセスを有効にします。
たとえば、以下の HAProxy 設定に留意してください。
サンプル HAProxy 設定のセクション
... listen my-cluster-api-6443 bind 0.0.0.0:6443 mode tcp balance roundrobin server my-cluster-master-2 192.0.2.2:6443 check server my-cluster-master-0 192.0.2.3:6443 check server my-cluster-master-1 192.0.2.1:6443 check listen my-cluster-apps-443 bind 0.0.0.0:443 mode tcp balance roundrobin server my-cluster-worker-0 192.0.2.6:443 check server my-cluster-worker-1 192.0.2.5:443 check server my-cluster-worker-2 192.0.2.4:443 check listen my-cluster-apps-80 bind 0.0.0.0:80 mode tcp balance roundrobin server my-cluster-worker-0 192.0.2.7:80 check server my-cluster-worker-1 192.0.2.9:80 check server my-cluster-worker-2 192.0.2.8:80 checkロードバランサーでクラスター API およびアプリケーションの DNS サーバーにレコードを追加します。以下に例を示します。
<load_balancer_ip_address> api.<cluster_name>.<base_domain> <load_balancer_ip_address> apps.<cluster_name>.<base_domain>
コマンドラインで
curlを使用して、外部ロードバランサーおよび DNS 設定が機能することを確認します。クラスター API がアクセス可能であることを確認します。
$ curl https://<loadbalancer_ip_address>:6443/version --insecure
設定が正しい場合は、応答として JSON オブジェクトを受信します。
{ "major": "1", "minor": "11+", "gitVersion": "v1.11.0+ad103ed", "gitCommit": "ad103ed", "gitTreeState": "clean", "buildDate": "2019-01-09T06:44:10Z", "goVersion": "go1.10.3", "compiler": "gc", "platform": "linux/amd64" }クラスターアプリケーションがアクセス可能であることを確認します。
注記Web ブラウザーで OpenShift Container Platform コンソールを開き、アプリケーションのアクセスを確認することもできます。
$ curl http://console-openshift-console.apps.<cluster_name>.<base_domain> -I -L --insecure
設定が正しい場合は、HTTP 応答を受信します。
HTTP/1.1 302 Found content-length: 0 location: https://console-openshift-console.apps.<cluster-name>.<base domain>/ cache-control: no-cacheHTTP/1.1 200 OK referrer-policy: strict-origin-when-cross-origin set-cookie: csrf-token=39HoZgztDnzjJkq/JuLJMeoKNXlfiVv2YgZc09c3TBOBU4NI6kDXaJH1LdicNhN1UsQWzon4Dor9GWGfopaTEQ==; Path=/; Secure x-content-type-options: nosniff x-dns-prefetch-control: off x-frame-options: DENY x-xss-protection: 1; mode=block date: Tue, 17 Nov 2020 08:42:10 GMT content-type: text/html; charset=utf-8 set-cookie: 1e2670d92730b515ce3a1bb65da45062=9b714eb87e93cf34853e87a92d6894be; path=/; HttpOnly; Secure; SameSite=None cache-control: private
13.4.4. 新しい customDeploy インストール方法への手動移行
OpenShift Container Platform 4.10 で導入された新しいデプロイメント方法により、インストールおよびプロビジョニングのプロセス中にホストごとに install-config.yaml ファイルのネットワーク設定 (networkConfig) をカスタマイズできます。ホストごとに静的 IP を設定し、追加の高度なネットワーク設定を設定することもできます。
バージョン 4.10 にアップグレードする場合、OpenShift Container Platform は新しいデプロイメント方法に自動的にアップグレードされないため、以下の手動手順を実行する必要があります。OpenShift Container Platform の機能は影響を受けませんが、クラスターをスケールアップする前にこの変更が必要です。
手順
-
cluster-adminパーミッションを持つユーザーとして、ocにログインする。 存在する machineSet を見つけます。
$ oc get machinesets -A
各 machineSet を編集します。
$ oc edit machineset <machineset> -n openshift-machine-api
以下を含むように変更します。
spec: providerSpec: value: customDeploy: method: install_coreos image: checksum: "" url: ""注記この変更により、イメージの
checksum/urlが削除され、customDeployフィールドが追加されます。
