検索

ネットワーク

download PDF
OpenShift Container Platform 4.15

クラスターネットワークの設定および管理

Red Hat OpenShift Documentation Team

概要

この文書では、DNS、ingress および Pod ネットワークを含む、OpenShift Container Platform のクラスターネットワークを設定し、管理する方法を説明します。

第1章 ネットワークの概要

Red Hat OpenShift Networking は、1 つまたは複数のハイブリッドクラスターのネットワークトラフィックを管理するためにクラスターが必要とする高度なネットワーク関連機能で Kubernetes ネットワーキングを拡張する機能、プラグイン、高度なネットワーク機能のエコシステムです。このネットワーキング機能のエコシステムは、ingress、egress、ロードバランシング、高性能スループット、セキュリティー、クラスター間およびクラスター内のトラフィック管理を統合し、ロールベースの可観測性ツールを提供して複雑さを軽減します。

注記

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

以下のリストは、クラスターで利用可能な最も一般的に使用される Red Hat OpenShift Networking 機能の一部を強調しています。

  • 次の Container Network Interface (CNI) プラグインのいずれかによって提供されるプライマリークラスターネットワーク:

  • 認定されたサードパーティーの代替プライマリーネットワークプラグイン
  • ネットワークプラグイン管理用の Cluster Network Operator
  • TLS 暗号化 Web トラフィックの Ingress Operator
  • 名前割り当てのための DNS Operator
  • ベアメタルクラスターでのトラフィック負荷分散用の MetalLB Operator
  • 高可用性のための IP フェイルオーバーのサポート
  • macvlan、ipvlan、SR-IOV ハードウェアネットワークなど、複数の CNI プラグインによる追加のハードウェアネットワークサポート
  • IPv4、IPv6、およびデュアルスタックアドレッシング
  • Windows ベースのワークロード用のハイブリッド Linux-Windows ホストクラスター
  • サービスのディスカバリー、ロードバランシング、サービス間認証、障害リカバリー、メトリクス、およびモニター用の Red Hat OpenShift Service Mesh
  • シングルノード OpenShift
  • ネットワークのデバッグと洞察のための Network Observability Operator
  • クラスター間ネットワーク用の Submariner
  • レイヤー 7 クラスター間ネットワーク用の Red Hat Service Interconnect

第2章 ネットワークについて

クラスター管理者は、クラスターで実行されるアプリケーションを外部トラフィックに公開し、ネットワーク接続のセキュリティーを保護するための複数のオプションがあります。

  • ノードポートやロードバランサーなどのサービスタイプ
  • IngressRoute などの API リソース

デフォルトで、Kubernetes は各 Pod に、Pod 内で実行しているアプリケーションの内部 IP アドレスを割り当てます。Pod とそのコンテナーはネットワーク接続が可能ですが、クラスター外のクライアントにはネットワークアクセスがありません。アプリケーションを外部トラフィックに公開する場合、各 Pod に IP アドレスを割り当てると、ポートの割り当て、ネットワーク、名前の指定、サービス検出、負荷分散、アプリケーション設定、移行などの点で、Pod を物理ホストや仮想マシンのように扱うことができます。

注記

一部のクラウドプラットフォームでは、169.254.169.254 IP アドレスでリッスンするメタデータ API があります。これは、IPv4 169.254.0.0/16 CIDR ブロックのリンクローカル IP アドレスです。

この CIDR ブロックは Pod ネットワークから到達できません。これらの IP アドレスへのアクセスを必要とする Pod には、Pod 仕様の spec.hostNetwork フィールドを true に設定して、ホストのネットワークアクセスが付与される必要があります。

Pod ホストのネットワークアクセスを許可する場合、Pod に基礎となるネットワークインフラストラクチャーへの特権アクセスを付与します。

2.1. OpenShift Container Platform DNS

フロントエンドサービスやバックエンドサービスなど、複数のサービスを実行して複数の Pod で使用している場合、フロントエンド Pod がバックエンドサービスと通信できるように、ユーザー名、サービス IP などの環境変数を作成します。サービスが削除され、再作成される場合には、新規の IP アドレスがそのサービスに割り当てられるので、フロントエンド Pod がサービス IP の環境変数の更新された値を取得するには、これを再作成する必要があります。さらに、バックエンドサービスは、フロントエンド Pod を作成する前に作成し、サービス IP が正しく生成され、フロントエンド Pod に環境変数として提供できるようにする必要があります。

そのため、OpenShift Container Platform には DNS が組み込まれており、これにより、サービスは、サービス IP/ポートと共にサービス DNS によって到達可能になります。

2.2. OpenShift Container Platform Ingress Operator

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

Ingress Operator を使用すると、ルーティングを処理する 1 つ以上の HAProxy ベースの Ingress Controller をデプロイおよび管理することにより、外部クライアントがサービスにアクセスできるようになります。OpenShift Container Platform Route および Kubernetes Ingress リソースを指定して、トラフィックをルーティングするために Ingress Operator を使用します。endpointPublishingStrategy タイプおよび内部負荷分散を定義する機能などの Ingress Controller 内の設定は、Ingress Controller エンドポイントを公開する方法を提供します。

2.2.1. ルートと Ingress の比較

OpenShift Container Platform の Kubernetes Ingress リソースは、クラスター内で Pod として実行される共有ルーターサービスと共に Ingress Controller を実装します。Ingress トラフィックを管理する最も一般的な方法は Ingress Controller を使用することです。他の通常の Pod と同様にこの Pod をスケーリングし、複製できます。このルーターサービスは、オープンソースのロードバランサーソリューションである HAProxy をベースとしています。

OpenShift Container Platform ルートは、クラスターのサービスに Ingress トラフィックを提供します。ルートは、Blue-Green デプロイメント向けに TLS 再暗号化、TLS パススルー、分割トラフィックなどの標準の Kubernetes Ingress Controller でサポートされない可能性のある高度な機能を提供します。

Ingress トラフィックは、ルートを介してクラスターのサービスにアクセスします。ルートおよび Ingress は、Ingress トラフィックを処理する主要なリソースです。Ingress は、外部要求を受け入れ、ルートに基づいてそれらを委譲するなどのルートと同様の機能を提供します。ただし、Ingress では、特定タイプの接続 (HTTP/2、HTTPS およびサーバー名 ID(SNI)、ならび証明書を使用した TLS のみを許可できます。OpenShift Container Platform では、ルートは、Ingress リソースで指定される各種の条件を満たすために生成されます。

2.3. OpenShift Container Platform ネットワーキングの一般用語集

この用語集では、ネットワーキングコンテンツで使用される一般的な用語を定義します。

authentication
OpenShift Container Platform クラスターへのアクセスを制御するために、クラスター管理者はユーザー認証を設定し、承認されたユーザーのみがクラスターにアクセスできます。OpenShift Container Platform クラスターと対話するには、OpenShift Container Platform API に対して認証する必要があります。OpenShift Container Platform API へのリクエストで、OAuth アクセストークンまたは X.509 クライアント証明書を提供することで認証できます。
AWS Load Balancer Operator
AWS Load Balancer (ALB) Operator は、aws-load-balancer-controller のインスタンスをデプロイおよび管理します。
Cluster Network Operator
Cluster Network Operator (CNO) は、OpenShift Container Platform クラスター内のクラスターネットワークコンポーネントをデプロイおよび管理します。これには、インストール時にクラスター用に選択された Container Network Interface (CNI) ネットワークプラグインのデプロイが含まれます。
config map
config map は、設定データを Pod に注入する方法を提供します。タイプ ConfigMap のボリューム内の config map に格納されたデータを参照できます。Pod で実行しているアプリケーションは、このデータを使用できます。
カスタムリソース (CR)
CR は Kubernetes API の拡張です。カスタムリソースを作成できます。
DNS
クラスター DNS は、Kubernetes サービスの DNS レコードを提供する DNS サーバーです。Kubernetes により開始したコンテナーは、DNS 検索にこの DNS サーバーを自動的に含めます。
DNS Operator
DNS Operator は、CoreDNS をデプロイして管理し、Pod に名前解決サービスを提供します。これにより、OpenShift Container Platform で DNS ベースの Kubernetes サービス検出が可能になります。
deployment
アプリケーションのライフサイクルを維持する Kubernetes リソースオブジェクト。
domain
ドメインは、Ingress Controller によってサービスされる DNS 名です。
egress
Pod からのネットワークのアウトバウンドトラフィックを介して外部とデータを共有するプロセス。
外部 DNS Operator
外部 DNS Operator は、ExternalDNS をデプロイして管理し、外部 DNS プロバイダーから OpenShift Container Platform へのサービスおよびルートの名前解決を提供します。
HTTP ベースのルート
HTTP ベースのルートとは、セキュアではないルートで、基本的な HTTP ルーティングプロトコルを使用してセキュリティー保護されていないアプリケーションポートでサービスを公開します。
Ingress
OpenShift Container Platform の Kubernetes Ingress リソースは、クラスター内で Pod として実行される共有ルーターサービスと共に Ingress Controller を実装します。
Ingress Controller
Ingress Operator は Ingress Controller を管理します。Ingress Controller の使用は、最も一般的な、OpenShift Container Platform クラスターへの外部アクセスを許可する方法です。
インストーラーでプロビジョニングされるインフラストラクチャー
インストールプログラムは、クラスターが実行されるインフラストラクチャーをデプロイして設定します。
kubelet
コンテナーが Pod で実行されていることを確認するために、クラスター内の各ノードで実行されるプライマリーノードエージェント。
Kubernetes NMState Operator
Kubernetes NMState Operator は、NMState の OpenShift Container Platform クラスターのノード間でステートドリブンのネットワーク設定を実行するための Kubernetes API を提供します。
kube-proxy
Kube-proxy は、各ノードで実行するプロキシーサービスであり、外部ホストがサービスを利用できるようにするのに役立ちます。リクエストを正しいコンテナーに転送するのに役立ち、基本的な負荷分散を実行できます。
ロードバランサー
OpenShift Container Platform は、ロードバランサーを使用して、クラスターの外部からクラスターで実行されているサービスと通信します。
MetalLB Operator
クラスター管理者は、MetalLB Operator をクラスターに追加し、タイプ LoadBalancer のサービスがクラスターに追加されると、MetalLB はサービスの外部 IP アドレスを追加できます。
multicast
IP マルチキャストを使用すると、データが多数の IP アドレスに同時に配信されます。
namespace
namespace は、すべてのプロセスから見える特定のシステムリソースを分離します。namespace 内では、その namespace のメンバーであるプロセスのみがそれらのリソースを参照できます。
networking
OpenShift Container Platform クラスターのネットワーク情報。
node
OpenShift Container Platform クラスター内のワーカーマシン。ノードは、仮想マシン (VM) または物理マシンのいずれかです。
OpenShift Container Platform Ingress Operator
Ingress Operator は IngressController API を実装し、OpenShift Container Platform サービスへの外部アクセスを可能にするコンポーネントです。
Pod
OpenShift Container Platform クラスターで実行されている、ボリュームや IP アドレスなどの共有リソースを持つ 1 つ以上のコンテナー。Pod は、定義、デプロイ、および管理される最小のコンピュート単位です。
PTP Operator
PTP Operator は、linuxptp サービスを作成し、管理します。
route
OpenShift Container Platform ルートは、クラスターのサービスに Ingress トラフィックを提供します。ルートは、Blue-Green デプロイメント向けに TLS 再暗号化、TLS パススルー、分割トラフィックなどの標準の Kubernetes Ingress Controller でサポートされない可能性のある高度な機能を提供します。
スケーリング
リソース容量の増減。
サービス
一連の Pod で実行中のアプリケーションを公開します。
シングルルート I/O 仮想化 (SR-IOV) Network Operator
Single Root I/O Virtualization (SR-IOV) ネットワーク Operator は、クラスターで SR-IOV ネットワークデバイスおよびネットワーク割り当てを管理します。
ソフトウェア定義ネットワーク (SDN)
OpenShift Container Platform は、Software Defined Networking (SDN) アプローチを使用して、クラスターのネットワークを統合し、OpenShift Container Platform クラスターの Pod 間の通信を可能にします。
注記

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

SCTP (Stream Control Transmission Protocol)
SCTP は、IP ネットワークの上部で実行される信頼できるメッセージベースのプロトコルです。
taint
テイントと容認により、Pod が適切なノードに確実にスケジュールされます。ノードに 1 つ以上のテイントを適用できます。
容認
Pod に容認を適用できます。Tolerations を使用すると、スケジューラーは、テイントが一致する Pod をスケジュールできます。
Web コンソール
OpenShift Container Platform を管理するためのユーザーインターフェイス (UI)。

第3章 ゼロトラストネットワーク

ゼロトラストは、すべてのインタラクションが信頼できない状態から始まるという前提に基づきセキュリティーアーキテクチャーを設計するアプローチです。これは、通信がファイアウォールの内側で開始されるかどうかに基づき信頼性を決定する従来のアーキテクチャーとは対照的です。より具体的には、ゼロトラストは、暗黙的信頼モデルと 1 回限りの認証に依存するセキュリティーアーキテクチャーのギャップを埋めようとします。

OpenShift Container Platform は、コンテナーやコンテナー内で実行されているソフトウェアを変更することなく、プラットフォーム上で実行されているコンテナーにゼロトラストネットワーク機能を追加できます。Red Hat は、コンテナーのゼロトラストネットワーキング機能をさらに強化できる製品もさらにいくつか提供しています。コンテナー内で実行されているソフトウェアを変更できる場合は、Red Hat がサポートする他のプロジェクトを使用して、さらに機能を追加できます。

以下は、ゼロトラストネットワークの対象となる機能の詳細です。

3.1. Root of Trust

公開証明書と秘密鍵はゼロトラストネットワークにとって重要です。これらは、各コンポーネントを相互に識別し、認証し、トラフィックを保護するために使用されます。証明書は他の証明書によって署名され、ルート認証局 (CA) への信頼チェーンが存在します。ネットワークに参加するすべてが、信頼チェーンを検証できるように、最終的にルート CA の公開鍵を持っている必要があります。一般に公開されている場合、通常は世界的に知られているルート CA のセットであり、その鍵はオペレーティングシステムや Web ブラウザーなどとともに配布されます。ただし、プライベート CA の証明書がすべての関係者に配布されている場合、クラスターまたは企業向けにプライベート CA を実行できます。

活用方法:

  • OpenShift Container Platform: OpenShift は、クラスターリソースの保護に使用される クラスター CA をインストール時に 作成します。ただし、OpenShift Container Platform は、クラスター内で サービス証明書 を作成して署名することもでき、そのクラスター CA バンドルを必要に応じて Pod に注入することもできます。OpenShift Container Platform によって作成および署名された サービス証明書 の有効期間 (TTL) は 26 カ月で、13 カ月ごとに自動的にローテーションされます。必要に応じて手動でローテーションすることも可能です。
  • OpenShift cert-manager Operator: cert-manager を使用すると、外部の root of trust によって署名された鍵を要求できます。委譲された署名証明書を使用して実行する方法の他に、外部発行者と統合するために設定できる発行者が多数あります。cert-manager API は、ゼロトラストネットワーク内の他のソフトウェア (Red Hat OpenShift Service Mesh など) が必要な証明書を要求するために使用することも、お客様のソフトウェアが直接使用することも可能です。

3.2. トラフィック認証と暗号化

回線上のすべてのトラフィックが暗号化され、エンドポイントが識別可能になります。一例として、相互認証方式である Mutual TLS (mTLS) が挙げられます。

活用方法:

  • OpenShift Container Platform: 透過的な Pod 間の IPsec を使用することで、トラフィックの送信元と宛先を IP アドレスで識別できます。Egress トラフィックを IPsec を使用して暗号化 する機能があります。Egress IP 機能を使用すると、トラフィックの送信元 IP アドレスを使用して、クラスター内のトラフィックの送信元を識別できます。
  • Red Hat OpenShift Service Mesh: Pod から送信されるトラフィックを透過的に拡張して認証と暗号化を提供する強力な mTLS 機能 を提供します。
  • OpenShift cert-manager Operator: カスタムリソース定義 (CRD) を使用して、プログラムが SSL/TLS プロトコルに使用するためにマウントできる証明書を要求します。

3.3. 識別と認証

CA を使用して証明書を作成できるようになると、それを使用して接続のもう一方の端 (ユーザーまたはクライアントマシン) のアイデンティティーを検証することで信頼関係を確立できるようになります。また、侵害された場合に使用を制限するために、証明書のライフサイクルを管理する必要もあります。

活用方法:

  • OpenShift Container Platform: クライアントが信頼済みエンドポイントと通信していることを確認するためのクラスター署名付き サービス証明書。これには、サービスが SSL/TLS を使用し、クライアントが クラスター CA を使用することが求められます。クライアントアイデンティティーは他の手段で提供する必要があります。
  • Red Hat Single Sign-On: エンタープライズユーザーディレクトリーまたはサードパーティーのアイデンティティープロバイダーとの要求認証統合を提供します。
  • Red Hat OpenShift Service Mesh: mTLS への接続の 透過的なアップグレード、自動ローテーション、カスタム証明書の有効期限、JSON Web トークン (JWT) による要求認証。
  • OpenShift cert-manager Operator: アプリケーションで使用する証明書の作成と管理。証明書は CRD により制御され、シークレットとしてマウントできます。また、cert-manager API と直接対話するようにアプリケーションを変更することもできます。

3.4. サービス間認可

リクエスト元のアイデンティティーに基づきサービスへのアクセスを制御できることが重要です。これはプラットフォームによって実行されるため、各アプリケーションで実装する必要はありません。これにより、ポリシーの監査と検査がより適切に行えるようになります。

活用方法:

  • OpenShift Container Platform: Kubernetes NetworkPolicy および AdminNetworkPolicy オブジェクトを使用して、プラットフォームのネットワーク層で分離を強制できます。
  • Red Hat OpenShift Service Mesh: 標準の Istio オブジェクトを使用し、mTLS を使用してトラフィックの送信元と宛先を識別し、その情報に基づきポリシーを適用する、高度な L4 および L7 の トラフィック制御

3.5. トランザクションレベルの検証

接続の識別および認証機能に加えて、個々のトランザクションへのアクセスを制御するのにも役立ちます。これには、ソースによるレート制限、可観測性、トランザクションが適切に形成されていることのセマンティック検証などが含まれます。

活用方法:

3.6. リスク評価

クラスター内のセキュリティーポリシーの数が増えるにつれ、ポリシーが許可および拒否する内容の可視化がますます重要になります。これらのツールを使用すると、クラスターセキュリティーポリシーの作成、可視化、管理が容易になります。

活用方法:

3.7. サイト全体のポリシーの施行と配布

クラスターにアプリケーションをデプロイした後、セキュリティールールを構成するすべてのオブジェクトを管理することが困難になります。サイト全体にポリシーを適用し、デプロイしたオブジェクトがポリシーに準拠しているかどうかを監査することが重要になります。これにより、定義された範囲内でユーザーとクラスター管理者に一部の権限を委譲できるようになり、必要に応じてポリシーの例外も許可されるようになります。

活用方法:

3.8. 継続的かつ遡及的な評価のための可観測性

クラスターを実行した後は、トラフィックを観察し、トラフィックが定義したルールに準拠していることを確認する必要があります。これは侵入検知やフォレンジックのために重要であり、運用負荷管理にも役立ちます。

活用方法:

  • Network Observability Operator: クラスター内の Pod やノードへのネットワーク接続に関する検査、監視、アラートが可能になります。
  • Red Hat Advanced Cluster Management (RHACM) for Kubernetes: プロセス実行、ネットワーク接続とフロー、権限昇格などのシステムレベルのイベントを監視、収集、評価します。クラスターのベースラインを決定し、異常なアクティビティーを検出して警告することができます。
  • Red Hat OpenShift Service Mesh: Pod に出入りする トラフィックを監視 できます。
  • Red Hat OpenShift 分散トレーシングプラットフォーム: 適切にインストルメント化されたアプリケーションの場合、特定のアクションがマイクロサービスへのサブリクエストに分割されるときに、そのアクションに関連付けられたすべてのトラフィックを確認できます。これにより、分散アプリケーション内のボトルネックを特定できます。

3.9. エンドポイントセキュリティー

クラスター内のサービスを実行しているソフトウェアが侵害されていないことを確信できることが重要です。たとえば、認定されたイメージが信頼済みハードウェア上で実行されるようにし、エンドポイントの特性に基づいてエンドポイントとの間の接続のみを許可するポリシーを設定する必要がある場合があります。

活用方法:

  • OpenShift Container Platform: Secureboot を使用すると、クラスター内のノードが信頼済みのソフトウェアを実行していることを確認できるため、プラットフォーム自体 (コンテナーランタイムを含む) が改ざんされていないことを確認できます。OpenShift Container Platform を、特定の署名で署名された イメージのみを実行するように設定できます。
  • Red Hat Trusted Artifact Signer: 信頼済みビルドチェーンで使用でき、署名付きコンテナーイメージを生成できます。

3.10. クラスター外への信頼の拡張

クラスターによるサブドメインの CA 作成を許可することで、クラスター外部に信頼を拡張する必要がある場合があります。あるいは、クラスター内のワークロードアイデンティティーをリモートエンドポイントに証明する必要があることもあります。

活用方法:

  • OpenShift cert-manager Operator: cert-manager を使用して委譲された CA を管理し、クラスターをまたいで、もしくは組織全体で信頼を分散できます。
  • Red Hat OpenShift Service Mesh: SPIFFE を使用して、リモートまたはローカルクラスターで実行されているエンドポイントにワークロードのリモートアテステーションを提供できます。

第4章 ホストへのアクセス

OpenShift Container Platform インスタンスにアクセスして、セキュアシェル (SSH) アクセスでコントロールプレーンノードにアクセスするために bastion ホストを作成する方法を学びます。

4.1. インストーラーでプロビジョニングされるインフラストラクチャークラスターでの Amazon Web Services のホストへのアクセス

OpenShift Container Platform インストーラーは、OpenShift Container Platform クラスターにプロビジョニングされる Amazon Elastic Compute Cloud (Amazon EC2) インスタンスのパブリック IP アドレスを作成しません。OpenShift Container Platform ホストに対して SSH を実行できるようにするには、以下の手順を実行する必要があります。

手順

  1. openshift-install コマンドで作成される仮想プライベートクラウド (VPC) に対する SSH アクセスを可能にするセキュリティーグループを作成します。
  2. インストーラーが作成したパブリックサブネットのいずれかに Amazon EC2 インスタンスを作成します。
  3. パブリック IP アドレスを、作成した Amazon EC2 インスタンスに関連付けます。

    OpenShift Container Platform のインストールとは異なり、作成した Amazon EC2 インスタンスを SSH キーペアに関連付ける必要があります。これにはインターネットを OpenShift Container Platform クラスターの VPC にブリッジ接続するための SSH bastion としてのみの単純な機能しかないため、このインスタンスにどのオペレーティングシステムを選択しても問題ありません。どの Amazon Machine Image (AMI) を使用するかについては、注意が必要です。たとえば、Red Hat Enterprise Linux CoreOS (RHCOS) では、インストーラーと同様に、Ignition でキーを指定することができます。

  4. Amazon EC2 インスタンスをプロビジョニングし、これに対して SSH を実行した後に、OpenShift Container Platform インストールに関連付けた SSH キーを追加する必要があります。このキーは bastion インスタンスのキーとは異なる場合がありますが、異なるキーにしなければならない訳ではありません。

    注記

    直接の SSH アクセスは、障害復旧を目的とする場合にのみ推奨されます。Kubernetes API が応答する場合、特権付き Pod を代わりに実行します。

  5. oc get nodes を実行し、出力を検査し、マスターであるノードのいずれかを選択します。ホスト名は ip-10-0-1-163.ec2.internal に類似したものになります。
  6. Amazon EC2 に手動でデプロイした bastion SSH ホストから、そのコントロールプレーンホストに SSH を実行します。インストール時に指定したものと同じ SSH キーを使用するようにします。

    $ ssh -i <ssh-key-path> core@<master-hostname>

第5章 ネットワーキング Operator の概要

OpenShift Container Platform は、複数のタイプのネットワーキング Operator をサポートします。これらのネットワーク Operator を使用して、クラスターネットワークを管理できます。

5.1. Cluster Network Operator

Cluster Network Operator (CNO) は、OpenShift Container Platform クラスター内のクラスターネットワークコンポーネントをデプロイおよび管理します。これには、インストール時にクラスター用に選択された Container Network Interface (CNI) ネットワークプラグインのデプロイが含まれます。詳細は、OpenShift Container Platform における Cluster Network Operator を参照してください。

5.2. DNS Operator

DNS Operator は、CoreDNS をデプロイして管理し、Pod に名前解決サービスを提供します。これにより、OpenShift Container Platform で DNS ベースの Kubernetes サービス検出が可能になります。詳細は、OpenShift Container Platform の DNS Operator を参照してください。

5.3. Ingress Operator

OpenShift Container Platform クラスターを作成すると、クラスターで実行している Pod およびサービスにはそれぞれの IP アドレスが割り当てられます。IP アドレスは、近くで実行されている他の Pod やサービスからアクセスできますが、外部クライアントの外部からはアクセスできません。Ingress Operator は Ingress Controller API を実装し、OpenShift Container Platform クラスターサービスへの外部アクセスを可能にします。詳細は、OpenShift Container Platform の Ingress Operator を参照してください。

5.4. 外部 DNS Operator

外部 DNS Operator は、ExternalDNS をデプロイして管理し、外部 DNS プロバイダーから OpenShift Container Platform へのサービスおよびルートの名前解決を提供します。詳細は、Understanding the External DNS Operator を参照してください。

5.5. Ingress Node Firewall Operator

Ingress Node Firewall Operator は、拡張された Berkley Packet Filter (eBPF) と eXpress Data Path (XDP) プラグインを使用して、ノードファイアウォールルールを処理し、統計を更新し、ドロップされたトラフィックのイベントを生成します。Operator は、Ingress ノードファイアウォールリソースを管理し、ファイアウォール設定を検証し、クラスターアクセスを妨げる可能性がある誤設定されたルールを許可せず、ルールのオブジェクトで選択されたインターフェイスに Ingress ノードファイアウォール XDP プログラムをロードします。詳細は、Ingress Node Firewall Operator についてを参照してください。

5.6. Network Observability Operator

Network Observability Operator は、クラスター管理者が OpenShift Container Platform クラスターのネットワークトラフィックを観察するために使用できるオプションの Operator です。Network Observability Operator は、eBPF テクノロジーを使用してネットワークフローを作成します。その後、ネットワークフローは OpenShift Container Platform 情報で強化され、Loki に保存されます。保存されたネットワークフロー情報を OpenShift Container Platform コンソールで表示および分析して、さらなる洞察とトラブルシューティングを行うことができます。詳細は、Network Observability Operator について を参照してください。

第6章 ネットワークダッシュボード

ネットワークメトリクスは、OpenShift Container Platform Web コンソール内のダッシュボードから、ObserveDashboards で表示できます。

6.1. Network Observability Operator

Network Observability Operator がインストールされている場合は、Dashboards ドロップダウンリストから Netobserv ダッシュボードを選択すると、ネットワークトラフィックメトリクスダッシュボードが表示されます。この ダッシュボード で利用できるメトリクスの詳細は、ネットワーク可観測性メトリクスのダッシュボード を参照してください。

6.2. ネットワーキングと OVN-Kubernetes ダッシュボード

このダッシュボードからは、一般的なネットワークメトリクスと OVN-Kubernetes メトリクスの両方を表示できます。

一般的なネットワークメトリクスを表示するには、Dashboards ドロップダウンリストから Networking/Linux Subsystem Stats を選択します。ダッシュボードから表示できるネットワークメトリクスは、Network UtilisationNetwork SaturationNetwork Errors です。

OVN-Kubernetes メトリクスを表示するには、Dashboards ドロップダウンリストから Networking/Infrastructure を選択します。表示できる OVN-Kuberenetes メトリクスは、Networking ConfigurationTCP Latency ProbesControl Plane ResourcesWorker Resources です。

6.3. Ingress Operator ダッシュボード

Ingress Operator によって処理されるネットワークメトリクスをダッシュボードから表示できます。これには、次のようなメトリクスが含まれます。

  • 受信および送信の帯域幅
  • HTTP エラーレート
  • HTTP サーバーの応答遅延

これらの Ingress メトリクスを表示するには、Dashboards ドロップダウンリストから Networking/Ingress を選択します。Top 10 Per RouteTop 10 Per NamespaceTop 10 Per Shard のカテゴリーの Ingress メトリクスを表示できます。

第7章 OpenShift Container Platform における Cluster Network Operator

Cluster Network Operator (CNO) は、インストール時にクラスター用に選択される Container Network Interface (CNI) ネットワークプラグインを含む、OpenShift Container Platform クラスターの各種のクラスターネットワークコンポーネントをデプロイし、これらを管理します。

7.1. Cluster Network Operator

Cluster Network Operator は、operator.openshift.io API グループから network API を実装します。Operator は、デーモンセットを使用して、クラスターのインストール中に選択した OVN-Kubernetes ネットワークプラグインまたはネットワークプロバイダープラグインをデプロイします。

手順

Cluster Network Operator は、インストール時に Kubernetes Deployment としてデプロイされます。

  1. 以下のコマンドを実行して Deployment のステータスを表示します。

    $ oc get -n openshift-network-operator deployment/network-operator

    出力例

    NAME               READY   UP-TO-DATE   AVAILABLE   AGE
    network-operator   1/1     1            1           56m

  2. 以下のコマンドを実行して、Cluster Network Operator の状態を表示します。

    $ oc get clusteroperator/network

    出力例

    NAME      VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE
    network   4.5.4     True        False         False      50m

    以下のフィールドは、Operator のステータス (AVAILABLEPROGRESSING、および DEGRADED) についての情報を提供します。AVAILABLE フィールドは、Cluster Network Operator が Available ステータス条件を報告する場合に True になります。

7.2. クラスターネットワーク設定の表示

すべての新規 OpenShift Container Platform インストールには、cluster という名前の network.config オブジェクトがあります。

手順

  • oc describe コマンドを使用して、クラスターネットワーク設定を表示します。

    $ oc describe network.config/cluster

    出力例

    Name:         cluster
    Namespace:
    Labels:       <none>
    Annotations:  <none>
    API Version:  config.openshift.io/v1
    Kind:         Network
    Metadata:
      Self Link:           /apis/config.openshift.io/v1/networks/cluster
    Spec: 1
      Cluster Network:
        Cidr:         10.128.0.0/14
        Host Prefix:  23
      Network Type:   OpenShiftSDN
      Service Network:
        172.30.0.0/16
    Status: 2
      Cluster Network:
        Cidr:               10.128.0.0/14
        Host Prefix:        23
      Cluster Network MTU:  8951
      Network Type:         OpenShiftSDN
      Service Network:
        172.30.0.0/16
    Events:  <none>

    1
    Spec フィールドは、クラスターネットワークの設定済みの状態を表示します。
    2
    Status フィールドは、クラスターネットワークの現在の状態を表示します。

7.3. Cluster Network Operator のステータス表示

oc describe コマンドを使用して、Cluster Network Operator のステータスを検査し、その詳細を表示することができます。

手順

  • 以下のコマンドを実行して、Cluster Network Operator のステータスを表示します。

    $ oc describe clusteroperators/network

7.4. Cluster Network Operator ログの表示

oc logs コマンドを使用して、Cluster Network Operator ログを表示できます。

手順

  • 以下のコマンドを実行して、Cluster Network Operator のログを表示します。

    $ oc logs --namespace=openshift-network-operator deployment/network-operator

7.5. Cluster Network Operator (CNO) の設定

クラスターネットワークの設定は、Cluster Network Operator (CNO) 設定の一部として指定され、cluster という名前のカスタムリソース (CR) オブジェクトに保存されます。CR は operator.openshift.io API グループの Network API のフィールドを指定します。

CNO 設定は、Network.config.openshift.io API グループの Network API からクラスターのインストール時に以下のフィールドを継承します。

clusterNetwork
Pod IP アドレスの割り当てに使用する IP アドレスプール。
serviceNetwork
サービスの IP アドレスプール。
defaultNetwork.type
クラスターネットワークプラグイン。OVNKubernetes は、インストール時にサポートされる唯一のプラグインです。
注記

クラスターをインストールした後は、clusterNetwork IP アドレス範囲のみ変更できます。デフォルトのネットワークタイプは、移行時に OpenShift SDN から OVN-Kubernetes にのみ変更できます。

defaultNetwork オブジェクトのフィールドを cluster という名前の CNO オブジェクトに設定することにより、クラスターのクラスターネットワークプラグイン設定を指定できます。

7.5.1. Cluster Network Operator 設定オブジェクト

Cluster Network Operator (CNO) のフィールドは以下の表で説明されています。

表7.1 Cluster Network Operator 設定オブジェクト
フィールド説明

metadata.name

string

CNO オブジェクトの名前。この名前は常に cluster です。

spec.clusterNetwork

array

Pod ID アドレスの割り当て、サブネット接頭辞の長さのクラスター内の個別ノードへの割り当てに使用される IP アドレスのブロックを指定するリストです。以下に例を示します。

spec:
  clusterNetwork:
  - cidr: 10.128.0.0/19
    hostPrefix: 23
  - cidr: 10.128.32.0/19
    hostPrefix: 23

spec.serviceNetwork

array

サービスの IP アドレスのブロック。OpenShift SDN および OVN-Kubernetes ネットワークプラグインは、サービスネットワークの単一 IP アドレスブロックのみをサポートします。以下に例を示します。

spec:
  serviceNetwork:
  - 172.30.0.0/14

この値は読み取り専用であり、クラスターのインストール時に cluster という名前の Network.config.openshift.io オブジェクトから継承されます。

spec.defaultNetwork

object

クラスターネットワークのネットワークプラグインを設定します。

spec.kubeProxyConfig

object

このオブジェクトのフィールドは、kube-proxy 設定を指定します。OVN-Kubernetes クラスターネットワークプラグインを使用している場合、kube-proxy 設定は機能しません。

defaultNetwork オブジェクト設定

defaultNetwork オブジェクトの値は、以下の表で定義されます。

表7.2 defaultNetwork オブジェクト
フィールド説明

type

string

OVNKubernetes。Red Hat OpenShift Networking ネットワークプラグインは、インストール中に選択されます。この値は、クラスターのインストール後は変更できません。

注記

OpenShift Container Platform は、デフォルトで OVN-Kubernetes ネットワークプラグインを使用します。OpenShift SDN は、新しいクラスターのインストールの選択肢として利用できなくなりました。

ovnKubernetesConfig

object

このオブジェクトは、OVN-Kubernetes ネットワークプラグインに対してのみ有効です。

OpenShift SDN ネットワークプラグインの設定

以下の表では、OpenShift SDN ネットワークプラグインの設定フィールドについて説明します。

表7.3 openshiftSDNConfig オブジェクト
フィールド説明

mode

string

OpenShiftSDN のネットワーク分離モード。

mtu

integer

VXLAN オーバーレイネットワークの最大転送単位 (MTU)。通常、この値は自動的に設定されます。

vxlanPort

integer

すべての VXLAN パケットに使用するポート。デフォルト値は 4789 です。

OpenShift SDN 設定の例

defaultNetwork:
  type: OpenShiftSDN
  openshiftSDNConfig:
    mode: NetworkPolicy
    mtu: 1450
    vxlanPort: 4789

OVN-Kubernetes ネットワークプラグインの設定

次の表では、OVN-Kubernetes ネットワークプラグインの設定フィールドについて説明します。

表7.4 ovnKubernetesConfig オブジェクト
フィールド説明

mtu

integer

Geneve (Generic Network Virtualization Encapsulation) オーバーレイネットワークの MTU (maximum transmission unit)。通常、この値は自動的に設定されます。

genevePort

integer

Geneve オーバーレイネットワークの UDP ポート。

ipsecConfig

object

クラスターの IPsec モードを示すオブジェクト。

policyAuditConfig

object

ネットワークポリシー監査ロギングをカスタマイズする設定オブジェクトを指定します。指定されていない場合は、デフォルトの監査ログ設定が使用されます。

gatewayConfig

object

オプション: egress トラフィックのノードゲートウェイへの送信方法をカスタマイズするための設定オブジェクトを指定します。

注記

egress トラフィックの移行中は、Cluster Network Operator (CNO) が変更を正常にロールアウトするまで、ワークロードとサービストラフィックに多少の中断が発生することが予想されます。

v4InternalSubnet

既存のネットワークインフラストラクチャーが 100.64.0.0/16 IPv4 サブネットと重複している場合は、OVN-Kubernetes による内部使用のために別の IP アドレス範囲を指定できます。IP アドレス範囲が、OpenShift Container Platform インストールで使用される他のサブネットと重複しないようにする必要があります。IP アドレス範囲は、クラスターに追加できるノードの最大数より大きくする必要があります。たとえば、clusterNetwork.cidr 値が 10.128.0.0/14 で、clusterNetwork.hostPrefix 値が /23 の場合、ノードの最大数は 2^(23-14)=512 です。

このフィールドは、インストール後に変更できません。

デフォルト値は 100.64.0.0/16 です。

v6InternalSubnet

既存のネットワークインフラストラクチャーが fd98::/48 IPv6 サブネットと重複する場合は、OVN-Kubernetes による内部使用のために別の IP アドレス範囲を指定できます。IP アドレス範囲が、OpenShift Container Platform インストールで使用される他のサブネットと重複しないようにする必要があります。IP アドレス範囲は、クラスターに追加できるノードの最大数より大きくする必要があります。

このフィールドは、インストール後に変更できません。

デフォルト値は fd98::/48 です。

表7.5 policyAuditConfig オブジェクト
フィールド説明

rateLimit

integer

ノードごとに毎秒生成されるメッセージの最大数。デフォルト値は、1 秒あたり 20 メッセージです。

maxFileSize

integer

監査ログの最大サイズ (バイト単位)。デフォルト値は 50000000 (50MB) です。

maxLogFiles

integer

保持されるログファイルの最大数。

比較先

string

以下の追加の監査ログターゲットのいずれかになります。

libc
ホスト上の journald プロセスの libc syslog() 関数。
udp:<host>:<port>
syslog サーバー。<host>:<port> を syslog サーバーのホストおよびポートに置き換えます。
unix:<file>
<file> で指定された Unix ドメインソケットファイル。
null
監査ログを追加のターゲットに送信しないでください。

syslogFacility

string

RFC5424 で定義される kern などの syslog ファシリティー。デフォルト値は local0 です。

表7.6 gatewayConfig オブジェクト
フィールド説明

routingViaHost

boolean

Pod からホストネットワークスタックへの egress トラフィックを送信するには、このフィールドを true に設定します。インストールおよびアプリケーションがカーネルルーティングテーブルに手動設定されたルートに依存するなど非常に特化されている場合には、egress トラフィックをホストネットワークスタックにルーティングすることを推奨します。デフォルトでは、egress トラフィックは OVN で処理され、クラスターを終了するために処理され、トラフィックはカーネルルーティングテーブルの特殊なルートによる影響を受けません。デフォルト値は false です。

このフィールドで、Open vSwitch ハードウェアオフロード機能との対話が可能になりました。このフィールドをtrueに設定すると、egress トラフィックがホストネットワークスタックで処理されるため、パフォーマンス的に、オフロードによる利点は得られません。

ipForwarding

object

Network リソースの ipForwarding 仕様を使用して、OVN-Kubernetes マネージドインターフェイス上のすべてのトラフィックの IP フォワーディングを制御できます。Kubernetes 関連のトラフィックの IP フォワーディングのみを許可するには、Restricted を指定します。すべての IP トラフィックの転送を許可するには、Global を指定します。新規インストールの場合、デフォルトは Restricted です。OpenShift Container Platform 4.14 以降に更新する場合、デフォルトは Global です。

表7.7 ipsecConfig オブジェクト
フィールド説明

mode

string

IPsec 実装の動作を指定します。次の値のいずれかである必要があります。

  • Disabled: クラスターノードで IPsec が有効になりません。
  • External: 外部ホストとのネットワークトラフィックに対して IPsec が有効になります。
  • Full: Pod トラフィックおよび外部ホストとのネットワークトラフィックに対して IPsec が有効になります。
注記

クラスターのインストール中にのみクラスターネットワークプラグインの設定を変更できます。ただし、インストール後のアクティビティーとして実行時に変更できるgatewayConfigフィールドは除きます。

IPsec が有効な OVN-Kubernetes 設定の例

defaultNetwork:
  type: OVNKubernetes
  ovnKubernetesConfig:
    mtu: 1400
    genevePort: 6081
      ipsecConfig:
        mode: Full

重要

OVNKubernetes を使用すると、IBM Power® でスタック枯渇の問題が発生する可能性があります。

kubeProxyConfig オブジェクト設定 (OpenShiftSDN コンテナーネットワークインターフェイスのみ)

kubeProxyConfig オブジェクトの値は以下の表で定義されます。

表7.8 kubeProxyConfig オブジェクト
フィールド説明

iptablesSyncPeriod

string

iptables ルールの更新期間。デフォルト値は 30s です。有効な接尾辞には、sm、および h などが含まれ、これらについては、Go time パッケージ ドキュメントで説明されています。

注記

OpenShift Container Platform 4.3 以降で強化されたパフォーマンスの向上により、iptablesSyncPeriod パラメーターを調整する必要はなくなりました。

proxyArguments.iptables-min-sync-period

array

iptables ルールを更新する前の最小期間。このフィールドにより、更新の頻度が高くなり過ぎないようにできます。有効な接尾辞には、sm、および h などが含まれ、これらについては、Go time パッケージ で説明されています。デフォルト値:

kubeProxyConfig:
  proxyArguments:
    iptables-min-sync-period:
    - 0s

7.5.2. Cluster Network Operator の設定例

以下の例では、詳細な CNO 設定が指定されています。

Cluster Network Operator オブジェクトのサンプル

apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  clusterNetwork:
  - cidr: 10.128.0.0/14
    hostPrefix: 23
  serviceNetwork:
  - 172.30.0.0/16
  networkType: OVNKubernetes
      clusterNetworkMTU: 8900

7.6. 関連情報

第8章 OpenShift Container Platform の DNS Operator

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

8.1. DNS Operator

DNS Operator は、operator.openshift.io API グループから dns API を実装します。この Operator は、デーモンセットを使用して CoreDNS をデプロイし、デーモンセットのサービスを作成し、kubelet を Pod に対して名前解決に CoreDNS サービス IP を使用するように指示するように設定します。

手順

DNS Operator は、インストール時に Deployment オブジェクトを使用してデプロイされます。

  1. oc get コマンドを使用してデプロイメントのステータスを表示します。

    $ oc get -n openshift-dns-operator deployment/dns-operator

    出力例

    NAME           READY     UP-TO-DATE   AVAILABLE   AGE
    dns-operator   1/1       1            1           23h

  2. oc get コマンドを使用して DNS Operator の状態を表示します。

    $ oc get clusteroperator/dns

    出力例

    NAME      VERSION     AVAILABLE   PROGRESSING   DEGRADED   SINCE
    dns       4.1.0-0.11  True        False         False      92m

    AVAILABLEPROGRESSING および DEGRADED は、Operator のステータスについての情報を提供します。AVAILABLE は、CoreDNS デーモンセットからの 1 つ以上の Pod が Available ステータス条件を報告する場合は True になります。

8.2. DNS Operator managementState の変更

DNS は CoreDNS コンポーネントを管理し、クラスター内の Pod およびサービスの名前解決サービスを提供します。DNS Operator の managementState はデフォルトで Managed に設定されます。これは、DNS Operator がそのリソースをアクティブに管理できることを意味します。これを Unmanaged に変更できます。つまり、DNS Operator がそのリソースを管理していないことを意味します。

以下は、DNS Operator managementState を変更するためのユースケースです。

  • 開発者であり、CoreDNS の問題が修正されているかどうかを確認するために設定変更をテストする必要があります。managementStateUnmanaged に設定すると、DNS Operator により修正が上書きされないようにできます。
  • クラスター管理者であり、CoreDNS の問題が報告されていますが、問題が修正されるまで回避策を適用する必要があります。DNS Operator の managementState フィールドを Unmanaged に設定して、回避策を適用できます。

手順

  • managementState DNS Operator を変更します。

    oc patch dns.operator.openshift.io default --type merge --patch '{"spec":{"managementState":"Unmanaged"}}'

8.3. DNS Pod 配置の制御

DNS Operator には、CoreDNS 用と /etc/hosts ファイルを管理するための 2 つのデーモンセットがあります。/etc/hosts に設定されたデーモンは、イメージのプルをサポートするクラスターイメージレジストリーのエントリーを追加するために、すべてのノードホストで実行する必要があります。セキュリティーポリシーにより、ノードのペア間の通信が禁止され、CoreDNS のデーモンセットがすべてのノードで実行できなくなります。

クラスター管理者は、カスタムノードセレクターを使用して、CoreDNS のデーモンセットを特定のノードで実行するか、実行しないように設定できます。

前提条件

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

手順

  • 特定のノード間の通信を防ぐには、spec.nodePlacement.nodeSelector API フィールドを設定します。

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

      $ oc edit dns.operator/default
    2. spec.nodePlacement.nodeSelector API フィールドにコントロールプレーンノードのみが含まれるノードセレクターを指定します。

       spec:
         nodePlacement:
           nodeSelector:
             node-role.kubernetes.io/worker: ""
  • CoreDNS のデーモンセットをノードで実行されるようにするには、テイントおよび容認を設定します。

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

      $ oc edit dns.operator/default
    2. テイントのテイントキーおよび容認を指定します。

       spec:
         nodePlacement:
           tolerations:
           - effect: NoExecute
             key: "dns-only"
             operators: Equal
             value: abc
             tolerationSeconds: 3600 1
      1
      テイントが dns-only である場合、それは無制限に許容できます。tolerationSeconds は省略できます。

8.4. デフォルト DNS の表示

すべての新規 OpenShift Container Platform インストールには、default という名前の dns.operator があります。

手順

  1. oc describe コマンドを使用してデフォルトの dns を表示します。

    $ oc describe dns.operator/default

    出力例

    Name:         default
    Namespace:
    Labels:       <none>
    Annotations:  <none>
    API Version:  operator.openshift.io/v1
    Kind:         DNS
    ...
    Status:
      Cluster Domain:  cluster.local 1
      Cluster IP:      172.30.0.10 2
    ...

    1
    Cluster Domain フィールドは、完全修飾 Pod およびサービスドメイン名を作成するために使用されるベース DNS ドメインです。
    2
    クラスター IP は、Pod が名前解決のためにクエリーするアドレスです。IP は、サービス CIDR 範囲の 10 番目のアドレスで定義されます。
  2. クラスターのサービス CIDR を見つけるには、oc get コマンドを使用します。

    $ oc get networks.config/cluster -o jsonpath='{$.status.serviceNetwork}'

出力例

[172.30.0.0/16]

8.5. DNS 転送の使用

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

  • すべてのゾーンにネームサーバーを指定します。転送されるゾーンが OpenShift Container Platform によって管理される Ingress ドメインである場合、アップストリームネームサーバーがドメインについて認証される必要があります。
  • アップストリーム DNS サーバーのリストを指定します。
  • デフォルトの転送ポリシーを変更します。
注記

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

手順

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

    $ oc edit dns.operator/default

    以前のコマンドを実行した後に、Operator は Server に基づく追加のサーバー設定ブロックを使用して dns-default という名前の config map を作成して更新します。クエリーに一致するゾーンがサーバーにない場合には、名前解決はアップストリーム 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
    クエリー用にアップストリームサーバーが選択される順序を決定します。RandomRoundRobin、またはSequential のいずれかの値を指定できます。デフォルト値はSequentialです。
    7
    オプション: これを使用して、アップストリームリゾルバーを指定できます。
    8
    SystemResolvConfNetworkの 2 種類のアップストリームを指定できます。SystemResolvConf で、アップストリームが /etc/resolv.conf を使用するように設定して、NetworkNetworkresolver を定義します。1 つまたは両方を指定できます。
    9
    指定したタイプがNetworkの場合には、IP アドレスを指定する必要があります。address フィールドは、有効な IPv4 または IPv6 アドレスである必要があります。
    10
    指定したタイプが Network の場合、必要に応じてポートを指定できます。port フィールドの値は 165535 である必要があります。アップストリームのポートを指定しない場合、デフォルトでポート 853 が試行されます。
  2. 任意: 高度に規制された環境で作業する場合は、要求をアップストリームリゾルバーに転送する際に DNS トラフィックのセキュリティーを確保して、追加の DNS トラフィックおよびデータのプライバシーを確保できるようにする必要がある場合があります。クラスター管理者は、転送された 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 の値は 165535 である必要があります。アップストリームのポートを指定しない場合、デフォルトでポート 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 デーモンセットのローリング更新がトリガーされます。

関連情報

8.6. DNS Operator のステータス

oc describe コマンドを使用して、DNS Operator のステータスを検査し、その詳細を表示することができます。

手順

DNS Operator のステータスを表示します。

$ oc describe clusteroperators/dns

8.7. DNS Operator ログ

oc logs コマンドを使用して、DNS Operator ログを表示できます。

手順

DNS Operator のログを表示します。

$ oc logs -n openshift-dns-operator deployment/dns-operator -c dns-operator

8.8. CoreDNS ログレベルの設定

CoreDNS ログレベルを設定して、ログに記録されたエラーメッセージの情報量を決定できます。CoreDNS ログレベルの有効な値は、NormalDebug、および Trace です。デフォルトの logLevelNormal です。

注記

エラープラグインは常に有効になっています。次の logLevel 設定は、さまざまなエラー応答を報告します。

  • logLevel: Normalは "errors" class: log . { class error } を有効にします。
  • logLevel: Debugは "denial" class: log . { class denial error } を有効にします。
  • logLevel: Traceは "all" class: log . { class all } を有効にします。

手順

  • logLevelDebug に設定するには、次のコマンドを入力します。

    $ oc patch dnses.operator.openshift.io/default -p '{"spec":{"logLevel":"Debug"}}' --type=merge
  • logLevelTrace に設定するには、次のコマンドを入力します。

    $ oc patch dnses.operator.openshift.io/default -p '{"spec":{"logLevel":"Trace"}}' --type=merge

検証

  • 目的のログレベルが設定されていることを確認するには、config map を確認します。

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

8.9. CoreDNS Operator のログレベルの設定

クラスター管理者は、Operator ログレベルを設定して、OpenShift DNS の問題をより迅速に追跡できます。operatorLogLevel の有効な値は、NormalDebug、およびTraceです。Trace には最も詳細にわたる情報が含まれます。デフォルトのoperatorlogLevelNormalです。問題のログレベルには、Trace、Debug、Info、Warning、Error、Fatal および Panic の 7 つがあります。ログレベルの設定後に、その重大度またはそれを超える重大度のログエントリーがログに記録されます。

  • operatorLogLevel: "Normal"logrus.SetLogLevel("Info") を設定します。
  • operatorLogLevel: "Debug"logrus.SetLogLevel("Debug") を設定します。
  • operatorLogLevel: "Trace"logrus.SetLogLevel("Trace") を設定します。

手順

  • operatorLogLevelDebugに設定するには、次のコマンドを入力します。

    $ oc patch dnses.operator.openshift.io/default -p '{"spec":{"operatorLogLevel":"Debug"}}' --type=merge
  • operatorLogLevelTraceに設定するには、次のコマンドを入力します。

    $ oc patch dnses.operator.openshift.io/default -p '{"spec":{"operatorLogLevel":"Trace"}}' --type=merge

8.10. CoreDNS キャッシュのチューニング

CoreDNS によって実行される成功または失敗したキャッシュ (それぞれポジティブキャッシュまたはネガティブキャッシュとも呼ばれます) の最大期間を設定できます。DNS クエリー応答のキャッシュ期間を調整すると、上流の DNS リゾルバーの負荷を軽減できます。

手順

  1. 次のコマンドを実行して、default という名前の DNS Operator オブジェクトを編集します。

    $ oc edit dns.operator.openshift.io/default
  2. Time-to-Live (TTL) キャッシュ値を変更します。

    DNS キャッシングの設定

    apiVersion: operator.openshift.io/v1
    kind: DNS
    metadata:
      name: default
    spec:
      cache:
        positiveTTL: 1h 1
        negativeTTL: 0.5h10m 2

    1
    文字列値 1h は、CoreDNS によってそれぞれの秒数に変換されます。このフィールドを省略した場合、値は 0 と見なされ、クラスターはフォールバックとして内部デフォルト値の 900 を使用します。
    2
    文字列値は、0.5h10m などの単位の組み合わせにすることができ、CoreDNS によってそれぞれの秒数に変換されます。このフィールドを省略した場合、値は 0 と見なされ、クラスターはフォールバックとして内部デフォルト値の 30 を使用します。
    警告

    TTL フィールドを低い値に設定すると、クラスター、上流のリゾルバー、またはその両方の負荷が増加する可能性があります。

第9章 OpenShift Container Platform の Ingress Operator

9.1. OpenShift Container Platform Ingress Operator

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

Ingress Operator を使用すると、ルーティングを処理する 1 つ以上の HAProxy ベースの Ingress Controller をデプロイおよび管理することにより、外部クライアントがサービスにアクセスできるようになります。OpenShift Container Platform Route および Kubernetes Ingress リソースを指定して、トラフィックをルーティングするために Ingress Operator を使用します。endpointPublishingStrategy タイプおよび内部負荷分散を定義する機能などの Ingress Controller 内の設定は、Ingress Controller エンドポイントを公開する方法を提供します。

9.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 リソースのデフォルトホストを生成する際にも使用されます。

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

Infrastructure カスタムリソース (CR) には、組織の特定のニーズを満たすように設定できる任意の設定パラメーターが含まれています。

パラメーター説明

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 コントローラーレプリカの数です。設定されていない場合、デフォルト値は 2 になります。

endpointPublishingStrategy

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

クラウド環境の場合、loadBalancer フィールドを使用して、Ingress Controller のエンドポイント公開ストラテジーを設定します。

GCP、AWS、および Azure では、次の endpointPublishingStrategy フィールドを設定できます。

  • loadBalancer.scope
  • loadBalancer.allowedSourceRanges

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

  • Azure: LoadBalancerService (外部スコープあり)
  • Google Cloud Platform (GCP): LoadBalancerService (外部スコープあり)

ほとんどのプラットフォームでは、endpointPublishingStrategy 値は更新できます。GCP では、次のendpointPublishingStrategyフィールドを設定できます。

  • loadBalancer.scope
  • loadbalancer.providerParameters.gcp.clientAccess

ベアメタルプラットフォームなどの非クラウド環境の場合は、NodePortServiceHostNetwork、または Private フィールドを使用して、Ingress Controller のエンドポイント公開ストラテジーを設定します。

これらのフィールドのいずれかで値を設定しない場合のデフォルト値は、Infrastructure CR の .status.platform 値で指定されたバインディングポートに基づきます。

クラスターのデプロイ後に、endpointPublishingStrategy の値を更新する必要がある場合は、次の endpointPublishingStrategy フィールドを設定できます。

  • hostNetwork.protocol
  • nodePort.protocol
  • private.protocol

defaultCertificate

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

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

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

使用中の証明書 (生成されるか、ユーザー指定の場合かを問わない) は OpenShift Container Platform のビルトイン OAuth サーバーに自動的に統合されます。

namespaceSelector

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

routeSelector

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

nodePlacement

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

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

注記

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

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

tlsSecurityProfile

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

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

OldIntermediate、および 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.0Old または Custom プロファイルを 1.1 に変換します。

clientTLS

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

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

ClientCertificatePolicy サブフィールドは、Required または Optional の 2 つの値のいずれかを受け入れます。ClientCA サブフィールドは、openshift-config namespace にある config map を指定します。config map には 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 によって許可されることを示します。wildcardPolicyWildcardsAllowed から WildcardsDisallowed に更新すると、ワイルドカードポリシーの Subdomain を持つ許可されたルートが機能を停止します。これらのルートは、Ingress Controller によって許可されるように None のワイルドカードポリシーに対して再作成される必要があります。WildcardsDisallowed はデフォルト設定です。

IngressControllerLogging

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

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

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

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

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

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

httpHeaders

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

IngressControllerHTTPHeadersforwardedHeaderPolicy を設定することで、Ingress Controller が ForwardedX-Forwarded-ForX-Forwarded-HostX-Forwarded-PortX-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

httpCompressionは、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 つのリストは requestresponse です。どちらのリストでも、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 要求には、headerBufferBytesheaderBufferMaxRewriteBytes よりも大きくなければなりません。設定されていない場合、デフォルト値は 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-12000 から 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 に設定すると問題の検出と診断が妨げられる可能性があります。これらの要求はポートスキャンによって引き起こされ、空の要求をログに記録すると、侵入の試行が検出されなくなります。

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

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

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

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

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

表9.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 へのアップグレードにより、新規のプロファイル設定が適用され、ロールアウトが生じる可能性があります。

9.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.3Modern プロファイルをサポートしています。

また、Ingress Operator は TLS 1.0Old または 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 セキュリティープロファイルタイプ (OldIntermediate、または 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
     ...

9.3.1.3. 相互 TLS 認証の設定

spec.clientTLS 値を設定して、相互 TLS (mTLS) 認証を有効にするように Ingress Controller を設定できます。clientTLS 値は、クライアント証明書を検証するように Ingress Controller を設定します。この設定には、config map の参照である clientCA 値の設定が含まれます。config map には、クライアントの証明書を検証するために使用される 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
    config map データキーは 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$"

  4. オプションで、次のコマンドを入力して、allowedSubjectPatterns の識別名 (DN) を取得します。
$ openssl  x509 -in custom-cert.pem  -noout -subject
subject= /CN=example.com/ST=NC/C=US/O=Security/OU=OpenShift

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

Ingress Operator は、OpenShift Container Platform の中核となる機能であり、追加の設定なしに有効にできます。

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

手順

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

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

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

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

手順

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

    $ oc describe clusteroperators/ingress

9.6. Ingress Controller ログの表示

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

手順

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

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

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

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

手順

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

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

9.8. カスタム Ingress Controller の作成

クラスター管理者は、新規のカスタム Ingress Controller を作成できます。デフォルトの Ingress Controller は OpenShift Container Platform の更新時に変更される可能性があるため、クラスターの更新後も保持される設定を手動で維持する場合は、カスタム Ingress Controller を作成すると便利です。

この例では、カスタム Ingress Controller の最小限の仕様を提供します。カスタム Ingress Controller をさらにカスタマイズするには、「Ingress Controller の設定」を参照してください。

前提条件

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

手順

  1. カスタム IngressController オブジェクトを定義する YAML ファイルを作成します。

    custom-ingress-controller.yaml ファイルの例

    apiVersion: operator.openshift.io/v1
    kind: IngressController
    metadata:
        name: <custom_name> 1
        namespace: openshift-ingress-operator
    spec:
        defaultCertificate:
            name: <custom-ingress-custom-certs> 2
        replicas: 1 3
        domain: <custom_domain> 4

    1
    IngressController オブジェクトのカスタム を指定します。
    2
    カスタムワイルドカード証明書でシークレットの名前を指定します。
    3
    最小レプリカは ONE である必要があります
    4
    ドメイン名のドメインを指定します。IngressController オブジェクトで指定されるドメインと、証明書に使用されるドメインが一致する必要があります。たとえば、ドメイン値が "custom_domain.mycompany.com" の場合、証明書には SAN *.custom_domain.mycompany.com が必要です (*. がドメインに追加されます)。
  2. 以下のコマンドを実行してオブジェクトを作成します。

    $ oc create -f custom-ingress-controller.yaml

9.9. Ingress Controller の設定

9.9.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 のデプロイメントを更新します。

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

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

前提条件

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

手順

  • カスタム証明書を削除し、OpenShift Container Platform に同梱されている証明書を復元するには、以下のコマンドを入力します。

    $ 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

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

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

前提条件

  1. OpenShift CLI (oc) がインストールされている。
  2. cluster-admin ロールを持つユーザーとして OpenShift Container Platform クラスターにアクセスできる。
  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. 次のコマンドを使用して、サービスアカウントシークレットトークンを手動で作成します。

    重要

    ImageRegistry 機能を無効にした場合、または Cluster Image Registry Operator の設定で統合済みの OpenShift イメージレジストリーを無効にした場合、イメージプルシークレットはサービスアカウントごとに生成されません。この状況では、この手順を実行する必要があります。

    $ oc apply -f - <<EOF
    apiVersion: v1
    kind: Secret
    metadata:
      name: thanos-token
      annotations:
        kubernetes.io/service-account.name: thanos
      type: kubernetes.io/service-account-token
    EOF
  3. サービスアカウントのトークンを使用して、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
  4. 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
  5. 以下のコマンドを入力して、新しいロールをサービスアカウントに追加します。

    $ 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 からのクエリーを使用します。

  6. デフォルトの 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 をターゲットにする必要があります。また、このポートからメトリクスを読み取るには、昇格した権限が必要です。

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

    $ 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

9.9.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 値を変更します。

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

アクセスログを有効にするように Ingress Controller を設定できます。大量のトラフィックを受信しないクラスターがある場合、サイドカーにログインできます。クラスターのトラフィックが多い場合、ロギングスタックの容量を超えないようにしたり、OpenShift Container Platform 外のロギングインフラストラクチャーと統合したりするために、ログをカスタム 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.typeSyslog を指定する必要があります。宛先タイプが 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

9.9.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 を随時高い値に設定します。

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

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

警告

クラウドプロバイダーが Microsoft Azure の場合、ノードを参照するパブリックロードバランサーが少なくとも 1 つ必要です。これがない場合、すべてのノードがインターネットへの egress 接続を失います。

重要

IngressControllerscopeを変更する場合は、カスタムリソース (CR) の作成後に .spec.endpointPublishingStrategy.loadBalancer.scope パラメーターを変更します。

図9.1 LoadBalancer の図

OpenShift Container Platform Ingress LoadBalancerService エンドポイント公開ストラテジー

前述の図では、OpenShift Container Platform 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

9.9.8. GCP での Ingress Controller のグローバルアクセスの設定

内部ロードバランサーで GCP で作成された Ingress Controller は、サービスの内部 IP アドレスを生成します。クラスター管理者は、グローバルアクセスオプションを指定できます。これにより、同じ VPC ネットワーク内の任意のリージョンでクラスターを有効にし、ロードバランサーとしてコンピュートリージョンを有効にして、クラスターで実行されるワークロードに到達できるようにできます。

詳細情報は、GCP ドキュメントの グローバルアクセス について参照してください。

前提条件

  • OpenShift Container Platform クラスターを GCP インフラストラクチャーにデプロイしている。
  • 内部ロードバランサーを使用するように Ingress Controller を設定している。
  • OpenShift CLI (oc) がインストールされている。

手順

  1. グローバルアクセスを許可するように Ingress Controller リソースを設定します。

    注記

    Ingress Controller を作成し、グローバルアクセスのオプションを指定することもできます。

    1. Ingress Controller リソースを設定します。

      $ oc -n openshift-ingress-operator edit ingresscontroller/default
    2. YAML ファイルを編集します。

      サンプル clientAccess 設定を Global に設定します。

        spec:
          endpointPublishingStrategy:
            loadBalancer:
              providerParameters:
                gcp:
                  clientAccess: Global 1
                type: GCP
              scope: Internal
            type: LoadBalancerService

      1
      gcp.clientAccessGlobal に設定します。
    3. 変更を適用するためにファイルを保存します。
  2. 以下のコマンドを実行して、サービスがグローバルアクセスを許可することを確認します。

    $ oc -n openshift-ingress edit svc/router-default -o yaml

    この出力では、グローバルアクセスがアノテーション networking.gke.io/internal-load-balancer-allow-global-access で GCP について有効にされていることを示しています。

9.9.9. 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 を使用します

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

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

警告

クラウドプロバイダーが Microsoft Azure の場合、ノードを参照するパブリックロードバランサーが少なくとも 1 つ必要です。これがない場合、すべてのノードがインターネットへの egress 接続を失います。

重要

IngressControllerscope を変更する場合は、カスタムリソース (CR) の作成後に .spec.endpointPublishingStrategy.loadBalancer.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

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

管理者およびアプリケーション開発者は、同じドメイン名を持つ複数の 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

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

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

9.9.13. HTTP ヘッダーの設定

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

注記

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

9.9.13.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 またはルートのいずれかで定義されたアクションは、ルートアノテーションを使用して設定された値をオーバーライドします。

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

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

表9.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 ルートアノテーション

cookieset-cookie

いいえ

いいえ

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

はい:

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

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

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

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

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

前提条件

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

手順

  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. 変更を適用するためにファイルを保存します。

9.9.15. 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 ポリシーフィールドを AppendReplaceIfNone、または 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 アノテーションをルートごとに設定できます。

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

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

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

警告

Keepalived Ingress Virtual IP (VIP)を使用するクラウド以外のプラットフォーム上のインストーラーでプロビジョニングされるクラスターを使用するデフォルトの Ingress コントローラーは PROXY プロトコルをサポートしません。

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

重要

パススルールートの設定の場合、OpenShift Container Platform クラスターのサーバーは元のクライアントソースの IP アドレスを確認できません。元のクライアントソース IP アドレスを把握する必要がある場合は、クライアントソースの IP アドレスを表示できるように Ingress コントローラーの Ingress アクセスロギングを設定します。

re-encrypt および edge ルートの場合、OpenShift Container Platform ルーターは Forwarded および X-Forwarded-For ヘッダーを設定し、アプリケーションワークロードがクライアントソースの IP アドレスを確認するようにします。

Ingress アクセスログの詳細については、「イングレスアクセスログの設定」を参照してください。

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

重要

PROXY プロトコルまたは TCP のいずれかを使用するように、OpenShift Container Platform と外部ロードバランサーの両方を設定する必要があります。

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

重要

PROXY プロトコルを使用するか、Transmission Control Protocol (TCP)を使用するには、OpenShift Container Platform と外部ロードバランサーの両方を設定する必要があります。

前提条件

  • Ingress Controller を作成している。

手順

  1. CLI で次のコマンドを入力して、Ingress コントローラーリソースを編集します。

    $ oc -n openshift-ingress-operator edit ingresscontroller/default
  2. PROXY 設定を設定します。

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

      PROXY への hostNetwork の設定例

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

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

      PROXY へのサンプル nodePort 設定

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

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

      PROXYへの プライベート 設定の例

      # ...
        spec:
          endpointPublishingStrategy:
            private:
              protocol: PROXY
          type: Private
      # ...

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

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

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

前提条件

  • OpenShift Container Platform クラスターをデプロイしていること。
  • oc コマンドラインインターフェイスがインストールされている。

手順

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

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

      $ oc edit ingresses.config/cluster -o yaml
    2. YAML ファイルを編集します。

      test.example.com への appsDomain の設定例

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

      1
      デフォルトドメインを指定します。インストール後にデフォルトドメインを変更することはできません。
      2
      オプション: アプリケーションルートに使用する OpenShift Container Platform インフラストラクチャーのドメイン。デフォルトの接頭辞である 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

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

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

重要

OpenShift Container Platform には 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 に設定します。

9.9.20. ルーター圧縮の使用

特定の 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"
         ...

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

デフォルトで、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

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

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

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

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

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

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

注記

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

手順

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

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

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

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

    $ 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 config map をコピーします。Operator は、openshift-ingress namespace のパターン <your_ingresscontroller_name>-errorpages に従って config map に名前を付けます。

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

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

    出力例

    NAME                       DATA   AGE
    default-errorpages         2      25s  1

    1
    default の Ingress Controller カスタムリソース (CR) にパッチが適用されているため、config map 名の例は default-errorpages です。
  4. カスタムエラー応答ページを含む config map がルーターボリュームにマウントされることを確認します。config map キーは、カスタム 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

9.9.23. 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 設定パラメーター」セクションの表を参照してください。

9.10. 関連情報

第10章 OpenShift Container Platform での Ingress シャーディング

OpenShift Container Platform では、Ingress Controller はすべてのルートを提供することも、ルートのサブセットを提供することもできます。デフォルトでは、Ingress Controller は、クラスター内の任意の namespace で作成されたすべてのルートを提供します。別の Ingress Controller をクラスターに追加して、選択した特性に基づくルートのサブセットである シャード を作成することにより、ルーティングを最適化できます。ルートをシャードのメンバーとしてマークするには、ルートまたは namespace の メタデータ フィールドでラベルを使用します。Ingress Controller は、選択式 とも呼ばれる セレクター を使用して、ルートのプール全体からルートのサブセットを選択し、サービスを提供します。

Ingress シャーディングは、受信トラフィックを複数の Ingress Controller 間で負荷分散する場合に、トラフィックを分離して特定の Ingress Controller にルーティングする場合、または次のセクションで説明する他のさまざまな理由で役立ちます。

デフォルトでは、各ルートはクラスターのデフォルトドメインを使用します。ただし、代わりにルーターのドメインを使用するようにルートを設定できます。詳細は、Ingress Controller シャーディングのルートの作成 を参照してください。

10.1. Ingress Controller のシャード化

Ingress シャーディング (ルーターシャーディングとも呼ばれます) を使用して、ルート、namespace、またはその両方にラベルを追加することで、一連のルートを複数のルーターに分散できます。Ingress Controller は、対応する一連のセレクターを使用して、指定されたラベルが含まれるルートのみを許可します。各 Ingress シャードは、特定の選択式を使用してフィルタリングされたルートで構成されます。

トラフィックがクラスターに送信される主要なメカニズムとして、Ingress Controller への要求が大きくなる可能性があります。クラスター管理者は、以下を実行するためにルートをシャード化できます。

  • Ingress Controller またはルーターを複数のルートに分散し、変更に対する応答を加速します。
  • 特定のルートを他のルートとは異なる信頼性の保証を持つように割り当てます。
  • 特定の Ingress Controller に異なるポリシーを定義することを許可します。
  • 特定のルートのみが追加機能を使用することを許可します。
  • たとえば、異なるアドレスで異なるルートを公開し、内部ユーザーおよび外部ユーザーが異なるルートを認識できるようにします。
  • blue green デプロイ中に、アプリケーションの別のバージョンにトラフィックを転送します。

Ingress Controller がシャーディングされると、特定のルートがグループ内の 0 個以上の Ingress Controller に受け入れられます。ルートのステータスは、Ingress Controller がルートを受け入れたかどうかを示します。Ingress Controller は、ルートがそのシャードに固有である場合にのみルートを受け入れます。

Ingress Controller は、次の 3 つのシャーディング方法を使用できます。

  • namespace セレクターとラベルが同じ namespace 内のすべてのルートが Ingress シャードに含まれるように、namespace セレクターのみを Ingress Controller に追加します。
  • Ingress Controller にルートセレクターのみを追加して、ルートセレクターとラベルが同じ全ルートが Ingress シャードに含まれるようにします。
  • namespace セレクターとラベルが同じ namespace 内のルートセレクターのラベルがルートと同じ場合に、Ingress シャード内に含まれるように、namespace セレクターとルートセレクターの両方を Ingress Controller に追加します。

シャーディングを使用すると、ルートのサブセットを複数の Ingress Controller に分散できます。これらのサブセットは、重複なし (従来 のシャーディングとも呼ばれる) にすることも、重複 (重複 シャーディングとも呼ばれる) にすることもできます。

10.1.1. 従来のシャーディングの例

Ingress Controller の finops-router は、ラベルセレクター spec.namespaceSelector.matchLabels.namefinance および ops に指定して設定されます。

finops-router の YAML 定義の例

apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name: finops-router
  namespace: openshift-ingress-operator
spec:
  namespaceSelector:
    matchLabels:
      name:
        - finance
        - ops

2 番目の Ingress Controller dev-router は、ラベルセレクター spec.namespaceSelector.matchLabels.namedev に指定して設定されます。

dev-router の YAML 定義の例

apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name: dev-router
  namespace: openshift-ingress-operator
spec:
  namespaceSelector:
    matchLabels:
      name: dev

すべてのアプリケーションルートが個別の namespace にあり、それぞれに name:financename:ops、および name:dev というラベルが付けられている場合、この設定は 2 つの Ingress Controller 間でルートを効果的に分散します。コンソール、認証、およびその他の目的の OpenShift Container Platform ルートは処理しないでください。

上記のシナリオでは、シャード化は重複するセットを持たないパーティション設定の特別なケースとなります。ルートは複数のルーターシャード間で分割されます。

警告

デフォルト の Ingress Controller は、namespaceSelector または routeSelector フィールドに除外対象のルートが含まれていない限り、引き続きすべてのルートを提供します。デフォルトの Ingress Controller からルートを除外する方法の詳細は、この Red Hat ナレッジベースのソリューション と「デフォルトの Ingress Controller のシャーディング」のセクションを参照してください。

10.1.2. 重複シャーディングの例

上記の例の finops-routerdev-router に加えて、ラベルセレクター spec.namespaceSelector.matchLabels.namedevops に指定して設定された devops-router もあります。

Devops-router の YAML 定義の例

apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name: devops-router
  namespace: openshift-ingress-operator
spec:
  namespaceSelector:
    matchLabels:
      name:
        - dev
        - ops

name:dev および name:ops という 名前の namespace のルートは、2 つの異なる Ingress Controller によって処理されるようになりました。この設定では、ルートのサブセットが重複しています。

重複するルートのサブセットを使用すると、より複雑なルーティングルールを作成できます。たとえば、優先度の低いトラフィックを devops-router に送信しながら、優先度の高いトラフィックを専用の finops-router に迂回させることができます。

10.1.3. デフォルトの Ingress Controller のシャーディング

新しい Ingress シャードを作成した後に、デフォルトの Ingress Controller と、新しい Ingress シャードの両方により許可されるルートが存在する場合があります。これは、デフォルトの Ingress Controller にセレクターがなく、デフォルトですべてのルートを許可するためです。

namespace セレクターまたはルートセレクターを使用して、Ingress Controller が特定のラベルが割り当てられたルートの処理を制限できます。次の手順では、namespace セレクターを使用して、デフォルトの Ingress Controller が新しく分割された financeops、および dev ルートにサービスを提供しないように制限します。これにより、Ingress シャードがさらに分離されます。

重要

OpenShift Container Platform のすべての管理ルートを同じ Ingress Controller で保持する必要があります。したがって、これらの重要なルートを除外するセレクターをデフォルトの Ingress Controller に追加することは避けてください。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • プロジェクト管理者としてログインしている。

手順

  1. 次のコマンドを実行して、デフォルトの Ingress Controller を変更します。

    $ oc edit ingresscontroller -n openshift-ingress-operator default
  2. Ingress Controller を編集して、financeops、および dev ラベルのいずれかを持つルートを除外する namespaceSelector を含めます。

    apiVersion: operator.openshift.io/v1
    kind: IngressController
    metadata:
      name: default
      namespace: openshift-ingress-operator
    spec:
      namespaceSelector:
        matchExpressions:
          - key: type
            operator: NotIn
            values:
              - finance
              - ops
              - dev

デフォルトの Ingress Controller では、name:financename:ops、および name:dev という名前の namespace が提供されなくなります。

10.1.4. Ingress シャーディングと DNS

クラスター管理者は、プロジェクト内のルーターごとに個別の DNS エントリーを作成します。ルーターは不明なルートを別のルーターに転送することはありません。

以下の例を考慮してください。

  • Router A はホスト 192.168.0.5 にあり、*.foo.com のルートを持つ。
  • Router B はホスト 192.168.1.9 にあり、*.example.com のルートを持つ。

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

  • *.foo.com A IN 192.168.0.5
  • *.example.com A IN 192.168.1.9

10.1.5. ルートラベルを使用した Ingress Controller のシャード化の設定

ルートラベルを使用した Ingress Controller のシャード化とは、Ingress Controller がルートセレクターによって選択される任意 namespace の任意のルートを提供することを意味します。

図10.1 ルートラベルを使用した Ingress シャーディング

ルートの所属先の namespace に関係なく、特定のルートと一致するラベルが含まれるルートにサービスを提供するさまざまなルートセレクターと複数の Ingress Controller を示す図

Ingress Controller のシャード化は、一連の Ingress Controller 間で着信トラフィックの負荷を分散し、トラフィックを特定の Ingress Controller に分離する際に役立ちます。たとえば、Company A のトラフィックをある Ingress Controller に指定し、Company B を別の Ingress Controller に指定できます。

手順

  1. router-internal.yaml ファイルを編集します。

    # cat router-internal.yaml
    apiVersion: operator.openshift.io/v1
    kind: IngressController
    metadata:
      name: sharded
      namespace: openshift-ingress-operator
    spec:
      domain: <apps-sharded.basedomain.example.net> 1
      nodePlacement:
        nodeSelector:
          matchLabels:
            node-role.kubernetes.io/worker: ""
      routeSelector:
        matchLabels:
          type: sharded
    1
    Ingress Controller が使用するドメインを指定します。このドメインは、デフォルトの Ingress Controller ドメインとは異なる必要があります。
  2. Ingress Controller の router-internal.yaml ファイルを適用します。

    # oc apply -f router-internal.yaml

    Ingress Controller は、type: sharded というラベルのある namespace のルートを選択します。

  3. router-internal.yaml で設定されたドメインを使用して新しいルートを作成します。

    $ oc expose svc <service-name> --hostname <route-name>.apps-sharded.basedomain.example.net

10.1.6. namespace ラベルを使用した Ingress Controller のシャード化の設定

namespace ラベルを使用した Ingress Controller のシャード化とは、Ingress Controller が namespace セレクターによって選択される任意の namespace の任意のルートを提供することを意味します。

図10.2 namespace ラベルを使用した Ingress シャーディング

指定の namespace セレクターと同じラベルが含まれる namespace に所属するルートにサービスを提供するさまざまな namespace セレクターと複数の Ingress Controller を示す図

Ingress Controller のシャード化は、一連の Ingress Controller 間で着信トラフィックの負荷を分散し、トラフィックを特定の Ingress Controller に分離する際に役立ちます。たとえば、Company A のトラフィックをある Ingress Controller に指定し、Company B を別の Ingress Controller に指定できます。

手順

  1. router-internal.yaml ファイルを編集します。

    # cat router-internal.yaml

    出力例

    apiVersion: operator.openshift.io/v1
    kind: IngressController
    metadata:
      name: sharded
      namespace: openshift-ingress-operator
    spec:
      domain: <apps-sharded.basedomain.example.net> 1
      nodePlacement:
        nodeSelector:
          matchLabels:
            node-role.kubernetes.io/worker: ""
      namespaceSelector:
        matchLabels:
          type: sharded

    1
    Ingress Controller が使用するドメインを指定します。このドメインは、デフォルトの Ingress Controller ドメインとは異なる必要があります。
  2. Ingress Controller の router-internal.yaml ファイルを適用します。

    # oc apply -f router-internal.yaml

    Ingress Controller は、type: sharded というラベルのある namespace セレクターによって選択される namespace のルートを選択します。

  3. router-internal.yaml で設定されたドメインを使用して新しいルートを作成します。

    $ oc expose svc <service-name> --hostname <route-name>.apps-sharded.basedomain.example.net

10.2. Ingress Controller シャーディングのルート作成

ルートを使用すると、URL でアプリケーションをホストできます。この場合、ホスト名は設定されず、ルートは代わりにサブドメインを使用します。サブドメインを指定すると、ルートを公開する Ingress Controller のドメインが自動的に使用されます。ルートが複数の Ingress Controller によって公開されている状況では、ルートは複数の URL でホストされます。

以下の手順では、例として hello-openshift アプリケーションを使用して、Ingress Controller シャーディングのルートを作成する方法について説明します。

Ingress Controller のシャード化は、一連の Ingress Controller 間で着信トラフィックの負荷を分散し、トラフィックを特定の Ingress Controller に分離する際に役立ちます。たとえば、Company A のトラフィックをある Ingress Controller に指定し、Company B を別の Ingress Controller に指定できます。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • プロジェクト管理者としてログインしている。
  • あるポートを公開する Web アプリケーションと、そのポートでトラフィックをリッスンする HTTP または TCP エンドポイントがある。
  • シャーディング用に Ingress Controller を設定している。

手順

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

    $ oc new-project hello-openshift
  2. 以下のコマンドを実行してプロジェクトに Pod を作成します。

    $ oc create -f https://raw.githubusercontent.com/openshift/origin/master/examples/hello-openshift/hello-pod.json
  3. 以下のコマンドを実行して、hello-openshift というサービスを作成します。

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

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

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

    1
    ラベルキーとそれに対応するラベル値の両方が、Ingress Controller で指定されたものと一致する必要があります。この例では、Ingress Controller にはラベルキーと値 type: sharded があります。
    2
    ルートは、subdomain フィールドの値を使用して公開されます。subdomain フィールドを指定するときは、ホスト名を未設定のままにしておく必要があります。host フィールドと subdomain フィールドの両方を指定すると、ルートは host フィールドの値を使用し、subdomain フィールドを無視します。
  5. 次のコマンドを実行し、hello-openshift-route.yaml を使用して hello-openshift アプリケーションへのルートを作成します。

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

検証

  • 次のコマンドを使用して、ルートのステータスを取得します。

    $ oc -n hello-openshift get routes/hello-openshift-edge -o yaml

    結果の Route リソースは次のようになります。

    出力例

    apiVersion: route.openshift.io/v1
    kind: Route
    metadata:
      labels:
        type: sharded
      name: hello-openshift-edge
      namespace: hello-openshift
    spec:
      subdomain: hello-openshift
      tls:
        termination: edge
      to:
        kind: Service
        name: hello-openshift
    status:
      ingress:
      - host: hello-openshift.<apps-sharded.basedomain.example.net> 1
        routerCanonicalHostname: router-sharded.<apps-sharded.basedomain.example.net> 2
        routerName: sharded 3

    1
    Ingress Controller またはルーターがルートを公開するために使用するホスト名。host フィールドの値は、Ingress Controller によって自動的に決定され、そのドメインを使用します。この例では、Ingress Controller のドメインは <apps-sharded.basedomain.example.net> です。
    2
    Ingress Controller のホスト名。
    3
    Ingress Controller の名前。この例では、Ingress Controller の名前は sharded です。

関連情報

第11章 OpenShift Container Platform の Ingress Node Firewall Operator

Ingress Node Firewall Operator を使用すると、管理者はノードレベルでファイアウォール設定を管理できます。

11.1. Ingress Node Firewall Operator

Ingress Node Firewall Operator は、ファイアウォール設定で指定および管理するノードにデーモンセットをデプロイすることにより、ノードレベルで ingress ファイアウォールルールを提供します。デーモンセットをデプロイするには、IngressNodeFirewallConfig カスタムリソース (CR) を作成します。Operator は IngressNodeFirewallConfig CR を適用して、nodeSelector に一致するすべてのノードで実行される ingress ノードファイアウォールデーモンセット (daemon) を作成します。

IngressNodeFirewall CR の rule を設定し、nodeSelector を使用して値を "true" に設定してクラスターに適用します。

重要

Ingress Node Firewall Operator は、ステートレスファイアウォールルールのみをサポートします。

ネイティブ XDP ドライバーをサポートしないネットワークインターフェイスコントローラー (NIC) は、より低いパフォーマンスで実行されます。

OpenShift Container Platform 4.14 以降の場合は、RHEL 9.0 以降で Ingress Node Firewall Operator を実行する必要があります。

Ingress Node Firewall Operator は、デフォルトの OpenShift インストールを備えた Amazon Web Services (AWS) または Red Hat OpenShift Service on AWS (ROSA) ではサポートされていません。Red Hat OpenShift Service on AWS のサポートと Ingress の詳細は、Red Hat OpenShift Service on AWS の Ingress Operator を参照してください。

11.2. Ingress Node Firewall Operator のインストール

クラスター管理者は、OpenShift Container Platform CLI または Web コンソールを使用して Ingress Node Firewall Operator をインストールできます。

11.2.1. CLI を使用した Ingress Node Firewall Operator のインストール

クラスター管理者は、CLI を使用して Operator をインストールできます。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • 管理者権限を持つアカウントを持っています。

手順

  1. openshift-ingress-node-firewall namespace を作成するには、次のコマンドを入力します。

    $ cat << EOF| oc create -f -
    apiVersion: v1
    kind: Namespace
    metadata:
      labels:
        pod-security.kubernetes.io/enforce: privileged
        pod-security.kubernetes.io/enforce-version: v1.24
      name: openshift-ingress-node-firewall
    EOF
  2. OperatorGroup CR を作成するには、以下のコマンドを実行します。

    $ cat << EOF| oc create -f -
    apiVersion: operators.coreos.com/v1
    kind: OperatorGroup
    metadata:
      name: ingress-node-firewall-operators
      namespace: openshift-ingress-node-firewall
    EOF
  3. Ingress Node Firewall Operator にサブスクライブします。

    1. Ingress Node Firewall Operator の Subscription CR を作成するには、次のコマンドを入力します。

      $ cat << EOF| oc create -f -
      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
        name: ingress-node-firewall-sub
        namespace: openshift-ingress-node-firewall
      spec:
        name: ingress-node-firewall
        channel: stable
        source: redhat-operators
        sourceNamespace: openshift-marketplace
      EOF
  4. Operator がインストールされていることを確認するには、以下のコマンドを入力します。

    $ oc get ip -n openshift-ingress-node-firewall

    出力例

    NAME            CSV                                         APPROVAL    APPROVED
    install-5cvnz   ingress-node-firewall.4.15.0-202211122336   Automatic   true

  5. Operator のバージョンを確認するには、次のコマンドを入力します。

    $ oc get csv -n openshift-ingress-node-firewall

    出力例

    NAME                                        DISPLAY                          VERSION               REPLACES                                    PHASE
    ingress-node-firewall.4.15.0-202211122336   Ingress Node Firewall Operator   4.15.0-202211122336   ingress-node-firewall.4.15.0-202211102047   Succeeded

11.2.2. Web コンソールを使用した Ingress Node Firewall Operator のインストール

クラスター管理者は、Web コンソールを使用して Operator をインストールできます。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • 管理者権限を持つアカウントを持っています。

手順

  1. Ingress Node Firewall Operator をインストールします。

    1. OpenShift Container Platform Web コンソールで、OperatorsOperatorHub をクリックします。
    2. 利用可能な Operator のリストから Ingress Node Firewall Operator を選択し、Install をクリックします。
    3. Install Operator ページの Installed Namespace で、Operator recommend Namespace を選択します。
    4. Install をクリックします。
  2. Ingress Node Firewall Operator が正常にインストールされていることを確認します。

    1. OperatorsInstalled Operators ページに移動します。
    2. Ingress Node Firewall Operatoropenshift-ingress-node-firewall プロジェクトにリストされ、StatusInstallSucceeded であることを確認します。

      注記

      インストール時に、Operator は Failed ステータスを表示する可能性があります。インストールが後に InstallSucceeded メッセージを出して正常に実行される場合は、Failed メッセージを無視できます。

      Operator の StatusInstallSucceeded でない場合は、次の手順を使用してトラブルシューティングを行います。

      • Operator Subscriptions および Install Plans タブで、Status の下の失敗またはエラーの有無を確認します。
      • WorkloadsPods ページに移動し、openshift-ingress-node-firewall プロジェクトの Pod のログを確認します。
      • YAML ファイルの namespace を確認してください。アノテーションが抜けている場合は、次のコマンドを使用して、アノテーションworkload.openshift.io/allowed=management を Operator namespace に追加できます。

        $ oc annotate ns/openshift-ingress-node-firewall workload.openshift.io/allowed=management
        注記

        単一ノードの OpenShift クラスターの場合、openshift-ingress-node-firewall namespace には workload.openshift.io/allowed=management アノテーションが必要です。

11.3. Ingress Node Firewall Operator のデプロイ

前提条件

  • Ingress Node Firewall Operator がインストールされます。

手順

Ingress Node Firewall Operator をデプロイするには、Operator のデーモンセットをデプロイする IngressNodeFirewallConfig カスタムリソースを作成します。ファイアウォールルールを適用することで、1 つまたは複数の IngressNodeFirewall CRD をノードにデプロイできます。

  1. ingressnodefirewallconfig という名前の openshift-ingress-node-firewall namespace 内に IngressNodeFirewallConfig を作成します。
  2. 次のコマンドを実行して、Ingress Node Firewall Operator ルールをデプロイします。

    $ oc apply -f rule.yaml

11.3.1. ingress ノードファイアウォール設定オブジェクト

Ingress Node Firewall 設定オブジェクトのフィールドについて、次の表で説明します。

表11.1 ingress ノードファイアウォール設定オブジェクト
フィールド説明

metadata.name

string

CR オブジェクトの名前。ファイアウォールルールオブジェクトの名前は ingressnodefirewallconfig である必要があります。

metadata.namespace

string

Ingress Firewall Operator CR オブジェクトの namespace。IngressNodeFirewallConfig CR は、openshift-ingress-node-firewall namespace 内に作成する必要があります。

spec.nodeSelector

string

指定されたノードラベルを介してノードをターゲットにするために使用されるノード選択制約。以下に例を示します。

spec:
  nodeSelector:
    node-role.kubernetes.io/worker: ""
注記

デーモンセットを開始するには、nodeSelector で使用される 1 つのラベルがノードのラベルと一致する必要があります。たとえば、ノードラベル node-role.kubernetes.io/worker および node-type.kubernetes.io/vm がノードに適用される場合、デーモンセットを開始するには、nodeSelector を使用して少なくとも 1 つのラベルを設定する必要があります。

注記

Operator は CR を使用し、nodeSelector に一致するすべてのノード上に Ingress ノードファイアウォールデーモンセットを作成します。

Ingress Node Firewall Operator の設定例

次の例では、完全な Ingress ノードファイアウォール設定が指定されています。

ingress ノードファイアウォール設定オブジェクトの例

apiVersion: ingressnodefirewall.openshift.io/v1alpha1
kind: IngressNodeFirewallConfig
metadata:
  name: ingressnodefirewallconfig
  namespace: openshift-ingress-node-firewall
spec:
  nodeSelector:
    node-role.kubernetes.io/worker: ""

注記

Operator は CR を使用し、nodeSelector に一致するすべてのノード上に Ingress ノードファイアウォールデーモンセットを作成します。

11.3.2. ingress ノードファイアウォールルールオブジェクト

ingress ノードファイアウォールルールオブジェクトのフィールドについて、次の表で説明します。

表11.2 ingress ノードファイアウォールルールオブジェクト
フィールド説明

metadata.name

string

CR オブジェクトの名前。

interfaces

array

このオブジェクトのフィールドは、ファイアウォールルールを適用するインターフェイスを指定します。たとえば、-en0-en1 です。

nodeSelector

array

nodeSelector を使用して、ファイアウォールルールを適用するノードを選択できます。名前付き nodeselector ラベルの値を true に設定して、ルールを適用します。

ingress

object

ingress を使用すると、クラスター上のサービスへの外部アクセスを許可するルールを設定できます。

Ingress オブジェクトの設定

Ingress オブジェクトの値は、次の表で定義されています。

表11.3 ingress オブジェクト
フィールド説明

sourceCIDRs

array

CIDR ブロックを設定できます。異なるアドレスファミリーから複数の CIDR を設定できます。

注記

異なる CIDR を使用すると、同じ順序ルールを使用できます。CIDR が重複する同じノードおよびインターフェイスに対して複数の IngressNodeFirewall オブジェクトがある場合、order フィールドは最初に適用されるルールを指定します。ルールは昇順で適用されます。

rules

array

Ingress ファイアウォール rules.order オブジェクトは、source.CIDR ごとに 1 から順に並べられ、CIDR ごとに最大 100 のルールがあります。低次ルールが最初に実行されます。

rules.protocolConfig.protocol は次のプロトコルをサポートします: TCP、UDP、SCTP、ICMP、および ICMPv6。ICMP および ICMPv6 ルールは、ICMP および ICMPv6 のタイプまたはコードと照合できます。TCP、UDP、および SCTP ルールは、<start : end-1> 形式を使用して、単一の宛先ポートまたはポートの範囲に対して照合できます。

rules.action を設定してルールの適用を allow するか、deny してルールを禁止します。

注記

ingress ファイアウォールルールは、無効な設定をブロックする検証 Webhook を使用して検証されます。検証 Webhook は、API サーバーや SSH などの重要なクラスターサービスをブロックすることを防ぎます。

ingress ノードファイアウォールルールオブジェクトの例

次の例では、完全な Ingress ノードファイアウォール設定が指定されています。

Ingress ノードファイアウォールの設定例

apiVersion: ingressnodefirewall.openshift.io/v1alpha1
kind: IngressNodeFirewall
metadata:
  name: ingressnodefirewall
spec:
  interfaces:
  - eth0
  nodeSelector:
    matchLabels:
      <ingress_firewall_label_name>: <label_value> 1
  ingress:
  - sourceCIDRs:
       - 172.16.0.0/12
    rules:
    - order: 10
      protocolConfig:
        protocol: ICMP
        icmp:
          icmpType: 8 #ICMP Echo request
      action: Deny
    - order: 20
      protocolConfig:
        protocol: TCP
        tcp:
          ports: "8000-9000"
      action: Deny
  - sourceCIDRs:
       - fc00:f853:ccd:e793::0/64
    rules:
    - order: 10
      protocolConfig:
        protocol: ICMPv6
        icmpv6:
          icmpType: 128 #ICMPV6 Echo request
      action: Deny

1
<label_name> と <label_value> はノード上に存在する必要があり、ingressfirewallconfig CR を実行するノードに適用される nodeselector ラベルと値に一致する必要があります。<label_value> は、true または false です。nodeSelector ラベルを使用すると、ノードのグループを個別にターゲットにして、ingressfirewallconfig CR の使用に異なるルールを適用できます。
ゼロトラスト Ingress ノードファイアウォールルールオブジェクトの例

ゼロトラストの Ingress ノードファイアウォールルールは、マルチインターフェイスクラスターに追加のセキュリティーを提供できます。たとえば、ゼロトラストの Ingress ノードファイアウォールルールを使用して、SSH を除く特定のインターフェイス上のすべてのトラフィックをドロップできます。

次の例では、ゼロトラスト Ingress ノードファイアウォールルールセットの完全な設定が指定されています。

重要

次の場合、ユーザーはアプリケーションが使用するすべてのポートを許可リストに追加して、適切な機能を確保する必要があります。

ゼロトラストの Ingress ノードファイアウォールルールの例

apiVersion: ingressnodefirewall.openshift.io/v1alpha1
kind: IngressNodeFirewall
metadata:
 name: ingressnodefirewall-zero-trust
spec:
 interfaces:
 - eth1 1
 nodeSelector:
   matchLabels:
     <ingress_firewall_label_name>: <label_value> 2
 ingress:
 - sourceCIDRs:
      - 0.0.0.0/0 3
   rules:
   - order: 10
     protocolConfig:
       protocol: TCP
       tcp:
         ports: 22
     action: Allow
   - order: 20
     action: Deny 4

1
ネットワークインターフェイスクラスター
2
<label_name> と <label_value> は、ingressfirewallconfig CR を適用する特定のノードに適用される nodeSelector ラベルと値に一致する必要があります。
3
0.0.0.0/0 は、任意の CIDR に一致するように設定されています
4
Deny に設定された action

11.4. Ingress Node Firewall Operator ルールの表示

手順

  1. 次のコマンドを実行して、現在のルールをすべて表示します。

    $ oc get ingressnodefirewall
  2. 返された <resource> 名のいずれかを選択し、次のコマンドを実行してルールまたは設定を表示します。

    $ oc get <resource> <name> -o yaml

11.5. Ingress Node Firewall Operator のトラブルシューティング

  • 次のコマンドを実行して、インストールされている Ingress ノードファイアウォールのカスタムリソース定義 (CRD) を一覧表示します。

    $ oc get crds | grep ingressnodefirewall

    出力例

    NAME               READY   UP-TO-DATE   AVAILABLE   AGE
    ingressnodefirewallconfigs.ingressnodefirewall.openshift.io       2022-08-25T10:03:01Z
    ingressnodefirewallnodestates.ingressnodefirewall.openshift.io    2022-08-25T10:03:00Z
    ingressnodefirewalls.ingressnodefirewall.openshift.io             2022-08-25T10:03:00Z

  • 次のコマンドを実行して、Ingress Node Firewall Operator の状態を表示します。

    $ oc get pods -n openshift-ingress-node-firewall

    出力例

    NAME                                       READY  STATUS         RESTARTS  AGE
    ingress-node-firewall-controller-manager   2/2    Running        0         5d21h
    ingress-node-firewall-daemon-pqx56         3/3    Running        0         5d21h

    次のフィールドは、Operator のステータスに関する情報を提供します: READYSTATUSAGE、および RESTARTS。Ingress Node Firewall Operator が割り当てられたノードに設定されたデーモンをデプロイしている場合、STATUS フィールドは Running になります。

  • 次のコマンドを実行して、すべての ingress ファイアウォールノード Pod のログを収集します。

    $ oc adm must-gather – gather_ingress_node_firewall

    ログは、/sos_commands/ebpf にある eBPF bpftool 出力を含む sos ノードのレポートで利用できます。これらのレポートには、Ingress ファイアウォール XDP がパケット処理を処理し、統計を更新し、イベントを発行するときに使用または更新されたルックアップテーブルが含まれます。

第12章 手動 DNS 管理のための Ingress Controller の設定

クラスター管理者として Ingress Controller を作成すると、Operator は DNS レコードを自動的に管理します。必要な DNS ゾーンがクラスター DNS ゾーンと異なる場合、または DNS ゾーンがクラウドプロバイダーの外部でホストされている場合、これにはいくつかの制限があります。

クラスター管理者は、Ingress Controller を設定して、自動 DNS 管理を停止し、手動 DNS 管理を開始することができます。dnsManagementPolicy を設定して、いつ自動または手動で管理するかを指定します。

Ingress Controller を Managed から Unmanaged DNS 管理ポリシーに変更すると、Operator はクラウドでプロビジョニングされた以前のワイルドカード DNS レコードをクリーンアップしません。Ingress Controller を Unmanaged から Managed DNS 管理ポリシーに変更すると、Operator は、クラウドプロバイダーに DNS レコードが存在しない場合は作成を試み、DNS レコードがすでに存在する場合は更新を試みます。

重要

dnsManagementPolicyunmanaged に設定すると、クラウドプロバイダーでワイルドカード DNS レコードのライフサイクルを手動で管理する必要があります。

12.1. Managed DNS 管理ポリシー

Ingress Controller の Managed DNS 管理ポリシーにより、クラウドプロバイダーのワイルドカード DNS レコードのライフサイクルが Operator によって自動的に管理されるようになります。

12.2. Unmanaged DNS 管理ポリシー

Ingress Controller の Unmanaged DNS 管理ポリシーにより、クラウドプロバイダーのワイルドカード DNS レコードのライフサイクルが自動的に管理されず、代わりにクラスター管理者の責任になります。

注記

AWS クラウドプラットフォームでは、Ingress Controller のドメインが dnsConfig.Spec.BaseDomain と一致しない場合、DNS 管理ポリシーは自動的に Unmanaged に設定されます。

12.3. Unmanaged DNS 管理ポリシーを使用したカスタム Ingress Controller の作成

クラスター管理者は、Unmanaged DNS 管理ポリシーを使用して、新しいカスタム Ingress Controller を作成できます。

前提条件

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

手順

  1. 以下を含む sample-ingress.yaml という名前のカスタムリソース (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: External 3
          dnsManagementPolicy: Unmanaged 4
    1
    IngressController オブジェクトの名前で <name> を指定します。
    2
    前提として作成した DNS レコードをもとに domain を指定します。
    3
    scopeExternal として指定して、ロードバランサーを外部に公開します。
    4
    dnsManagementPolicy は、Ingress Controller がロードバランサーに関連付けられたワイルドカード DNS レコードのライフサイクルを管理しているかどうかを示します。有効な値は Managed および Unmanaged です。デフォルト値は Managed です。
  2. 変更を適用するためにファイルを保存します。

    oc apply -f <name>.yaml 1

12.4. 既存の Ingress Controller の変更

クラスター管理者は、既存の Ingress Controller を変更して、DNS レコードのライフサイクルを手動で管理できます。

前提条件

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

手順

  1. 選択した IngressController を変更して dnsManagementPolicy を設定します。

    SCOPE=$(oc -n openshift-ingress-operator get ingresscontroller <name> -o=jsonpath="{.status.endpointPublishingStrategy.loadBalancer.scope}")
    
    oc -n openshift-ingress-operator patch ingresscontrollers/<name> --type=merge --patch='{"spec":{"endpointPublishingStrategy":{"type":"LoadBalancerService","loadBalancer":{"dnsManagementPolicy":"Unmanaged", "scope":"${SCOPE}"}}}}'
  2. オプション: クラウドプロバイダーで関連付けられている DNS レコードを削除できます。

12.5. 関連情報

第13章 Ingress Controller エンドポイント公開戦略の設定

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

重要

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

詳細は、RHOSP インストールドキュメントの「RHOSP Cloud Controller Manager オプションの設定」セクションを参照してください。

13.1. Ingress Controller エンドポイントの公開ストラテジー

NodePortService エンドポイントの公開ストラテジー

NodePortService エンドポイントの公開ストラテジーは、Kubernetes NodePort サービスを使用して Ingress Controller を公開します。

この設定では、Ingress Controller のデプロイメントはコンテナーのネットワークを使用します。NodePortService はデプロイメントを公開するために作成されます。特定のノードポートは OpenShift Container Platform によって動的に割り当てられますが、静的ポートの割り当てをサポートするために、管理される NodePortService のノードポートフィールドへの変更が保持されます。

図13.1 NodePortService の図

OpenShift Container Platform Ingress NodePort のエンドポイント公開戦略

前述の図では、OpenShift Container Platform Ingress NodePort エンドポイントの公開戦略に関する以下のような概念を示しています。

  • クラスターで利用可能なノードにはすべて、外部からアクセス可能な独自の IP アドレスが割り当てられています。クラスター内で動作するサービスは、全ノードに固有の NodePort にバインドされます。
  • たとえば、クライアントが図中の IP アドレス 10.0.128.4 に接続してダウンしているノードに接続した場合に、ノードポートは、サービスを実行中で利用可能なノードにクライアントを直接接続します。このシナリオでは、ロードバランシングは必要ありません。イメージが示すように、10.0.128.4 アドレスがダウンしており、代わりに別の IP アドレスを使用する必要があります。
注記

Ingress Operator は、サービスの .spec.ports[].nodePort フィールドへの更新を無視します。

デフォルトで、ポートは自動的に割り当てられ、各種の統合用のポート割り当てにアクセスできます。ただし、既存のインフラストラクチャーと統合するために静的ポートの割り当てが必要になることがありますが、これは動的ポートに対応して簡単に再設定できない場合があります。静的ノードポートとの統合を実行するには、マネージドのサービスリソースを直接更新できます。

詳細は、NodePort についての Kubernetes サービスについてのドキュメント を参照してください。

HostNetwork エンドポイントの公開ストラテジー

HostNetwork エンドポイントの公開ストラテジーは、Ingress Controller がデプロイされるノードポートで Ingress Controller を公開します。

HostNetwork エンドポイント公開ストラテジーを持つ Ingress Controller には、ノードごとに単一の Pod レプリカのみを設定できます。n のレプリカを使用する場合、それらのレプリカをスケジュールできる n 以上のノードを使用する必要があります。各 Pod はスケジュールされるノードホストでポート 80 および 443 を要求するので、同じノードで別の Pod がそれらのポートを使用している場合、レプリカをノードにスケジュールすることはできません。

HostNetwork オブジェクトには、オプションのバインディングポートのデフォルト値が httpPort:80httpsPort:443statsPort:1936hostNetwork フィールドがあります。ネットワークに異なるバインディングポートを指定することで、HostNetwork ストラテジーに対して、同じノードに複数の Ingress コントローラーをデプロイできます。

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

13.1.1. Ingress Controller エンドポイント公開スコープの内部への設定

クラスター管理者がクラスターをプライベートに指定せずに新しいクラスターをインストールすると、scopeExternalに設定されたデフォルトの Ingress Controller が作成されます。クラスター管理者は、External スコープの Ingress Controller をInternalに変更できます。

前提条件

  • oc CLI がインストールされている。

手順

  • Externalスコープの Ingress Controller をInternalに変更するには、次のコマンドを入力します。

    $ oc -n openshift-ingress-operator patch ingresscontrollers/default --type=merge --patch='{"spec":{"endpointPublishingStrategy":{"type":"LoadBalancerService","loadBalancer":{"scope":"Internal"}}}}'
  • Ingress Controller のステータスを確認するには、次のコマンドを入力します。

    $ oc -n openshift-ingress-operator get ingresscontrollers/default -o yaml
    • ステータス状態が Progressing の場合は、さらにアクションを実行する必要があるかどうかを示します。たとえば、ステータスの状態によっては、次のコマンドを入力して、サービスを削除する必要があることを示している可能性があります。

      $ oc -n openshift-ingress delete services/router-default

      サービスを削除すると、Ingress Operator はサービスをInternalとして再作成します。

13.1.2. Ingress Controller エンドポイント公開スコープの外部への設定

クラスター管理者がクラスターをプライベートに指定せずに新しいクラスターをインストールすると、scopeExternalに設定されたデフォルトの Ingress Controller が作成されます。

Ingress Controller のスコープは、インストール中またはインストール後にInternalになるように設定でき、クラスター管理者はInternal の Ingress Controller をExternalに変更できます。

重要

一部のプラットフォームでは、サービスを削除して再作成する必要があります。

スコープを変更すると、場合によっては数分間、Ingress トラフィックが中断される可能性があります。これが該当するのは、サービスを削除して再作成する必要があるプラットフォームです。理由は、この手順により、OpenShift Container Platform が既存のサービスロードバランサーのプロビジョニングを解除して新しいサービスロードバランサーをプロビジョニングし、DNS を更新する可能性があるためです。

前提条件

  • oc CLI がインストールされている。

手順

  • Internalスコープの入力コントローラーをExternalに変更するには、次のコマンドを入力します。

    $ oc -n openshift-ingress-operator patch ingresscontrollers/private --type=merge --patch='{"spec":{"endpointPublishingStrategy":{"type":"LoadBalancerService","loadBalancer":{"scope":"External"}}}}'
  • Ingress Controller のステータスを確認するには、次のコマンドを入力します。

    $ oc -n openshift-ingress-operator get ingresscontrollers/default -o yaml
    • ステータス状態が Progressing の場合は、さらにアクションを実行する必要があるかどうかを示します。たとえば、ステータスの状態によっては、次のコマンドを入力して、サービスを削除する必要があることを示している可能性があります。

      $ oc -n openshift-ingress delete services/router-default

      サービスを削除すると、Ingress Operator はサービスをExternalとして再作成します。

13.2. 関連情報

第14章 エンドポイントへの接続の確認

Cluster Network Operator (CNO) は、クラスター内のリソース間の接続ヘルスチェックを実行するコントローラーである接続性チェックコントローラーを実行します。ヘルスチェックの結果を確認して、調査している問題が原因で生じる接続の問題を診断したり、ネットワーク接続を削除したりできます。

14.1. 実行する接続ヘルスチェック

クラスターリソースにアクセスできることを確認するには、以下のクラスター API サービスのそれぞれに対して TCP 接続が行われます。

  • Kubernetes API サーバーサービス
  • Kubernetes API サーバーエンドポイント
  • OpenShift API サーバーサービス
  • OpenShift API サーバーエンドポイント
  • ロードバランサー

サービスおよびサービスエンドポイントがクラスター内のすべてのノードで到達可能であることを確認するには、以下の各ターゲットに対して TCP 接続が行われます。

  • ヘルスチェックターゲットサービス
  • ヘルスチェックターゲットエンドポイント

14.2. 接続ヘルスチェックの実装

接続チェックコントローラーは、クラスター内の接続検証チェックをオーケストレーションします。接続テストの結果は、openshift-network-diagnostics namespace の PodNetworkConnectivity オブジェクトに保存されます。接続テストは、1 分ごとに並行して実行されます。

Cluster Network Operator (CNO) は、接続性ヘルスチェックを送受信するためにいくつかのリソースをクラスターにデプロイします。

ヘルスチェックのソース
このプログラムは、Deployment オブジェクトで管理される単一の Pod レプリカセットにデプロイします。このプログラムは PodNetworkConnectivity オブジェクトを消費し、各オブジェクトで指定される spec.targetEndpoint に接続されます。
ヘルスチェックのターゲット
クラスターのすべてのノードにデーモンセットの一部としてデプロイされた Pod。Pod はインバウンドのヘルスチェックをリッスンします。すべてのノードにこの Pod が存在すると、各ノードへの接続をテストすることができます。

14.3. PodNetworkConnectivityCheck オブジェクトフィールド

PodNetworkConnectivityCheck オブジェクトフィールドについては、以下の表で説明されています。

表14.1 PodNetworkConnectivityCheck オブジェクトフィールド
フィールド説明

metadata.name

string

以下の形式のオブジェクトの名前: <source>-to-<target><target> で記述される宛先には、以下のいずれかの文字列が含まれます。

  • load-balancer-api-external
  • load-balancer-api-internal
  • kubernetes-apiserver-endpoint
  • kubernetes-apiserver-service-cluster
  • network-check-target
  • openshift-apiserver-endpoint
  • openshift-apiserver-service-cluster

metadata.namespace

string

オブジェクトが関連付けられる namespace。この値は、常に openshift-network-diagnostics になります。

spec.sourcePod

string

接続チェックの起点となる Pod の名前 (例: network-check-source-596b4c6566-rgh92)。

spec.targetEndpoint

string

api.devcluster.example.com:6443 などの接続チェックのターゲット。

spec.tlsClientCert

object

使用する TLS 証明書の設定。

spec.tlsClientCert.name

string

使用される TLS 証明書の名前 (ある場合)。デフォルト値は空の文字列です。

status

object

接続テストの状態を表す、および最近の接続の成功および失敗についてのログ。

status.conditions

array

接続チェックと最新のステータスと以前のステータス。

status.failures

array

試行に失敗した接続テストのログ。

status.outages

array

停止が生じた期間が含まれる接続テストのログ。

status.successes

array

試行に成功した接続テストのログ。

以下の表は、status.conditions 配列内のオブジェクトのフィールドについて説明しています。

表14.2 status.conditions
フィールド説明

lastTransitionTime

string

接続の条件がある状態から別の状態に移行した時間。

message

string

人が判読できる形式の最後の移行についての詳細。

reason

string

マシンの読み取り可能な形式での移行の最後のステータス。

status

string

状態のテータス。

type

string

状態のタイプ。

以下の表は、status.conditions 配列内のオブジェクトのフィールドについて説明しています。

表14.3 status.outages
フィールド説明

end

string

接続の障害が解決された時点からのタイムスタンプ。

endLogs

array

接続ログエントリー (停止の正常な終了に関連するログエントリーを含む)。

message

string

人が判読できる形式の停止について詳細情報の要約。

start

string

接続の障害が最初に検知された時点からのタイムスタンプ。

startLogs

array

元の障害を含む接続ログのエントリー。

接続ログフィールド

接続ログエントリーのフィールドの説明は以下の表で説明されています。オブジェクトは以下のフィールドで使用されます。

  • status.failures[]
  • status.successes[]
  • status.outages[].startLogs[]
  • status.outages[].endLogs[]
表14.4 接続ログオブジェクト
フィールド説明

latency

string

アクションの期間を記録します。

message

string

ステータスを人が判読できる形式で提供します。

reason

string

ステータスの理由をマシンが判読できる形式で提供します。値は TCPConnectTCPConnectErrorDNSResolveDNSError のいずれかになります。

success

boolean

ログエントリーが成功または失敗であるかを示します。

time

string

接続チェックの開始時間。

14.4. エンドポイントのネットワーク接続の確認

クラスター管理者は、API サーバー、ロードバランサー、サービス、または Pod などのエンドポイントの接続を確認できます。

前提条件

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

手順

  1. 現在の PodNetworkConnectivityCheck オブジェクトをリスト表示するには、以下のコマンドを入力します。

    $ oc get podnetworkconnectivitycheck -n openshift-network-diagnostics

    出力例

    NAME                                                                                                                                AGE
    network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0   75m
    network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-1   73m
    network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-2   75m
    network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-kubernetes-apiserver-service-cluster                               75m
    network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-kubernetes-default-service-cluster                                 75m
    network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-load-balancer-api-external                                         75m
    network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-load-balancer-api-internal                                         75m
    network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-network-check-target-ci-ln-x5sv9rb-f76d1-4rzrp-master-0            75m
    network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-network-check-target-ci-ln-x5sv9rb-f76d1-4rzrp-master-1            75m
    network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-network-check-target-ci-ln-x5sv9rb-f76d1-4rzrp-master-2            75m
    network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-network-check-tar