第4章 ルーターのセットアップ

トラフィックをクラスターに送る方法は多数あります。最も一般的な方法として、 OpenShift Container Platform インストールで OpenShift Container Platform ルーターを、サービス向けの外部トラフィックの ingress ポイントとして使用できます。

OpenShift Container Platform は以下のルータープラグインを提供し、サポートしています。

OpenShift Container Platform クラスターをデプロイする前に、ルーターのサービスアカウントを取得する必要があります。OpenShift Container Platform 3.1 以降では、クイックインストールまたは通常インストール (Advanced installation) の実行時に、ルーターのサービスアカウントが自動的に作成されます (以前は手動で作成する必要がありました)。このサービスアカウントには、ホストポートを指定することを許可する SCC (security context constraint) のパーミッションがあります。

$ oc adm policy add-cluster-role-to-user \
    cluster-reader \
    system:serviceaccount:default:router

oc adm router コマンドには、新規インストールでのルーターのセットアップタスクを単純化する管理者 CLI が提供されます。 クイックインストールを実行している場合は、デフォルトのルーターが自動的に作成されます。oc adm router コマンドは、サービスとデプロイメント設定オブジェクトを作成します。 --service-account オプションを使用して、ルーターがマスターとの通信で使用するサービスアカウントを指定します。

ルーターサービスアカウントは事前に作成するか、oc adm router --service-account コマンドで作成することができます。

OpenShift Container Platform コンポーネント間のあらゆる形式の通信は TLS によって保護され、各種の証明書や認証方法を使用します。--default-certificate .pem フォーマットファイルは提供されるか、または oc adm router コマンドで作成されます。ルートが作成されると、ユーザーはルートの処理時にルーターが使用するルート証明書を提供できるようになります。

ルーターは特定のノードにデプロイされます。これにより、クラスター管理者と外部ネットワークマネージャーはどの IP アドレスがルーターを実行し、ルーターがどのトラフィックを処理するかについて調整しやすくなります。ノードセレクターを使用してルーターを特定のノードにデプロイします。

$ oc adm router --dry-run --service-account=router 1

クイックインストールプロセスは、デフォルトルーターを自動的に作成します。ルーターが存在しない場合は、以下を実行してルーターを作成します。

$ oc adm router <router_name> --replicas=<number> --service-account=router

高可用性の設定が作成されない限り、--replicas は通常 1 になります。

ルーターのホスト IP アドレスを見つけるには、以下を実行します。

$ oc get po <router-pod>  --template={{.status.hostIP}}

また、ルーターシャードを使用して、ルーターを特定の namespace またはルートに絞り込むか、ルーターの作成後に環境変数を設定できます。この場合には、シャードごとにルーターを作成します。

$ oc adm router --dry-run --service-account=router

$ oc adm router --dry-run -o yaml --service-account=router

$ oc adm router <router_name> --replicas=<number> --selector=<label> \
    --service-account=router

たとえば、router という名前のルーターを作成し、それを region=infra とラベルが付けられたノードに配置するには、以下を実行します。

$ oc adm router router --replicas=1 --selector='region=infra' \
  --service-account=router

通常インストール (Advanced installation) の実行時に、openshift_router_selector および openshift_registry_selector Ansible 設定はデフォルトで region=infra に設定されます。region=infra ラベルと一致するノードが存在する場合、デフォルトのルーターとレジストリーは自動的にデプロイされます。

ラベルの更新に関する情報については、「ノードのラベルの更新」を参照してください。

複数のインスタンスが スケジューラーポリシーに従って複数の異なるホストに作成されます。

$ oc adm router <router_name> -o <format> --images=<image> \
    --service-account=router

例を以下に示します。

$ oc adm router region-west -o yaml --images=myrepo/somerouter:mytag \
    --service-account=router

ROUTE_LABELS 環境変数を使用してルートを絞り込むことで、特定のルーターによってのみ使用されるようできます。

たとえば、複数のルーターと 100 のルートがある場合、ラベルをルートに割り当てることで、それらの一部を 1 つのルーターで処理し、残りを別のルーターで処理するようにできます。

ルーターを作成したら、--max-connections= オプションで必要な上限を設定します。

$ oc adm router --max-connections=10000   ....

ルーターのデプロイメント設定で ROUTER_MAX_CONNECTIONS 環境変数を編集し、値を変更します。ルーター Pod は新しい値で再起動されます。ROUTER_MAX_CONNECTIONS が存在しない場合は、デフォルト値の 20000 が使用されます。

HAProxy strict-sni は、ルーターのデプロイメント設定の ROUTER_STRICT_SNI 環境変数によって管理できます。また、これは --strict-sni コマンドラインオプションを使用してルーターを作成する時にも設定できます。

$ oc adm router --strict-sni

ルーターの作成時に --ciphers オプションを使用して、ルーターの暗号化スイートを設定します。

$ oc adm router --ciphers=modern   ....

値は modern、intermediate、または old で、デフォルトは intermediateです。または、 ":" で区切られた暗号セットを指定することもできます。暗号は以下によって表示されるセットから取られたものである必要があります。

$ openssl ciphers

また、既存のルーターには ROUTER_CIPHERS 環境変数を使用します。

IP フェイルオーバーを使用して OpenShift Container Platform クラスターで高可用性ルーターをセットアップできます。このセットアップには複数の異なるノードの複数のレプリカが含まれるため、フェイルオーバーソフトウェアは現在のレプリカが失敗したら別のレプリカに切り替えることができます。

環境変数の ROUTER_SERVICE_HTTP_PORT と ROUTER_SERVICE_HTTPS_PORT を設定することで、テンプレートルーターがバインドするサービスポートをカスタマイズできます。これは、テンプレートルーターを作成し、そのデプロイメント設定を編集することで実行できます。

以下の例では、0 レプリカのルーターデプロイメントを作成し、ルーターサービス HTTP と HTTPS ポートをカスタマイズし、これを適切に (1 レプリカに) スケーリングしています。

$ oc adm router --replicas=0 --ports='10080:10080,10443:10443' 1
$ oc set env dc/router ROUTER_SERVICE_HTTP_PORT=10080  \
                   ROUTER_SERVICE_HTTPS_PORT=10443
$ oc scale dc/router --replicas=1

以下は、カスタムルーターサービスポートを開くために iptables を使用した例です。

$ iptables -A INPUT -p tcp --dport 10080 -j ACCEPT
$ iptables -A INPUT -p tcp --dport 10443 -j ACCEPT

管理者は同じ定義を使用して複数のルーターを作成し、同じルートのセットを提供することができます。各ルーターは複数の異なるノードに置かれ、異なる IP アドレスを持ちます。ネットワーク管理者は、各ノードに必要なトラフィックを送る必要があります。

複数のルーターをグループ化して、クラスター内や複数テナントでのルーティングの負荷を別のルーターまたはシャードに分散することができます。グループの各ルーターまたはシャードは、ルーターのセレクターに基づいてルートを許可します。管理者は ROUTE_LABELS を使用してクラスター全体でシャードを作成できます。ユーザーは NAMESPACE_LABELS を使用して namespace (プロジェクト) でシャードを作成できます。

特定のルーターを特定のノードにデプロイするには、2 つの手順を実行する必要があります。

ルーターのシャード化では NAMESPACE_LABELS と ROUTE_LABELS を使用してルーターの namespace とルートを絞り込みます。これにより、複数のルーターデプロイメントでルートのサブセットを分散させることができます。重複しないサブセットを使用することにより、ルートの設定のパーティション設定を効果的に行うことができます。または、ルートの重複するサブセットを構成するシャードを定義することもできます。

デフォルトで、ルーターはすべてのプロジェクト (namespace) からすべてのルートを選択します。シャード化によってラベルがルートまたはルーターの namespace およびラベルセレクターに追加されます。各ルーターシャードは特定のラベルのセットで選択されるルーターを構成するか、または特定のラベルセレクターで選択される namespace に属します。

ルーターのシャード化および DNS

外部 DNS サーバーは要求を必要なシャードにルートするために必要となるので、管理者はプロジェクトの各ルーターに個別の DNS エントリーを作成する必要があります。ルーターは不明なルートを別のルーターに転送することはありません。

以下は例を示しています。

各 DNS エントリーは *.foo.com を Router A をホストするノードに解決し、*.example.com を Router B をホストするノードに解決する必要があります。

ルーターのシャード化の例

このセクションでは、namespace およびルートラベルを使用するルーターのシャード化について説明します。

図4.1 namespace ラベルに基づくルーターのシャード化

このラベルを追加すると、ルートはルーターで利用できるようになります。

sla=high       geo=east     hw=modest     dept=finance
sla=medium     geo=west     hw=strong     dept=dev
sla=low                                   dept=ops

#!/bin/bash
# Usage: mkshard ID SELECTION-EXPRESSION
id=$1
sel="$2"
router=router-shard-$id           1
oc adm router $router --replicas=0  2
dc=dc/router-shard-$id            3
oc set env   $dc ROUTE_LABELS="$sel"  4
oc scale $dc --replicas=3         5

#!/bin/bash
# Usage: modshard ID SELECTION-EXPRESSION...
id=$1
shift
router=router-shard-$id       1
dc=dc/$router                 2
oc scale $dc --replicas=0     3
oc set env   $dc "$@"             4
oc scale $dc --replicas=3     5

$ modshard 3 ROUTE_LABELS='dept in (dev, ops)'

$ modshard 3 ROUTE_LABELS='dept != finance'

$ modshard 3 ROUTE_LABELS='hw=strong,type=dynamic,geo=west'

$ modshard 3 NAMESPACE_LABELS='frequency=weekly'

$ modshard 3 \
    NAMESPACE_LABELS='frequency=weekly' \
    ROUTE_LABELS='sla=low'

サービスを公開する際に、ユーザーは外部ユーザーがアプリケーションにアクセスするために使用する DNS 名からの同じルートを使用できます。外部ネットワークのネットワーク管理者は、ホスト名がルートを許可したルーター名に解決することを確認する必要があります。ユーザーはこのホスト名を指す CNAME を使用して DNS をセットアップできます。ただし、ユーザーはルーターのホスト名を知らない場合があり、その場合はクラスター管理者がホスト名を知らせることができます。

クラスター管理者は、--router-canonical-hostname オプションをルーター作成時のルーターの正規ホスト名で使用できます。以下は例になります。

# oc adm router myrouter --router-canonical-hostname="rtr.example.com"

これは、ルーターのホスト名を含む ROUTER_CANONICAL_HOSTNAME 環境変数をルーターのデプロイメント設定に作成します。

すでに存在しているルーターの場合、クラスター管理者はルーターのデプロイメント設定を編集し、ROUTER_CANONICAL_HOSTNAME 環境変数を追加します。

spec:
  template:
    spec:
      containers:
        - env:
          - name: ROUTER_CANONICAL_HOSTNAME
            value: rtr.example.com

ROUTER_CANONICAL_HOSTNAME 値は、ルートを許可したすべてのルーターのルートステータスに表示されます。ルートステータスはルーターがリロードされるたびに更新されます。

ユーザーがルートを作成すると、すべてのアクティブなルーターはそのルートを評価し、条件を満たしていればそのルートを許可します。ROUTER_CANONICAL_HOSTNAME 環境変数を定義するルーターがルートを許可すると、ルーターはルートステータスの routerCanonicalHostname フィールドに値を入力します。ユーザーはルートステータスを検証して、どのルーターがルートを許可したかを確認でき、ルーターを一覧から選択し、ネットワーク管理者に渡すルーターのホスト名を見つけることができます (該当する場合)。

status:
  ingress:
    conditions:
      lastTransitionTime: 2016-12-07T15:20:57Z
      status: "True"
      type: Admitted
      host: hello.in.mycloud.com
      routerCanonicalHostname: rtr.example.com
      routerName: myrouter
      wildcardPolicy: None

oc describe にはホスト名が含まれます (利用可能な場合)。

$ oc describe route/hello-route3
...
Requested Host: hello.in.mycloud.com exposed on router myroute (host rtr.example.com) 12 minutes ago

上記の情報を使用して、ユーザーは DNS 管理者に対し、ルートのホスト hello.in.mycloud.com から CNAME をルーターの正規ホスト名 rtr.example.com に応じてセットアップするよう依頼できます。この結果として、hello.in.mycloud.com へのトラフィックがユーザーのアプリケーションに到達するようになります。

マスター設定ファイル (デフォルトでは /etc/origin/master/master-config.yaml ファイル) を変更することで、お使いの環境のデフォルトルーティングサブドメインとして使用されるサフィックスをカスタマイズできます。ホスト名を指定しないルートの場合、このデフォルトのルーティングサブドメインを使用してホスト名が生成されます。

以下の例は、設定されたサフィックスを v3.openshift.test に設定する方法を示しています。

routingConfig:
  subdomain: v3.openshift.test

OpenShift Container Platform マスターが上記の設定を実行している場合、 namespace の mynamespace に追加されるホスト名を持たない no-route-hostname というルートの例では、生成されるホスト名は以下のようになります。

no-route-hostname-mynamespace.v3.openshift.test

管理者がすべてのルートを特定のルーティングサブドメインに限定する場合、--force-subdomain オプションを oc adm router コマンドに渡すことができます。これはルートで指定されたホスト名を上書きし、--force-subdomain オプションに提供されるテンプレートに基づいてホスト名を生成するようルーターに強制します。

以下の例ではルーターを実行し、カスタムサブドメインテンプレート ${name}-${namespace}.apps.example.com を使用してルートホスト名を上書きしています。

$ oc adm router --force-subdomain='${name}-${namespace}.apps.example.com'

証明書を含まない TLS 対応のルートはルーターのデフォルト証明書を代わりに使用します。ほとんどの場合、この証明書は信頼された認証局から提供されますが、利便性を考慮して OpenShift Container Platform CA を使用して証明書を作成することができます。以下は例になります。

$ CA=/etc/origin/master
$ oc adm ca create-server-cert --signer-cert=$CA/ca.crt \
      --signer-key=$CA/ca.key --signer-serial=$CA/ca.serial.txt \
      --hostnames='*.cloudapps.example.com' \
      --cert=cloudapps.crt --key=cloudapps.key

ルーターは、証明書とキーが単一ファイルに PEM 形式で入力されていると予想します。

$ cat cloudapps.crt cloudapps.key $CA/ca.crt > cloudapps.router.pem

ここで --default-cert フラグを使用できます。

$ oc adm router --default-cert=cloudapps.router.pem --service-account=router

ルーター証明書を手動で再デプロイするには、以下を実行します。

現時点で、パスワードで保護されたキーファイルはサポートされていません。HAProxy は開始時にパスワードのプロンプトを出しますが、このプロセスを自動化する方法は提供しません。キーファイルからパスフレーズを削除するために、以下を実行できます。

# openssl rsa -in <passwordProtectedKey.key> -out <new.key>

以下の例は、トラフィックが宛先にプロキシー処理される前に TLS 終端がルーターで生じる場合にセキュアな edge termination ルートを使用する方法を示しています。セキュアな edge termination ルートは TLS 証明書とキー情報を指定します。TLS 証明書は、ルーターのフロントエンドで提供されます。

最初にルーターインスタンスを起動します。

# oc adm router --replicas=1 --service-account=router

次に、セキュアな edge ルートのプライベートキー、CSR、証明書を作成します。この手順はお使いの認証局やプロバイダーによって異なります。www.example.test というドメインの単純な自己署名証明書の場合は、以下の例を参照してください。

# sudo openssl genrsa -out example-test.key 2048
#
# sudo openssl req -new -key example-test.key -out example-test.csr  \
  -subj "/C=US/ST=CA/L=Mountain View/O=OS3/OU=Eng/CN=www.example.test"
#
# sudo openssl x509 -req -days 366 -in example-test.csr  \
      -signkey example-test.key -out example-test.crt

上記の証明書とキーを使用してルートを生成します。

$ oc create route edge --service=my-service \
    --hostname=www.example.test \
    --key=example-test.key --cert=example-test.crt
route "my-service" created

その定義を確認します。

$ oc get route/my-service -o yaml
apiVersion: v1
kind: Route
metadata:
  name:  my-service
spec:
  host: www.example.test
  to:
    kind: Service
    name: my-service
  tls:
    termination: edge
    key: |
      -----BEGIN PRIVATE KEY-----
      [...]
      -----END PRIVATE KEY-----
    certificate: |
      -----BEGIN CERTIFICATE-----
      [...]
      -----END CERTIFICATE-----

www.example.test の DNS エントリーがルーターインスタンスを指し、ドメインへのルートが利用できることを確認します。以下の例では、Curl をローカルリゾルバーと共に使用して DNS ルックアップのシミュレーションを行っています。

# routerip="4.1.1.1"  #  replace with IP address of one of your router instances.
# curl -k --resolve www.example.test:443:$routerip https://www.example.test/

HAProxy ルーターはワイルドカードルートをサポートしており、ROUTER_ALLOW_WILDCARD_ROUTES 環境変数を true に設定することでこれを有効にできます。ルーター許可のチェックをパスする Subdomain のワイルドカードポリシーを持つすべてのルートは HAProxy ルーターによって提供されます。次に、HAProxy ルーターはルートのワイルドカードポリシーに基づいて (ルートの) 関連サービスを公開します。

$ oc adm router --replicas=0 ...
$ oc set env dc/router ROUTER_ALLOW_WILDCARD_ROUTES=true
$ oc scale dc/router --replicas=1

Web コンソールでワイルドカードルートを設定する方法についてはこちらを参照してください。

セキュアな edge termination ルートは TLS 証明書とキー情報を指定します。TLS 証明書は、サブドメイン (*.example.org) に一致するすべてのホストのルーターのフロントエンドによって提供されます。

ワイルドカードルートを許可しているルーター (ROUTER_ALLOW_WILDCARD_ROUTES を true に設定する) の場合、ワイルドカードルートに関連付けられたサブドメインの所有権についてのいくつかの注意点があります。

ワイルドカードルートの設定前に、所有権は、最も古いルートを持つ namespace のホスト名についての要求に基づいて設定されました (これはその他の要求を行うルートよりも優先されました)。たとえば、ルート r1 がルート r2 より古い場合、one.example.test の要求を持つ namespace ns1 のルート r1 は同じホスト名 one.example.test について namespace ns2 のルート ns2 よりも優先されます。

さらに、他の namespace のルートは重複しないホスト名を要求することを許可されていました。たとえば、namespace ns1 のルート rone は www.example.test を要求でき、namespace d2 の別のルート rtwo は c3po.example.test を要求できました。

これは、同じサブドメイン (上記の例では example.test) を要求するワイルドカードルートがない場合には同様になります。

ただし、ワイルドカードルートはサブドメイン内のホスト名 ( \*.example.test 形式のホスト名) をすべて要求する必要があります。ワイルドカードルートの要求は、そのサブドメイン (example.test) の最も古いルートがワイルドカードルートと同じ namespace 内にあるかどうかによって許可または拒否されます。最も古いルートは通常のルートまたはワイルドカードルートのいずれかになります。

たとえば、ホスト owner.example.test を要求する 最も古い ルートが namespace ns1 にすでに存在し、後からそのサブドメイン (example.test) のルートを要求する新規のワイルドカードルート wildthing が追加される場合、そのワイルドカードルートによる要求は、そのルートが所有ルートと同じ namespace (ns1) にある場合にのみ許可されます。

以下の例では、ワイルドカードルートの要求が成功する場合と失敗する場合のさまざまなシナリオを示しています。

以下の例では、ワイルドカードルートを許可するルーターは、ワイルドカードルートがサブドメインを要求していない限り、サブドメイン example.test のホストに対する重複しない要求を許可します。

$ oc adm router ...
$ oc set env dc/router ROUTER_ALLOW_WILDCARD_ROUTES=true

$ oc project ns1
$ oc expose service myservice --hostname=owner.example.test
$ oc expose service myservice --hostname=aname.example.test
$ oc expose service myservice --hostname=bname.example.test

$ oc project ns2
$ oc expose service anotherservice --hostname=second.example.test
$ oc expose service anotherservice --hostname=cname.example.test

$ oc project otherns
$ oc expose service thirdservice --hostname=emmy.example.test
$ oc expose service thirdservice --hostname=webby.example.test

以下の例では、ワイルドカードルートを許可するルーターは、所有している namespace が ns1 なので、owner.example.test または aname.example.test の要求を許可しません。

$ oc adm router ...
$ oc set env dc/router ROUTER_ALLOW_WILDCARD_ROUTES=true

$ oc project ns1
$ oc expose service myservice --hostname=owner.example.test
$ oc expose service myservice --hostname=aname.example.test

$ oc project ns2
$ oc expose service secondservice --hostname=bname.example.test
$ oc expose service secondservice --hostname=cname.example.test

$ # Router will not allow this claim with a different path name `/p1` as
$ # namespace `ns1` has an older route claiming host `aname.example.test`.
$ oc expose service secondservice --hostname=aname.example.test --path="/p1"

$ # Router will not allow this claim as namespace `ns1` has an older route
$ # claiming host name `owner.example.test`.
$ oc expose service secondservice --hostname=owner.example.test

$ oc project otherns

$ # Router will not allow this claim as namespace `ns1` has an older route
$ # claiming host name `aname.example.test`.
$ oc expose service thirdservice --hostname=aname.example.test

以下の例では、ワイルドカードルートを許可するルーターは、所有している namespace が ns1 で、そのワイルドカードルートが同じ namespace に属しているので、`\*.example.test の要求を許可します。

$ oc adm router ...
$ oc set env dc/router ROUTER_ALLOW_WILDCARD_ROUTES=true

$ oc project ns1
$ oc expose service myservice --hostname=owner.example.test

$ # Reusing the route.yaml from the previous example.
$ # spec:
$ #   host: www.example.test
$ #   wildcardPolicy: Subdomain

$ oc create -f route.yaml   #  router will allow this claim.

以下の例では、ワイルドカードルートを許可するルーターは、所有している namespace が ns1 で、ワイルドカードルートが別の namespace cyclone に属するため、`\*.example.test の要求を許可しません。

$ oc adm router ...
$ oc set env dc/router ROUTER_ALLOW_WILDCARD_ROUTES=true

$ oc project ns1
$ oc expose service myservice --hostname=owner.example.test

$ # Switch to a different namespace/project.
$ oc project cyclone

$ # Reusing the route.yaml from a prior example.
$ # spec:
$ #   host: www.example.test
$ #   wildcardPolicy: Subdomain

$ oc create -f route.yaml   #  router will deny (_NOT_ allow) this claim.

同様に、ワイルドカードルートを持つ namespace がサブドメインを要求すると、その namespace 内のルートのみがその同じサブドメインでホストを要求できます。

以下の例では、ワイルドカードルートを持つ namespace ns1 のルートがサブドメイン example.test を要求すると、namespace ns1 内のルートのみがその同じサブドメインのホストを要求することを許可されます。

$ oc adm router ...
$ oc set env dc/router ROUTER_ALLOW_WILDCARD_ROUTES=true

$ oc project ns1
$ oc expose service myservice --hostname=owner.example.test

$ oc project otherns

$ # namespace `otherns` is allowed to claim for other.example.test
$ oc expose service otherservice --hostname=other.example.test

$ oc project ns1

$ # Reusing the route.yaml from the previous example.
$ # spec:
$ #   host: www.example.test
$ #   wildcardPolicy: Subdomain

$ oc create -f route.yaml   #  Router will allow this claim.

$ #  In addition, route in namespace otherns will lose its claim to host
$ #  `other.example.test` due to the wildcard route claiming the subdomain.

$ # namespace `ns1` is allowed to claim for deux.example.test
$ oc expose service mysecondservice --hostname=deux.example.test

$ # namespace `ns1` is allowed to claim for deux.example.test with path /p1
$ oc expose service mythirdservice --hostname=deux.example.test --path="/p1"

$ oc project otherns

$ # namespace `otherns` is not allowed to claim for deux.example.test
$ # with a different path '/otherpath'
$ oc expose service otherservice --hostname=deux.example.test --path="/otherpath"

$ # namespace `otherns` is not allowed to claim for owner.example.test
$ oc expose service yetanotherservice --hostname=owner.example.test

$ # namespace `otherns` is not allowed to claim for unclaimed.example.test
$ oc expose service yetanotherservice --hostname=unclaimed.example.test

以下の例では、所有権のあるルートが削除され、所有権が namespace 内または namespace 間で渡されるさまざまなシナリオが示されています。namespace ns1 のホスト eldest.example.test を要求するルートが存在する場合、その namespace 内のワイルドカードルートはサブドメイン example.test を要求できます。ホスト eldest.example.test のルートが削除されると、次に古いルート senior.example.test が最も古いルートになりますが、これは他のルートに影響を与えません。ホスト senior.example.test のルートが削除されると、次に古いルート junior.example.test が最も古いルートになり、ワイルドカードルートの要求をブロックします。

$ oc adm router ...
$ oc set env dc/router ROUTER_ALLOW_WILDCARD_ROUTES=true

$ oc project ns1
$ oc expose service myservice --hostname=eldest.example.test
$ oc expose service seniorservice --hostname=senior.example.test

$ oc project otherns

$ # namespace `otherns` is allowed to claim for other.example.test
$ oc expose service juniorservice --hostname=junior.example.test

$ oc project ns1

$ # Reusing the route.yaml from the previous example.
$ # spec:
$ #   host: www.example.test
$ #   wildcardPolicy: Subdomain

$ oc create -f route.yaml   #  Router will allow this claim.

$ #  In addition, route in namespace otherns will lose its claim to host
$ #  `junior.example.test` due to the wildcard route claiming the subdomain.

$ # namespace `ns1` is allowed to claim for dos.example.test
$ oc expose service mysecondservice --hostname=dos.example.test

$ # Delete route for host `eldest.example.test`, the next oldest route is
$ # the one claiming `senior.example.test`, so route claims are unaffacted.
$ oc delete route myservice

$ # Delete route for host `senior.example.test`, the next oldest route is
$ # the one claiming `junior.example.test` in another namespace, so claims
$ # for a wildcard route would be affected. The route for the host
$ # `dos.example.test` would be unaffected as there are no other wildcard
$ # claimants blocking it.
$ oc delete route seniorservice

OpenShift Container Platform ルーターはコンテナー内で実行され、デフォルトの動作として、ホスト (例: ルーターコンテナーが実行されるノードなど) のネットワークスタックを使用します。このデフォルトの動作には、リモートクライアントからのネットワークトラフィックがターゲットサービスとコンテナーに到達するためにユーザー空間で複数のホップを使用する必要がないので、パフォーマンス上のメリットがあります。

さらに、このデフォルト動作によってルーターはノードの IP アドレスではなくリモート接続の実際のソース IP アドレスを取得できます。これは、発信元の IP に基づいて ingress ルールを定義し、スティッキーセッションをサポートし、他に使用されているものの中でトラフィックを監視するのに役立ちます。

このホストネットワークの動作は --host-network ルーターコマンドラインオプションによって制御でき、デフォルトの動作は --host-network=true を使用した場合と等しくなります。コンテナーネットワークスタックを使用してルーターを実行する場合は、ルーターを作成する際に --host-network=false オプションを使用します。以下は例になります。

$ oc adm router --service-account=router --host-network=false

内部的には、これは外部ネットワークがルーターと通信するために、ルーターコンテナーが 80 と 443 ポートを公開する必要があることを意味します。

HAProxy ルーターメトリクス は、外部メトリクス収集および集約システム (例: Prometheus、statsd) で使用されるようにデフォルトで Prometheus 形式で公開されます。メトリクスは独自の HTML 形式でブラウザーで閲覧したり CSV ダウンロードを実行するために HAProxy ルーターから直接利用することもできます。これらのメトリクスには、HAProxy ネイティブメトリクスおよび一部のコントローラーメトリクスが含まれます。

以下のコマンドを使用してルーターを作成する場合、OpenShift Container Platform は Prometheus 形式のメトリクスをデフォルトが 1936 の統計ポートで利用可能にします。

$ oc adm router --service-account=router

(net.ipv4.neigh.default.gc_thresh3 の値 (デフォルトで65536) を上回る) 多数のルート を持つ OpenShift Container Platform クラスターでは、ARP キャッシュでより多くのエントリーを許可するためにルーター Pod を実行するクラスターの各ノードで sysctl 変数のデフォルト値を増やす必要があります。

問題が発生している場合、以下のようなカーネルメッセージが表示されます。

[ 1738.811139] net_ratelimit: 1045 callbacks suppressed
[ 1743.823136] net_ratelimit: 293 callbacks suppressed

この問題が発生すると、oc コマンドは以下のエラーを出して失敗することがあります。

Unable to connect to the server: dial tcp: lookup <hostname> on <ip>:<port>: write udp <ip>:<port>-><ip>:<port>: write: invalid argument

IPv4 の ARP エントリーの実際の量を確認するには、以下を実行します。

# ip -4 neigh show nud all | wc -l

数字が net.ipv4.neigh.default.gc_thresh3 しきい値に近づき始めたら、値を増やします。以下を実行して現在値を取得します。

# sysctl net.ipv4.neigh.default.gc_thresh1
net.ipv4.neigh.default.gc_thresh1 = 128
# sysctl net.ipv4.neigh.default.gc_thresh2
net.ipv4.neigh.default.gc_thresh2 = 512
# sysctl net.ipv4.neigh.default.gc_thresh3
net.ipv4.neigh.default.gc_thresh3 = 1024

以下の sysctl は変数を OpenShift Container Platform の現在のデフォルト値に設定します。

# sysctl net.ipv4.neigh.default.gc_thresh1=8192
# sysctl net.ipv4.neigh.default.gc_thresh2=32768
# sysctl net.ipv4.neigh.default.gc_thresh3=65536

これらの設定を永続化するには、このドキュメントを参照してください。

timeout http-request をデフォルトの HAProxy ルーターイメージに追加して、分散型の denial-of-service (DDoS) 攻撃 (slowloris など) からデプロイメントを保護します。

# and the haproxy stats socket is available at /var/run/haproxy.stats
global
  stats socket ./haproxy.stats level admin

defaults
  option http-server-close
  mode http
  timeout http-request 5s
  timeout connect 5s 1
  timeout server 10s
  timeout client 30s

また、環境変数 ROUTER_SLOWLORIS_TIMEOUT が設定されている場合、クライアントが HTTP 要求全体を送信するためにかかる合計時間が制限されます。これが設定されていない場合、HAProxy は接続を切断します。

環境変数を設定することで、情報をルーターのデプロイメント設定の一部として取得でき、テンプレートを手動で変更することが不要になります。一方、HAProxy 設定を手動で追加すると、ルーター Pod の再ビルドとルーターテンプレートファイルの保守が必要になります。

アノテーションを使用して、以下を制限する機能を含む基本的な DDoS 保護を HAProxy テンプレートルーターに実装します。

アプリケーションによってはトラフィックのパターンが完全に異なる場合があるため、これらはルートごとに有効にされます。

デフォルトの HAProxy ルーターは多数のユーザーのニーズを対応することを目的としています。ただし、このルーターは HAProxy のすべての機能を公開している訳ではありません。そのため、ユーザーはそれぞれのニーズに合わせてルーターを変更する必要があります。

新機能をアプリケーションバックエンド内で実装したり、現在の操作を変更する必要がある場合があります。ルータープラグインはこのカスタマイズを行うために必要なすべての機能を提供します。

ルーター Pod はテンプレートファイルを使用して必要な HAProxy 設定ファイルを作成します。テンプレートファイルは golang テンプレート です。テンプレートを処理する際に、ルーターはルーターのデプロイメント設定、許可されたルートのセット、一部のヘルパー機能などの OpenShift Container Platform 情報にアクセスします。

ルーター Pod が起動し、リロードされるたびに、HAProxy 設定ファイルが作成され、HAProxy が起動します。『HAProxy 設定マニュアル』には HAProxy のすべての機能と有効な設定ファイルの作成方法が記載されています。

configMap を使用して新規テンプレートをルーター Pod に追加することができます。この方法により、ルーターデプロイメント設定を変更して、configMap をルーター Pod のボリュームとしてマウントできます。 TEMPLATE_FILE 環境変数はルーター Pod のテンプレートファイルのフルパス名に設定されます。

または、カスタムルーターイメージをビルドし、ルーターの一部またはすべてをデプロイする際にこれを使用することができます。すべてのルーターが同じイメージを実行する必要はありません。これを実行するには、 haproxy-template.config ファイルを変更し、ルーターイメージを再ビルドします。新しいイメージはクラスターの Docker リポジトリーにプッシュされ、ルーターのデプロイメント設定の image: フィールドが新しい名前で更新されます。クラスターが更新されたら、イメージを再ビルドし、プッシュする必要があります。

いずれの場合でも、ルーター Pod はテンプレートファイルを使用して起動します。

HAProxy テンプレートファイルはかなり大きく複雑です。一部を変更するのであれば、すべてを書き換えるよりも既存のテンプレートを変更する方が簡単です。マスターでルーターを実行し、ルーター Pod を参照することで実行中のルーターから haproxy-config.templateファイルを取得できます。

# oc get po
NAME                       READY     STATUS    RESTARTS   AGE
router-2-40fc3             1/1       Running   0          11d
# oc rsh router-2-40fc3 cat haproxy-config.template > haproxy-config.template
# oc rsh router-2-40fc3 cat haproxy.config > haproxy.config

または、ルーターを実行しているノードにログオンします。

# docker run --rm --interactive=true --tty --entrypoint=cat \
    registry.access.redhat.com/openshift3/ose-haproxy-router:v3.7 haproxy-config.template

イメージ名は docker イメージ から取られます。

この内容をカスタマイズされたテンプレートのベースとして使用するためにファイルに保存します。保存された haproxy.config は実際に実行されているものを示します。

ConfigMap を使用して、ルーターイメージを再ビルドすることなくルーターインスタンスをカスタマイズできます。ルーター環境変数の作成し、変更することができるだけでなく、haproxy-config.template、reload-haproxy その他のスクリプトを変更することもできます。

以下のカスタマイズの例を高可用なルーティングセットアップで使用することで、ピア間の同期を行う stick-table を使用できます。

ピアセクションの追加

ピア間で stick-table を同期するには、HAProxy 設定でピアセクションを定義する必要があります。このセクションによって、HAProxy がどのようにピアを識別し、接続するかが決まります。プラグインはデータを .PeerEndpoints 変数にあるテンプレートに提供するので、ルーターサービスのメンバーを簡単に識別できます。以下を追加することで、ピアセクションをルーターイメージ内の haproxy-config.template ファイルに追加することができます。

{{ if (len .PeerEndpoints) gt 0 }}
peers openshift_peers
  {{ range $endpointID, $endpoint := .PeerEndpoints }}
    peer {{$endpoint.TargetName}} {{$endpoint.IP}}:1937
  {{ end }}
{{ end }}

リロードスクリプトの変更

stick-table を使用する場合、HAProxy にピアセクションでローカルホスト名として見なすものをオプションで指示することができます。エンドポイントの作成時に、プラグインは TargetName をエンドポイントの TargetRef.Name の値に設定するよう試みます。TargetRef が設定されていない場合、TargetName は IP アドレスに設定されます。TargetRef.Name は Kubernetes ホスト名に対応しているので、-L オプションを reload-haproxy スクリプトに追加してローカルホストをピアセクションで識別できます。

peer_name=$HOSTNAME 1

if [ -n "$old_pid" ]; then
  /usr/sbin/haproxy -f $config_file -p $pid_file -L $peer_name -sf $old_pid
else
  /usr/sbin/haproxy -f $config_file -p $pid_file -L $peer_name
fi

バックエンドの変更

最後に、stick-table をバックエンド内で使用するために、HAProxy 設定を変更して stick-table およびピアセットを使用することができます。以下は、stick-table を使用するように TCP 接続の既存のバックエンドを変更している例です。

            {{ if eq $cfg.TLSTermination "passthrough" }}
backend be_tcp_{{$cfgIdx}}
  balance leastconn
  timeout check 5000ms
  stick-table type ip size 1m expire 5m{{ if (len $.PeerEndpoints) gt 0 }} peers openshift_peers {{ end }}
  stick on src
                {{ range $endpointID, $endpoint := $serviceUnit.EndpointTable }}
  server {{$endpointID}} {{$endpoint.IP}}:{{$endpoint.Port}} check inter 5000ms
                {{ end }}
            {{ end }}

この変更を行った後に、ルーターを再ビルドできます。

ルーターを再ビルドするには、実行中のルーターにある複数のファイルのコピーが必要になります。作業ディレクトリーを作成し、ルーターからファイルをコピーします。

# mkdir - myrouter/conf
# cd myrouter
# oc get po
NAME                       READY     STATUS    RESTARTS   AGE
router-2-40fc3             1/1       Running   0          11d
# oc rsh router-2-40fc3 cat haproxy-config.template > conf/haproxy-config.template
# oc rsh router-2-40fc3 cat error-page-503.http > conf/error-page-503.http
# oc rsh router-2-40fc3 cat default_pub_keys.pem > conf/default_pub_keys.pem
# oc rsh router-2-40fc3 cat ../Dockerfile > Dockerfile
# oc rsh router-2-40fc3 cat ../reload-haproxy > reload-haproxy

これらのファイルのいずれも編集するか、または置き換えることができます。ただし、conf/haproxy-config.template と reload-haproxy が変更される可能性が高くなります。

ファイルの更新後:

# docker build -t openshift/origin-haproxy-router-myversion .
# docker tag openshift/origin-haproxy-router-myversion 172.30.243.98:5000/openshift/haproxy-router-myversion 1
# docker push 172.30.243.98:5000/openshift/origin-haproxy-router-pc:latest 2

新規ルーターを使用するには、image: 文字列を変更するか、または --images=<repo>/<image>:<tag> フラグを oc adm router コマンドに追加してルーターデプロイ設定を編集します。

変更のデバッグ時に、デプロイメント設定で imagePullPolicy: Always を設定して各 Pod の作成時にイメージプルを強制的に実行すると便利です。デバッグが完了したら、これを imagePullPolicy: IfNotPresent に戻して各 Pod の起動時のプルを回避します。

デフォルトで HAProxy ルーターは、非セキュアな edge および re-encrypt ルートへの受信接続に HTTP を使用することを想定しています。ただし、PROXY プロトコルを使用することで、ルーターが受信要求を予想するよう設定することができます。このトピックでは、HAProxy ルーターと外部ロードバランサーを PROXY プロトコルを使用するように設定する方法を説明しています。

プロキシーサーバーやロードバランサーなどの中間サービスが HTTP 要求を転送する際に、これは接続のソースアドレスを要求の「Forwarded」ヘッダーに追加して、この情報を後続の中間サービスと、要求が最終的に転送されるバックエンドサービスに提供できます。ただし、接続が暗号化されている場合、中間サービスは「Forwarded」ヘッダーを変更できません。この場合、要求が転送されても HTTP ヘッダーは元のソースアドレスを正確に通信することができません。

この問題を解決するために、一部のロードバランサーは、単純に HTTP を転送する代替手段として PROXY プロトコルを使用して HTTP 要求をカプセル化します。カプセル化によって、ロードバランサーは転送される要求自体を変更することなく、情報を要求に追加することができます。これにより、ロードバランサーは、暗号化された接続を転送する場合でもソースアドレスを通信できます。

HAProxy ルーターが PROXY プロトコルを受け入れ、HTTP 要求のカプセル化を解除するように設定できます。ルーターは edge および re-encrypt ルートの暗号化を終了するので、ルーターは要求の「Forwarded」HTTP ヘッダー (および関連する HTTP ヘッダー) を更新でき、PROXY プロトコルを使用して通信されるソースアドレスを追加できます。

デフォルトで、HAProxy ルーターは PROXY プロトコルを使用しません。ROUTER_USE_PROXY_PROTOCOL 環境変数を使用することで、ルーターが受信接続に PROXY プロコトルの使用を予想するように設定できます。

$ oc env dc/router ROUTER_USE_PROXY_PROTOCOL=true

変数を true または TRUE 以外の値に設定し、PROXY プロコトルを無効にします。

$ oc env dc/router ROUTER_USE_PROXY_PROTOCOL=false

ルーターで PROXY プロトコルを有効にする場合、ルーターの前のロードバランサーが PROXY プロコトルを使用するように設定する必要があります。以下は、Amazon の Elastic Load Balancer (ELB) サービスを PROXY プロトコルを使用するように設定した例です。この例では、ELB がポート 80 (HTTP)、443 (HTTPS)、5000 (イメージレジストリーの場合) を 1 つ以上の EC2 インスタンスで実行されるルーターに転送することを想定しています。

$ aws elb describe-load-balancers --load-balancer-name "$lb" |
    jq '.LoadBalancerDescriptions| [.[]|.ListenerDescriptions]'
[
  [
    {
      "Listener": {
        "InstancePort": 80,
        "LoadBalancerPort": 80,
        "Protocol": "TCP",
        "InstanceProtocol": "TCP"
      },
      "PolicyNames": ["infra-lb-ProxyProtocol-policy"] 1
    },
    {
      "Listener": {
        "InstancePort": 443,
        "LoadBalancerPort": 443,
        "Protocol": "TCP",
        "InstanceProtocol": "TCP"
      },
      "PolicyNames": ["infra-lb-ProxyProtocol-policy"] 2
    },
    {
      "Listener": {
        "InstancePort": 5000,
        "LoadBalancerPort": 5000,
        "Protocol": "TCP",
        "InstanceProtocol": "TCP"
      },
      "PolicyNames": [] 3
    }
  ]
]

または、ELB をすでに設定していても、PROXY プロトコルを使用するよう設定されていない場合は、 TCP ポート 80 の既存リスナーを、HTTP ではなく TCP プロコトルを使用するように変更する必要があります (TCP ポート 443 はすでに TCP プロトコルを使用しているはずです)。

$ aws elb delete-load-balancer-listeners --load-balancer-name "$lb" \
   --load-balancer-ports 80
$ aws elb create-load-balancer-listeners --load-balancer-name "$lb" \
   --listeners 'Protocol=TCP,LoadBalancerPort=80,InstanceProtocol=TCP,InstancePort=80'

$ aws elb describe-load-balancers --load-balancer-name "$lb" |
   jq '[.LoadBalancerDescriptions[]|.ListenerDescriptions]'
[
  [
    {
      "Listener": {
        "InstancePort": 443,
        "LoadBalancerPort": 443,
        "Protocol": "TCP",
        "InstanceProtocol": "TCP"
      },
      "PolicyNames": []
    },
    {
      "Listener": {
        "InstancePort": 5000,
        "LoadBalancerPort": 5000,
        "Protocol": "TCP",
        "InstanceProtocol": "TCP"
      },
      "PolicyNames": []
    },
    {
      "Listener": {
        "InstancePort": 80,
        "LoadBalancerPort": 80,
        "Protocol": "TCP", 1
        "InstanceProtocol": "TCP"
      },
      "PolicyNames": []
    }
  ]
]

次にロードバランサーポリシーを作成し、上記の手順 5 に説明されているようにこれを ELB に追加します。

F5 ルーターブラグインはコンテナーイメージとして提供され、デフォルトの HAProxy ルーターのように Pod として実行されます。

F5 ルータープラグインのデプロイ時に、以下の要件を満たしていることを確認してください。

OpenShift Container Platform は以下の F5 BIG-IP® バージョンのみをサポートしています。

$ oc adm policy remove-scc-from-user hostnetwork -z router
$ oc adm policy add-scc-to-user privileged -z router

oc adm router コマンドを使用して F5 ルーターをデプロイしますが、F5 BIG-IP® ホストの以下のパラメーターを指定する追加のフラグ (または環境変数) を提供します。

例を以下に示します。

$ oc adm router \
    --type=f5-router \
    --external-host=10.0.0.2 \
    --external-host-username=admin \
    --external-host-password=mypassword \
    --external-host-http-vserver=ose-vserver \
    --external-host-https-vserver=https-ose-vserver \
    --external-host-private-key=/path/to/key \
    --host-network=false \
    --service-account=router

HAProxy ルーターの場合のように、oc adm router コマンドがサービスとデプロイメント設定オブジェクトを作成するため、F5 ルーター自体が実行されるレプリケーションコントローラーと Pod が作成されます。レプリケーションコントローラーはクラッシュが発生した場合に F5 ルーターを再起動します。F5 ルーターはルート、エンドポイント、ノードを監視し、F5 BIG-IP® を適宜設定するため、 F5 ルーターを適切に設定された F5 BIG-IP® デプロイメントで実行することは高可用性の要件を満たすはずです。

パーティションパスによって、デフォルトの /Common パーティションではなく、カスタムの F5 BIG-IP® 管理パーティションで OpenShift Container Platform ルーティング設定を保存できます。カスタム管理パーティションを使用して F5 BIG-IP® 環境を保護することができます。つまり、F5 BIG-IP® システムオブジェクトに保存される OpenShift Container Platform 特有の設定が論理コンテナー内にあり、管理者はその管理パーティションでアクセス制御を定義できます。

管理パーティションの詳細については、F5 BIG-IP® ドキュメントを参照してください。

パーティションパスについて OpenShift Container Platform を設定するには、以下を実行します。

OpenShift Container Platform バージョン 3.4 時点で、F5 の OpenShift Container Platform とのネイティブな統合により、F5 の Ramp ノードを OpenShift SDN で作成されるオーバーレイネットワークの Pod に到達するように設定する必要がありません。

F5 コントローラー Pod は、Pod に直接正常に接続できるようにするために必要な十分な情報を使って起動する必要があります。

これで Ramp ノードを設定せずに F5 のセットアップを開始できます。