Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

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

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

重要

仮想化またはクラウド環境で OpenShift Container Platform クラスターのインストールを試行する前に、guidelines for deploying OpenShift Container Platform on non-tested platforms にある情報を確認してください。

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>. の形式を取ります。

Expand
表1.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 コマンドを使用して、名前および逆引き名前解決を確認することができます。

1.7.1.1. プラットフォーム "none" クラスターの DNS 設定例
リンクのコピー

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

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

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

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

例1.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
Copy to Clipboard Toggle word wrap
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 レコードを示しています。

例1.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
Copy to Clipboard Toggle word wrap
1
Kubernetes API の逆引き DNS 解決を提供します。PTR レコードは、API ロードバランサーのレコード名を参照します。
2
Kubernetes API の逆引き DNS 解決を提供します。PTR レコードは、API ロードバランサーのレコード名を参照し、内部クラスター通信に使用されます。
3 4 5
コントロールプレーンマシンの逆引き DNS 解決を提供します。
6 7
コンピュートマシンの逆引き DNS 解決を提供します。
注記

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

1.7.2. プラットフォーム "none" 負荷分散要件
リンクのコピー

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

注記

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

注記

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

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

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

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

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

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

    Expand
    表1.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 暗号化を使用するアプリケーションのパフォーマンスを強化できます。

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

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

    443

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

    X

    X

    HTTPS トラフィック

    80

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

    X

    X

    HTTP トラフィック

    注記

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

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 ポートにバインドできることを確認する必要があります。

例1.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
Copy to Clipboard Toggle word wrap
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 を実行して、ポート 6443、22623、443、および 80 で haproxy プロセスがリッスンしていることを確認することができます。

トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

Theme

© 2025 Red Hat