第22章 ルートの作成

手順

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

   $ oc new-project hello-openshift

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

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

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

   $ oc expose pod/hello-openshift

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

   $ oc expose svc hello-openshift

手順

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

   $ oc new-project hello-openshift

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

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

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

   $ oc expose pod/hello-openshift

4. hello-openshift-route.yaml というルート定義を作成します。

   シャーディング用に作成したルートの YAML 定義

   apiVersion: route.openshift.io/v1
   kind: Route
   metadata:
     labels:
       type: sharded 1
     name: hello-openshift-edge
     namespace: hello-openshift
   spec:
     subdomain: hello-openshift 2
     tls:
       termination: edge
     to:
       kind: Service
       name: hello-openshift

   1

   ラベルキーとそれに対応するラベル値の両方が、Ingress Controller で指定されたものと一致する必要があります。この例では、Ingress Controller にはラベルキーと値 type: sharded があります。

   2

   ルートは、subdomain フィールドの値を使用して公開されます。subdomain フィールドを指定するときは、ホスト名を未設定のままにしておく必要があります。host フィールドと subdomain フィールドの両方を指定すると、ルートは host フィールドの値を使用し、subdomain フィールドを無視します。

5. 次のコマンドを実行し、hello-openshift-route.yaml を使用して hello-openshift アプリケーションへのルートを作成します。

   $ oc -n hello-openshift create -f hello-openshift-route.yaml

手順

1. oc annotate コマンドを使用して、ルートにタイムアウトを追加します。

   $ oc annotate route <route_name> \
       --overwrite haproxy.router.openshift.io/timeout=<timeout><time_unit> 1

   1

   サポートされる時間単位は、マイクロ秒 (us)、ミリ秒 (ms)、秒 (s)、分 (m)、時間 (h)、または日 (d) です。

   以下の例では、2 秒のタイムアウトを myroute という名前のルートに設定します。

   $ oc annotate route myroute --overwrite haproxy.router.openshift.io/timeout=2s

手順

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

   1

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

   2

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

   3

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

   4

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

   5

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

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

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

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

   注記

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

手順

1. OpenShift Container Platform コンソールで Ingress オブジェクトを定義するか、oc create コマンドを実行します。

   Ingress の YAML 定義

   apiVersion: networking.k8s.io/v1
   kind: Ingress
   metadata:
     name: frontend
     annotations:
       route.openshift.io/termination: "reencrypt" 1
       route.openshift.io/destination-ca-certificate-secret: secret-ca-cert 2
   spec:
     rules:
     - host: www.example.com 3
       http:
         paths:
         - backend:
             service:
               name: frontend
               port:
                 number: 443
           path: /
           pathType: Prefix
     tls:
     - hosts:
       - www.example.com
       secretName: example-com-tls-certificate

   1

   route.openshift.io/termination アノテーションは、Route の spec.tls.termination フィールドを設定するために使用できます。Ingress にはこのフィールドがありません。許可される値は edge、passthrough、および reencrypt です。その他のすべての値は警告なしに無視されます。アノテーション値が設定されていない場合は、edge がデフォルトルートになります。デフォルトのエッジルートを実装するには、TLS 証明書の詳細をテンプレートファイルで定義する必要があります。

   3

   Ingress オブジェクトを操作する場合、ルートを操作する場合とは異なり、明示的なホスト名を指定する必要があります。<host_name>.<cluster_ingress_domain> 構文 (apps.openshiftdemos.com など) を使用して、*.<cluster_ingress_domain> ワイルドカード DNS レコードとクラスターのサービング証明書を利用できます。それ以外の場合は、選択したホスト名の DNS レコードがあることを確認する必要があります。

   1. route.openshift.io/termination アノテーションで passthrough の値を指定する場合は、仕様で path を '' に設定し、pathType を ImplementationSpecific に設定します。

        spec:
          rules:
          - host: www.example.com
            http:
              paths:
              - path: ''
                pathType: ImplementationSpecific
                backend:
                  service:
                    name: frontend
                    port:
                      number: 443

      $ oc apply -f ingress.yaml

   2

   route.openshift.io/destination-ca-certificate-secret を Ingress オブジェクトで使用して、カスタム宛先証明書 (CA) でルートを定義できます。アノテーションは、生成されたルートに挿入される kubernetes シークレット secret-ca-cert を参照します。

   1. Ingress オブジェクトから宛先 CA を使用してルートオブジェクトを指定するには、シークレットの data.tls.crt 指定子に PEM エンコード形式の証明書を使用して kubernetes.io/tls または Opaque タイプのシークレットを作成する必要があります。

2. ルートを一覧表示します。

   $ oc get routes

   結果には、frontend- で始まる名前の自動生成ルートが含まれます。

   NAME             HOST/PORT         PATH    SERVICES    PORT    TERMINATION          WILDCARD
   frontend-gnztq   www.example.com           frontend    443     reencrypt/Redirect   None

   このルートを検査すると、以下のようになります。

   自動生成されるルートの YAML 定義

   apiVersion: route.openshift.io/v1
   kind: Route
   metadata:
     name: frontend-gnztq
     ownerReferences:
     - apiVersion: networking.k8s.io/v1
       controller: true
       kind: Ingress
       name: frontend
       uid: 4e6c59cc-704d-4f44-b390-617d879033b6
   spec:
     host: www.example.com
     path: /
     port:
       targetPort: https
     tls:
       certificate: |
         -----BEGIN CERTIFICATE-----
         [...]
         -----END CERTIFICATE-----
       insecureEdgeTerminationPolicy: Redirect
       key: |
         -----BEGIN RSA PRIVATE KEY-----
         [...]
         -----END RSA PRIVATE KEY-----
       termination: reencrypt
       destinationCACertificate: |
         -----BEGIN CERTIFICATE-----
         [...]
         -----END CERTIFICATE-----
     to:
       kind: Service
       name: frontend

手順

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

   Ingress オブジェクトの YAML 定義

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

   1

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

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

   $ oc create -f example-ingress.yaml

手順

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

   1

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

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

   出力例

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

手順

1. Ingress Controller が、IPv4 / IPv6 を介してトラフィックをワークロードに提供するようにするには、ipFamilies フィールドおよび ipFamilyPolicy フィールドを設定して、サービス YAML ファイルを作成するか、既存のサービス YAML ファイルを変更します。以下に例を示します。

   サービス YAML ファイルの例

   apiVersion: v1
   kind: Service
   metadata:
     creationTimestamp: yyyy-mm-ddT00:00:00Z
     labels:
       name: <service_name>
       manager: kubectl-create
       operation: Update
       time: yyyy-mm-ddT00:00:00Z
     name: <service_name>
     namespace: <namespace_name>
     resourceVersion: "<resource_version_number>"
     selfLink: "/api/v1/namespaces/<namespace_name>/services/<service_name>"
     uid: <uid_number>
   spec:
     clusterIP: 172.30.0.0/16
     clusterIPs: 1
     - 172.30.0.0/16
     - <second_IP_address>
     ipFamilies: 2
     - IPv4
     - IPv6
     ipFamilyPolicy: RequireDualStack 3
     ports:
     - port: 8080
       protocol: TCP
       targetport: 8080
     selector:
       name: <namespace_name>
     sessionAffinity: None
     type: ClusterIP
   status:
     loadbalancer: {}

   1

   デュアルスタックインスタンスでは、2 つの異なる clusterIPs が提供されます。

   2

   シングルスタックインスタンスの場合は、IPv4 または IPv6 と入力します。デュアルスタックインスタンスの場合は、IPv4 と IPv6 の両方を入力します。

   3

   シングルスタックインスタンスの場合は、SingleStack と入力します。デュアルスタックインスタンスの場合は、RequireDualStack と入力します。

   これらのリソースは、対応する endpoints を生成します。Ingress Controller は、endpointslices を監視するようになりました。

2. endpoints を表示するには、以下のコマンドを入力します。

   $ oc get endpoints

3. endpointslices を表示するには、以下のコマンドを入力します。

   $ oc get endpointslices