Red Hat Training

A Red Hat training course is available for OpenShift Container Platform

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 ポリシーを設定するには、以下を実行します。

  1. 対象とするプロジェクトに移動します。
  2. 以下の例のように、使用する必要のあるポリシー設定で 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 ファイアウォールを追加する必要があります。

  3. 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 を使用している場合は、EnableMACAntiSpoofingFilterRulesfalse に設定する必要が あります。
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 ルーターに接続するように変更される必要があります。

  1. 以下を使用して 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 の設定されたノードにのみデプロイされます。
  2. 上記の定義を使用して Pod を作成します。

    $ oc create -f <pod_name>.json

    Pod が作成されているかどうかを確認するには、以下を実行します。

    $ oc get pod <pod_name>
  3. 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
1
ノードが置かれており、クラスター管理者がこの Pod で使用するために予約している物理ネットワークの IP アドレスです。オプションとして、サブネットの長さ /24 接尾辞を組み込み、ローカルサブネットへの適切なルートがセットアップされるようにできます。サブネットの長さを指定しない場合、egress ルーターは EGRESS_GATEWAY 変数で指定されたホストにのみアクセスでき、サブネットの他のホストにはアクセスできません。
2
EGRESS_DESTINATION はその値に YAML 構文を使用し、複数行の文字列を使用できます。詳細は、以下を参照してください。

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 定義を直接編集することはできません。

  1. 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

    空の行とコメントをこのファイルに追加できることに注意してください。

  2. このファイルから 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 はデータの読み取り元のファイルの名前です。

  3. 前述のように 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 プロキシーを使用するように指示されます。

  1. 例として以下を使用して 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) は該当ドメインおよびそのサブドメインのすべてへのプロキシーを許可します。
    • 上記のいずれかに ! を付けると、接続は許可されるのではなく、拒否されます。
    • 最後の行が * の場合、拒否されていないすべてのものが許可されます。または、許可されていないすべてのものが拒否されます。
  2. 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 に設定されていることを確認します。
  3. 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 ルーターに接続するように変更される必要があります。これにより、外部の宛先でトラフィックが既知のソースから送信されているかのように処理されます。

  1. 例として以下を使用して 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 にプロキシー送信しています。
  2. 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 つのコピーを常に確保できるようにします。

  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 つだけであるため、replicas1 に設定されていることを確認します。これは、ルーターの単一コピーのみがラベル site=springfield-1 が設定されたノードで実行されることを意味します。
    2
    ノードが置かれており、クラスター管理者がこの Pod で使用するために予約している物理ネットワークの IP アドレスです。オプションとして、サブネットの長さ /24 接尾辞を組み込み、ローカルサブネットへの適切なルートがセットアップされるようにできます。サブネットの長さを指定しない場合、egress ルーターは EGRESS_GATEWAY 変数で指定されたホストにのみアクセスでき、サブネットの他のホストにはアクセスできません。
  2. 定義を使用して Pod を作成します。

    $ oc create -f <replication_controller>.json
  3. 検証するには、レプリケーションコントローラー Pod が作成されているかどうかを確認します。

    $ oc describe rc <replication_controller>