2.2. 環境要件
以下のセクションでは、OpenShift Container Platform 設定を含む環境の要件を定義します。これには、ネットワークの考慮事項や Git リポジトリーのアクセス、ストレージおよびクラウドインフラストラクチャープロバイダーなどの外部サービスへのアクセスなどの要件が含まれます。
2.2.1. DNS 要件
OpenShift Container Platform では、完全に機能する DNS サーバーが環境になければなりません。この場合、DNS ソフトウェアを実行する別個のホストを使用することが適しており、これによりプラットフォームで実行されるホストおよびコンテナーに対して名前解決を実行することができます。
各ホストの /etc/hosts ファイルにエントリーを追加するだけでは不十分です。このファイルはプラットフォームで実行されるコンテナーにはコピーされません。
OpenShift Container Platform の主要コンポーネントはコンテナーの内部で実行され、名前解決に以下のプロセスを使用します。
- デフォルトで、コンテナーはホストから DNS 設定ファイル (/etc/resolv.conf) を受信します。
- OpenShift Container Platform は Pod の最初のネームサーバーをノードの IP アドレスに設定します。
OpenShift Container Platform 3.2 の時点で、dnsmasq はすべてのマスターおよびノードで自動的に設定されます。Pod は DNS としてノードを使用し、ノードは要求を転送します。デフォルトで、dnsmasq はポート 53 でリッスンするようにノード上に設定されます。 そのため、ノードはその他の種類の DNS アプリケーションを実行することができません。
NetworkManager はネットワークに自動的に接続するシステムの検出と設定を行うプログラムであり、dnsmasq を DNS IP アドレスで設定するためにノードで必要となります。
NM_CONTROLLED はデフォルトで yes に設定されます。NM_CONTROLLED が no に設定されている場合、NetworkManager のディスパッチスクリプトは関連する origin-upstream-dns.conf dnsmasq ファイルを作成せず、dnsmasq を手動で設定する必要があります。
同様に、ネットワークスクリプト (例: /etc/sysconfig/network-scripts/ifcfg-em1) で PEERDNS パラメーターが no に設定されている場合、dnsmasq ファイルは生成されず、Ansible のインストールは失敗します。PEERDNS 設定が yes に設定されていることを確認してください。
以下はレコードのサンプルセットです。
master1 A 10.64.33.100 master2 A 10.64.33.103 node1 A 10.64.33.101 node2 A 10.64.33.102
適切に機能する DNS 環境がない場合には、以下に関連する障害が発生する可能性があります。
- Ansible ベースの参照スクリプトによる製品のインストール
- インフラストラクチャーコンテナー (レジストリー、ルーター) のデプロイ
- OpenShift Container Platform web コンソールへのアクセス (IP アドレスのみではアクセスできないため)
2.2.1.1. ホストを DNS を使用するように設定する
環境内の各ホストが DNS サーバーのホスト名を解決するように設定されていることを確認します。ホストの DNS 解決の設定は、DHCP が有効にされているかどうかによって異なります。DHCP の場合:
- DHCP が無効にされている場合、ネットワークインターフェイスを static (静的) に設定し、DNS ネームサーバーを NetworkManager に追加します。
- DHCP が有効にされている場合、NetworkManager ディスパッチスクリプトは DHCP 設定に基づいて DNS を自動的に設定します。
ホストが DNS サーバーで解決できることを確認するには、以下を実行します。
/etc/resolv.conf の内容を確認します。
$ cat /etc/resolv.conf # Generated by NetworkManager search example.com nameserver 10.64.33.1 # nameserver updated by /etc/NetworkManager/dispatcher.d/99-origin-dns.sh
この例では、10.64.33.1 が DNS サーバーのアドレスです。
/etc/resolv.conf に一覧表示されている DNS サーバーが OpenShift Container Platform 環境のすべてのマスターおよびノードの IP アドレスに対してホスト名を解決できることをテストします。
$ dig <node_hostname> @<IP_address> +short
以下は例になります。
$ dig master.example.com @10.64.33.1 +short 10.64.33.100 $ dig node1.example.com @10.64.33.1 +short 10.64.33.101
2.2.1.2. DNS ワイルドカードの設定
オプションとして、ルーターが使用するワイルドカードを設定し、新規ルートが追加される際に DNS 設定を更新しなくてもよいようにします。ルーターのワイルドカードを設定する場合は、Ansible インベントリーファイル の設定時に openshift_master_default_subdomain パラメーターをこの値に設定します。
DNS ゾーンのワイルドカードは、最終的には OpenShift Container Platform ルーター の IP アドレスに解決される必要があります。
たとえば、有効期間 (TTL) の低い値が設定されていて、ルーターがデプロイされるホストのパブリック IP アドレスをポイントする cloudapps のワイルドカード DNS エントリーを作成します。
*.cloudapps.example.com. 300 IN A 192.168.133.2
各ノードホストの /etc/resolv.conf ファイルで、ワイルドカードエントリーを持つ DNS サーバーがネームサーバーとして一覧表示されていないこと、またはワイルドカードドメインが検索一覧に表示されていないことを確認してください。そうでない場合、OpenShift Container Platform が管理するコンテナーはホスト名を適切に解決できないことがあります。
2.2.1.3. ノードホスト名の設定
クラウドプロバイダーに統合されていないクラスターを設定する場合、ノードのホスト名を正しく設定する必要があります。各ノードのホスト名は解決可能である必要があり、各ノードは相互に到達できる必要があります。
ノードが他のノードに到達できることを確認するには、以下を実行します。
1 つのノードでホスト名を取得します。
$ hostname master-1.example.com
同じノードで、ホストの完全修飾ドメイン名を取得します。
$ hostname -f master-1.example.com
別のノードから、この最初のノードに到達できることを確認します。
$ ping master-1.example.com -c 1 PING master-1.example.com (172.16.122.9) 56(84) bytes of data. 64 bytes from master-1.example.com (172.16.122.9): icmp_seq=1 ttl=64 time=0.319 ms --- master-1.example.com ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 0.319/0.319/0.319/0.000 ms
