Ingress と負荷分散

手順

1. 次のコマンドを実行して、hello-openshift というプロジェクトを作成します。

   $ oc new-project hello-openshift

   Copy to Clipboard Toggle word wrap

2. 以下のコマンドを実行してプロジェクトに Pod を作成します。

   $ oc create -f https://raw.githubusercontent.com/openshift/origin/master/examples/hello-openshift/hello-pod.json

   Copy to Clipboard Toggle word wrap

3. 以下のコマンドを実行して、hello-openshift というサービスを作成します。

   $ oc expose pod/hello-openshift

   Copy to Clipboard Toggle word wrap

4. 次のコマンドを実行して、hello-openshift アプリケーションに対して、セキュアではないルートを作成します。

   $ oc expose svc hello-openshift

   Copy to Clipboard Toggle word wrap

手順

1. ルート定義を作成し、app-example-route.yaml というファイルに保存します。

   HTTP ヘッダーディレクティブを使用して作成されたルートの YAML 定義

   apiVersion: route.openshift.io/v1
   kind: Route
   # ...
   spec:
     host: app.example.com
     tls:
       termination: edge
     to:
       kind: Service
       name: app-example
     httpHeaders:
       actions: 

   1

   
         response: 

   2

   
         - name: Content-Location 

   3

   
           action:
             type: Set 

   4

   
             set:
               value: /lang/en-us 

   5

   Copy to Clipboard Toggle word wrap

   1

   HTTP ヘッダーに対して実行するアクションのリスト。

   2

   変更するヘッダーのタイプ。この場合は、応答ヘッダーです。

   3

   変更するヘッダーの名前。設定または削除できる使用可能なヘッダーのリストは、HTTP ヘッダーの設定 を参照してください。

   4

   ヘッダーに対して実行されるアクションのタイプ。このフィールドには、Set または Delete の値を指定できます。

   5

   HTTP ヘッダーの設定時は、値 を指定する必要があります。値は、そのヘッダーで使用可能なディレクティブのリストからの文字列 (例: DENY) にすることも、HAProxy の動的値構文を使用して解釈される動的値にすることもできます。この場合、値はコンテンツの相対位置に設定されます。

2. 新しく作成したルート定義を使用して、既存の Web アプリケーションへのルートを作成します。

   $ oc -n app-example create -f app-example-route.yaml

   Copy to Clipboard Toggle word wrap

1. デフォルトでは、ルーターは 5 秒ごとにリロードされ、最初から Pod 間の接続のバランスがリセットされます。その結果、roundrobin 状態はリロード間で保持されません。このアルゴリズムは、Pod のコンピューティング能力とストレージ容量がほぼ同じである場合に最適に機能します。たとえば、CI/CD パイプラインの使用により、アプリケーションまたはサービスのエンドポイントが継続的に変更される場合、結果的にバランスが不均一になる可能性があります。その場合は別のアルゴリズムを使用します。

2. 許可リストの IP アドレスと CIDR 範囲の数が 61 を超えると、それらは別のファイルに書き込まれます。これは haproxy.config ファイルから参照されます。このファイルは、/var/lib/haproxy/router/allowlists フォルダーに保存されます。

   注記

   アドレスが許可リストに書き込まれることを確認するには、CIDR 範囲の完全なリストが Ingress Controller 設定ファイルに記載されていることを確認します。etcd オブジェクトサイズ制限は、ルートアノテーションのサイズを制限します。このため、許可リストに追加できる IP アドレスと CIDR 範囲の最大数のしきい値が作成されます。

手順

1. Ingress オブジェクトの YAML ファイルを作成します。この例では、ファイルの名前は example-ingress.yaml です。

   Ingress オブジェクトの YAML 定義

   apiVersion: networking.k8s.io/v1
   kind: Ingress
   metadata:
     name: frontend
     ...
   spec:
     rules:
       ...
     tls:
     - {} 

   1

   Copy to Clipboard Toggle word wrap

   1

   この正確な構文を使用して、カスタム証明書を指定せずに TLS を指定します。

2. 次のコマンドを実行して、Ingress オブジェクトを作成します。

   $ oc create -f example-ingress.yaml

   Copy to Clipboard Toggle word wrap

手順

1. 次のコマンドを入力して、宛先 CA 証明書のシークレットを作成します。

   $ oc create secret generic dest-ca-cert --from-file=tls.crt=<file_path>

   Copy to Clipboard Toggle word wrap

   以下に例を示します。

   $ oc -n test-ns create secret generic dest-ca-cert --from-file=tls.crt=tls.crt

   Copy to Clipboard Toggle word wrap

   出力例

   secret/dest-ca-cert created

   Copy to Clipboard Toggle word wrap

2. route.openshift.io/destination-ca-certificate-secret を Ingress アノテーションに追加します。

   apiVersion: networking.k8s.io/v1
   kind: Ingress
   metadata:
     name: frontend
     annotations:
       route.openshift.io/termination: "reencrypt"
       route.openshift.io/destination-ca-certificate-secret: secret-ca-cert 

   1

   
   ...

   Copy to Clipboard Toggle word wrap

   1

   アノテーションは kubernetes シークレットを参照します。

3. このアノテーションで参照されているシークレットは、生成されたルートに挿入されます。

   出力例

   apiVersion: route.openshift.io/v1
   kind: Route
   metadata:
     name: frontend
     annotations:
       route.openshift.io/termination: reencrypt
       route.openshift.io/destination-ca-certificate-secret: secret-ca-cert
   spec:
   ...
     tls:
       insecureEdgeTerminationPolicy: Redirect
       termination: reencrypt
       destinationCACertificate: |
         -----BEGIN CERTIFICATE-----
         [...]
         -----END CERTIFICATE-----
   ...

   Copy to Clipboard Toggle word wrap

手順

1. 次のコマンドを実行して、シークレットと同じ namespace に role を作成し、ルーターサービスアカウントに読み取りアクセスを許可します。

   $ oc create role secret-reader --verb=get,list,watch --resource=secrets --resource-name=<secret-name> \ 

   1

   
   --namespace=<current-namespace> 

   2

   Copy to Clipboard Toggle word wrap

   1

   シークレットの実際の名前を指定します。

   2

   シークレットとルートの両方が存在する namespace を指定します。

2. 次のコマンドを実行して、シークレットと同じ namespace に rolebinding を作成し、ルーターサービスアカウントを新しく作成されたロールにバインドします。

   $ oc create rolebinding secret-reader-binding --role=secret-reader --serviceaccount=openshift-ingress:router --namespace=<current-namespace> 

   1

   Copy to Clipboard Toggle word wrap

   1

   シークレットとルートの両方が存在する namespace を指定します。

3. 次の例を使用して、route を定義し、証明書を含むシークレットを指定する YAML ファイルを作成します。

   セキュアなルートの YAML 定義

   apiVersion: route.openshift.io/v1
   kind: Route
   metadata:
     name: myedge
     namespace: test
   spec:
     host: myedge-test.apps.example.com
     tls:
       externalCertificate:
         name: <secret-name> 

   1

   
       termination: edge
       [...]
   [...]

   Copy to Clipboard Toggle word wrap

   1

   シークレットの実際の名前を指定します。

4. 次のコマンドを実行して route リソースを作成します。

   $ oc apply -f <route.yaml> 

   1

   Copy to Clipboard Toggle word wrap

   1

   生成された YAML ファイル名を指定します。

   シークレットが存在し、証明書/キーペアがある場合、すべての前提条件が満たされていれば、ルーターは生成された証明書を提供します。

   注記

   .spec.tls.externalCertificate が指定されていないと、ルーターはデフォルトで生成された証明書を使用します。

   .spec.tls.externalCertificate フィールドを使用する場合は、.spec.tls.certificate フィールドまたは .spec.tls.key フィールドを指定することはできません。