16.4. インストーラーでプロビジョニングされるインストール後の設定
インストーラーでプロビジョニングされるクラスターを正常にデプロイしたら、以下のインストール後の手順を考慮してください。
16.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.13.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.13.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
16.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
16.4.3. 外部ロードバランサーの設定
OpenShift Container Platform クラスターを設定し、デフォルトのロードバランサーの代わりに外部ロードバランサーを使用することができます。
複数のサブネットをサポートする外部ロードバランサーを使用するように OpenShift Container Platform クラスターを設定することもできます。複数のサブネットを使用する場合は、ロードバランサーターゲットが使用するネットワーク内のすべての IP アドレスを明示的にリストできます。この設定では、ロードバランサーターゲットを再設定せずにネットワーク内でノードを作成および破棄できるため、メンテナンスオーバーヘッドを削減できます。
/27 や /28 などの小規模なネットワーク上に設定されたマシンを使用して Ingress Pod をデプロイする場合、ロードバランサーのターゲットを簡素化できます。
インストールプログラムに API および Ingress 静的アドレスを指定する必要はありません。この設定を選択した場合は、追加のアクションを実行して、参照される各 vSphere サブネットから IP アドレスを受け入れるネットワークターゲットを定義する必要があります。
前提条件
- ロードバランサーでは、クラスターの外部にあるシステムのすべてのユーザーがポート 6443、443、および 80 経由の TCP に到達できる必要があります。
- すべてのコンピュートノード間でアプリケーションポート 443 と 80 の負荷を分散します。
- それぞれのコントロールプレーンノード間で API ポート 6443 を負荷分散します。
- ロードバランサーでは、Ignition 起動設定をノードに提供するために使用されるポート 22623 はクラスター外に公開されません。
ロードバランサーは、クラスター内の各ノード上の必要なポートにアクセスできます。次のアクションを実行することで、このレベルのアクセスを確保できます。
- API ロードバランサーは、コントロールプレーンノードのポート 22623 および 6443 にアクセスできます。
- ingress ロードバランサーは、ingress Pod が配置されているノードのポート 443 および 80 にアクセスできます。
手順
ポート 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