ネットワーク

Red Hat OpenShift Service on AWS 4

Red Hat OpenShift Service on AWS ネットワーキングの設定

Red Hat OpenShift Documentation Team

概要

このドキュメントは、Red Hat OpenShift Service on AWS (ROSA) クラスターのネットワークに関する情報を提供します。

第1章 Red Hat OpenShift Service on AWS の DNS Operator

DNS Operator は、Pod に対して名前解決サービスを提供するために CoreDNS をデプロイし、これを管理し、Red Hat OpenShift Service on AWS での DNS ベースの Kubernetes サービス検出を可能にします。

1.1. DNS 転送の使用

次の方法で、DNS 転送を使用して /etc/resolv.conf ファイル内のデフォルトの転送設定をオーバーライドできます。

  • すべてのゾーンにネームサーバーを指定します。転送されるゾーンが Red Hat OpenShift Service on AWS に管理される Ingress ドメインである場合は、アップストリームネームサーバーがドメインについて認証される必要があります。

    重要

    少なくとも 1 つのゾーンを指定する必要があります。そうしないと、クラスターの機能が失われる可能性があります。

  • アップストリーム DNS サーバーのリストを指定します。
  • デフォルトの転送ポリシーを変更します。
注記

デフォルトドメインの DNS 転送設定には、/etc/resolv.conf ファイルおよびアップストリーム DNS サーバーで指定されたデフォルトのサーバーの両方を設定できます。

手順

  1. default という名前の DNS Operator オブジェクトを変更します。 

    $ oc edit dns.operator/default

    以前のコマンドを実行した後に、Operator は Server に基づく追加のサーバー設定ブロックを使用して dns-default という名前の config map を作成して更新します。

    重要

    zones パラメーターの値を指定する場合は、イントラネットなどの特定のゾーンにのみ転送してください。少なくとも 1 つのゾーンを指定する必要があります。そうしないと、クラスターの機能が失われる可能性があります。

    クエリーに一致するゾーンがサーバーにない場合には、名前解決はアップストリーム DNS サーバーにフォールバックします。

    DNS 転送の設定

    apiVersion: operator.openshift.io/v1
kind: DNS
metadata:
  name: default
spec:
  servers:
  - name: example-server 1
    zones: 2
    - example.com
    forwardPlugin:
      policy: Random 3
      upstreams: 4
      - 1.1.1.1
      - 2.2.2.2:5353
  upstreamResolvers: 5
    policy: Random 6
    upstreams: 7
    - type: SystemResolvConf 8
    - type: Network
      address: 1.2.3.4 9
      port: 53 10

    1
    rfc6335 サービス名の構文に準拠する必要があります。
    2
    rfc1123 サービス名構文のサブドメインの定義に準拠する必要があります。クラスタードメインの cluster.local は、zones フィールドの無効なサブドメインです。
    3
    アップストリームリゾルバーを選択するためのポリシーを定義します。デフォルト値はRandomです。RoundRobin および Sequential の値を使用することもできます。
    4
    forwardPlugin ごとに最大 15 の upstreams が許可されます。
    5
    オプション: これを使用して、デフォルトポリシーを上書きし、デフォルトドメインで指定された DNS リゾルバー (アップストリームリゾルバー) に DNS 解決を転送できます。アップストリームリゾルバーを指定しない場合に、DNS 名のクエリーは /etc/resolv.conf のサーバーに送信されます。
    6
    クエリー用にアップストリームサーバーが選択される順序を決定します。Random、Round Robin、またはSequential のいずれかの値を指定できます。デフォルト値はSequentialです。
    7
    オプション: これを使用して、アップストリームリゾルバーを指定できます。
    8
    SystemResolvConfとNetworkの 2 種類のアップストリームを指定できます。SystemResolvConf で、アップストリームが /etc/resolv.conf を使用するように設定して、Network で Networkresolver を定義します。1 つまたは両方を指定できます。
    9
    指定したタイプがNetworkの場合には、IP アドレスを指定する必要があります。address フィールドは、有効な IPv4 または IPv6 アドレスである必要があります。
    10
    指定したタイプが Network の場合、必要に応じてポートを指定できます。port フィールドには 1 - 65535 の値を指定する必要があります。アップストリームのポートを指定しない場合、デフォルトでポート 853 が試行されます。

  2. オプション: 高度に規制された環境で作業する場合は、要求をアップストリームリゾルバーに転送する際に DNS トラフィックのセキュリティーを確保して、追加の DNS トラフィックおよびデータのプライバシーを確保できるようにする必要がある場合があります。

    重要

    zones パラメーターの値を指定する場合は、イントラネットなどの特定のゾーンにのみ転送してください。少なくとも 1 つのゾーンを指定する必要があります。そうしないと、クラスターの機能が失われる可能性があります。

    クラスター管理者は、転送された DNS クエリーに Transport Layer Security (TLS) を設定できるようになりました。

    TLS を使用した DNS 転送の設定

    apiVersion: operator.openshift.io/v1
kind: DNS
metadata:
  name: default
spec:
  servers:
  - name: example-server 1
    zones: 2
    - example.com
    forwardPlugin:
      transportConfig:
        transport: TLS 3
        tls:
          caBundle:
            name: mycacert
          serverName: dnstls.example.com  4
      policy: Random 5
      upstreams: 6
      - 1.1.1.1
      - 2.2.2.2:5353
  upstreamResolvers: 7
    transportConfig:
      transport: TLS
      tls:
        caBundle:
          name: mycacert
        serverName: dnstls.example.com
    upstreams:
    - type: Network 8
      address: 1.2.3.4 9
      port: 53 10

    1
    rfc6335 サービス名の構文に準拠する必要があります。
    2
    rfc1123 サービス名構文のサブドメインの定義に準拠する必要があります。クラスタードメインの cluster.local は、zones フィールドの無効なサブドメインです。クラスタードメインの cluster.local は、 zones の無効な subdomain です。
    3
    転送された DNS クエリーの TLS を設定する場合、transport フィールドの値を TLS に設定します。デフォルトでは、CoreDNS は転送された接続を 10 秒間キャッシュします。要求が発行されない場合、CoreDNS はその 10 秒間、TCP 接続を開いたままにします。大規模なクラスターでは、ノードごとに接続を開始できるため、DNS サーバーが多くの新しい接続を開いたまま保持する可能性があることを認識しているか確認してください。パフォーマンスの問題を回避するために、それに応じて DNS 階層を設定します。
    4
    転送された DNS クエリー用に TLS を設定する場合、これは、アップストリーム TLS サーバー証明書を検証するための Server Name Indication (SNI) の一部として使用される必須のサーバー名です。
    5
    アップストリームリゾルバーを選択するためのポリシーを定義します。デフォルト値はRandomです。RoundRobin および Sequential の値を使用することもできます。
    6
    必須。これを使用して、アップストリームリゾルバーを指定できます。forwardPlugin エントリーごとに最大 15 の upstreams エントリーが許可されます。
    7
    オプション: これを使用して、デフォルトポリシーを上書きし、デフォルトドメインで指定された DNS リゾルバー (アップストリームリゾルバー) に DNS 解決を転送できます。アップストリームリゾルバーを指定しない場合に、DNS 名のクエリーは /etc/resolv.conf のサーバーに送信されます。
    8
    Network タイプは、このアップストリームリゾルバーが /etc/resolv.conf にリストされているアップストリームリゾルバーとは別に転送されたリクエストを処理する必要があることを示します。TLS を使用する場合、Network タイプのみが許可され、IP アドレスを指定する必要があります。
    9
    address フィールドは、有効な IPv4 または IPv6 アドレスである必要があります。
    10
    オプションでポートを指定できます。port の値は 1 〜 65535 である必要があります。アップストリームのポートを指定しない場合、デフォルトでポート 853 が試行されます。
    注記

    servers が定義されていないか無効な場合、config map にはデフォルトサーバーのみが含まれます。

検証

  1. config map を表示します。 

    $ oc get configmap/dns-default -n openshift-dns -o yaml

    以前のサンプル DNS に基づく DNS ConfigMap の例

    apiVersion: v1
data:
  Corefile: |
    example.com:5353 {
        forward . 1.1.1.1 2.2.2.2:5353
    }
    bar.com:5353 example.com:5353 {
        forward . 3.3.3.3 4.4.4.4:5454 1
    }
    .:5353 {
        errors
        health
        kubernetes cluster.local in-addr.arpa ip6.arpa {
            pods insecure
            upstream
            fallthrough in-addr.arpa ip6.arpa
        }
        prometheus :9153
        forward . /etc/resolv.conf 1.2.3.4:53 {
            policy Random
        }
        cache 30
        reload
    }
kind: ConfigMap
metadata:
  labels:
    dns.operator.openshift.io/owning-dns: default
  name: dns-default
  namespace: openshift-dns

    1
    forwardPlugin への変更により、CoreDNS デーモンセットのローリング更新がトリガーされます。

関連情報

第2章 Red Hat OpenShift Service on AWS の Ingress Operator

2.1. Red Hat OpenShift Service on AWS Ingress Operator

Red Hat OpenShift Service on AWS クラスターを作成すると、クラスターで実行されている Pod とサービスにそれぞれ独自の IP アドレスが割り当てられます。IP アドレスは、近くで実行されている他の Pod やサービスからアクセスできますが、外部クライアントの外部からはアクセスできません。Ingress Operator は IngressController API を実装し、Red Hat OpenShift Service on AWS クラスターサービスへの外部アクセスを可能にするコンポーネントです。

Ingress Operator を使用すると、ルーティングを処理する 1 つ以上の HAProxy ベースの Ingress Controller をデプロイおよび管理することにより、外部クライアントがサービスにアクセスできるようになります。Red Hat Site Reliability Engineer (SRE) は、Red Hat OpenShift Service on AWS クラスターの Ingress Operator を管理します。Ingress Operator の設定を変更することはできませんが、デフォルトの Ingress コントローラーの設定、ステータス、およびログおよび Ingress Operator ステータスを表示できます。

2.2. Ingress 設定アセット

インストールプログラムでは、config.openshift.io API グループの Ingress リソースでアセットを生成します (cluster-ingress-02-config.yml)。

Ingress リソースの YAML 定義

apiVersion: config.openshift.io/v1
kind: Ingress
metadata:
  name: cluster
spec:
  domain: apps.openshiftdemos.com

インストールプログラムは、このアセットを manifests/ ディレクトリーの cluster-ingress-02-config.yml ファイルに保存します。この Ingress リソースは、Ingress のクラスター全体の設定を定義します。この Ingress 設定は、以下のように使用されます。

  • Ingress Operator は、クラスター Ingress 設定のドメインを、デフォルト Ingress Controller のドメインとして使用します。
  • OpenShift API Server Operator は、クラスター Ingress 設定からのドメインを使用します。このドメインは、明示的なホストを指定しない Route リソースのデフォルトホストを生成する際にも使用されます。

2.3. Ingress Controller 設定パラメーター

ingresscontrollers.operator.openshift.io リソースは以下の設定パラメーターを提供します。

パラメーター説明

domain

domain は Ingress Controller によって提供される DNS 名で、複数の機能を設定するために使用されます。

  • LoadBalancerService エンドポイント公開ストラテジーの場合、domain は DNS レコードを設定するために使用されます。endpointPublishingStrategy を参照してください。
  • 生成されるデフォルト証明書を使用する場合、証明書は domain およびその subdomains で有効です。defaultCertificate を参照してください。
  • この値は個別の Route ステータスに公開され、ユーザーは外部 DNS レコードのターゲット先を認識できるようにします。

domain 値はすべての Ingress Controller の中でも固有の値であり、更新できません。

空の場合、デフォルト値は ingress.config.openshift.io/cluster .spec.domain です。

replicas

replicas は Ingress Controller レプリカの必要な数です。設定されていない場合、デフォルト値は 2 になります。

endpointPublishingStrategy

endpointPublishingStrategy は Ingress Controller エンドポイントを他のネットワークに公開し、ロードバランサーの統合を有効にし、他のシステムへのアクセスを提供するために使用されます。

次の endpointPublishingStrategy フィールドを設定できます。

  • loadBalancer.scope
  • loadBalancer.allowedSourceRanges

設定されていない場合、デフォルト値は infrastructure.config.openshift.io/cluster .status.platform をベースとします。

  • Amazon Web Services (AWS): LoadBalancerService (外部スコープあり)

    注記

    HostNetwork には、オプションのバインディングポートのデフォルト値が httpPort:80、httpsPort:443、statsPort:1936 の hostNetwork フィールドがあります。バインディングポートを使用すると、HostNetwork ストラテジーの同じノードに複数の Ingress Controller をデプロイできます。

    例

    apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name: internal
  namespace: openshift-ingress-operator
spec:
  domain: example.com
  endpointPublishingStrategy:
    type: HostNetwork
    hostNetwork:
      httpPort: 80
      httpsPort: 443
      statsPort: 1936

    注記

    Red Hat OpenStack Platform (RHOSP) では、クラウドプロバイダーがヘルスモニターを作成するように設定されている場合にのみ、LoadBalancerService エンドポイントの公開ストラテジーがサポートされます。RHOSP 16.2 の場合、このストラテジーは Amphora Octavia プロバイダーを使用する場合にのみ可能です。

    詳細については、RHOSP インストールドキュメントのクラウドプロバイダーオプションの設定セクションを参照してください。

defaultCertificate

defaultCertificate 値は、Ingress Controller によって提供されるデフォルト証明書が含まれるシークレットへの参照です。ルートが独自の証明書を指定しない場合、defaultCertificate が使用されます。

シークレットには以下のキーおよびデータが含まれる必要があります: * tls.crt: 証明書ファイルコンテンツ * tls.key: キーファイルコンテンツ

設定されていない場合、ワイルドカード証明書は自動的に生成され、使用されます。証明書は Ingress コントーラーの domain および subdomains で有効であり、生成された証明書 CA はクラスターの信頼ストアに自動的に統合されます。

使用中の証明書は、生成されたものでもユーザーが指定したものでも、Red Hat OpenShift Service on AWS のビルトイン OAuth サーバーと自動的に統合されます。

namespaceSelector

namespaceSelector は、Ingress Controller によって提供される namespace セットをフィルターするために使用されます。これはシャードの実装に役立ちます。

routeSelector

routeSelector は、Ingress Controller によって提供される Routes のセットをフィルターするために使用されます。これはシャードの実装に役立ちます。

nodePlacement

nodePlacement は、Ingress Controller のスケジュールに対する明示的な制御を有効にします。

設定されていない場合は、デフォルト値が使用されます。

注記

nodePlacement パラメーターには、nodeSelector と tolerations の 2 つの部分が含まれます。以下に例を示します。 

nodePlacement:
 nodeSelector:
   matchLabels:
     kubernetes.io/os: linux
 tolerations:
 - effect: NoSchedule
   operator: Exists

tlsSecurityProfile

tlsSecurityProfile は、Ingress Controller の TLS 接続の設定を指定します。

これが設定されていない場合、デフォルト値は apiservers.config.openshift.io/cluster リソースをベースとして設定されます。

Old、Intermediate、および Modern のプロファイルタイプを使用する場合、有効なプロファイル設定はリリース間で変更される可能性があります。たとえば、リリース X.Y.Z にデプロイされた Intermediate プロファイルを使用する仕様がある場合、リリース X.Y.Z+1 へのアップグレードにより、新規のプロファイル設定が Ingress Controller に適用され、ロールアウトが生じる可能性があります。

Ingress Controller の最小 TLS バージョンは 1.1 で、最大 TLS バージョンは 1.3 です。

注記

設定されたセキュリティープロファイルの暗号および最小 TLS バージョンが TLSProfile ステータスに反映されます。

重要

Ingress Operator は TLS 1.0 の Old または Custom プロファイルを 1.1 に変換します。

clientTLS

clientTLS は、クラスターおよびサービスへのクライアントアクセスを認証します。その結果、相互 TLS 認証が有効になります。設定されていない場合、クライアント TLS は有効になっていません。

ClientTLS には、必要なサブフィールド spec.clientTLS.clientCertificatePolicy および spec.clientTLS.ClientCA があります。

ClientCertificatePolicy サブフィールドは、Required または Optional の 2 つの値のいずれかを受け入れます。ClientCA サブフィールドは、openshift-config namespace にある ConfigMap を指定します。ConfigMap には CA 証明書バンドルが含まれている必要があります。

AllowedSubjectPatterns は、要求をフィルターするために有効なクライアント証明書の識別名と照合される正規表現のリストを指定する任意の値です。正規表現は PCRE 構文を使用する必要があります。1 つ以上のパターンがクライアント証明書の識別名と一致している必要があります。一致しない場合、Ingress Controller は証明書を拒否し、接続を拒否します。指定しないと、Ingress Controller は識別名に基づいて証明書を拒否しません。

routeAdmission

routeAdmission は、複数の namespace での要求の許可または拒否など、新規ルート要求を処理するためのポリシーを定義します。

namespaceOwnership は、namespace 間でホスト名の要求を処理する方法を記述します。デフォルトは Strict です。

  • Strict: ルートが複数の namespace 間で同じホスト名を要求することを許可しません。
  • InterNamespaceAllowed: ルートが複数の namespace 間で同じホスト名の異なるパスを要求することを許可します。

wildcardPolicy は、ワイルドカードポリシーを使用するルートが Ingress Controller によって処理される方法を記述します。

  • WildcardsAllowed: ワイルドカードポリシーと共にルートが Ingress Controller によって許可されていることを示します。
  • WildcardsDisallowed: ワイルドカードポリシーの None を持つルートのみが Ingress Controller によって許可されることを示します。wildcardPolicy を WildcardsAllowed から WildcardsDisallowed に更新すると、ワイルドカードポリシーの Subdomain を持つ許可されたルートが機能を停止します。これらのルートは、Ingress Controller によって許可されるように None のワイルドカードポリシーに対して再作成される必要があります。WildcardsDisallowed はデフォルト設定です。

IngressControllerLogging

logging はログに記録される内容および場所のパラメーターを定義します。このフィールドが空の場合、操作ログは有効になりますが、アクセスログは無効になります。

  • access は、クライアント要求をログに記録する方法を記述します。このフィールドが空の場合、アクセスロギングは無効になります。

    • destination はログメッセージの宛先を記述します。

      • type はログの宛先のタイプです。

        • Container は、ログがサイドカーコンテナーに移動することを指定します。Ingress Operator は Ingress Controller Pod で logs という名前のコンテナーを設定し、Ingress Controller がログをコンテナーに書き込むように設定します。管理者がこのコンテナーからログを読み取るカスタムロギングソリューションを設定することが予想されます。コンテナーログを使用すると、ログの割合がコンテナーランタイムの容量やカスタムロギングソリューションの容量を超えるとログがドロップされることがあります。
        • Syslog は、ログが Syslog エンドポイントに送信されることを指定します。管理者は、Syslog メッセージを受信できるエンドポイントを指定する必要があります。管理者がカスタム Syslog インスタンスを設定していることが予想されます。
      • container は Container ロギング宛先タイプのパラメーターを記述します。現在、コンテナーロギングのパラメーターはないため、このフィールドは空である必要があります。

      • syslog は、Syslog ロギング宛先タイプのパラメーターを記述します。

        • address は、ログメッセージを受信する syslog エンドポイントの IP アドレスです。
        • port は、ログメッセージを受信する syslog エンドポイントの UDP ポート番号です。
        • maxLengthは、syslog メッセージの最大長です。サイズは 480 から 4096 バイトである必要があります。このフィールドが空の場合には、最大長はデフォルト値の1024バイトに設定されます。
        • facility はログメッセージの syslog ファシリティーを指定します。このフィールドが空の場合、ファシリティーは local1 になります。それ以外の場合、有効な syslog ファシリティー ( kern、user、mail、daemon、auth、 syslog、lpr、news、uucp、cron、 auth2、ftp、 ntp、audit、 alert、cron2、 local0、local1、 local2、local3) を指定する必要があります。local4、local5、 local6、または local7。
    • httpLogFormat は、HTTP 要求のログメッセージの形式を指定します。このフィールドが空の場合、ログメッセージは実装のデフォルト HTTP ログ形式を使用します。HAProxy のデフォルトの HTTP ログ形式については、HAProxy ドキュメント を参照してください。

httpHeaders

httpHeaders は HTTP ヘッダーのポリシーを定義します。

IngressControllerHTTPHeaders の forwardedHeaderPolicy を設定することで、Ingress Controller が Forwarded、X-Forwarded-For、X-Forwarded-Host、X-Forwarded-Port、X-Forwarded-Proto、および X-Forwarded-Proto-Version HTTP ヘッダーをいつどのように設定するか指定します。

デフォルトでは、ポリシーは Append に設定されます。

  • Append は、Ingress Controller がヘッダーを追加するように指定し、既存のヘッダーを保持します。
  • Replace は、Ingress Controller がヘッダーを設定するように指定し、既存のヘッダーを削除します。
  • IfNone は、ヘッダーがまだ設定されていない場合に、Ingress Controller がヘッダーを設定するように指定します。
  • Never は、Ingress Controller がヘッダーを設定しないように指定し、既存のヘッダーを保持します。

headerNameCaseAdjustments を設定して、HTTP ヘッダー名に適 用できるケースの調整を指定できます。それぞれの調整は、必要な大文字化を指定して HTTP ヘッダー名として指定されます。たとえば、X-Forwarded-For を指定すると、指定された大文字化を有効にするために x-forwarded-for HTTP ヘッダーを調整する必要があることを示唆できます。

これらの調整は、クリアテキスト、edge terminationd、および re-encrypt ルートにのみ適用され、HTTP/1 を使用する場合にのみ適用されます。

要求ヘッダーの場合、これらの調整は haproxy.router.openshift.io/h1-adjust-case=true アノテーションを持つルートについてのみ適用されます。応答ヘッダーの場合、これらの調整はすべての HTTP 応答に適用されます。このフィールドが空の場合、要求ヘッダーは調整されません。

actions は、ヘッダーに対して特定のアクションを実行するためのオプションを指定します。TLS パススルー接続のヘッダーは設定または削除できません。actions フィールドには、spec.httpHeader.actions.response および spec.httpHeader.actions.request の追加のサブフィールドがあります。

  • response サブフィールドは、設定または削除する HTTP 応答ヘッダーのリストを指定します。
  • request サブフィールドは、設定または削除する HTTP 要求ヘッダーのリストを指定します。

httpCompression

http Compressionは、HTTP トラフィック圧縮のポリシーを定義します。

  • mimeTypes は、圧縮を適用する必要がある MIME タイプのリストを定義します。(例: text/css; charset=utf-8, text/html, text/*, image/svg+xml, application/octet-stream, X-custom/customsub, using the format pattern, type/subtype; [;attribute=value])typesは、アプリケーション、イメージ、メッセージ、マルチパート、テキスト、ビデオ、またはX-で始まるカスタムタイプ。例: MIME タイプとサブタイプの完全な表記を確認するには、 RFC1341を参照してください。

httpErrorCodePages

httpErrorCodePages は、カスタムの HTTP エラーコードの応答ページを指定します。デフォルトで、IngressController は IngressController イメージにビルドされたエラーページを使用します。

httpCaptureCookies

httpCaptureCookies は、アクセスログにキャプチャーする HTTP Cookie を指定します。httpCaptureCookies フィールドが空の場合、アクセスログは Cookie をキャプチャーしません。

キャプチャーするすべての Cookie について、次のパラメーターが IngressController 設定に含まれている必要があります。

  • name は、Cookie の名前を指定します。
  • maxLength は、Cookie の最大長を指定します。
  • matchType は、Cookie のフィールド の name が、キャプチャー Cookie 設定と完全に一致するか、キャプチャー Cookie 設定の接頭辞であるかを指定します。matchType フィールドは Exact および Prefix パラメーターを使用します。

以下に例を示します。 

  httpCaptureCookies:
  - matchType: Exact
    maxLength: 128
    name: MYCOOKIE

httpCaptureHeaders

httpCaptureHeaders は、アクセスログにキャプチャーする HTTP ヘッダーを指定します。httpCaptureHeaders フィールドが空の場合、アクセスログはヘッダーをキャプチャーしません。

httpCaptureHeaders には、アクセスログにキャプチャーするヘッダーの 2 つのリストが含まれています。ヘッダーフィールドの 2 つのリストは request と response です。どちらのリストでも、name フィールドはヘッダー名を指定し、maxlength フィールドはヘッダーの最大長を指定する必要があります。以下に例を示します。 

  httpCaptureHeaders:
    request:
    - maxLength: 256
      name: Connection
    - maxLength: 128
      name: User-Agent
    response:
    - maxLength: 256
      name: Content-Type
    - maxLength: 256
      name: Content-Length

tuningOptions

tuningOptions は、Ingress Controller Pod のパフォーマンスを調整するためのオプションを指定します。

  • clientFinTimeout は、クライアントの応答が接続を閉じるのを待機している間に接続が開かれる期間を指定します。デフォルトのタイムアウトは 1s です。
  • clientTimeout は、クライアント応答の待機中に接続が開かれる期間を指定します。デフォルトのタイムアウトは 30s です。
  • headerBufferBytes は、Ingress Controller 接続セッション用に予約されるメモリーの量をバイト単位で指定します。Ingress Controller で HTTP / 2 が有効になっている場合、この値は少なくとも 16384 である必要があります。設定されていない場合、デフォルト値は 32768 バイトになります。このフィールドを設定することは推奨しません。headerBufferBytes 値が小さすぎると Ingress Controller が破損する可能性があり、headerBufferBytes 値が大きすぎると、Ingress Controller が必要以上のメモリーを使用する可能性があるためです。
  • headerBufferMaxRewriteBytes は、HTTP ヘッダーの書き換えと Ingress Controller 接続セッションの追加のために headerBufferBytes から予約するメモリーの量をバイト単位で指定します。headerBufferMaxRewriteBytes の最小値は 4096 です。受信 HTTP 要求には、headerBufferBytes は headerBufferMaxRewriteBytes よりも大きくなければなりません。設定されていない場合、デフォルト値は 8192 バイトになります。このフィールドを設定することは推奨しません。headerBufferMaxRewriteBytes 値が小さすぎると Ingress Controller が破損する可能性があり、headerBufferMaxRewriteBytes 値が大きすぎると、Ingress Controller が必要以上のメモリーを使用する可能性があるためです。
  • healthCheckInterval は、ルーターがヘルスチェックの間隔として待機する時間を指定します。デフォルトは 5s です。
  • serverFinTimeout は、接続を閉じるクライアントへの応答を待つ間、接続が開かれる期間を指定します。デフォルトのタイムアウトは 1s です。
  • serverTimeout は、サーバーの応答を待機している間に接続が開かれる期間を指定します。デフォルトのタイムアウトは 30s です。
  • threadCount は、HAProxy プロセスごとに作成するスレッドの数を指定します。より多くのスレッドを作成すると、使用されるシステムリソースを増やすことで、各 Ingress Controller Pod がより多くの接続を処理できるようになります。HAProxy は最大 64 のスレッドをサポートします。このフィールドが空の場合、Ingress Controller はデフォルト値の 4 スレッドを使用します。デフォルト値は、将来のリリースで変更される可能性があります。このフィールドを設定することは推奨しません。HAProxy スレッドの数を増やすと、Ingress Controller Pod が負荷時に CPU 時間をより多く使用できるようになり、他の Pod が実行に必要な CPU リソースを受け取れないようになるためです。スレッドの数を減らすと、Ingress Controller のパフォーマンスが低下する可能性があります。
  • tlsInspectDelay は、一致するルートを見つけるためにルーターがデータを保持する期間を指定します。この値の設定が短すぎると、より一致する証明書を使用している場合でも、ルーターがエッジ終端、再暗号化された、またはパススルーのルートのデフォルトの証明書にフォールバックする可能性があります。デフォルトの検査遅延は 5s です。
  • tunnelTimeout は、トンネルがアイドル状態の間、WebSocket などのトンネル接続期間を開いた期間を指定します。デフォルトのタイムアウトは 1h です。

  • maxConnections は、HAProxy プロセスごとに確立できる同時接続の最大数を指定します。この値を増やすと、追加のシステムリソースで各 Ingress Controller Pod がより多くの接続を処理できるようになります。0、-1、2000 から 2000000 の 範囲内の任意の値を使用でき、フィールドを空にすることも可能です。

    • このフィールドが空のままであるか、値が 0 の場合、Ingress Controller はデフォルト値の 50000 を使用します。この値は、今後のリリースで変更される可能性があります。
    • フィールド値が -1 の場合、HAProxy は、実行中のコンテナーで使用可能な ulimit に基づき最大値を動的に計算します。このプロセスにより、計算値が大きくなり、現在のデフォルト値である 50000 と比較してかなり大きなメモリー使用量が発生します。
    • フィールドの値が現在のオペレーティングシステムの制限よりも大きい場合、HAProxy プロセスは開始されません。
    • 個別の値を選択し、ルーター Pod が新しいノードに移行された場合、新しいノードに同一の ulimit が設定されていない可能性があります。このような場合、Pod は起動に失敗します。
    • 異なる ulimit を持つノードが設定されていて、離散値を選択する場合は、実行時に接続の最大数が計算されるように、このフィールドに -1 の値を使用することを推奨します。

logEmptyRequests

logEmptyRequests は、リクエストを受け取らず、ログに記録されない接続を指定します。これらの空の要求は、ロードバランサーヘルスプローブまたは Web ブラウザーの投機的接続 (事前接続) から送信され、これらの要求をログに記録することは望ましくない場合があります。ただし、これらの要求はネットワークエラーによって引き起こされる可能性があります。この場合は、空の要求をログに記録すると、エラーの診断に役立ちます。これらの要求はポートスキャンによって引き起こされ、空の要求をログに記録すると、侵入の試行が検出されなくなります。このフィールドに使用できる値は Log および Ignore です。デフォルト値は Log です。

LoggingPolicy タイプは、以下のいずれかの値を受け入れます。

  • ログ: この値を Log に設定すると、イベントがログに記録される必要があることを示します。
  • Ignore: この値を Ignore に設定すると、HAproxy 設定の dontlognull オプションを設定します。

HTTPEmptyRequestsPolicy

HTTPEmptyRequestsPolicy は、リクエストを受け取る前に接続がタイムアウトした場合に HTTP 接続を処理する方法を記述します。このフィールドに使用できる値は Respond および Ignore です。デフォルト値は Respond です。

HTTPEmptyRequestsPolicy タイプは、以下のいずれかの値を受け入れます。

  • 応答: フィールドが Respond に設定されている場合、Ingress Controller は HTTP 400 または 408 応答を送信する場合、アクセスログが有効な場合に接続をログに記録し、適切なメトリックで接続をカウントします。
  • ignore: このオプションを Ignore に設定すると HAproxy 設定に http-ignore-probes パラメーターが追加されます。フィールドが Ignore に設定されている場合、Ingress Controller は応答を送信せずに接続を閉じると、接続をログに記録するか、メトリックを増分します。

これらの接続は、ロードバランサーのヘルスプローブまたは Web ブラウザーの投機的接続 (事前接続) から取得され、無視しても問題はありません。ただし、これらの要求はネットワークエラーによって引き起こされる可能性があります。そのため、このフィールドを Ignore に設定すると問題の検出と診断が妨げられる可能性があります。これらの要求はポートスキャンによって引き起こされ、空の要求をログに記録すると、侵入の試行が検出されなくなります。

注記

すべてのパラメーターはオプションです。

2.3.1. Ingress Controller の TLS セキュリティープロファイル

TLS セキュリティープロファイルは、サーバーに接続する際に接続クライアントが使用できる暗号を規制する方法をサーバーに提供します。

2.3.1.1. TLS セキュリティープロファイルについて

TLS (Transport Layer Security) セキュリティープロファイルを使用すると、さまざまな Red Hat OpenShift Service on AWS コンポーネントで必須にする TLS 暗号を定義できます。Red Hat OpenShift Service on AWS の TLS セキュリティープロファイルは、Mozilla の推奨設定 に基づいています。

コンポーネントごとに、以下の TLS セキュリティープロファイルのいずれかを指定できます。

表2.1 TLS セキュリティープロファイル

プロファイル説明

Old

このプロファイルは、レガシークライアントまたはライブラリーでの使用を目的としています。このプロファイルは、Old 後方互換性 の推奨設定に基づいています。

Old プロファイルには、最小 TLS バージョン 1.0 が必要です。

注記

Ingress Controller の場合、TLS の最小バージョンは 1.0 から 1.1 に変換されます。

Intermediate

このプロファイルは、大多数のクライアントに推奨される設定です。これは、Ingress Controller 、kubelet、およびコントロールプレーンのデフォルトの TLS セキュリティープロファイルです。このプロファイルは、Intermediate 互換性 の推奨設定に基づいています。

Intermediate プロファイルには、最小 TLS バージョン 1.2 が必要です。

Modern

このプロファイルは、後方互換性を必要としない Modern のクライアントでの使用を目的としています。このプロファイルは、Modern 互換性 の推奨設定に基づいています。

Modern プロファイルには、最小 TLS バージョン 1.3 が必要です。

カスタム

このプロファイルを使用すると、使用する TLS バージョンと暗号を定義できます。

警告

無効な設定により問題が発生する可能性があるため、Custom プロファイルを使用する際には注意してください。

注記

事前定義されたプロファイルタイプのいずれかを使用する場合、有効なプロファイル設定はリリース間で変更される可能性があります。たとえば、リリース X.Y.Z にデプロイされた Intermediate プロファイルを使用する仕様がある場合、リリース X.Y.Z+1 へのアップグレードにより、新規のプロファイル設定が適用され、ロールアウトが生じる可能性があります。

2.3.1.2. Ingress Controller の TLS セキュリティープロファイルの設定

Ingress Controller の TLS セキュリティープロファイルを設定するには、IngressController カスタムリソース (CR) を編集して、事前定義済みまたはカスタムの TLS セキュリティープロファイルを指定します。TLS セキュリティープロファイルが設定されていない場合、デフォルト値は API サーバーに設定された TLS セキュリティープロファイルに基づいています。

Old TLS のセキュリティープロファイルを設定するサンプル IngressController CR

apiVersion: operator.openshift.io/v1
kind: IngressController
 ...
spec:
  tlsSecurityProfile:
    old: {}
    type: Old
 ...

TLS セキュリティープロファイルは、Ingress Controller の TLS 接続の最小 TLS バージョンと TLS 暗号を定義します。

設定された TLS セキュリティープロファイルの暗号と最小 TLS バージョンは、Status.Tls Profile 配下の IngressController カスタムリソース (CR) と Spec.Tls Security Profile 配下の設定された TLS セキュリティープロファイルで確認できます。Custom TLS セキュリティープロファイルの場合、特定の暗号と最小 TLS バージョンは両方のパラメーターの下に一覧表示されます。

注記

HAProxy Ingress Controller イメージは、TLS1.3 と Modern プロファイルをサポートしています。

また、Ingress Operator は TLS 1.0 の Old または Custom プロファイルを 1.1 に変換します。

前提条件

  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。

手順

  1. openshift-ingress-operator プロジェクトの IngressController CR を編集して、TLS セキュリティープロファイルを設定します。 

    $ oc edit IngressController default -n openshift-ingress-operator

  2. spec.tlsSecurityProfile フィールドを追加します。

    Custom プロファイルのサンプル IngressController CR

    apiVersion: operator.openshift.io/v1
kind: IngressController
 ...
spec:
  tlsSecurityProfile:
    type: Custom 1
    custom: 2
      ciphers: 3
      - ECDHE-ECDSA-CHACHA20-POLY1305
      - ECDHE-RSA-CHACHA20-POLY1305
      - ECDHE-RSA-AES128-GCM-SHA256
      - ECDHE-ECDSA-AES128-GCM-SHA256
      minTLSVersion: VersionTLS11
 ...

    1
    TLS セキュリティープロファイルタイプ (Old、Intermediate、または Custom) を指定します。デフォルトは Intermediate です。
    2
    選択したタイプに適切なフィールドを指定します。
    • old: {}
    • intermediate: {}
    • custom:
    3
    custom タイプには、TLS 暗号のリストと最小許容 TLS バージョンを指定します。
  3. 変更を適用するためにファイルを保存します。

検証

  • IngressController CR にプロファイルが設定されていることを確認します。 

    $ oc describe IngressController default -n openshift-ingress-operator

    出力例

    Name:         default
Namespace:    openshift-ingress-operator
Labels:       <none>
Annotations:  <none>
API Version:  operator.openshift.io/v1
Kind:         IngressController
 ...
Spec:
 ...
  Tls Security Profile:
    Custom:
      Ciphers:
        ECDHE-ECDSA-CHACHA20-POLY1305
        ECDHE-RSA-CHACHA20-POLY1305
        ECDHE-RSA-AES128-GCM-SHA256
        ECDHE-ECDSA-AES128-GCM-SHA256
      Min TLS Version:  VersionTLS11
    Type:               Custom
 ...

2.3.1.3. 相互 TLS 認証の設定

spec.clientTLS 値を設定して、相互 TLS (mTLS) 認証を有効にするように Ingress Controller を設定できます。clientTLS 値は、クライアント証明書を検証するように Ingress Controller を設定します。この設定には、ConfigMap の参照である clientCA 値の設定が含まれます。ConfigMap には、クライアントの証明書を検証するために使用される PEM でエンコードされた CA 証明書バンドルが含まれます。必要に応じて、証明書サブジェクトフィルターのリストも設定できます。

clientCA 値が X509v3 証明書失効リスト (CRL) ディストリビューションポイントを指定している場合、Ingress Operator は、提供された各証明書で指定されている HTTP URI X509v3 CRL Distribution Point に基づいて CRL config map をダウンロードおよび管理します。Ingress Controller は、mTLS/TLS ネゴシエーション中にこの config map を使用します。有効な証明書を提供しない要求は拒否されます。

前提条件

  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
  • PEM でエンコードされた CA 証明書バンドルがある。

  • CA バンドルが CRL ディストリビューションポイントを参照する場合は、エンドエンティティーまたはリーフ証明書もクライアント CA バンドルに含める必要があります。この証明書には、RFC 5280 で説明されているとおり、この証明書の CRL Distribution Points に HTTP URI が含まれている必要があります。以下に例を示します。 

     Issuer: C=US, O=Example Inc, CN=Example Global G2 TLS RSA SHA256 2020 CA1
         Subject: SOME SIGNED CERT            X509v3 CRL Distribution Points:
                Full Name:
                  URI:http://crl.example.com/example.crl

手順

  1. openshift-config namespace で、CA バンドルから config map を作成します。 

    $ oc create configmap \
   router-ca-certs-default \
   --from-file=ca-bundle.pem=client-ca.crt \1
   -n openshift-config
    1
    ConfigMap データキーは ca-bundle.pem で、data の値は PEM 形式の CA 証明書である必要があります。

  2. openshift-ingress-operator プロジェクトで IngressController リソースを編集します。 

    $ oc edit IngressController default -n openshift-ingress-operator

  3. spec.clientTLS フィールドおよびサブフィールドを追加して相互 TLS を設定します。

    フィルタリングパターンを指定する clientTLS プロファイルのサンプル IngressController CR

      apiVersion: operator.openshift.io/v1
  kind: IngressController
  metadata:
    name: default
    namespace: openshift-ingress-operator
  spec:
    clientTLS:
      clientCertificatePolicy: Required
      clientCA:
        name: router-ca-certs-default
      allowedSubjectPatterns:
      - "^/CN=example.com/ST=NC/C=US/O=Security/OU=OpenShift$"

2.4. デフォルト Ingress Controller の表示

Ingress Operator は Red Hat OpenShift Service on AWS のコア機能であり、すぐに有効にできます。

Red Hat OpenShift Service on AWS の新しいインストールにはすべて、default という名前の ingresscontroller があります。これは、追加の Ingress Controller で補足できます。デフォルトの ingresscontroller が削除される場合、Ingress Operator は 1 分以内にこれを自動的に再作成します。

手順

  • デフォルト Ingress Controller を表示します。 

    $ oc describe --namespace=openshift-ingress-operator ingresscontroller/default

2.5. Ingress Operator ステータスの表示

Ingress Operator のステータスを表示し、検査することができます。

手順

  • Ingress Operator ステータスを表示します。 

    $ oc describe clusteroperators/ingress

2.6. Ingress Controller ログの表示

Ingress Controller ログを表示できます。

手順

  • Ingress Controller ログを表示します。 

    $ oc logs --namespace=openshift-ingress-operator deployments/ingress-operator -c <container_name>

2.7. Ingress Controller ステータスの表示

特定の Ingress Controller のステータスを表示できます。

手順

  • Ingress Controller のステータスを表示します。 

    $ oc describe --namespace=openshift-ingress-operator ingresscontroller/<name>

2.8. Ingress Controller の設定

2.8.1. カスタムデフォルト証明書の設定

管理者として、 Secret リソースを作成し、IngressController カスタムリソース (CR) を編集して Ingress Controller がカスタム証明書を使用するように設定できます。

前提条件

  • PEM エンコードされたファイルに証明書/キーのペアがなければなりません。ここで、証明書は信頼される認証局またはカスタム PKI で設定されたプライベートの信頼される認証局で署名されます。

  • 証明書が以下の要件を満たしている必要があります。

    • 証明書が Ingress ドメインに対して有効化されている必要があります。
    • 証明書は拡張を使用して、subjectAltName 拡張を使用して、*.apps.ocp4.example.com などのワイルドカードドメインを指定します。

  • IngressController CR がなければなりません。デフォルトの CR を使用できます。 

    $ oc --namespace openshift-ingress-operator get ingresscontrollers

    出力例

    NAME      AGE
default   10m

注記

Intermediate 証明書がある場合、それらはカスタムデフォルト証明書が含まれるシークレットの tls.crt ファイルに組み込まれる必要があります。証明書を指定する際の順序は重要になります。サーバー証明書の後に Intermediate 証明書をリスト表示します。

手順

以下では、カスタム証明書とキーのペアが、現在の作業ディレクトリーの tls.crt および tls.key ファイルにあることを前提とします。tls.crt および tls.key を実際のパス名に置き換えます。さらに、 Secret リソースを作成し、これを IngressController CR で参照する際に、custom-certs-default を別の名前に置き換えます。

注記

このアクションにより、Ingress Controller はデプロイメントストラテジーを使用して再デプロイされます。

  1. tls.crt および tls.key ファイルを使用して、カスタム証明書を含む Secret リソースを openshift-ingress namespace に作成します。 

    $ oc --namespace openshift-ingress create secret tls custom-certs-default --cert=tls.crt --key=tls.key

  2. IngressController CR を、新規証明書シークレットを参照するように更新します。 

    $ oc patch --type=merge --namespace openshift-ingress-operator ingresscontrollers/default \
  --patch '{"spec":{"defaultCertificate":{"name":"custom-certs-default"}}}'

  3. 更新が正常に行われていることを確認します。 

    $ echo Q |\
  openssl s_client -connect console-openshift-console.apps.<domain>:443 -showcerts 2>/dev/null |\
  openssl x509 -noout -subject -issuer -enddate

    ここでは、以下のようになります。

    <domain>
    クラスターのベースドメイン名を指定します。

    出力例

    subject=C = US, ST = NC, L = Raleigh, O = RH, OU = OCP4, CN = *.apps.example.com
issuer=C = US, ST = NC, L = Raleigh, O = RH, OU = OCP4, CN = example.com
notAfter=May 10 08:32:45 2022 GM

    ヒント

    または、以下の YAML を適用してカスタムのデフォルト証明書を設定できます。 

    apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name: default
  namespace: openshift-ingress-operator
spec:
  defaultCertificate:
    name: custom-certs-default

    証明書シークレットの名前は、CR を更新するために使用された値に一致する必要があります。

IngressController CR が変更された後に、Ingress Operator はカスタム証明書を使用できるように Ingress Controller のデプロイメントを更新します。

2.8.2. カスタムデフォルト証明書の削除

管理者は、使用する Ingress Controller を設定したカスタム証明書を削除できます。

前提条件

  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
  • OpenShift CLI (oc) がインストールされている。
  • Ingress Controller のカスタムデフォルト証明書を設定している。

手順

  • カスタム証明書を削除し、Red Hat OpenShift Service on AWS に付属の証明書を復元するには、次のコマンドを入力します。 

    $ oc patch -n openshift-ingress-operator ingresscontrollers/default \
  --type json -p $'- op: remove\n  path: /spec/defaultCertificate'

    クラスターが新しい証明書設定を調整している間、遅延が発生する可能性があります。

検証

  • 元のクラスター証明書が復元されたことを確認するには、次のコマンドを入力します。 

    $ echo Q | \
  openssl s_client -connect console-openshift-console.apps.<domain>:443 -showcerts 2>/dev/null | \
  openssl x509 -noout -subject -issuer -enddate

    ここでは、以下のようになります。

    <domain>
    クラスターのベースドメイン名を指定します。

    出力例

    subject=CN = *.apps.<domain>
issuer=CN = ingress-operator@1620633373
notAfter=May 10 10:44:36 2023 GMT

2.8.3. Ingress Controller の自動スケーリング

Ingress Controller は、スループットを増大させるための要件を含む、ルーティングのパフォーマンスや可用性に関する各種要件に動的に対応するために自動でスケーリングできます。以下の手順では、デフォルトの IngressController をスケールアップする例を示します。

前提条件

  1. OpenShift CLI (oc) がインストールされている。
  2. cluster-admin ロールを持つユーザーとして Red Hat OpenShift Service on AWS クラスターにアクセスできる。
  3. Custom Metrics Autoscaler Operator がインストールされている。
  4. openshift-ingress-operator プロジェクトの namespace に切り替えている。

手順

  1. 以下のコマンドを実行して、Thanos で認証するためのサービスアカウントを作成します。 

    $ oc create serviceaccount thanos && oc describe serviceaccount thanos

    出力例

    Name:                thanos
Namespace:           openshift-ingress-operator
Labels:              <none>
Annotations:         <none>
Image pull secrets:  thanos-dockercfg-b4l9s
Mountable secrets:   thanos-dockercfg-b4l9s
Tokens:              thanos-token-c422q
Events:              <none>

  2. サービスアカウントのトークンを使用して、openshift-ingress-operator namespace 内で TriggerAuthentication オブジェクトを定義します。

    1. 以下のコマンドを実行して、シークレットを含む変数 secret を定義します。 

      $ secret=$(oc get secret | grep thanos-token | head -n 1 | awk '{ print $1 }')

    2. TriggerAuthentication オブジェクトを作成し、secret 変数の値を TOKEN パラメーターに渡します。 

      $ oc process TOKEN="$secret" -f - <<EOF | oc apply -f -
apiVersion: template.openshift.io/v1
kind: Template
parameters:
- name: TOKEN
objects:
- apiVersion: keda.sh/v1alpha1
  kind: TriggerAuthentication
  metadata:
    name: keda-trigger-auth-prometheus
  spec:
    secretTargetRef:
    - parameter: bearerToken
      name: \${TOKEN}
      key: token
    - parameter: ca
      name: \${TOKEN}
      key: ca.crt
EOF

  3. Thanos からメトリクスを読み取るためのロールを作成して適用します。

    1. Pod およびノードからメトリクスを読み取る新規ロール thanos-metrics-reader.yaml を作成します。

      thanos-metrics-reader.yaml

      apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: thanos-metrics-reader
rules:
- apiGroups:
  - ""
  resources:
  - pods
  - nodes
  verbs:
  - get
- apiGroups:
  - metrics.k8s.io
  resources:
  - pods
  - nodes
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - ""
  resources:
  - namespaces
  verbs:
  - get

    2. 以下のコマンドを実行して新規ロールを適用します。 

      $ oc apply -f thanos-metrics-reader.yaml

  4. 以下のコマンドを入力して、新しいロールをサービスアカウントに追加します。 

    $ oc adm policy add-role-to-user thanos-metrics-reader -z thanos --role-namespace=openshift-ingress-operator
    $ oc adm policy -n openshift-ingress-operator add-cluster-role-to-user cluster-monitoring-view -z thanos
    注記

    引数 add-cluster-role-to-user は、namespace 間のクエリーを使用する場合にのみ必要になります。以下の手順では、この引数を必要とする kube-metrics namespace からのクエリーを使用します。

  5. デフォルトの Ingress Controller デプロイメントをターゲットにする新しい ScaledObject YAML ファイル ingress-autoscaler.yaml を作成します。

    ScaledObject 定義の例

    apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: ingress-scaler
spec:
  scaleTargetRef: 1
    apiVersion: operator.openshift.io/v1
    kind: IngressController
    name: default
    envSourceContainerName: ingress-operator
  minReplicaCount: 1
  maxReplicaCount: 20 2
  cooldownPeriod: 1
  pollingInterval: 1
  triggers:
  - type: prometheus
    metricType: AverageValue
    metadata:
      serverAddress: https://thanos-querier.openshift-monitoring.svc.cluster.local:9091 3
      namespace: openshift-ingress-operator 4
      metricName: 'kube-node-role'
      threshold: '1'
      query: 'sum(kube_node_role{role="worker",service="kube-state-metrics"})' 5
      authModes: "bearer"
    authenticationRef:
      name: keda-trigger-auth-prometheus

    1
    対象とするカスタムリソース。この場合、Ingress Controller。
    2
    オプション: レプリカの最大数。このフィールドを省略すると、デフォルトの最大値は 100 レプリカに設定されます。
    3
    openshift-monitoring namespace の Thanos サービスエンドポイント。
    4
    Ingress Operator namespace。
    5
    この式は、デプロイされたクラスターに存在するワーカーノードの数に対して評価されます。
    重要

    namespace 間クエリーを使用している場合は、serverAddress フィールドのポート 9092 ではなくポート 9091 をターゲットにする必要があります。また、このポートからメトリクスを読み取るには、昇格した権限が必要です。

  6. 以下のコマンドを実行してカスタムリソース定義を適用します。 

    $ oc apply -f ingress-autoscaler.yaml

検証

  • 以下のコマンドを実行して、デフォルトの Ingress Controller が kube-state-metrics クエリーによって返される値に一致するようにスケールアウトされていることを確認します。

    • grep コマンドを使用して、Ingress Controller の YAML ファイルでレプリカを検索します。 

      $ oc get ingresscontroller/default -o yaml | grep replicas:

      出力例

      replicas: 3

    • openshift-ingress プロジェクトで Pod を取得します。 

      $ oc get pods -n openshift-ingress

      出力例

      NAME                             READY   STATUS    RESTARTS   AGE
router-default-7b5df44ff-l9pmm   2/2     Running   0          17h
router-default-7b5df44ff-s5sl5   2/2     Running   0          3d22h
router-default-7b5df44ff-wwsth   2/2     Running   0          66s

2.8.4. Ingress Controller のスケーリング

Ingress Controller は、スループットを増大させるための要件を含む、ルーティングのパフォーマンスや可用性に関する各種要件に対応するために手動でスケーリングできます。oc コマンドは、IngressController リソースのスケーリングに使用されます。以下の手順では、デフォルトの IngressController をスケールアップする例を示します。

注記

スケーリングは、必要な数のレプリカを作成するのに時間がかかるため、すぐに実行できるアクションではありません。

手順

  1. デフォルト IngressController の現在の利用可能なレプリカ数を表示します。 

    $ oc get -n openshift-ingress-operator ingresscontrollers/default -o jsonpath='{$.status.availableReplicas}'

    出力例

    2

  2. oc patch コマンドを使用して、デフォルトの IngressController を必要なレプリカ数にスケーリングします。以下の例では、デフォルトの IngressController を 3 つのレプリカにスケーリングしています。 

    $ oc patch -n openshift-ingress-operator ingresscontroller/default --patch '{"spec":{"replicas": 3}}' --type=merge

    出力例

    ingresscontroller.operator.openshift.io/default patched

  3. デフォルトの IngressController が指定したレプリカ数にスケーリングされていることを確認します。 

    $ oc get -n openshift-ingress-operator ingresscontrollers/default -o jsonpath='{$.status.availableReplicas}'

    出力例

    3

    ヒント

    または、以下の YAML を適用して Ingress Controller を 3 つのレプリカにスケーリングすることもできます。 

    apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name: default
  namespace: openshift-ingress-operator
spec:
  replicas: 3               1
    1
    異なる数のレプリカが必要な場合は replicas 値を変更します。

2.8.5. Ingress アクセスロギングの設定

アクセスログを有効にするように Ingress Controller を設定できます。大量のトラフィックを受信しないクラスターがある場合、サイドカーにログインできます。クラスターのトラフィックが多い場合は、ロギングスタックの容量の超過を避けるために、または Red Hat OpenShift Service on AWS の外部のロギングインフラストラクチャーと統合するために、ログをカスタム syslog エンドポイントに転送できます。アクセスログの形式を指定することもできます。

コンテナーロギングは、既存の Syslog ロギングインフラストラクチャーがない場合や、Ingress Controller で問題を診断する際に短期間使用する場合に、低トラフィックのクラスターのアクセスログを有効にするのに役立ちます。

アクセスログが OpenShift Logging スタックの容量を超える可能性があるトラフィックの多いクラスターや、ロギングソリューションが既存の Syslog ロギングインフラストラクチャーと統合する必要のある環境では、syslog が必要です。Syslog のユースケースは重複する可能性があります。

前提条件

  • cluster-admin 権限を持つユーザーとしてログインしている。

手順

サイドカーへの Ingress アクセスロギングを設定します。

  • Ingress アクセスロギングを設定するには、spec.logging.access.destination を使用して宛先を指定する必要があります。サイドカーコンテナーへのロギングを指定するには、Container spec.logging.access.destination.type を指定する必要があります。以下の例は、コンテナー Container の宛先に対してログ記録する Ingress Controller 定義です。 

    apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name: default
  namespace: openshift-ingress-operator
spec:
  replicas: 2
  logging:
    access:
      destination:
        type: Container

  • Ingress Controller をサイドカーに対してログを記録するように設定すると、Operator は Ingress Controller Pod 内に logs という名前のコンテナーを作成します。 

    $ oc -n openshift-ingress logs deployment.apps/router-default -c logs

    出力例

    2020-05-11T19:11:50.135710+00:00 router-default-57dfc6cd95-bpmk6 router-default-57dfc6cd95-bpmk6 haproxy[108]: 174.19.21.82:39654 [11/May/2020:19:11:50.133] public be_http:hello-openshift:hello-openshift/pod:hello-openshift:hello-openshift:10.128.2.12:8080 0/0/1/0/1 200 142 - - --NI 1/1/0/0/0 0/0 "GET / HTTP/1.1"

Syslog エンドポイントへの Ingress アクセスロギングを設定します。

  • Ingress アクセスロギングを設定するには、spec.logging.access.destination を使用して宛先を指定する必要があります。Syslog エンドポイント宛先へのロギングを指定するには、spec.logging.access.destination.type に Syslog を指定する必要があります。宛先タイプが Syslog の場合、spec.logging.access.destination.syslog.endpoint を使用して宛先エンドポイントも指定する必要があります。また、spec.logging.access.destination.syslog.facility を使用してファシリティーを指定できます。以下の例は、Syslog 宛先に対してログを記録する Ingress Controller の定義です。 

    apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name: default
  namespace: openshift-ingress-operator
spec:
  replicas: 2
  logging:
    access:
      destination:
        type: Syslog
        syslog:
          address: 1.2.3.4
          port: 10514
    注記

    syslog 宛先ポートは UDP である必要があります。

特定のログ形式で Ingress アクセスロギングを設定します。

  • spec.logging.access.httpLogFormat を指定して、ログ形式をカスタマイズできます。以下の例は、IP アドレスが 1.2.3.4 およびポート 10514 の syslog エンドポイントに対してログを記録する Ingress Controller の定義です。 

    apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name: default
  namespace: openshift-ingress-operator
spec:
  replicas: 2
  logging:
    access:
      destination:
        type: Syslog
        syslog:
          address: 1.2.3.4
          port: 10514
      httpLogFormat: '%ci:%cp [%t] %ft %b/%s %B %bq %HM %HU %HV'

Ingress アクセスロギングを無効にします。

  • Ingress アクセスロギングを無効にするには、spec.logging または spec.logging.access を空のままにします。 

    apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name: default
  namespace: openshift-ingress-operator
spec:
  replicas: 2
  logging:
    access: null

サイドカーの使用時に Ingress Controller が HAProxy ログの長さを変更できるようにします。

  • spec.logging.access.destination.type: Syslog を使用している場合は、spec.logging.access.destination.syslog.maxLength を使用します。 

    apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name: default
  namespace: openshift-ingress-operator
spec:
  replicas: 2
  logging:
    access:
      destination:
        type: Syslog
        syslog:
          address: 1.2.3.4
          maxLength: 4096
          port: 10514

  • spec.logging.access.destination.type: Container を使用している場合は、spec.logging.access.destination.container.maxLength を使用します。 

    apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name: default
  namespace: openshift-ingress-operator
spec:
  replicas: 2
  logging:
    access:
      destination:
        type: Container
        container:
          maxLength: 8192

2.8.6. Ingress Controller スレッド数の設定

クラスター管理者は、スレッド数を設定して、クラスターが処理できる受信接続の量を増やすことができます。既存の Ingress Controller にパッチを適用して、スレッドの数を増やすことができます。

前提条件

  • 以下では、Ingress Controller がすでに作成されていることを前提とします。

手順

  • Ingress Controller を更新して、スレッド数を増やします。 

    $ oc -n openshift-ingress-operator patch ingresscontroller/default --type=merge -p '{"spec":{"tuningOptions": {"threadCount": 8}}}'
    注記

    大量のリソースを実行できるノードがある場合、spec.nodePlacement.nodeSelector を、意図されているノードの容量に一致するラベルで設定し、spec.tuningOptions.threadCount を随時高い値に設定します。

2.8.7. 内部ロードバランサーを使用するための Ingress Controller の設定

クラウドプラットフォームで Ingress Controller を作成する場合、Ingress Controller はデフォルトでパブリッククラウドロードバランサーによって公開されます。管理者は、内部クラウドロードバランサーを使用する Ingress Controller を作成できます。

重要

IngressControllerのscopeを変更する場合は、カスタムリソース (CR) の作成後に.spec.endpoint Publishing Strategy.load Balancer.scopeパラメーターを変更できます。

図2.1 ロードバランサーの図

Red Hat OpenShift Service on AWS Ingress LoadBalancerService endpoint publishing strategy

上の図は、Red Hat OpenShift Service on AWS の Ingress LoadBalancerService エンドポイント公開ストラテジーに関する次の概念を示しています。

  • 負荷は、外部からクラウドプロバイダーのロードバランサーを使用するか、内部から OpenShift Ingress Controller Load Balancer を使用して、分散できます。
  • ロードバランサーのシングル IP アドレスと、図にあるクラスターのように、8080 や 4200 といった馴染みのあるポートを使用することができます。
  • 外部のロードバランサーからのトラフィックは、ダウンしたノードのインスタンスで記載されているように、Pod の方向に進められ、ロードバランサーが管理します。実装の詳細については、Kubernetes サービスドキュメント を参照してください。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてログインしている。

手順

  1. 以下の例のように、<name>-ingress-controller.yaml という名前のファイルに IngressController カスタムリソース (CR) を作成します。 

    apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  namespace: openshift-ingress-operator
  name: <name> 1
spec:
  domain: <domain> 2
  endpointPublishingStrategy:
    type: LoadBalancerService
    loadBalancer:
      scope: Internal 3
    1
    <name> を IngressController オブジェクトの名前に置き換えます。
    2
    コントローラーによって公開されるアプリケーションの ドメイン を指定します。
    3
    内部ロードバランサーを使用するために Internal の値を指定します。

  2. 以下のコマンドを実行して、直前の手順で定義された Ingress Controller を作成します。 

    $ oc create -f <name>-ingress-controller.yaml 1
    1
    <name> を IngressController オブジェクトの名前に置き換えます。

  3. オプション: 以下のコマンドを実行して Ingress Controller が作成されていることを確認します。 

    $ oc --all-namespaces=true get ingresscontrollers

2.8.8. Ingress Controller のヘルスチェック間隔の設定

クラスター管理者は、ヘルスチェックの間隔を設定して、ルーターが連続する 2 回のヘルスチェックの間で待機する時間を定義できます。この値は、すべてのルートのデフォルトとしてグローバルに適用されます。デフォルト値は 5 秒です。

前提条件

  • 以下では、Ingress Controller がすでに作成されていることを前提とします。

手順

  • Ingress Controller を更新して、バックエンドヘルスチェックの間隔を変更します。 

    $ oc -n openshift-ingress-operator patch ingresscontroller/default --type=merge -p '{"spec":{"tuningOptions": {"healthCheckInterval": "8s"}}}'
    注記

    単一ルートの healthCheckInterval をオーバーライドするには、ルートアノテーション router.openshift.io/haproxy.health.check.interval を使用します

2.8.9. クラスターを内部に配置するためのデフォルト Ingress Controller の設定

削除や再作成を実行して、クラスターを内部に配置するように default Ingress Controller を設定できます。

重要

IngressControllerのscopeを変更する場合は、カスタムリソース (CR) の作成後に.spec.endpoint Publishing Strategy.load Balancer.scopeパラメーターを変更できます。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてログインしている。

手順

  1. 削除や再作成を実行して、クラスターを内部に配置するように default Ingress Controller を設定します。 

    $ oc replace --force --wait --filename - <<EOF
apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  namespace: openshift-ingress-operator
  name: default
spec:
  endpointPublishingStrategy:
    type: LoadBalancerService
    loadBalancer:
      scope: Internal
EOF

2.8.10. ルートの受付ポリシーの設定

管理者およびアプリケーション開発者は、同じドメイン名を持つ複数の namespace でアプリケーションを実行できます。これは、複数のチームが同じホスト名で公開されるマイクロサービスを開発する組織を対象としています。

警告

複数の namespace での要求の許可は、namespace 間の信頼のあるクラスターに対してのみ有効にする必要があります。有効にしないと、悪意のあるユーザーがホスト名を乗っ取る可能性があります。このため、デフォルトの受付ポリシーは複数の namespace 間でのホスト名の要求を許可しません。

前提条件

  • クラスター管理者の権限。

手順

  • 以下のコマンドを使用して、ingresscontroller リソース変数の .spec.routeAdmission フィールドを編集します。 

    $ oc -n openshift-ingress-operator patch ingresscontroller/default --patch '{"spec":{"routeAdmission":{"namespaceOwnership":"InterNamespaceAllowed"}}}' --type=merge

    イメージコントローラー設定例

    spec:
  routeAdmission:
    namespaceOwnership: InterNamespaceAllowed
...

    ヒント

    または、以下の YAML を適用してルートの受付ポリシーを設定できます。 

    apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name: default
  namespace: openshift-ingress-operator
spec:
  routeAdmission:
    namespaceOwnership: InterNamespaceAllowed

2.8.11. ワイルドカードルートの使用

HAProxy Ingress Controller にはワイルドカードルートのサポートがあります。Ingress Operator は wildcardPolicy を使用して、Ingress Controller の ROUTER_ALLOW_WILDCARD_ROUTES 環境変数を設定します。

Ingress Controller のデフォルトの動作では、ワイルドカードポリシーの None (既存の IngressController リソースとの後方互換性がある) を持つルートを許可します。

手順

  1. ワイルドカードポリシーを設定します。

    1. 以下のコマンドを使用して IngressController リソースを編集します。 

      $ oc edit IngressController

    2. spec の下で、wildcardPolicy フィールドを WildcardsDisallowed または WildcardsAllowed に設定します。 

      spec:
  routeAdmission:
    wildcardPolicy: WildcardsDisallowed # or WildcardsAllowed

2.8.12. HTTP ヘッダーの設定

Red Hat OpenShift Service on AWS は、HTTP ヘッダーを操作するさまざまな方法を提供します。ヘッダーを設定または削除する場合、Ingress Controller の特定のフィールドまたは個々のルートを使用して、リクエストヘッダーと応答ヘッダーを変更できます。ルートアノテーションを使用して特定のヘッダーを設定することもできます。ヘッダーを設定するさまざまな方法は、連携時に課題となる可能性があります。

注記

IngressController または Route CR 内のヘッダーは設定または削除のみ可能で、追加はできません。HTTP ヘッダーに値が設定されている場合、その値は完全である必要があるため、今後追加する必要はありません。X-Forwarded-For ヘッダーなどのヘッダーを追加することが適切な状況では、spec.httpHeaders.actions の代わりに spec.httpHeaders.forwardedHeaderPolicy フィールドを使用します。

2.8.12.1. 優先順位

同じ HTTP ヘッダーを Ingress Controller とルートの両方で変更すると、HAProxy は、それがリクエストヘッダーであるか応答ヘッダーであるかに応じて、特定の方法でアクションの優先順位を付けます。

  • HTTP 応答ヘッダーの場合、Ingress Controller で指定されたアクションは、ルートで指定されたアクションの後に実行されます。これは、Ingress Controller で指定されたアクションが優先されることを意味します。
  • HTTP リクエストヘッダーの場合、ルートで指定されたアクションは、Ingress Controller で指定されたアクションの後に実行されます。これは、ルートで指定されたアクションが優先されることを意味します。

たとえば、クラスター管理者は、次の設定を使用して、Ingress Controller で X-Frame-Options 応答ヘッダーに値 DENY を設定します。

IngressController 仕様の例

apiVersion: operator.openshift.io/v1
kind: IngressController
# ...
spec:
  httpHeaders:
    actions:
      response:
      - name: X-Frame-Options
        action:
          type: Set
          set:
            value: DENY

ルート所有者は、クラスター管理者が Ingress Controller に設定したものと同じ応答ヘッダーを設定しますが、次の設定を使用して値 SAMEORIGIN を設定します。

Route 仕様の例

apiVersion: route.openshift.io/v1
kind: Route
# ...
spec:
  httpHeaders:
    actions:
      response:
      - name: X-Frame-Options
        action:
          type: Set
          set:
            value: SAMEORIGIN

IngressController 仕様と Route 仕様の両方で X-Frame-Options ヘッダーを設定している場合、特定のルートでフレームが許可されている場合でも、Ingress Controller のグローバルレベルでこのヘッダーに設定された値が優先されます。

この優先順位付けは、haproxy.config ファイルが次のロジックを使用するために発生します。このロジックでは、Ingress Controller がフロントエンドとみなされ、個々のルートがバックエンドとみなされます。フロントエンド設定に適用されるヘッダー値 DENY は、バックエンドで設定されている値 SAMEORIGIN で同じヘッダーをオーバーライドします。 

frontend public
  http-response set-header X-Frame-Options 'DENY'

frontend fe_sni
  http-response set-header X-Frame-Options 'DENY'

frontend fe_no_sni
  http-response set-header X-Frame-Options 'DENY'

backend be_secure:openshift-monitoring:alertmanager-main
  http-response set-header X-Frame-Options 'SAMEORIGIN'

さらに、Ingress Controller またはルートのいずれかで定義されたアクションは、ルートアノテーションを使用して設定された値をオーバーライドします。

2.8.12.2. 特殊なケースのヘッダー

次のヘッダーは、設定または削除が完全に禁止されているか、特定の状況下で許可されています。

表2.2 特殊な場合のヘッダー設定オプション

ヘッダー名IngressController 仕様を使用して設定可能かどうかRoute 仕様を使用して設定可能かどうか不許可の理由別の方法で設定可能かどうか

proxy

いいえ

いいえ

プロキシー HTTP リクエストヘッダーを使用して、ヘッダー値を HTTP_PROXY 環境変数に挿入して、脆弱な CGI アプリケーションを悪用できます。プロキシー HTTP リクエストヘッダーも標準ではないため、設定中にエラーが発生しやすくなります。

いいえ

host

いいえ

はい

IngressController CR を使用して ホスト HTTP 要求ヘッダーが設定されている場合、HAProxy は正しいルートを検索するときに失敗する可能性があります。

いいえ

strict-transport-security

いいえ

いいえ

strict-transport-security HTTP 応答ヘッダーはルートアノテーションを使用してすでに処理されているため、別の実装は必要ありません。

はい: haproxy.router.openshift.io/hsts_header ルートアノテーション

cookie と set-cookie

いいえ

いいえ

HAProxy が設定する Cookie は、クライアント接続を特定のバックエンドサーバーにマップするセッション追跡に使用されます。これらのヘッダーの設定を許可すると、HAProxy のセッションアフィニティーが妨げられ、HAProxy の Cookie の所有権が制限される可能性があります。

はい:

  • haproxy.router.openshift.io/disable_cookie ルートアノテーション
  • haproxy.router.openshift.io/cookie_name ルートアノテーション

2.8.13. Ingress Controller での HTTP リクエストおよびレスポンスヘッダーの設定または削除

コンプライアンス目的またはその他の理由で、特定の HTTP 要求および応答ヘッダーを設定または削除できます。これらのヘッダーは、Ingress Controller によって提供されるすべてのルート、または特定のルートに対して設定または削除できます。

たとえば、相互 TLS を使用するようにクラスター上で実行されているアプリケーションを移行する場合があります。このような場合、お使いのアプリケーションで X-Forwarded-Client-Cert リクエストヘッダーをチェックする必要がありますが、Red Hat OpenShift Service on AWS のデフォルトの Ingress Controller は X-SSL-Client-Der リクエストヘッダーを提供します。

次の手順では、Ingress Controller を変更して X-Forwarded-Client-Cert リクエストヘッダーを設定し、X-SSL-Client-Der リクエストヘッダーを削除します。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin ロールを持つユーザーとして Red Hat OpenShift Service on AWS クラスターにアクセスできる。

手順

  1. Ingress Controller リソースを編集します。 

    $ oc -n openshift-ingress-operator edit ingresscontroller/default

  2. X-SSL-Client-Der HTTP リクエストヘッダーは X-Forwarded-Client-Cert HTTP リクエストヘッダーに置き換えます。 

    apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name: default
  namespace: openshift-ingress-operator
spec:
  httpHeaders:
    actions: 1
      request: 2
      - name: X-Forwarded-Client-Cert 3
        action:
          type: Set 4
          set:
           value: "%{+Q}[ssl_c_der,base64]" 5
      - name: X-SSL-Client-Der
        action:
          type: Delete
    1
    HTTP ヘッダーに対して実行するアクションのリスト。
    2
    変更するヘッダーのタイプ。この場合はリクエストヘッダーです。
    3
    変更するヘッダーの名前。設定または削除できる使用可能なヘッダーのリストについては、HTTP ヘッダーの設定 を参照してください。
    4
    ヘッダーに対して実行されるアクションのタイプ。このフィールドには、Set または Delete の値を指定できます。
    5
    HTTP ヘッダーの設定時は、値 を指定する必要があります。値は、そのヘッダーで使用可能なディレクティブのリストからの文字列 (例: DENY) にすることも、HAProxy の動的値構文を使用して解釈される動的値にすることもできます。この場合、動的な値が追加されます。
    注記

    HTTP 応答の動的ヘッダー値を設定する場合、サンプルフェッチャーとして res.hdr および ssl_c_der を使用できます。HTTP リクエストの動的ヘッダー値を設定する場合、許可されるサンプルフェッチャーは req.hdr および ssl_c_der です。リクエストとレスポンスの両方の動的値で、lower コンバーターと Base64 コンバーターを使用できます。

  3. 変更を適用するためにファイルを保存します。

2.8.14. X-Forwarded ヘッダーの使用

Forwarded および X-Forwarded-For を含む HTTP ヘッダーの処理方法についてのポリシーを指定するように HAProxy Ingress Controller を設定します。Ingress Operator は HTTPHeaders フィールドを使用して、Ingress Controller の ROUTER_SET_FORWARDED_HEADERS 環境変数を設定します。

手順

  1. Ingress Controller 用に HTTPHeaders フィールドを設定します。

    1. 以下のコマンドを使用して IngressController リソースを編集します。 

      $ oc edit IngressController

    2. spec の下で、HTTPHeaders ポリシーフィールドを Append、Replace、IfNone、または Never に設定します。 

      apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name: default
  namespace: openshift-ingress-operator
spec:
  httpHeaders:
    forwardedHeaderPolicy: Append
使用例

クラスター管理者として、以下を実行できます。

  • Ingress Controller に転送する前に、X-Forwarded-For ヘッダーを各リクエストに挿入する外部プロキシーを設定します。

    ヘッダーを変更せずに渡すように Ingress Controller を設定するには、never ポリシーを指定します。これにより、Ingress Controller はヘッダーを設定しなくなり、アプリケーションは外部プロキシーが提供するヘッダーのみを受信します。

  • 外部プロキシーが外部クラスター要求を設定する X-Forwarded-For ヘッダーを変更せずに渡すように Ingress Controller を設定します。

    外部プロキシーを通過しない内部クラスター要求に X-Forwarded-For ヘッダーを設定するように Ingress Controller を設定するには、if-none ポリシーを指定します。外部プロキシー経由で HTTP 要求にヘッダーがすでに設定されている場合、Ingress Controller はこれを保持します。要求がプロキシーを通過していないためにヘッダーがない場合、Ingress Controller はヘッダーを追加します。

アプリケーション開発者として、以下を実行できます。

  • X-Forwarded-For ヘッダーを挿入するアプリケーション固有の外部プロキシーを設定します。

    他の Route のポリシーに影響を与えずに、アプリケーションの Route 用にヘッダーを変更せずに渡すように Ingress Controller を設定するには、アプリケーションの Route に アノテーション haproxy.router.openshift.io/set-forwarded-headers: if-none または haproxy.router.openshift.io/set-forwarded-headers: never を追加します。

    注記

    Ingress Controller のグローバルに設定された値とは別に、haproxy.router.openshift.io/set-forwarded-headers アノテーションをルートごとに設定できます。

2.8.15. HTTP/2 Ingress 接続の有効化

HAProxy で透過的なエンドツーエンド HTTP/2 接続を有効にすることができます。これにより、アプリケーションの所有者は、単一接続、ヘッダー圧縮、バイナリーストリームなど、HTTP/2 プロトコル機能を使用できます。

個別の Ingress Controller またはクラスター全体について、HTTP/2 接続を有効にすることができます。

クライアントから HAProxy への接続について HTTP/2 の使用を有効にするために、ルートはカスタム証明書を指定する必要があります。デフォルトの証明書を使用するルートは HTTP/2 を使用することができません。この制限は、クライアントが同じ証明書を使用する複数の異なるルートに接続を再使用するなどの、接続の結合 (coalescing) の問題を回避するために必要です。

HAProxy からアプリケーション Pod への接続は、re-encrypt ルートのみに HTTP/2 を使用でき、edge termination ルートまたは非セキュアなルートには使用しません。この制限は、HAProxy が TLS 拡張である Application-Level Protocol Negotiation (ALPN) を使用してバックエンドで HTTP/2 の使用をネゴシエートするためにあります。そのため、エンドツーエンドの HTTP/2 はパススルーおよび re-encrypt 使用できますが、非セキュアなルートまたは edge termination ルートでは使用できません。

重要

パススルー以外のルートの場合、Ingress コントローラーはクライアントからの接続とは独立してアプリケーションへの接続をネゴシエートします。つまり、クライアントが Ingress Controller に接続して HTTP/1.1 をネゴシエートし、Ingress Controller は次にアプリケーションに接続して HTTP/2 をネゴシエートし、アプリケーションへの HTTP/2 接続を使用してクライアント HTTP/1.1 接続からの要求の転送を実行できます。Ingress Controller は WebSocket を HTTP/2 に転送できず、その HTTP/2 接続を WebSocket に対してアップグレードできないため、クライアントが後に HTTP/1.1 から WebSocket プロトコルに接続をアップグレードしようとすると問題が発生します。そのため、WebSocket 接続を受け入れることが意図されたアプリケーションがある場合、これは HTTP/2 プロトコルのネゴシエートを許可できないようにする必要があります。そうしないと、クライアントは WebSocket プロトコルへのアップグレードに失敗します。

手順

単一 Ingress Controller で HTTP/2 を有効にします。

  • Ingress Controller で HTTP/2 を有効にするには、oc annotate コマンドを入力します。 

    $ oc -n openshift-ingress-operator annotate ingresscontrollers/<ingresscontroller_name> ingress.operator.openshift.io/default-enable-http2=true

    <ingresscontroller_name> をアノテーションを付ける Ingress Controller の名前に置き換えます。

クラスター全体で HTTP/2 を有効にします。

  • クラスター全体で HTTP/2 を有効にするには、oc annotate コマンドを入力します。 

    $ oc annotate ingresses.config/cluster ingress.operator.openshift.io/default-enable-http2=true
    ヒント

    または、以下の YAML を適用してアノテーションを追加できます。 

    apiVersion: config.openshift.io/v1
kind: Ingress
metadata:
  name: cluster
  annotations:
    ingress.operator.openshift.io/default-enable-http2: "true"

2.8.16. Ingress Controller の PROXY プロトコルの設定

クラスター管理者は、Ingress Controller が HostNetwork または NodePortService エンドポイントの公開ストラテジータイプのいずれかを使用する際に PROXY プロトコル を設定できます。PROXY プロトコルにより、ロードバランサーは Ingress Controller が受信する接続の元のクライアントアドレスを保持することができます。元のクライアントアドレスは、HTTP ヘッダーのロギング、フィルタリング、および挿入を実行する場合に便利です。デフォルト設定では、Ingress Controller が受信する接続には、ロードバランサーに関連付けられるソースアドレスのみが含まれます。

この機能は、クラウドデプロイメントではサポートされていません。この制限があるのは、Red Hat OpenShift Service on AWS がクラウドプラットフォームで実行され、IngressController がサービスロードバランサーを使用するように指定している場合に、Ingress Operator がロードバランサーサービスを設定し、ソースアドレスを保持するプラットフォーム要件に基づいて PROXY プロトコルを有効にするためです。

重要

PROXY プロトコルまたは TCP を使用するには、Red Hat OpenShift Service on AWS と外部ロードバランサーの両方を設定する必要があります。

警告

PROXY プロトコルは、Keepalived Ingress VIP を使用するクラウド以外のプラットフォーム上のインストーラーによってプロビジョニングされたクラスターを使用するデフォルトの Ingress Controller ではサポートされていません。

前提条件

  • Ingress Controller を作成している。

手順

  1. Ingress Controller リソースを編集します。 

    $ oc -n openshift-ingress-operator edit ingresscontroller/default

  2. PROXY 設定を設定します。

    • Ingress Controller が hostNetwork エンドポイント公開ストラテジータイプを使用する場合は、spec.endpointPublishingStrategy.nodePort.protocol サブフィールドを PROXY に設定します。

      PROXY への hostNetwork の設定例

        spec:
    endpointPublishingStrategy:
      hostNetwork:
        protocol: PROXY
      type: HostNetwork

    • Ingress Controller が NodePortService エンドポイント公開ストラテジータイプを使用する場合は、spec.endpointPublishingStrategy.nodePort.protocol サブフィールドを PROXY に設定します。

      PROXY へのサンプル nodePort 設定

        spec:
    endpointPublishingStrategy:
      nodePort:
        protocol: PROXY
      type: NodePortService

2.8.17. appsDomain オプションを使用した代替クラスタードメインの指定

クラスター管理者は、appsDomain フィールドを設定して、ユーザーが作成したルートのデフォルトのクラスタードメインの代わりとなるものを指定できます。appsDomain フィールドは、domain フィールドで指定されているデフォルトの代わりに使用する Red Hat OpenShift Service on AWS のオプションのドメインです。代替ドメインを指定する場合、これは新規ルートのデフォルトホストを判別できるようにする目的でデフォルトのクラスタードメインを上書きします。

たとえば、所属企業の DNS ドメインを、クラスター上で実行されるアプリケーションのルートおよび ingress のデフォルトドメインとして使用できます。

前提条件

  • Red Hat OpenShift Service on AWS クラスターをデプロイしている。
  • oc コマンドラインインターフェイスをインストールしている。

手順

  1. ユーザーが作成するルートに代替のデフォルトドメインを指定して appsDomain フィールドを設定します。

    1. Ingress cluster リソースを編集します。 

      $ oc edit ingresses.config/cluster -o yaml

    2. YAML ファイルを編集します。

      test.example.com への apps Domain の設定例

      apiVersion: config.openshift.io/v1
kind: Ingress
metadata:
  name: cluster
spec:
  domain: apps.example.com            1
  appsDomain: <test.example.com>      2

      1
      デフォルトドメインを指定します。インストール後にデフォルトドメインを変更することはできません。
      2
      オプション: アプリケーションルートに使用する Red Hat OpenShift Service on AWS インフラストラクチャーのドメイン。デフォルトの接頭辞である apps の代わりに、test のような別の接頭辞を使用できます。

  2. ルートを公開し、ルートドメインの変更を確認して、既存のルートに、appsDomain フィールドで指定したドメイン名が含まれていることを確認します。

    注記

    ルートを公開する前に openshift-apiserver がローリング更新を終了するのを待機します。

    1. ルートを公開します。 

      $ oc expose service hello-openshift
route.route.openshift.io/hello-openshift exposed

      出力例:

      $ oc get routes
NAME              HOST/PORT                                   PATH   SERVICES          PORT       TERMINATION   WILDCARD
hello-openshift   hello_openshift-<my_project>.test.example.com
hello-openshift   8080-tcp                 None

2.8.18. HTTP ヘッダーケースの変換

HAProxy では、デフォルトで HTTP ヘッダー名を小文字化します。たとえば、Host: xyz.com は host: xyz.com に変更されます。レガシーアプリケーションが HTTP ヘッダー名の大文字を認識する場合、Ingress Controller の spec.httpHeaders.headerNameCaseAdjustments API フィールドを、修正されるまでレガシーアプリケーションに対応するソリューションに使用します。

重要

Red Hat OpenShift Service on AWS には HAProxy 2.6 が含まれるため、アップグレードする前に spec.httpHeaders.headerNameCaseAdjustments を使用して必要な設定を追加するようにしてください。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。

手順

クラスター管理者は、oc patch コマンドを入力するか、Ingress Controller YAML ファイルの HeaderNameCaseAdjustments フィールドを設定して HTTP ヘッダーのケースを変換できます。

  • oc patch コマンドを入力して、HTTP ヘッダーの大文字化を指定します。

    1. oc patch コマンドを入力して、HTTP host ヘッダーを Host に変更します。 

      $ oc -n openshift-ingress-operator patch ingresscontrollers/default --type=merge --patch='{"spec":{"httpHeaders":{"headerNameCaseAdjustments":["Host"]}}}'

    2. アプリケーションのルートにアノテーションを付けます。 

      $ oc annotate routes/my-application haproxy.router.openshift.io/h1-adjust-case=true

      次に、Ingress Controller は host 要求ヘッダーを指定どおりに調整します。

  • Ingress Controller の YAML ファイルを設定し、HeaderNameCaseAdjustments フィールドを使用して調整を指定します。

    1. 以下のサンプル Ingress Controller YAML は、適切にアノテーションが付けられたルートへの HTTP/1 要求について host ヘッダーを Host に調整します。

      Ingress Controller YAML のサンプル

      apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name: default
  namespace: openshift-ingress-operator
spec:
  httpHeaders:
    headerNameCaseAdjustments:
    - Host

    2. 以下のサンプルルートでは、haproxy.router.openshift.io/h1-adjust-case アノテーションを使用して HTTP 応答ヘッダー名のケース調整を有効にします。

      ルート YAML のサンプル

      apiVersion: route.openshift.io/v1
kind: Route
metadata:
  annotations:
    haproxy.router.openshift.io/h1-adjust-case: true 1
  name: my-application
  namespace: my-application
spec:
  to:
    kind: Service
    name: my-application

      1
      haproxy.router.openshift.io/h1-adjust-case を true に設定します。

2.8.19. ルーター圧縮の使用

特定の MIME タイプに対してルーター圧縮をグローバルに指定するように HAProxy Ingress Controller を設定します。mimeTypes変数を使用して、圧縮が適用される MIME タイプの形式を定義できます。タイプは、アプリケーション、イメージ、メッセージ、マルチパート、テキスト、ビデオ、または X-で始まるカスタムタイプです。MIME タイプとサブタイプの完全な表記を確認するには、RFC1341を参照してください。

注記

圧縮用に割り当てられたメモリーは、最大接続数に影響を与える可能性があります。さらに、大きなバッファーを圧縮すると、正規表現による負荷が多い場合や正規表現のリストが長い場合など、レイテンシーが発生する可能性があります。

すべての MIME タイプが圧縮から利点を得るわけではありませんが、HAProxy は、指示された場合でもリソースを使用して圧縮を試みます。一般に、html、css、js などのテキスト形式は圧縮から利点を得ますが、イメージ、音声、ビデオなどのすでに圧縮済みの形式は、圧縮に時間とリソースが費やされるわりに利点はほぼありません。

手順

  1. Ingress Controller のhttpCompressionフィールドを設定します。

    1. 以下のコマンドを使用して IngressController リソースを編集します。 

      $ oc edit -n openshift-ingress-operator ingresscontrollers/default

    2. specで、 httpCompression ポリシーフィールドをmimeTypes に設定し、圧縮を適用する必要がある MIME タイプのリストを指定します。 

      apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name: default
  namespace: openshift-ingress-operator
spec:
  httpCompression:
    mimeTypes:
    - "text/html"
    - "text/css; charset=utf-8"
    - "application/json"
   ...

2.8.20. ルーターメトリクスの公開

デフォルトで、HAProxy ルーターメトリクスをデフォルトの stats ポート (1936) に Prometheus 形式で公開できます。Prometheus などの外部メトリクス収集および集約システムは、HAProxy ルーターメメトリクスにアクセスできます。HAProxy ルーターメトリクスは、HTML およびコンマ区切り値 (CSV) 形式でブラウザーに表示できます。

前提条件

  • ファイアウォールを、デフォルトの stats ポート (1936) にアクセスするように設定している。

手順

  1. 次のコマンドを実行して、ルーター Pod 名を取得します。 

    $ oc get pods -n openshift-ingress

    出力例

    NAME                              READY   STATUS    RESTARTS   AGE
router-default-76bfffb66c-46qwp   1/1     Running   0          11h

  2. ルーター Pod が /var/lib/haproxy/conf/metrics-auth/statsUsername および /var/lib/haproxy/conf/metrics-auth/statsPassword ファイルに保存しているルーターのユーザー名およびパスワードを取得します。

    1. 次のコマンドを実行して、ユーザー名を取得します。 

      $ oc rsh <router_pod_name> cat metrics-auth/statsUsername

    2. 次のコマンドを実行して、パスワードを取得します。 

      $ oc rsh <router_pod_name> cat metrics-auth/statsPassword

  3. 次のコマンドを実行して、ルーター IP およびメトリクス証明書を取得します。 

    $ oc describe pod <router_pod>

  4. つぎのコマンドを実行して、Prometheus 形式で未加工の統計情報を取得します。 

    $ curl -u <user>:<password> http://<router_IP>:<stats_port>/metrics

  5. 次のコマンドを実行して、安全にメトリクスにアクセスします。 

    $ curl -u user:password https://<router_IP>:<stats_port>/metrics -k

  6. 次のコマンドを実行して、デフォルトの stats ポート (1936) にアクセスします。 

    $ curl -u <user>:<password> http://<router_IP>:<stats_port>/metrics

    例2.1 出力例

    ...
# HELP haproxy_backend_connections_total Total number of connections.
# TYPE haproxy_backend_connections_total gauge
haproxy_backend_connections_total{backend="http",namespace="default",route="hello-route"} 0
haproxy_backend_connections_total{backend="http",namespace="default",route="hello-route-alt"} 0
haproxy_backend_connections_total{backend="http",namespace="default",route="hello-route01"} 0
...
# HELP haproxy_exporter_server_threshold Number of servers tracked and the current threshold value.
# TYPE haproxy_exporter_server_threshold gauge
haproxy_exporter_server_threshold{type="current"} 11
haproxy_exporter_server_threshold{type="limit"} 500
...
# HELP haproxy_frontend_bytes_in_total Current total of incoming bytes.
# TYPE haproxy_frontend_bytes_in_total gauge
haproxy_frontend_bytes_in_total{frontend="fe_no_sni"} 0
haproxy_frontend_bytes_in_total{frontend="fe_sni"} 0
haproxy_frontend_bytes_in_total{frontend="public"} 119070
...
# HELP haproxy_server_bytes_in_total Current total of incoming bytes.
# TYPE haproxy_server_bytes_in_total gauge
haproxy_server_bytes_in_total{namespace="",pod="",route="",server="fe_no_sni",service=""} 0
haproxy_server_bytes_in_total{namespace="",pod="",route="",server="fe_sni",service=""} 0
haproxy_server_bytes_in_total{namespace="default",pod="docker-registry-5-nk5fz",route="docker-registry",server="10.130.0.89:5000",service="docker-registry"} 0
haproxy_server_bytes_in_total{namespace="default",pod="hello-rc-vkjqx",route="hello-route",server="10.130.0.90:8080",service="hello-svc-1"} 0
...

  7. ブラウザーで以下の URL を入力して、stats ウィンドウを起動します。 

    http://<user>:<password>@<router_IP>:<stats_port>

  8. オプション: ブラウザーに次の URL を入力して、CSV 形式で統計情報を取得します。 

    http://<user>:<password>@<router_ip>:1936/metrics;csv

2.8.21. HAProxy エラーコードの応答ページのカスタマイズ

クラスター管理者は、503、404、またはその両方のエラーページにカスタムのエラーコード応答ページを指定できます。HAProxy ルーターは、アプリケーション Pod が実行していない場合や、要求された URL が存在しない場合に 404 エラーページを提供する 503 エラーページを提供します。たとえば、503 エラーコードの応答ページをカスタマイズする場合は、アプリケーション Pod が実行していないときにページが提供されます。また、デフォルトの 404 エラーコード HTTP 応答ページは、誤ったルートまたは存在しないルートについて HAProxy ルーターによって提供されます。

カスタムエラーコードの応答ページは ConfigMap に指定し、Ingress Controller にパッチを適用されます。ConfigMap キーには、error-page-503.http と error-page-404.http の 2 つの利用可能なファイル名があります。

カスタムの HTTP エラーコードの応答ページは、HAProxy HTTP エラーページ設定のガイドライン に従う必要があります。以下は、デフォルトの Red Hat OpenShift Service on AWS HAProxy ルーターの http 503 エラーコード応答ページ の例です。デフォルトのコンテンツを、独自のカスタムページを作成するためのテンプレートとして使用できます。

デフォルトで、HAProxy ルーターは、アプリケーションが実行していない場合や、ルートが正しくないまたは存在しない場合に 503 エラーページのみを提供します。このデフォルトの動作は、Red Hat OpenShift Service on AWS 4.8 以前の動作と同じです。HTTP エラーコード応答をカスタマイズするための ConfigMap が提供されておらず、カスタム HTTP エラーコード応答ページを使用している場合、ルーターはデフォルトの 404 または 503 エラーコード応答ページを提供します。

注記

OpenShift Container Platform のデフォルトの 503 エラーコードページをカスタマイズのテンプレートとして使用する場合、ファイル内のヘッダーで CRLF 改行コードを使用できるエディターが必要になります。

手順

  1. openshift-config に my-custom-error-code-pages という名前の ConfigMap を作成します。 

    $ oc -n openshift-config create configmap my-custom-error-code-pages \
--from-file=error-page-503.http \
--from-file=error-page-404.http
    重要

    カスタムエラーコードの応答ページに適した形式を指定しない場合は、ルーター Pod が停止します。この停止を解決するには、ConfigMap を削除するか、修正し、影響を受けるルーター Pod を削除して、正しい情報で再作成できるようにします。

  2. Ingress Controller にパッチを適用し、名前を指定して my-custom-error-code-pages ConfigMap を参照します。 

    $ oc patch -n openshift-ingress-operator ingresscontroller/default --patch '{"spec":{"httpErrorCodePages":{"name":"my-custom-error-code-pages"}}}' --type=merge

    Ingress Operator は、openshift-config namespace から openshift-ingress namespace に my-custom-error-code-pages ConfigMap をコピーします。Operator は、openshift-ingress namespace のパターン <your_ingresscontroller_name>-errorpages に従って ConfigMap に名前を付けます。

  3. コピーを表示します。 

    $ oc get cm default-errorpages -n openshift-ingress

    出力例

    NAME                       DATA   AGE
default-errorpages         2      25s  1

    1
    default の Ingress Controller カスタムリソース (CR) にパッチが適用されているため、ConfigMap 名の例は default-errorpages です。

  4. カスタムエラー応答ページを含む ConfigMap がルーターボリュームにマウントされることを確認します。ConfigMap キーは、カスタム HTTP エラーコード応答を持つファイル名です。

    • 503 カスタム HTTP カスタムエラーコード応答の場合: 

      $ oc -n openshift-ingress rsh <router_pod> cat /var/lib/haproxy/conf/error_code_pages/error-page-503.http

    • 404 カスタム HTTP カスタムエラーコード応答の場合: 

      $ oc -n openshift-ingress rsh <router_pod> cat /var/lib/haproxy/conf/error_code_pages/error-page-404.http

検証

カスタムエラーコード HTTP 応答を確認します。

  1. テストプロジェクトおよびアプリケーションを作成します。 

     $ oc new-project test-ingress
    $ oc new-app django-psql-example

  2. 503 カスタム http エラーコード応答の場合:

    1. アプリケーションのすべての Pod を停止します。

    2. 以下の curl コマンドを実行するか、ブラウザーでルートのホスト名にアクセスします。 

      $ curl -vk <route_hostname>

  3. 404 カスタム http エラーコード応答の場合:

    1. 存在しないルートまたは正しくないルートにアクセスします。

    2. 以下の curl コマンドを実行するか、ブラウザーでルートのホスト名にアクセスします。 

      $ curl -vk <route_hostname>

  4. errorfile 属性が haproxy.config ファイルで適切にあるかどうかを確認します。 

    $ oc -n openshift-ingress rsh <router> cat /var/lib/haproxy/conf/haproxy.config | grep errorfile

2.8.22. Ingress Controller の最大接続数の設定

クラスター管理者は、OpenShift ルーターデプロイメントの同時接続の最大数を設定できます。既存の Ingress Controller にパッチを適用して、接続の最大数を増やすことができます。

前提条件

  • 以下では、Ingress Controller が作成済みであることを前提とします。

手順

  • Ingress Controller を更新して、HAProxy の最大接続数を変更します。 

    $ oc -n openshift-ingress-operator patch ingresscontroller/default --type=merge -p '{"spec":{"tuningOptions": {"maxConnections": 7500}}}'
    警告

    spec.tuningOptions.maxConnections の値を現在のオペレーティングシステムの制限よりも大きく設定すると、HAProxy プロセスは開始しません。このパラメーターの詳細は、Ingress Controller 設定パラメーターセクションの表を参照してください。

2.9. Red Hat OpenShift Service on AWS Ingress Operator の設定

以下の表は、Ingress Operator のコンポーネントおよび、Red Hat Site Reliability Engineers (SRE) が Red Hat OpenShift Service on AWS クラスターでこのコンポーネントを管理するかどうかについて詳しく説明します。

表2.3 Ingress Operator の責務チャート

Ingress コンポーネント管理デフォルト設定？

Ingress コントローラーのスケーリング

SRE

◯

Ingress Operator のスレッド数

SRE

◯

Ingress コントローラーのアクセスロギング

SRE

◯

Ingress コントローラーのシャード化

SRE

◯

Ingress コントローラールートの受付ポリシー

SRE

◯

Ingress コントローラーのワイルドカードルート

SRE

◯

Ingress コントローラー X-Forwarded ヘッダー

SRE

◯

Ingress コントローラールートの圧縮

SRE

◯

第3章 AWS Load Balancer Operator

AWS Load Balancer Operator (ALBO) は、Red Hat でサポートされている Operator です。ユーザーは、オプションでこれを SRE が管理する Red Hat OpenShift Service on AWS (ROSA) クラスターにインストールできます。ALBO は、ROSA クラスターで実行されているアプリケーションに AWS Elastic Load Balancing v2 (ELBv2) サービスをプロビジョニングする、AWS マネージドの AWS Load Balancer Controller (ALBC) のライフサイクルを管理します。

3.1. AWS Load Balancer Operator のインストール

特定の要件を満たしている場合は、AWS Load Balancer Operator (ALBO) をインストールできます。

前提条件

  • STS モードでインストールされた複数のアベイラビリティーゾーン (AZ) をまたいで、Bring-your-own-VPC (BYO-VPC) が設定された既存の Red Hat OpenShift Service on AWS (ROSA) クラスターがある。
  • dedicated-admin ロールを持つユーザーとしてクラスターにアクセスできる。
  • 作成された ROSA クラスターの VPC とサブネットを変更するためのアクセス権がある。
  • ROSA CLI (rosa) ツールをインストールしている。
  • Amazon Web Services (AWS) CLI がインストールされている。
  • OpenShift CLI (oc) がインストールされている。
  • OpenShift Container Platform (OCP) 4.13 以降を使用している。
重要

AWS Local Zone (LZ) の ROSA クラスターで使用する ALBO をインストールには、使用するアカウントで AWS LZ を有効にし、その AWS LZ で AWS Elastic Load Balancing v2 (ELBv2) サービスを利用可能にする必要があります。

手順

  1. 次のコマンドを実行して、クラスターインフラストラクチャー ID とクラスター OpenID Connect (OIDC) DNS を特定します。

    1. ROSA クラスターの INFRA ID を特定します。 

      $ rosa describe cluster --cluster=<cluster_name> | grep -i 'Infra ID'

      または、以下を実行します。 

      $ oc get infrastructure cluster -o json | jq -r '.status.infrastructureName'

    2. ROSA クラスターの OIDC DNS を特定します。 

      $ rosa describe cluster --cluster=<cluster_name> | grep -i 'OIDC'

      コマンドからの出力を保存します。この情報は、この後の手順で使用します。

  2. ALBO に必要な AWS IAM ポリシーを作成します。

    1. dedicated-admin ロールを持つユーザーとして ROSA クラスターにログインし、次のコマンドを使用して新しいプロジェクトを作成します。 

      $ oc new-project aws-load-balancer-operator

    2. 新しく作成した AWS IAM ロールに次の信頼ポリシーを割り当てます。 

      $ IDP='{Cluster_OIDC_Endpoint}'
$ IDP_ARN="arn:aws:iam::{AWS_AccountNo}:oidc-provider/${IDP}" 1
$ cat <<EOF > albo-operator-trusted-policy.json
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Federated": "${IDP_ARN}"
            },
            "Action": "sts:AssumeRoleWithWebIdentity",
            "Condition": {
                "StringEquals": {
                    "${IDP}:sub": "system:serviceaccount:aws-load-balancer-operator:aws-load-balancer-operator-controller-manager"
                }
            }
        }
    ]
}
EOF
      1
      '{AWS_AccountNo}' を AWS アカウント番号に置き換え、'{Cluster_OIDC_Endpoint}' を前の手順で特定した OIDC DNS に置き換えます。
      重要

      {Cluster_OIDC_Endpoint} を前に特定した OIDC DNS に置き換える際に、OIDC DNS URL の https 部分は含めないでください。URL 内の / に続く英数字情報のみ必要です。

      信頼ポリシーを AWS IAM ロールに割り当てる方法について、詳細は IAM ロールで信頼ポリシーを使用する方法 を参照してください。

    3. 生成された信頼ポリシーを使用してロールを作成し、検証します。 

      $ aws iam create-role --role-name albo-operator --assume-role-policy-document file://albo-operator-trusted-policy.json
$ OPERATOR_ROLE_ARN=$(aws iam get-role --role-name albo-operator --output json | jq -r '.Role.Arn')
$ echo $OPERATOR_ROLE_ARN

      AWS IAM ロールの作成について、詳細は IAM ロールの作成 を参照してください。

    4. Operator の権限ポリシーをロールにアタッチします。 

      $ curl -o albo-operator-permission-policy.json https://raw.githubusercontent.com/alebedev87/aws-load-balancer-operator/aws-cli-commands-for-sts/hack/operator-permission-policy.json
aws iam put-role-policy --role-name albo-operator --policy-name perms-policy-albo-operator --policy-document file://albo-operator-permission-policy.json

      AWS IAM ロールへの AWS IAM 権限の追加について、詳細は IAM アイデンティティーの権限の追加と削除 を参照してください。

    5. Operator の AWS 認証情報を生成します。 

      $ cat <<EOF> albo-operator-aws-credentials.cfg
[default]
sts_regional_endpoints = regional
role_arn = ${OPERATOR_ROLE_ARN}
web_identity_token_file = /var/run/secrets/openshift/serviceaccount/token
EOF

      認証情報ファイルの形式について、詳細は Amazon Web Services Security Token Service を手動モードで使用する を参照してください。

    6. 生成された AWS 認証情報を使用して Operator の認証情報シークレットを作成します。 

      $ oc -n aws-load-balancer-operator create secret generic aws-load-balancer-operator --from-file=credentials=albo-operator-aws-credentials.cfg

  3. AWS Load Balancer Controller (ALBC) に必要な AWS IAM ポリシーを作成します。

    1. アイデンティティープロバイダー用の信頼ポリシーファイルを生成します。次の例では OpenID Connect を使用しています。 

      $ IDP='{Cluster_OIDC_Endpoint}'
$ IDP_ARN="arn:aws:iam::{AWS_AccountNo}:oidc-provider/${IDP}"
$ cat <<EOF > albo-controller-trusted-policy.json
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Federated": "${IDP_ARN}"
            },
            "Action": "sts:AssumeRoleWithWebIdentity",
            "Condition": {
                "StringEquals": {
                    "${IDP}:sub": "system:serviceaccount:aws-load-balancer-operator:aws-load-balancer-controller-cluster"
                }
            }
        }
    ]
}
EOF

    2. 生成された信頼ポリシーを使用してロールを作成し、検証します。 

      $ aws iam create-role --role-name albo-controller --assume-role-policy-document file://albo-controller-trusted-policy.json
$ CONTROLLER_ROLE_ARN=$(aws iam get-role --role-name albo-controller --output json | jq -r '.Role.Arn')
$ echo $CONTROLLER_ROLE_ARN

    3. コントローラーの権限ポリシーをロールにアタッチします。 

      $ curl -o albo-controller-permission-policy.json https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/v2.4.7/docs/install/iam_policy.json
aws iam put-role-policy --role-name albo-controller --policy-name perms-policy-albo-controller --policy-document file://albo-controller-permission-policy.json

    4. コントローラーの AWS 認証情報を生成します。 

      $ cat <<EOF > albo-controller-aws-credentials.cfg
[default]
sts_regional_endpoints = regional
role_arn = ${CONTROLLER_ROLE_ARN}
web_identity_token_file = /var/run/secrets/openshift/serviceaccount/token
EOF

    5. 生成された AWS 認証情報を使用して、コントローラーの認証情報シークレットを作成します。 

      $ oc -n aws-load-balancer-operator create secret generic aws-load-balancer-controller-cluster --from-file=credentials=albo-controller-aws-credentials.cfg

  4. サブネットの検出に必要なタグを追加します。

    1. ROSA クラスターをホストする VPC に、次の {Key: Value} タグを追加します。{Cluster Infra ID} を、前に指定した Infra ID に置き換えます。 

      * kubernetes.io/cluster/${Cluster Infra ID}:owned

    2. 次の ELBv2 {Key: Value} タグをプライベートサブネットに追加します。必要な場合は、パブリックサブネットにも追加します。

      • プライベートサブネット: kubernetes.io/role/internal-elb:1

      • パブリックサブネット: kubernetes.io/role/elb:1

        注記

        インターネットに接続された内部ロードバランサーは、これらのサブネットが属する AZ 内に作成されます。

        VPC やサブネットなどの AWS リソースにタグを追加する方法について、詳細は Tag your Amazon EC2 resources を参照してください。

        重要

        ALBO が作成した ELBv2 リソース (ALB や NLB など) は、ROSA クラスターに設定されたカスタムタグを継承しません。これらのリソースには、個別にタグを設定する必要があります。

  5. ALBO を作成します。 

    apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: aws-load-balancer-operator
  namespace: aws-load-balancer-operator
spec:
  upgradeStrategy: Default
---
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: aws-load-balancer-operator
  namespace: aws-load-balancer-operator
spec:
  channel: stable-v1.0
  installPlanApproval: Automatic
  name: aws-load-balancer-operator
  source: redhat-operators
  sourceNamespace: openshift-marketplace
  startingCSV: aws-load-balancer-operator.v1.0.0

  6. AWS ALBC を作成します。 

    apiVersion: networking.olm.openshift.io/v1
kind: AWSLoadBalancerController
metadata:
  name: cluster
spec:
  subnetTagging: Manual
  credentials:
    name: aws-load-balancer-controller-cluster
    重要

    AWS ALBC は AZ と AWS LZ の両方に関連付けられた ALB の作成をサポートしていないため、ROSA クラスターは AWS LZ または AZ のいずれかにのみ関連付けられた ALB を持つことができますが、両方を同時に持つことはできません。

    AWS ALBC の設定について、詳細は次のトピックを参照してください。

検証

  • 次のコマンドを実行して、インストールが成功したことを確認します。

    1. プロジェクト内の Pod に関する情報を収集します。 

      $ oc get pods -n aws-load-balancer-operator

    2. プロジェクト内のログを表示します。 

      $ oc logs -n aws-load-balancer-operator deployment/aws-load-balancer-operator-controller-manager -c manager

      ROSA クラスターで実行されているアプリケーション用に ELBv2 が作成されたことを確認する詳細な手順は、AWS Load Balancer Controller のインスタンスの作成 を参照してください。

3.2. AWS Load Balancer Operator のアンインストール

AWS Load Balancer Operator (ALBO) をアンインストールし、関連リソース全体をクリーンアップするには、次の手順を実行します。

手順

  1. ALBO が作成および管理するロードバランサーを削除して、サンプルアプリケーションをクリーンアップします。ロードバランサーの削除について、詳細は Delete an Application Load Balancer を参照してください。
  2. サブネットの検出と Application Load Balancer (ALB) の作成のためにサブネットに追加された VPC タグを削除して、AWS VPC タグをクリーンアップします。詳細は、Tag basics を参照してください。
  3. ALBO と Application Load Balancer Controller (ALBC) の両方を削除して、ALBO コンポーネントをクリーンアップします。詳細は、クラスターからの Operator の削除 を参照してください。

第4章 OpenShift SDN デフォルト CNI ネットワークプロバイダー

4.1. プロジェクトのマルチキャストの有効化

注記

OpenShift SDN CNI は、Red Hat OpenShift Service on AWS 4.14 で非推奨になりました。Red Hat OpenShift Service on AWS 4.15 の時点で、ネットワークプラグインは新規インストールのオプションではありません。今後のリリースでは、OpenShift SDN ネットワークプラグインは削除され、サポートされなくなる予定です。Red Hat は、この機能が削除されるまでバグ修正とサポートを提供しますが、この機能は拡張されなくなります。OpenShift SDN CNI の代わりに、OVN Kubernetes CNI を使用できます。

4.1.1. マルチキャストについて

IP マルチキャストを使用すると、データが多数の IP アドレスに同時に配信されます。

重要
  • 現時点で、マルチキャストは低帯域幅の調整またはサービスの検出での使用に最も適しており、高帯域幅のソリューションとしては適していません。
  • デフォルトでは、ネットワークポリシーは namespace 内のすべての接続に影響します。ただし、マルチキャストはネットワークポリシーの影響を受けません。マルチキャストがネットワークポリシーと同じ namespace で有効にされている場合、deny-all ネットワークポリシーがある場合でも、マルチキャストは常に許可されます。クラスター管理者は、これを有効にする前に、ネットワークポリシーからマルチキャストが除外されることの影響を考慮する必要があります。

Red Hat OpenShift Service on AWS Pod 間のマルチキャストトラフィックはデフォルトで無効になっています。OpenShift SDN ネットワークプラグインを使用している場合、プロジェクトごとにマルチキャストを有効にできます。

networkpolicy 分離モードで OpenShift SDN ネットワークプラグインを使用する場合は、以下を行います。

  • Pod によって送信されるマルチキャストパケットは、NetworkPolicy オブジェクトに関係なく、プロジェクトの他のすべての Pod に送信されます。Pod はユニキャストで通信できない場合でもマルチキャストで通信できます。
  • 1 つのプロジェクトの Pod によって送信されるマルチキャストパケットは、NetworkPolicy オブジェクトがプロジェクト間の通信を許可する場合であっても、それ以外のプロジェクトの Pod に送信されることはありません。

multinenant 分離モードで OpenShift SDN ネットワークプラグインを使用する場合は、以下を行います。

  • Pod で送信されるマルチキャストパケットはプロジェクトにあるその他の全 Pod に送信されます。
  • あるプロジェクトの Pod によって送信されるマルチキャストパケットは、各プロジェクトが結合し、マルチキャストが結合した各プロジェクトで有効にされている場合にのみ、他のプロジェクトの Pod に送信されます。

4.1.2. Pod 間のマルチキャストの有効化

プロジェクトの Pod でマルチキャストを有効にすることができます。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin または dedicated-admin ロールを持つユーザーでクラスターにログインする必要があります。

手順

  • 以下のコマンドを実行し、プロジェクトのマルチキャストを有効にします。<namespace> を、マルチキャストを有効にする必要のある namespace に置き換えます。 

    $ oc annotate netnamespace <namespace> \
    netnamespace.network.openshift.io/multicast-enabled=true

検証

マルチキャストがプロジェクトについて有効にされていることを確認するには、以下の手順を実行します。

  1. 現在のプロジェクトを、マルチキャストを有効にしたプロジェクトに切り替えます。<project> をプロジェクト名に置き換えます。 

    $ oc project <project>

  2. マルチキャストレシーバーとして機能する Pod を作成します。 

    $ cat <<EOF| oc create -f -
apiVersion: v1
kind: Pod
metadata:
  name: mlistener
  labels:
    app: multicast-verify
spec:
  containers:
    - name: mlistener
      image: registry.access.redhat.com/ubi9
      command: ["/bin/sh", "-c"]
      args:
        ["dnf -y install socat hostname && sleep inf"]
      ports:
        - containerPort: 30102
          name: mlistener
          protocol: UDP
EOF

  3. マルチキャストセンダーとして機能する Pod を作成します。 

    $ cat <<EOF| oc create -f -
apiVersion: v1
kind: Pod
metadata:
  name: msender
  labels:
    app: multicast-verify
spec:
  containers:
    - name: msender
      image: registry.access.redhat.com/ubi9
      command: ["/bin/sh", "-c"]
      args:
        ["dnf -y install socat && sleep inf"]
EOF

  4. 新しいターミナルウィンドウまたはタブで、マルチキャストリスナーを起動します。

    1. Pod の IP アドレスを取得します。 

      $ POD_IP=$(oc get pods mlistener -o jsonpath='{.status.podIP}')

    2. 次のコマンドを入力して、マルチキャストリスナーを起動します。 

      $ oc exec mlistener -i -t -- \
    socat UDP4-RECVFROM:30102,ip-add-membership=224.1.0.1:$POD_IP,fork EXEC:hostname

  5. マルチキャストトランスミッターを開始します。

    1. Pod ネットワーク IP アドレス範囲を取得します。 

      $ CIDR=$(oc get Network.config.openshift.io cluster \
    -o jsonpath='{.status.clusterNetwork[0].cidr}')

    2. マルチキャストメッセージを送信するには、以下のコマンドを入力します。 

      $ oc exec msender -i -t -- \
    /bin/bash -c "echo | socat STDIO UDP4-DATAGRAM:224.1.0.1:30102,range=$CIDR,ip-multicast-ttl=64"

      マルチキャストが機能している場合、直前のコマンドは以下の出力を返します。 

      mlistener

第5章 ROSA クラスターのネットワーク検証

Red Hat OpenShift Service on AWS (ROSA) クラスターを既存の Virtual Private Cloud (VPC) にデプロイするとき、またはクラスターに新しいサブネットを持つ追加のマシンプールを作成するときに、ネットワーク検証チェックが自動的に実行します。このチェックによりネットワーク設定が検証され、エラーが強調表示されるため、デプロイメント前に設定の問題を解決できます。

ネットワーク検証チェックを手動で実行して、既存のクラスターの設定を検証することもできます。

5.1. ROSA クラスターのネットワーク検証について

Red Hat OpenShift Service on AWS (ROSA) クラスターを既存の Virtual Private Cloud (VPC) にデプロイするか、クラスターに新しいサブネットを持つ追加のマシンプールを作成すると、ネットワーク検証が自動的に実行されます。これは、デプロイメント前に設定の問題を特定して解決するのに役立ちます。

Red Hat OpenShift Cluster Manager を使用してクラスターをインストールする準備をする場合は、Virtual Private Cloud (VPC) subnet settings ページのサブネット ID フィールドにサブネットを入力した後に自動チェックが実行します。ROSA CLI (rosa) を対話モードで使用してクラスターを作成する場合は、必要な VPC ネットワーク情報を指定した後にチェックが実行します。対話モードなしで CLI を使用する場合、チェックはクラスターの作成の直前に開始します。

新しいサブネットを持つマシンプールをクラスターに追加すると、マシンプールがプロビジョニングされる前に、自動ネットワーク検証によってサブネットがチェックされ、ネットワーク接続が利用可能であることが確認されます。

自動ネットワーク検証が完了すると、レコードがサービスログに送信されます。レコードには、ネットワーク設定エラーを含む検証チェックの結果が示されます。特定された問題をデプロイメント前に解決すると、デプロイメントが成功する可能性が高くなります。

既存のクラスターに対してネットワーク検証を手動で実行することもできます。これにより、設定を変更した後にクラスターのネットワーク設定を検証できます。ネットワーク検証チェックを手動で実行する手順は、ネットワーク検証を手動で実行する を参照してください。

5.2. ネットワーク検証チェックの範囲

ネットワーク検証には、次の各要件のチェックが含まれます。

  • 親の Virtual Private Cloud (VPC) がある。
  • 指定されたすべてのサブネットは VPC に属している。
  • VPC で enableDnsSupport が有効になっている。
  • VPC で enableDnsHostnames が 有効になっている。
  • Egress は、AWS ファイアウォールの前提条件 セクションで指定されている必要なドメインとポートの組み合わせで利用できます。

5.3. 自動ネットワーク検証のバイパス

既知のネットワーク設定の問題がある Red Hat OpenShift Service on AWS (ROSA) クラスターを既存の Virtual Private Cloud (VPC) にデプロイする場合は、自動ネットワーク検証を回避できます。

クラスターの作成時にネットワーク検証を回避すると、クラスターのサポートステータスは制限されます。インストール後、問題を解決してからネットワーク検証を手動で実行できます。制限付きサポートステータスは、検証が成功すると削除されます。

OpenShift Cluster Manager を使用した自動ネットワーク検証のバイパス

Red Hat OpenShift Cluster Manager を使用して既存の VPC にクラスターをインストールする時に、Virtual Private Cloud (VPC) subnet settings ページで Bypass network verification を選択することで自動検証を回避できます。

5.4. ネットワーク検証を手動で実行する

Red Hat OpenShift Service on AWS (ROSA) クラスターをインストールした後、Red Hat OpenShift Cluster Manager または ROSA CLI (rosa) を使用してネットワーク検証チェックを手動で実行できます。

OpenShift Cluster Manager を使用してネットワーク検証を手動で実行する

Red Hat OpenShift Cluster Manager を使用して、既存の Red Hat OpenShift Service on AWS (ROSA) クラスターのネットワーク検証チェックを手動で実行できます。

前提条件

  • 既存の ROSA クラスターがあります。
  • クラスター所有者になっているか、クラスター編集者のロールがある。

手順

  1. OpenShift Cluster Manager に移動し、クラスターを選択します。
  2. Actions ドロップダウンメニューから Verify networking を選択します。

CLI を使用してネットワーク検証を手動で実行する

ROSA CLI (rosa) を使用して、既存の Red Hat OpenShift Service on AWS (ROSA) クラスターのネットワーク検証チェックを手動で実行できます。

ネットワーク検証を実行するときは、一連の VPC サブネット ID またはクラスター名を指定できます。

前提条件

  • インストールホストに、最新の ROSA CLI (rosa) をインストールして設定している。
  • 既存の ROSA クラスターがあります。
  • クラスター所有者になっているか、クラスター編集者のロールがある。

手順

  • 次のいずれかの方法を使用して、ネットワーク設定を確認します。

    • クラスター名を指定してネットワーク設定を確認します。サブネット ID は自動的に検出されます。 

      $ rosa verify network --cluster <cluster_name> 1
      1
      <cluster_name> は、クラスター名に置き換えます。

      出力例

      I: Verifying the following subnet IDs are configured correctly: [subnet-03146b9b52b6024cb subnet-03146b9b52b2034cc]
I: subnet-03146b9b52b6024cb: pending
I: subnet-03146b9b52b2034cc: passed
I: Run the following command to wait for verification to all subnets to complete:
rosa verify network --watch --status-only --region us-east-1 --subnet-ids subnet-03146b9b52b6024cb,subnet-03146b9b52b2034cc

      • すべてのサブネットに対する検証が完了していることを確認します。 

        $ rosa verify network --watch \ 1
                      --status-only \ 2
                      --region <region_name> \ 3
                      --subnet-ids subnet-03146b9b52b6024cb,subnet-03146b9b52b2034cc 4
        1
        watch フラグを使用すると、テスト対象のすべてのサブネットが失敗または合格状態になった後でコマンドが完了します。
        2
        status-only フラグは、ネットワーク検証の実行をトリガーしませんが、現在の状態 (例: subnet-123 (検証はまだ進行中)) を返します。デフォルトでは、このオプションを使用しない場合、このコマンドを呼び出すと、指定されたサブネットの検証が常にトリガーされます。
        3
        AWS_REGION 環境変数をオーバーライドする特定の AWS リージョンを使用します。
        4
        コンマで区切られたサブネット ID のリストを入力して確認します。いずれかのサブネットが存在しない場合は、Network verification for subnet 'subnet-<subnet_number> not found というエラーメッセージが表示され、サブネットはチェックされません。

        出力例

        I: Checking the status of the following subnet IDs: [subnet-03146b9b52b6024cb subnet-03146b9b52b2034cc]
I: subnet-03146b9b52b6024cb: passed
I: subnet-03146b9b52b2034cc: passed

        ヒント

        検証テストの完全なリストを出力するには、rosa verify network コマンドを実行するときに --debug 引数を含めることができます。

    • VPC サブネット ID を指定してネットワーク設定を確認します。<region_name> は AWS リージョンに置き換え、<AWS_account_ID> は AWS アカウント ID に置き換えます。 

      $ rosa verify network --subnet-ids 03146b9b52b6024cb,subnet-03146b9b52b2034cc --region <region_name> --role-arn arn:aws:iam::<AWS_account_ID>:role/my-Installer-Role

      出力例

      I: Verifying the following subnet IDs are configured correctly: [subnet-03146b9b52b6024cb subnet-03146b9b52b2034cc]
I: subnet-03146b9b52b6024cb: pending
I: subnet-03146b9b52b2034cc: passed
I: Run the following command to wait for verification to all subnets to complete:
rosa verify network --watch --status-only --region us-east-1 --subnet-ids subnet-03146b9b52b6024cb,subnet-03146b9b52b2034cc

      • すべてのサブネットに対する検証が完了していることを確認します。 

        $ rosa verify network --watch --status-only --region us-east-1 --subnet-ids subnet-03146b9b52b6024cb,subnet-03146b9b52b2034cc

        出力例

        I: Checking the status of the following subnet IDs: [subnet-03146b9b52b6024cb subnet-03146b9b52b2034cc]
I: subnet-03146b9b52b6024cb: passed
I: subnet-03146b9b52b2034cc: passed

第6章 クラスター全体のプロキシーの設定

既存の Virtual Private Cloud (VPC) を使用している場合は、Red Hat OpenShift Service on AWS (ROSA) クラスターのインストール中またはクラスターのインストール後に、クラスター全体のプロキシーを設定できます。プロキシーを有効にすると、コアクラスターコンポーネントはインターネットへの直接アクセスを拒否されますが、プロキシーはユーザーのワークロードには影響しません。

注記

クラウドプロバイダー API への呼び出しを含め、クラスターシステムの egress トラフィックのみがプロキシーされます。

クラスター全体のプロキシーを使用する場合は、責任をもってクラスターへのプロキシーの可用性を確保してください。プロキシーが利用できなくなると、クラスターの正常性とサポート性に影響を与える可能性があります。

6.1. クラスター全体のプロキシーを設定するための前提条件

クラスター全体のプロキシーを設定するには、次の要件を満たす必要があります。これらの要件は、インストール中またはインストール後にプロキシーを設定する場合に有効です。

一般要件

  • クラスターの所有者である。
  • アカウントには十分な権限がある。
  • クラスターに既存の Virtual Private Cloud (VPC) がある。
  • プロキシーは、クラスターの VPC および VPC のプライベートサブネットにアクセスできる。またクラスターの VPC および VPC のプライベートサブネットからもアクセスできる。

  • 次のエンドポイントが VPC エンドポイントに追加されている。

    • ec2.<aws_region>.amazonaws.com
    • elasticloadbalancing.<aws_region>.amazonaws.com

    • s3.<aws_region>.amazonaws.com

      これらのエンドポイントは、ノードから AWS EC2 API への要求を完了するために必要です。プロキシーはノードレベルではなくコンテナーレベルで機能するため、これらの要求を AWS プライベートネットワークを使用して AWS EC2 API にルーティングする必要があります。プロキシーサーバーの許可リストに EC2 API のパブリック IP アドレスを追加するだけでは不十分です。

      注記

      クラスター全体のプロキシーを使用する場合は、s3.<aws_region>.amazonaws.com エンドポイントを Gateway のタイプとして設定する必要があります。また、ec2.<aws_region>.amazonaws.com および elasticloadbalancing.<aws_region>.amazonaws.com エンドポイントを Interface のタイプとしてのみ設定できます。

ネットワーク要件

  • プロキシーが出力トラフィックを再登録する場合は、ドメインとポートの組み合わせに対する除外を作成する必要があります。次の表は、これらの例外のガイダンスを示しています。

    • プロキシーは、以下の OpenShift URL の再暗号化を除外する必要があります。

      アドレスプロトコル/ポート機能

      observatorium-mst.api.openshift.com

      https/443

      必須。Managed OpenShift 固有の Telemetry に使用されます。

      sso.redhat.com

      https/443

      https://cloud.redhat.com/openshift サイトでは、sso.redhat.com からの認証を使用してプルシークレットをダウンロードし、Red Hat SaaS ソリューションを使用してサブスクリプション、クラスターインベントリー、チャージバックレポートなどのモニタリングを行います。

    • プロキシーでは、次のサイトリライアビリティーエンジニアリング (SRE) および管理 URL の再暗号化を除外する必要があります。

      アドレスプロトコル/ポート機能

      *.osdsecuritylogs.splunkcloud.com

      OR

      inputs1.osdsecuritylogs.splunkcloud.cominputs2.osdsecuritylogs.splunkcloud.cominputs4.osdsecuritylogs.splunkcloud.cominputs5.osdsecuritylogs.splunkcloud.cominputs6.osdsecuritylogs.splunkcloud.cominputs7.osdsecuritylogs.splunkcloud.cominputs8.osdsecuritylogs.splunkcloud.cominputs9.osdsecuritylogs.splunkcloud.cominputs10.osdsecuritylogs.splunkcloud.cominputs11.osdsecuritylogs.splunkcloud.cominputs12.osdsecuritylogs.splunkcloud.cominputs13.osdsecuritylogs.splunkcloud.cominputs14.osdsecuritylogs.splunkcloud.cominputs15.osdsecuritylogs.splunkcloud.com

      tcp/9997

      ログベースのアラートについて Red Hat SRE が使用するロギング転送エンドポイントとして splunk-forwarder-operator によって使用されます。

      http-inputs-osdsecuritylogs.splunkcloud.com

      https/443

      ログベースのアラートについて Red Hat SRE が使用するロギング転送エンドポイントとして splunk-forwarder-operator によって使用されます。

    重要

    サーバーが --http-proxy または --https-proxy 引数を介してクラスター上で設定されていない透過的な転送プロキシーとして機能している場合は、プロキシーサーバーを使用して TLS 再暗号化を実行することは現在サポートされていません。

    透過的な転送プロキシーはクラスタートラフィックをインターセプトしますが、実際にはクラスター自体には設定されていません。

関連情報

6.2. 追加の信頼バンドルに対する責任

追加の信頼バンドルを指定する場合は、以下の要件を満たす必要があります。

  • 追加の信頼バンドルの内容が有効であることを確認する
  • 追加の信頼バンドルに含まれる中間証明書を含む証明書の有効期限が切れていないことを確認する
  • 追加の信頼バンドルに含まれる証明書の有効期限を追跡して必要な更新を実行する
  • 更新された追加の信頼バンドルを使用してクラスター設定を更新する

6.3. インストール中にプロキシーを設定する

Red Hat OpenShift Service on AWS (ROSA) クラスターを既存の Virtual Private Cloud (VPC) にインストールする時に、HTTP または HTTPS プロキシーを設定できます。Red Hat OpenShift Cluster Manager または ROSA CLI (rosa) を使用して、インストール中にプロキシーを設定できます。

6.3.1. OpenShift Cluster Manager を使用したインストール時のプロキシーの設定

Red Hat OpenShift Service on AWS (ROSA) クラスターを既存の Virtual Private Cloud (VPC) にインストールする場合、Red Hat OpenShift Cluster Manager を使用して、インストール中にクラスター全体の HTTP または HTTPS プロキシーを有効にすることができます。

インストールの前に、クラスターがインストールされている VPC からプロキシーにアクセスできることを確認する必要があります。プロキシーは VPC のプライベートサブネットからもアクセスできる必要があります。

OpenShift Cluster Manager を使用してインストール中にクラスター全体のプロキシーを設定する詳細な手順は、OpenShift Cluster Manager を使用したカスタマイズしたクラスターの作成 を参照してください。

6.3.2. CLI を使用したインストール時のプロキシーの設定

Red Hat OpenShift Service on AWS (ROSA) クラスターを既存の Virtual Private Cloud (VPC) にインストールする場合は、ROSA CLI (rosa) を使用して、インストール中にクラスター全体の HTTP または HTTPS プロキシーを有効にできます。

以下の手順では、インストール時にクラスター全体のプロキシーを設定するために使用される ROSA CLI (rosa) 引数の詳細を説明します。ROSA CLI を使用した一般的なインストール手順は、CLI を使用したカスタマイズしたクラスターの作成 を参照してください。

前提条件

  • クラスターがインストールされている VPC からプロキシーにアクセスできることを確認している。プロキシーは VPC のプライベートサブネットからもアクセスできる必要があります。

手順

  • クラスターの作成時にプロキシー設定を指定します。 

    $ rosa create cluster \
 <other_arguments_here> \
 --additional-trust-bundle-file <path_to_ca_bundle_file> \ 1 2 3
 --http-proxy http://<username>:<password>@<ip>:<port> \ 4 5
 --https-proxy https://<username>:<password>@<ip>:<port> \ 6 7
 --no-proxy example.com 8
    1 4 6
    additional-trust-bundle-file、http-proxy 引数、および https-proxy 引数はすべてオプションです。
    2
    http-proxy または https-proxy 引数を指定せずに additional-trust-bundle-file 引数を使用する場合、信頼バンドルはトラストストアに追加され、クラスターシステムの egress トラフィックの検証に使用されます。このシナリオでは、バンドルがプロキシーで使用するように設定されていません。
    3
    additional-trust-bundle-file 引数は、PEM でエンコードされた X.509 証明書のバンドルを指すファイルパスであり、これはすべて連結されています。additionalTrustBundle パラメーターは、プロキシーのアイデンティティー証明書が RHCOS 信頼バンドルからの認証局によって署名されない限り必要になります。追加のプロキシー設定が必要ではなく、追加の CA を必要とする MITM の透過的なプロキシーネットワークを使用する場合には、MITM CA 証明書を指定する必要があります。
    5 7
    http-proxy 引数および https-proxy 引数は、有効な URL を指している必要があります。
    8
    プロキシーを除外する宛先ドメイン名、IP アドレス、またはネットワーク CIDR のコンマ区切りのリスト。

    サブドメインのみと一致するように、ドメインの前に . を付けます。たとえば、.y.com は x.y.com に一致しますが、 y.com には一致しません。* を使用し、すべての宛先のプロキシーをバイパスします。インストール設定で networking.machineNetwork[].cidr フィールドで定義されるネットワークに含まれていないワーカーをスケールアップする場合、それらをこのリストに追加し、接続の問題を防ぐ必要があります。

    httpProxy または httpsProxy フィールドのいずれも設定されていない場合に、このフィールドは無視されます。

関連情報

6.4. インストール後のプロキシーの設定

Red Hat OpenShift Service on AWS (ROSA) クラスターを既存の Virtual Private Cloud (VPC)にインストールした後に、HTTP または HTTPS プロキシーを設定できます。Red Hat OpenShift Cluster Manager または ROSA CLI (rosa) を使用して、インストール後にプロキシーを設定できます。

6.4.1. OpenShift Cluster Manager を使用したインストール後のプロキシーの設定

Red Hat OpenShift Cluster Manager を使用して、Virtual Private Cloud (VPC) の既存の Red Hat OpenShift Service on AWS クラスターにクラスター全体のプロキシー設定を追加できます。

OpenShift Cluster Manager を使用して、既存のクラスター全体のプロキシー設定を更新することもできます。たとえば、プロキシーのネットワークアドレスを更新するか、プロキシーの認証局のいずれかが期限切れになる場合は追加の信頼バンドルを置き換える必要がある場合があります。

重要

クラスターはプロキシー設定をコントロールプレーンおよびコンピュートノードに適用します。設定の適用時に、各クラスターノードは一時的にスケジュール不可能な状態になり、そのワークロードがドレイン (解放) されます。プロセスの一環として各ノードが再起動されます。

前提条件

  • Red Hat OpenShift Service on AWS クラスターがある。
  • クラスターが VPC にデプロイされている。

手順

  1. OpenShift Cluster Manager に移動し、クラスターを選択します。
  2. Networking ページの Virtual Private Cloud (VPC) セクションで、Edit cluster-wide proxy をクリックします。

  3. Edit cluster-wide proxy ページで、プロキシー設定の詳細を指定します。

    1. 次のフィールドの少なくとも 1 つに値を入力します。

      • 有効な HTTP proxy URL を指定します。
      • 有効な HTTPS proxy URL を指定します。

      • Additional trust bundle フィールドに、PEM でエンコードされた X.509 証明書バンドルを指定します。既存の信頼バンドルファイルを置き換える場合は、Replace file を選択して フィールドを表示します。このバンドルはクラスターノードの信頼済み証明書ストアに追加されます。プロキシーのアイデンティティー証明書が Red Hat Enterprise Linux CoreOS (RHCOS) 信頼バンドルからの認証局によって署名されない限り、追加の信頼バンドルファイルが必要です。

        追加のプロキシー設定が必要ではなく、追加の認証局 (CA) を必要とする MITM の透過的なプロキシーネットワークを使用する場合には、MITM CA 証明書を指定する必要があります。

        注記

        HTTP または HTTPS プロキシー URL を指定せずに追加の信頼バンドルファイルをアップロードする場合、バンドルはクラスターに設定されますが、プロキシーで使用するように設定されていません。

    2. Confirm をクリックします。

検証

  • Networking ページの Virtual Private Cloud (VPC) セクションで、クラスターのプロキシー設定が想定どおりであることを確認します。

6.4.2. CLI を使用したインストール後のプロキシーの設定

Red Hat OpenShift Service on AWS (ROSA) CLI (rosa) を使用して、Virtual Private Cloud (VPC) の既存の ROSA クラスターにクラスター全体のプロキシー設定を追加できます。

rosa を使用して、既存のクラスター全体のプロキシー設定を更新することもできます。たとえば、プロキシーのネットワークアドレスを更新するか、プロキシーの認証局のいずれかが期限切れになる場合は追加の信頼バンドルを置き換える必要がある場合があります。

重要

クラスターはプロキシー設定をコントロールプレーンおよびコンピュートノードに適用します。設定の適用時に、各クラスターノードは一時的にスケジュール不可能な状態になり、そのワークロードがドレイン (解放) されます。プロセスの一環として各ノードが再起動されます。

前提条件

  • インストールホストに、最新の ROSA (rosa) および OpenShift (oc) CLI をインストールして設定している。
  • VPC にデプロイされた ROSA クラスターがある。

手順

  • クラスター設定を編集して、クラスター全体のプロキシーの詳細を追加または更新します。 

    $ rosa edit cluster \
 --cluster $CLUSTER_NAME \
 --additional-trust-bundle-file <path_to_ca_bundle_file> \ 1 2 3
 --http-proxy http://<username>:<password>@<ip>:<port> \ 4 5
 --https-proxy https://<username>:<password>@<ip>:<port> \ 6 7
  --no-proxy example.com 8
    1 4 6
    additional-trust-bundle-file、http-proxy 引数、および https-proxy 引数はすべてオプションです。
    2
    http-proxy または https-proxy 引数を指定せずに additional-trust-bundle-file 引数を使用する場合、信頼バンドルはトラストストアに追加され、クラスターシステムの egress トラフィックの検証に使用されます。このシナリオでは、バンドルがプロキシーで使用するように設定されていません。
    3
    additional-trust-bundle-file 引数は、PEM でエンコードされた X.509 証明書のバンドルを指すファイルパスであり、これはすべて連結されています。additionalTrustBundle パラメーターは、プロキシーのアイデンティティー証明書が RHCOS 信頼バンドルからの認証局によって署名されない限り必要になります。追加のプロキシー設定が必要ではなく、追加の CA を必要とする MITM の透過的なプロキシーネットワークを使用する場合には、MITM CA 証明書を指定する必要があります。
    注記

    プロキシーまたは追加の信頼バンドル設定をクラスターで直接変更しようとしないでください。これらの変更は、ROSA CLI (rosa) または Red Hat OpenShift Cluster Manager を使用して適用する必要があります。クラスターに直接加えられた変更はすべて自動的に元に戻されます。

    5 7
    http-proxy 引数および https-proxy 引数は、有効な URL を指している必要があります。
    8
    プロキシーを除外する宛先ドメイン名、IP アドレス、またはネットワーク CIDR のコンマ区切りのリスト。

    サブドメインのみと一致するように、ドメインの前に . を付けます。たとえば、.y.com は x.y.com に一致しますが、 y.com には一致しません。* を使用し、すべての宛先のプロキシーをバイパスします。インストール設定で networking.machineNetwork[].cidr フィールドで定義されるネットワークに含まれていないワーカーをスケールアップする場合、それらをこのリストに追加し、接続の問題を防ぐ必要があります。

    httpProxy または httpsProxy フィールドのいずれも設定されていない場合に、このフィールドは無視されます。

検証

  1. マシン設定プールのステータスを一覧表示し、それらが更新されていることを確認します。 

    $ oc get machineconfigpools

    出力例

    NAME     CONFIG                                             UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
master   rendered-master-d9a03f612a432095dcde6dcf44597d90   True      False      False      3              3                   3                     0                      31h
worker   rendered-worker-f6827a4efe21e155c25c21b43c46f65e   True      False      False      6              6                   6                     0                      31h

  2. クラスターのプロキシー設定を表示し、詳細が想定通りに表示されていることを確認します。 

    $ oc get proxy cluster -o yaml

    出力例

    apiVersion: config.openshift.io/v1
kind: Proxy
spec:
  httpProxy: http://proxy.host.domain:<port>
  httpsProxy: https://proxy.host.domain:<port>
  <...more...>
status:
  httpProxy: http://proxy.host.domain:<port>
  httpsProxy: https://proxy.host.domain:<port>
  <...more...>

6.5. クラスター全体のプロキシーの削除

ROSA CLI ツールを使用して、クラスター全体のプロキシーを削除できます。クラスターを削除した後、クラスターに追加された信頼バンドルもすべて削除する必要があります。

6.5.1. CLI を使用してクラスター全体のプロキシーを削除する

クラスターからプロキシーのアドレスを削除するには、Red Hat OpenShift Service on AWS (ROSA) CLI、rosa を使用する必要があります。

前提条件

  • クラスター管理者の権限がある。
  • ROSA CLI (rosa) ツールをインストールしている。

手順

  • rosa edit コマンドを使用して、プロキシーを変更します。--http-proxy および --https-proxy 引数に空の文字列を渡して、クラスターからプロキシーをクリアする必要があります。 

    $ rosa edit cluster -c <cluster_name> --http-proxy "" --https-proxy ""
    注記

    プロキシーはプロキシー引数の 1 つしか使用しない場合がありますが、空のフィールドは無視されるため、空の文字列を --http-proxy 引数と --https-proxy 引数の両方に渡しても問題は発生しません。

    出力例

    I: Updated cluster <cluster_name>

検証

  • rosa describe コマンドを使用して、プロキシーがクラスターから削除されたことを確認できます。 

    $ rosa describe cluster -c <cluster_name>

    削除する前に、プロキシー IP がプロキシーセクションに表示されます。 

    Name:                       <cluster_name>
ID:                         <cluster_internal_id>
External ID:                <cluster_external_id>
OpenShift Version:          4.0
Channel Group:              stable
DNS:                        <dns>
AWS Account:                <aws_account_id>
API URL:                    <api_url>
Console URL:                <console_url>
Region:                     us-east-1
Multi-AZ:                   false
Nodes:
 - Control plane:           3
 - Infra:                   2
 - Compute:                 2
Network:
 - Type:                    OVNKubernetes
 - Service CIDR:            <service_cidr>
 - Machine CIDR:            <machine_cidr>
 - Pod CIDR:                <pod_cidr>
 - Host Prefix:             <host_prefix>
Proxy:
 - HTTPProxy:               <proxy_url>
Additional trust bundle:    REDACTED

    プロキシーを削除すると、プロキシーセクションが削除されます。 

    Name:                       <cluster_name>
ID:                         <cluster_internal_id>
External ID:                <cluster_external_id>
OpenShift Version:          4.0
Channel Group:              stable
DNS:                        <dns>
AWS Account:                <aws_account_id>
API URL:                    <api_url>
Console URL:                <console_url>
Region:                     us-east-1
Multi-AZ:                   false
Nodes:
 - Control plane:           3
 - Infra:                   2
 - Compute:                 2
Network:
 - Type:                    OVNKubernetes
 - Service CIDR:            <service_cidr>
 - Machine CIDR:            <machine_cidr>
 - Pod CIDR:                <pod_cidr>
 - Host Prefix:             <host_prefix>
Additional trust bundle:    REDACTED

6.5.2. Red Hat OpenShift Service on AWS クラスターでの認証局の削除

Red Hat OpenShift Service on AWS (ROSA) CLI の rosa を使用して、クラスターから認証局 (CA) を削除できます。

前提条件

  • クラスター管理者の権限がある。
  • ROSA CLI (rosa) ツールをインストールしている。
  • クラスターには認証局が追加されている。

手順

  • rosa edit コマンドを使用して、CA 信頼バンドルを変更します。--additional-trust-bundle-file 引数に空の文字列を渡して、クラスターから信頼バンドルを消去する必要があります。 

    $ rosa edit cluster -c <cluster_name> --additional-trust-bundle-file ""

    出力例

    I: Updated cluster <cluster_name>

検証

  • rosa describe コマンドを使用して、信頼バンドルがクラスターから削除されたことを確認できます。 

    $ rosa describe cluster -c <cluster_name>

    削除する前に、追加の信頼バンドルセクションが表示され、セキュリティー上の目的でその値が編集されます。 

    Name:                       <cluster_name>
ID:                         <cluster_internal_id>
External ID:                <cluster_external_id>
OpenShift Version:          4.0
Channel Group:              stable
DNS:                        <dns>
AWS Account:                <aws_account_id>
API URL:                    <api_url>
Console URL:                <console_url>
Region:                     us-east-1
Multi-AZ:                   false
Nodes:
 - Control plane:           3
 - Infra:                   2
 - Compute:                 2
Network:
 - Type:                    OVNKubernetes
 - Service CIDR:            <service_cidr>
 - Machine CIDR:            <machine_cidr>
 - Pod CIDR:                <pod_cidr>
 - Host Prefix:             <host_prefix>
Proxy:
 - HTTPProxy:               <proxy_url>
Additional trust bundle:    REDACTED

    プロキシーを削除すると、追加の信頼バンドルセクションが削除されます。 

    Name:                       <cluster_name>
ID:                         <cluster_internal_id>
External ID:                <cluster_external_id>
OpenShift Version:          4.0
Channel Group:              stable
DNS:                        <dns>
AWS Account:                <aws_account_id>
API URL:                    <api_url>
Console URL:                <console_url>
Region:                     us-east-1
Multi-AZ:                   false
Nodes:
 - Control plane:           3
 - Infra:                   2
 - Compute:                 2
Network:
 - Type:                    OVNKubernetes
 - Service CIDR:            <service_cidr>
 - Machine CIDR:            <machine_cidr>
 - Pod CIDR:                <pod_cidr>
 - Host Prefix:             <host_prefix>
Proxy:
 - HTTPProxy:               <proxy_url>

第7章 CIDR 範囲の定義

次の CIDR 範囲には、重複しない範囲を指定する必要があります。

注記

クラスターの作成後にマシンの CIDR 範囲を変更することはできません。

サブネット CIDR 範囲を指定するときは、サブネット CIDR 範囲が定義済みの Machine CIDR 内にあることを確認してください。サブネットの CIDR 範囲が、考えられる AWS ロードバランサー用の少なくとも 8 つの IP アドレスを含め、意図したすべてのワークロードに十分な IP アドレスを許可していることを確認する必要があります。

重要

Red Hat OpenShift Service on AWS 4.11 以降のデフォルトのネットワークプロバイダーである OVN-Kubernetes は、IP アドレス範囲 100.64.0.0/16 を内部的に使用します。クラスターで OVN-Kubernetes を使用している場合は、クラスター内の他の CIDR 定義に IP アドレス範囲 100.64.0.0/16 を含めないでください。

7.1. Machine CIDR

Machine CIDR フィールドで、マシンまたはクラスターノードの IP アドレス範囲を指定する必要があります。この範囲には、仮想プライベートクラウド (VPC) サブネットのすべての CIDR アドレス範囲が含まれている必要があります。サブネットは連続している必要があります。単一のアベイラビリティーゾーンデプロイメントでは、サブネット接頭辞 /25 を使用した 128 アドレスの最小 IP アドレス範囲がサポートされます。サブネット接頭辞 /24 を使用する最小アドレス範囲 256 アドレスの範囲は、複数のアベイラビリティーゾーンを使用するデプロイメントでサポートされます。

デフォルトは 10.0.0.0/16 です。この範囲は、接続されているネットワークと競合しないようにする必要があります。

注記

HCP で ROSA を使用する場合、静的 IP アドレス 172.20.0.1 は内部 Kubernetes API アドレス用に予約されています。マシン、Pod、およびサービスの CIDR 範囲は、この IP アドレスと競合してはなりません。

7.2. Service CIDR

Service CIDR フィールドで、サービスの IP アドレス範囲を指定する必要があります。必須ではありませんが、クラスター間でアドレスブロックを同じにすることが推奨されます。これにより、IP アドレスの競合が発生することはありません。範囲は、ワークロードに対応するのに十分な大きさである必要があります。アドレスブロックは、クラスター内からアクセスする外部サービスと重複してはいけません。デフォルトは 172.30.0.0/16 です。

7.3. Pod CIDR

Pod CIDR フィールドで、Pod の IP アドレス範囲を指定する必要があります。

必須ではありませんが、クラスター間でアドレスブロックを同じにすることが推奨されます。これにより、IP アドレスの競合が発生することはありません。範囲は、ワークロードに対応するのに十分な大きさである必要があります。アドレスブロックは、クラスター内からアクセスする外部サービスと重複してはいけません。デフォルトは 10.128.0.0/14 です。

7.4. ホスト接頭辞

Host Prefix フィールドで、個々のマシンにスケジュールされた Pod に割り当てられたサブネット接頭辞の長さを指定する必要があります。ホスト接頭辞は、各マシンの Pod IP アドレスプールを決定します。

例えば、ホスト接頭辞を /23 に設定した場合、各マシンには Pod CIDR アドレス範囲から /23 のサブネットが割り当てられます。デフォルトは /23 で、クラスターノード数は 512、ノードあたりの Pod 数は 512 となっていますが、いずれも弊社がサポートする最大値を超えています。

第8章 ネットワークポリシー

8.1. ネットワークポリシーについて

クラスター管理者は、トラフィックをクラスター内の Pod に制限するネットワークポリシーを定義できます。

8.1.1. ネットワークポリシーについて

Kubernetes ネットワークポリシーをサポートするネットワークプラグインを使用するクラスターでは、ネットワーク分離は NetworkPolicy オブジェクトによって完全に制御されます。Red Hat OpenShift Service on AWS 4 では、OpenShift SDN はデフォルトのネットワーク分離モードでのネットワークポリシーの使用をサポートしています。

警告

ネットワークポリシーは、ホストのネットワーク namespace には適用されません。ホストネットワークが有効にされている Pod はネットワークポリシールールによる影響を受けません。ただし、ホストネットワークの Pod に接続する Pod はネットワークポリシールールの影響を受ける可能性があります。

ネットワークポリシーは、ローカルホストまたは常駐ノードからのトラフィックをブロックすることはできません。

デフォルトで、プロジェクトのすべての Pod は他の Pod およびネットワークのエンドポイントからアクセスできます。プロジェクトで 1 つ以上の Pod を分離するには、そのプロジェクトで NetworkPolicy オブジェクトを作成し、許可する着信接続を指定します。プロジェクト管理者は独自のプロジェクト内で NetworkPolicy オブジェクトの作成および削除を実行できます。

Pod が 1 つ以上の NetworkPolicy オブジェクトのセレクターで一致する場合、Pod はそれらの 1 つ以上の NetworkPolicy オブジェクトで許可される接続のみを受け入れます。NetworkPolicy オブジェクトによって選択されていない Pod は完全にアクセス可能です。

ネットワークポリシーは、TCP、UDP、ICMP、および SCTP プロトコルにのみ適用されます。他のプロトコルは影響を受けません。

以下のサンプル NetworkPolicy オブジェクトは、複数の異なるシナリオをサポートすることを示しています。

  • すべてのトラフィックを拒否します。

    プロジェクトに deny by default (デフォルトで拒否) を実行させるには、すべての Pod に一致するが、トラフィックを一切許可しない NetworkPolicy オブジェクトを追加します。 

    kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: deny-by-default
spec:
  podSelector: {}
  ingress: []

  • Red Hat OpenShift Service on AWS Ingress コントローラーからの接続のみを許可します。

    プロジェクトで Red Hat OpenShift Service on AWS Ingress コントローラーからの接続のみを許可するには、以下の NetworkPolicy オブジェクトを追加します。 

    apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-openshift-ingress
spec:
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          network.openshift.io/policy-group: ingress
  podSelector: {}
  policyTypes:
  - Ingress

  • プロジェクト内の Pod からの接続のみを受け入れます。

    Pod が同じプロジェクト内の他の Pod からの接続を受け入れるが、他のプロジェクトの Pod からの接続を拒否するように設定するには、以下の NetworkPolicy オブジェクトを追加します。 

    kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-same-namespace
spec:
  podSelector: {}
  ingress:
  - from:
    - podSelector: {}

  • Pod ラベルに基づいて HTTP および HTTPS トラフィックのみを許可します。

    特定のラベル (以下の例の role=frontend) の付いた Pod への HTTP および HTTPS アクセスのみを有効にするには、以下と同様の NetworkPolicy オブジェクトを追加します。 

    kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-http-and-https
spec:
  podSelector:
    matchLabels:
      role: frontend
  ingress:
  - ports:
    - protocol: TCP
      port: 80
    - protocol: TCP
      port: 443

  • namespace および Pod セレクターの両方を使用して接続を受け入れます。

    namespace と Pod セレクターを組み合わせてネットワークトラフィックのマッチングをするには、以下と同様の NetworkPolicy オブジェクトを使用できます。 

    kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-pod-and-namespace-both
spec:
  podSelector:
    matchLabels:
      name: test-pods
  ingress:
    - from:
      - namespaceSelector:
          matchLabels:
            project: project_name
        podSelector:
          matchLabels:
            name: test-pods

NetworkPolicy オブジェクトは加算されるものです。 つまり、複数の NetworkPolicy オブジェクトを組み合わせて複雑なネットワーク要件を満すことができます。

たとえば、先の例で定義された NetworkPolicy オブジェクトの場合、同じプロジェト内に allow-same-namespace と allow-http-and-https ポリシーの両方を定義することができます。これにより、ラベル role=frontend の付いた Pod は各ポリシーで許可されるすべての接続を受け入れます。つまり、同じ namespace の Pod からのすべてのポート、およびすべての namespace の Pod からのポート 80 および 443 での接続を受け入れます。

8.1.1.1. allow-from-router ネットワークポリシーの使用

次の NetworkPolicy を使用して、ルーターの設定に関係なく外部トラフィックを許可します。 

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-router
spec:
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          policy-group.network.openshift.io/ingress: ""1
  podSelector: {}
  policyTypes:
  - Ingress
1
policy-group.network.openshift.io/ingress:"" ラベルは、OpenShift-SDN と OVN-Kubernetes の両方をサポートします。

8.1.1.2. allow-from-hostnetwork ネットワークポリシーの使用

次の allow-from-hostnetwork NetworkPolicy オブジェクトを追加して、ホストネットワーク Pod からのトラフィックを転送します。 

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-hostnetwork
spec:
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          policy-group.network.openshift.io/host-network: ""
  podSelector: {}
  policyTypes:
  - Ingress

8.1.2. OpenShift SDN を使用したネットワークポリシー最適化

ネットワークポリシーを使用して、namespace 内でラベルで相互に区別される Pod を分離します。

NetworkPolicy オブジェクトを単一 namespace 内の多数の個別 Pod に適用することは効率的ではありません。Pod ラベルは IP レベルには存在しないため、ネットワークポリシーは、podSelector で選択されるすべての Pod 間のすべてのリンクについての別個の Open vSwitch (OVS) フロールールを生成します。

たとえば、仕様の podSelector および NetworkPolicy オブジェクト内の ingress podSelector のそれぞれが 200 Pod に一致する場合、40,000 (200*200) OVS フロールールが生成されます。これにより、ノードの速度が低下する可能性があります。

ネットワークポリシーを設計する場合は、以下のガイドラインを参照してください。

  • namespace を使用して分離する必要のある Pod のグループを組み込み、OVS フロールールの数を減らします。

    namespace 全体を選択する NetworkPolicy オブジェクトは、namespaceSelectors または空の podSelectors を使用して、namespace の VXLAN 仮想ネットワーク ID に一致する単一の OVS フロールールのみを生成します。

  • 分離する必要のない Pod は元の namespace に維持し、分離する必要のある Pod は 1 つ以上の異なる namespace に移します。
  • 追加のターゲット設定された namespace 間のネットワークポリシーを作成し、分離された Pod から許可する必要のある特定のトラフィックを可能にします。

8.1.3. OVN-Kubernetes ネットワークプラグインによるネットワークポリシーの最適化

ネットワークポリシーを設計する場合は、以下のガイドラインを参照してください。

  • 同じ spec.podSelector 仕様を持つネットワークポリシーの場合、ingress ルールまたは egress ルールを持つ複数のネットワークポリシーを使用するよりも、複数の Ingress ルールまたは egress ルールを持つ 1 つのネットワークポリシーを使用する方が効率的です。

  • podSelector または namespaceSelector 仕様に基づくすべての Ingress または egress ルールは、number of pods selected by network policy + number of pods selected by ingress or egress rule に比例する数の OVS フローを生成します。そのため、Pod ごとに個別のルールを作成するのではなく、1 つのルールで必要な数の Pod を選択できる podSelector または namespaceSelector 仕様を使用することが推奨されます。

    たとえば、以下のポリシーには 2 つのルールが含まれています。 

    apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-network-policy
spec:
  podSelector: {}
  ingress:
  - from:
    - podSelector:
        matchLabels:
          role: frontend
  - from:
    - podSelector:
        matchLabels:
          role: backend

    以下のポリシーは、上記と同じ 2 つのルールを 1 つのルールとして表現しています。 

    apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-network-policy
spec:
  podSelector: {}
  ingress:
  - from:
    - podSelector:
        matchExpressions:
        - {key: role, operator: In, values: [frontend, backend]}

    同じガイドラインが spec.podSelector 仕様に適用されます。異なるネットワークポリシーに同じ ingress ルールまたは egress ルールがある場合、共通の spec.podSelector 仕様で 1 つのネットワークポリシーを作成する方が効率的な場合があります。たとえば、以下の 2 つのポリシーには異なるルールがあります。 

    apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: policy1
spec:
  podSelector:
    matchLabels:
      role: db
  ingress:
  - from:
    - podSelector:
        matchLabels:
          role: frontend
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: policy2
spec:
  podSelector:
    matchLabels:
      role: client
  ingress:
  - from:
    - podSelector:
        matchLabels:
          role: frontend

    以下のネットワークポリシーは、上記と同じ 2 つのルールを1 つのルールとして表現しています。 

    apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: policy3
spec:
  podSelector:
    matchExpressions:
    - {key: role, operator: In, values: [db, client]}
  ingress:
  - from:
    - podSelector:
        matchLabels:
          role: frontend

    この最適化は、複数のセレクターを 1 つのセレクターとして表現する場合に限り適用できます。セレクターが異なるラベルに基づいている場合、この最適化は適用できない可能性があります。その場合は、ネットワークポリシーの最適化に特化して新規ラベルをいくつか適用することを検討してください。

8.1.4. 次のステップ

8.2. ネットワークポリシーの作成

admin ロールを持つユーザーは、namespace のネットワークポリシーを作成できます。

8.2.1. サンプル NetworkPolicy オブジェクト

以下は、サンプル NetworkPolicy オブジェクトにアノテーションを付けます。 

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-27107 1
spec:
  podSelector: 2
    matchLabels:
      app: mongodb
  ingress:
  - from:
    - podSelector: 3
        matchLabels:
          app: app
    ports: 4
    - protocol: TCP
      port: 27017
1
NetworkPolicy オブジェクトの名前。
2
ポリシーが適用される Pod を説明するセレクター。ポリシーオブジェクトは NetworkPolicy オブジェクトが定義されるプロジェクトの Pod のみを選択できます。
3
ポリシーオブジェクトが入力トラフィックを許可する Pod に一致するセレクター。セレクターは、NetworkPolicy と同じ namaspace にある Pod を照合して検索します。
4
トラフィックを受け入れる 1 つ以上の宛先ポートのリスト。

8.2.2. CLI を使用したネットワークポリシーの作成

クラスターの namespace に許可される Ingress または egress ネットワークトラフィックを記述する詳細なルールを定義するには、ネットワークポリシーを作成できます。

注記

cluster-admin ロールを持つユーザーでログインしている場合、クラスター内の任意の namespace でネットワークポリシーを作成できます。

前提条件

  • クラスターは、NetworkPolicy オブジェクトをサポートするネットワークプラグイン (mode: NetworkPolicy が設定された OVN-Kubernetes ネットワークプラグインや OpenShift SDN ネットワークプラグインなど) を使用します。このモードは OpenShiftSDN のデフォルトです。
  • OpenShift CLI (oc) がインストールされている。
  • admin 権限を持つユーザーとしてクラスターにログインしている。
  • ネットワークポリシーが適用される namespace で作業している。

手順

  1. ポリシールールを作成します。

    1. <policy_name>.yaml ファイルを作成します。 

      $ touch <policy_name>.yaml

      ここでは、以下のようになります。

      <policy_name>
      ネットワークポリシーファイル名を指定します。

    2. 作成したばかりのファイルで、以下の例のようなネットワークポリシーを定義します。

      すべての namespace のすべての Pod から ingress を拒否します。

      これは基本的なポリシーであり、他のネットワークポリシーの設定によって許可されたクロス Pod トラフィック以外のすべてのクロス Pod ネットワーキングをブロックします。 

      kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: deny-by-default
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  ingress: []

      同じ namespace のすべての Pod から ingress を許可します。

      kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-same-namespace
spec:
  podSelector:
  ingress:
  - from:
    - podSelector: {}

      特定のnamespaceから 1 つの Pod への上りトラフィックを許可する

      このポリシーは、namespace-y で実行されている Pod から pod-a というラベルの付いた Pod へのトラフィックを許可します。 

      kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-traffic-pod
spec:
  podSelector:
   matchLabels:
      pod: pod-a
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
           kubernetes.io/metadata.name: namespace-y

  2. ネットワークポリシーオブジェクトを作成するには、以下のコマンドを入力します。 

    $ oc apply -f <policy_name>.yaml -n <namespace>

    ここでは、以下のようになります。

    <policy_name>
    ネットワークポリシーファイル名を指定します。
    <namespace>
    オプション: オブジェクトが現在の namespace 以外の namespace に定義されている場合は namespace を指定します。

    出力例

    networkpolicy.networking.k8s.io/deny-by-default created

注記

cluster-admin 権限で Web コンソールにログインする場合、YAML で、または Web コンソールのフォームから、クラスターの任意の namespace でネットワークポリシーを直接作成できます。

8.2.3. デフォルトの全拒否ネットワークポリシーの作成

これは基本的なポリシーであり、他のデプロイメントされたネットワークポリシーの設定によって許可されたネットワークトラフィック以外のすべてのクロス Pod ネットワークをブロックします。この手順では、デフォルトの deny-by-default ポリシーを適用します。

注記

cluster-admin ロールを持つユーザーでログインしている場合、クラスター内の任意の namespace でネットワークポリシーを作成できます。

前提条件

  • クラスターは、NetworkPolicy オブジェクトをサポートするネットワークプラグイン (mode: NetworkPolicy が設定された OVN-Kubernetes ネットワークプラグインや OpenShift SDN ネットワークプラグインなど) を使用します。このモードは OpenShiftSDN のデフォルトです。
  • OpenShift CLI (oc) がインストールされている。
  • admin 権限を持つユーザーとしてクラスターにログインしている。
  • ネットワークポリシーが適用される namespace で作業している。

手順

  1. すべての namespace におけるすべての Pod からの ingress を拒否する deny-by-default ポリシーを定義する次の YAML を作成します。YAML を deny-by-default.yaml ファイルに保存します。 

    kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: deny-by-default
  namespace: default 1
spec:
  podSelector: {} 2
  ingress: [] 3
    1
    namespace: default は、このポリシーを default namespace にデプロイします。
    2
    podSelector: は空です。これは、すべての Pod に一致することを意味します。したがって、ポリシーはデフォルトnamespaceのすべての Pod に適用されます。
    3
    指定された ingress ルールはありません。これにより、着信トラフィックがすべての Pod にドロップされます。

  2. 次のコマンドを入力して、ポリシーを適用します。 

    $ oc apply -f deny-by-default.yaml

    出力例

    networkpolicy.networking.k8s.io/deny-by-default created

8.2.4. 外部クライアントからのトラフィックを許可するネットワークポリシーの作成

deny-by-default ポリシーを設定すると、外部クライアントからラベル app=web を持つ Pod へのトラフィックを許可するポリシーの設定に進むことができます。

注記

cluster-admin ロールを持つユーザーでログインしている場合、クラスター内の任意の namespace でネットワークポリシーを作成できます。

この手順に従って、パブリックインターネットから直接、またはロードバランサーを使用して Pod にアクセスすることにより、外部サービスを許可するポリシーを設定します。トラフィックは、ラベル app=web を持つ Pod にのみ許可されます。

前提条件

  • クラスターは、NetworkPolicy オブジェクトをサポートするネットワークプラグイン (mode: NetworkPolicy が設定された OVN-Kubernetes ネットワークプラグインや OpenShift SDN ネットワークプラグインなど) を使用します。このモードは OpenShiftSDN のデフォルトです。
  • OpenShift CLI (oc) がインストールされている。
  • admin 権限を持つユーザーとしてクラスターにログインしている。
  • ネットワークポリシーが適用される namespace で作業している。

手順

  1. パブリックインターネットからのトラフィックが直接、またはロードバランサーを使用して Pod にアクセスできるようにするポリシーを作成します。YAML を web-allow-external.yaml ファイルに保存します。 

    kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: web-allow-external
  namespace: default
spec:
  policyTypes:
  - Ingress
  podSelector:
    matchLabels:
      app: web
  ingress:
    - {}

  2. 次のコマンドを入力して、ポリシーを適用します。 

    $ oc apply -f web-allow-external.yaml

    出力例

    networkpolicy.networking.k8s.io/web-allow-external created

    このポリシーは、次の図に示すように、外部トラフィックを含むすべてのリソースからのトラフィックを許可します。

Allow traffic from external clients

8.2.5. すべてのnamespaceからアプリケーションへのトラフィックを許可するネットワークポリシーを作成する

注記

cluster-admin ロールを持つユーザーでログインしている場合、クラスター内の任意の namespace でネットワークポリシーを作成できます。

この手順に従って、すべてのnamespace内のすべての Pod から特定のアプリケーションへのトラフィックを許可するポリシーを設定します。

前提条件

  • クラスターは、NetworkPolicy オブジェクトをサポートするネットワークプラグイン (mode: NetworkPolicy が設定された OVN-Kubernetes ネットワークプラグインや OpenShift SDN ネットワークプラグインなど) を使用します。このモードは OpenShiftSDN のデフォルトです。
  • OpenShift CLI (oc) がインストールされている。
  • admin 権限を持つユーザーとしてクラスターにログインしている。
  • ネットワークポリシーが適用される namespace で作業している。

手順

  1. すべてのnamespaceのすべての Pod から特定のアプリケーションへのトラフィックを許可するポリシーを作成します。YAML を web-allow-all-namespaces.yaml ファイルに保存します。 

    kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: web-allow-all-namespaces
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: web 1
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector: {} 2
    1
    デフォルトの namespace の app:web Pod にのみポリシーを適用します。
    2
    すべてのnamespaceのすべての Pod を選択します。
    注記

    デフォルトでは、namespaceSelector の指定を省略した場合、namespace は選択されません。つまり、ポリシーは、ネットワークポリシーがデプロイされている namespace からのトラフィックのみを許可します。

  2. 次のコマンドを入力して、ポリシーを適用します。 

    $ oc apply -f web-allow-all-namespaces.yaml

    出力例

    networkpolicy.networking.k8s.io/web-allow-all-namespaces created

検証

  1. 次のコマンドを入力して、default namespace で Web サービスを開始します。 

    $ oc run web --namespace=default --image=nginx --labels="app=web" --expose --port=80

  2. 次のコマンドを実行して、alpine イメージを secondary namespace にデプロイし、シェルを開始します。 

    $ oc run test-$RANDOM --namespace=secondary --rm -i -t --image=alpine -- sh

  3. シェルで次のコマンドを実行し、リクエストが許可されていることを確認します。 

    # wget -qO- --timeout=2 http://web.default

    予想される出力

    <!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
html { color-scheme: light dark; }
body { width: 35em; margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif; }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>

8.2.6. namespaceからアプリケーションへのトラフィックを許可するネットワークポリシーの作成

注記

cluster-admin ロールを持つユーザーでログインしている場合、クラスター内の任意の namespace でネットワークポリシーを作成できます。

特定の namespace からラベル app=web を持つ Pod へのトラフィックを許可するポリシーを設定するには、次の手順に従います。以下の場合にこれを行うことができます。

  • 運用データベースへのトラフィックを、運用ワークロードがデプロイされているnamespaceのみに制限します。
  • 特定のnamespaceにデプロイされた監視ツールを有効にして、現在のnamespaceからメトリックをスクレイピングします。

前提条件

  • クラスターは、NetworkPolicy オブジェクトをサポートするネットワークプラグイン (mode: NetworkPolicy が設定された OVN-Kubernetes ネットワークプラグインや OpenShift SDN ネットワークプラグインなど) を使用します。このモードは OpenShiftSDN のデフォルトです。
  • OpenShift CLI (oc) がインストールされている。
  • admin 権限を持つユーザーとしてクラスターにログインしている。
  • ネットワークポリシーが適用される namespace で作業している。

手順

  1. ラベルが purpose=production の特定の namespace 内にあるすべての Pod からのトラフィックを許可するポリシーを作成します。YAML を web-allow-prod.yaml ファイルに保存します。 

    kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: web-allow-prod
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: web 1
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          purpose: production 2
    1
    デフォルトの namespace の app:web Pod にのみポリシーを適用します。
    2
    ラベルが purpose=production の namespace 内にある Pod のみにトラフィックを制限します。

  2. 次のコマンドを入力して、ポリシーを適用します。 

    $ oc apply -f web-allow-prod.yaml

    出力例

    networkpolicy.networking.k8s.io/web-allow-prod created

検証

  1. 次のコマンドを入力して、default namespace で Web サービスを開始します。 

    $ oc run web --namespace=default --image=nginx --labels="app=web" --expose --port=80

  2. 次のコマンドを実行して、prod namespace を作成します。 

    $ oc create namespace prod

  3. 次のコマンドを実行して、prod namespace にラベルを付けます。 

    $ oc label namespace/prod purpose=production

  4. 次のコマンドを実行して、dev namespace を作成します。 

    $ oc create namespace dev

  5. 次のコマンドを実行して、dev namespace にラベルを付けます。 

    $ oc label namespace/dev purpose=testing

  6. 次のコマンドを実行して、alpine イメージを dev namespace にデプロイし、シェルを開始します。 

    $ oc run test-$RANDOM --namespace=dev --rm -i -t --image=alpine -- sh

  7. シェルで次のコマンドを実行し、リクエストがブロックされていることを確認します。 

    # wget -qO- --timeout=2 http://web.default

    予想される出力

    wget: download timed out

  8. 次のコマンドを実行して、alpine イメージを prod namespace にデプロイし、シェルを開始します。 

    $ oc run test-$RANDOM --namespace=prod --rm -i -t --image=alpine -- sh

  9. シェルで次のコマンドを実行し、リクエストが許可されていることを確認します。 

    # wget -qO- --timeout=2 http://web.default

    予想される出力

    <!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
html { color-scheme: light dark; }
body { width: 35em; margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif; }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>

8.2.7. OpenShift Cluster Manager を使用したネットワークポリシーの作成

クラスターの namespace に許可される Ingress または egress ネットワークトラフィックを記述する詳細なルールを定義するには、ネットワークポリシーを作成できます。

前提条件

  • OpenShift Cluster Manager にログインしている。
  • Red Hat OpenShift Service on AWS クラスターを作成している。
  • クラスターにアイデンティティープロバイダーを設定している。
  • 設定したアイデンティティープロバイダーにユーザーアカウントを追加している。
  • Red Hat OpenShift Service on AWS クラスター内にプロジェクトを作成しました。

手順

  1. OpenShift Cluster Manager で、アクセスするクラスターをクリックします。
  2. コンソールを開く をクリックして、OpenShift Web コンソールに移動します。
  3. アイデンティティープロバイダーをクリックし、クラスターにログインするためのクレデンシャルを指定します。
  4. 管理者の観点から、Networking の下の NetworkPolicies をクリックします。
  5. ネットワークポリシーの 作成 をクリックします。
  6. ポリシー名 フィールドにポリシーの名前を入力します。
  7. オプション: このポリシーが 1 つ以上の特定の Pod にのみ適用される場合は、特定の Pod のラベルとセレクターを指定できます。特定の Pod を選択しない場合、このポリシーはクラスター上のすべての Pod に適用されます。
  8. オプション: Deny all ingress traffic または Deny all egress traffic チェックボックスを使用して、すべてのイングレストラフィックとエグレストラフィックをブロックできます。
  9. イングレスルールとエグレスルールの任意の組み合わせを追加して、承認するポート、名前空間、または IP ブロックを指定することもできます。

  10. Ingress ルールをポリシーに追加します。

    1. Add ingress rule を選択して新規ルールを設定します。このアクションにより、受信トラフィックを制限する方法を指定できる Add allowed source ドロップダウンメニューを含む新しい Ingress ルール 行が作成されます。ドロップダウンメニューでは、Ingress トラフィックを制限する 3 つのオプションを利用できます。

      • Allow pods from the same namespace では、空間内の Pod へのトラフィックが制限されます。namespace に Pod を指定できますが、このオプションは空のままにすると namespace の Pod からのすべてのトラフィックを許可します。
      • Allow pods from inside the cluster では、ポリシーと同じクラスター内の Pod へのトラフィックが制限されます。インバウンドトラフィックを許可する名前空間と Pod を指定できます。このオプションを空白のままにすると、このクラスター内のすべての名前空間と Pod からのインバウンドトラフィックが許可されます。
      • IP ブロックによるピアの許可 は、指定された Classless Inter-Domain Routing (CIDR) IP ブロックからのトラフィックを制限します。例外オプションを使用して、特定の IP をブロックできます。CIDR フィールドを空白のままにすると、すべての外部ソースからのすべてのインバウンドトラフィックが許可されます。
    2. すべての受信トラフィックをポートに制限できます。ポートを追加しない場合、トラフィックはすべてのポートにアクセスできます。

  11. ネットワークポリシーにエグレスルールを追加します。

    1. Add egress rule 選択して、新しいルールを設定します。このアクションにより、送信トラフィックを制限する方法を指定できる Add allowed destination"* する * ドロップダウンメニューを含む新しい Egress rule 行が作成されます。ドロップダウンメニューには、下りトラフィックを制限する 3 つのオプションがあります。

      • Allow pods from the same namespace では、同じ namespace 内の Pod へのトラフィックが制限されます。namespace に Pod を指定できますが、このオプションは空のままにすると namespace の Pod からのすべてのトラフィックを許可します。
      • Allow pods from inside the cluster では、ポリシーと同じクラスター内の Pod へのトラフィックが制限されます。アウトバウンドトラフィックを許可する namespace および Pod を指定できます。このオプションを空白のままにすると、このクラスター内のすべての名前空間と Pod からのアウトバウンドトラフィックが許可されます。
      • Allow peers by IP block すると、指定された CIDR IP ブロックからのトラフィックが制限されます。例外オプションを使用して、特定の IP をブロックできます。CIDR フィールドを空白のままにすると、すべての外部ソースからのすべてのアウトバウンドが許可されます。
    2. すべてのアウトバウンドトラフィックをポートに制限できます。ポートを追加しない場合、トラフィックはすべてのポートにアクセスできます。

8.3. ネットワークポリシーの表示

admin ロールを持つユーザーは、namespace のネットワークポリシーを表示できます。

8.3.1. サンプル NetworkPolicy オブジェクト

以下は、サンプル NetworkPolicy オブジェクトにアノテーションを付けます。 

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-27107 1
spec:
  podSelector: 2
    matchLabels:
      app: mongodb
  ingress:
  - from:
    - podSelector: 3
        matchLabels:
          app: app
    ports: 4
    - protocol: TCP
      port: 27017
1
NetworkPolicy オブジェクトの名前。
2
ポリシーが適用される Pod を説明するセレクター。ポリシーオブジェクトは NetworkPolicy オブジェクトが定義されるプロジェクトの Pod のみを選択できます。
3
ポリシーオブジェクトが入力トラフィックを許可する Pod に一致するセレクター。セレクターは、NetworkPolicy と同じ namaspace にある Pod を照合して検索します。
4
トラフィックを受け入れる 1 つ以上の宛先ポートのリスト。

8.3.2. CLI を使用したネットワークポリシーの表示

namespace のネットワークポリシーを検査できます。

注記

cluster-admin ロールを持つユーザーでログインしている場合、クラスター内の任意のネットワークポリシーを表示できます。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • admin 権限を持つユーザーとしてクラスターにログインしている。
  • ネットワークポリシーが存在する namespace で作業している。

手順

  • namespace のネットワークポリシーを一覧表示します。

    • namespace で定義されたネットワークポリシーオブジェクトを表示するには、以下のコマンドを実行します。 

      $ oc get networkpolicy

    • オプション: 特定のネットワークポリシーを検査するには、以下のコマンドを入力します。 

      $ oc describe networkpolicy <policy_name> -n <namespace>

      ここでは、以下のようになります。

      <policy_name>
      検査するネットワークポリシーの名前を指定します。
      <namespace>
      オプション: オブジェクトが現在の namespace 以外の namespace に定義されている場合は namespace を指定します。

      以下に例を示します。 

      $ oc describe networkpolicy allow-same-namespace

      oc describe コマンドの出力

      Name:         allow-same-namespace
Namespace:    ns1
Created on:   2021-05-24 22:28:56 -0400 EDT
Labels:       <none>
Annotations:  <none>
Spec:
  PodSelector:     <none> (Allowing the specific traffic to all pods in this namespace)
  Allowing ingress traffic:
    To Port: <any> (traffic allowed to all ports)
    From:
      PodSelector: <none>
  Not affecting egress traffic
  Policy Types: Ingress

注記

cluster-admin 権限で Web コンソールにログインする場合、YAML で、または Web コンソールのフォームから、クラスターの任意の namespace でネットワークポリシーを直接表示できます。

8.3.3. OpenShift Cluster Manager を使用したネットワークポリシーの表示

Red Hat OpenShift Cluster Manager でネットワークポリシーの設定の詳細を表示できます。

前提条件

  • OpenShift Cluster Manager にログインしている。
  • Red Hat OpenShift Service on AWS クラスターを作成している。
  • クラスターにアイデンティティープロバイダーを設定している。
  • 設定したアイデンティティープロバイダーにユーザーアカウントを追加している。
  • ネットワークポリシーを作成しました。

手順

  1. OpenShift Cluster Manager Web コンソールの Administrator パースペクティブから、Networking の下にある NetworkPolicies をクリックします。
  2. 表示するネットワークポリシーを選択します。
  3. ネットワークポリシー の詳細ページで、関連付けられたすべての Ingress および egress ルールを表示できます。

  4. ネットワークポリシーの詳細で YAML を選択して、ポリシー設定を YAML 形式で表示します。

    注記

    これらのポリシーの詳細のみを表示できます。これらのポリシーは編集できません。

8.4. ネットワークポリシーの削除

admin ロールを持つユーザーは、namespace からネットワークポリシーを削除できます。

8.4.1. CLI を使用したネットワークポリシーの削除

namespace のネットワークポリシーを削除できます。

注記

cluster-admin ロールを持つユーザーでログインしている場合、クラスター内の任意のネットワークポリシーを削除できます。

前提条件

  • クラスターは、NetworkPolicy オブジェクトをサポートするネットワークプラグイン (mode: NetworkPolicy が設定された OVN-Kubernetes ネットワークプラグインや OpenShift SDN ネットワークプラグインなど) を使用します。このモードは OpenShiftSDN のデフォルトです。
  • OpenShift CLI (oc) がインストールされている。
  • admin 権限を持つユーザーとしてクラスターにログインしている。
  • ネットワークポリシーが存在する namespace で作業している。

手順

  • ネットワークポリシーオブジェクトを削除するには、以下のコマンドを入力します。 

    $ oc delete networkpolicy <policy_name> -n <namespace>

    ここでは、以下のようになります。

    <policy_name>
    ネットワークポリシーの名前を指定します。
    <namespace>
    オプション: オブジェクトが現在の namespace 以外の namespace に定義されている場合は namespace を指定します。

    出力例

    networkpolicy.networking.k8s.io/default-deny deleted

注記

cluster-admin 権限で Web コンソールにログインする場合、YAML で、または Web コンソールの Actions メニューのポリシーから、クラスターの任意の namespace でネットワークポリシーを直接削除できます。

8.4.2. OpenShift Cluster Manager を使用したネットワークポリシーの削除

namespace のネットワークポリシーを削除できます。

前提条件

  • OpenShift Cluster Manager にログインしている。
  • Red Hat OpenShift Service on AWS クラスターを作成している。
  • クラスターにアイデンティティープロバイダーを設定している。
  • 設定したアイデンティティープロバイダーにユーザーアカウントを追加している。

手順

  1. OpenShift Cluster Manager Web コンソールの Administrator パースペクティブから、Networking の下にある NetworkPolicies をクリックします。

  2. ネットワークポリシーを削除するには、次のいずれかの方法を使用します。

    • ネットワークポリシー テーブルからポリシーを削除します。

      1. ネットワークポリシー テーブルから、削除するネットワークポリシーの行にあるスタックメニューを選択し、ネットワークポリシーの 削除 をクリックします。

    • 個々のネットワークポリシーの詳細から アクション ドロップダウンメニューを使用してポリシーを削除します。

      1. ネットワークポリシーの アクション ドロップダウンメニューをクリックします。
      2. メニューから Delete NetworkPolicy を選択します。

8.5. ネットワークポリシーを使用したマルチテナント分離の設定

クラスター管理者は、マルチテナントネットワークの分離を実行するようにネットワークポリシーを設定できます。

注記

OpenShift SDN ネットワークプラグインを使用している場合、本セクションで説明されているようにネットワークポリシーを設定すると、マルチテナントモードと同様のネットワーク分離が行われますが、ネットワークポリシーモードが設定されます。

8.5.1. ネットワークポリシーを使用したマルチテナント分離の設定

他のプロジェクト namespace の Pod およびサービスから分離できるようにプロジェクトを設定できます。

前提条件

  • クラスターは、NetworkPolicy オブジェクトをサポートするネットワークプラグイン (mode: NetworkPolicy が設定された OVN-Kubernetes ネットワークプラグインや OpenShift SDN ネットワークプラグインなど) を使用します。このモードは OpenShiftSDN のデフォルトです。このモードは OpenShiftSDN のデフォルトです。
  • OpenShift CLI (oc) がインストールされている。
  • admin 権限を持つユーザーとしてクラスターにログインしている。

手順

  1. 以下の NetworkPolicy オブジェクトを作成します。

    1. allow-from-openshift-ingress という名前のポリシー: 

      $ cat << EOF| oc create -f -
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-openshift-ingress
spec:
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          policy-group.network.openshift.io/ingress: ""
  podSelector: {}
  policyTypes:
  - Ingress
EOF
      注記

      policy-group.network.openshift.io/ingress: ""は、OpenShift SDN の推奨の namespace セレクターラベルです。network.openshift.io/policy-group: ingress namespace セレクターラベルを使用できますが、これはレガシーラベルです。

    2. allow-from-openshift-monitoring という名前のポリシー。 

      $ cat << EOF| oc create -f -
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-openshift-monitoring
spec:
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          network.openshift.io/policy-group: monitoring
  podSelector: {}
  policyTypes:
  - Ingress
EOF

    3. allow-same-namespace という名前のポリシー: 

      $ cat << EOF| oc create -f -
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-same-namespace
spec:
  podSelector:
  ingress:
  - from:
    - podSelector: {}
EOF

    4. allow-from-kube-apiserver-operator という名前のポリシー: 

      $ cat << EOF| oc create -f -
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-kube-apiserver-operator
spec:
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: openshift-kube-apiserver-operator
      podSelector:
        matchLabels:
          app: kube-apiserver-operator
  policyTypes:
  - Ingress
EOF

      詳細は、新規の New kube-apiserver-operator webhook controller validating health of webhook を参照してください。

  2. オプション: 以下のコマンドを実行し、ネットワークポリシーオブジェクトが現在のプロジェクトに存在することを確認します。 

    $ oc describe networkpolicy

    出力例

    Name:         allow-from-openshift-ingress
Namespace:    example1
Created on:   2020-06-09 00:28:17 -0400 EDT
Labels:       <none>
Annotations:  <none>
Spec:
  PodSelector:     <none> (Allowing the specific traffic to all pods in this namespace)
  Allowing ingress traffic:
    To Port: <any> (traffic allowed to all ports)
    From:
      NamespaceSelector: network.openshift.io/policy-group: ingress
  Not affecting egress traffic
  Policy Types: Ingress


Name:         allow-from-openshift-monitoring
Namespace:    example1
Created on:   2020-06-09 00:29:57 -0400 EDT
Labels:       <none>
Annotations:  <none>
Spec:
  PodSelector:     <none> (Allowing the specific traffic to all pods in this namespace)
  Allowing ingress traffic:
    To Port: <any> (traffic allowed to all ports)
    From:
      NamespaceSelector: network.openshift.io/policy-group: monitoring
  Not affecting egress traffic
  Policy Types: Ingress

第9章 OVN-Kubernetes ネットワークプラグイン

9.1. egress IP アドレスの設定

クラスター管理者は、1 つ以上の egress IP アドレスを namespace に、または namespace 内の特定の pod に割り当てるように、OVN-Kubernetes の Container Network Interface (CNI) ネットワークプラグインを設定することができます。

9.1.1. Egress IP アドレスアーキテクチャーの設計および実装

Red Hat OpenShift Service on AWS の egress IP アドレス機能を使用すると、1 つ以上の namespace の 1 つ以上の Pod からのトラフィックに、クラスターネットワーク外のサービスに対する一貫したソース IP アドレスを持たせることができます。

たとえば、クラスター外のサーバーでホストされるデータベースを定期的にクエリーする Pod がある場合があります。サーバーにアクセス要件を適用するために、パケットフィルタリングデバイスは、特定の IP アドレスからのトラフィックのみを許可するよう設定されます。この特定の Pod のみからサーバーに確実にアクセスできるようにするには、サーバーに要求を行う Pod に特定の egress IP アドレスを設定できます。

namespace に割り当てられた egress IP アドレスは、特定の宛先にトラフィックを送信するために使用されるスロールーターとは異なります。

ROSA with HCP では、アプリケーション Pod と ingress ルーター Pod が同じノード上で実行されます。このシナリオでアプリケーションプロジェクトの Egress IP アドレスを設定する場合、アプリケーションプロジェクトからルートに要求を送信するときに IP アドレスは使用されません。

重要

EgressIP 機能を持つコントロールプレーンノードへの egress IP アドレスの割り当てはサポートされていません。

次の例は、いくつかのパブリッククラウドプロバイダーのノードからのアノテーションを示しています。アノテーションは、読みやすくするためにインデントされています。

AWS での cloud.network.openshift.io/egress-ipconfig アノテーションの例

cloud.network.openshift.io/egress-ipconfig: [
  {
    "interface":"eni-078d267045138e436",
    "ifaddr":{"ipv4":"10.0.128.0/18"},
    "capacity":{"ipv4":14,"ipv6":15}
  }
]

次のセクションでは、容量計算で使用するためにサポートされているパブリッククラウド環境の IP アドレス容量を説明します。

9.1.1.1. Amazon Web Services (AWS) の IP アドレス容量の制限

AWS では、IP アドレスの割り当てに関する制約は、設定されているインスタンスタイプによって異なります。詳細は、IP addresses per network interface per instance type を参照してください。

9.1.1.2. egress IP の Pod への割り当て

1 つ以上の egress IP を namespace に、または namespace の特定の Pod に割り当てるには、以下の条件を満たす必要があります。

  • クラスター内の 1 つ以上のノードに k8s.ovn.org/egress-assignable: "" ラベルがなければなりません。
  • EgressIP オブジェクトが存在し、これは namespace の Pod からクラスターを離脱するトラフィックのソース IP アドレスとして使用する 1 つ以上の egress IP アドレスを定義します。
重要

egress IP の割り当て用にクラスター内のノードにラベルを付ける前に EgressIP オブジェクトを作成する場合、Red Hat OpenShift Service on AWS は k8s.ovn.org/egress-assignable: "" ラベルですべての egress IP アドレスを最初のノードに割り当てる可能性があります。

egress IP アドレスがクラスター内のノード全体に広く分散されるようにするには、EgressIP オブジェクトを作成する前に、egress IP アドレスをホストする予定のノードにラベルを常に適用します。

9.1.1.3. egress IP のノードへの割り当て

EgressIP オブジェクトを作成する場合、k8s.ovn.org/egress-assignable: "" ラベルのラベルが付いたノードに以下の条件が適用されます。

  • egress IP アドレスは一度に複数のノードに割り当てられることはありません。
  • egress IP アドレスは、egress IP アドレスをホストできる利用可能なノード間で均等に分散されます。

  • EgressIP オブジェクトの spec.EgressIPs 配列が複数の IP アドレスを指定する場合は、以下の条件が適用されます。

    • 指定された IP アドレスを複数ホストするノードはありません。
    • トラフィックは、指定された namespace の指定された IP アドレス間でほぼ均等に分散されます。
  • ノードが利用不可の場合、そのノードに割り当てられる egress IP アドレスは自動的に再割り当てされます (前述の条件が適用されます)。

Pod が複数の EgressIP オブジェクトのセレクターに一致する場合、EgressIP オブジェクトに指定される egress IP アドレスのどれが Pod の egress IP アドレスとして割り当てられるのかという保証はありません。

さらに、EgressIP オブジェクトが複数の送信 IP アドレスを指定する場合、どの送信 IP アドレスが使用されるかは保証されません。たとえば、Pod が 10.10.20.1 と 10.10.20.2 の 2 つの egress IP アドレスを持つ EgressIP オブジェクトのセレクターと一致する場合、各 TCP 接続または UDP 会話にいずれかが使用される可能性があります。

9.1.1.4. egress IP アドレス設定のアーキテクチャー図

以下の図は、egress IP アドレス設定を示しています。この図では、クラスターの 3 つのノードで実行される 2 つの異なる namespace の 4 つの Pod について説明します。ノードには、ホストネットワークの 192.168.126.0/18 CIDR ブロックから IP アドレスが割り当てられます。

ノード 1 とノード 3 の両方に k8s.ovn.org/egress-assignable: "" というラベルが付けられるため、egress IP アドレスの割り当てに利用できます。

図の破線は、pod1、pod2、および pod3 からのトラフィックフローが Pod ネットワークを通過し、クラスターがノード 1 およびノード 3 から出る様子を示しています。外部サービスが、EgressIP オブジェクトの例で選択した Pod からトラフィックを受信する場合、ソース IP アドレスは 192.168.126.10 または 192.168.126.102 のいずれかになります。トラフィックはこれらの 2 つのノード間でほぼ均等に分散されます。

図にある次のリソースの詳細を以下に示します。

Namespace オブジェクト

namespace は以下のマニフェストで定義されます。

namespace オブジェクト

apiVersion: v1
kind: Namespace
metadata:
  name: namespace1
  labels:
    env: prod
---
apiVersion: v1
kind: Namespace
metadata:
  name: namespace2
  labels:
    env: prod

EgressIP オブジェクト

以下の EgressIP オブジェクトは、env ラベルが prod に設定される namespace のすべての Pod を選択する設定を説明しています。選択された Pod の egress IP アドレスは 192.168.126.10 および 192.168.126.102 です。

EgressIP オブジェクト

apiVersion: k8s.ovn.org/v1
kind: EgressIP
metadata:
  name: egressips-prod
spec:
  egressIPs:
  - 192.168.126.10
  - 192.168.126.102
  namespaceSelector:
    matchLabels:
      env: prod
status:
  items:
  - node: node1
    egressIP: 192.168.126.10
  - node: node3
    egressIP: 192.168.126.102

前述の例の設定では、Red Hat OpenShift Service on AWS は両方の egress IP アドレスを使用可能なノードに割り当てます。status フィールドは、egress IP アドレスの割り当ての有無および割り当てられる場所を反映します。

9.1.2. EgressIP オブジェクト

以下の YAML は、EgressIP オブジェクトの API について説明しています。オブジェクトの範囲はクラスター全体です。これは namespace では作成されません。 

apiVersion: k8s.ovn.org/v1
kind: EgressIP
metadata:
  name: <name> 1
spec:
  egressIPs: 2
  - <ip_address>
  namespaceSelector: 3
    ...
  podSelector: 4
    ...
1
EgressIPs オブジェクトの名前。
2
1 つ以上の IP アドレスの配列。
3
egress IP アドレスを関連付ける namespace の 1 つ以上のセレクター。
4
オプション: egress IP アドレスを関連付けるための指定された namespace の Pod の 1 つ以上のセレクター。これらのセレクターを適用すると、namespace 内の Pod のサブセットを選択できます。

以下の YAML は namespace セレクターのスタンザについて説明しています。

namespace セレクタースタンザ

namespaceSelector: 1
  matchLabels:
    <label_name>: <label_value>

1
namespace の 1 つ以上のマッチングルール。複数のマッチングルールを指定すると、一致するすべての namespace が選択されます。

以下の YAML は Pod セレクターのオプションのスタンザについて説明しています。

Pod セレクタースタンザ

podSelector: 1
  matchLabels:
    <label_name>: <label_value>

1
オプション: 指定された namespaceSelector ルールに一致する、namespace の Pod の 1 つ以上のマッチングルール。これが指定されている場合、一致する Pod のみが選択されます。namespace の他の Pod は選択されていません。

以下の例では、EgressIP オブジェクトは 192.168.126.11 および 192.168.126.102 egress IP アドレスを、app ラベルが web に設定されており、env ラベルが prod に設定されている namespace にある Pod に関連付けます。

EgressIP オブジェクトの例

apiVersion: k8s.ovn.org/v1
kind: EgressIP
metadata:
  name: egress-group1
spec:
  egressIPs:
  - 192.168.126.11
  - 192.168.126.102
  podSelector:
    matchLabels:
      app: web
  namespaceSelector:
    matchLabels:
      env: prod

以下の例では、EgressIP オブジェクトは、192.168.127.30 および 192.168.127.40 egress IP アドレスを、environment ラベルが development に設定されていない Pod に関連付けます。

EgressIP オブジェクトの例

apiVersion: k8s.ovn.org/v1
kind: EgressIP
metadata:
  name: egress-group2
spec:
  egressIPs:
  - 192.168.127.30
  - 192.168.127.40
  namespaceSelector:
    matchExpressions:
    - key: environment
      operator: NotIn
      values:
      - development

9.1.3. egress IP アドレスをホストするノードのラベル付け

Red Hat OpenShift Service on AWS が 1 つ以上の egress IP アドレスをノードに割り当てることができるように、k8s.ovn.org/egress-assignable="" ラベルをクラスター内のノードに適用できます。

前提条件

  • ROSA CLI (rosa) をインストールしている。
  • クラスター管理者としてクラスターにログインしている。

手順

  • 1 つ以上の egress IP アドレスをホストできるようにノードにラベルを付けるには、以下のコマンドを入力します。 

    $ rosa edit machinepool <machinepool_name> --cluster=<cluster_name> --labels "k8s.ovn.org/egress-assignable="
    重要

    このコマンドは、マシンプール上の既存のノードラベルをすべて置き換えます。既存のノードラベルを確実に保持するには、必要なラベルを --labels フィールドに含める必要があります。

9.1.4. 次のステップ

9.1.5. 関連情報

第10章 ルートの作成

10.1. ルート設定

10.1.1. HTTP ベースのルートの作成

ルートを使用すると、公開された URL でアプリケーションをホストできます。これは、アプリケーションのネットワークセキュリティー設定に応じて、セキュリティー保護または保護なしを指定できます。HTTP ベースのルートとは、セキュアではないルートで、基本的な HTTP ルーティングプロトコルを使用してセキュリティー保護されていないアプリケーションポートでサービスを公開します。

以下の手順では、hello-openshift アプリケーションを例に、Web アプリケーションへのシンプルな HTTP ベースのルートを作成する方法を説明します。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • 管理者としてログインしている。
  • あるポートを公開する Web アプリケーションと、そのポートでトラフィックをリッスンする TCP エンドポイントがあります。

手順

  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

検証

  • 作成した route リソースを確認するには、次のコマンドを実行します。 

    $ oc get routes -o yaml <name of resource> 1
    1
    この例では、ルートの名前は hello-openshift です。

上記で作成されたセキュアでないルートの YAML 定義

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: hello-openshift
spec:
  host: hello-openshift-hello-openshift.<Ingress_Domain> 1
  port:
    targetPort: 8080 2
  to:
    kind: Service
    name: hello-openshift

1
&lt;Ingress_Domain&gt; はデフォルトの Ingress ドメイン名です。ingresses.config/cluster オブジェクトはインストール中に作成され、変更できません。別のドメインを指定する場合は、appsDomain オプションを使用して別のクラスタードメインを指定できます。
2
targetPort は、このルートが指すサービスによって選択される Pod のターゲットポートです。
注記

デフォルトの ingress ドメインを表示するには、以下のコマンドを実行します。 

$ oc get ingresses.config/cluster -o jsonpath={.spec.domain}

10.1.2. ルートのタイムアウトの設定

Service Level Availability (SLA) で必要とされる、低タイムアウトが必要なサービスや、バックエンドでの処理速度が遅いケースで高タイムアウトが必要なサービスがある場合は、既存のルートに対してデフォルトのタイムアウトを設定することができます。

前提条件

  • 実行中のクラスターでデプロイ済みの Ingress Controller が必要になります。

手順

  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

10.1.3. HTTP Strict Transport Security

HTTP Strict Transport Security (HSTS) ポリシーは、HTTPS トラフィックのみがルートホストで許可されるブラウザークライアントに通知するセキュリティーの拡張機能です。また、HSTS は、HTTP リダイレクトを使用せずに HTTPS トランスポートにシグナルを送ることで Web トラフィックを最適化します。HSTS は Web サイトとの対話を迅速化するのに便利です。

HSTS ポリシーが適用されると、HSTS はサイトから Strict Transport Security ヘッダーを HTTP および HTTPS 応答に追加します。HTTP を HTTPS にリダイレクトするルートで insecureEdgeTerminationPolicy 値を使用できます。HSTS を強制している場合は、要求の送信前にクライアントがすべての要求を HTTP URL から HTTPS に変更するため、リダイレクトの必要がなくなります。

クラスター管理者は、以下を実行するために HSTS を設定できます。

  • ルートごとに HSTS を有効にします。
  • ルートごとに HSTS を無効にします。
  • ドメインごとに HSTS を適用するか、ドメインと組み合わせた namespace ラベルを使用します。
重要

HSTS はセキュアなルート (edge-termination または re-encrypt) でのみ機能します。この設定は、HTTP またはパススルールートには適していません。

10.1.3.1. ルートごとの HTTP Strict Transport Security の有効化

HTTP 厳密なトランスポートセキュリティー (HSTS) は HAProxy テンプレートに実装され、haproxy.router.openshift.io/hsts_header アノテーションを持つ edge および re-encrypt ルートに適用されます。

前提条件

  • プロジェクトの管理者権限があるユーザーで、クラスターにログインしている。
  • oc CLI をインストールした。

手順

  • ルートで HSTS を有効にするには、haproxy.router.openshift.io/hsts_header 値を edge-termed または re-encrypt ルートに追加します。これを実行するには、oc annotate ツールを使用してこれを実行できます。 

    $ oc annotate route <route_name> -n <namespace> --overwrite=true "haproxy.router.openshift.io/hsts_header"="max-age=31536000;\ 1
includeSubDomains;preload"
    1
    この例では、最長期間は 31536000 ミリ秒 (約 8 時間および半分) に設定されます。
    注記

    この例では、等号 (=) が引用符で囲まれています。これは、annotate コマンドを正しく実行するために必要です。

    アノテーションで設定されたルートの例

    apiVersion: route.openshift.io/v1
kind: Route
metadata:
  annotations:
    haproxy.router.openshift.io/hsts_header: max-age=31536000;includeSubDomains;preload 1 2 3
...
spec:
  host: def.abc.com
  tls:
    termination: "reencrypt"
    ...
  wildcardPolicy: "Subdomain"

    1
    必須。max-age は、HSTS ポリシーが有効な期間 (秒単位) を測定します。0 に設定すると、これはポリシーを無効にします。
    2
    オプション: includeSubDomains は、クライアントに対し、ホストのすべてのサブドメインにホストと同じ HSTS ポリシーを持つ必要があることを指示します。
    3
    オプション: max-age が 0 より大きい場合、preload を haproxy.router.openshift.io/hsts_header に追加し、外部サービスがこのサイトをそれぞれの HSTS プリロードリストに含めることができます。たとえば、Google などのサイトは preload が設定されているサイトの一覧を作成します。ブラウザーはこれらのリストを使用し、サイトと対話する前でも HTTPS 経由で通信できるサイトを判別できます。preload を設定していない場合、ブラウザーはヘッダーを取得するために、HTTPS を介してサイトと少なくとも 1 回対話している必要があります。

10.1.3.2. ルートごとの HTTP Strict Transport Security の無効化

ルートごとに HSTS (HTTP Strict Transport Security) を無効にするには、ルートアノテーションの max-age の値を 0 に設定します。

前提条件

  • プロジェクトの管理者権限があるユーザーで、クラスターにログインしている。
  • oc CLI をインストールした。

手順

  • HSTS を無効にするには、以下のコマンドを入力してルートアノテーションの max-age の値を 0 に設定します。 

    $ oc annotate route <route_name> -n <namespace> --overwrite=true "haproxy.router.openshift.io/hsts_header"="max-age=0"
    ヒント

    または、以下の YAML を適用して ConfigMap を作成できます。

    ルートごとに HSTS を無効にする例

    metadata:
  annotations:
    haproxy.router.openshift.io/hsts_header: max-age=0

  • namespace のすべてのルートで HSTS を無効にするには、following コマンドを入力します。 

    $ oc annotate route --all -n <namespace> --overwrite=true "haproxy.router.openshift.io/hsts_header"="max-age=0"

検証

  1. すべてのルートのアノテーションをクエリーするには、以下のコマンドを入力します。 

    $ oc get route  --all-namespaces -o go-template='{{range .items}}{{if .metadata.annotations}}{{$a := index .metadata.annotations "haproxy.router.openshift.io/hsts_header"}}{{$n := .metadata.name}}{{with $a}}Name: {{$n}} HSTS: {{$a}}{{"\n"}}{{else}}{{""}}{{end}}{{end}}{{end}}'

    出力例

    Name: routename HSTS: max-age=0

10.1.4. Cookie の使用によるルートのステートフル性の維持

Red Hat OpenShift Service on AWS は、すべてのトラフィックを同じエンドポイントにヒットさせることによりステートフルなアプリケーションのトラフィックを可能にするスティッキーセッションを提供します。ただし、エンドポイント Pod が再起動、スケーリング、または設定の変更などによって終了する場合、このステートフル性はなくなります。

Red Hat OpenShift Service on AWS は Cookie を使用してセッションの永続化を設定できます。Ingress コントローラーはユーザー要求を処理するエンドポイントを選択し、そのセッションの Cookie を作成します。Cookie は要求の応答として戻され、ユーザーは Cookie をセッションの次の要求と共に送り返します。Cookie は Ingress Controller に対し、セッションを処理しているエンドポイントを示し、クライアント要求が Cookie を使用して同じ Pod にルーティングされるようにします。

注記

cookie は、HTTP トラフィックを表示できないので、パススルールートで設定できません。代わりに、ソース IP アドレスをベースに数が計算され、バックエンドを判断します。

バックエンドが変わると、トラフィックが間違ったサーバーに転送されてしまい、スティッキーではなくなります。ソース IP を非表示にするロードバランサーを使用している場合は、すべての接続に同じ番号が設定され、トラフィックは同じ Pod に送られます。

10.1.5. パスベースのルート

パスベースのルートは、URL に対して比較できるパスコンポーネントを指定します。この場合、ルートのトラフィックは HTTP ベースである必要があります。そのため、それぞれが異なるパスを持つ同じホスト名を使用して複数のルートを提供できます。ルーターは、最も具体的なパスの順に基づいてルートと一致する必要があります。ただし、これはルーターの実装によって異なります。

以下の表は、ルートのサンプルおよびそれらのアクセシビリティーを示しています。

表10.1 ルートの可用性

ルート比較対象アクセス可能

www.example.com/test

www.example.com/test

はい

www.example.com

いいえ

www.example.com/test および www.example.com

www.example.com/test

はい

www.example.com

はい

www.example.com

www.example.com/text

Yes (ルートではなく、ホストで一致)

www.example.com

はい

パスが 1 つでセキュリティー保護されていないルート

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: route-unsecured
spec:
  host: www.example.com
  path: "/test" 1
  to:
    kind: Service
    name: service-name

1
パスは、パスベースのルートに唯一追加される属性です。
注記

ルーターは TLS を終了させず、要求のコンテンツを読み込みことができないので、パスベースのルーティングは、パススルー TLS を使用する場合には利用できません。

10.1.6. HTTP ヘッダーの設定

Red Hat OpenShift Service on AWS は、HTTP ヘッダーを操作するさまざまな方法を提供します。ヘッダーを設定または削除する場合、Ingress Controller の特定のフィールドまたは個々のルートを使用して、リクエストヘッダーと応答ヘッダーを変更できます。ルートアノテーションを使用して特定のヘッダーを設定することもできます。ヘッダーを設定するさまざまな方法は、連携時に課題となる可能性があります。

注記

IngressController または Route CR 内のヘッダーは設定または削除のみ可能で、追加はできません。HTTP ヘッダーに値が設定されている場合、その値は完全である必要があるため、今後追加する必要はありません。X-Forwarded-For ヘッダーなどのヘッダーを追加することが適切な状況では、spec.httpHeaders.actions の代わりに spec.httpHeaders.forwardedHeaderPolicy フィールドを使用します。

10.1.6.1. 優先順位

同じ HTTP ヘッダーを Ingress Controller とルートの両方で変更すると、HAProxy は、それがリクエストヘッダーであるか応答ヘッダーであるかに応じて、特定の方法でアクションの優先順位を付けます。

  • HTTP 応答ヘッダーの場合、Ingress Controller で指定されたアクションは、ルートで指定されたアクションの後に実行されます。これは、Ingress Controller で指定されたアクションが優先されることを意味します。
  • HTTP リクエストヘッダーの場合、ルートで指定されたアクションは、Ingress Controller で指定されたアクションの後に実行されます。これは、ルートで指定されたアクションが優先されることを意味します。

たとえば、クラスター管理者は、次の設定を使用して、Ingress Controller で X-Frame-Options 応答ヘッダーに値 DENY を設定します。

IngressController 仕様の例

apiVersion: operator.openshift.io/v1
kind: IngressController
# ...
spec:
  httpHeaders:
    actions:
      response:
      - name: X-Frame-Options
        action:
          type: Set
          set:
            value: DENY

ルート所有者は、クラスター管理者が Ingress Controller に設定したものと同じ応答ヘッダーを設定しますが、次の設定を使用して値 SAMEORIGIN を設定します。

Route 仕様の例

apiVersion: route.openshift.io/v1
kind: Route
# ...
spec:
  httpHeaders:
    actions:
      response:
      - name: X-Frame-Options
        action:
          type: Set
          set:
            value: SAMEORIGIN

IngressController 仕様と Route 仕様の両方で X-Frame-Options ヘッダーを設定している場合、特定のルートでフレームが許可されている場合でも、Ingress Controller のグローバルレベルでこのヘッダーに設定された値が優先されます。

この優先順位付けは、haproxy.config ファイルが次のロジックを使用するために発生します。このロジックでは、Ingress Controller がフロントエンドとみなされ、個々のルートがバックエンドとみなされます。フロントエンド設定に適用されるヘッダー値 DENY は、バックエンドで設定されている値 SAMEORIGIN で同じヘッダーをオーバーライドします。 

frontend public
  http-response set-header X-Frame-Options 'DENY'

frontend fe_sni
  http-response set-header X-Frame-Options 'DENY'

frontend fe_no_sni
  http-response set-header X-Frame-Options 'DENY'

backend be_secure:openshift-monitoring:alertmanager-main
  http-response set-header X-Frame-Options 'SAMEORIGIN'

さらに、Ingress Controller またはルートのいずれかで定義されたアクションは、ルートアノテーションを使用して設定された値をオーバーライドします。

10.1.6.2. 特殊なケースのヘッダー

次のヘッダーは、設定または削除が完全に禁止されているか、特定の状況下で許可されています。

表10.2 特殊な場合のヘッダー設定オプション

ヘッダー名IngressController 仕様を使用して設定可能かどうかRoute 仕様を使用して設定可能かどうか不許可の理由別の方法で設定可能かどうか

proxy

いいえ

いいえ

プロキシー HTTP リクエストヘッダーを使用して、ヘッダー値を HTTP_PROXY 環境変数に挿入して、脆弱な CGI アプリケーションを悪用できます。プロキシー HTTP リクエストヘッダーも標準ではないため、設定中にエラーが発生しやすくなります。

いいえ

host

いいえ

はい

IngressController CR を使用して ホスト HTTP 要求ヘッダーが設定されている場合、HAProxy は正しいルートを検索するときに失敗する可能性があります。

いいえ

strict-transport-security

いいえ

いいえ

strict-transport-security HTTP 応答ヘッダーはルートアノテーションを使用してすでに処理されているため、別の実装は必要ありません。

はい: haproxy.router.openshift.io/hsts_header ルートアノテーション

cookie と set-cookie

いいえ

いいえ

HAProxy が設定する Cookie は、クライアント接続を特定のバックエンドサーバーにマップするセッション追跡に使用されます。これらのヘッダーの設定を許可すると、HAProxy のセッションアフィニティーが妨げられ、HAProxy の Cookie の所有権が制限される可能性があります。

はい:

  • haproxy.router.openshift.io/disable_cookie ルートアノテーション
  • haproxy.router.openshift.io/cookie_name ルートアノテーション

10.1.7. ルート内の HTTP リクエストおよびレスポンスヘッダーの設定または削除

コンプライアンス目的またはその他の理由で、特定の HTTP 要求および応答ヘッダーを設定または削除できます。これらのヘッダーは、Ingress Controller によって提供されるすべてのルート、または特定のルートに対して設定または削除できます。

たとえば、ルートを提供する Ingress Controller によってデフォルトのグローバルな場所が指定されている場合でも、コンテンツが複数の言語で記述されていると、Web アプリケーションが特定のルートの別の場所でコンテンツを提供するように指定できます。

以下の手順では Content-Location HTTP リクエストヘッダーを設定するルートを作成し、アプリケーション (https://app.example.com) に URL が関連付けられ、https://app.example.com/lang/en-us のロケーションにダイレクトされるようにします。アプリケーショントラフィックをこの場所にダイレクトすると、特定のルートを使用する場合はすべて、アメリカ英語で記載された Web コンテンツにアクセスすることになります。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • プロジェクト管理者として Red Hat OpenShift Service on AWS クラスターにログインしている。
  • あるポートを公開する Web アプリケーションと、そのポートでトラフィックをリッスンする HTTP または TCP エンドポイントがある。

手順

  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

HTTP リクエストヘッダーの場合、ルート定義で指定されたアクションは、Ingress Controller の HTTP リクエストヘッダーに対して実行されたアクションの後に実行されます。これは、ルート内のこれらのリクエストヘッダーに設定された値が、Ingress Controller に設定された値よりも優先されることを意味します。HTTP ヘッダーの処理順序の詳細は、HTTP ヘッダーの設定 を参照してください。

10.1.8. ルート固有のアノテーション

Ingress Controller は、公開するすべてのルートのデフォルトオプションを設定できます。個別のルートは、アノテーションに個別の設定を指定して、デフォルトの一部を上書きできます。Red Hat では、ルートアノテーションの Operator 管理ルートへの追加はサポートしません。

重要

複数のソース IP またはサブネットのホワイトリストを作成するには、スペースで区切られたリストを使用します。他の区切りタイプを使用すると、リストが警告やエラーメッセージなしに無視されます。

表10.3 ルートアノテーション

変数説明デフォルトで使用される環境変数

haproxy.router.openshift.io/balance

ロードバランシングアルゴリズムを設定します。使用できるオプションは、random、 source、roundrobin、および leastconn です。デフォルト値は、TLS パススルールートの場合、source です。他のすべてのルートの場合、デフォルトは random です。

パススルールートの ROUTER_TCP_BALANCE_SCHEME です。それ以外の場合は ROUTER_LOAD_BALANCE_ALGORITHM を使用します。

haproxy.router.openshift.io/disable_cookies

関連の接続を追跡する cookie の使用を無効にします。'true' または 'TRUE' に設定する場合は、分散アルゴリズムを使用して、受信する HTTP 要求ごとに、どのバックエンドが接続を提供するかを選択します。

 

router.openshift.io/cookie_name

このルートに使用するオプションの cookie を指定します。名前は、大文字、小文字、数字、"_" または "-" を任意に組み合わせて指定する必要があります。デフォルトは、ルートのハッシュ化された内部キー名です。

 

haproxy.router.openshift.io/pod-concurrent-connections

ルーターからバッキングされる Pod に対して許容される接続最大数を設定します。
注意: Pod が複数ある場合には、それぞれに対応する接続数を設定できます。複数のルーターがある場合は、それらのルーター間で調整は行われず、それぞれがこれに複数回接続する可能性があります。設定されていない場合または 0 に設定されている場合には制限はありません。

 

haproxy.router.openshift.io/rate-limit-connections

'true' または 'TRUE' を設定すると、ルートごとに特定のバックエンドの stick-tables で実装されるレート制限機能が有効になります。
注記: このアノテーションを使用すると、サービス拒否攻撃に対する基本的な保護が提供されます。

 

haproxy.router.openshift.io/rate-limit-connections.concurrent-tcp

同じソース IP アドレスで行われる同時 TCP 接続の数を制限します。数値を受け入れます。
注記: このアノテーションを使用すると、サービス拒否攻撃に対する基本的な保護が提供されます。

 

haproxy.router.openshift.io/rate-limit-connections.rate-http

同じソース IP アドレスを持つクライアントが HTTP 要求を実行できるレートを制限します。数値を受け入れます。
注記: このアノテーションを使用すると、サービス拒否攻撃に対する基本的な保護が提供されます。

 

haproxy.router.openshift.io/rate-limit-connections.rate-tcp

同じソース IP アドレスを持つクライアントが TCP 接続を確立するレートを制限します。数値を受け入れます。
注記: このアノテーションを使用すると、サービス拒否攻撃に対する基本的な保護が提供されます。

 

haproxy.router.openshift.io/timeout

ルートのサーバー側のタイムアウトを設定します。(TimeUnits)

ROUTER_DEFAULT_SERVER_TIMEOUT

haproxy.router.openshift.io/timeout-tunnel

このタイムアウトは、クリアテキスト、エッジ、再暗号化、またはパススルーのルートを介した Web Socket などトンネル接続に適用されます。cleartext、edge、または reencrypt のルートタイプでは、このアノテーションは、タイムアウト値がすでに存在するタイムアウトトンネルとして適用されます。パススルーのルートタイプでは、アノテーションは既存のタイムアウト値の設定よりも優先されます。

ROUTER_DEFAULT_TUNNEL_TIMEOUT

ingresses.config/cluster ingress.operator.openshift.io/hard-stop-after

設定できるのは、Ingress Controller または ingress config です。このアノテーションでは、ルーターを再デプロイし、HA プロキシーが haproxyhard-stop-after グローバルオプションを実行するように設定します。このオプションは、クリーンなソフトストップ実行で最大許容される時間を定義します。

ROUTER_HARD_STOP_AFTER

router.openshift.io/haproxy.health.check.interval

バックエンドのヘルスチェックの間隔を設定します。(TimeUnits)

ROUTER_BACKEND_CHECK_INTERVAL

haproxy.router.openshift.io/ip_whitelist

ルートの許可リストを設定します。許可リストは、承認したソースアドレスの IP アドレスおよび CIDR 範囲のリストをスペース区切りにしたリストです。許可リストに含まれていない IP アドレスからの要求は破棄されます。

haproxy.config ファイルで直接表示される IP アドレスと CIDR 範囲の最大数は 61 です [1]。

 

haproxy.router.openshift.io/hsts_header

edge terminated または re-encrypt ルートの Strick-Transport-Security ヘッダーを設定します。

 

haproxy.router.openshift.io/rewrite-target

バックエンドの要求の書き換えパスを設定します。

 

router.openshift.io/cookie-same-site

Cookie を制限するために値を設定します。値は以下のようになります。

Lax: ブラウザーは、クロスサイト要求では Cookie を送信しませんが、ユーザーが外部サイトから元のサイトに移動するときに Cookie を送信します。これは、SameSite 値が指定されていない場合のブラウザーのデフォルトの動作です。

Strict: ブラウザーは、同じサイトのリクエストに対してのみ Cookie を送信します。

None: ブラウザーは、クロスサイト要求と同一サイト要求の両方に対して Cookie を送信します。

この値は、re-encrypt および edge ルートにのみ適用されます。詳細は、SameSite cookie のドキュメント を参照してください。

 

haproxy.router.openshift.io/set-forwarded-headers

ルートごとに Forwarded および X-Forwarded-For HTTP ヘッダーを処理するポリシーを設定します。値は以下のようになります。

append: ヘッダーを追加し、既存のヘッダーを保持します。これはデフォルト値です。

Replace: ヘッダーを設定し、既存のヘッダーを削除します。

never: ヘッダーを設定しませんが、既存のヘッダーを保持します。

if-none: ヘッダーがまだ設定されていない場合にこれを設定します。

ROUTER_SET_FORWARDED_HEADERS

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

    注記

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

注記

環境変数を編集することはできません。

ルータータイムアウト変数

TimeUnits は数字、その後に単位を指定して表現します。 us *(マイクロ秒)、ms (ミリ秒、デフォルト)、s (秒)、m (分)、h *(時間)、d (日)

正規表現: [1-9][0-9]*(us\|ms\|s\|m\|h\|d)

変数デフォルト説明

ROUTER_BACKEND_CHECK_INTERVAL

5000ms

バックエンドでの後続の liveness チェックの時間の長さ。

ROUTER_CLIENT_FIN_TIMEOUT

1s

クライアントがルートに接続する場合の TCP FIN タイムアウトの期間を制御します。接続切断のために送信された FIN が指定の時間内に応答されない場合は、HAProxy が接続を切断します。小さい値を設定し、ルーターでリソースをあまり使用していない場合には、リスクはありません。

ROUTER_DEFAULT_CLIENT_TIMEOUT

30s

クライアントがデータを確認するか、送信するための時間の長さ。

ROUTER_DEFAULT_CONNECT_TIMEOUT

5s

最大接続時間。

ROUTER_DEFAULT_SERVER_FIN_TIMEOUT

1s

ルーターからルートをバッキングする Pod の TCP FIN タイムアウトを制御します。

ROUTER_DEFAULT_SERVER_TIMEOUT

30s

サーバーがデータを確認するか、送信するための時間の長さ。

ROUTER_DEFAULT_TUNNEL_TIMEOUT

1h

TCP または WebSocket 接続が開放された状態で保つ時間数。このタイムアウト期間は、HAProxy が再読み込みされるたびにリセットされます。

ROUTER_SLOWLORIS_HTTP_KEEPALIVE

300s

新しい HTTP 要求が表示されるまで待機する最大時間を設定します。この値が低すぎる場合には、ブラウザーおよびアプリケーションの keepalive 値が低くなりすぎて、問題が発生する可能性があります。

有効なタイムアウト値には、想定した個別のタイムアウトではなく、特定の変数を合計した値に指定することができます。たとえば、ROUTER_SLOWLORIS_HTTP_KEEPALIVE は、timeout http-keep-alive を調整します。HAProxy はデフォルトで 300s に設定されていますが、HAProxy は tcp-request inspect-delay も待機します。これは 5s に設定されています。この場合、全体的なタイムアウトは 300s に 5s を加えたことになります。

ROUTER_SLOWLORIS_TIMEOUT

10s

HTTP 要求の伝送にかかる時間。

RELOAD_INTERVAL

5s

ルーターがリロードし、新規の変更を受け入れる最小の頻度を許可します。

ROUTER_METRICS_HAPROXY_TIMEOUT

5s

HAProxy メトリクスの収集タイムアウト。

ルート設定のカスタムタイムアウト

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  annotations:
    haproxy.router.openshift.io/timeout: 5500ms 1
...

1
HAProxy 対応の単位 (us、ms、s、 m、h、d) で新規のタイムアウトを指定します。単位が指定されていない場合は、ms がデフォルトになります。
注記

パススルールートのサーバー側のタイムアウト値を低く設定し過ぎると、WebSocket 接続がそのルートで頻繁にタイムアウトする可能性があります。

特定の IP アドレスを 1 つだけ許可するルート

metadata:
  annotations:
    haproxy.router.openshift.io/ip_whitelist: 192.168.1.10

複数の IP アドレスを許可するルート

metadata:
  annotations:
    haproxy.router.openshift.io/ip_whitelist: 192.168.1.10 192.168.1.11 192.168.1.12

IP アドレスの CIDR ネットワークを許可するルート

metadata:
  annotations:
    haproxy.router.openshift.io/ip_whitelist: 192.168.1.0/24

IP アドレスと IP アドレスの CIDR ネットワークの両方を許可するルート

metadata:
  annotations:
    haproxy.router.openshift.io/ip_whitelist: 180.5.61.153 192.168.1.0/24 10.0.0.0/8

書き換えターゲットを指定するルート

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  annotations:
    haproxy.router.openshift.io/rewrite-target: / 1
...

1
バックエンドの要求の書き換えパスとして / を設定します。

ルートに haproxy.router.openshift.io/rewrite-target アノテーションを設定すると、要求をバックエンドアプリケーションに転送する前に Ingress Controller がこのルートを使用して HTTP 要求のパスを書き換える必要があることを指定します。spec.path で指定されたパスに一致する要求パスの一部は、アノテーションで指定された書き換えターゲットに置き換えられます。

以下の表は、spec.path、要求パス、および書き換えターゲットの各種の組み合わせについてのパスの書き換え動作の例を示しています。

表10.4 rewrite-target の例:

Route.spec.path要求パス書き換えターゲット転送された要求パス

/foo

/foo

/

/

/foo

/foo/

/

/

/foo

/foo/bar

/

/bar

/foo

/foo/bar/

/

/bar/

/foo

/foo

/bar

/bar

/foo

/foo/

/bar

/bar/

/foo

/foo/bar

/baz

/baz/bar

/foo

/foo/bar/

/baz

/baz/bar/

/foo/

/foo

/

該当なし (要求パスがルートパスに一致しない)

/foo/

/foo/

/

/

/foo/

/foo/bar

/

/bar

10.1.9. Ingress オブジェクトを介してデフォルトの証明書を使用してルートを作成する

TLS 設定を指定せずに Ingress オブジェクトを作成すると、Red Hat OpenShift Service on AWS は安全でないルートを生成します。デフォルトの Ingress 証明書を使用してセキュアなエッジ終端ルートを生成する Ingress オブジェクトを作成するには、次のように空の TLS 設定を指定できます。

前提条件

  • 公開したいサービスがあります。
  • OpenShift CLI (oc) にアクセスできる。

手順

  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

検証

  • 次のコマンドを実行して、Red Hat OpenShift Service on AWS が Ingress オブジェクトの想定されるルートを作成したことを確認します。 

    $ oc get routes -o yaml

    出力例

    apiVersion: v1
items:
- apiVersion: route.openshift.io/v1
  kind: Route
  metadata:
    name: frontend-j9sdd 1
    ...
  spec:
  ...
    tls: 2
      insecureEdgeTerminationPolicy: Redirect
      termination: edge 3
  ...

    1
    ルートの名前には、Ingress オブジェクトの名前とそれに続くランダムな接尾辞が含まれます。
    2
    デフォルトの証明書を使用するには、ルートで spec.certificate を指定しないでください。
    3
    ルートは、edge の終了ポリシーを指定する必要があります。

10.1.10. Ingress アノテーションでの宛先 CA 証明書を使用したルート作成

route.openshift.io/destination-ca-certificate-secret アノテーションを Ingress オブジェクトで使用して、カスタム宛先 CA 証明書でルートを定義できます。

前提条件

  • PEM エンコードされたファイルで証明書/キーのペアを持つことができます。ここで、証明書はルートホストに対して有効となっています。
  • 証明書チェーンを完了する PEM エンコードされたファイルの別の CA 証明書が必要です。
  • PEM エンコードされたファイルの別の宛先 CA 証明書が必要です。
  • 公開する必要のあるサービスが必要です。

手順

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

関連情報

10.2. セキュリティー保護されたルート

セキュアなルートは、複数の TLS 終端タイプを使用してクライアントに証明書を提供できます。以下のセクションでは、カスタム証明書を使用して re-encrypt、edge、および passthrough ルートを作成する方法を説明します。

10.2.1. カスタム証明書を使用した re-encrypt ルートの作成

oc create route コマンドを使用し、カスタム証明書と共に reencrypt TLS termination を使用してセキュアなルートを設定できます。

前提条件

  • PEM エンコードされたファイルに証明書/キーのペアが必要です。ここで、証明書はルートホストに対して有効となっています。
  • 証明書チェーンを完了する PEM エンコードされたファイルの別の CA 証明書が必要です。
  • PEM エンコードされたファイルの別の宛先 CA 証明書が必要です。
  • 公開する必要のあるサービスが必要です。
注記

パスワードで保護されるキーファイルはサポートされません。キーファイルからパスフレーズを削除するには、以下のコマンドを使用します。 

$ openssl rsa -in password_protected_tls.key -out tls.key

手順

この手順では、カスタム証明書および reencrypt TLS termination を使用して Route リソースを作成します。以下では、証明書/キーのペアが現在の作業ディレクトリーの tls.crt および tls.key ファイルにあることを前提としています。また、Ingress Controller がサービスの証明書を信頼できるように宛先 CA 証明書を指定する必要もあります。必要な場合には、証明書チェーンを完了するために CA 証明書を指定することもできます。tls.crt、 tls.key、cacert.crt、および (オプションで) ca.crt を実際のパス名に置き換えます。frontend を、公開する必要のある Service リソースに置き換えます。www.example.com を適切な名前に置き換えます。

  • reencrypt TLS 終端およびカスタム証明書を使用してセキュアな Route リソースを作成します。 

    $ oc create route reencrypt --service=frontend --cert=tls.crt --key=tls.key --dest-ca-cert=destca.crt --ca-cert=ca.crt --hostname=www.example.com

    結果として生成される Route リソースを検査すると、以下のようになります。

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

    apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: frontend
spec:
  host: www.example.com
  to:
    kind: Service
    name: frontend
  tls:
    termination: reencrypt
    key: |-
      -----BEGIN PRIVATE KEY-----
      [...]
      -----END PRIVATE KEY-----
    certificate: |-
      -----BEGIN CERTIFICATE-----
      [...]
      -----END CERTIFICATE-----
    caCertificate: |-
      -----BEGIN CERTIFICATE-----
      [...]
      -----END CERTIFICATE-----
    destinationCACertificate: |-
      -----BEGIN CERTIFICATE-----
      [...]
      -----END CERTIFICATE-----

    他のオプションについては、oc create route reencrypt --help を参照してください。

10.2.2. カスタム証明書を使用した edge ルートの作成

oc create route コマンドを使用し、edge TLS termination とカスタム証明書を使用してセキュアなルートを設定できます。edge ルートの場合、Ingress Controller は、トラフィックを宛先 Pod に転送する前に TLS 暗号を終了します。ルートは、Ingress Controller がルートに使用する TLS 証明書およびキーを指定します。

前提条件

  • PEM エンコードされたファイルに証明書/キーのペアが必要です。ここで、証明書はルートホストに対して有効となっています。
  • 証明書チェーンを完了する PEM エンコードされたファイルの別の CA 証明書が必要です。
  • 公開する必要のあるサービスが必要です。
注記

パスワードで保護されるキーファイルはサポートされません。キーファイルからパスフレーズを削除するには、以下のコマンドを使用します。 

$ openssl rsa -in password_protected_tls.key -out tls.key

手順

この手順では、カスタム証明書および edge TLS termination を使用して Route リソースを作成します。以下では、証明書/キーのペアが現在の作業ディレクトリーの tls.crt および tls.key ファイルにあることを前提としています。必要な場合には、証明書チェーンを完了するために CA 証明書を指定することもできます。tls.crt、 tls.key、および (オプションで) ca.crt を実際のパス名に置き換えます。frontend を、公開する必要のあるサービスの名前に置き換えます。www.example.com を適切な名前に置き換えます。

  • edge TLS termination およびカスタム証明書を使用して、セキュアな Route リソースを作成します。 

    $ oc create route edge --service=frontend --cert=tls.crt --key=tls.key --ca-cert=ca.crt --hostname=www.example.com

    結果として生成される Route リソースを検査すると、以下のようになります。

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

    apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: frontend
spec:
  host: www.example.com
  to:
    kind: Service
    name: frontend
  tls:
    termination: edge
    key: |-
      -----BEGIN PRIVATE KEY-----
      [...]
      -----END PRIVATE KEY-----
    certificate: |-
      -----BEGIN CERTIFICATE-----
      [...]
      -----END CERTIFICATE-----
    caCertificate: |-
      -----BEGIN CERTIFICATE-----
      [...]
      -----END CERTIFICATE-----

    他のオプションについては、oc create route edge --help を参照してください。

10.2.3. passthrough ルートの作成

oc create route コマンドを使用し、passthrough termination を使用してセキュアなルートを設定できます。passthrough termination では、暗号化されたトラフィックが TLS 終端を提供するルーターなしに宛先に直接送信されます。そのため、ルートでキーや証明書は必要ありません。

前提条件

  • 公開する必要のあるサービスが必要です。

手順

  • Route リソースを作成します。 

    $ oc create route passthrough route-passthrough-secured --service=frontend --port=8080

    結果として生成される Route リソースを検査すると、以下のようになります。

    passthrough termination を使用したセキュリティー保護されたルート

    apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: route-passthrough-secured 1
spec:
  host: www.example.com
  port:
    targetPort: 8080
  tls:
    termination: passthrough 2
    insecureEdgeTerminationPolicy: None 3
  to:
    kind: Service
    name: frontend

    1
    オブジェクトの名前で、63 文字に制限されます。
    2
    termination フィールドを passthrough に設定します。これは、必要な唯一の tls フィールドです。
    3
    オプションの insecureEdgeTerminationPolicy。唯一有効な値は None、Redirect、または空の値です (無効にする場合)。

    宛先 Pod は、エンドポイントでトラフィックに証明書を提供します。これは、必須となるクライアント証明書をサポートするための唯一の方法です (相互認証とも呼ばれる)。

法律上の通知

Copyright © 2024 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.