検索

第11章 Agent-based Installer を使用したオンプレミスクラスターのインストール

download PDF

11.1. Agent-based Installer を使用したインストールの準備

11.1.1. Agent-based Installer について

エージェントベースのインストール方法では、選択した任意の方法でオンプレミスサーバーを柔軟に起動できます。Assisted Installation サービスの使いやすさと、エアギャップ環境を含むオフラインでの実行機能を兼ね備えています。エージェントベースのインストールは、OpenShift Container Platform インストーラーのサブコマンドです。OpenShift Container Platform クラスターをデプロイするために必要なすべての情報を含む起動可能な ISO イメージを、利用可能なリリースイメージと共に生成します。

設定は、installer-provisioned infrastructure および user-provisioned infrastructure のインストール方法と同じ形式です。Agent-based Installer は、必要に応じてゼロタッチプロビジョニング (ZTP) カスタムリソースを生成または受け入れることもできます。ZTP を使用すると、ベアメタル機器の宣言型設定で新しいエッジサイトをプロビジョニングできます。

表11.1 Agent-based Installer でサポートされるアーキテクチャー
CPU アーキテクチャー接続インストール非接続インストール

64-bit x86

64-bit ARM

ppc64le

s390x

11.1.2. Agent-based Installer について

OpenShift Container Platform ユーザーは、切断された環境で Assisted Installer のホストサービスの利点を活用できます。

エージェントベースのインストールは、Assisted Discovery Agent と Assisted Service を含む起動可能な ISO で構成されます。クラスターのインストールを実行するには両方が必要ですが、後者はいずれかのホストでのみ実行されます。

注記

現在、IBM Z® (s390x) 上の ISO ブートサポートは Red Hat Enterprise Linux (RHEL) KVM でのみ利用できます。RHEL KVM では、PXE ベースのインストールか ISO ベースのインストールのどちらかを柔軟に選択できます。z/VM および論理パーティション (LPAR) を使用したインストールでは、PXE ブートのみがサポートされます。

openshift-install agent create image サブコマンドは、指定した入力をもとに一時 ISO を生成します。以下のマニフェストで入力を指定できます。

推奨:

  • install-config.yaml
  • agent-config.yaml

オプション: ZTP マニフェスト

  • cluster-manifests/cluster-deployment.yaml
  • cluster-manifests/agent-cluster-install.yaml
  • cluster-manifests/pull-secret.yaml
  • cluster-manifests/infraenv.yaml
  • cluster-manifests/cluster-image-set.yaml
  • cluster-manifests/nmstateconfig.yaml
  • mirror/registries.conf
  • mirror/ca-bundle.crt

11.1.2.1. Agent-based Installer のワークフロー

コントロールプレーンホストの 1 つは、ブートプロセスの開始時に Assisted Service を実行し、最終的にブートストラップホストになります。このノードを ランデブーホスト (ノード 0) と呼びます。Assisted Service は、すべてのホストが要件を満たしていることを確認し、OpenShift Container Platform クラスターのデプロイをトリガーします。すべてのノードで Red Hat Enterprise Linux CoreOS (RHCOS) イメージがディスクに書き込まれます。ブートストラップ以外のノードは再起動し、クラスターデプロイメントを開始します。ノードが再起動されると、ランデブーホストが再起動し、クラスターに参加します。ブートストラップが完了し、クラスターがデプロイされます。

図11.1 ノードのインストールワークフロー

Agent-based Installer のワークフロー

以下のトポロジーでは、openshift-install agent create image サブコマンドを使用して、ネットワークに接続されていない OpenShift Container Platform クラスターをインストールできます。

  • 単一ノードの OpenShift Container Platform クラスター (SNO): マスターとワーカーの両方であるノード。
  • 3 ノードの OpenShift Container Platform クラスター: ワーカーノードでもある 3 つのマスターノードを持つコンパクトなクラスター。
  • 高可用性 OpenShift Container Platform クラスター (HA): 任意の数のワーカーノードを持つ 3 つのマスターノード。

11.1.3. FIPS 準拠について

多くの OpenShift Container Platform のお客様においては、システムが実稼働環境で使用される前に、一定レベルでの規制への対応またはコンプライアンスが必要になります。この規制対応は、国家標準、業界標準または組織の企業ガバナンスフレームワークによって課せられます。FIPS (Federal Information Processing Standards) コンプライアンスは、安全な環境で必要とされる最も重要なコンポーネントの 1 つであり、サポートされている暗号化技術のみがノード上で許可されるようにします。

重要

クラスターで FIPS モードを有効にするには、FIPS モードで動作するように設定された Red Hat Enterprise Linux (RHEL) コンピューターからインストールプログラムを実行する必要があります。RHEL で FIPS モードを設定する方法の詳細は、RHEL から FIPS モードへの切り替え を参照してください。

FIPS モードでブートされた Red Hat Enterprise Linux (RHEL) または Red Hat Enterprise Linux CoreOS (RHCOS) を実行する場合、OpenShift Container Platform コアコンポーネントは、x86_64、ppc64le、および s390x アーキテクチャーのみで、FIPS 140-2/140-3 検証のために NIST に提出された RHEL 暗号化ライブラリーを使用します。

11.1.4. Agent-based Installer による FIPS の設定

クラスターのデプロイ中に、Red Hat Enterprise Linux CoreOS (RHCOS) マシンがクラスターにデプロイされると、連邦情報処理標準 (FIPS) の変更が適用されます。Red Hat Enterprise Linux (RHEL) マシンでは、ワーカーマシンとして使用する予定のマシンにオペレーティングシステムをインストールする場合に FIPS モードを有効にする必要があります。

install-config.yaml および agent-config.yaml の推奨される方法で FIPS モードを有効にできます。

  1. install-config.yaml ファイルで fips フィールドの値を True に設定する必要があります。

    サンプル install-config.yaml.file

    apiVersion: v1
    baseDomain: test.example.com
    metadata:
      name: sno-cluster
    fips: True

  2. オプション: GitOps ZTP マニフェストを使用している場合、agent-cluster-install.yaml ファイルの Agent-install.openshift.io/install-config-overrides フィールドで fips の値を True に設定する必要があります。

    サンプルの agent-cluster-install.yaml ファイル

    apiVersion: extensions.hive.openshift.io/v1beta1
    kind: AgentClusterInstall
    metadata:
      annotations:
        agent-install.openshift.io/install-config-overrides: '{"fips": True}'
      name: sno-cluster
      namespace: sno-cluster-test

11.1.5. ホストの設定

クラスター上の各ホストの agent-config.yaml ファイルで、ネットワーク設定やルートデバイスのヒントなど追加設定を行うことができます。

重要

設定するホストごとに、ホスト上のインターフェイスの MAC アドレスで、設定するホストを指定する必要があります。

11.1.5.1. ホストのロール

クラスター内の各ホストには、master または worker のいずれかのロールが割り当てられます。role パラメーターを使用して、agent-config.yaml ファイルで各ホストのロールを定義できます。ホストにロールを割り当てない場合、インストール時にロールがランダムに割り当てられます。

そのため、ホストのロールは明示的に定義することが推奨されます。

rendezvousIP は、master ロールを持つホストに割り当てる必要があります。これは、手動で、または Agent-based Installer によるロールの割り当てを許可することで行えます。

重要

ランデブーホストの master ロールを明示的に定義する必要はありませんが、この割り当てと競合する設定は作成できません。

たとえば、ホストが 4 台あり、そのうち 3 台が master ロールを持つように明示的に定義されている場合、最後の 1 台にはインストール時に worker ロールが自動的に割り当てられ、ランデブーホストには設定できません。

agent-config.yaml のサンプルファイル

apiVersion: v1beta1
kind: AgentConfig
metadata:
  name: example-cluster
rendezvousIP: 192.168.111.80
hosts:
  - hostname: master-1
    role: master
    interfaces:
      - name: eno1
        macAddress: 00:ef:44:21:e6:a5
  - hostname: master-2
    role: master
    interfaces:
      - name: eno1
        macAddress: 00:ef:44:21:e6:a6
  - hostname: master-3
    role: master
    interfaces:
      - name: eno1
        macAddress: 00:ef:44:21:e6:a7
  - hostname: worker-1
    role: worker
    interfaces:
      - name: eno1
        macAddress: 00:ef:44:21:e6:a8

11.1.5.2. ルートデバイスヒントについて

rootDeviceHints パラメーターは、インストーラーが Red Hat Enterprise Linux CoreOS (RHCOS) イメージを特定のデバイスにプロビジョニングできるようにします。インストーラーは、検出順にデバイスを検査し、検出された値をヒントの値と比較します。インストーラーは、ヒント値に一致する最初に検出されたデバイスを使用します。この設定は複数のヒントを組み合わせることができますが、デバイスは、インストーラーがこれを選択できるようにすべてのヒントに一致する必要があります。

表11.3 サブフィールド
サブフィールド説明

deviceName

/dev/vda/dev/disk/by-path/ などの Linux デバイス名を含む文字列。ストレージの場所への /dev/disk/by-path/<device_path> リンクを使用することを推奨します。ヒントは、実際の値と完全に一致する必要があります。

hctl

0:0:0:0 などの SCSI バスアドレスを含む文字列。ヒントは、実際の値と完全に一致する必要があります。

model

ベンダー固有のデバイス識別子を含む文字列。ヒントは、実際の値のサブ文字列になります。

vendor

デバイスのベンダーまたは製造元の名前が含まれる文字列。ヒントは、実際の値のサブ文字列になります。

serialNumber

デバイスのシリアル番号を含む文字列。ヒントは、実際の値と完全に一致する必要があります。

minSizeGigabytes

デバイスの最小サイズ (ギガバイト単位) を表す整数。

wwn

一意のストレージ ID を含む文字列。ヒントは、実際の値と完全に一致する必要があります。

rotational

デバイスがローテーションするディスクである (true) か、そうでないか (false) を示すブール値。

使用例

     - name: master-0
       role: master
       rootDeviceHints:
         deviceName: "/dev/sda"

11.1.6. ネットワークの概要

最初の起動時にすべてのホストが支援サービスにチェックインできるように、ランデブー IP はエージェント ISO の生成時に認識されている必要があります。IP アドレスが動的ホスト設定プロトコル (DHCP) サーバーを使用して割り当てられている場合、rendezvousIP フィールドは、デプロイメントされたコントロールプレーンの一部になるホストの 1 つの IP アドレスに設定する必要があります。DHCP サーバーがない環境では、IP アドレスを静的に定義できます。

静的 IP アドレスに加えて、NMState 形式の任意のネットワーク設定を適用できます。これには、VLAN と NIC ボンディングが含まれます。

11.1.6.1. DHCP

推奨される方法: install-config.yaml および agent-config.yaml

rendezvousIP フィールドの値を指定する必要があります。networkConfig フィールドは空白のままにすることができます。

agent-config.yaml.file のサンプル

apiVersion: v1alpha1
kind: AgentConfig
metadata:
  name: sno-cluster
rendezvousIP: 192.168.111.80 1

1
ランデブーホストの IP アドレス。

11.1.6.2. 静的ネットワーキング

  1. 推奨される方法: install-config.yaml および agent-config.yaml

    agent-config.yaml.file のサンプル

      cat > agent-config.yaml << EOF
      apiVersion: v1alpha1
      kind: AgentConfig
      metadata:
        name: sno-cluster
      rendezvousIP: 192.168.111.80 1
      hosts:
        - hostname: master-0
          interfaces:
            - name: eno1
              macAddress: 00:ef:44:21:e6:a5 2
          networkConfig:
            interfaces:
              - name: eno1
                type: ethernet
                state: up
                mac-address: 00:ef:44:21:e6:a5
                ipv4:
                  enabled: true
                  address:
                    - ip: 192.168.111.80 3
                      prefix-length: 23 4
                  dhcp: false
            dns-resolver:
              config:
                server:
                  - 192.168.111.1 5
            routes:
              config:
                - destination: 0.0.0.0/0
                  next-hop-address: 192.168.111.1 6
                  next-hop-interface: eno1
                  table-id: 254
      EOF

    1
    rendezvousIP フィールドに値が指定されていない場合、networkConfig フィールドで指定された静的 IP アドレスから 1 つのアドレスが選択されます。
    2
    設定を適用するホストを決定するために使用される、ホスト上のインターフェイスの MAC アドレス。
    3
    ターゲットのベアメタルホストの静的 IP アドレス。
    4
    ターゲットのベアメタルホストの静的 IP アドレスのサブネット接頭辞。
    5
    ターゲットのベアメタルホストの DNS サーバー。
    6
    ノードトラフィックのネクストホップアドレス。これは、指定されたインターフェイスに設定される IP アドレスと同じサブネットにある必要があります。
  2. オプションの方法: GitOps ZTP マニフェスト

    GitOps ZTP カスタムリソースのオプションの方法は、6 つのカスタムリソースで構成されます。静的 IP は nmstateconfig.yaml で設定できます。

    apiVersion: agent-install.openshift.io/v1beta1
    kind: NMStateConfig
    metadata:
      name: master-0
      namespace: openshift-machine-api
      labels:
        cluster0-nmstate-label-name: cluster0-nmstate-label-value
    spec:
      config:
        interfaces:
          - name: eth0
            type: ethernet
            state: up
            mac-address: 52:54:01:aa:aa:a1
            ipv4:
              enabled: true
              address:
                - ip: 192.168.122.2 1
                  prefix-length: 23 2
              dhcp: false
        dns-resolver:
          config:
            server:
              - 192.168.122.1 3
        routes:
          config:
            - destination: 0.0.0.0/0
              next-hop-address: 192.168.122.1 4
              next-hop-interface: eth0
              table-id: 254
      interfaces:
        - name: eth0
          macAddress: 52:54:01:aa:aa:a1 5
    1
    ターゲットのベアメタルホストの静的 IP アドレス。
    2
    ターゲットのベアメタルホストの静的 IP アドレスのサブネット接頭辞。
    3
    ターゲットのベアメタルホストの DNS サーバー。
    4
    ノードトラフィックのネクストホップアドレス。これは、指定されたインターフェイスに設定される IP アドレスと同じサブネットにある必要があります。
    5
    設定を適用するホストを決定するために使用される、ホスト上のインターフェイスの MAC アドレス。

ランデブー IP は、config フィールドで指定された静的 IP アドレスから選択されます。

11.1.7. プラットフォーム "none" オプションを使用するクラスターの要件

このセクションでは、プラットフォーム none オプションを使用するように設定されたエージェントベースの OpenShift Container Platform インストールの要件を説明します。

重要

仮想化またはクラウド環境で OpenShift Container Platform クラスターのインストールを試行する前に、Deploying OpenShift 4.x on non-tested platforms using the bare metal install method にある情報を確認してください。

11.1.7.1. プラットフォーム "none" の DNS 要件

OpenShift Container Platform のデプロイメントでは、以下のコンポーネントに DNS 名前解決が必要です。

  • The Kubernetes API
  • OpenShift Container Platform のアプリケーションワイルドカード
  • コントロールプレーンおよびコンピュートマシン

逆引き DNS 解決は、Kubernetes API、コントロールプレーンマシン、およびコンピュートマシンにも必要です。

DNS A/AAAA または CNAME レコードは名前解決に使用され、PTR レコードは逆引き名前解決に使用されます。ホスト名が DHCP によって提供されていない場合は、Red Hat Enterprise Linux CoreOS (RHCOS) は逆引きレコードを使用してすべてのノードのホスト名を設定するため、逆引きレコードは重要です。さらに、逆引きレコードは、OpenShift Container Platform が動作するために必要な証明書署名要求 (CSR) を生成するために使用されます。

注記

各クラスターノードにホスト名を提供するために DHCP サーバーを使用することが推奨されます。

以下の DNS レコードは、プラットフォーム none オプションを使用する OpenShift Container Platform クラスターに必要であり、インストール前に設定されている必要があります。各レコードで、<cluster_name> はクラスター名で、<base_domain> は、install-config.yaml ファイルに指定するベースドメインです。完全な DNS レコードは <component>.<cluster_name>.<base_domain>. の形式を取ります。

表11.4 必要な DNS レコード
コンポーネントレコード説明

Kubernetes API

api.<cluster_name>.<base_domain>.

API ロードバランサーを特定するための DNS A/AAAA または CNAME レコード、および DNS PTR レコード。これらのレコードは、クラスター外のクライアントおよびクラスター内のすべてのノードで解決できる必要があります。

api-int.<cluster_name>.<base_domain>.

API ロードバランサーを内部的に識別するための DNS A/AAAA または CNAME レコード、および DNS PTR レコード。これらのレコードは、クラスター内のすべてのノードで解決できる必要があります。

重要

API サーバーは、Kubernetes に記録されるホスト名でワーカーノードを解決できる必要があります。API サーバーがノード名を解決できない場合、プロキシーされる API 呼び出しが失敗し、Pod からログを取得できなくなる可能性があります。

ルート

*.apps.<cluster_name>.<base_domain>.

アプリケーション Ingress ロードバランサーを参照するワイルドカード DNS A/AAAA または CNAME レコード。アプリケーション Ingress ロードバランサーは、Ingress コントローラー Pod を実行するマシンをターゲットにします。Ingress コントローラー Pod はデフォルトでコンピュートマシンで実行されます。これらのレコードは、クラスター外のクライアントおよびクラスター内のすべてのノードで解決できる必要があります。

たとえば、console-openshift-console.apps.<cluster_name>.<base_domain> は、OpenShift Container Platform コンソールへのワイルドカードルートとして使用されます。

コントロールプレーンマシン

<master><n>.<cluster_name>.<base_domain>.

ワーカーノードの各マシンを特定するための DNS A/AAAA または CNAME レコードおよび DNS PTR レコードこれらのレコードは、クラスター内のノードで解決できる必要があります。

コンピュートマシン

<worker><n>.<cluster_name>.<base_domain>.

ワーカーノードの各マシンを特定するための DNS A/AAAA または CNAME レコード、および DNS PTR レコード。これらのレコードは、クラスター内のノードで解決できる必要があります。

注記

OpenShift Container Platform 4.4 以降では、DNS 設定で etcd ホストおよび SRV レコードを指定する必要はありません。

ヒント

dig コマンドを使用して、名前および逆引き名前解決を確認することができます。

11.1.7.1.1. プラットフォーム "none" クラスターの DNS 設定例

このセクションでは、プラットフォーム none オプションを使用して OpenShift Container Platform をデプロイするための DNS 要件を満たす A および PTR レコード設定サンプルを提供します。サンプルは、特定の DNS ソリューションを選択するためのアドバイスを提供することを目的としていません。

この例では、クラスター名は ocp4 で、ベースドメインは example.com です。

プラットフォーム "none" クラスターの DNS A レコード設定の例

次の例は、プラットフォーム none オプションを使用したクラスター内の名前解決のサンプル A レコードを示す BIND ゾーンファイルです。

例11.1 DNS ゾーンデータベースのサンプル

$TTL 1W
@	IN	SOA	ns1.example.com.	root (
			2019070700	; serial
			3H		; refresh (3 hours)
			30M		; retry (30 minutes)
			2W		; expiry (2 weeks)
			1W )		; minimum (1 week)
	IN	NS	ns1.example.com.
	IN	MX 10	smtp.example.com.
;
;
ns1.example.com.		IN	A	192.168.1.5
smtp.example.com.		IN	A	192.168.1.5
;
helper.example.com.		IN	A	192.168.1.5
helper.ocp4.example.com.	IN	A	192.168.1.5
;
api.ocp4.example.com.		IN	A	192.168.1.5 1
api-int.ocp4.example.com.	IN	A	192.168.1.5 2
;
*.apps.ocp4.example.com.	IN	A	192.168.1.5 3
;
master0.ocp4.example.com.	IN	A	192.168.1.97 4
master1.ocp4.example.com.	IN	A	192.168.1.98 5
master2.ocp4.example.com.	IN	A	192.168.1.99 6
;
worker0.ocp4.example.com.	IN	A	192.168.1.11 7
worker1.ocp4.example.com.	IN	A	192.168.1.7 8
;
;EOF
1
Kubernetes API の名前解決を提供します。レコードは API ロードバランサーの IP アドレスを参照します。
2
Kubernetes API の名前解決を提供します。レコードは API ロードバランサーの IP アドレスを参照し、内部クラスター通信に使用されます。
3
ワイルドカードルートの名前解決を提供します。レコードは、アプリケーション Ingress ロードバランサーの IP アドレスを参照します。アプリケーション Ingress ロードバランサーは、Ingress コントローラー Pod を実行するマシンをターゲットにします。Ingress コントローラー Pod はデフォルトでコンピュートマシンで実行されます。
注記

この例では、同じロードバランサーが Kubernetes API およびアプリケーションの Ingress トラフィックに使用されます。実稼働のシナリオでは、API およびアプリケーション Ingress ロードバランサーを個別にデプロイし、それぞれのロードバランサーインフラストラクチャーを分離してスケーリングすることができます。

4 5 6
コントロールプレーンマシンの名前解決を提供します。
7 8
コンピュートマシンの名前解決を提供します。

プラットフォーム "none" クラスターの DNS PTR レコード設定の例

次の BIND ゾーンファイルの例は、プラットフォーム none オプションを使用したクラスターでの逆名前解決のサンプル PTR レコードを示しています。

例11.2 逆引きレコードの DNS ゾーンデータベースの例

$TTL 1W
@	IN	SOA	ns1.example.com.	root (
			2019070700	; serial
			3H		; refresh (3 hours)
			30M		; retry (30 minutes)
			2W		; expiry (2 weeks)
			1W )		; minimum (1 week)
	IN	NS	ns1.example.com.
;
5.1.168.192.in-addr.arpa.	IN	PTR	api.ocp4.example.com. 1
5.1.168.192.in-addr.arpa.	IN	PTR	api-int.ocp4.example.com. 2
;
97.1.168.192.in-addr.arpa.	IN	PTR	master0.ocp4.example.com. 3
98.1.168.192.in-addr.arpa.	IN	PTR	master1.ocp4.example.com. 4
99.1.168.192.in-addr.arpa.	IN	PTR	master2.ocp4.example.com. 5
;
11.1.168.192.in-addr.arpa.	IN	PTR	worker0.ocp4.example.com. 6
7.1.168.192.in-addr.arpa.	IN	PTR	worker1.ocp4.example.com. 7
;
;EOF
1
Kubernetes API の逆引き DNS 解決を提供します。PTR レコードは、API ロードバランサーのレコード名を参照します。
2
Kubernetes API の逆引き DNS 解決を提供します。PTR レコードは、API ロードバランサーのレコード名を参照し、内部クラスター通信に使用されます。
3 4 5
コントロールプレーンマシンの逆引き DNS 解決を提供します。
6 7
コンピュートマシンの逆引き DNS 解決を提供します。
注記

PTR レコードは、OpenShift Container Platform アプリケーションのワイルドカードには必要ありません。

11.1.7.2. プラットフォーム "none" 負荷分散要件

OpenShift Container Platform をインストールする前に、API およびアプリケーションの Ingress 負荷分散インフラストラクチャーをプロビジョニングする必要があります。実稼働のシナリオでは、API およびアプリケーション Ingress ロードバランサーを個別にデプロイし、それぞれのロードバランサーインフラストラクチャーを分離してスケーリングすることができます。

注記

これらの要件は、プラットフォーム none オプションを使用する単一ノード OpenShift クラスターには適用されません。

注記

Red Hat Enterprise Linux (RHEL) インスタンスを使用して API およびアプリケーションイングレスロードバランサーをデプロイする場合は、RHEL サブスクリプションを別途購入する必要があります。

負荷分散インフラストラクチャーは以下の要件を満たす必要があります。

  1. API ロードバランサー: プラットフォームと対話およびプラットフォームを設定するためのユーザー向けの共通のエンドポイントを提供します。以下の条件を設定します。

    • Layer 4 の負荷分散のみ。これは、Raw TCP、SSL パススルー、または SSL ブリッジモードと呼ばれます。SSL ブリッジモードを使用する場合は、API ルートの Server Name Indication (SNI) を有効にする必要があります。
    • ステートレス負荷分散アルゴリズム。オプションは、ロードバランサーの実装によって異なります。
    重要

    API ロードバランサーのセッションの永続性は設定しないでください。

    ロードバランサーのフロントとバックの両方で以下のポートを設定します。

    表11.5 API ロードバランサー
    ポートバックエンドマシン (プールメンバー)内部外部説明

    6443

    コントロールプレーンAPI サーバーのヘルスチェックプローブの /readyz エンドポイントを設定する必要があります。

    X

    X

    Kubernetes API サーバー

    22623

    コントロールプレーン

    X

     

    マシン設定サーバー

    注記

    ロードバランサーは、API サーバーが /readyz エンドポイントをオフにしてからプールから API サーバーインスタンスを削除するまで最大 30 秒かかるように設定する必要があります。/readyz の後の時間枠内でエラーが返されたり、正常になったりする場合は、エンドポイントが削除または追加されているはずです。5 秒または 10 秒ごとにプローブし、2 つの正常な要求が正常な状態になり、3 つの要求が正常な状態になりません。これらは十分にテストされた値です。

  2. Application Ingress ロードバランサー: クラスター外から送られるアプリケーショントラフィックの Ingress ポイントを提供します。Ingress ルーターの作業用の設定が OpenShift Container Platform クラスターに必要です。

    以下の条件を設定します。

    • Layer 4 の負荷分散のみ。これは、Raw TCP、SSL パススルー、または SSL ブリッジモードと呼ばれます。SSL ブリッジモードを使用する場合は、Ingress ルートの Server Name Indication (SNI) を有効にする必要があります。
    • 選択可能なオプションやプラットフォーム上でホストされるアプリケーションの種類に基づいて、接続ベースの永続化またはセッションベースの永続化が推奨されます。
    ヒント

    クライアントの実際の IP アドレスがアプリケーション Ingress ロードバランサーによって確認できる場合、ソースの IP ベースのセッション永続化を有効にすると、エンドツーエンドの TLS 暗号化を使用するアプリケーションのパフォーマンスを強化できます。

    ロードバランサーのフロントとバックの両方で以下のポートを設定します。

    表11.6 アプリケーション Ingress ロードバランサー
    ポートバックエンドマシン (プールメンバー)内部外部説明

    443

    デフォルトで Ingress コントローラー Pod、コンピュート、またはワーカーを実行するマシン。

    X

    X

    HTTPS トラフィック

    80

    デフォルトで Ingress コントローラー Pod、コンピュート、またはワーカーを実行するマシン。

    X

    X

    HTTP トラフィック

    注記

    ゼロ (0) コンピュートノードで 3 ノードクラスターをデプロイする場合、Ingress コントローラー Pod はコントロールプレーンノードで実行されます。3 ノードクラスターデプロイメントでは、HTTP および HTTPS トラフィックをコントロールプレーンノードにルーティングするようにアプリケーション Ingress ロードバランサーを設定する必要があります。

11.1.7.2.1. プラットフォーム "none" クラスターのロードバランサー設定の例

このセクションでは、プラットフォーム none オプションを使用してクラスターのロードバランシング要件を満たす API とアプリケーションの Ingress ロードバランサー設定の例を示します。この例は、HAProxy ロードバランサーの /etc/haproxy/haproxy.cfg 設定です。この例では、特定の負荷分散ソリューションを選択するためのアドバイスを提供することを目的としていません。

この例では、同じロードバランサーが Kubernetes API およびアプリケーションの Ingress トラフィックに使用されます。実稼働のシナリオでは、API およびアプリケーション Ingress ロードバランサーを個別にデプロイし、それぞれのロードバランサーインフラストラクチャーを分離してスケーリングすることができます。

注記

HAProxy をロードバランサーとして使用し、SELinux が enforcing に設定されている場合は、setsebool -P haproxy_connect_any=1 を実行して、HAProxy サービスが設定済みの TCP ポートにバインドできることを確認する必要があります。

例11.3 API およびアプリケーション Ingress ロードバランサーの設定例

global
  log         127.0.0.1 local2
  pidfile     /var/run/haproxy.pid
  maxconn     4000
  daemon
defaults
  mode                    http
  log                     global
  option                  dontlognull
  option http-server-close
  option                  redispatch
  retries                 3
  timeout http-request    10s
  timeout queue           1m
  timeout connect         10s
  timeout client          1m
  timeout server          1m
  timeout http-keep-alive 10s
  timeout check           10s
  maxconn                 3000
listen api-server-6443 1
  bind *:6443
  mode tcp
  server master0 master0.ocp4.example.com:6443 check inter 1s
  server master1 master1.ocp4.example.com:6443 check inter 1s
  server master2 master2.ocp4.example.com:6443 check inter 1s
listen machine-config-server-22623 2
  bind *:22623
  mode tcp
  server master0 master0.ocp4.example.com:22623 check inter 1s
  server master1 master1.ocp4.example.com:22623 check inter 1s
  server master2 master2.ocp4.example.com:22623 check inter 1s
listen ingress-router-443 3
  bind *:443
  mode tcp
  balance source
  server worker0 worker0.ocp4.example.com:443 check inter 1s
  server worker1 worker1.ocp4.example.com:443 check inter 1s
listen ingress-router-80 4
  bind *:80
  mode tcp
  balance source
  server worker0 worker0.ocp4.example.com:80 check inter 1s
  server worker1 worker1.ocp4.example.com:80 check inter 1s
1
ポート 6443 は Kubernetes API トラフィックを処理し、コントロールプレーンマシンを参照します。
2
ポート 22623 はマシン設定サーバートラフィックを処理し、コントロールプレーンマシンを参照します。
3
ポート 443 は HTTPS トラフィックを処理し、Ingress コントローラー Pod を実行するマシンを参照します。Ingress コントローラー Pod はデフォルトでコンピュートマシンで実行されます。
4
ポート 80 は HTTP トラフィックを処理し、Ingress コントローラー Pod を実行するマシンを参照します。Ingress コントローラー Pod はデフォルトでコンピュートマシンで実行されます。
注記

ゼロ (0) コンピュートノードで 3 ノードクラスターをデプロイする場合、Ingress コントローラー Pod はコントロールプレーンノードで実行されます。3 ノードクラスターデプロイメントでは、HTTP および HTTPS トラフィックをコントロールプレーンノードにルーティングするようにアプリケーション Ingress ロードバランサーを設定する必要があります。

ヒント

HAProxy をロードバランサーとして使用する場合は、HAProxy ノードで netstat -nltupe を実行して、ポート 644322623443、および 80haproxy プロセスがリッスンしていることを確認することができます。

11.1.8. 例: ボンディングと VLAN インターフェイスノードのネットワーク設定

次の agent-config.yaml ファイルは、ボンディングおよび VLAN インターフェイスのマニフェストの例です。

  apiVersion: v1alpha1
  kind: AgentConfig
  rendezvousIP: 10.10.10.14
  hosts:
    - hostname: master0
      role: master
      interfaces:
       - name: enp0s4
         macAddress: 00:21:50:90:c0:10
       - name: enp0s5
         macAddress: 00:21:50:90:c0:20
      networkConfig:
        interfaces:
          - name: bond0.300 1
            type: vlan 2
            state: up
            vlan:
              base-iface: bond0
              id: 300
            ipv4:
              enabled: true
              address:
                - ip: 10.10.10.14
                  prefix-length: 24
              dhcp: false
          - name: bond0 3
            type: bond 4
            state: up
            mac-address: 00:21:50:90:c0:10 5
            ipv4:
              enabled: false
            ipv6:
              enabled: false
            link-aggregation:
              mode: active-backup 6
              options:
                miimon: "150" 7
              port:
               - enp0s4
               - enp0s5
        dns-resolver: 8
          config:
            server:
              - 10.10.10.11
              - 10.10.10.12
        routes:
          config:
            - destination: 0.0.0.0/0
              next-hop-address: 10.10.10.10 9
              next-hop-interface: bond0.300 10
              table-id: 254
1 3
インターフェイスの名前。
2
インターフェイスのタイプ。以下の例では VLAN を作成します。
4
インターフェイスのタイプ。この例では、ボンドを作成します。
5
インターフェイスの MAC アドレス。
6
mode 属性は、ボンドモードを指定します。
7
MII リンクの監視頻度をミリ秒単位で指定します。この例では、ボンディングリンクを 150 ミリ秒ごとに検査します。
8
オプション:DNS サーバーの検索およびサーバー設定を指定します。
9
ノードトラフィックのネクストホップアドレス。これは、指定されたインターフェイスに設定される IP アドレスと同じサブネットにある必要があります。
10
ノードトラフィックのネクストホップインターフェイス。

11.1.9. 例: ボンディングと SR-IOV デュアル NIC ノードのネットワーク設定

重要

SR-IOV デバイスの NIC パーティショニングの有効化に関連する Day 1 操作のサポートは、テクノロジープレビュー機能のみです。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビューの機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。

Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。

次の agent-config.yaml ファイルは、ボンドと SR-IOV インターフェイスを備えたデュアルポート NIC のマニフェストの例です。

apiVersion: v1alpha1
kind: AgentConfig
rendezvousIP: 10.10.10.14
hosts:
  - hostname: worker-1
    interfaces:
      - name: eno1
        macAddress: 0c:42:a1:55:f3:06
      - name: eno2
        macAddress: 0c:42:a1:55:f3:07
    networkConfig: 1
      interfaces: 2
        - name: eno1 3
          type: ethernet 4
          state: up
          mac-address: 0c:42:a1:55:f3:06
          ipv4:
            enabled: true
            dhcp: false 5
          ethernet:
            sr-iov:
              total-vfs: 2 6
          ipv6:
            enabled: false
        - name: sriov:eno1:0
          type: ethernet
          state: up 7
          ipv4:
            enabled: false 8
          ipv6:
            enabled: false
            dhcp: false
        - name: sriov:eno1:1
          type: ethernet
          state: down
        - name: eno2
          type: ethernet
          state: up
          mac-address: 0c:42:a1:55:f3:07
          ipv4:
            enabled: true
          ethernet:
            sr-iov:
              total-vfs: 2
          ipv6:
            enabled: false
        - name: sriov:eno2:0
          type: ethernet
          state: up
          ipv4:
            enabled: false
          ipv6:
            enabled: false
        - name: sriov:eno2:1
          type: ethernet
          state: down
        - name: bond0
          type: bond
          state: up
          min-tx-rate: 100 9
          max-tx-rate: 200 10
          link-aggregation:
            mode: active-backup 11
            options:
              primary: sriov:eno1:0 12
            port:
              - sriov:eno1:0
              - sriov:eno2:0
          ipv4:
            address:
              - ip: 10.19.16.57 13
                prefix-length: 23
            dhcp: false
            enabled: true
          ipv6:
            enabled: false
          dns-resolver:
            config:
              server:
                - 10.11.5.160
                - 10.2.70.215
          routes:
            config:
              - destination: 0.0.0.0/0
                next-hop-address: 10.19.17.254
                next-hop-interface: bond0 14
                table-id: 254
1
networkConfig フィールドには、ホストのネットワーク設定に関する情報が含まれ、サブフィールドには、interfacesdns-resolver、および routes が含まれます。
2
interfaces フィールドは、ホスト用に定義されたネットワークインターフェイスの配列です。
3
インターフェイスの名前。
4
インターフェイスのタイプ。この例では、イーサネットインターフェイスを作成します。
5
厳密に必要ではない場合、物理機能 (PF) の DHCP を無効にするには、これを false に設定します。
6
これを、インスタンス化する SR-IOV 仮想機能 (VF) の数に設定します。
7
これを up に設定します。
8
ボンドに接続された VF の IPv4 アドレス指定を無効にするには、これを false に設定します。
9
VF の最小伝送速度 (Mbps) を設定します。このサンプル値は、100 Mbps のレートを設定します。
  • この値は、最大伝送レート以下である必要があります。
  • Intel NIC は min-tx-rate パラメーターをサポートしていません。詳細は、BZ#1772847 を参照してください。
10
VF の最大伝送速度 (Mbps) を設定します。このサンプル値は、200 Mbps のレートを設定します。
11
目的のボンディングモードを設定します。
12
ボンディングインターフェイスの優先ポートを設定します。プライマリーデバイスは、最初に使用されるボンディングインターフェイスであり、障害が発生しないかぎり、破棄されません。この設定が特に役立つのは、ボンディングインターフェイスの NIC の 1 つが高速なため、大規模な負荷に対応できる場合です。この設定は、ボンディングインターフェイスが active-backup モード (モード 1) および balance-tlb (モード 5) の場合のみに有効です。
13
ボンドインターフェイスの静的 IP アドレスを設定します。これはノードの IP アドレスです。
14
デフォルトルートのゲートウェイとして bond0 を設定します。

11.1.10. ベアメタルのサンプル install-config.yaml ファイル

install-config.yaml ファイルをカスタマイズして、OpenShift Container Platform クラスターのプラットフォームに関する詳細を指定するか、必要なパラメーターの値を変更することができます。

apiVersion: v1
baseDomain: example.com 1
compute: 2
- name: worker
  replicas: 0 3
controlPlane: 4
  name: master
  replicas: 1 5
metadata:
  name: sno-cluster 6
networking:
  clusterNetwork:
  - cidr: 10.128.0.0/14 7
    hostPrefix: 23 8
  networkType: OVNKubernetes 9
  serviceNetwork: 10
  - 172.30.0.0/16
platform:
  none: {} 11
fips: false 12
pullSecret: '{"auths": ...}' 13
sshKey: 'ssh-ed25519 AAAA...' 14
1
クラスターのベースドメイン。すべての DNS レコードはこのベースのサブドメインである必要があり、クラスター名が含まれる必要があります。
2 4
controlPlane セクションは単一マッピングですが、compute セクションはマッピングのシーケンスになります。複数の異なるデータ構造の要件を満たすには、compute セクションの最初の行はハイフン - で始め、controlPlane セクションの最初の行はハイフンで始めることができません。1 つのコントロールプレーンプールのみが使用されます。
3
このパラメーターは、インストールプロセスをトリガーする前に、エージェントベースのインストールが検出を待機するコンピュートマシンの数を制御します。これは、生成された ISO で起動する必要があるコンピューティングマシンの数です。
注記

3 ノードクラスターをインストールする場合は、Red Hat Enterprise Linux CoreOS (RHCOS) マシンをインストールする際にコンピュートマシンをデプロイしないでください。

5
クラスターに追加するコントロールプレーンマシンの数。クラスターをこれらの値をクラスターの etcd エンドポイント数として使用するため、値はデプロイするコントロールプレーンマシンの数に一致する必要があります。
6
DNS レコードに指定したクラスター名。
7
Pod IP アドレスの割り当てに使用する IP アドレスのブロック。このブロックは既存の物理ネットワークと重複できません。これらの IP アドレスは Pod ネットワークに使用されます。外部ネットワークから Pod にアクセスする必要がある場合、ロードバランサーおよびルーターを、トラフィックを管理するように設定する必要があります。
注記

クラス E の CIDR 範囲は、将来の使用のために予約されています。クラス E CIDR 範囲を使用するには、ネットワーク環境がクラス E CIDR 範囲内の IP アドレスを受け入れるようにする必要があります。

8
それぞれの個別ノードに割り当てるサブネット接頭辞長。たとえば、hostPrefix23 に設定されている場合、各ノードに指定の cidr から /23 サブネットが割り当てられます。これにより、510 (2^(32 - 23) - 2) Pod IP アドレスが許可されます。外部ネットワークからのノードへのアクセスを提供する必要がある場合には、ロードバランサーおよびルーターを、トラフィックを管理するように設定します。
9
インストールするクラスターネットワークプラグイン。サポートされる値はデフォルト値の OVNKubernetes のみです。
10
サービス IP アドレスに使用する IP アドレスプール。1 つの IP アドレスプールのみを入力できます。このブロックは既存の物理ネットワークと重複できません。外部ネットワークからサービスにアクセスする必要がある場合、ロードバランサーおよびルーターを、トラフィックを管理するように設定します。
11
単一ノードクラスターの場合は、プラットフォームを none に設定しなくてはなりません。マルチノードクラスターの場合は、プラットフォームを vspherebaremetal、または none に設定できます。
注記

プラットフォームを vsphere または baremetal に設定すると、次の 3 つの方法でクラスターノードの IP アドレスエンドポイントを設定できます。

  • IPv4
  • IPv6
  • IPv4 と IPv6 の並列 (デュアルスタック)

デュアルスタックネットワーキングの例

networking:
  clusterNetwork:
    - cidr: 172.21.0.0/16
      hostPrefix: 23
    - cidr: fd02::/48
      hostPrefix: 64
  machineNetwork:
    - cidr: 192.168.11.0/16
    - cidr: 2001:DB8::/32
  serviceNetwork:
    - 172.22.0.0/16
    - fd03::/112
  networkType: OVNKubernetes
platform:
  baremetal:
    apiVIPs:
    - 192.168.11.3
    - 2001:DB8::4
    ingressVIPs:
    - 192.168.11.4
    - 2001:DB8::5

12
FIPS モードを有効または無効にするかどうか。デフォルトでは、FIPS モードは有効にされません。FIPS モードが有効にされている場合、OpenShift Container Platform が実行される Red Hat Enterprise Linux CoreOS (RHCOS) マシンがデフォルトの Kubernetes 暗号スイートをバイパスし、代わりに RHCOS で提供される暗号モジュールを使用します。
重要

FIPS モードでブートされた Red Hat Enterprise Linux (RHEL) または Red Hat Enterprise Linux CoreOS (RHCOS) を実行する場合、OpenShift Container Platform コアコンポーネントは、x86_64、ppc64le、および s390x アーキテクチャーのみで、FIPS 140-2/140-3 検証のために NIST に提出された RHEL 暗号化ライブラリーを使用します。

13
このプルシークレットを使用し、OpenShift Container Platform コンポーネントのコンテナーイメージを提供する Quay.io など、組み込まれた各種の認証局によって提供されるサービスで認証できます。
14
Red Hat Enterprise Linux CoreOS (RHCOS) の core ユーザーの SSH 公開鍵。
注記

インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、ssh-agent プロセスが使用する SSH キーを指定します。

11.1.11. agent.ISO の作成前の検証チェック

Agent-based Installer は、ISO が作成される前に、ユーザー定義の YAML ファイルに対して検証チェックを実行します。検証に成功すると、agent.ISO が作成されます。

install-config.yaml

  • baremetalvsphere、および none プラットフォームがサポートされています。
  • none プラットフォームの場合、networkType パラメーターは OVNKubernetes である必要があります。
  • apiVIPs および ingressVIPs パラメーターは、ベアメタルおよび vSphere プラットフォームに設定する必要があります。
  • agent-config.yaml ファイルに相当するベアメタルプラットフォーム設定の一部のホスト固有フィールドは無視されます。これらのフィールドが設定されている場合、警告メッセージがログに記録されます。

agent-config.yaml

  • 各インターフェイスには、定義された MAC アドレスが必要です。また、すべてのインターフェイスに異なる MAC アドレスが必要です。
  • ホストごとに少なくとも 1 つのインターフェイスを定義する必要があります。
  • World Wide Name (WWN) ベンダーエクステンションは、ルートデバイスのヒントではサポートされません。
  • host オブジェクトの role パラメーターの値は master または worker のいずれかである必要があります。

11.1.11.1. ZTP マニフェスト

agent-cluster-install.yaml

  • IPv6 の場合、networkType パラメーターでサポートされる唯一の値は OVNKubernetes です。OpenShiftSDN 値は、IPv4 にのみ使用できます。

cluster-image-set.yaml

  • ReleaseImage パラメーターは、インストーラーで定義されるリリースと一致する必要があります。

11.1.12. 次のステップ

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.