8.6. 外部リソースへのアクセスを制限するための Egress ファイアウォールの使用
OpenShift Container Platform クラスター管理者は egress ファイアウォールを使用して、一部またはすべての Pod がクラスター内からアクセスできる外部 IP アドレスを制限できます。egress ファイアウォールポリシーは以下のシナリオをサポートします。
- Pod の接続を内部ホストに制限し、パブリックインターネットへの接続を開始できないようにする。
- Pod の接続をパブリックインターネットに制限し、OpenShift Container Platform クラスター外にある内部ホストへの接続を開始できないようにする。
- Pod が到達不能な状態の指定された内部サブネットまたはホストに到達できないようにする。
egress ポリシーは、IP アドレス範囲を CIDR 形式で指定するか、または DNS 名を指定して設定できます。たとえば、指定された IP 範囲への <project_A>
アクセスを許可しつつ、<project_B>
への同じアクセスを拒否することができます。または、アプリケーション開発者が (Python) pip mirror からの更新を制限したり、更新を承認されたソースからの更新のみに強制的に制限したりすることができます。
Pod アクセスを egress ポリシーで制限するには、ovs-multitenant または ovs-networkpolicy プラグインを有効にする 必要があります。
ovs-multitenant プラグインを使用している場合、egress ポリシーはプロジェクトごとに 1 つのポリシーとのみ互換性を持ち、グローバルプロジェクトなどのネットワークを共有するプロジェクトでは機能しません。
プロジェクト管理者は、EgressNetworkPolicy
オブジェクトを作成することも、プロジェクトで作成するオブジェクトを編集することもできません。また、EgressNetworkPolicy
の作成に関連して他のいくつかの制限があります。
-
デフォルト
プロジェクト (およびoc adm pod-network make-projects-global
でグローバルにされたその他のプロジェクト) には egress ポリシーを設定することができません。 -
(
oc adm pod-network join-projects
を使用して) 2 つのプロジェクトをマージする場合、マージしたプロジェクトのいずれでも egress ポリシーを使用することはできません。 - いずれのプロジェクトも複数の egress ポリシーオブジェクトを持つことができません。
上記の制限のいずれかに違反すると、プロジェクトの egress ポリシーに障害が発生し、すべての外部ネットワークトラフィックがドロップされる可能性があります。
oc
コマンドまたは REST API を使用して egress ポリシーを設定します。oc [create|replace|delete]
を使用すると、EgressNetworkPolicy
オブジェクトを操作できます。api/swagger-spec/oapi-v1.json ファイルには、オブジェクトを実際に機能させる方法についての API レベルの詳細情報が含まれます。
egress ポリシーを設定するには、以下を実行します。
- 対象とするプロジェクトに移動します。
以下の例のように、使用する必要のあるポリシー設定で JSON ファイルを作成します。
{ "kind": "EgressNetworkPolicy", "apiVersion": "v1", "metadata": { "name": "default" }, "spec": { "egress": [ { "type": "Allow", "to": { "cidrSelector": "1.2.3.0/24" } }, { "type": "Allow", "to": { "dnsName": "www.foo.com" } }, { "type": "Deny", "to": { "cidrSelector": "0.0.0.0/0" } } ] } }
上記のサンプルがプロジェクトに追加されると、IP 範囲
1.2.3.0/24
およびドメイン名www.foo.com
へのトラフィックが許可されますが、その他のすべての外部 IP アドレスへのアクセスは拒否されます。このポリシーは外部トラフィックにのみ適用されるため、その他すべての Pod へのトラフィックは影響を受けません。EgressNetworkPolicy
のルールは順番にチェックされ、一致する最初のルールが実施されます。上記の例の 3 つの例を逆順に定義した場合、0.0.0.0/0
ルールが最初にチェックされ、すべてのトラフィックに一致し、それらすべてを拒否するため、1.2.3.0/24
およびwww.foo.com
へのトラフィックは許可されません。ドメイン名の更新は、ローカルの非権威サーバーのドメインの TTL (time to live) 値に基づいてポーリングされます。Pod は必要な場合には、同じローカルのネームサーバーのドメインを解決する必要もあります。そうしないと、egress ネットワークポリシーコントローラーと Pod で認識されるドメインの IP アドレスが異なり、egress ネットワークが予想通りに実施されない場合があります。egress ネットワークポリシーコントローラーおよび Pod は同じローカルネームサーバーを非同期にポーリングするため、Pod が egress コントローラーの前に更新された IP を取得するという競合状態が発生する可能性があります。この現時点の制限により、
EgressNetworkPolicy
のドメイン名の使用は、IP アドレスの変更が頻繁に生じないドメインの場合にのみ推奨されます。注記egress ファイアウォールは、DNS 解決用に Pod が置かれるノードの外部インターフェイスに Pod が常にアクセスできるようにします。DNS 解決がローカルノード上のいずれかによって処理されない場合は、Pod でドメイン名を使用している場合には DNS サーバーの IP アドレスへのアクセスを許可する egress ファイアウォールを追加する必要があります。
JSON ファイルを使用して EgressNetworkPolicy オブジェクトを作成します。
$ oc create -f <policy>.json
ルート を作成してサービスを公開すると、EgressNetworkPolicy
は無視されます。Egress ネットワークポリシーサービスのエンドポイントのフィルターは、ノード kubeproxy
で実行されます。ルーターが使用される場合は、kubeproxy
はバイパスされ、egress ネットワークポリシーの施行は適用されません。管理者は、ルートを作成するためのアクセスを制限してこのバイパスを防ぐことができます。
8.6.1. 外部リソースから Pod トラフィックを認識可能にするための Egress ルーターの使用
OpenShift Container Platform egress ルーターは、他の用途で使用されていないプライベートソース IP アドレスを使用して、指定されたリモートサーバーにトラフィックをリダイレクトするサービスを実行します。このサービスにより、Pod はホワイトリスト IP アドレスからのアクセスのみを許可するように設定されたサーバーと通信できるようになります。
egress ルーターはすべての発信接続のために使用されることが意図されていません。多数の egress ルーターを作成することで、ネットワークハードウェアの制限を引き上げる可能性があります。たとえば、すべてのプロジェクトまたはアプリケーションに egress ルーターを作成すると、ソフトウェアの MAC アドレスのフィルターにフォールバックする前にネットワークインターフェイスが処理できるローカル MAC アドレス数の上限を超えてしまう可能性があります。
現時点で、egress ルーターには Amazon AWS, Azure Cloud またはレイヤー 2 操作をサポートしないその他のクラウドプラットフォームとの互換性がありません。 それらに macvlan トラフィックとの互換性がないためです。
デプロイメントに関する考慮事項
Egress ルーターは 2 つ目の IP アドレスおよび MAC アドレスをノードのプライマリーネットワークインターフェイスに追加します。OpenShift Container Platform をベアメタルで実行していない場合は、ハイパーバイザーまたはクラウドプロバイダーが追加のアドレスを許可するように設定する必要があります。
- Red Hat OpenStack Platform
OpenShift Container Platform を Red Hat OpenStack Platform にデプロイしている場合、OpenStack 環境で IP および MAC アドレスのホワイトリストを作成する必要があります。作成しないと、通信は失敗します。
neutron port-update $neutron_port_uuid \ --allowed_address_pairs list=true \ type=dict mac_address=<mac_address>,ip_address=<ip_address>
- Red Hat Enterprise Virtualization
-
Red Hat Enterprise Virtualization を使用している場合は、
EnableMACAntiSpoofingFilterRules
をfalse
に設定する必要が あります。 - VMware vSphere
- VMware vSphere を使用している場合は、vSphere 標準スイッチのセキュリティー保護についての VMWare ドキュメント を参照してください。vSphere Web クライアントからホストの仮想スイッチを選択して、VMWare vSphere デフォルト設定を表示し、変更します。
とくに、以下が有効にされていることを確認します。
Egress ルーターモード
egress ルーターは、リダイレクトモード と HTTP プロキシーモード および DNS プロキシーモード の 3 つの異なるモードで実行できます。リダイレクトモードは、HTTP および HTTPS 以外のすべてのサービスで機能します。HTTP および HTTPS サービスの場合は、HTTP プロキシーモードを使用します。IP アドレスまたはドメイン名を持つ TCP ベースのサービスの場合は、DNS プロキシーモードを使用します。
8.6.1.1. リダイレクトモードでの Egress ルーター Pod のデプロイ
リダイレクトモードでは、egress ルーターは、トラフィックを独自の IP アドレスから 1 つ以上の宛先 IP アドレスにリダイレクトするために iptables ルールをセットアップします。予約されたソース IP アドレスを使用する必要のあるクライアント Pod は、宛先 IP に直接接続するのでなく、egress ルーターに接続するように変更される必要があります。
以下を使用して Pod 設定を作成します。
apiVersion: v1 kind: Pod metadata: name: egress-1 labels: name: egress-1 annotations: pod.network.openshift.io/assign-macvlan: "true" 1 spec: initContainers: - name: egress-router image: registry.redhat.io/openshift3/ose-egress-router securityContext: privileged: true env: - name: EGRESS_SOURCE 2 value: 192.168.12.99/24 - name: EGRESS_GATEWAY 3 value: 192.168.12.1 - name: EGRESS_DESTINATION 4 value: 203.0.113.25 - name: EGRESS_ROUTER_MODE 5 value: init containers: - name: egress-router-wait image: registry.redhat.io/openshift3/ose-pod nodeSelector: site: springfield-1 6
- 1
- プライマリーネットワークインターフェイスで Macvlan ネットワークインターフェイスを作成し、これを Pod のネットワークプロジェクトに移行してから egress-router コンテナーを起動します。
"true"
の周りの引用符をそのまま残します。これらを省略すると、エラーが発生します。プライマリーネットワークインターフェイス以外のネットワークインターフェイスで Macvlan インターフェイスを作成するには、アノテーションの値を該当インターフェイスの名前に設定します。たとえば、eth1
を使用します。 - 2
- ノードが置かれており、クラスター管理者がこの Pod で使用するために予約している物理ネットワークの IP アドレスです。オプションとして、サブネットの長さ
/24
接尾辞を組み込み、ローカルサブネットへの適切なルートがセットアップされるようにできます。サブネットの長さを指定しない場合、egress ルーターはEGRESS_GATEWAY
変数で指定されたホストにのみアクセスでき、サブネットの他のホストにはアクセスできません。 - 3
- ノードで使用されるデフォルトゲートウェイと同じ値です。
- 4
- トラフィックの送信先となる外部サーバー。この例では、Pod の接続は 203.0.113.25 にリダイレクトされます。 ソース IP アドレスは 192.168.12.99 です。
- 5
- これは egress ルーターイメージに対して、これが init コンテナーとしてデプロイされていることを示しています。以前のバージョンの OpenShift Container Platform (および egress ルーターイメージ) はこのモードをサポートしておらず、通常のコンテナーとして実行される必要がありました。
- 6
- Pod はラベル
site=springfield-1
の設定されたノードにのみデプロイされます。
上記の定義を使用して Pod を作成します。
$ oc create -f <pod_name>.json
Pod が作成されているかどうかを確認するには、以下を実行します。
$ oc get pod <pod_name>
egresss ルーターを参照するサービスを作成し、他の Pod が Pod の IP アドレスを見つけられるようにします。
apiVersion: v1 kind: Service metadata: name: egress-1 spec: ports: - name: http port: 80 - name: https port: 443 type: ClusterIP selector: name: egress-1
Pod がこのサービスに接続できるようになります。これらの接続は、予約された egress IP アドレスを使用して外部サーバーの対応するポートにリダイレクトされます。
egress ルーターのセットアップは、openshift3/ose-egress-router イメージで作成される init コンテナーで実行され、このコンテナーは Macvlan インターフェイスを設定し、iptables
ルールをセットアップできるように特権モード実行されます。iptables
ルールのセットアップ終了後に、これは終了し、openshift3/ose-pod コンテナーが Pod が強制終了されるまで (特定のタスクを実行しない) 実行状態になります。
環境変数は egress-router イメージに対し、使用するアドレスを指示します。 これは、EGRESS_SOURCE
を IP アドレスとして、また EGRESS_GATEWAY
をゲートウェイとして使用するよう Macvlan を設定します。
NAT ルールが設定され、Pod のクラスター IP アドレスの TCP または UDP ポートへの接続が EGRESS_DESTINATION
の同じポートにリダイレクトされるようにします。
クラスター内の一部のノードのみが指定されたソース IP アドレスを要求でき、指定されたゲートウェイを使用できる場合、受け入れ可能なノードを示す nodeName
または nodeSelector
を指定することができます。
8.6.1.2. 複数の宛先へのリダイレクト
前の例では、任意のポートでの egress Pod (またはその対応するサービス) への接続は単一の宛先 IP にリダイレクトされます。ポートに応じて異なる宛先 IP を設定することもできます。
apiVersion: v1 kind: Pod metadata: name: egress-multi labels: name: egress-multi annotations: pod.network.openshift.io/assign-macvlan: "true" spec: initContainers: - name: egress-router image: registry.redhat.io/openshift3/ose-egress-router securityContext: privileged: true env: - name: EGRESS_SOURCE 1 value: 192.168.12.99/24 - name: EGRESS_GATEWAY value: 192.168.12.1 - name: EGRESS_DESTINATION 2 value: | 80 tcp 203.0.113.25 8080 tcp 203.0.113.26 80 8443 tcp 203.0.113.26 443 203.0.113.27 - name: EGRESS_ROUTER_MODE value: init containers: - name: egress-router-wait image: registry.redhat.io/openshift3/ose-pod
EGRESS_DESTINATION
の各行は、以下の 3 つのタイプのいずれかになります。
-
<port> <protocol> <IP_address>
: これは、指定される<port>
への着信接続が指定される<IP_address>
の同じポートにリダイレクトされる必要があることを示しています。<protocol>
はtcp
またはudp
のいずれかになります。上記の例では、最初の行がローカルポート 80 から 203.0.113.25 のポート 80 にトラフィックをリダイレクトしています。 -
<port> <protocol> <IP_address> <remote_port>
: 接続が<IP_address>
の別の<remote_port>
にリダイレクトされるのを除き、上記と同じになります。この例では、2 番目と 3 番目の行ではローカルポート 8080 および 8443 を 203.0.113.26 のリモートポート 80 および 443 にリダイレクトしています。 -
<fallback_IP_address>
:EGRESS_DESTINATION
の最後の行が単一 IP アドレスである場合、それ以外のポートの接続はその IP アドレス (上記の例では 203.0.113.27) の対応するポートにリダイレクトされます。フォールバック IP アドレスがない場合、他のポートでの接続は単純に拒否されます。 )
8.6.1.3. ConfigMap の使用による EGRESS_DESTINATION の指定
宛先マッピングのセットのサイズが大きいか、またはこれが頻繁に変更される場合、ConfigMap を使用して一覧を外部で維持し、egress ルーター Pod がそこから一覧を読み取れるようにすることができます。これには、プロジェクト管理者が ConfigMap を編集できるという利点がありますが、これには特権付きコンテナーが含まれるため、管理者は Pod 定義を直接編集することはできません。
EGRESS_DESTINATION
データを含むファイルを作成します。$ cat my-egress-destination.txt # Egress routes for Project "Test", version 3 80 tcp 203.0.113.25 8080 tcp 203.0.113.26 80 8443 tcp 203.0.113.26 443 # Fallback 203.0.113.27
空の行とコメントをこのファイルに追加できることに注意してください。
このファイルから ConfigMap オブジェクトを作成します。
$ oc delete configmap egress-routes --ignore-not-found $ oc create configmap egress-routes \ --from-file=destination=my-egress-destination.txt
ここで、
egress-routes
は作成される ConfigMap オブジェクトの名前で、my-egress-destination.txt
はデータの読み取り元のファイルの名前です。前述のように egress ルーター Pod 定義を作成しますが、ConfigMap を環境セクションの
EGRESS_DESTINATION
に指定します。... env: - name: EGRESS_SOURCE 1 value: 192.168.12.99/24 - name: EGRESS_GATEWAY value: 192.168.12.1 - name: EGRESS_DESTINATION valueFrom: configMapKeyRef: name: egress-routes key: destination - name: EGRESS_ROUTER_MODE value: init ...
- 1
- ノードが置かれており、クラスター管理者がこの Pod で使用するために予約している物理ネットワークの IP アドレスです。オプションとして、サブネットの長さ
/24
接尾辞を組み込み、ローカルサブネットへの適切なルートがセットアップされるようにできます。サブネットの長さを指定しない場合、egress ルーターはEGRESS_GATEWAY
変数で指定されたホストにのみアクセスでき、サブネットの他のホストにはアクセスできません。
egress ルーターは、ConfigMap が変更されても自動的に更新されません。更新を取得するには Pod を再起動します。
8.6.1.4. Egress ルーター HTTP プロキシー Pod のデプロイ
HTTP プロキシーモードでは、egress ルーターはポート 8080
で HTTP プロキシーとして実行されます。これは、HTTP または HTTPS ベースのサービスと通信するクライアントの場合にのみ機能しますが、通常それらを機能させるのにクライアント Pod への多くの変更は不要です。環境変数を設定することで、プログラムは HTTP プロキシーを使用するように指示されます。
例として以下を使用して Pod を作成します。
apiVersion: v1 kind: Pod metadata: name: egress-http-proxy labels: name: egress-http-proxy annotations: pod.network.openshift.io/assign-macvlan: "true" 1 spec: initContainers: - name: egress-router-setup image: registry.redhat.io/openshift3/ose-egress-router securityContext: privileged: true env: - name: EGRESS_SOURCE 2 value: 192.168.12.99/24 - name: EGRESS_GATEWAY 3 value: 192.168.12.1 - name: EGRESS_ROUTER_MODE 4 value: http-proxy containers: - name: egress-router-proxy image: registry.redhat.io/openshift3/ose-egress-http-proxy env: - name: EGRESS_HTTP_PROXY_DESTINATION 5 value: | !*.example.com !192.168.1.0/24 *
- 1
- プライマリーネットワークインターフェイスで Macvlan ネットワークインターフェイスを作成してから、これを Pod のネットワークプロジェクトに移行し、egress-router コンテナーを起動します。
"true"
の周りの引用符をそのまま残します。これらを省略すると、エラーが発生します。 - 2
- ノードが置かれており、クラスター管理者がこの Pod で使用するために予約している物理ネットワークの IP アドレスです。オプションとして、サブネットの長さ
/24
接尾辞を組み込み、ローカルサブネットへの適切なルートがセットアップされるようにできます。サブネットの長さを指定しない場合、egress ルーターはEGRESS_GATEWAY
変数で指定されたホストにのみアクセスでき、サブネットの他のホストにはアクセスできません。 - 3
- ノード自体で使用されるデフォルトゲートウェイと同じ値。
- 4
- これは egress ルーターイメージに対し、これが HTTP プロキシーの一部としてデプロイされているため、iptables のリダイレクトルールを設定できないことを示します。
- 5
- プロキシーの設定方法を指定する文字列または YAML の複数行文字列です。これは、init コンテナーの他の環境変数ではなく、HTTP プロキシーコンテナーの環境変数として指定されることに注意してください。
EGRESS_HTTP_PROXY_DESTINATION
値に以下のいずれかを指定できます。また、*
を使用することができます。これはすべてのリモート宛先への接続を許可することを意味します。 設定の各行には、許可または拒否する接続の 1 つのグループを指定します。-
IP アドレス (例:
192.168.1.1
) は該当する IP アドレスへの接続を許可します。 -
CIDR 範囲 (例:
192.168.1.0/24
) は CIDR 範囲への接続を許可します。 -
ホスト名 (例:
www.example.com
) は該当ホストへのプロキシーを許可します。 -
*.
が先に付けられるドメイン名 (例:*.example.com
) は該当ドメインおよびそのサブドメインのすべてへのプロキシーを許可します。 -
上記のいずれかに
!
を付けると、接続は許可されるのではなく、拒否されます。 -
最後の行が
*
の場合、拒否されていないすべてのものが許可されます。または、許可されていないすべてのものが拒否されます。
egresss ルーターを参照するサービスを作成し、他の Pod が Pod の IP アドレスを見つけられるようにします。
apiVersion: v1 kind: Service metadata: name: egress-1 spec: ports: - name: http-proxy port: 8080 1 type: ClusterIP selector: name: egress-1
- 1
http
ポートが常に8080
に設定されていることを確認します。
http_proxy
またはhttps_proxy
変数を設定して、クライアント Pod (egress プロキシー Pod ではない) を HTTP プロキシーを使用するように設定します。... env: - name: http_proxy value: http://egress-1:8080/ 1 - name: https_proxy value: http://egress-1:8080/ ...
- 1
- 手順 2 で作成されたサービス。
注記すべてのセットアップに
http_proxy
およびhttps_proxy
環境変数が必要になる訳ではありません。上記を実行しても作業用セットアップが作成されない場合は、Pod で実行しているツールまたはソフトウェアについてのドキュメントを参照してください。
リダイレクトする egress ルーターの上記の例 と同様に、ConfigMap を使用して EGRESS_HTTP_PROXY_DESTINATION
を指定することもできます。
8.6.1.5. Egress ルーター DNS プロキシー Pod のデプロイ
DNS プロキシーモードでは、egress ルーターは、トラフィックを独自の IP アドレスから 1 つ以上の宛先 IP アドレスに送信する TCP ベースのサービスの DNS プロキシーとして実行されます。予約されたソース IP アドレスを使用する必要のあるクライアント Pod は、宛先 IP に直接接続するのでなく、egress ルーターに接続するように変更される必要があります。これにより、外部の宛先でトラフィックが既知のソースから送信されているかのように処理されます。
例として以下を使用して Pod を作成します。
apiVersion: v1 kind: Pod metadata: name: egress-dns-proxy labels: name: egress-dns-proxy annotations: pod.network.openshift.io/assign-macvlan: "true" 1 spec: initContainers: - name: egress-router-setup image: registry.redhat.io/openshift3/ose-egress-router securityContext: privileged: true env: - name: EGRESS_SOURCE 2 value: 192.168.12.99/24 - name: EGRESS_GATEWAY 3 value: 192.168.12.1 - name: EGRESS_ROUTER_MODE 4 value: dns-proxy containers: - name: egress-dns-proxy image: registry.redhat.io/openshift3/ose-egress-dns-proxy env: - name: EGRESS_DNS_PROXY_DEBUG 5 value: "1" - name: EGRESS_DNS_PROXY_DESTINATION 6 value: | # Egress routes for Project "Foo", version 5 80 203.0.113.25 100 example.com 8080 203.0.113.26 80 8443 foobar.com 443
- 1
pod.network.openshift.io/assign-macvlan annotation
を使用することで、プライマリーネットワークインターフェイスで Macvlan ネットワークインターフェイスが作成され、これを Pod のネットワーク namespace に移行してから、egress-router-setup コンテナーを起動します。"true"
の周りの引用符をそのまま残します。これらを省略すると、エラーが発生します。- 2
- ノードが置かれており、クラスター管理者がこの Pod で使用するために予約している物理ネットワークの IP アドレスです。オプションとして、サブネットの長さ
/24
接尾辞を組み込み、ローカルサブネットへの適切なルートがセットアップされるようにできます。サブネットの長さを指定しない場合、egress ルーターはEGRESS_GATEWAY
変数で指定されたホストにのみアクセスでき、サブネットの他のホストにはアクセスできません。 - 3
- ノード自体で使用されるデフォルトゲートウェイと同じ値。
- 4
- これは egress ルーターイメージに対し、これが DNS プロキシーの一部としてデプロイされているため、iptables のリダイレクトルールを設定できないことを示します。
- 5
- オプション。この変数を設定すると、DNS プロキシーログ出力が 標準出力 (stdout) で表示されます。
- 6
- ここでは、複数行の文字列に YAML 構文を使用しています。詳細は以下を参照してください。
注記EGRESS_DNS_PROXY_DESTINATION
の各行は、以下の 2 つの方法のいずれかで設定できます。-
<port> <remote_address>
: これは、指定の<port>
への受信接続が指定の<remote_address>
の同じ TCP ポートにプロキシー送信される必要があることを示しています。<remote_address>
は IP アドレスまたは DNS 名を指定できます。DNS 名の場合、DNS 解決は起動時に行われます。上記の例では、最初の行はローカルポート 80 から 203.0.113.25 のポート 80 に TCP トラフィックをプロキシー送信します。2 つ目の行は、TCP トラフィックをローカルポート 100 から example.com のポート 100 にプロキシー送信しています。 -
<port> <remote_address> <remote_port>
: 接続が<remote_address>
の別の<remote_port>
にプロキシー送信されるのを除き、上記と同じになります。この例では、3 番目の行ではローカルポート 8080 を 203.0.113.26 のリモートポート 80 にプロキシー送信し、4 番目の行ではローカルポート 8443 を footbar.com のリモートポートおよび 443 にプロキシー送信しています。
egresss ルーターを参照するサービスを作成し、他の Pod が Pod の IP アドレスを見つけられるようにします。
apiVersion: v1 kind: Service metadata: name: egress-dns-svc spec: ports: - name: con1 protocol: TCP port: 80 targetPort: 80 - name: con2 protocol: TCP port: 100 targetPort: 100 - name: con3 protocol: TCP port: 8080 targetPort: 8080 - name: con4 protocol: TCP port: 8443 targetPort: 8443 type: ClusterIP selector: name: egress-dns-proxy
Pod がこのサービスに接続できるようになります。これらの接続は、予約された egress IP アドレスを使用して外部サーバーの対応するポートにプロキシー送信されます。
リダイレクトする egress ルーターの上記の例 と同様に、ConfigMap を使用して EGRESS_DNS_PROXY_DESTINATION
を指定することもできます。
8.6.1.6. Egress ルーター Pod のフェイルオーバーの有効化
レプリケーションコントローラーを使用し、ダウンタイムを防ぐために egress ルーター Pod の 1 つのコピーを常に確保できるようにします。
以下を使用してレプリケーションコントローラーの設定ファイルを作成します。
apiVersion: v1 kind: ReplicationController metadata: name: egress-demo-controller spec: replicas: 1 1 selector: name: egress-demo template: metadata: name: egress-demo labels: name: egress-demo annotations: pod.network.openshift.io/assign-macvlan: "true" spec: initContainers: - name: egress-demo-init image: registry.redhat.io/openshift3/ose-egress-router env: - name: EGRESS_SOURCE 2 value: 192.168.12.99/24 - name: EGRESS_GATEWAY value: 192.168.12.1 - name: EGRESS_DESTINATION value: 203.0.113.25 - name: EGRESS_ROUTER_MODE value: init securityContext: privileged: true containers: - name: egress-demo-wait image: registry.redhat.io/openshift3/ose-pod nodeSelector: site: springfield-1
- 1
- 特定の
EGRESS_SOURCE
値を使用できる Pod は常に 1 つだけであるため、replicas
が1
に設定されていることを確認します。これは、ルーターの単一コピーのみがラベルsite=springfield-1
が設定されたノードで実行されることを意味します。 - 2
- ノードが置かれており、クラスター管理者がこの Pod で使用するために予約している物理ネットワークの IP アドレスです。オプションとして、サブネットの長さ
/24
接尾辞を組み込み、ローカルサブネットへの適切なルートがセットアップされるようにできます。サブネットの長さを指定しない場合、egress ルーターはEGRESS_GATEWAY
変数で指定されたホストにのみアクセスでき、サブネットの他のホストにはアクセスできません。
定義を使用して Pod を作成します。
$ oc create -f <replication_controller>.json
検証するには、レプリケーションコントローラー Pod が作成されているかどうかを確認します。
$ oc describe rc <replication_controller>