Menu Close
ネットワーク
クラスターネットワークの設定および管理
概要
第1章 ネットワークについて
クラスター管理者は、クラスターで実行されるアプリケーションを外部トラフィックに公開し、ネットワーク接続のセキュリティーを保護するための複数のオプションがあります。
- ノードポートやロードバランサーなどのサービスタイプ
-
Ingress
やRoute
などの API リソース
デフォルトで、Kubernetes は各 Podに、Pod 内で実行しているアプリケーションの内部 IP アドレスを割り当てます。Pod とそのコンテナーはネットワークネットワーク接続が可能ですが、クラスター外のクライアントにはネットワークアクセスがありません。こうすることで、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 に基礎となるネットワークインフラストラクチャーへの特権アクセスを付与します。
1.1. OpenShift Container Platform DNS
フロントエンドサービスやバックエンドサービスなど、複数のサービスを実行して複数の Pod で使用している場合、フロントエンド Pod がバックエンドサービスと通信できるように、ユーザー名、サービス IP などの環境変数を作成します。サービスが削除され、再作成される場合には、新規の IP アドレスがそのサービスに割り当てられるので、フロントエンド Pod がサービス IP の環境変数の更新された値を取得するには、これを再作成する必要があります。さらに、バックエンドサービスは、フロントエンド Pod を作成する前に作成し、サービス IP が正しく生成され、フロントエンド Pod に環境変数として提供できるようにする必要があります。
そのため、OpenShift Container Platform には DNS が組み込まれており、これにより、サービスは、サービス IP/ポートと共にサービス DNS によって到達可能になります。
1.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 コントローラー をデプロイおよび管理することにより、外部クライアントがサービスにアクセスできるようになります。OpenShift Container Platform Route
および Kubernetes Ingress
リソースを指定して、トラフィックをルーティングするために Ingress Operator を使用します。endpointPublishingStrategy
タイプおよび内部負荷分散を定義する機能などのIngress コントローラー内の設定は、Ingress コントローラーエンドポイントを公開する方法を提供します。
1.2.1. ルートと Ingress の比較
OpenShift Container Platform の Kubernetes Ingress リソースは、クラスター内で Pod として実行される共有ルーターサービスと共に Ingress コントローラーを実装します。Ingress トラフィックを管理する最も一般的な方法は Ingress コントローラーを使用することです。他の通常の Pod と同様にこの Pod をスケーリングし、複製できます。このルーターサービスは、オープンソースのロードバランサーソリューションである HAProxy をベースとしています。
OpenShift Container Platform ルートは、クラスターのサービスに Ingress トラフィックを提供します。ルートは、Blue-Green デプロイメント向けに TLS 再暗号化、TLS パススルー、分割トラフィックなどの標準の Kubernetes Ingress コントローラーでサポートされない可能性のある高度な機能を提供します。
Ingress トラフィックは、ルートを介してクラスターのサービスにアクセスします。ルートおよび Ingress は、Ingress トラフィックを処理する主要なリソースです。Ingress は、外部要求を受け入れ、ルートに基づいてそれらを委譲するなどのルートと同様の機能を提供します。ただし、Ingress では、特定タイプの接続(HTTP/2、HTTPS およびサーバー名 ID(SNI)、ならび証明書を使用した TLS のみを許可できます。OpenShift Container Platform では、ルートは、Ingress リソースで指定される各種の条件を満たすために生成されます。
第2章 ホストへのアクセス
OpenShift Container Platform インスタンスにアクセスして、セキュアなシェル (SSH) アクセスでコントロールプレーンノードにアクセスするために bastion ホストを作成する方法を学びます。
2.1. インストーラーでプロビジョニングされるインフラストラクチャークラスターでの Amazon Web Services のホストへのアクセス
OpenShift Container Platform インストーラーは、OpenShift Container Platform クラスターにプロビジョニングされる Amazon Elastic Compute Cloud (Amazon EC2) インスタンスのパブリック IP アドレスを作成しません。OpenShift Container Platform ホストに対して SSH を実行できるようにするには、以下の手順を実行する必要があります。
手順
-
openshift-install
コマンドで作成される仮想プライベートクラウド (VPC) に対する SSH アクセスを可能にするセキュリティーグループを作成します。 - インストーラーが作成したパブリックサブネットのいずれかに Amazon EC2 インスタンスを作成します。
パブリック 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 でキーを指定することができます。
Amazon EC2 インスタンスをプロビジョニングし、これに対して SSH を実行した後に、OpenShift Container Platform インストールに関連付けた SSH キーを追加する必要があります。このキーは bastion インスタンスのキーとは異なる場合がありますが、異なるキーにしなければならない訳ではありません。
注記直接の SSH アクセスは、障害復旧を目的とする場合にのみ推奨されます。Kubernetes API が応答する場合、特権付き Pod を代わりに実行します。
-
oc get nodes
を実行し、出力を検査し、マスターであるノードのいずれかを選択します。ホスト名はip-10-0-1-163.ec2.internal
に類似したものになります。 Amazon EC2 に手動でデプロイした bastion SSH ホストから、そのコントロールプレーンホストに SSH を実行します。インストール時に指定したものと同じ SSH キーを使用するようにします。
$ ssh -i <ssh-key-path> core@<master-hostname>
第3章 OpenShift Container Platform における Cluster Network Operator
Cluster Network Operator (CNO) は、インストール時にクラスター用に選択される Container Network Interface (CNI) デフォルトネットワークプロバイダープラグインを含む、OpenShift Container Platform クラスターの各種のクラスターネットワークコンポーネントをデプロイし、これらを管理します。
3.1. Cluster Network Operator
Cluster Network Operator は、operator.openshift.io
API グループから network
API を実装します。Operator は、デーモンセットを使用して OpenShift SDN デフォルト Container Network Interface (CNI) ネットワークプロバイダープラグイン、またはクラスターのインストール時に選択したデフォルトネットワークプロバイダープラグインをデプロイします。
手順
Cluster Network Operator は、インストール時に Kubernetes Deployment
としてデプロイされます。
以下のコマンドを実行して Deployment のステータスを表示します。
$ oc get -n openshift-network-operator deployment/network-operator
出力例
NAME READY UP-TO-DATE AVAILABLE AGE network-operator 1/1 1 1 56m
以下のコマンドを実行して、Cluster Network Operator の状態を表示します。
$ oc get clusteroperator/network
出力例
NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE network 4.5.4 True False False 50m
以下のフィールドは、Operator のステータス (
AVAILABLE
、PROGRESSING
、およびDEGRADED
) についての情報を提供します。AVAILABLE
フィールドは、Cluster Network Operator が Available ステータス条件を報告する場合にTrue
になります。
3.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>
3.3. Cluster Network Operator のステータス表示
oc describe
コマンドを使用して、Cluster Network Operator のステータスを検査し、その詳細を表示することができます。
手順
以下のコマンドを実行して、Cluster Network Operator のステータスを表示します。
$ oc describe clusteroperators/network
3.4. Cluster Network Operator ログの表示
oc logs
コマンドを使用して、Cluster Network Operator ログを表示できます。
手順
以下のコマンドを実行して、Cluster Network Operator のログを表示します。
$ oc logs --namespace=openshift-network-operator deployment/network-operator
3.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
- OpenShift SDN または OVN-Kubernetes などのクラスターネットワークプロバイダー。
クラスターのインストール後に、直前のセクションで一覧表示されているフィールドを変更することはできません。
defaultNetwork
オブジェクトのフィールドを cluster
という名前の CNO オブジェクトに設定することにより、クラスターのクラスターネットワークプロバイダー設定を指定できます。
3.5.1. Cluster Network Operator 設定オブジェクト
Cluster Network Operator (CNO) のフィールドは以下の表で説明されています。
表3.1 Cluster Network Operator 設定オブジェクト
フィールド | タイプ | 詳細 |
---|---|---|
|
|
CNO オブジェクトの名前。この名前は常に |
|
| Pod ID アドレスの割り当て、サブネットプレフィックスの長さのクラスター内の個別ノードへの割り当てに使用される IP アドレスのブロックを指定する一覧です。以下は例になります。 spec: clusterNetwork: - cidr: 10.128.0.0/19 hostPrefix: 23 - cidr: 10.128.32.0/19 hostPrefix: 23
この値は読み取り専用であり、クラスターのインストール時に |
|
| サービスの IP アドレスのブロック。OpenShift SDN および OVN-Kubernetes Container Network Interface (CNI) ネットワークプロバイダーは、サービスネットワークの単一 IP アドレスブロックのみをサポートします。以下は例になります。 spec: serviceNetwork: - 172.30.0.0/14
この値は読み取り専用であり、クラスターのインストール時に |
|
| クラスターネットワークの Container Network Interface (CNI) ネットワークプロバイダーを設定します。 |
|
| このオブジェクトのフィールドは、kube-proxy 設定を指定します。OVN-Kubernetes クラスターネットワークプロバイダーを使用している場合、kube-proxy 設定は機能しません。 |
defaultNetwork オブジェクト設定
defaultNetwork
オブジェクトの値は、以下の表で定義されます。
表3.2 defaultNetwork
オブジェクト
フィールド | タイプ | 詳細 |
---|---|---|
|
|
注記 OpenShift Container Platform はデフォルトで、OpenShift SDN Container Network Interface (CNI) クラスターネットワークプロバイダーを使用します。 |
|
| このオブジェクトは OpenShift SDN クラスターネットワークプロバイダーにのみ有効です。 |
|
| このオブジェクトは OVN-Kubernetes クラスターネットワークプロバイダーにのみ有効です。 |
OpenShift SDN CNI クラスターネットワークプロバイダーの設定
以下の表は、OpenShift SDN Container Network Interface (CNI) クラスターネットワークプロバイダーの設定フィールドについて説明しています。
表3.3 openshiftSDNConfig
オブジェクト
フィールド | タイプ | 詳細 |
---|---|---|
|
| OpenShiftSDN のネットワーク分離モード。 |
|
| VXLAN オーバーレイネットワークの最大転送単位 (MTU)。通常、この値は自動的に設定されます。 |
|
|
すべての VXLAN パケットに使用するポート。デフォルト値は |
クラスターのインストール時にのみクラスターネットワークプロバイダーの設定を変更することができます。
OpenShift SDN 設定の例
defaultNetwork: type: OpenShiftSDN openshiftSDNConfig: mode: NetworkPolicy mtu: 1450 vxlanPort: 4789
OVN-Kubernetes CNI クラスターネットワークプロバイダーの設定
以下の表は OVN-Kubernetes CNI クラスターネットワークプロバイダーの設定フィールドについて説明しています。
表3.4 ovnKubernetesConfig
object
フィールド | タイプ | 詳細 |
---|---|---|
|
| Geneve (Generic Network Virtualization Encapsulation) オーバーレイネットワークの MTU (maximum transmission unit)。通常、この値は自動的に設定されます。 |
|
| Geneve オーバーレイネットワークの UDP ポート。 |
|
| フィールドがある場合、IPsec はクラスターに対して有効にされます。 |
|
| ネットワークポリシー監査ロギングをカスタマイズする設定オブジェクトを指定します。指定されていない場合は、デフォルトの監査ログ設定が使用されます。 |
表3.5 policyAuditConfig
object
フィールド | タイプ | 詳細 |
---|---|---|
| integer |
ノードごとに毎秒生成されるメッセージの最大数。デフォルト値は、1 秒あたり |
| integer |
監査ログの最大サイズ (バイト単位)。デフォルト値は |
| string | 以下の追加の監査ログターゲットのいずれかになります。
|
| string |
RFC5424 で定義される |
クラスターのインストール時にのみクラスターネットワークプロバイダーの設定を変更することができます。
OVN-Kubernetes 設定の例
defaultNetwork: type: OVNKubernetes ovnKubernetesConfig: mtu: 1400 genevePort: 6081 ipsecConfig: {}
kubeProxyConfig オブジェクト設定
kubeProxyConfig
オブジェクトの値は以下の表で定義されます。
表3.6 kubeProxyConfig
オブジェクト
フィールド | タイプ | 詳細 |
---|---|---|
|
|
注記
OpenShift Container Platform 4.3 以降で強化されたパフォーマンスの向上により、 |
|
|
kubeProxyConfig: proxyArguments: iptables-min-sync-period: - 0s |
3.5.2. Cluster Network Operator の設定例
以下の例では、詳細な CNO 設定が指定されています。
Cluster Network Operator オブジェクトのサンプル
apiVersion: operator.openshift.io/v1 kind: Network metadata: name: cluster spec: clusterNetwork: 1 - cidr: 10.128.0.0/14 hostPrefix: 23 serviceNetwork: 2 - 172.30.0.0/16 defaultNetwork: 3 type: OpenShiftSDN openshiftSDNConfig: mode: NetworkPolicy mtu: 1450 vxlanPort: 4789 kubeProxyConfig: iptablesSyncPeriod: 30s proxyArguments: iptables-min-sync-period: - 0s
3.6. 関連情報
第4章 OpenShift Container Platform の DNS Operator
DNS Operator は、Pod に対して名前解決サービスを提供するために CoreDNS をデプロイし、これを管理し、OpenShift Container Platform での DNS ベースの Kubernetes サービス検出を可能にします。
4.1. DNS Operator
DNS Operator は、operator.openshift.io
API グループから dns
API を実装します。この Operator は、デーモンセットを使用して CoreDNS をデプロイし、デーモンセットのサービスを作成し、 kubelet を Pod に対して名前解決に CoreDNS サービス IP を使用するように指示するように設定します。
手順
DNS Operator は、インストール時に Deployment
オブジェクトを使用してデプロイされます。
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
oc get
コマンドを使用して DNS Operator の状態を表示します。$ oc get clusteroperator/dns
出力例
NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE dns 4.1.0-0.11 True False False 92m
AVAILABLE
、PROGRESSING
およびDEGRADED
は、Operator のステータスについての情報を提供します。AVAILABLE
は、CoreDNS デーモンセットからの 1 つ以上の Pod がAvailable
ステータス条件を報告する場合はTrue
になります。
4.2. DNS Operator managementState の変更
DNS は CoreDNS コンポーネントを管理し、クラスター内の Pod およびサービスの名前解決サービスを提供します。DNS Operator の managementState
はデフォルトで Managed
に設定されます。これは、DNS Operator がそのリソースをアクティブに管理できることを意味します。これを Unmanaged
に変更できます。つまり、DNS Operator がそのリソースを管理していないことを意味します。
以下は、DNS Operator managementState
を変更するためのユースケースです。
-
開発者であり、CoreDNS の問題が修正されているかどうかを確認するために設定変更をテストする必要があります。
managementState
をUnmanaged
に設定すると、DNS Operator により修正が上書きされないようにできます。 -
クラスター管理者であり、CoreDNS の問題が報告されていますが、問題が修正されるまで回避策を適用する必要があります。DNS Operator の
managementState
フィールドをUnmanaged
に設定して、回避策を適用できます。
手順
managementState
DNS Operator を変更します。oc patch dns.operator.openshift.io default --type merge --patch '{"spec":{"managementState":"Unmanaged"}}'
4.3. DNS Pod 配置の制御
DNS Operator には、CoreDNS 用と /etc/hosts
ファイルを管理するための 2 つのデーモンセットがあります。/etc/hosts
に設定されたデーモンは、イメージのプルをサポートするクラスターイメージレジストリーのエントリーを追加するために、すべてのノードホストで実行する必要があります。セキュリティーポリシーにより、ノードのペア間の通信が禁止され、CoreDNS のデーモンセットがすべてのノードで実行できなくなります。
クラスター管理者は、カスタムノードセレクターを使用して、CoreDNS のデーモンセットを特定のノードで実行するか、または実行しないように設定できます。
前提条件
-
oc
CLI をインストールしていること。 -
cluster-admin
権限を持つユーザーとしてクラスターにログインしていること。
手順
特定のノード間の通信を防ぐには、
spec.nodePlacement.nodeSelector
API フィールドを設定します。default
という名前の DNS Operator オブジェクトを変更します。$ oc edit dns.operator/default
spec.nodePlacement.nodeSelector
API フィールドにコントロールプレーンノードのみが含まれるノードセレクターを指定します。spec: nodePlacement: nodeSelector: node-role.kubernetes.io/worker: ""
CoreDNS のデーモンセットをノードで実行されるようにするには、テイントおよび容認を設定します。
default
という名前の DNS Operator オブジェクトを変更します。$ oc edit dns.operator/default
テイントのテイントキーおよび容認を指定します。
spec: nodePlacement: tolerations: - effect: NoExecute key: "dns-only" operators: Equal value: abc tolerationSeconds: 3600 1
- 1
- テイントが
dns-only
である場合、それは無制限に許容できます。tolerationSeconds
は省略できます。
4.4. デフォルト DNS の表示
すべての新規 OpenShift Container Platform インストールには、default
という名前の dns.operator
があります。
手順
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 ...
クラスターのサービス CIDR を見つけるには、
oc get
コマンドを使用します。$ oc get networks.config/cluster -o jsonpath='{$.status.serviceNetwork}'
出力例
[172.30.0.0/16]
4.5. DNS 転送の使用
DNS 転送を使用すると、指定のゾーンにどのネームサーバーを使用するかを指定することで、ゾーンごとに /etc/resolv.conf
で特定される転送設定をオーバーライドできます。転送されるゾーンが OpenShift Container Platform によって管理される Ingress ドメインである場合、アップストリームネームサーバーがドメインについて認証される必要があります。
手順
default
という名前の DNS Operator オブジェクトを変更します。$ oc edit dns.operator/default
これにより、
Server
に基づく追加のサーバー設定ブロックを使用してdns-default
という名前の ConfigMap を作成し、更新できます。クエリーに一致するゾーンを持つサーバーがない場合、名前解決は/etc/resolv.conf
で指定されたネームサーバーにフォールバックします。DNS の例
apiVersion: operator.openshift.io/v1 kind: DNS metadata: name: default spec: servers: - name: foo-server 1 zones: 2 - example.com forwardPlugin: upstreams: 3 - 1.1.1.1 - 2.2.2.2:5353 - name: bar-server zones: - bar.com - example.com forwardPlugin: upstreams: - 3.3.3.3 - 4.4.4.4:5454
注記servers
が定義されていないか、または無効な場合、ConfigMap にはデフォルトサーバーのみが含まれます。ConfigMap を表示します。
$ 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 { policy sequential } cache 30 reload } kind: ConfigMap metadata: labels: dns.operator.openshift.io/owning-dns: default name: dns-default namespace: openshift-dns
- 1
forwardPlugin
への変更により、CoreDNS デーモンセットのローリングアップデートがトリガーされます。
関連情報
- DNS 転送の詳細は、CoreDNS forward のドキュメント を参照してください。
4.6. DNS Operator のステータス
oc describe
コマンドを使用して、DNS Operator のステータスを検査し、その詳細を表示することができます。
手順
DNS Operator のステータスを表示します。
$ oc describe clusteroperators/dns
4.7. DNS Operator ログ
oc logs
コマンドを使用して、DNS Operator ログを表示できます。
手順
DNS Operator のログを表示します。
$ oc logs -n openshift-dns-operator deployment/dns-operator -c dns-operator
第5章 OpenShift Container Platform の Ingress Operator
5.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 コントローラー をデプロイおよび管理することにより、外部クライアントがサービスにアクセスできるようになります。OpenShift Container Platform Route
および Kubernetes Ingress
リソースを指定して、トラフィックをルーティングするために Ingress Operator を使用します。endpointPublishingStrategy
タイプおよび内部負荷分散を定義する機能などのIngress コントローラー内の設定は、Ingress コントローラーエンドポイントを公開する方法を提供します。
5.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 コントローラーのドメインとして使用します。
-
OpenShift API Server Operator は、クラスター Ingress 設定からのドメインを使用します。このドメインは、明示的なホストを指定しない
Route
リソースのデフォルトホストを生成する際にも使用されます。
5.3. Ingress コントローラー設定パラメーター
ingresscontrollers.operator.openshift.io
リソースは以下の設定パラメーターを提供します。
パラメーター | 詳細 |
---|---|
|
空の場合、デフォルト値は |
|
|
|
設定されていない場合、デフォルト値は
ほとんどのプラットフォームの場合、 |
|
シークレットには以下のキーおよびデータが含まれる必要があります: *
設定されていない場合、ワイルドカード証明書は自動的に生成され、使用されます。証明書は Ingress コントーラーの 使用中の証明書 (生成されるか、ユーザー指定の場合かを問わない) は OpenShift Container Platform のビルトイン OAuth サーバーに自動的に統合されます。 |
|
|
|
|
|
設定されていない場合は、デフォルト値が使用されます。 注記
nodePlacement: nodeSelector: matchLabels: kubernetes.io/os: linux tolerations: - effect: NoSchedule operator: Exists |
|
これが設定されていない場合、デフォルト値は
Ingress コントローラーの最小 TLS バージョンは 注記
設定されたセキュリティープロファイルの暗号および最小 TLS バージョンが 重要
Ingress Operator は TLS |
|
|
|
|
|
|
|
デフォルトでは、ポリシーは
これらの調整は、クリアテキスト、edge terminationd、および re-encrypt ルートにのみ適用され、HTTP/1 を使用する場合にのみ適用されます。
要求ヘッダーの場合、これらの調整は |
|
|
|
|
|
|
|
これらの接続は、ロードバランサーのヘルスプローブまたは Web ブラウザーの投機的接続(事前接続)から取得され、無視しても問題はありません。ただし、これらの要求はネットワークエラーによって引き起こされる可能性があります。そのため、このフィールドを |
すべてのパラメーターはオプションです。
5.3.1. Ingress コントローラーの TLS セキュリティープロファイル
TLS セキュリティープロファイルは、サーバーに接続する際に接続クライアントが使用できる暗号を規制する方法をサーバーに提供します。
5.3.1.1. TLS セキュリティープロファイルについて
TLS (Transport Layer Security) セキュリティープロファイルを使用して、さまざまな OpenShift Container Platform コンポーネントに必要な TLS 暗号を定義できます。OpenShift Container Platform の TLS セキュリティープロファイルは、Mozilla が推奨する設定 に基づいています。
コンポーネントごとに、以下の TLS セキュリティープロファイルのいずれかを指定できます。
表5.1 TLS セキュリティープロファイル
プロファイル | 詳細 |
---|---|
| このプロファイルは、レガシークライアントまたはライブラリーでの使用を目的としています。このプロファイルは、Old 後方互換性 の推奨設定に基づいています。
注記 Ingress コントローラーの場合、TLS の最小バージョンは 1.0 から 1.1 に変換されます。 |
| このプロファイルは、大多数のクライアントに推奨される設定です。これは、Ingress コントローラー、kubelet、およびコントロールプレーンのデフォルトの TLS セキュリティープロファイルです。このプロファイルは、Intermediate 互換性 の推奨設定に基づいています。
|
| このプロファイルは、後方互換性を必要としない Modern のクライアントでの使用を目的としています。このプロファイルは、Modern 互換性 の推奨設定に基づいています。
|
| このプロファイルを使用すると、使用する TLS バージョンと暗号を定義できます。 警告
無効な設定により問題が発生する可能性があるため、 |
事前定義されたプロファイルタイプのいずれかを使用する場合、有効なプロファイル設定はリリース間で変更される可能性があります。たとえば、リリース X.Y.Z にデプロイされた Intermediate プロファイルを使用する仕様がある場合、リリース X.Y.Z+1 へのアップグレードにより、新規のプロファイル設定が適用され、ロールアウトが生じる可能性があります。
5.3.1.2. Ingress コントローラーの TLS セキュリティープロファイルの設定
Ingress コントローラーの 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 コントローラーの TLS 接続の最小 TLS バージョンと TLS 暗号を定義します。
設定された TLS セキュリティープロファイルの暗号と最小 TLS バージョンは、Status.Tls Profile
配下の IngressController
カスタムリソース (CR) と Spec.Tls Security Profile
配下の設定された TLS セキュリティープロファイルで確認できます。Custom
TLS セキュリティープロファイルの場合、特定の暗号と最小 TLS バージョンは両方のパラメーターの下に一覧表示されます。
HAProxy Ingress Controller イメージは、TLS1.3
とModern
プロファイルをサポートしています。
また、Ingress Operator は TLS 1.0
の Old
または Custom
プロファイルを 1.1
に変換します。
前提条件
-
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできる。
手順
openshift-ingress-operator
プロジェクトのIngressController
CR を編集して、TLS セキュリティープロファイルを設定します。$ oc edit IngressController default -n openshift-ingress-operator
spec.tlsSecurityProfile
フィールドを追加します。Custom
プロファイルのサンプルIngressController
CRapiVersion: 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 ...
- 変更を適用するためにファイルを保存します。
検証
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 ...
5.3.1.3. 相互 TLS 認証の設定
spec.clientTLS
値を設定して、相互 TLS (mTLS) 認証を有効にするように Ingress コントローラーを設定できます。clientTLS
値は、クライアント証明書を検証するように Ingress コントローラーを設定します。この設定には、設定マップの参照である clientCA
値の設定が含まれます。設定マップには、クライアントの証明書を検証するために使用される PEM でエンコードされた CA 証明書バンドルが含まれます。必要に応じて、証明書サブジェクトフィルターの一覧を設定できます。
clientCA
の値が X509v3 証明書失効リスト (CRL)の分散ポイントを指定する場合、Ingress Operator は CRL をダウンロードし、Ingress コントローラーがこれを認識するように設定します。有効な証明書を提供しない要求は拒否されます。
前提条件
-
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできる。
手順
openshift-config
namespace にある設定マップを作成します。$ oc create configmap router-ca-certs-default --from-file=ca-bundle.pem=client-ca.crt -n openshift-config
注記設定マップデータキーは
ca-bundle.pem
で、data の値は PEM 形式の CA 証明書である必要があります。openshift-ingress-operator
プロジェクトでIngressController
リソースを編集します。$ oc edit IngressController default -n openshift-ingress-operator
spec.clientTLS フィールドおよびサブフィールドを追加して相互 TLS を設定します。
フィルタリングパターンを指定する
clientTLS
プロファイルのサンプルIngressController
CRapiVersion: 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$"
5.3.2. Ingress コントローラーエンドポイントの公開ストラテジー
NodePortService
エンドポイントの公開ストラテジー
NodePortService
エンドポイントの公開ストラテジーは、Kubernetes NodePort サービスを使用して Ingress コントローラーを公開します。
この設定では、Ingress コントローラーのデプロイメントはコンテナーのネットワークを使用します。NodePortService
はデプロイメントを公開するために作成されます。特定のノードポートは OpenShift Container Platform によって動的に割り当てられますが、静的ポートの割り当てをサポートするために、管理される NodePortService
のノードポートフィールドへの変更が保持されます。
図5.1 NodePortService の図

前述の図では、OpenShift Container Platform Ingress NodePort エンドポイントの公開戦略に関する以下のような概念を示しています。
- クラスターで利用可能なノードにはすべて、外部からアクセス可能な独自の IP アドレスが割り当てられています。クラスター内で動作するサービスは、全ノードに固有の NodePort にバインドされます。
-
グラフィックで
10.0.128.4
IP アドレスを接続して、クライアントがダウンしているノードに接続すると、ノードポートはクライアントを、サービスを実行している利用可能なノードに直接接続します。このシナリオでは、ロードバランシングは必要ありません。イメージが示すように、1.128.4
アドレスがダウンし、代わりに別の IP アドレスを使用する必要があります。
Ingress Operator は、サービスの .spec.ports[].nodePort
フィールドへの更新を無視します。
デフォルトで、ポートは自動的に割り当てられ、各種の統合用のポート割り当てにアクセスできます。ただし、既存のインフラストラクチャーと統合するために静的ポートの割り当てが必要になることがありますが、これは動的ポートに対応して簡単に再設定できない場合があります。静的ノードポートとの統合を実行するには、管理対象のサービスリソースを直接更新できます。
詳細は、NodePort
についての Kubernetes サービスについてのドキュメント を参照してください。
HostNetwork
エンドポイントの公開ストラテジー
HostNetwork
エンドポイントの公開ストラテジーは、Ingress コントローラーがデプロイされるノードポートで Ingress コントローラーを公開します。
HostNetwork
エンドポイント公開ストラテジーを持つ Ingress コントローラーには、ノードごとに単一の Pod レプリカのみを設定できます。n のレプリカを使用する場合、それらのレプリカをスケジュールできる n 以上のノードを使用する必要があります。各 Pod はスケジュールされるノードホストでポート 80
および 443
を要求するので、同じノードで別の Pod がそれらのポートを使用している場合、レプリカをノードにスケジュールすることはできません。
5.4. デフォルト Ingress コントローラーの表示
Ingress Operator は、OpenShift Container Platform の中核となる機能であり、追加の設定なしに有効にできます。
すべての新規 OpenShift Container Platform インストールには、ingresscontroller
の名前付きのデフォルトがあります。これは、追加の Ingress コントローラーで補足できます。デフォルトの ingresscontroller
が削除される場合、Ingress Operator は 1 分以内にこれを自動的に再作成します。
手順
デフォルト Ingress コントローラーを表示します。
$ oc describe --namespace=openshift-ingress-operator ingresscontroller/default
5.5. Ingress Operator ステータスの表示
Ingress Operator のステータスを表示し、検査することができます。
手順
Ingress Operator ステータスを表示します。
$ oc describe clusteroperators/ingress
5.6. Ingress コントローラーログの表示
Ingress コントローラーログを表示できます。
手順
Ingress コントローラーログを表示します。
$ oc logs --namespace=openshift-ingress-operator deployments/ingress-operator
5.7. Ingress コントローラーステータスの表示
特定の Ingress コントローラーのステータスを表示できます。
手順
Ingress コントローラーのステータスを表示します。
$ oc describe --namespace=openshift-ingress-operator ingresscontroller/<name>
5.8. Ingress コントローラーの設定
5.8.1. カスタムデフォルト証明書の設定
管理者として、 Secret リソースを作成し、IngressController
カスタムリソース (CR) を編集して Ingress コントローラーがカスタム証明書を使用するように設定できます。
前提条件
- 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 コントローラーはデプロイメントストラテジーを使用して再デプロイされます。
tls.crt
およびtls.key
ファイルを使用して、カスタム証明書を含む Secret リソースをopenshift-ingress
namespace に作成します。$ oc --namespace openshift-ingress create secret tls custom-certs-default --cert=tls.crt --key=tls.key
IngressController CR を、新規証明書シークレットを参照するように更新します。
$ oc patch --type=merge --namespace openshift-ingress-operator ingresscontrollers/default \ --patch '{"spec":{"defaultCertificate":{"name":"custom-certs-default"}}}'
更新が正常に行われていることを確認します。
$ oc get --namespace openshift-ingress-operator ingresscontrollers/default \ --output jsonpath='{.spec.defaultCertificate}'
出力例
map[name:custom-certs-default]
ヒントまたは、以下の 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 コントローラーのデプロイメントを更新します。
5.8.2. Ingress コントローラーのスケーリング
Ingress コントローラーは、スループットを増大させるための要件を含む、ルーティングのパフォーマンスや可用性に関する各種要件に対応するために手動でスケーリングできます。oc
コマンドは、IngressController
リソースのスケーリングに使用されます。以下の手順では、デフォルトの IngressController
をスケールアップする例を示します。
スケーリングは、必要な数のレプリカを作成するのに時間がかかるため、すぐに実行できるアクションではありません。
手順
デフォルト
IngressController
の現在の利用可能なレプリカ数を表示します。$ oc get -n openshift-ingress-operator ingresscontrollers/default -o jsonpath='{$.status.availableReplicas}'
出力例
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
デフォルトの
IngressController
が指定したレプリカ数にスケーリングされていることを確認します。$ oc get -n openshift-ingress-operator ingresscontrollers/default -o jsonpath='{$.status.availableReplicas}'
出力例
3
ヒントまたは、以下の YAML を適用して Ingress コントローラーを 3 つのレプリカにスケーリングすることもできます。
apiVersion: operator.openshift.io/v1 kind: IngressController metadata: name: default namespace: openshift-ingress-operator spec: replicas: 3 1
- 1
- 異なる数のレプリカが必要な場合は
replicas
値を変更します。
5.8.3. Ingress アクセスロギングの設定
アクセスログを有効にするように Ingress コントローラーを設定できます。大量のトラフィックを受信しないクラスターがある場合、サイドカーにログインできます。クラスターのトラフィックが多い場合、ロギングスタックの容量を超えないようにしたり、OpenShift Container Platform 外のロギングインフラストラクチャーと統合したりするために、ログをカスタム syslog エンドポイントに転送することができます。アクセスログの形式を指定することもできます。
コンテナーロギングは、既存の Syslog ロギングインフラストラクチャーがない場合や、Ingress コントローラーで問題を診断する際に短期間使用する場合に、低トラフィックのクラスターのアクセスログを有効にするのに役立ちます。
アクセスログが OpenShift Logging スタックの容量を超える可能性があるトラフィックの多いクラスターや、ロギングソリューションが既存の Syslog ロギングインフラストラクチャーと統合する必要のある環境では、syslog が必要です。Syslog のユースケースは重複する可能性があります。
前提条件
-
cluster-admin
権限を持つユーザーとしてログインしている。
手順
サイドカーへの Ingress アクセスロギングを設定します。
Ingress アクセスロギングを設定するには、
spec.logging.access.destination
を使用して宛先を指定する必要があります。サイドカーコンテナーへのロギングを指定するには、Container
spec.logging.access.destination.type
を指定する必要があります。以下の例は、コンテナーContainer
の宛先に対してログ記録する Ingress コントローラー定義です。apiVersion: operator.openshift.io/v1 kind: IngressController metadata: name: default namespace: openshift-ingress-operator spec: replicas: 2 logging: access: destination: type: Container
Ingress コントローラーをサイドカーに対してログを記録するように設定すると、Operator は Ingress コントローラー Pod 内に
logs
という名前のコンテナーを作成します。$ oc -n openshift-ingress logs deployment.apps/router-default -c logs
出力例
2020-05-11T19:11:50.135710+00:00 router-default-57dfc6cd95-bpmk6 router-default-57dfc6cd95-bpmk6 haproxy[108]: 174.19.21.82:39654 [11/May/2020:19:11:50.133] public be_http:hello-openshift:hello-openshift/pod:hello-openshift:hello-openshift:10.128.2.12:8080 0/0/1/0/1 200 142 - - --NI 1/1/0/0/0 0/0 "GET / HTTP/1.1"
Syslog エンドポイントへの Ingress アクセスロギングを設定します。
Ingress アクセスロギングを設定するには、
spec.logging.access.destination
を使用して宛先を指定する必要があります。Syslog エンドポイント宛先へのロギングを指定するには、spec.logging.access.destination.type
にSyslog
を指定する必要があります。宛先タイプがSyslog
の場合、spec.logging.access.destination.syslog.endpoint
を使用して宛先エンドポイントも指定する必要があります。また、spec.logging.access.destination.syslog.facility
を使用してファシリティーを指定できます。以下の例は、Syslog
宛先に対してログを記録する Ingress コントローラーの定義です。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 コントローラーの定義です。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
5.8.4. Ingress コントローラースレッド数の設定
クラスター管理者は、スレッド数を設定して、クラスターが処理できる受信接続の量を増やすことができます。既存の Ingress コントローラーにパッチを適用して、スレッドの数を増やすことができます。
前提条件
- 以下では、Ingress コントローラーがすでに作成されていることを前提とします。
手順
Ingress コントローラーを更新して、スレッド数を増やします。
$ oc -n openshift-ingress-operator patch ingresscontroller/default --type=merge -p '{"spec":{"tuningOptions": {"threadCount": 8}}}'
注記大量のリソースを実行できるノードがある場合、
spec.nodePlacement.nodeSelector
を、意図されているノードの容量に一致するラベルで設定し、spec.tuningOptions.threadCount
を随時高い値に設定します。
5.8.5. Ingress コントローラーのシャード化
トラフィックがクラスターに送信される主要なメカニズムとして、Ingress コントローラーまたはルーターへの要求が大きくなる可能性があります。クラスター管理者は、以下を実行するためにルートをシャード化できます。
- Ingress コントローラーまたはルーターを複数のルートに分散し、変更に対する応答を加速します。
- 特定のルートを他のルートとは異なる信頼性の保証を持つように割り当てます。
- 特定の Ingress コントローラーに異なるポリシーを定義することを許可します。
- 特定のルートのみが追加機能を使用することを許可します。
- たとえば、異なるアドレスで異なるルートを公開し、内部ユーザーおよび外部ユーザーが異なるルートを認識できるようにします。
Ingress コントローラーは、ルートラベルまたは namespace ラベルのいずれかをシャード化の方法として使用できます。
5.8.5.1. ルートラベルを使用した Ingress コントローラーのシャード化の設定
ルートラベルを使用した Ingress コントローラーのシャード化とは、Ingress コントローラーがルートセレクターによって選択される任意 namespace の任意のルートを提供することを意味します。
Ingress コントローラーのシャード化は、一連の Ingress コントローラー間で着信トラフィックの負荷を分散し、トラフィックを特定の Ingress コントローラーに分離する際に役立ちます。たとえば、Company A のトラフィックをある Ingress コントローラーに指定し、Company B を別の Ingress コントローラーに指定できます。
手順
router-internal.yaml
ファイルを編集します。# cat router-internal.yaml apiVersion: v1 items: - apiVersion: operator.openshift.io/v1 kind: IngressController metadata: name: sharded namespace: openshift-ingress-operator spec: domain: <apps-sharded.basedomain.example.net> nodePlacement: nodeSelector: matchLabels: node-role.kubernetes.io/worker: "" routeSelector: matchLabels: type: sharded status: {} kind: List metadata: resourceVersion: "" selfLink: ""
Ingress コントローラーの
router-internal.yaml
ファイルを適用します。# oc apply -f router-internal.yaml
Ingress コントローラーは、
type: sharded
というラベルのある namespace のルートを選択します。
5.8.5.2. namespace ラベルを使用した Ingress コントローラーのシャード化の設定
namespace ラベルを使用した Ingress コントローラーのシャード化とは、Ingress コントローラーが namespace セレクターによって選択される任意の namespace の任意のルートを提供することを意味します。
Ingress コントローラーのシャード化は、一連の Ingress コントローラー間で着信トラフィックの負荷を分散し、トラフィックを特定の Ingress コントローラーに分離する際に役立ちます。たとえば、Company A のトラフィックをある Ingress コントローラーに指定し、Company B を別の Ingress コントローラーに指定できます。
Keepalived Ingress VIP をデプロイする場合は、endpoint Publishing Strategy
パラメーターにHost Network
の値が割り当てられた、デフォルト以外の Ingress Controller をデプロイしないでください。デプロイしてしまうと、問題が発生する可能性があります。endpoint Publishing Strategy
にHost Network
ではなく、Node Port
という値を使用してください。
手順
router-internal.yaml
ファイルを編集します。# cat router-internal.yaml
出力例
apiVersion: v1 items: - apiVersion: operator.openshift.io/v1 kind: IngressController metadata: name: sharded namespace: openshift-ingress-operator spec: domain: <apps-sharded.basedomain.example.net> nodePlacement: nodeSelector: matchLabels: node-role.kubernetes.io/worker: "" namespaceSelector: matchLabels: type: sharded status: {} kind: List metadata: resourceVersion: "" selfLink: ""
Ingress コントローラーの
router-internal.yaml
ファイルを適用します。# oc apply -f router-internal.yaml
Ingress コントローラーは、
type: sharded
というラベルのある namespace セレクターによって選択される namespace のルートを選択します。
5.8.6. 内部ロードバランサーを使用するように Ingress コントローラーを設定する
クラウドプラットフォームで Ingress コントローラーを作成する場合、Ingress コントローラーはデフォルトでパブリッククラウドロードバランサーによって公開されます。管理者は、内部クラウドロードバランサーを使用する Ingress コントローラーを作成できます。
クラウドプロバイダーが Microsoft Azure の場合、ノードを参照するパブリックロードバランサーが少なくとも 1 つ必要です。これがない場合、すべてのノードがインターネットへの egress 接続を失います。
IngressController
オブジェクトのスコープ
を変更する必要がある場合、IngressController
オブジェクトを削除してから、これを再作成する必要があります。カスタムリソース (CR) の作成後に .spec.endpointPublishingStrategy.loadBalancer.scope
パラメーターを変更することはできません。
図5.2 ロードバランサーの図

前述の図では、OpenShift Container Platform Ingress LoadBalancerService エンドポイントの公開戦略に関する以下のような概念を示しています。
- 負荷は、外部からクラウドプロバイダーのロードバランサーを使用するか、内部から OpenShift Ingress Controller Load Balancer を使用して、分散できます。
- ロードバランサーのシングル IP アドレスと、図にあるクラスターのように、8080 や 4200 といった馴染みのあるポートを使用することができます。
- 外部のロードバランサーからのトラフィックは、ダウンしたノードのインスタンスで記載されているように、Pod の方向に進められ、ロードバランサーが管理します。実装の詳細については、Kubernetes サービスドキュメント を参照してください。
前提条件
-
OpenShift CLI (
oc
) をインストールします。 -
cluster-admin
権限を持つユーザーとしてログインしている。
手順
以下の例のように、
<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
以下のコマンドを実行して、直前の手順で定義された Ingress コントローラーを作成します。
$ oc create -f <name>-ingress-controller.yaml 1
- 1
<name>
をIngressController
オブジェクトの名前に置き換えます。
オプション: 以下のコマンドを実行して Ingress コントローラーが作成されていることを確認します。
$ oc --all-namespaces=true get ingresscontrollers
5.8.7. GCP での Ingress コントローラーのグローバルアクセスの設定
内部ロードバランサーで GCP で作成された Ingress コントローラーは、サービスの内部 IP アドレスを生成します。クラスター管理者は、グローバルアクセスオプションを指定できます。これにより、同じ VPC ネットワーク内の任意のリージョンでクラスターを有効にし、ロードバランサーとしてコンピュートリージョンを有効にして、クラスターで実行されるワークロードに到達できるようにできます。
詳細情報は、GCP ドキュメントのグローバルアクセスについて参照してください。
前提条件
- OpenShift Container Platform クラスターを GCP インフラストラクチャーにデプロイしている。
- 内部ロードバランサーを使用するように Ingress コントローラーを設定している。
-
OpenShift CLI (
oc
) がインストールされている。
手順
グローバルアクセスを許可するように Ingress コントローラーリソースを設定します。
注記Ingress コントローラーを作成し、グローバルアクセスのオプションを指定することもできます。
Ingress コントローラーリソースを設定します。
$ oc -n openshift-ingress-operator edit ingresscontroller/default
YAML ファイルを編集します。
サンプル
clientAccess
設定をGlobal
に設定します。spec: endpointPublishingStrategy: loadBalancer: providerParameters: gcp: clientAccess: Global 1 type: GCP scope: Internal type: LoadBalancerService
- 1
gcp.clientAccess
をGlobal
に設定します。
- 変更を適用するためにファイルを保存します。
以下のコマンドを実行して、サービスがグローバルアクセスを許可することを確認します。
$ oc -n openshift-ingress edit svc/router-default -o yaml
この出力では、グローバルアクセスがアノテーション
networking.gke.io/internal-load-balancer-allow-global-access
で GCP について有効にされていることを示しています。
5.8.8. クラスターを内部に配置するようにのデフォルト Ingress コントローラーを設定する
削除や再作成を実行して、クラスターを内部に配置するように default
Ingress コントローラーを設定できます。
クラウドプロバイダーが Microsoft Azure の場合、ノードを参照するパブリックロードバランサーが少なくとも 1 つ必要です。これがない場合、すべてのノードがインターネットへの egress 接続を失います。
IngressController
オブジェクトのスコープ
を変更する必要がある場合、IngressController
オブジェクトを削除してから、これを再作成する必要があります。カスタムリソース (CR) の作成後に .spec.endpointPublishingStrategy.loadBalancer.scope
パラメーターを変更することはできません。
前提条件
-
OpenShift CLI (
oc
) をインストールします。 -
cluster-admin
権限を持つユーザーとしてログインしている。
手順
削除や再作成を実行して、クラスターを内部に配置するように
default
Ingress コントローラーを設定します。$ 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
5.8.9. ルートの受付ポリシーの設定
管理者およびアプリケーション開発者は、同じドメイン名を持つ複数の 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
5.8.10. ワイルドカードルートの使用
HAProxy Ingress コントローラーにはワイルドカードルートのサポートがあります。Ingress Operator は wildcardPolicy
を使用して、Ingress コントローラーの ROUTER_ALLOW_WILDCARD_ROUTES
環境変数を設定します。
Ingress コントローラーのデフォルトの動作では、ワイルドカードポリシーの None
(既存の IngressController
リソースとの後方互換性がある) を持つルートを許可します。
手順
ワイルドカードポリシーを設定します。
以下のコマンドを使用して
IngressController
リソースを編集します。$ oc edit IngressController
spec
の下で、wildcardPolicy
フィールドをWildcardsDisallowed
またはWildcardsAllowed
に設定します。spec: routeAdmission: wildcardPolicy: WildcardsDisallowed # or WildcardsAllowed
5.8.11. X-Forwarded ヘッダーの使用
Forwarded
および X-Forwarded-For
を含む HTTP ヘッダーの処理方法についてのポリシーを指定するように HAProxy Ingress コントローラーを設定します。Ingress Operator は HTTPHeaders
フィールドを使用して、Ingress コントローラーの ROUTER_SET_FORWARDED_HEADERS
環境変数を設定します。
手順
Ingress コントローラー用に
HTTPHeaders
フィールドを設定します。以下のコマンドを使用して
IngressController
リソースを編集します。$ oc edit IngressController
spec
の下で、HTTPHeaders
ポリシーフィールドをAppend
、Replace
、IfNone
、またはNever
に設定します。apiVersion: operator.openshift.io/v1 kind: IngressController metadata: name: default namespace: openshift-ingress-operator spec: httpHeaders: forwardedHeaderPolicy: Append
使用例
クラスター管理者として、以下を実行できます。
Ingress コントローラーに転送する前に、
X-Forwarded-For
ヘッダーを各リクエストに挿入する外部プロキシーを設定します。ヘッダーを変更せずに渡すように Ingress コントローラーを設定するには、
never
ポリシーを指定します。これにより、Ingress コントローラーはヘッダーを設定しなくなり、アプリケーションは外部プロキシーが提供するヘッダーのみを受信します。外部プロキシーが外部クラスター要求を設定する
X-Forwarded-For
ヘッダーを変更せずに渡すように Ingress コントローラーを設定します。外部プロキシーを通過しない内部クラスター要求に
X-Forwarded-For
ヘッダーを設定するように Ingress コントローラーを設定するには、if-none
ポリシーを指定します。外部プロキシー経由で HTTP 要求にヘッダーがすでに設定されている場合、Ingress コントローラーはこれを保持します。要求がプロキシーを通過していないためにヘッダーがない場合、Ingress コントローラーはヘッダーを追加します。
アプリケーション開発者として、以下を実行できます。
X-Forwarded-For
ヘッダーを挿入するアプリケーション固有の外部プロキシーを設定します。他の Route のポリシーに影響を与えずに、アプリケーションの Route 用にヘッダーを変更せずに渡すように Ingress コントローラーを設定するには、アプリケーションの Route に アノテーション
haproxy.router.openshift.io/set-forwarded-headers: if-none
またはhaproxy.router.openshift.io/set-forwarded-headers: never
を追加します。注記Ingress コントローラーのグローバルに設定された値とは別に、
haproxy.router.openshift.io/set-forwarded-headers
アノテーションをルートごとに設定できます。
5.8.12. HTTP/2 Ingress 接続の有効化
HAProxy で透過的なエンドツーエンド HTTP/2 接続を有効にすることができます。これにより、アプリケーションの所有者は、単一接続、ヘッダー圧縮、バイナリーストリームなど、HTTP/2 プロトコル機能を使用できます。
個別の Ingress コントローラーまたはクラスター全体について、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 コントローラーに接続して HTTP/1.1 をネゴシエートし、Ingress コントローラーは次にアプリケーションに接続して HTTP/2 をネゴシエートし、アプリケーションへの HTTP/2 接続を使用してクライアント HTTP/1.1 接続からの要求の転送を実行できます。Ingress コントローラーは WebSocket を HTTP/2 に転送できず、その HTTP/2 接続を WebSocket に対してアップグレードできないため、クライアントが後に HTTP/1.1 から WebSocket プロトコルに接続をアップグレードしようとすると問題が発生します。そのため、WebSocket 接続を受け入れることが意図されたアプリケーションがある場合、これは HTTP/2 プロトコルのネゴシエートを許可できないようにする必要があります。そうしないと、クライアントは WebSocket プロトコルへのアップグレードに失敗します。
手順
単一 Ingress コントローラーで HTTP/2 を有効にします。
Ingress コントローラーで HTTP/2 を有効にするには、
oc annotate
コマンドを入力します。$ oc -n openshift-ingress-operator annotate ingresscontrollers/<ingresscontroller_name> ingress.operator.openshift.io/default-enable-http2=true
<ingresscontroller_name>
をアノテーションを付ける Ingress コントローラーの名前に置き換えます。
クラスター全体で 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"
5.8.13. Ingress コントローラーの PROXY プロトコルの設定
クラスター管理者は、Ingress コントローラーが HostNetwork
または NodePortService
エンドポイントの公開ストラテジータイプのいずれかを使用する際に PROXY プロトコル を設定できます。PROXY プロトコルにより、ロードバランサーは Ingress コントローラーが受信する接続の元のクライアントアドレスを保持することができます。元のクライアントアドレスは、HTTP ヘッダーのロギング、フィルタリング、および挿入を実行する場合に便利です。デフォルト設定では、Ingress コントローラーが受信する接続には、ロードバランサーに関連付けられるソースアドレスのみが含まれます。
この機能は、クラウドデプロイメントではサポートされていません。この制限は、OpenShift Container Platform がクラウドプラットフォームで実行される場合、IngressController はサービスロードバランサーを使用するように指定し、Ingress Operator はロードバランサーサービスを設定し、ソースアドレスを保持するプラットフォーム要件に基づいて PROXY プロトコルを有効にするためにあります。
接続の障害を防ぐには、Ingress コントローラーとロードバランサーの両方を PROXY プロトコルを使用するように設定します。
前提条件
- Ingress コントローラーを作成している。
手順
Ingress コントローラーリソースを編集します。
$ oc -n openshift-ingress-operator edit ingresscontroller/default
PROXY 設定を設定します。
Ingress コントローラーが hostNetwork エンドポイント公開ストラテジータイプを使用する場合は、
spec.endpointPublishingStrategy.nodePort.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
5.8.14. appsDomain オプションを使用した代替クラスタードメインの指定
クラスター管理者は、appsDomain
フィールドを設定して、ユーザーが作成したルートのデフォルトのクラスタードメインの代わりとなるものを指定できます。appsDomain
フィールドは、ドメインフィールドで指定されるデフォルトの代わりに使用する OpenShift Container Platform のオプションの ドメイン
です。代替ドメインを指定する場合、これは新規ルートのデフォルトホストを判別できるようにする目的でデフォルトのクラスタードメインを上書きします。
たとえば、所属企業の DNS ドメインを、クラスター上で実行されるアプリケーションのルートおよび ingress のデフォルトドメインとして使用できます。
前提条件
- OpenShift Container Platform クラスターをデプロイしていること。
-
oc
コマンドラインインターフェースをインストールしている。
手順
ユーザーが作成するルートに代替のデフォルトドメインを指定して
appsDomain
フィールドを設定します。Ingress
クラスター
リソースを編集します。$ oc edit ingresses.config/cluster -o yaml
YAML ファイルを編集します。
test.example.com
へのapps Domain
の設定例apiVersion: config.openshift.io/v1 kind: Ingress metadata: name: cluster spec: domain: apps.example.com 1 appsDomain: <test.example.com> 2
ルートを公開し、ルートドメインの変更を確認して、既存のルートに、
appsDomain
フィールドで指定したドメイン名が含まれていることを確認します。注記ルートを公開する前に
openshift-apiserver
がローリングアップデートを終了するのを待機します。ルートを公開します。
$ 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
5.8.15. HTTP ヘッダーケースの変換
HAProxy 2.2 では、デフォルトで HTTP ヘッダー名を小文字化します。たとえば、Host: xyz.com
を host: xyz.com
に変更します。レガシーアプリケーションが HTTP ヘッダー名の大文字を認識する場合、Ingress Controller の spec.httpHeaders.headerNameCaseAdjustments
API フィールドを、修正されるまでレガシーアプリケーションに対応するソリューションに使用します。
OpenShift Container Platform 4.9 には HAProxy 2.2 が含まれるため、アップグレードする前に spec.httpHeaders.headerNameCaseAdjustments
を使用して必要な設定を追加するようにしてください。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできる。
手順
クラスター管理者は、oc patch
コマンドを入力するか、または Ingress コントローラー YAML ファイルの HeaderNameCaseAdjustments
フィールドを設定して HTTP ヘッダーのケースを変換できます。
oc patch
コマンドを入力して、HTTP ヘッダーの大文字化を指定します。oc patch
コマンドを入力して、HTTPhost
ヘッダーをHost
に変更します。$ oc -n openshift-ingress-operator patch ingresscontrollers/default --type=merge --patch='{"spec":{"httpHeaders":{"headerNameCaseAdjustments":["Host"]}}}'
アプリケーションのルートにアノテーションを付けます。
$ oc annotate routes/my-application haproxy.router.openshift.io/h1-adjust-case=true
次に、Ingress コントローラーは
host
要求ヘッダーを指定どおりに調整します。
Ingress コントローラーの YAML ファイルを設定し、
HeaderNameCaseAdjustments
フィールドを使用して調整を指定します。以下のサンプル Ingress コントローラー YAML は、適切にアノテーションが付けられたルートへの HTTP/1 要求について
host
ヘッダーをHost
に調整します。Ingress コントローラー YAML のサンプル
apiVersion: operator.openshift.io/v1 kind: IngressController metadata: name: default namespace: openshift-ingress-operator spec: httpHeaders: headerNameCaseAdjustments: - Host
以下のサンプルルートでは、
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 に設定します。
5.8.16. HAProxy エラーコードの応答ページのカスタマイズ
クラスター管理者は、503、404、またはその両方のエラーページにカスタムのエラーコード応答ページを指定できます。HAProxy ルーターは、アプリケーション Pod が実行していない場合や、要求された URL が存在しない場合に 404 エラーページを提供する 503 エラーページを提供します。たとえば、503 エラーコードの応答ページをカスタマイズする場合は、アプリケーション Pod が実行していないときにページが提供されます。また、デフォルトの 404 エラーコード HTTP 応答ページは、誤ったルートまたは存在しないルートについて HAProxy ルーターによって提供されます。
カスタムエラーコードの応答ページは設定マップに指定し、Ingress コントローラーにパッチを適用されます。設定マップキーには、error-page-503.http
と error-page-404.http
の 2 つの利用可能なファイル名があります。
カスタムの HTTP エラーコードの応答ページは、HAProxy HTTP エラーページ設定のガイドライン に従う必要があります。以下は、デフォルトの OpenShift Container Platform HAProxy ルーターの http 503 エラーコード応答ページ の例です。デフォルトのコンテンツを、独自のカスタムページを作成するためのテンプレートとして使用できます。
デフォルトで、HAProxy ルーターは、アプリケーションが実行していない場合や、ルートが正しくないまたは存在しない場合に 503 エラーページのみを提供します。このデフォルトの動作は、OpenShift Container Platform 4.8 以前の動作と同じです。HTTPエラーコード応答をカスタマイズするための設定マップが提供されておらず、カスタムHTTPエラーコード応答ページを使用している場合、ルーターはデフォルトの404または503エラーコード応答ページを提供します。
カスタマイズ用のテンプレートとして OpenShift Container Platform のデフォルトの 503 エラーコードページを使用する場合、ファイルのヘッダーには CRLF 行の終了よりも多くのエディターが必要になります。
手順
openshift-config
にmy-custom-error-code-pages
という名前の設定マップを作成します。$ oc -n openshift-config create configmap my-custom-error-code-pages \ --from-file=error-page-503.http \ --from-file=error-page-404.http
重要カスタムエラーコードの応答ページに適した形式を指定しない場合は、ルーター Pod が停止します。この停止を解決するには、設定マップを削除するか、または修正し、影響を受けるルーター Pod を削除して、正しい情報で再作成できるようにします。
Ingress コントローラーにパッチを適用し、名前を指定して
my-custom-error-code-pages
設定マップを参照します。$ 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
設定マップをコピーします。Operator は、openshift-ingress
namespace のパターン<your_ingresscontroller_name>-errorpages
に従って設定マップに名前を付けます。コピーを表示します。
$ oc get cm default-errorpages -n openshift-ingress
出力例
NAME DATA AGE default-errorpages 2 25s 1
- 1
default
の Ingress Controller カスタムリソース(CR)にパッチが適用されているため、設定マップ名の例はdefault-errorpages
です。
カスタムエラー応答ページを含む構成マップがルーターボリュームにマウントされることを確認します。構成マップキーは、カスタム 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 応答を確認します。
テストプロジェクトおよびアプリケーションを作成します。
$ oc new-project test-ingress
$ oc new-app django-psql-example
503 カスタム http エラーコード応答の場合:
- アプリケーションのすべての Pod を停止します。
以下の curl コマンドを実行するか、ブラウザーでルートのホスト名にアクセスします。
$ curl -vk <route_hostname>
404 カスタム http エラーコード応答の場合:
- 存在しないルートまたは正しくないルートにアクセスします。
以下の curl コマンドを実行するか、ブラウザーでルートのホスト名にアクセスします。
$ curl -vk <route_hostname>
errorfile
属性がhaproxy.config
ファイルで適切にあるかどうかを確認します。$ oc -n openshift-ingress rsh <router> cat /var/lib/haproxy/conf/haproxy.config | grep errorfile
5.9. 関連情報
第6章 エンドポイントへの接続の確認
Cluster Network Operator (CNO) は、クラスター内のリソース間の接続ヘルスチェックを実行するコントローラーである接続性チェックコントローラーを実行します。ヘルスチェックの結果を確認して、調査している問題が原因で生じる接続の問題を診断したり、ネットワーク接続を削除したりできます。
6.1. 実行する接続ヘルスチェック
クラスターリソースにアクセスできることを確認するには、以下のクラスター API サービスのそれぞれに対して TCP 接続が行われます。
- Kubernetes API サーバーサービス
- Kubernetes API サーバーエンドポイント
- OpenShift API サーバーサービス
- OpenShift API サーバーエンドポイント
- ロードバランサー
サービスおよびサービスエンドポイントがクラスター内のすべてのノードで到達可能であることを確認するには、以下の各ターゲットに対して TCP 接続が行われます。
- ヘルスチェックターゲットサービス
- ヘルスチェックターゲットエンドポイント
6.2. 接続ヘルスチェックの実装
接続チェックコントローラーは、クラスター内の接続検証チェックをオーケストレーションします。接続テストの結果は、openshift-network-diagnostics
namespace の PodNetworkConnectivity
オブジェクトに保存されます。接続テストは、1 分ごとに並行して実行されます。
Cluster Network Operator (CNO) は、接続性ヘルスチェックを送受信するためにいくつかのリソースをクラスターにデプロイします。
- ヘルスチェックのソース
-
このプログラムは、
Deployment
オブジェクトで管理される単一の Pod レプリカセットにデプロイします。このプログラムはPodNetworkConnectivity
オブジェクトを消費し、各オブジェクトで指定されるspec.targetEndpoint
に接続されます。 - ヘルスチェックのターゲット
- クラスターのすべてのノードにデーモンセットの一部としてデプロイされた Pod。Pod はインバウンドのヘルスチェックをリッスンします。すべてのノードにこの Pod が存在すると、各ノードへの接続をテストすることができます。
6.3. PodNetworkConnectivityCheck オブジェクトフィールド
PodNetworkConnectivityCheck
オブジェクトフィールドについては、以下の表で説明されています。
表6.1 PodNetworkConnectivityCheck オブジェクトフィールド
フィールド | タイプ | 詳細 |
---|---|---|
|
|
以下の形式のオブジェクトの名前:
|
|
|
オブジェクトが関連付けられる namespace。この値は、常に |
|
|
接続チェックの起点となる Pod の名前 (例: |
|
|
|
|
| 使用する TLS 証明書の設定。 |
|
| 使用される TLS 証明書の名前 (ある場合)。デフォルト値は空の文字列です。 |
|
| 接続テストの状態を表す、および最近の接続の成功および失敗についてのログ。 |
|
| 接続チェックと最新のステータスと以前のステータス。 |
|
| 試行に失敗した接続テストのログ。 |
|
| 停止が生じた期間が含まれる接続テストのログ。 |
|
| 試行に成功した接続テストのログ。 |
以下の表は、status.conditions
配列内のオブジェクトのフィールドについて説明しています。
表6.2 status.conditions
フィールド | タイプ | 詳細 |
---|---|---|
|
| 接続の条件がある状態から別の状態に移行した時間。 |
|
| 人が判読できる形式の最後の移行についての詳細。 |
|
| マシンの読み取り可能な形式での移行の最後のステータス。 |
|
| 状態のテータス。 |
|
| 状態のタイプ。 |
以下の表は、status.conditions
配列内のオブジェクトのフィールドについて説明しています。
表6.3 status.outages
フィールド | タイプ | 詳細 |
---|---|---|
|
| 接続の障害が解決された時点からのタイムスタンプ。 |
|
| 接続ログエントリー (停止の正常な終了に関連するログエントリーを含む)。 |
|
| 人が判読できる形式の停止について詳細情報の要約。 |
|
| 接続の障害が最初に検知された時点からのタイムスタンプ。 |
|
| 元の障害を含む接続ログのエントリー。 |
接続ログフィールド
接続ログエントリーのフィールドの説明は以下の表で説明されています。オブジェクトは以下のフィールドで使用されます。
-
status.failures[]
-
status.successes[]
-
status.outages[].startLogs[]
-
status.outages[].endLogs[]
表6.4 接続ログオブジェクト
フィールド | タイプ | 詳細 |
---|---|---|
|
| アクションの期間を記録します。 |
|
| ステータスを人が判読できる形式で提供します。 |
|
|
ステータスの理由をマシンが判読できる形式で提供します。値は |
|
| ログエントリーが成功または失敗であるかを示します。 |
|
| 接続チェックの開始時間。 |
6.4. エンドポイントのネットワーク接続の確認
クラスター管理者は、API サーバー、ロードバランサー、サービス、または Pod などのエンドポイントの接続を確認できます。
前提条件
-
OpenShift CLI (
oc
) をインストールします。 -
cluster-admin
ロールを持つユーザーとしてのクラスターへのアクセス。
手順
現在の
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-target-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh 74m network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-network-check-target-ci-ln-x5sv9rb-f76d1-4rzrp-worker-c-n8mbf 74m network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-network-check-target-ci-ln-x5sv9rb-f76d1-4rzrp-worker-d-4hnrz 74m network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-network-check-target-service-cluster 75m network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-openshift-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0 75m network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-openshift-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-1 75m network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-openshift-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-2 74m network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-openshift-apiserver-service-cluster 75m
接続テストログを表示します。
- 直前のコマンドの出力から、接続ログを確認するエンドポイントを特定します。
オブジェクトを表示するには、以下のコマンドを入力します。
$ oc get podnetworkconnectivitycheck <name> \ -n openshift-network-diagnostics -o yaml
ここで、
<name>
はPodNetworkConnectivityCheck
オブジェクトの名前を指定します。出力例
apiVersion: controlplane.operator.openshift.io/v1alpha1 kind: PodNetworkConnectivityCheck metadata: name: network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0 namespace: openshift-network-diagnostics ... spec: sourcePod: network-check-source-7c88f6d9f-hmg2f targetEndpoint: 10.0.0.4:6443 tlsClientCert: name: "" status: conditions: - lastTransitionTime: "2021-01-13T20:11:34Z" message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp connection to 10.0.0.4:6443 succeeded' reason: TCPConnectSuccess status: "True" type: Reachable failures: - latency: 2.241775ms message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: failed to establish a TCP connection to 10.0.0.4:6443: dial tcp 10.0.0.4:6443: connect: connection refused' reason: TCPConnectError success: false time: "2021-01-13T20:10:34Z" - latency: 2.582129ms message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: failed to establish a TCP connection to 10.0.0.4:6443: dial tcp 10.0.0.4:6443: connect: connection refused' reason: TCPConnectError success: false time: "2021-01-13T20:09:34Z" - latency: 3.483578ms message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: failed to establish a TCP connection to 10.0.0.4:6443: dial tcp 10.0.0.4:6443: connect: connection refused' reason: TCPConnectError success: false time: "2021-01-13T20:08:34Z" outages: - end: "2021-01-13T20:11:34Z" endLogs: - latency: 2.032018ms message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp connection to 10.0.0.4:6443 succeeded' reason: TCPConnect success: true time: "2021-01-13T20:11:34Z" - latency: 2.241775ms message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: failed to establish a TCP connection to 10.0.0.4:6443: dial tcp 10.0.0.4:6443: connect: connection refused' reason: TCPConnectError success: false time: "2021-01-13T20:10:34Z" - latency: 2.582129ms message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: failed to establish a TCP connection to 10.0.0.4:6443: dial tcp 10.0.0.4:6443: connect: connection refused' reason: TCPConnectError success: false time: "2021-01-13T20:09:34Z" - latency: 3.483578ms message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: failed to establish a TCP connection to 10.0.0.4:6443: dial tcp 10.0.0.4:6443: connect: connection refused' reason: TCPConnectError success: false time: "2021-01-13T20:08:34Z" message: Connectivity restored after 2m59.999789186s start: "2021-01-13T20:08:34Z" startLogs: - latency: 3.483578ms message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: failed to establish a TCP connection to 10.0.0.4:6443: dial tcp 10.0.0.4:6443: connect: connection refused' reason: TCPConnectError success: false time: "2021-01-13T20:08:34Z" successes: - latency: 2.845865ms message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp connection to 10.0.0.4:6443 succeeded' reason: TCPConnect success: true time: "2021-01-13T21:14:34Z" - latency: 2.926345ms message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp connection to 10.0.0.4:6443 succeeded' reason: TCPConnect success: true time: "2021-01-13T21:13:34Z" - latency: 2.895796ms message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp connection to 10.0.0.4:6443 succeeded' reason: TCPConnect success: true time: "2021-01-13T21:12:34Z" - latency: 2.696844ms message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp connection to 10.0.0.4:6443 succeeded' reason: TCPConnect success: true time: "2021-01-13T21:11:34Z" - latency: 1.502064ms message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp connection to 10.0.0.4:6443 succeeded' reason: TCPConnect success: true time: "2021-01-13T21:10:34Z" - latency: 1.388857ms message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp connection to 10.0.0.4:6443 succeeded' reason: TCPConnect success: true time: "2021-01-13T21:09:34Z" - latency: 1.906383ms message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp connection to 10.0.0.4:6443 succeeded' reason: TCPConnect success: true time: "2021-01-13T21:08:34Z" - latency: 2.089073ms message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp connection to 10.0.0.4:6443 succeeded' reason: TCPConnect success: true time: "2021-01-13T21:07:34Z" - latency: 2.156994ms message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp connection to 10.0.0.4:6443 succeeded' reason: TCPConnect success: true time: "2021-01-13T21:06:34Z" - latency: 1.777043ms message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp connection to 10.0.0.4:6443 succeeded' reason: TCPConnect success: true time: "2021-01-13T21:05:34Z"
第7章 ノードポートサービス範囲の設定
クラスター管理者は、利用可能なノードのポート範囲を拡張できます。クラスターで多数のノードポートが使用される場合、利用可能なポートの数を増やす必要がある場合があります。
デフォルトのポート範囲は 30000-32767
です。最初にデフォルト範囲を超えて拡張した場合でも、ポート範囲を縮小することはできません。
7.1. 前提条件
-
クラスターインフラストラクチャーは、拡張された範囲内で指定するポートへのアクセスを許可する必要があります。たとえば、ノードのポート範囲を
30000-32900
に拡張する場合、ファイアウォールまたはパケットフィルタリングの設定によりこれに含まれるポート範囲32768-32900
を許可する必要があります。
7.2. ノードのポート範囲の拡張
クラスターのノードポート範囲を拡張できます。
前提条件
-
OpenShift CLI (
oc
) をインストールします。 -
cluster-admin
権限を持つユーザーとしてクラスターにログインすること。
手順
ノードのポート範囲を拡張するには、以下のコマンドを入力します。
<port>
を、新規の範囲内で最大のポート番号に置き換えます。$ oc patch network.config.openshift.io cluster --type=merge -p \ '{ "spec": { "serviceNodePortRange": "30000-<port>" } }'
ヒントまたは、以下の YAML を適用してノードのポート範囲を更新することもできます。
apiVersion: config.openshift.io/v1 kind: Network metadata: name: cluster spec: serviceNodePortRange: "30000-<port>"
出力例
network.config.openshift.io/cluster patched
設定がアクティブであることを確認するには、以下のコマンドを入力します。更新が適用されるまでに数分の時間がかかることがあります。
$ oc get configmaps -n openshift-kube-apiserver config \ -o jsonpath="{.data['config\.yaml']}" | \ grep -Eo '"service-node-port-range":["[[:digit:]]+-[[:digit:]]+"]'
出力例
"service-node-port-range":["30000-33000"]
7.3. 関連情報
第8章 IP フェイルオーバーの設定
このトピックでは、OpenShift Container Platform クラスターの Pod およびサービスの IP フェイルオーバーの設定について説明します。
IP フェイルオーバーは、ノードセットの仮想 IP (VIP) アドレスのプールを管理します。セットのすべての VIP はセットから選択されるノードによって提供されます。VIP は単一ノードが利用可能である限り提供されます。ノード上で VIP を明示的に配布する方法がないため、VIP のないノードがある可能性も、多数の VIP を持つノードがある可能性もあります。ノードが 1 つのみ存在する場合は、すべての VIP がそのノードに配置されます。
VIP はクラスター外からルーティングできる必要があります。
IP フェイルオーバーは各 VIP のポートをモニターし、ポートがノードで到達可能かどうかを判別します。ポートが到達不能な場合、VIP はノードに割り当てられません。ポートが 0
に設定されている場合、このチェックは抑制されます。check スクリプトは必要なテストを実行します。
IP フェイルオーバーは Keepalived を使用して、一連のホストでの外部からアクセスできる VIP アドレスのセットをホストします。各 VIP は 1 度に 1 つのホストによって提供されます。Keepalived は Virtual Router Redundancy Protocol (VRRP) を使用して、(一連のホストの) どのホストがどの VIP を提供するかを判別します。ホストが利用不可の場合や Keepalived が監視しているサービスが応答しない場合は、VIP は一連のホストの別のホストに切り換えられます。したがって、VIP はホストが利用可能である限り常に提供されます。
Keepalived を実行するノードが check スクリプトを渡す場合、ノードの VIP はプリエンプションストラテジーに応じて、その優先順位および現在のマスターの優先順位に基づいて master
状態になることができます。
クラスター管理者は OPENSHIFT_HA_NOTIFY_SCRIPT
変数を介してスクリプトを提供できます。このスクリプトは、ノードの VIP の状態が変更されるたびに呼び出されます。Keepalived は VIP を提供する場合は master
状態を、別のノードが VIP を提供する場合は backup
状態を、または check スクリプトが失敗する場合は fault
状態を使用します。notify スクリプトは、状態が変更されるたびに新規の状態で呼び出されます。
OpenShift Container Platform で IP フェイルオーバーのデプロイメント設定を作成できます。IP フェイルオーバーのデプロイメント設定は VIP アドレスのセットを指定し、それらの提供先となるノードのセットを指定します。クラスターには複数の IP フェイルオーバーのデプロイメント設定を持たせることができ、それぞれが固有な VIP アドレスの独自のセットを管理します。IP フェイルオーバー設定の各ノードは IP フェイルオーバー Pod として実行され、この Pod は Keepalived を実行します。
VIP を使用してホストネットワークを持つ Pod にアクセスする場合、アプリケーション Pod は IP フェイルオーバー Pod を実行しているすべてのノードで実行されます。これにより、いずれの IP フェイルオーバーノードもマスターになり、必要時に VIP を提供することができます。アプリケーション Pod が IP フェイルオーバーのすべてのノードで実行されていない場合、一部の IP フェイルオーバーノードが VIP を提供できないか、または一部のアプリケーション Pod がトラフィックを受信できなくなります。この不一致を防ぐために、IP フェイルオーバーとアプリケーション Pod の両方に同じセレクターとレプリケーション数を使用します。
VIP を使用してサービスにアクセスしている間は、アプリケーション Pod が実行されている場所に関係なく、すべてのノードでサービスに到達できるため、任意のノードをノードの IP フェイルオーバーセットに含めることができます。いずれの IP フェイルオーバーノードも、いつでもマスターにすることができます。サービスは外部 IP およびサービスポートを使用するか、または NodePort
を使用することができます。
サービス定義で外部 IP を使用する場合、VIP は外部 IP に設定され、IP フェイルオーバーのモニタリングポートはサービスポートに設定されます。ノードポートを使用する場合、ポートはクラスター内のすべてのノードで開かれ、サービスは、現在 VIP にサービスを提供しているあらゆるノードからのトラフィックの負荷を分散します。この場合、IP フェイルオーバーのモニタリングポートはサービス定義で NodePort
に設定されます。
NodePort
のセットアップは特権付きの操作で実行されます。
サービス VIP の可用性が高い場合でも、パフォーマンスに影響が出る可能性があります。Keepalived は、各 VIP が設定内の一部のノードによってサービスされることを確認し、他のノードに VIP がない場合でも、複数の VIP が同じノードに配置される可能性があります。IP フェイルオーバーによって複数の VIP が同じノードに配置されると、VIP のセット全体で外部から負荷分散される戦略が妨げられる可能性があります。
ingressIP
を使用する場合は、IP フェイルオーバーを ingressIP
範囲と同じ VIP 範囲を持つように設定できます。また、モニタリングポートを無効にすることもできます。この場合、すべての VIP がクラスター内の同じノードに表示されます。すべてのユーザーが ingressIP
でサービスをセットアップし、これを高い可用性のあるサービスにすることができます。
クラスター内の VIP の最大数は 254 です。
8.1. IP フェイルオーバーの環境変数
以下の表は、IP フェイルオーバーの設定に使用される変数を示しています。
表8.1 IP フェイルオーバーの環境変数
変数名 | デフォルト | 詳細 |
---|---|---|
|
|
IP フェイルオーバー Pod は、各仮想 IP (VIP) のこのポートに対して TCP 接続を開こうとします。接続が設定されると、サービスは実行中であると見なされます。このポートが |
|
IP フェイルオーバーが Virtual Router Redundancy Protocol (VRRP) トラフィックの送信に使用するインターフェース名。デフォルト値は | |
|
|
作成するレプリカの数です。これは、IP フェイルオーバーデプロイメント設定の |
|
複製する IP アドレス範囲の一覧です。これは指定する必要があります例: | |
|
|
仮想ルーター ID の設定に使用されるオフセット値。異なるオフセット値を使用すると、複数の IP フェイルオーバー設定が同じクラスター内に存在できるようになります。デフォルトのオフセットは |
|
VRRP に作成するグループの数です。これが設定されていない場合、グループは | |
| INPUT |
iptables チェーンの名前であり、 |
| アプリケーションが動作していることを確認するために定期的に実行されるスクリプトの Pod ファイルシステム内の完全パス名です。 | |
|
| check スクリプトが実行される期間 (秒単位) です。 |
| 状態が変更されるたびに実行されるスクリプトの Pod ファイルシステム内の完全パス名です。 | |
|
|
新たな優先度の高いホストを処理するためのストラテジーです。 |
8.2. IP フェイルオーバーの設定
クラスター管理者は、クラスター全体に IP フェイルオーバーを設定することも、ラベルセレクターの定義に基づいてノードのサブセットに IP フェイルオーバーを設定することもできます。また、複数の IP フェイルオーバーのデプロイメント設定をクラスター内に設定することもでき、それぞれの設定をクラスター内で相互に切り離すことができます。
IP フェイルオーバーのデプロイメント設定により、フェイルオーバー Pod は、制約または使用されるラベルに一致する各ノードで確実に実行されます。
この Pod は Keepalived を実行します。これは、最初のノードがサービスまたはエンドポイントに到達できない場合に、エンドポイントを監視し、Virtual Router Redundancy Protocol (VRRP) を使用して仮想 IP (VIP) を別のノードにフェイルオーバーできます。
実稼働環境で使用する場合は、少なくとも 2 つのノードを選択し、選択したノードの数に相当するreplicas
を設定する selector
を設定します。
前提条件
-
cluster-admin
権限を持つユーザーとしてクラスターにログインしていること。 - プルシークレットを作成している。
手順
IP フェイルオーバーのサービスアカウントを作成します。
$ oc create sa ipfailover
hostNetwork
の SCC (Security Context Constraints) を更新します。$ oc adm policy add-scc-to-user privileged -z ipfailover $ oc adm policy add-scc-to-user hostnetwork -z ipfailover
デプロイメント YAML ファイルを作成して IP フェイルオーバーを設定します。
IP フェイルオーバー設定のデプロイメント YAML の例
apiVersion: apps/v1 kind: Deployment metadata: name: ipfailover-keepalived 1 labels: ipfailover: hello-openshift spec: strategy: type: Recreate replicas: 2 selector: matchLabels: ipfailover: hello-openshift template: metadata: labels: ipfailover: hello-openshift spec: serviceAccountName: ipfailover privileged: true hostNetwork: true nodeSelector: node-role.kubernetes.io/worker: "" containers: - name: openshift-ipfailover image: quay.io/openshift/origin-keepalived-ipfailover ports: - containerPort: 63000 hostPort: 63000 imagePullPolicy: IfNotPresent securityContext: privileged: true volumeMounts: - name: lib-modules mountPath: /lib/modules readOnly: true - name: host-slash mountPath: /host readOnly: true mountPropagation: HostToContainer - name: etc-sysconfig mountPath: /etc/sysconfig readOnly: true - name: config-volume mountPath: /etc/keepalive env: - name: OPENSHIFT_HA_CONFIG_NAME value: "ipfailover" - name: OPENSHIFT_HA_VIRTUAL_IPS 2 value: "1.1.1.1-2" - name: OPENSHIFT_HA_VIP_GROUPS 3 value: "10" - name: OPENSHIFT_HA_NETWORK_INTERFACE 4 value: "ens3" #The host interface to assign the VIPs - name: OPENSHIFT_HA_MONITOR_PORT 5 value: "30060" - name: OPENSHIFT_HA_VRRP_ID_OFFSET 6 value: "0" - name: OPENSHIFT_HA_REPLICA_COUNT 7 value: "2" #Must match the number of replicas in the deployment - name: OPENSHIFT_HA_USE_UNICAST value: "false" #- name: OPENSHIFT_HA_UNICAST_PEERS #value: "10.0.148.40,10.0.160.234,10.0.199.110" - name: OPENSHIFT_HA_IPTABLES_CHAIN 8 value: "INPUT" #- name: OPENSHIFT_HA_NOTIFY_SCRIPT 9 # value: /etc/keepalive/mynotifyscript.sh - name: OPENSHIFT_HA_CHECK_SCRIPT 10 value: "/etc/keepalive/mycheckscript.sh" - name: OPENSHIFT_HA_PREEMPTION 11 value: "preempt_delay 300" - name: OPENSHIFT_HA_CHECK_INTERVAL 12 value: "2" livenessProbe: initialDelaySeconds: 10 exec: command: - pgrep - keepalived volumes: - name: lib-modules hostPath: path: /lib/modules - name: host-slash hostPath: path: / - name: etc-sysconfig hostPath: path: /etc/sysconfig # config-volume contains the check script # created with `oc create configmap keepalived-checkscript --from-file=mycheckscript.sh` - configMap: defaultMode: 0755 name: keepalived-checkscript name: config-volume imagePullSecrets: - name: openshift-pull-secret 13
- 1
- IP フェイルオーバーデプロイメントの名前。
- 2
- 複製する IP アドレス範囲の一覧です。これは指定する必要があります例:
1.2.3.4-6,1.2.3.9
- 3
- VRRP に作成するグループの数です。これが設定されていない場合、グループは
OPENSHIFT_HA_VIP_GROUPS
変数で指定されている仮想 IP 範囲ごとに作成されます。 - 4
- IP フェイルオーバーが VRRP トラフィックの送信に使用するインターフェース名。デフォルトで
eth0
が使用されます。 - 5
- IP フェイルオーバー Pod は、各 VIP のこのポートに対して TCP 接続を開こうとします。接続が設定されると、サービスは実行中であると見なされます。このポートが
0
に設定される場合、テストは常にパスします。デフォルト値は80
です。 - 6
- 仮想ルーター ID の設定に使用されるオフセット値。異なるオフセット値を使用すると、複数の IP フェイルオーバー設定が同じクラスター内に存在できるようになります。デフォルトのオフセットは
0
で、許可される範囲は0
から255
までです。 - 7
- 作成するレプリカの数です。これは、IP フェイルオーバーデプロイメント設定の
spec.replicas
値に一致する必要があります。デフォルト値は2
です。 - 8
iptables
チェーンの名前であり、iptables
ルールを自動的に追加し、VRRP トラフィックをオンにすることを許可するために使用されます。この値が設定されていない場合、iptables
ルールは追加されません。チェーンが存在しない場合は作成されず、Keepalived はユニキャストモードで動作します。デフォルトはINPUT
です。- 9
- 状態が変更されるたびに実行されるスクリプトの Pod ファイルシステム内の完全パス名です。
- 10
- アプリケーションが動作していることを確認するために定期的に実行されるスクリプトの Pod ファイルシステム内の完全パス名です。
- 11
- 新たな優先度の高いホストを処理するためのストラテジーです。デフォルト値は
preempt_delay 300
で、優先順位の低いマスターが VIP を保持する場合に、Keepalived インスタンスが VIP を 5 分後に引き継ぎます。 - 12
- check スクリプトが実行される期間 (秒単位) です。デフォルト値は
2
です。 - 13
- デプロイメントを作成する前にプルシークレットを作成します。作成しない場合には、デプロイメントの作成時にエラーが発生します。
8.3. 仮想 IP アドレスについて
Keepalived は一連の仮想 IP アドレス (VIP) を管理します。管理者はこれらすべてのアドレスについて以下の点を確認する必要があります。
- 仮想 IP アドレスは設定されたホストでクラスター外からアクセスできる。
- 仮想 IP アドレスはクラスター内でこれ以外の目的で使用されていない。
各ノードの Keepalived は、必要とされるサービスが実行中であるかどうかを判別します。実行中の場合、VIP がサポートされ、Keepalived はネゴシエーションに参加してどのノードが VIP を提供するかを決定します。これに参加するノードについては、このサービスが VIP の監視 ポートでリッスンしている、またはチェックが無効にされている必要があります。
セット内の各 VIP は最終的に別のノードによって提供される可能性があります。
8.4. check スクリプトおよび notify スクリプトの設定
Keepalived は、オプションのユーザー指定の check スクリプトを定期的に実行してアプリケーションの正常性をモニターします。たとえば、このスクリプトは要求を発行し、応答を検証することで web サーバーをテストします。
チェックスクリプトが指定されない場合、TCP 接続をテストする単純なデフォルトスクリプトが実行されます。このデフォルトテストは、モニターポートが 0
の場合は抑制されます。
各 IP フェイルオーバー Pod は、Pod が実行されているノードで 1 つ以上の仮想 IP (VIP) を管理する Keepalived デーモンを管理します。Keepalived デーモンは、ノードの各 VIP の状態を維持します。特定のノード上の特定の VIP は、master
、backup
、または fault
状態にある可能性があります。
master
状態にあるノードでその VIP の check スクリプトが失敗すると、そのノードの VIP は fault
状態になり、再ネゴシエーションがトリガーされます。再ネゴシエーションの中に fault
状態にないノード上のすべての VIP は、どのノードが VIP を引き継ぐかを決定することに参加します。最終的に VIP は一部のノードで master
の状態に入り、VIP は他のノードで backup
状態のままになります。
backup
状態の VIP を持つノードに障害が発生すると、そのノードの VIP は fault
状態になります。fault
状態のノード上の VIP の check スクリプトが再度パスすると、そのノードの VIP はfault
状態を終了し、master
状態に入るためにネゴシエートします。次に、そのノードの VIP は、master
状態または backup
状態のいずれかになります。
クラスター管理者は、オプションの notify スクリプトを提供できます。このスクリプトは状態が変更されるたびに呼び出されます。Keepalived は以下の 3 つのパラメーターをこのスクリプトに渡します。
-
$1
-group
またはinstance
-
$2
:group
またはinstance
の名前です。 -
$3
: 新規の状態:master
、backup
、またはfault
check および notify スクリプトは、IP フェイルオーバー Pod で実行され、ホストファイルシステムではなく Pod ファイルシステムを使用します。ただし、IP フェイルオーバー Pod はホストファイルシステムが /hosts
マウントパスで利用可能にします。check または notify スクリプトを設定する場合は、スクリプトへの完全パスを指定する必要があります。スクリプトを提供する方法として、設定マップの使用が推奨されます。
check および notify スクリプトの完全パス名は、Keepalived 設定ファイル (_/etc/keepalived/keepalived.conf
) に追加されます。このファイルは、Keepalived が起動するたびにロードされます。スクリプトは、以下のように設定マップを使用して Pod に追加できます。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
権限を持つユーザーとしてクラスターにログインしていること。
手順
必要なスクリプトを作成し、これを保持する設定マップを作成します。スクリプトには入力引数は指定されず、
OK
の場合は0
を、fail
の場合は1
を返す必要があります。check スクリプト
mycheckscript.sh
:#!/bin/bash # Whatever tests are needed # E.g., send request and verify response exit 0
設定マップを作成します。
$ oc create configmap mycustomcheck --from-file=mycheckscript.sh
スクリプトを Pod に追加します。マウントされた設定マップファイルの
defaultMode
は、oc
コマンドを使用して、またはデプロイメント設定を編集して実行できる必要があります。通常は、0755
、493
(10 進数) の値が使用されます。$ oc set env deploy/ipfailover-keepalived \ OPENSHIFT_HA_CHECK_SCRIPT=/etc/keepalive/mycheckscript.sh
$ oc set volume deploy/ipfailover-keepalived --add --overwrite \ --name=config-volume \ --mount-path=/etc/keepalive \ --source='{"configMap": { "name": "mycustomcheck", "defaultMode": 493}}'
注記oc set env
コマンドは空白を区別します。=
記号の両側に空白を入れることはできません。ヒントまたは、
ipfailover-keepalived
デプロイメント設定を編集することもできます。$ oc edit deploy ipfailover-keepalived
spec: containers: - env: - name: OPENSHIFT_HA_CHECK_SCRIPT 1 value: /etc/keepalive/mycheckscript.sh ... volumeMounts: 2 - mountPath: /etc/keepalive name: config-volume dnsPolicy: ClusterFirst ... volumes: 3 - configMap: defaultMode: 0755 4 name: customrouter name: config-volume ...
変更を保存し、エディターを終了します。これにより
ipfailover-keepalived
が再起動されます。
8.5. VRRP プリエンプションの設定
ノードの仮想 IP (VIP) が check スクリプトを渡すことで fault
状態を終了すると、ノードの VIP は、現在 master
状態にあるノードの VIP よりも優先度が低い場合は backup
状態になります。ただし、fault
状態を終了するノードの VIP の優先度が高い場合は、プリエンプションストラテジーによってクラスター内でのその役割が決定されます。
nopreempt
ストラテジーは master
をホスト上の優先度の低いホストからホスト上の優先度の高い VIP に移動しません。デフォルトの preempt_delay 300
の場合、Keepalived は指定された 300 秒の間待機し、master
をホスト上の優先度の高い VIP に移動します。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。
手順
プリエンプションを指定するには、
oc edit deploy ipfailover-keepalived
を入力し、ルーターのデプロイメント設定を編集します。$ oc edit deploy ipfailover-keepalived
... spec: containers: - env: - name: OPENSHIFT_HA_PREEMPTION 1 value: preempt_delay 300 ...
- 1
OPENSHIFT_HA_PREEMPTION
の値を設定します。-
preempt_delay 300
: Keepalived は、指定された 300 秒の間待機し、master
をホスト上の優先度の高い VIP に移動します。これはデフォルト値です。 -
nopreempt
:master
をホスト上の優先度の低い VIP からホスト上の優先度の高い VIP に移動しません。
-
8.6. VRRP ID オフセットについて
IP フェイルオーバーのデプロイメント設定で管理される各 IP フェイルオーバー Pod (ノード/レプリカあたり 1
Pod) は Keepalived デーモンを実行します。設定される IP フェイルオーバーのデプロイメント設定が多くなると、作成される Pod も多くなり、共通の Virtual Router Redundancy Protocol (VRRP) ネゴシエーションに参加するデーモンも多くなります。このネゴシエーションはすべての Keepalived デーモンによって実行され、これはどのノードがどの仮想 IP (VIP) を提供するかを決定します。
Keepalived は内部で固有の vrrp-id
を各 VIP に割り当てます。ネゴシエーションはこの vrrp-ids
セットを使用し、決定後には優先される vrrp-id
に対応する VIP が優先されるノードで提供されます。
したがって、IP フェイルオーバーのデプロイメント設定で定義されるすべての VIP について、IP フェイルオーバーPod は対応する vrrp-id
を割り当てる必要があります。これは、OPENSHIFT_HA_VRRP_ID_OFFSET
から開始し、順序に従って vrrp-ids
を VIP の一覧に割り当てることによって実行されます。vrrp-ids
には範囲 1..255
の値を設定できます。
複数の IP フェイルオーバーのデプロイメント設定がある場合は、OPENSHIFT_HA_VRRP_ID_OFFSET
を指定して、デプロイメント設定内の VIP 数を増やす余地があり、vrrp-id
範囲が重複しないようにする必要があります。
8.7. 254 を超えるアドレスについての IP フェイルオーバーの設定
IP フェイルオーバー管理は、仮想IP (VIP) アドレスの 254 グループに制限されています。デフォルトでは、OpenShift Container Platform は各グループに 1 つの IP アドレスを割り当てます。OPENSHIFT_HA_VIP_GROUPS
変数を使用してこれを変更し、複数の IP アドレスが各グループに含まれるようにして、IP フェイルオーバーを設定するときに各 Virtual Router Redundancy Protocol (VRRP) インスタンスで使用可能な VIP グループの数を定義できます。
VIP の作成により、VRRP フェイルオーバーの発生時の広範囲の VRRP の割り当てが作成され、これはクラスター内のすべてのホストがローカルにサービスにアクセスする場合に役立ちます。たとえば、サービスが ExternalIP
で公開されている場合などがこれに含まれます。
フェイルオーバーのルールとして、ルーターなどのサービスは特定の 1 つのホストに制限しません。代わりに、サービスは、IP フェイルオーバーの発生時にサービスが新規ホストに再作成されないように各ホストに複製可能な状態にする必要があります。
OpenShift Container Platform のヘルスチェックを使用している場合、IP フェイルオーバーおよびグループの性質上、グループ内のすべてのインスタンスはチェックされません。そのため、Kubernetes ヘルスチェック を使ってサービスが有効であることを確認する必要があります。
前提条件
-
cluster-admin
権限を持つユーザーとしてクラスターにログインしていること。
手順
各グループに割り当てられた IP アドレスの数を変更するには、
OPENSHIFT_HA_VIP_GROUPS
変数の値を変更します。次に例を示します。IP フェイルオーバー設定の
Deployment
YAML の例... spec: env: - name: OPENSHIFT_HA_VIP_GROUPS 1 value: "3" ...
- 1
- たとえば、7 つの VIP のある環境で
OPENSHIFT_HA_VIP_GROUPS
が3
に設定されている場合、これは 3 つのグループを作成し、3 つの VIP を最初のグループに、2 つの VIP を 2 つの残りのグループにそれぞれ割り当てます。
OPENSHIFT_HA_VIP_GROUPS
で設定されたグループの数が、フェイルオーバーに設定された IP アドレスの数より少ない場合、グループには複数の IP アドレスが含まれ、すべてのアドレスが 1 つのユニットとして移動します。
8.8. ingressIP の高可用性
クラウド以外のクラスターでは、IP フェイルオーバーおよびサービスへの ingressIP
を組み合わせることができます。結果として、ingressIP
を使用してサービスを作成するユーザーに高可用サービスが提供されます。
この方法では、まず ingressIPNetworkCIDR
範囲を指定し、次に ipfailover 設定を作成する際に同じ範囲を使用します。
IP フェイルオーバーはクラスター全体に対して最大 255 の VIP をサポートできるため、ingressIPNetworkCIDR
は /24
以下に設定する必要があります。
8.9. IP フェイルオーバーの削除
IP フェイルオーバーが最初に設定されている場合、クラスターのワーカーノードは、Keepalived 用に 224.0.0.18
のマルチキャストパケットを明示的に許可する iptables
ルールを使用して変更されます。ノードが変更されるため、IP フェイルオーバーを削除するには、ジョブを実行して iptables
ルールを削除し、Keepalived が使用する仮想 IP アドレスを削除する必要があります。
手順
オプション: 設定マップとして保存されるチェックおよび通知スクリプトを特定し、削除します。
IP フェイルオーバーの Pod が設定マップをボリュームとして使用するかどうかを決定します。
$ oc get pod -l ipfailover \ -o jsonpath="\ {range .items[?(@.spec.volumes[*].configMap)]} {'Namespace: '}{.metadata.namespace} {'Pod: '}{.metadata.name} {'Volumes that use config maps:'} {range .spec.volumes[?(@.configMap)]} {'volume: '}{.name} {'configMap: '}{.configMap.name}{'\n'}{end} {end}"
出力例
Namespace: default Pod: keepalived-worker-59df45db9c-2x9mn Volumes that use config maps: volume: config-volume configMap: mycustomcheck
前述の手順でボリュームとして使用される設定マップの名前が提供されている場合は、設定マップを削除します。
$ oc delete configmap <configmap_name>
IP フェイルオーバーの既存デプロイメントを特定します。
$ oc get deployment -l ipfailover
出力例
NAMESPACE NAME READY UP-TO-DATE AVAILABLE AGE default ipfailover 2/2 2 2 105d
デプロイメントを削除します。
$ oc delete deployment <ipfailover_deployment_name>
ipfailover
サービスアカウントを削除します。$ oc delete sa ipfailover
IP フェイルオーバーの設定時に追加された IP テーブルルールを削除するジョブを実行します。
以下の例のような内容で
remove-ipfailover-job.yaml
などのファイルを作成します。apiVersion: batch/v1 kind: Job metadata: generateName: remove-ipfailover- labels: app: remove-ipfailover spec: template: metadata: name: remove-ipfailover spec: containers: - name: remove-ipfailover image: quay.io/openshift/origin-keepalived-ipfailover:4.9 command: ["/var/lib/ipfailover/keepalived/remove-failover.sh"] nodeSelector: kubernetes.io/hostname: <host_name> 1 restartPolicy: Never
- 1
- IP フェイルオーバー用に設定されたクラスター内の各ノードのジョブを実行し、毎回ホスト名を置き換えます。
ジョブを実行します。
$ oc create -f remove-ipfailover-job.yaml
出力例
job.batch/remove-ipfailover-2h8dm created
検証
ジョブが IP フェイルオーバーの初期設定を削除していることを確認します。
$ oc logs job/remove-ipfailover-2h8dm
出力例
remove-failover.sh: OpenShift IP Failover service terminating. - Removing ip_vs module ... - Cleaning up ... - Releasing VIPs (interface eth0) ...
第9章 ベアメタルクラスターでの SCTP (Stream Control Transmission Protocol) の使用
クラスター管理者は、クラスターで SCTP (Stream Control Transmission Protocol) を使用できます。
9.1. OpenShift Container Platform での SCTP (Stream Control Transmission Protocol) のサポート
クラスター管理者は、クラスターのホストで SCTP を有効にできます。Red Hat Enterprise Linux CoreOS (RHCOS) で、SCTP モジュールはデフォルトで無効にされています。
SCTP は、IP ネットワークの上部で実行される信頼できるメッセージベースのプロトコルです。
これを有効にすると、SCTP を Pod、サービス、およびネットワークポリシーでプロトコルとして使用できます。Service
オブジェクトは、type
パラメーターを ClusterIP
または NodePort
のいずれかの値に設定して定義する必要があります。
9.1.1. SCTP プロトコルを使用した設定例
protocol
パラメーターを Pod またはサービスリソース定義の SCTP
値に設定して、Pod またはサービスを SCTP を使用するように設定できます。
以下の例では、Pod は SCTP を使用するように設定されています。
apiVersion: v1 kind: Pod metadata: namespace: project1 name: example-pod spec: containers: - name: example-pod ... ports: - containerPort: 30100 name: sctpserver protocol: SCTP
以下の例では、サービスは SCTP を使用するように設定されています。
apiVersion: v1 kind: Service metadata: namespace: project1 name: sctpserver spec: ... ports: - name: sctpserver protocol: SCTP port: 30100 targetPort: 30100 type: ClusterIP
以下の例では、NetworkPolicy
オブジェクトは、特定のラベルの付いた Pod からポート 80
の SCTP ネットワークトラフィックに適用するように設定されます。
kind: NetworkPolicy apiVersion: networking.k8s.io/v1 metadata: name: allow-sctp-on-http spec: podSelector: matchLabels: role: web ingress: - ports: - protocol: SCTP port: 80
9.2. SCTP (Stream Control Transmission Protocol) の有効化
クラスター管理者は、クラスターのワーカーノードでブラックリストに指定した SCTP カーネルモジュールを読み込み、有効にできます。
前提条件
-
OpenShift CLI (
oc
) をインストールします。 -
cluster-admin
ロールを持つユーザーとしてのクラスターへのアクセス。
手順
以下の YAML 定義が含まれる
load-sctp-module.yaml
という名前のファイルを作成します。apiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfig metadata: name: load-sctp-module labels: machineconfiguration.openshift.io/role: worker spec: config: ignition: version: 3.2.0 storage: files: - path: /etc/modprobe.d/sctp-blacklist.conf mode: 0644 overwrite: true contents: source: data:, - path: /etc/modules-load.d/sctp-load.conf mode: 0644 overwrite: true contents: source: data:,sctp
MachineConfig
オブジェクトを作成するには、以下のコマンドを入力します。$ oc create -f load-sctp-module.yaml
オプション: MachineConfig Operator が設定変更を適用している間にノードのステータスを確認するには、以下のコマンドを入力します。ノードのステータスが
Ready
に移行すると、設定の更新が適用されます。$ oc get nodes
9.3. SCTP (Stream Control Transmission Protocol) が有効になっていることの確認
SCTP がクラスターで機能することを確認するには、SCTP トラフィックをリッスンするアプリケーションで Pod を作成し、これをサービスに関連付け、公開されたサービスに接続します。
前提条件
-
クラスターからインターネットにアクセスし、
nc
パッケージをインストールすること。 -
OpenShift CLI (
oc
) をインストールします。 -
cluster-admin
ロールを持つユーザーとしてのクラスターへのアクセス。
手順
SCTP リスナーを起動する Pod を作成します。
以下の YAML で Pod を定義する
sctp-server.yaml
という名前のファイルを作成します。apiVersion: v1 kind: Pod metadata: name: sctpserver labels: app: sctpserver spec: containers: - name: sctpserver image: registry.access.redhat.com/ubi8/ubi command: ["/bin/sh", "-c"] args: ["dnf install -y nc && sleep inf"] ports: - containerPort: 30102 name: sctpserver protocol: SCTP
以下のコマンドを入力して Pod を作成します。
$ oc create -f sctp-server.yaml
SCTP リスナー Pod のサービスを作成します。
以下の YAML でサービスを定義する
sctp-service.yaml
という名前のファイルを作成します。apiVersion: v1 kind: Service metadata: name: sctpservice labels: app: sctpserver spec: type: NodePort selector: app: sctpserver ports: - name: sctpserver protocol: SCTP port: 30102 targetPort: 30102
サービスを作成するには、以下のコマンドを入力します。
$ oc create -f sctp-service.yaml
SCTP クライアントの Pod を作成します。
以下の YAML で
sctp-client.yaml
という名前のファイルを作成します。apiVersion: v1 kind: Pod metadata: name: sctpclient labels: app: sctpclient spec: containers: - name: sctpclient image: registry.access.redhat.com/ubi8/ubi command: ["/bin/sh", "-c"] args: ["dnf install -y nc && sleep inf"]
Pod
オブジェクトを作成するには、以下のコマンドを入力します。$ oc apply -f sctp-client.yaml
サーバーで SCTP リスナーを実行します。
サーバー Pod に接続するには、以下のコマンドを入力します。
$ oc rsh sctpserver
SCTP リスナーを起動するには、以下のコマンドを入力します。
$ nc -l 30102 --sctp
サーバーの SCTP リスナーに接続します。
- ターミナルプログラムで新規のターミナルウィンドウまたはタブを開きます。
sctpservice
サービスの IP アドレスを取得します。以下のコマンドを入力します。$ oc get services sctpservice -o go-template='{{.spec.clusterIP}}{{"\n"}}'
クライアント Pod に接続するには、以下のコマンドを入力します。
$ oc rsh sctpclient
SCTP クライアントを起動するには、以下のコマンドを入力します。
<cluster_IP>
をsctpservice
サービスのクラスター IP アドレスに置き換えます。# nc <cluster_IP> 30102 --sctp
第10章 PTP ハードウェアの使用
境界クロックとして設定した PTP (Precision Time Protocol) ハードウェアは、テクノロジープレビュー機能としてのみ提供されています。テクノロジープレビュー機能は Red Hat の実稼働環境でのサービスレベルアグリーメント (SLA) ではサポートされていないため、Red Hat では実稼働環境での使用を推奨していません。Red Hat は実稼働環境でこれらを使用することを推奨していません。これらの機能は、近々発表予定の製品機能をリリースに先駆けてご提供することにより、お客様は機能性をテストし、開発プロセス中にフィードバックをお寄せいただくことができます。
Red Hat のテクノロジープレビュー機能のサポート範囲についての詳細は、https://access.redhat.com/ja/support/offerings/techpreview/ を参照してください。
10.1. PTP ハードウェアについて
OpenShift Container Platform では、ノード上で PTP ハードウェアを使用できます。linuxptp サービスは、PTP 対応ハードウェアを搭載したノードで設定できます。
PTP Operator は、ベアメタルインフラストラクチャーでのみプロビジョニングされるクラスターの PTP 対応デバイスと連携します。
PTP Operator をデプロイし、OpenShift Container Platform コンソールまたは oc
を使用して PTP をインストールできます。PTP Operator は linuxptp サービスを作成し、管理し、以下の機能を提供します。
- クラスター内の PTP 対応デバイスの検出。
- linuxptp サービスの設定の管理。
-
PTP Operator
cloud-event-proxy
サイドカーによるアプリケーションのパフォーマンスおよび信頼性に悪影響を与える PTP クロックイベントの通知。
10.2. PTP について
Precision Time Protocol (PTP) は、ネットワーク内のクロックを同期するのに使用されます。ハードウェアサポートと併用する場合、PTP はマイクロ秒以下の正確性があり、Network Time Protocol (NTP) よりも正確になります。
linuxptp
パッケージには、クロック同期用の ptp4l
および phc2sys
プログラムが含まれています。ptp4l
は、PTP 境界クロックと通常のクロックを実装します。ptp4l
は PTP ハードウェアクロックをハードウェアのタイムスタンプにソースクロックに同期し、システムクロックをソフトウェアタイムスタンプとクロックに同期します。phc2sys
は、ネットワークインターフェースコントローラー (NIC) 上の PTP ハードウェアクロックに同期するために、ハードウェアタイムスタンプに使用されます。
10.2.1. PTP ドメインの要素
PTP は、ネットワークに接続された複数のノードを各ノードのクロックと同期するために使用されます。以下のタイプのクロックを設定に追加できます。
- グランドマスタークロック
- グランドマスタークロックは、ネットワーク全体の他のクロックに標準時間情報を提供し、正確で安定した同期を保証します。グランドマスタークロッククロックはタイムスタンプを書き込み、他のクロックからのタイムリクエストに応答します。
- 通常のクロック
- 通常のクロックには、ネットワーク内の位置に応じて、送信元クロックまたは宛先クロックの役割を果たすことができる単一のポート接続があります。通常のクロックは、タイムスタンプの読み取りおよび書き込みが可能です。
- 境界クロック
- 境界クロックには、2 つ以上の通信パスにあるポートがあり、ソースと宛先の宛先を同時に他の宛先クロックに指定できます。境界クロックは、宛先クロックアップストリームとして機能します。宛先クロックはタイミングメッセージを受け取り、遅延に合わせて調整し、ネットワークを渡す新しいソースタイムシグナルを作成します。境界クロックは、ソースクロックと正しく同期され、ソースクロックに直接レポートする接続されたデバイスの数を減らすことができる新しいタイミングパケットを生成します。
10.2.2. NTP 上の PTP の利点
PTP が NTP を経由した主な利点の 1 つは、さまざまなネットワークインターフェースコントローラー (NIC) およびネットワークスイッチにあるハードウェアサポートです。この特化されたハードウェアにより、PTP はメッセージ送信の遅れを説明でき、時間同期の精度を高められます。可能な限りの精度を実現するには、PTP クロック間の全ネットワークコンポーネントが PTP ハードウェアを有効にすることが推奨されます。
NICはPTPパケットを送受信した瞬間にタイムスタンプを付けることができるため、ハードウェアベースのPTPは最適な精度を提供します。これをソフトウェアベースの PTP と比較します。これには、オペレーティングシステムによる PTP パケットの追加処理が必要になります。
PTP を有効にする前に、必要なノードについて NTP が無効になっていることを確認します。MachineConfig
カスタムリソースを使用して chrony タイムサービス (chronyd
) を無効にすることができます。詳細は、chrony タイムサービスの無効化を参照してください。
10.3. CLI を使用した PTP Operator のインストール
クラスター管理者は、CLI を使用して Operator をインストールできます。
前提条件
- PTP に対応するハードウェアを持つノードでベアメタルハードウェアにインストールされたクラスター。
-
OpenShift CLI (
oc
) をインストールします。 -
cluster-admin
権限を持つユーザーとしてログインしている。
手順
PTP Operator の namespace を作成するには、以下のコマンドを入力します。
$ cat << EOF| oc create -f - apiVersion: v1 kind: Namespace metadata: name: openshift-ptp annotations: workload.openshift.io/allowed: management labels: name: openshift-ptp openshift.io/cluster-monitoring: "true" EOF
Operator の Operator グループを作成するには、以下のコマンドを入力します。
$ cat << EOF| oc create -f - apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: ptp-operators namespace: openshift-ptp spec: targetNamespaces: - openshift-ptp EOF
PTP Operator にサブスクライブします。
以下のコマンドを実行して、OpenShift Container Platform のメジャーおよびマイナーバージョンを環境変数として設定します。これは次の手順で
channel
の値として使用されます。$ OC_VERSION=$(oc version -o yaml | grep openshiftVersion | \ grep -o '[0-9]*[.][0-9]*' | head -1)
PTP Operator のサブスクリプションを作成するには、以下のコマンドを入力します。
$ cat << EOF| oc create -f - apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: ptp-operator-subscription namespace: openshift-ptp spec: channel: "${OC_VERSION}" name: ptp-operator source: redhat-operators sourceNamespace: openshift-marketplace EOF
Operator がインストールされていることを確認するには、以下のコマンドを入力します。
$ oc get csv -n openshift-ptp \ -o custom-columns=Name:.metadata.name,Phase:.status.phase
出力例
Name Phase ptp-operator.4.4.0-202006160135 Succeeded
10.4. Web コンソールを使用した PTP Operator のインストール
クラスター管理者は、Web コンソールを使用して PTP Operator をインストールできます。
先のセクションで説明されているように namespace および Operator グループを作成する必要があります。
手順
OpenShift Container Platform Web コンソールを使用して PTP Operator をインストールします。
- OpenShift Container Platform Web コンソールで、Operators → OperatorHub をクリックします。
- 利用可能な Operator の一覧から PTP Operator を選択してから Install をクリックします。
- Install Operator ページの A specific namespace on the cluster の下で openshift-ptp を選択します。次に、Install をクリックします。
オプション: PTP Operator が正常にインストールされていることを確認します。
- Operators → Installed Operators ページに切り替えます。
PTP Operator が Status が InstallSucceeded の状態で openshift-ptp プロジェクトに一覧表示されていることを確認します。
注記インストール時に、 Operator は Failed ステータスを表示する可能性があります。インストールが後に InstallSucceeded メッセージを出して正常に実行される場合は、Failed メッセージを無視できます。
Operator がインストール済みとして表示されない場合に、さらにトラブルシューティングを実行します。
- Operators → Installed Operators ページに移動し、Operator Subscriptions および Install Plans タブで Status にエラーがあるかどうかを検査します。
-
Workloads → Pods ページに移動し、
openshift-ptp
プロジェクトで Pod のログを確認します。
10.5. PTP ネットワークデバイスの自動検出
PTP Operator は NodePtpDevice.ptp.openshift.io
カスタムリソース定義 (CRD) を OpenShift Container Platform に追加します。
PTP Operator はクラスターで、各ノードの PTP 対応ネットワークデバイスを検索します。これは、互換性のある PTP デバイスを提供する各ノードの NodePtpDevice
カスタムリソース (CR) オブジェクトを作成し、更新します。
1 つの CR がノードごとに作成され、ノードと同じ名前を共有します。.status.devices
一覧は、ノード上の PTP デバイスについての情報を提供します。
以下は、PTP Operator によって作成される NodePtpDevice
CR の例です。
apiVersion: ptp.openshift.io/v1 kind: NodePtpDevice metadata: creationTimestamp: "2019-11-15T08:57:11Z" generation: 1 name: dev-worker-0 1 namespace: openshift-ptp 2 resourceVersion: "487462" selfLink: /apis/ptp.openshift.io/v1/namespaces/openshift-ptp/nodeptpdevices/dev-worker-0 uid: 08d133f7-aae2-403f-84ad-1fe624e5ab3f spec: {} status: devices: 3 - name: eno1 - name: eno2 - name: ens787f0 - name: ens787f1 - name: ens801f0 - name: ens801f1 - name: ens802f0 - name: ens802f1 - name: ens803
クラスター内の PTP 対応ネットワークデバイスの一覧を返すには、以下のコマンドを実行します。
$ oc get NodePtpDevice -n openshift-ptp -o yaml
10.6. linuxptp サービスを通常のクロックとして設定
PTP Operator は PtpConfig.ptp.openshift.io
カスタムリソース定義 (CRD) を OpenShift Container Platform に追加します。PtpConfig
カスタムリソース (CR) オブジェクトを作成して、linuxptp サービス (ptp4l
、phc2sys
) を設定できます。
前提条件
-
OpenShift CLI (
oc
) をインストールします。 -
cluster-admin
権限を持つユーザーとしてログインしている。 - PTP Operator をインストールします。
手順
以下の
PtpConfig
CR を作成してから、YAML をordinary-clock-ptp-config.yaml
ファイルに保存します。apiVersion: ptp.openshift.io/v1 kind: PtpConfig metadata: name: ordinary-clock-ptp-config 1 namespace: openshift-ptp spec: profile: 2 - name: "profile1" 3 interface: "ens787f1" 4 ptp4lOpts: "-s -2" 5 phc2sysOpts: "-a -r" 6 ptp4lConf: "" 7 ptpSchedulingPolicy: SCHED_OTHER 8 ptpSchedulingPriority: 65 9 recommend: 10 - profile: "profile1" 11 priority: 10 12 match: 13 - nodeLabel: "node-role.kubernetes.io/worker" 14 nodeName: "compute-0.example.com" 15
- 1
PtpConfig
CR の名前。- 2
- 1 つ以上の
profile
オブジェクトの配列を指定します。 - 3
- プロファイルオブジェクトを一意に識別するプロファイルオブジェクトの名前を指定します。
- 4
ptp4l
サービスで使用するネットワークインターフェース名を指定します (例:ens787f1
)。- 5
ptp4l
サービスのシステム設定オプションを指定します。たとえば、-2
で IEEE 802.3 ネットワークトランスポートを選択します。ネットワークインターフェース名とサービス設定ファイルが自動的に追加されるため、オプションには、ネットワークインターフェース名-i <interface>
およびサービス設定ファイル-f /etc/ptp4l.conf
を含めないでください。- 6
phc2sys
サービスのシステム設定オプション(例:-a -r
) を指定します。このフィールドが空の場合、PTP Operator はphc2sys
サービスを開始しません。- 7
- デフォルトの
/etc/ptp4l.conf
ファイルを置き換える設定が含まれる文字列を指定します。デフォルト設定を使用するには、フィールドを空のままにします。 - 8
ptp4l
とphc2sys
プロセスのスケジューリングポリシー。デフォルト値はSCHED_OTHER
です。FIFO スケジューリングをサポートするシステムでは、SCHED_FIFO
を使用してください。- 9
ptp4l
およびphc2sys
プロセスの FIFO 優先度の設定に使用する 1〜65 の整数値。ptp Scheduling Policy
にSCHED_FIFO
が設定されている場合は必須です。- 10
profile
がノードに適用される方法を定義する 1 つ以上のrecommend
オブジェクトの配列を指定します。- 11
profile
セクションに定義されるprofile
オブジェクト名を指定します。- 12
0
から99
までの整数値でpriority
を指定します。数値が大きいほど優先度が低くなるため、99
の優先度は10
よりも低くなります。ノードがmatch
フィールドで定義されるルールに基づいて複数のプロファイルに一致する場合、優先順位の高いプロファイルがそのノードに適用されます。- 13
match
ルールを、nodeLabel
またはnodeName
で指定します。- 14
oc get nodes --show-labels
コマンドを使用して、ノードオブジェクトのnode.Labels
のkey
でnodeLabel
を指定します。- 15
oc get nodes
コマンドを使用して、ノードオブジェクトのnode.Name
でnodeName
を指定します。
以下のコマンドを実行して CR を作成します。
$ oc create -f ordinary-clock-ptp-config.yaml
検証手順
PtpConfig
プロファイルがノードに適用されていることを確認します。以下のコマンドを実行して、
openshift-ptp
namespace の Pod の一覧を取得します。$ oc get pods -n openshift-ptp -o wide
出力例
NAME READY STATUS RESTARTS AGE IP NODE linuxptp-daemon-4xkbb 1/1 Running 0 43m 10.1.196.24 compute-0.example.com linuxptp-daemon-tdspf 1/1 Running 0 43m 10.1.196.25 compute-1.example.com ptp-operator-657bbb64c8-2f8sj 1/1 Running 0 43m 10.129.0.61 control-plane-1.example.com
プロファイルが正しいことを確認します。
PtpConfig
プロファイルで指定したノードに対応するlinuxptp
デーモンのログを検査します。以下のコマンドを実行します。$ oc logs linuxptp-daemon-4xkbb -n openshift-ptp -c linuxptp-daemon-container
出力例
I1115 09:41:17.117596 4143292 daemon.go:107] in applyNodePTPProfile I1115 09:41:17.117604 4143292 daemon.go:109] updating NodePTPProfile to: I1115 09:41:17.117607 4143292 daemon.go:110] ------------------------------------ I1115 09:41:17.117612 4143292 daemon.go:102] Profile Name: profile1 I1115 09:41:17.117616 4143292 daemon.go:102] Interface: ens787f1 I1115 09:41:17.117620 4143292 daemon.go:102] Ptp4lOpts: -s -2 I1115 09:41:17.117623 4143292 daemon.go:102] Phc2sysOpts: -a -r I1115 09:41:17.117626 4143292 daemon.go:116] ------------------------------------
10.7. linuxptp サービスを境界クロックとして設定
PTP Operator は PtpConfig.ptp.openshift.io
カスタムリソース定義 (CRD) を OpenShift Container Platform に追加します。PtpConfig
カスタムリソース (CR) オブジェクトを作成して、linuxptp
サービス (ptp4l
、phc2sys
) を設定できます。
前提条件
-
OpenShift CLI (
oc
) をインストールします。 -
cluster-admin
権限を持つユーザーとしてログインしている。 - PTP Operator をインストールします。
手順
以下の
PtpConfig
CR を作成してから、YAML をboundary-clock-ptp-config.yaml
ファイルに保存します。apiVersion: ptp.openshift.io/v1 kind: PtpConfig metadata: name: boundary-clock-ptp-config 1 namespace: openshift-ptp spec: profile: 2 - name: "profile1" 3 interface: "" 4 ptp4lOpts: "-2" 5 ptp4lConf: | 6 [ens1f0] 7 masterOnly 0 [ens1f3] 8 masterOnly 1 [global] # # Default Data Set # twoStepFlag 1 #slaveOnly 1 priority1 128 priority2 128 domainNumber 24 #utc_offset 37 clockClass 248 clockAccuracy 0xFE offsetScaledLogVariance 0xFFFF free_running 0 freq_est_interval 1 dscp_event 0 dscp_general 0 dataset_comparison G.8275.x G.8275.defaultDS.localPriority 128 # # Port Data Set # logAnnounceInterval -3 logSyncInterval -4 logMinDelayReqInterval -4 logMinPdelayReqInterval -4 announceReceiptTimeout 3 syncReceiptTimeout 0 delayAsymmetry 0 fault_reset_interval 4 neighborPropDelayThresh 20000000 masterOnly 0 G.8275.portDS.localPriority 128 # # Run time options # assume_two_step 0 logging_level 6 path_trace_enabled 0 follow_up_info 0 hybrid_e2e 0 inhibit_multicast_service 0 net_sync_monitor 0 tc_spanning_tree 0 tx_timestamp_timeout 10 #was 1 (default !) unicast_listen 0 unicast_master_table 0 unicast_req_duration 3600 use_syslog 1 verbose 0 summary_interval -4 kernel_leap 1 check_fup_sync 0 # # Servo Options # pi_proportional_const 0.0 pi_integral_const 0.0 pi_proportional_scale 0.0 pi_proportional_exponent -0.3 pi_proportional_norm_max 0.7 pi_integral_scale 0.0 pi_integral_exponent 0.4 pi_integral_norm_max 0.3 step_threshold 0 first_step_threshold 0.00002 max_frequency 900000000 clock_servo pi sanity_freq_limit 200000000 ntpshm_segment 0 # # Transport options # transportSpecific 0x0 ptp_dst_mac 01:1B:19:00:00:00 p2p_dst_mac 01:80:C2:00:00:0E udp_ttl 1 udp6_scope 0x0E uds_address /var/run/ptp4l # # Default interface options # clock_type BC network_transport UDPv4 delay_mechanism E2E time_stamping hardware tsproc_mode filter delay_filter moving_median delay_filter_length 10 egressLatency 0 ingressLatency 0 boundary_clock_jbod 1 # # Clock description # productDescription ;; revisionData ;; manufacturerIdentity 00:00:00 userDescription ; timeSource 0xA0 phc2sysOpts: "-a -r" 9 ptpSchedulingPolicy: SCHED_OTHER 10 ptpSchedulingPriority: 65 11 recommend: 12 - profile: "profile1" 13 priority: 10 14 match: 15 - nodeLabel: "node-role.kubernetes.io/worker" 16 nodeName: "compute-0.example.com" 17
- 1
PtpConfig
CR の名前。- 2
- 1 つ以上の
profile
オブジェクトの配列を指定します。 - 3
- プロファイルオブジェクトを一意に識別するプロファイルオブジェクトの名前を指定します。
- 4
- このフィールドは、境界クロックの場合は空のままにする必要があります。
- 5
ptp4l
サービスのシステム設定オプション (例:-2
) を指定します。ネットワークインターフェース名とサービス設定ファイルが自動的に追加されるため、オプションには、ネットワークインターフェース名-i <interface>
およびサービス設定ファイル-f /etc/ptp4l.conf
を含めないでください。- 6
ptp4l
を境界クロックとして起動するために必要な設定を指定します。たとえば、ens1f0
はグランドマスタークロックから同期し、ens1f3
は接続されたデバイスを同期します。- 7
- 同期元のインターフェース名。
- 8
- インターフェースに接続されたデバイスを同期するインターフェース。
- 9
phc2sys
サービスのシステム設定オプション(例:-a -r
) を指定します。このフィールドが空の場合、PTP Operator はphc2sys
サービスを開始しません。- 10
- ptp4l と phc2sys プロセスのスケジューリングポリシー。デフォルト値は
SCHED_OTHER
です。FIFO スケジューリングをサポートするシステムでは、SCHED_FIFO
を使用してください。 - 11
ptp4l
およびphc2sys
プロセスの FIFO 優先度の設定に使用する 1〜65 の整数値。ptp Scheduling Policy
にSCHED_FIFO
が設定されている場合は必須です。- 12
profile
がノードに適用される方法を定義する 1 つ以上のrecommend
オブジェクトの配列を指定します。- 13
profile
セクションに定義されるprofile
オブジェクト名を指定します。- 14
0
から99
までの整数値でpriority
を指定します。数値が大きいほど優先度が低くなるため、99
の優先度は10
よりも低くなります。ノードがmatch
フィールドで定義されるルールに基づいて複数のプロファイルに一致する場合、優先順位の高いプロファイルがそのノードに適用されます。- 15
match
ルールを、nodeLabel
またはnodeName
で指定します。- 16
oc get nodes --show-labels
コマンドを使用して、ノードオブジェクトのnode.Labels
のkey
でnodeLabel
を指定します。- 17
oc get nodes
コマンドを使用して、ノードオブジェクトのnode.Name
でnodeName
を指定します。
以下のコマンドを実行して CR を作成します。
$ oc create -f boundary-clock-ptp-config.yaml
検証手順
PtpConfig
プロファイルがノードに適用されていることを確認します。以下のコマンドを実行して、
openshift-ptp
namespace の Pod の一覧を取得します。$ oc get pods -n openshift-ptp -o wide
出力例
NAME READY STATUS RESTARTS AGE IP NODE linuxptp-daemon-4xkbb 1/1 Running 0 43m 10.1.196.24 compute-0.example.com linuxptp-daemon-tdspf 1/1 Running 0 43m 10.1.196.25 compute-1.example.com ptp-operator-657bbb64c8-2f8sj 1/1 Running 0 43m 10.129.0.61 control-plane-1.example.com
プロファイルが正しいことを確認します。
PtpConfig
プロファイルで指定したノードに対応するlinuxptp
デーモンのログを検査します。以下のコマンドを実行します。$ oc logs linuxptp-daemon-4xkbb -n openshift-ptp -c linuxptp-daemon-container
出力例
I1115 09:41:17.117596 4143292 daemon.go:107] in applyNodePTPProfile I1115 09:41:17.117604 4143292 daemon.go:109] updating NodePTPProfile to: I1115 09:41:17.117607 4143292 daemon.go:110] ------------------------------------ I1115 09:41:17.117612 4143292 daemon.go:102] Profile Name: profile1 I1115 09:41:17.117616 4143292 daemon.go:102] Interface: I1115 09:41:17.117620 4143292 daemon.go:102] Ptp4lOpts: -2 I1115 09:41:17.117623 4143292 daemon.go:102] Phc2sysOpts: -a -r I1115 09:41:17.117626 4143292 daemon.go:116] ------------------------------------
10.8. PTP ハードウェアの FIFO 優先スケジューリングの設定
低遅延のパフォーマンスを確保する必要のある通信業者や他のデプロイメント設定では、PTP デーモンスレッドは、制約された CPU フットプリントで、残りのインフラストラクチャーのコンポーネントと一緒に、実行されます。デフォルトでは、PTP スレッドはSCHED_OTHER
ポリシーで実行されます。負荷が高いと、エラーなしで運用する必要のある、これらのスレッドのスケジューリングでレイテンシーが発生する可能性があります。
スケジューリングのレイテンシーでエラーが発生する可能性を軽減するために、SCHED_FIFO
ポリシーでスレッドを実行できるように、PTP Operator のlinuxptp
サービスを設定できます。Ptp Config
CR にSCHED_FIFO
が設定されている場合には、ptp4l
とphc2sys
は、Ptp Config
CR のptp Scheduling Priority
フィールドで設定された優先順位で、chrt
の下の親コンテナーで実行されます。
ptp Scheduling Policy
の設定はオプションで、レイテンシーエラーが発生している場合にのみ必要となります。
手順
Ptp Config
CR プロファイルを編集します。$ oc edit PtpConfig -n openshift-ptp
ptp Scheduling Policy
とptp Scheduling Priority
フィールドを変更します。apiVersion: ptp.openshift.io/v1 kind: PtpConfig metadata: name: <ptp_config_name> namespace: openshift-ptp ... spec: profile: - name: "profile1" ... ptpSchedulingPolicy: SCHED_FIFO 1 ptpSchedulingPriority: 65 2
-
保存して終了すると、
Ptp Config
CR に変更が適用されます。
検証
Ptp Config
CR が適用されたlinuxptp-daemon
Pod と対応するノードの名前を取得します。$ oc get pods -n openshift-ptp -o wide
出力例
NAME READY STATUS RESTARTS AGE IP NODE linuxptp-daemon-gmv2n 3/3 Running 0 1d17h 10.1.196.24 compute-0.example.com linuxptp-daemon-lgm55 3/3 Running 0 1d17h 10.1.196.25 compute-1.example.com ptp-operator-3r4dcvf7f4-zndk7 1/1 Running 0 1d7h 10.129.0.61 control-plane-1.example.com
ptp4l
プロセスが、更新されたchrt
FIFO 優先度で実行されていることを確認します。$ oc -n openshift-ptp logs linuxptp-daemon-lgm55 -c linuxptp-daemon-container|grep chrt
出力例
I1216 19:24:57.091872 1600715 daemon.go:285] /bin/chrt -f 65 /usr/sbin/ptp4l -f /var/run/ptp4l.0.config -2 --summary_interval -4 -m
10.9. 一般的な PTP Operator の問題のトラブルシューティング
以下の手順を実行して、PTP Operator で典型的な問題のトラブルシューティングを行います。
前提条件
-
OpenShift Container Platform CLI (
oc
) をインストールします。 -
cluster-admin
権限を持つユーザーとしてログインしている。 - PTP をサポートするホストを使用して、PTP Operator をベアメタルクラスターにインストールします。
手順
Operator およびオペランドが、設定されたノードについてクラスターに正常にデプロイされていることを確認します。
$ oc get pods -n openshift-ptp -o wide
出力例
NAME READY STATUS RESTARTS AGE IP NODE linuxptp-daemon-lmvgn 3/3 Running 0 4d17h 10.1.196.24 compute-0.example.com linuxptp-daemon-qhfg7 3/3 Running 0 4d17h 10.1.196.25 compute-1.example.com ptp-operator-6b8dcbf7f4-zndk7 1/1 Running 0 5d7h 10.129.0.61 control-plane-1.example.com
注記PTP 高速イベントバスが有効な場合には、準備できた
linuxptp-daemon
Pod の数は3/3
になります。PTP 高速イベントバスが有効になっていない場合、2/2
が表示されます。サポートされているハードウェアがクラスターにあることを確認します。
$ oc -n openshift-ptp get nodeptpdevices.ptp.openshift.io
出力例
NAME AGE control-plane-0.example.com 10d control-plane-1.example.com 10d compute-0.example.com 10d compute-1.example.com 10d compute-2.example.com 10d
ノードで利用可能な PTP ネットワークインターフェースを確認します。
$ oc -n openshift-ptp get nodeptpdevices.ptp.openshift.io <node_name> -o yaml
ここで、
- <node_name>
問い合わせるノードを指定します(例:
compute-0.example.com
)。出力例
apiVersion: ptp.openshift.io/v1 kind: NodePtpDevice metadata: creationTimestamp: "2021-09-14T16:52:33Z" generation: 1 name: compute-0.example.com namespace: openshift-ptp resourceVersion: "177400" uid: 30413db0-4d8d-46da-9bef-737bacd548fd spec: {} status: devices: - name: eno1 - name: eno2 - name: eno3 - name: eno4 - name: enp5s0f0 - name: enp5s0f1
対応するノードの
linuxptp-daemon
Pod にアクセスし、PTP インターフェースがプライマリークロックに正常に同期されていることを確認します。以下のコマンドを実行して、
linuxptp-daemon
Pod の名前と、トラブルシューティングに使用するノードを取得します。$ oc get pods -n openshift-ptp -o wide
出力例
NAME READY STATUS RESTARTS AGE IP NODE linuxptp-daemon-lmvgn 3/3 Running 0 4d17h 10.1.196.24 compute-0.example.com linuxptp-daemon-qhfg7 3/3 Running 0 4d17h 10.1.196.25 compute-1.example.com ptp-operator-6b8dcbf7f4-zndk7 1/1 Running 0 5d7h 10.129.0.61 control-plane-1.example.com
リモートシェルが必要な
linuxptp-daemon
コンテナーへのリモートシェルです。$ oc rsh -n openshift-ptp -c linuxptp-daemon-container <linux_daemon_container>
ここで、
- <linux_daemon_container>
-
診断するコンテナーです(例:
linuxptp-daemon-lmvgn
)。
linuxptp-daemon
コンテナーへのリモートシェル接続では、PTP 管理クライアント(pmc
)ツールを使用して、ネットワークインターフェースを診断します。以下のpmc
コマンドを実行して、PTP デバイスの同期ステータスを確認します(例:ptp4l
)。# pmc -u -f /var/run/ptp4l.0.config -b 0 'GET PORT_DATA_SET'
ノードがプライマリークロックに正常に同期されたときの出力例
sending: GET PORT_DATA_SET 40a6b7.fffe.166ef0-1 seq 0 RESPONSE MANAGEMENT PORT_DATA_SET portIdentity 40a6b7.fffe.166ef0-1 portState SLAVE logMinDelayReqInterval -4 peerMeanPathDelay 0 logAnnounceInterval -3 announceReceiptTimeout 3 logSyncInterval -4 delayMechanism 1 logMinPdelayReqInterval -4 versionNumber 2
10.10. PTP ハードウェアの高速イベント通知フレームワーク
通常のクロックを使用した PTP イベントは、テクノロジープレビューとしてのみ機能します。テクノロジープレビュー機能は Red Hat の実稼働環境でのサービスレベルアグリーメント (SLA) ではサポートされていないため、Red Hat では実稼働環境での使用を推奨していません。Red Hat は実稼働環境でこれらを使用することを推奨していません。これらの機能は、近々発表予定の製品機能をリリースに先駆けてご提供することにより、お客様は機能性をテストし、開発プロセス中にフィードバックをお寄せいただくことができます。
Red Hat のテクノロジープレビュー機能のサポート範囲についての詳細は、https://access.redhat.com/ja/support/offerings/techpreview/ を参照してください。
10.10.1. PTP およびクロック同期エラーイベントについて
仮想 RAN などのクラウドネイティブアプリケーションでは、ネットワーク全体の機能に重要なハードウェアタイミングイベントに関する通知へのアクセスが必要です。高速イベント通知は、差し迫ったおよび Real-time Precision Time Protocol (PTP)のクロック同期イベントに関する早期の警告シグナルです。PTP クロック同期エラーは、分散ユニット(DU)で実行している vRAN アプリケーションなど、低レイテンシーアプリケーションのパフォーマンスおよび信頼性に悪影響を及ぼす可能性があります。
PTP 同期の損失は、RAN ネットワークでは重大なエラーです。ノードで同期が失われると、無線がシャットダウンされ、ネットワークのOTA(Over the Air)トラフィックがワイヤレスネットワーク内の別のノードにシフトされる可能性があります。高速のイベント通知は、クラスターノードが DU で実行している vRAN アプリケーションに対して PTP クロック同期ステータスと通信できるようにすることで、ワークロードのエラーを軽減します。
イベント通知は、同じ DU ノードで実行している RAN アプリケーションで利用できます。パブリッシュ/サブスクライブ REST API は、イベント通知をメッセージングバスに渡します。パブリッシュ/サブスクライブメッセージング、またはpub/subメッセージングは、トピックに公開されたメッセージがトピックのすべてのサブスクライバーに即座に受信される、サービス通信アーキテクチャへの非同期サービスです。
高速イベント通知は、すべての PTP 対応ネットワークインターフェースについて OpenShift Container Platform の PTP Operator によって生成されます。イベントは、Advanced Message Queuing Protocol (AMQP)メッセージバスで cloud-event-proxy
サイドカーコンテナーを使用して利用可能になります。AMQP メッセージバスは AMQ Interconnect Operator によって提供されます。
PTP 高速イベント通知は、PTP もしくは通常のクロックを使用するように設定されたネットワークインターフェースでのみ利用できます。
10.10.2. PTP 高速イベント通知フレームワークについて
分散ユニット(DU)アプリケーションを、PTP Operator および cloud-event-proxy
サイドカーコンテナーを使用して、OpenShift Container Platform によって生成される Precision Time Protocol(PTP)高速イベント通知にサブスクライブできます。ptpOperatorConfig
カスタムリソース(CR)で enableEventPublisher
フィールドを true
に設定し、transportHost
アドレスを指定することで、cloud-event-proxy
サイドカーコンテナーを有効にします 。PTP 高速イベントは、AMQ Interconnect Operator によって提供される Advanced Message Queuing Protocol (AMQP)イベント通知バスを使用します。AMQ Interconnect は Red Hat AMQ のコンポーネントで、AMQP 対応エンドポイント間でメッセージを柔軟にルーティングするメッセージングルーターです。
cloud-event-proxy
サイドカーコンテナーは、プライマリーアプリケーションのリソースを使用せずに、プライマリー vRAN アプリケーションと同じリソースにアクセスでき、レイテンシーが大きくなくても構いません。
高速イベント通知フレームワークは通信に REST API を使用し、O-RAN REST API 仕様に基づいています。フレームワークは、パブリッシャーとサブスクライバーアプリケーション間の通信を処理するパブリッシャー、サブスクライバー、および AMQ メッセージングバスで構成されます。cloud-event-proxy
サイドカーは、DU ノードのメイン DU アプリケーションコンテナーにゆるく結合された Pod で実行するユーティリティーコンテナーです。これは、DU アプリケーションを公開された PTP イベントにサブスクライブできるようにするイベント公開フレームワークを提供します。
DU アプリケーションはサイドカーパターンで cloud-event-proxy
コンテナーを実行し、PTP イベントにサブスクライブします。以下のワークフローでは、DU アプリケーションが PTP 高速イベントを使用する方法について説明します。
-
DU アプリケーションはサブスクリプションを要求: DU は API リクエストを
cloud-event-proxy
サイドカーに送信し、PTP イベントサブスクリプションを作成します。cloud-event-proxy
サイドカーは、サブスクリプションリソースを作成します。 -
cloud-event-proxy サイドカーは、サブスクリプションを作成: イベントリソースは
cloud-event-proxy
サイドカーによって永続化されます。cloud-event-proxy
サイドカーコンテナーは、ID と URL の場所で確認応答を送信し、保存されたサブスクリプションリソースにアクセスします。サイドカーは、サブスクリプションに指定されたリソースの AMQ メッセージングリスナープロトコルを作成します。 -
DU アプリケーションは PTP イベント通知を受受け取る:
cloud-event-proxy
サイドカーコンテナーは、リソース修飾子で指定されたアドレスをリッスンします。DU イベントのコンシューマーはメッセージを処理し、これをサブスクリプションで指定した返信 URL に渡します。 -
cloud-event-proxy サイドカーは、PTP イベントを検証し、これを DU アプリケーションに送信:
cloud-event-proxy
サイドカーはイベントを受信し、クラウドイベントオブジェクトをアンラップデータを取得し、イベントを返す URL を取得して DU コンシューマーアプリケーションに返します。 - DU アプリケーションは PTP イベントを使用: DU アプリケーションイベントコンシューマーは PTP イベントを受信して処理します。
10.10.3. AMQ メッセージングバスのインストール
ノードのパブリッシャーとサブスクライバー間で PTP 高速イベント通知を渡すには、ノードでローカルに実行するように AMQ メッセージングバスをインストールおよび設定する必要があります。これは、クラスターで使用するために AMQ Interconnect Operator をインストールして行います。
前提条件
-
OpenShift Container Platform CLI (
oc
) をインストールします。 -
cluster-admin
権限を持つユーザーとしてログインしている。
手順
-
AMQ Interconnect Operator を独自の
amq-interconnect
namespace にインストールします。Red Hat Integration - AMQ Interconnect Operator の追加 を参照してください。
検証
AMQ Interconnect Operator が利用可能で、必要な Pod が実行していることを確認します。
$ oc get pods -n amq-interconnect
出力例
NAME READY STATUS RESTARTS AGE amq-interconnect-645db76c76-k8ghs 1/1 Running 0 23h interconnect-operator-5cb5fc7cc-4v7qm 1/1 Running 0 23h
必要な
linuxptp-daemon
PTP イベントプロデューサー Pod がopenshift-ptp
namespace で実行していることを確認します。$ oc get pods -n openshift-ptp
出力例
NAME READY STATUS RESTARTS AGE linuxptp-daemon-2t78p 3/3 Running 0 12h linuxptp-daemon-k8n88 3/3 Running 0 12h
10.10.4. PTP 高速イベント通知パブリッシャーの設定
クラスター内のネットワークインターフェースの PTP 高速イベント通知の使用を開始するには、PTP Operator PtpOperatorConfig
カスタムリソース(CR)で高速イベントパブリッシャーを有効にし、作成する PtpConfig
CR に ptpClockThreshold
値を設定する必要があります。
前提条件
-
OpenShift Container Platform CLI (
oc
) をインストールします。 -
cluster-admin
権限を持つユーザーとしてログインしている。 - PTP Operator および AMQ Interconnect Operator をインストールします。
手順
PtpOperatorConfig
リソースのspec.ptpEventConfig
フィールドを変更し、以下のコマンドを実行して適切な値を設定します。$ oc edit PtpOperatorConfig default -n openshift-ptp
... spec: daemonNodeSelector: node-role.kubernetes.io/worker: "" ptpEventConfig: enableEventPublisher: true 1 transportHost: amqp://<instance_name>.<namespace>.svc.cluster.local 2
PTP 対応インターフェースの
PtpConfig
カスタムリソースを作成し、ptpClockThreshold
に必要な値を設定します。以下に例を示します。apiVersion: ptp.openshift.io/v1 kind: PtpConfig metadata: name: example-ptpconfig namespace: openshift-ptp spec: profile: - name: "profile1" interface: "enp5s0f0" ptp4lOpts: "-2 -s --summary_interval -4" phc2sysOpts: "-a -r -m -n 24 -N 8 -R 16" ptpClockThreshold: holdOverTimeout: 5 1 maxOffsetThreshold: 100 2 minOffsetThreshold: -100 3 recommend: - profile: "profile1" priority: 4 match: - nodeLabel: "node-role.kubernetes.io/worker"
10.10.5. DU アプリケーションを PTP イベントにサブスクライブする RESTAPI リファレンス
PTP イベント通知 REST API を使用して、分散ユニット (DU) アプリケーションを親ノードで生成される PTP イベントにサブスクライブします。
リソースアドレス/cluster/node/<node_name>/ptp
を使用して、アプリケーションを PTP イベントにサブスクライブします。ここで、<node_name>
は、DU アプリケーションを実行しているクラスターノードです。
cloud-event-consumerDU
アプリケーションコンテナーとcloud-event-proxy
サイドカーコンテナーを別々の DU アプリケーション Pod にデプロイします。cloud-event-consumer
DU アプリケーションは、アプリケーション Pod のcloud-event-proxy
コンテナーにサブスクライブします。
次の API エンドポイントを使用して、cloud-event-consumer
DU アプリケーションを、DU アプリケーション Pod の http://localhost:8089/api/cloudNotifications/v1/
にある cloud-event-proxy
コンテナーによって投稿された PTP イベントにサブスクライブします。
/api/cloudNotifications/v1/subscriptions
-
POST
: 新しいサブスクリプションを作成します。 -
GET
: サブスクリプションの一覧を取得します。
-
/api/cloudNotifications/v1/subscriptions/<subscription_id>
-
GET
:指定されたサブスクリプション ID の詳細を返します。
-
api/cloudNotifications/v1/subscriptions/status/<subscription_id>
-
PUT
: 指定されたサブスクリプション ID に新しいステータス ping 要求を作成します。
-
/api/cloudNotifications/v1/health
-
GET
:cloudNotifications API
の正常性ステータスを返します。
-
9089
は、アプリケーション Pod にデプロイされた cloud-event-consumer
コンテナーのデフォルトポートです。必要に応じて、DU アプリケーションに別のポートを設定できます。
10.10.5.1. api/cloudNotifications/v1/subscriptions
10.10.5.1.1. HTTP メソッド
GET api/cloudNotifications/v1/subscriptions
10.10.5.1.1.1. 詳細
サブスクリプションの一覧を返します。サブスクリプションが存在する場合は、サブスクリプションの一覧とともに 200 OK
のステータスコードが返されます。
API 応答の例
[ { "id": "75b1ad8f-c807-4c23-acf5-56f4b7ee3826", "endpointUri": "http://localhost:9089/event", "uriLocation": "http://localhost:8089/api/cloudNotifications/v1/subscriptions/75b1ad8f-c807-4c23-acf5-56f4b7ee3826", "resource": "/cluster/node/compute-1.example.com/ptp" } ]
10.10.5.1.2. HTTP メソッド
POST api/cloudNotifications/v1/subscriptions
10.10.5.1.2.1. 詳細
新しいサブスクリプションを作成します。サブスクリプションが正常に作成されるか、すでに存在する場合は、201 Created
ステータスコードが返されます。
表10.1 クエリーパラメーター
パラメーター | タイプ |
---|---|
subscription | data |
ペイロードの例
{ "uriLocation": "http://localhost:8089/api/cloudNotifications/v1/subscriptions", "resource": "/cluster/node/compute-1.example.com/ptp" }
10.10.5.2. api/cloudNotifications/v1/subscriptions/<subscription_id>
10.10.5.2.1. HTTP メソッド
GET api/cloudNotifications/v1/subscriptions/<subscription_id>
10.10.5.2.1.1. 詳細
ID が <subscription_id>
のサブスクリプションの詳細を返します。
表10.2 クエリーパラメーター
パラメーター | タイプ |
---|---|
| string |
API 応答の例
{ "id":"48210fb3-45be-4ce0-aa9b-41a0e58730ab", "endpointUri": "http://localhost:9089/event", "uriLocation":"http://localhost:8089/api/cloudNotifications/v1/subscriptions/48210fb3-45be-4ce0-aa9b-41a0e58730ab", "resource":"/cluster/node/compute-1.example.com/ptp" }
10.10.5.3. api/cloudNotifications/v1/subscriptions/status/<subscription_id>
10.10.5.3.1. HTTP メソッド
PUT api/cloudNotifications/v1/subscriptions/status/<subscription_id>
10.10.5.3.1.1. 詳細
ID <subscription_id>
のサブスクリプションの新規ステータス ping 要求を作成します。サブスクリプションが存在する場合は、ステータスリクエストに成功し、202 Accepted
ステータスコードが返されます。
表10.3 クエリーパラメーター
パラメーター | タイプ |
---|---|
| string |
API 応答の例
{"status":"ping sent"}
10.10.5.4. api/cloudNotifications/v1/health/
10.10.5.4.1. HTTP メソッド
GET api/cloudNotifications/v1/health/
10.10.5.4.1.1. 詳細
cloudNotifications
REST API の正常性ステータスを返します。
API 応答の例
OK
10.10.6. CLI を使用した PTP 高速イベントメトリクスの監視
oc
CLI を使用して、cloud-event-proxy
コンテナーから直接高速イベントバスメトリクスをモニターできます。
PTP 高速イベント通知メトリクスは OpenShift Container Platform Web コンソールでも利用できます。
前提条件
-
OpenShift Container Platform CLI (
oc
) をインストールします。 -
cluster-admin
権限を持つユーザーとしてログインしている。 - PTP Operator をインストールし、設定します。
手順
アクティブな
linuxptp-daemon
Pod の一覧を取得します。$ oc get pods -n openshift-ptp
出力例
NAME READY STATUS RESTARTS AGE linuxptp-daemon-2t78p 3/3 Running 0 8h linuxptp-daemon-k8n88 3/3 Running 0 8h
以下のコマンドを実行して、必要な
cloud-event-proxy
コンテナーのメトリクスにアクセスします。$ oc exec -it <linuxptp-daemon> -n openshift-ptp -c cloud-event-proxy -- curl 127.0.0.1:9091/metrics
ここで、
- <linuxptp-daemon>
問い合わせる Pod を指定します(例:
linuxptp-daemon-2t78p
)。出力例
# HELP cne_amqp_events_published Metric to get number of events published by the transport # TYPE cne_amqp_events_published gauge cne_amqp_events_published{address="/cluster/node/compute-1.example.com/ptp/status",status="success"} 1041 # HELP cne_amqp_events_received Metric to get number of events received by the transport # TYPE cne_amqp_events_received gauge cne_amqp_events_received{address="/cluster/node/compute-1.example.com/ptp",status="success"} 1019 # HELP cne_amqp_receiver Metric to get number of receiver created # TYPE cne_amqp_receiver gauge cne_amqp_receiver{address="/cluster/node/mock",status="active"} 1 cne_amqp_receiver{address="/cluster/node/compute-1.example.com/ptp",status="active"} 1 cne_amqp_receiver{address="/cluster/node/compute-1.example.com/redfish/event",status="active"} ...
10.10.7. Web コンソールでの PTP 高速イベントメトリクスの監視
事前に設定された自己更新型の Prometheus モニタリングスタックを使用して、OpenShift Container Platform Web コンソールで PTP 高速イベントメトリクスをモニタリングできます。
前提条件
-
OpenShift Container Platform CLI (
oc
) をインストールします。 -
cluster-admin
権限を持つユーザーとしてログインしている。
手順
以下のコマンドを実行して、
cloud-event-proxy
サイドカーコンテナーから利用可能な PTP メトリクスの一覧を返します。$ oc exec -it <linuxptp_daemon_pod> -n openshift-ptp -c cloud-event-proxy -- curl 127.0.0.1:9091/metrics
ここで、
- <linuxptp_daemon_pod>
-
問い合わせる Pod を指定します(例:
linuxptp-daemon-2t78p
)。
-
返されるメトリクスの一覧から問い合わせる PTP メトリクスの名前(例:
cne_amqp_events_received
)をコピーします。 - OpenShift Container Platform Web コンソールで、Observe → Metrics をクリックします。
- PTP メトリクスを Expression フィールドに貼り付け、Run queries をクリックします。
関連情報
第11章 ネットワークポリシー
11.1. ネットワークポリシーについて
クラスター管理者は、トラフィックをクラスター内の Pod に制限するネットワークポリシーを定義できます。
11.1.1. ネットワークポリシーについて
Kubernetes ネットワークポリシーをサポートする Kubernetes Container Network Interface (CNI) プラグインを使用するクラスターでは、ネットワークの分離は NetworkPolicy
オブジェクトによって完全に制御されます。OpenShift Container Platform 4.9 では、OpenShift SDN はデフォルトのネットワーク分離モードでのネットワークポリシーの使用をサポートしています。
OpenShift SDN クラスターネットワークプロバイダーを使用する場合、ネットワークポリシーについて、以下の制限が適用されます。
-
egress
フィールドで指定される egress ネットワークポリシーはサポートされていません。 -
IPBlock はネットワークポリシーでサポートされますが、
except
句はサポートしません。except
句を含む IPBlock セクションのあるポリシーを作成する場合、SDN Pod は警告をログに記録し、そのポリシーの IPBlock セクション全体は無視されます。
ネットワークポリシーは、ホストのネットワーク namespace には適用されません。ホストネットワークが有効にされている Pod はネットワークポリシールールによる影響を受けません。
デフォルトで、プロジェクトのすべての Pod は他の Pod およびネットワークのエンドポイントからアクセスできます。プロジェクトで 1 つ以上の Pod を分離するには、そのプロジェクトで NetworkPolicy
オブジェクトを作成し、許可する着信接続を指定します。プロジェクト管理者は独自のプロジェクト内で NetworkPolicy
オブジェクトの作成および削除を実行できます。
Pod が 1 つ以上の NetworkPolicy
オブジェクトのセレクターで一致する場合、Pod はそれらの 1 つ以上の NetworkPolicy
オブジェクトで許可される接続のみを受け入れます。NetworkPolicy
オブジェクトによって選択されていない Pod は完全にアクセス可能です。
以下のサンプル NetworkPolicy
オブジェクトは、複数の異なるシナリオをサポートすることを示しています。
すべてのトラフィックを拒否します。
プロジェクトに「deny by default (デフォルトで拒否)」を実行させるには、すべての Pod に一致するが、トラフィックを一切許可しない
NetworkPolicy
オブジェクトを追加します。kind: NetworkPolicy apiVersion: networking.k8s.io/v1 metadata: name: deny-by-default spec: podSelector: {} ingress: []
OpenShift Container Platform Ingress コントローラーからの接続のみを許可します。
プロジェクトで OpenShift Container Platform Ingress コントローラーからの接続のみを許可するには、以下の
NetworkPolicy
オブジェクトを追加します。apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-from-openshift-ingress spec: ingress: - from: - namespaceSelector: matchLabels: network.openshift.io/policy-group: ingress podSelector: {} policyTypes: - Ingress
プロジェクト内の Pod からの接続のみを受け入れます。
Pod が同じプロジェクト内の他の Pod からの接続を受け入れるが、他のプロジェクトの Pod からの接続を拒否するように設定するには、以下の
NetworkPolicy
オブジェクトを追加します。kind: NetworkPolicy apiVersion: networking.k8s.io/v1 metadata: name: allow-same-namespace spec: podSelector: {} ingress: - from: - podSelector: {}
Pod ラベルに基づいて HTTP および HTTPS トラフィックのみを許可します。
特定のラベル (以下の例の
role=frontend
) の付いた Pod への HTTP および HTTPS アクセスのみを有効にするには、以下と同様のNetworkPolicy
オブジェクトを追加します。kind: NetworkPolicy apiVersion: networking.k8s.io/v1 metadata: name: allow-http-and-https spec: podSelector: matchLabels: role: frontend ingress: - ports: - protocol: TCP port: 80 - protocol: TCP port: 443
namespace および Pod セレクターの両方を使用して接続を受け入れます。
namespace と Pod セレクターを組み合わせてネットワークトラフィックのマッチングをするには、以下と同様の
NetworkPolicy
オブジェクトを使用できます。kind: NetworkPolicy apiVersion: networking.k8s.io/v1 metadata: name: allow-pod-and-namespace-both spec: podSelector: matchLabels: name: test-pods ingress: - from: - namespaceSelector: matchLabels: project: project_name podSelector: matchLabels: name: test-pods
NetworkPolicy
オブジェクトは加算されるものです。 つまり、複数の NetworkPolicy
オブジェクトを組み合わせて複雑なネットワーク要件を満すことができます。
たとえば、先の例で定義された NetworkPolicy
オブジェクトの場合、同じプロジェト内に allow-same-namespace
と allow-http-and-https
ポリシーの両方を定義することができます。これにより、ラベル role=frontend
の付いた Pod は各ポリシーで許可されるすべての接続を受け入れます。つまり、同じ namespace の Pod からのすべてのポート、およびすべての namespace の Pod からのポート 80
および 443
での接続を受け入れます。
11.1.2. ネットワークポリシーの最適化
ネットワークポリシーを使用して、namespace 内でラベルで相互に区別される Pod を分離します。
ネットワークポリシールールを効果的に使用するためのガイドラインは、OpenShift SDN クラスターネットワークプロバイダーのみに適用されます。
NetworkPolicy
オブジェクトを単一 namespace 内の多数の個別 Pod に適用することは効率的ではありません。Pod ラベルは IP レベルには存在しないため、ネットワークポリシーは、podSelector
で選択されるすべての Pod 間のすべてのリンクについての別個の Open vSwitch (OVS) フロールールを生成します。
たとえば、仕様の podSelector
および NetworkPolicy
オブジェクト内の ingress podSelector
のそれぞれが 200 Pod に一致する場合、40,000 (200*200) OVS フロールールが生成されます。これにより、ノードの速度が低下する可能性があります。
ネットワークポリシーを設計する場合は、以下のガイドラインを参照してください。
namespace を使用して分離する必要のある Pod のグループを組み込み、OVS フロールールの数を減らします。
namespace 全体を選択する
NetworkPolicy
オブジェクトは、namespaceSelectors
または空のpodSelectors
を使用して、namespace の VXLAN 仮想ネットワーク ID に一致する単一の OVS フロールールのみを生成します。- 分離する必要のない Pod は元の namespace に維持し、分離する必要のある Pod は 1 つ以上の異なる namespace に移します。
- 追加のターゲット設定された namespace 間のネットワークポリシーを作成し、分離された Pod から許可する必要のある特定のトラフィックを可能にします。
11.1.3. 次のステップ
- ネットワークポリシーの作成
- オプション: デフォルトネットワークポリシーの定義
11.1.4. 関連情報
11.2. ネットワークポリシーイベントのロギング
クラスター管理者は、クラスターのネットワークポリシー監査ロギングを設定し、1 つ以上の namespace のロギングを有効にできます。
ネットワークポリシーの監査ロギングは OVN-Kubernetes クラスターネットワークプロバイダー でのみ利用可能です。
11.2.1. ネットワークポリシー監査ロギング
OVN-Kubernetes クラスターネットワークプロバイダーは、Open Virtual Network (OVN) ACL を使用してネットワークポリシーを管理します。監査ロギングは ACL イベントの許可および拒否を公開します。
syslog サーバーや UNIX ドメインソケットなどのネットワークポリシー監査ログの宛先を設定できます。追加の設定に関係なく、監査ログは常にクラスター内の各 OVN-Kubernetes Pod の /var/log/ovn/acl-audit-log.log
に保存されます。
以下の例のように、namespace に k8s.ovn.org/acl-logging
キーでアノテーションを付けることにより、namespace ごとにネットワークポリシー監査ログを有効にします。
namespace アノテーションの例
kind: Namespace apiVersion: v1 metadata: name: example1 annotations: k8s.ovn.org/acl-logging: |- { "deny": "info", "allow": "info" }
ロギング形式は RFC5424 によって定義される syslog と互換性があります。syslog ファシリティーは設定可能です。デフォルトは local0
です。ログエントリーの例は、以下のようになります。
ACL 拒否ログエントリーの例
2021-06-13T19:33:11.590Z|00005|acl_log(ovn_pinctrl0)|INFO|name="verify-audit-logging_deny-all", verdict=drop, severity=alert: icmp,vlan_tci=0x0000,dl_src=0a:58:0a:80:02:39,dl_dst=0a:58:0a:80:02:37,nw_src=10.128.2.57,nw_dst=10.128.2.55,nw_tos=0,nw_ecn=0,nw_ttl=64,icmp_type=8,icmp_code=0
以下の表は、namespace アノテーションの値について説明しています。
表11.1 ネットワークポリシー監査ロギング namespace アノテーション
アノテーション | 値 |
---|---|
|
namespace のネットワークポリシー監査ロギングを有効にするには、
|
11.2.2. ネットワークポリシー監査の設定
監査ロギングの設定は、OVN-Kubernetes クラスターネットワークプロバイダー設定の一部として指定されます。以下の YAML は、ネットワークポリシーの監査ロギング機能のデフォルト値を示しています。
監査ロギング設定
apiVersion: operator.openshift.io/v1 kind: Network metadata: name: cluster spec: defaultNetwork: ovnKubernetesConfig: policyAuditConfig: destination: "null" maxFileSize: 50 rateLimit: 20 syslogFacility: local0
以下の表は、ネットワークポリシー監査ロギングの設定フィールドについて説明しています。
表11.2 policyAuditConfig
object
フィールド | タイプ | 詳細 |
---|---|---|
| integer |
ノードごとに毎秒生成されるメッセージの最大数。デフォルト値は、1 秒あたり |
| integer |
監査ログの最大サイズ (バイト単位)。デフォルト値は |
| string | 以下の追加の監査ログターゲットのいずれかになります。
|
| string |
RFC5424 で定義される |
11.2.3. クラスターのネットワークポリシー監査の設定
クラスター管理者は、クラスターのネットワークポリシー監査ロギングをカスタマイズできます。
前提条件
-
OpenShift CLI (
oc
) をインストールします。 -
cluster-admin
権限を持つユーザーとしてクラスターにログインすること。
手順
ネットワークポリシーの監査ロギングの設定をカスタマイズするには、以下のコマンドを入力します。
$ oc edit network.operator.openshift.io/cluster
ヒントまたは、以下の YAML をカスタマイズして適用することで、監査ロギングを設定できます。
apiVersion: operator.openshift.io/v1 kind: Network metadata: name: cluster spec: defaultNetwork: ovnKubernetesConfig: policyAuditConfig: destination: "null" maxFileSize: 50 rateLimit: 20 syslogFacility: local0
検証
ネットワークポリシーを使用して namespace を作成するには、次の手順を実行します。
検証用の namespace を作成します。
$ cat <<EOF| oc create -f - kind: Namespace apiVersion: v1 metadata: name: verify-audit-logging annotations: k8s.ovn.org/acl-logging: '{ "deny": "alert", "allow": "alert" }' EOF
出力例
namespace/verify-audit-logging created
監査ロギングを有効にします。
$ oc annotate namespace verify-audit-logging k8s.ovn.org/acl-logging='{ "deny": "alert", "allow": "alert" }'
namespace/verify-audit-logging annotated
namespace のネットワークポリシーを作成します。
$ cat <<EOF| oc create -n verify-audit-logging -f - apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: deny-all spec: podSelector: matchLabels: policyTypes: - Ingress - Egress --- apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-from-same-namespace spec: podSelector: {} policyTypes: - Ingress - Egress ingress: - from: - podSelector: {} egress: - to: - namespaceSelector: matchLabels: namespace: verify-audit-logging EOF
出力例
networkpolicy.networking.k8s.io/deny-all created networkpolicy.networking.k8s.io/allow-from-same-namespace created
ソーストラフィックの Pod を
default
namespace に作成します。$ cat <<EOF| oc create -n default -f - apiVersion: v1 kind: Pod metadata: name: client spec: containers: - name: client image: registry.access.redhat.com/rhel7/rhel-tools command: ["/bin/sh", "-c"] args: ["sleep inf"] EOF
verify-audit-logging
namespace に 2 つの Pod を作成します。$ for name in client server; do cat <<EOF| oc create -n verify-audit-logging -f - apiVersion: v1 kind: Pod metadata: name: ${name} spec: containers: - name: ${name} image: registry.access.redhat.com/rhel7/rhel-tools command: ["/bin/sh", "-c"] args: ["sleep inf"] EOF done
出力例
pod/client created pod/server created
トラフィックを生成し、ネットワークポリシー監査ログエントリーを作成するには、以下の手順を実行します。
verify-audit-logging
namespace でserver
という名前の Pod の IP アドレスを取得します。$ POD_IP=$(oc get pods server -n verify-audit-logging -o jsonpath='{.status.podIP}')
default
の namespace のclient
という名前の Pod の直前のコマンドから IP アドレスに ping し、すべてのパケットがドロップされていることを確認します。$ oc exec -it client -n default -- /bin/ping -c 2 $POD_IP
出力例
PING 10.128.2.55 (10.128.2.55) 56(84) bytes of data. --- 10.128.2.55 ping statistics --- 2 packets transmitted, 0 received, 100% packet loss, time 2041ms
verify-audit-logging
namespace のclient
という名前の Pod からPOD_IP
シェル環境変数に保存されている IP アドレスに ping し、すべてのパケットが許可されていることを確認します。$ oc exec -it client -n verify-audit-logging -- /bin/ping -c 2 $POD_IP
出力例
PING 10.128.0.86 (10.128.0.86) 56(84) bytes of data. 64 bytes from 10.128.0.86: icmp_seq=1 ttl=64 time=2.21 ms 64 bytes from 10.128.0.86: icmp_seq=2 ttl=64 time=0.440 ms --- 10.128.0.86 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1001ms rtt min/avg/max/mdev = 0.440/1.329/2.219/0.890 ms
ネットワークポリシー監査ログの最新エントリーを表示します。
$ for pod in $(oc get pods -n openshift-ovn-kubernetes -l app=ovnkube-node --no-headers=true | awk '{ print $1 }') ; do oc exec -it $pod -n openshift-ovn-kubernetes -- tail -4 /var/log/ovn/acl-audit-log.log done
出力例
Defaulting container name to ovn-controller. Use 'oc describe pod/ovnkube-node-hdb8v -n openshift-ovn-kubernetes' to see all of the containers in this pod. 2021-06-13T19:33:11.590Z|00005|acl_log(ovn_pinctrl0)|INFO|name="verify-audit-logging_deny-all", verdict=drop, severity=alert: icmp,vlan_tci=0x0000,dl_src=0a:58:0a:80:02:39,dl_dst=0a:58:0a:80:02:37,nw_src=10.128.2.57,nw_dst=10.128.2.55,nw_tos=0,nw_ecn=0,nw_ttl=64,icmp_type=8,icmp_code=0 2021-06-13T19:33:12.614Z|00006|acl_log(ovn_pinctrl0)|INFO|name="verify-audit-logging_deny-all", verdict=drop, severity=alert: icmp,vlan_tci=0x0000,dl_src=0a:58:0a:80:02:39,dl_dst=0a:58:0a:80:02:37,nw_src=10.128.2.57,nw_dst=10.128.2.55,nw_tos=0,nw_ecn=0,nw_ttl=64,icmp_type=8,icmp_code=0 2021-06-13T19:44:10.037Z|00007|acl_log(ovn_pinctrl0)|INFO|name="verify-audit-logging_allow-from-same-namespace_0", verdict=allow, severity=alert: icmp,vlan_tci=0x0000,dl_src=0a:58:0a:80:02:3b,dl_dst=0a:58:0a:80:02:3a,nw_src=10.128.2.59,nw_dst=10.128.2.58,nw_tos=0,nw_ecn=0,nw_ttl=64,icmp_type=8,icmp_code=0 2021-06-13T19:44:11.037Z|00008|acl_log(ovn_pinctrl0)|INFO|name="verify-audit-logging_allow-from-same-namespace_0", verdict=allow, severity=alert: icmp,vlan_tci=0x0000,dl_src=0a:58:0a:80:02:3b,dl_dst=0a:58:0a:80:02:3a,nw_src=10.128.2.59,nw_dst=10.128.2.58,nw_tos=0,nw_ecn=0,nw_ttl=64,icmp_type=8,icmp_code=0
11.2.4. namespace のネットワークポリシー監査ロギングの有効化
クラスター管理者は、namespace のネットワークポリシーの監査ロギングを有効化できます。
前提条件
-
OpenShift CLI (
oc
) をインストールします。 -
cluster-admin
権限を持つユーザーとしてクラスターにログインすること。
手順
オプション: namespace のネットワークポリシー監査ロギングを有効にするには、以下のコマンドを入力します。
$ oc annotate namespace <namespace> \ k8s.ovn.org/acl-logging='{ "deny": "alert", "allow": "notice" }'
ここで、
<namespace>
- namespace の名前を指定します。
ヒントまたは、以下の YAML を適用して監査ロギングを有効化できます。
kind: Namespace apiVersion: v1 metadata: name: <namespace> annotations: k8s.ovn.org/acl-logging: |- { "deny": "alert", "allow": "notice" }
出力例
namespace/verify-audit-logging annotated
検証
ネットワークポリシー監査ログの最新エントリーを表示します。
$ for pod in $(oc get pods -n openshift-ovn-kubernetes -l app=ovnkube-node --no-headers=true | awk '{ print $1 }') ; do oc exec -it $pod -n openshift-ovn-kubernetes -- tail -4 /var/log/ovn/acl-audit-log.log done
出力例
2021-06-13T19:33:11.590Z|00005|acl_log(ovn_pinctrl0)|INFO|name="verify-audit-logging_deny-all", verdict=drop, severity=alert: icmp,vlan_tci=0x0000,dl_src=0a:58:0a:80:02:39,dl_dst=0a:58:0a:80:02:37,nw_src=10.128.2.57,nw_dst=10.128.2.55,nw_tos=0,nw_ecn=0,nw_ttl=64,icmp_type=8,icmp_code=0
11.2.5. namespace のネットワークポリシー監査ロギングの無効化
クラスター管理者は、namespace のネットワークポリシー監査ロギングを無効化できます。
前提条件
-
OpenShift CLI (
oc
) をインストールします。 -
cluster-admin
権限を持つユーザーとしてクラスターにログインすること。
手順
namespace のネットワークポリシー監査ロギングを無効にするには、以下のコマンドを入力します。
$ annotate --overwrite namespace <namespace> k8s.ovn.org/acl-logging={}
ここで、
<namespace>
- namespace の名前を指定します。
ヒントまたは、以下の YAML を適用して監査ロギングを無効化できます。
kind: Namespace apiVersion: v1 metadata: name: <namespace> annotations: k8s.ovn.org/acl-logging: null
出力例
namespace/verify-audit-logging annotated
11.2.6. 関連情報
11.3. ネットワークポリシーの作成
admin
ロールを持つユーザーは、namespace のネットワークポリシーを作成できます。
11.3.1. ネットワークポリシーの作成
クラスターの namespace に許可される Ingress または egress ネットワークトラフィックを記述する詳細なルールを定義するには、ネットワークポリシーを作成できます。
cluster-admin
ロールを持つユーザーでログインしている場合、クラスター内の namespace でネットワークポリシーを作成できます。
前提条件
-
クラスターは、
NetworkPolicy
オブジェクトをサポートするクラスターネットワークプロバイダーを使用する (例: OVN-Kubernetes ネットワークプロバイダー、またはmode: NetworkPolicy
が設定された OpenShift SDN ネットワークプロバイダー)。このモードは OpenShiftSDN のデフォルトです。 -
OpenShift CLI (
oc
) がインストールされている。 -
admin
権限を持つユーザーとしてクラスターにログインしている。 - ネットワークポリシーが適用される namespace で作業している。
手順
ポリシールールを作成します。
<policy_name>.yaml
ファイルを作成します。$ touch <policy_name>.yaml
ここでは、以下のようになります。
<policy_name>
- ネットワークポリシーファイル名を指定します。
作成したばかりのファイルで、以下の例のようなネットワークポリシーを定義します。
すべての namespace のすべての Pod から ingress を拒否します。
kind: NetworkPolicy apiVersion: networking.k8s.io/v1 metadata: name: deny-by-default spec: podSelector: ingress: []
同じ namespace のすべての Pod から ingress を許可します。
kind: NetworkPolicy apiVersion: networking.k8s.io/v1 metadata: name: allow-same-namespace spec: podSelector: ingress: - from: - podSelector: {}
ネットワークポリシーオブジェクトを作成するには、以下のコマンドを入力します。
$ oc apply -f <policy_name>.yaml -n <namespace>
ここでは、以下のようになります。
<policy_name>
- ネットワークポリシーファイル名を指定します。
<namespace>
- オプション: オブジェクトが現在の namespace 以外の namespace に定義されている場合は namespace を指定します。
出力例
networkpolicy.networking.k8s.io/default-deny created
コンソールで cluster-admin
ロールが割り当てられたユーザーでログインした場合に、YAML ビューから直接、または Web コンソールのフォームから、クラスター内の任意の namespace にネットワークポリシーを作成できます。
11.3.2. サンプル NetworkPolicy オブジェクト
以下は、サンプル NetworkPolicy オブジェクトにアノテーションを付けます。
kind: NetworkPolicy apiVersion: networking.k8s.io/v1 metadata: name: allow-27107 1 spec: podSelector: 2 matchLabels: app: mongodb ingress: - from: - podSelector: 3 matchLabels: app: app ports: 4 - protocol: TCP port: 27017
11.3.3. 関連情報
11.4. ネットワークポリシーの表示
admin
ロールを持つユーザーは、namespace のネットワークポリシーを表示できます。
11.4.1. ネットワークポリシーの表示
namespace のネットワークポリシーを検査できます。
cluster-admin
ロールを持つユーザーでログインしている場合、クラスター内のネットワークポリシーを表示できます。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 -
admin
権限を持つユーザーとしてクラスターにログインしている。 - ネットワークポリシーが存在する namespace で作業している。
手順
namespace のネットワークポリシーを一覧表示します。
namespace で定義されたネットワークポリシーオブジェクトを表示するには、以下のコマンドを実行します。
$ oc get networkpolicy
オプション: 特定のネットワークポリシーを検査するには、以下のコマンドを入力します。
$ oc describe networkpolicy <policy_name> -n <namespace>
ここでは、以下のようになります。
<policy_name>
- 検査するネットワークポリシーの名前を指定します。
<namespace>
- オプション: オブジェクトが現在の namespace 以外の namespace に定義されている場合は namespace を指定します。
以下は例になります。
$ oc describe networkpolicy allow-same-namespace
oc describe
コマンドの出力Name: allow-same-namespace Namespace: ns1 Created on: 2021-05-24 22:28:56 -0400 EDT Labels: <none> Annotations: <none> Spec: PodSelector: <none> (Allowing the specific traffic to all pods in this namespace) Allowing ingress traffic: To Port: <any> (traffic allowed to all ports) From: PodSelector: <none> Not affecting egress traffic Policy Types: Ingress
11.4.2. サンプル NetworkPolicy オブジェクト
以下は、サンプル NetworkPolicy オブジェクトにアノテーションを付けます。
kind: NetworkPolicy apiVersion: networking.k8s.io/v1 metadata: name: allow-27107 1 spec: podSelector: 2 matchLabels: app: mongodb ingress: - from: - podSelector: 3 matchLabels: app: app ports: 4 - protocol: TCP port: 27017
11.5. ネットワークポリシーの編集
admin
ロールを持つユーザーは、namespace の既存のネットワークポリシーを編集できます。
11.5.1. ネットワークポリシーの編集
namespace のネットワークポリシーを編集できます。
cluster-admin
ロールを持つユーザーでログインしている場合、クラスター内の namespace でネットワークポリシーを編集できます。
前提条件
-
クラスターは、
NetworkPolicy
オブジェクトをサポートするクラスターネットワークプロバイダーを使用する (例: OVN-Kubernetes ネットワークプロバイダー、またはmode: NetworkPolicy
が設定された OpenShift SDN ネットワークプロバイダー)。このモードは OpenShiftSDN のデフォルトです。 -
OpenShift CLI (
oc
) がインストールされている。 -
admin
権限を持つユーザーとしてクラスターにログインしている。 - ネットワークポリシーが存在する namespace で作業している。
手順
オプション: namespace のネットワークポリシーオブジェクトを一覧表示するには、以下のコマンドを入力します。
$ oc get networkpolicy
ここでは、以下のようになります。
<namespace>
- オプション: オブジェクトが現在の namespace 以外の namespace に定義されている場合は namespace を指定します。
ネットワークポリシーオブジェクトを編集します。
ネットワークポリシーの定義をファイルに保存した場合は、ファイルを編集して必要な変更を加えてから、以下のコマンドを入力します。
$ oc apply -n <namespace> -f <policy_file>.yaml
ここでは、以下のようになります。
<namespace>
- オプション: オブジェクトが現在の namespace 以外の namespace に定義されている場合は namespace を指定します。
<policy_file>
- ネットワークポリシーを含むファイルの名前を指定します。
ネットワークポリシーオブジェクトを直接更新する必要がある場合、以下のコマンドを入力できます。
$ oc edit networkpolicy <policy_name> -n <namespace>
ここでは、以下のようになります。
<policy_name>
- ネットワークポリシーの名前を指定します。
<namespace>
- オプション: オブジェクトが現在の namespace 以外の namespace に定義されている場合は namespace を指定します。
ネットワークポリシーオブジェクトが更新されていることを確認します。
$ oc describe networkpolicy <policy_name> -n <namespace>
ここでは、以下のようになります。
<policy_name>
- ネットワークポリシーの名前を指定します。
<namespace>
- オプション: オブジェクトが現在の namespace 以外の namespace に定義されている場合は namespace を指定します。
11.5.2. サンプル NetworkPolicy オブジェクト
以下は、サンプル NetworkPolicy オブジェクトにアノテーションを付けます。
kind: NetworkPolicy apiVersion: networking.k8s.io/v1 metadata: name: allow-27107 1 spec: podSelector: 2 matchLabels: app: mongodb ingress: - from: - podSelector: 3 matchLabels: app: app ports: 4 - protocol: TCP port: 27017
11.5.3. 関連情報
11.6. ネットワークポリシーの削除
admin
ロールを持つユーザーは、namespace からネットワークポリシーを削除できます。
11.6.1. ネットワークポリシーの削除
namespace のネットワークポリシーを削除できます。
cluster-admin
ロールを持つユーザーでログインしている場合、クラスター内のネットワークポリシーを削除できます。
前提条件
-
クラスターは、
NetworkPolicy
オブジェクトをサポートするクラスターネットワークプロバイダーを使用する (例: OVN-Kubernetes ネットワークプロバイダー、またはmode: NetworkPolicy
が設定された OpenShift SDN ネットワークプロバイダー)。このモードは OpenShiftSDN のデフォルトです。 -
OpenShift CLI (
oc
) がインストールされている。 -
admin
権限を持つユーザーとしてクラスターにログインしている。 - ネットワークポリシーが存在する namespace で作業している。
手順
ネットワークポリシーオブジェクトを削除するには、以下のコマンドを入力します。
$ oc delete networkpolicy <policy_name> -n <namespace>
ここで、
<policy_name>
- ネットワークポリシーの名前を指定します。
<namespace>
- オプション: オブジェクトが現在の namespace 以外の namespace に定義されている場合は namespace を指定します。
出力例
networkpolicy.networking.k8s.io/default-deny deleted
11.7. プロジェクトのデフォルトネットワークポリシーの定義
クラスター管理者は、新規プロジェクトの作成時にネットワークポリシーを自動的に含めるように新規プロジェクトテンプレートを変更できます。新規プロジェクトのカスタマイズされたテンプレートがまだない場合には、まずテンプレートを作成する必要があります。
11.7.1. 新規プロジェクトのテンプレートの変更
クラスター管理者は、デフォルトのプロジェクトテンプレートを変更し、新規プロジェクトをカスタム要件に基づいて作成することができます。
独自のカスタムプロジェクトテンプレートを作成するには、以下を実行します。
手順
-
cluster-admin
権限を持つユーザーとしてログインしている。 デフォルトのプロジェクトテンプレートを生成します。
$ oc adm create-bootstrap-project-template -o yaml > template.yaml
-
オブジェクトを追加するか、または既存オブジェクトを変更することにより、テキストエディターで生成される
template.yaml
ファイルを変更します。 プロジェクトテンプレートは、
openshift-config
namespace に作成される必要があります。変更したテンプレートを読み込みます。$ oc create -f template.yaml -n openshift-config
Web コンソールまたは CLI を使用し、プロジェクト設定リソースを編集します。
Web コンソールの使用
- Administration → Cluster Settings ページに移動します。
- Configuration をクリックし、すべての設定リソースを表示します。
- Project のエントリーを見つけ、Edit YAML をクリックします。
CLI の使用
project.config.openshift.io/cluster
リソースを編集します。$ oc edit project.config.openshift.io/cluster
spec
セクションを、projectRequestTemplate
およびname
パラメーターを組み込むように更新し、アップロードされたプロジェクトテンプレートの名前を設定します。デフォルト名はproject-request
です。カスタムプロジェクトテンプレートを含むプロジェクト設定リソース
apiVersion: config.openshift.io/v1 kind: Project metadata: ... spec: projectRequestTemplate: name: <template_name>
- 変更を保存した後、変更が正常に適用されたことを確認するために、新しいプロジェクトを作成します。
11.7.2. 新規プロジェクトへのネットワークポリシーの追加
クラスター管理者は、ネットワークポリシーを新規プロジェクトのデフォルトテンプレートに追加できます。OpenShift Container Platform は、プロジェクトのテンプレートに指定されたすべての NetworkPolicy
オブジェクトを自動的に作成します。
前提条件
-
クラスターは、
NetworkPolicy
オブジェクトをサポートするデフォルトの CNI ネットワークプロバイダーを使用する(例:mode: NetworkPolicy
が設定された OpenShift SDN ネットワークプロバイダー)。このモードは OpenShiftSDN のデフォルトです。 -
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
権限を持つユーザーとしてクラスターにログインすること。 - 新規プロジェクトのカスタムデフォルトプロジェクトテンプレートを作成していること。
手順
以下のコマンドを実行して、新規プロジェクトのデフォルトテンプレートを編集します。
$ oc edit template <project_template> -n openshift-config
<project_template>
を、クラスターに設定したデフォルトテンプレートの名前に置き換えます。デフォルトのテンプレート名はproject-request
です。テンプレートでは、各
NetworkPolicy
オブジェクトを要素としてobjects
パラメーターに追加します。objects
パラメーターは、1 つ以上のオブジェクトのコレクションを受け入れます。以下の例では、
objects
パラメーターのコレクションにいくつかのNetworkPolicy
オブジェクトが含まれます。objects: - apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-from-same-namespace spec: podSelector: {} ingress: - from: - podSelector: {} - apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-from-openshift-ingress spec: ingress: - from: - namespaceSelector: matchLabels: network.openshift.io/policy-group: ingress podSelector: {} policyTypes: - Ingress ...
オプション: 以下のコマンドを実行して、新規プロジェクトを作成し、ネットワークポリシーオブジェクトが正常に作成されることを確認します。
新規プロジェクトを作成します。
$ oc new-project <project> 1
- 1
<project>
を、作成しているプロジェクトの名前に置き換えます。
新規プロジェクトテンプレートのネットワークポリシーオブジェクトが新規プロジェクトに存在することを確認します。
$ oc get networkpolicy NAME POD-SELECTOR AGE allow-from-openshift-ingress <none> 7s allow-from-same-namespace <none> 7s
11.8. ネットワークポリシーを使用したマルチテナント分離の設定
クラスター管理者は、マルチテナントネットワークの分離を実行するようにネットワークポリシーを設定できます。
OpenShift SDN クラスターネットワークプロバイダーを使用している場合、本セクションで説明されているようにネットワークポリシーを設定すると、マルチテナントモードと同様のネットワーク分離が行われますが、ネットワークポリシーモードが設定されます。
11.8.1. ネットワークポリシーを使用したマルチテナント分離の設定
他のプロジェクト namespace の Pod およびサービスから分離できるようにプロジェクトを設定できます。
前提条件
-
クラスターは、
NetworkPolicy
オブジェクトをサポートするクラスターネットワークプロバイダーを使用する (例: OVN-Kubernetes ネットワークプロバイダー、またはmode: NetworkPolicy
が設定された OpenShift SDN ネットワークプロバイダー)。このモードは OpenShiftSDN のデフォルトです。 -
OpenShift CLI (
oc
) がインストールされている。 -
admin
権限を持つユーザーとしてクラスターにログインしている。
手順
以下の
NetworkPolicy
オブジェクトを作成します。allow-from-openshift-ingress
という名前のポリシー:$ cat << EOF| oc create -f - apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-from-openshift-ingress spec: ingress: - from: - namespaceSelector: matchLabels: policy-group.network.openshift.io/ingress: "" podSelector: {} policyTypes: - Ingress EOF
注記policy-group.network.openshift.io/ingress: ""
は、OpenShift SDN の推奨の namespace セレクターラベルです。network.openshift.io/policy-group: ingress
namespace セレクターラベルを使用できますが、これはレガシーラベルです。allow-from-openshift-monitoring
という名前のポリシー。$ cat << EOF| oc create -f - apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-from-openshift-monitoring spec: ingress: - from: - namespaceSelector: matchLabels: network.openshift.io/policy-group: monitoring podSelector: {} policyTypes: - Ingress EOF
allow-same-namespace
という名前のポリシー:$ cat << EOF| oc create -f - kind: NetworkPolicy apiVersion: networking.k8s.io/v1 metadata: name: allow-same-namespace spec: podSelector: ingress: - from: - podSelector: {} EOF
オプション: 以下のコマンドを実行し、ネットワークポリシーオブジェクトが現在のプロジェクトに存在することを確認します。
$ oc describe networkpolicy
出力例
Name: allow-from-openshift-ingress Namespace: example1 Created on: 2020-06-09 00:28:17 -0400 EDT Labels: <none> Annotations: <none> Spec: PodSelector: <none> (Allowing the specific traffic to all pods in this namespace) Allowing ingress traffic: To Port: <any> (traffic allowed to all ports) From: NamespaceSelector: network.openshift.io/policy-group: ingress Not affecting egress traffic Policy Types: Ingress Name: allow-from-openshift-monitoring Namespace: example1 Created on: 2020-06-09 00:29:57 -0400 EDT Labels: <none> Annotations: <none> Spec: PodSelector: <none> (Allowing the specific traffic to all pods in this namespace) Allowing ingress traffic: To Port: <any> (traffic allowed to all ports) From: NamespaceSelector: network.openshift.io/policy-group: monitoring Not affecting egress traffic Policy Types: Ingress
11.8.2. 次のステップ
11.8.3. 関連情報
第12章 複数ネットワーク
12.1. 複数ネットワークについて
Kubernetes では、コンテナーネットワークは Container Network Interface (CNI) を実装するネットワークプラグインに委任されます。
OpenShift Container Platform は、Multus CNI プラグインを使用して CNI プラグインのチェーンを許可します。クラスターのインストール時に、デフォルト の Pod ネットワークを設定します。デフォルトのネットワークは、クラスターのすべての通常のネットワークトラフィックを処理します。利用可能な CNI プラグインに基づいて 追加のネットワーク を定義し、1 つまたは複数のネットワークを Pod に割り当てることができます。必要に応じて、クラスターの複数のネットワークを追加で定義することができます。これは、スイッチまたはルーティングなどのネットワーク機能を提供する Pod を設定する場合に柔軟性を実現します。
12.1.1. 追加ネットワークの使用シナリオ
データプレーンとコントロールプレーンの分離など、ネットワークの分離が必要な状況で追加のネットワークを使用することができます。トラフィックの分離は、以下のようなパフォーマンスおよびセキュリティー関連の理由で必要になります。
- パフォーマンス
- 各プレーンのトラフィック量を管理するために、2 つの異なるプレーンにトラフィックを送信できます。
- セキュリティー
- 機密トラフィックは、セキュリティー上の考慮に基づいて管理されているネットワークに送信でき、テナントまたはカスタマー間で共有できないプライベートを分離することができます。
クラスターのすべての Pod はクラスター全体のデフォルトネットワークを依然として使用し、クラスター全体での接続性を維持します。すべての Pod には、クラスター全体の Pod ネットワークに割り当てられる eth0
インターフェースがあります。Pod のインターフェースは、oc exec -it <pod_name> -- ip a
コマンドを使用して表示できます。Multus CNI を使用するネットワークを追加する場合、それらの名前は net1
、net2
、…、 netN
になります。
追加のネットワークを Pod に割り当てるには、インターフェースの割り当て方法を定義する設定を作成する必要があります。それぞれのインターフェースは、NetworkAttachmentDefinition
カスタムリソース (CR) を使用して指定します。これらの CR のそれぞれにある CNI 設定は、インターフェースの作成方法を定義します。
12.1.2. OpenShift Container Platform の追加ネットワーク
OpenShift Container Platform は、クラスターに追加のネットワークを作成するために使用する以下の CNI プラグインを提供します。
- bridge: ブリッジベースの追加ネットワークを設定することで、同じホストにある Pod が相互に、かつホストと通信できます。
- host-device: ホストデバイスの追加ネットワークを設定することで、Pod がホストシステム上の物理イーサネットネットワークデバイスにアクセスすることができます。
- ipvlan: ipvlan ベースの追加ネットワークを設定することで、macvlan ベースの追加ネットワークと同様に、ホスト上の Pod が他のホストやそれらのホストの Pod と通信できます。macvlan ベースの追加のネットワークとは異なり、各 Pod は親の物理ネットワークインターフェースと同じ MAC アドレスを共有します。
- macvlan: macvlan ベースの追加ネットワークを作成することで、ホスト上の Pod が物理ネットワークインターフェースを使用して他のホストやそれらのホストの Pod と通信できます。macvlan ベースの追加ネットワークに割り当てられる各 Pod には固有の MAC アドレスが割り当てられます。
- SR-IOV: SR-IOV ベースの追加ネットワークを設定する ことで、Pod を ホストシステム上の SR-IOV 対応ハードウェアの Virtual Function (VF) インターフェースに割り当てることができます。
12.2. 追加のネットワークの設定
クラスター管理者は、クラスターの追加のネットワークを設定できます。以下のネットワークタイプに対応しています。
12.2.1. 追加のネットワークを管理するためのアプローチ
追加したネットワークのライフサイクルを管理するには、2 つのアプローチがあります。各アプローチは同時に使用できず、追加のネットワークを管理する場合に 1 つのアプローチしか使用できません。いずれの方法でも、追加のネットワークは、お客様が設定した Container Network Interface (CNI)プラグインで管理します。
追加ネットワークの場合には、IP アドレスは、追加ネットワークの一部として設定する IPAM(IP Address Management)CNI プラグインでプロビジョニングされます。IPAM プラグインは、DHCP や静的割り当てなど、さまざまな IP アドレス割り当ての方法をサポートしています。
-
Cluster Network Operator (CNO) の設定を変更する: CNO は自動的に
Network Attachment Definition
オブジェクトを作成し、管理します。CNO は、オブジェクトのライフサイクル管理に加えて、DHCP で割り当てられた IP アドレスを使用する追加のネットワークで確実に DHCP が利用できるようにします。 -
YAML マニフェストを適用する:
Network Attachment Definition
オブジェクトを作成することで、追加のネットワークを直接管理できます。この方法では、CNI プラグインを連鎖させることができます。
12.2.2. ネットワーク追加割り当ての設定
追加のネットワークは、k8s.cni.cncf.io
API グループのNetwork Attachment Definition
API で設定されます。
Network Attachment Definition
オブジェクトには、プロジェクト管理ユーザーがアクセスできるので、機密情報やシークレットを保存しないでください。
API の設定については、以下の表で説明されています。
表12.1 NetworkAttachmentDefinition
API フィールド
フィールド | タイプ | 詳細 |
---|---|---|
|
| 追加のネットワークの名前です。 |
|
| オブジェクトが関連付けられる namespace。 |
|
| JSON 形式の CNI プラグイン設定です。 |
12.2.2.1. Cluster Network Operator による追加ネットワークの設定
追加のネットワーク割り当ての設定は、Cluster Network Operator (CNO) の設定の一部として指定します。
以下の YAML は、CNO で追加のネットワークを管理するための設定パラメーターを記述しています。
Cluster Network Operator (CNO) の設定
apiVersion: operator.openshift.io/v1 kind: Network metadata: name: cluster spec: # ... additionalNetworks: 1 - name: <name> 2 namespace: <namespace> 3 rawCNIConfig: |- 4 { ... } type: Raw
12.2.2.2. YAML マニフェストからの追加ネットワークの設定
追加ネットワークの設定は、以下の例のように YAML 設定ファイルから指定します。
apiVersion: k8s.cni.cncf.io/v1 kind: NetworkAttachmentDefinition metadata: name: <name> 1 spec: config: |- 2 { ... }
12.2.3. 追加のネットワークタイプの設定
次のセクションでは、追加のネットワークの具体的な設定フィールドについて説明します。
12.2.3.1. ブリッジネットワークの追加設定
以下のオブジェクトは、ブリッジ CNI プラグインの設定パラメーターについて説明しています。
表12.2 ブリッジ CNI プラグイン JSON 設定オブジェクト
フィールド | タイプ | 詳細 |
---|---|---|
|
|
CNI 仕様のバージョン。値 |
|
|
CNO 設定に以前に指定した |
|
| |
|
|
使用する仮想ブリッジの名前を指定します。ブリッジインターフェースがホストに存在しない場合は、これが作成されます。デフォルト値は |
|
| IPAM CNI プラグインの設定オブジェクト。プラグインは、割り当て定義についての IP アドレスの割り当てを管理します。 |
|
|
仮想ネットワークから外すトラフィックについて IP マスカレードを有効にするには、 |
|
|
IP アドレスをブリッジに割り当てるには |
|
|
ブリッジを仮想ネットワークのデフォルトゲートウェイとして設定するには、 |
|
|
仮想ブリッジの事前に割り当てられた IP アドレスの割り当てを許可するには、 |
|
|
仮想ブリッジが受信時に使用した仮想ポートでイーサネットフレームを送信できるようにするには、 |
|
|
ブリッジで無作為検出モード (Promiscuous Mode) を有効にするには、 |
|
| 仮想 LAN (VLAN) タグを整数値として指定します。デフォルトで、VLAN タグは割り当てません。 |
|
| 最大転送単位 (MTU) を指定された値に設定します。デフォルト値はカーネルによって自動的に設定されます。 |
12.2.3.1.1. ブリッジ設定の例
以下の例では、bridge-net
という名前の追加のネットワークを設定します。
{ "cniVersion": "0.3.1", "name": "work-network", "type": "bridge", "isGateway": true, "vlan": 2, "ipam": { "type": "dhcp" } }
12.2.3.2. ホストデバイスの追加ネットワークの設定
device
、hwaddr
、 kernelpath
、または pciBusID
のいずれかのパラメーターを設定してネットワークデバイスを指定します。
以下のオブジェクトは、ホストデバイス CNI プラグインの設定パラメーターについて説明しています。
表12.3 ホストデバイス CNI プラグイン JSON 設定オブジェクト
フィールド | タイプ | 詳細 |
---|---|---|
|
|
CNI 仕様のバージョン。値 |
|
|
CNO 設定に以前に指定した |
|
|
設定する CNI プラグインの名前: |
|
|
オプション: |
|
| オプション: デバイスハードウェアの MAC アドレス。 |
|
|
オプション: |
|
|
オプション: |
12.2.3.2.1. ホストデバイス設定例
以下の例では、hostdev-net
という名前の追加のネットワークを設定します。
{ "cniVersion": "0.3.1", "name": "work-network", "type": "host-device", "device": "eth1" }
12.2.3.3. IPVLAN 追加ネットワークの設定
以下のオブジェクトは、IPVLAN CNI プラグインの設定パラメーターについて説明しています。
表12.4 IPVLAN CNI プラグイン JSON 設定オブジェクト
フィールド | タイプ | 詳細 |
---|---|---|
|
|
CNI 仕様のバージョン。値 |
|
|
CNO 設定に以前に指定した |
|
|
設定する CNI プラグインの名前: |
|
|
仮想ネットワークの操作モード。この値は、 |
|
|
ネットワーク割り当てに関連付けるイーサネットインターフェース。 |
|
| 最大転送単位 (MTU) を指定された値に設定します。デフォルト値はカーネルによって自動的に設定されます。 |
|
| IPAM CNI プラグインの設定オブジェクト。プラグインは、割り当て定義についての IP アドレスの割り当てを管理します。
|
12.2.3.3.1. IPVLAN 設定例
以下の例では、ipvlan-net
という名前の追加のネットワークを設定します。
{ "cniVersion": "0.3.1", "name": "work-network", "type": "ipvlan", "master": "eth1", "mode": "l3", "ipam": { "type": "static", "addresses": [ { "address": "192.168.10.10" } ] } }
12.2.3.4. MACVLAN 追加ネットワークの設定
以下のオブジェクトは、macvlan CNI プラグインの設定パラメーターについて説明しています。
表12.5 MACVLAN CNI プラグイン JSON 設定オブジェクト
フィールド | タイプ | 詳細 |
---|---|---|
|
|
CNI 仕様のバージョン。値 |
|
|
CNO 設定に以前に指定した |
|
|
設定する CNI プラグインの名前: |
|
|
仮想ネットワークのトラフィックの可視性を設定します。 |
|
| 仮想インターフェースに関連付けるイーサネット、ボンディング、または VLAN インターフェース。値が指定されない場合、ホストシステムのプライマリーイーサネットインターフェースが使用されます。 |
|
| 最大転送単位 (MTU) を指定された値。デフォルト値はカーネルによって自動的に設定されます。 |
|
| IPAM CNI プラグインの設定オブジェクト。プラグインは、割り当て定義についての IP アドレスの割り当てを管理します。 |
12.2.3.4.1. macvlan 設定の例
以下の例では、macvlan-net
という名前の追加のネットワークを設定します。
{ "cniVersion": "0.3.1", "name": "macvlan-net", "type": "macvlan", "master": "eth1", "mode": "bridge", "ipam": { "type": "dhcp" } }
12.2.4. 追加ネットワークの IP アドレス割り当ての設定
IPAM (IP アドレス管理) Container Network Interface (CNI) プラグインは、他の CNI プラグインの IP アドレスを提供します。
以下の IP アドレスの割り当てタイプを使用できます。
- 静的割り当て。
- DHCP サーバーを使用した動的割り当て。指定する DHCP サーバーは、追加のネットワークから到達可能である必要があります。
- Whereabouts IPAM CNI プラグインを使用した動的割り当て。
12.2.4.1. 静的 IP アドレス割り当ての設定
以下の表は、静的 IP アドレスの割り当ての設定について説明しています。
表12.6 ipam
静的設定オブジェクト
フィールド | タイプ | 詳細 |
---|---|---|
|
|
IPAM のアドレスタイプ。値 |
|
| 仮想インターフェースに割り当てる IP アドレスを指定するオブジェクトの配列。IPv4 と IPv6 の IP アドレスの両方がサポートされます。 |
|
| Pod 内で設定するルートを指定するオブジェクトの配列です。 |
|
| オプション: DNS の構成を指定するオブジェクトの配列です。 |
addresses
の配列には、以下のフィールドのあるオブジェクトが必要です。
表12.7 ipam.addresses[]
配列
フィールド | タイプ | 詳細 |
---|---|---|
|
|
指定する IP アドレスおよびネットワークプレフィックス。たとえば、 |
|
| egress ネットワークトラフィックをルーティングするデフォルトのゲートウェイ。 |
表12.8 ipam.routes[]
配列
フィールド | タイプ | 詳細 |
---|---|---|
|
|
CIDR 形式の IP アドレス範囲 ( |
|
| ネットワークトラフィックがルーティングされるゲートウェイ。 |
表12.9 ipam.dns
オブジェクト
フィールド | タイプ | 詳細 |
---|---|---|
|
| DNS クエリーの送信先となる 1 つ以上の IP アドレスの配列。 |
|
|
ホスト名に追加するデフォルトのドメイン。たとえば、ドメインが |
|
|
DNS ルックアップのクエリー時に非修飾ホスト名に追加されるドメイン名の配列 (例: |
静的 IP アドレス割り当ての設定例
{ "ipam": { "type": "static", "addresses": [ { "address": "191.168.1.7" } ] } }
12.2.4.2. 動的 IP アドレス (DHCP) 割り当ての設定
以下の JSON は、DHCP を使用した動的 IP アドレスの割り当ての設定について説明しています。
Pod は、作成時に元の DHCP リースを取得します。リースは、クラスターで実行している最小限の DHCP サーバーデプロイメントで定期的に更新する必要があります。
DHCP サーバーのデプロイメントをトリガーするには、以下の例にあるように Cluster Network Operator 設定を編集して shim ネットワーク割り当てを作成する必要があります。
shim ネットワーク割り当ての定義例
apiVersion: operator.openshift.io/v1 kind: Network metadata: name: cluster spec: additionalNetworks: - name: dhcp-shim namespace: default type: Raw rawCNIConfig: |- { "name": "dhcp-shim", "cniVersion": "0.3.1", "type": "bridge", "ipam": { "type": "dhcp" } } # ...
表12.10 ipam
DHCP 設定オブジェクト
フィールド | タイプ | 詳細 |
---|---|---|
|
|
IPAM のアドレスタイプ。値 |
動的 IP アドレス (DHCP) 割り当ての設定例
{ "ipam": { "type": "dhcp" } }
12.2.4.3. Whereabouts を使用した動的 IP アドレス割り当ての設定
Whereabouts CNI プラグインにより、DHCP サーバーを使用せずに IP アドレスを追加のネットワークに動的に割り当てることができます。
以下の表は、Whereabouts を使用した動的 IP アドレス割り当ての設定について説明しています。
表12.11 ipam
whereabouts 設定オブジェクト
フィールド | タイプ | 詳細 |
---|---|---|
|
|
IPAM のアドレスタイプ。値 |
|
| IP アドレスと範囲を CIDR 表記。IP アドレスは、この範囲内のアドレスから割り当てられます。 |
|
| オプション: CIDR 表記の IP アドレスと範囲 (0 個以上) の一覧。除外されたアドレス範囲内の IP アドレスは割り当てられません。 |
Whereabouts を使用する動的 IP アドレス割り当ての設定例
{ "ipam": { "type": "whereabouts", "range": "192.0.2.192/27", "exclude": [ "192.0.2.192/30", "192.0.2.196/32" ] } }
12.2.5. Cluster Network Operator による追加ネットワーク割り当ての作成
Cluster Network Operator (CNO) は追加ネットワークの定義を管理します。作成する追加ネットワークを指定する場合、CNO は NetworkAttachmentDefinition
オブジェクトを自動的に作成します。
Cluster Network Operator が管理する NetworkAttachmentDefinition
オブジェクトは編集しないでください。これを実行すると、追加ネットワークのネットワークトラフィックが中断する可能性があります。
前提条件
-
OpenShift CLI (
oc
) をインストールします。 -
cluster-admin
権限を持つユーザーとしてログインしている。
手順
CNO 設定を編集するには、以下のコマンドを入力します。
$ oc edit networks.operator.openshift.io cluster
以下のサンプル CR のように、作成される追加ネットワークの設定を追加して、作成している CR を変更します。
apiVersion: operator.openshift.io/v1 kind: Network metadata: name: cluster spec: # ... additionalNetworks: - name: tertiary-net namespace: project2 type: Raw rawCNIConfig: |- { "cniVersion": "0.3.1", "name": "tertiary-net", "type": "ipvlan", "master": "eth1", "mode": "l2", "ipam": { "type": "static", "addresses": [ { "address": "192.168.1.23/24" } ] } }
- 変更を保存し、テキストエディターを終了して、変更をコミットします。
検証
以下のコマンドを実行して、CNO が NetworkAttachmentDefinition オブジェクトを作成していることを確認します。CNO がオブジェクトを作成するまでに遅延が生じる可能性があります。
$ oc get network-attachment-definitions -n <namespace>
ここで、
<namespace>
- CNO の構成に追加したネットワーク割り当ての namespace を指定します。
出力例
NAME AGE test-network-1 14m
12.2.6. YAML マニフェストを適用した追加のネットワーク割り当ての作成
前提条件
-
OpenShift CLI (
oc
) をインストールします。 -
cluster-admin
権限を持つユーザーとしてログインしている。
手順
以下の例のように、追加のネットワーク設定を含む YAML ファイルを作成します。
apiVersion: k8s.cni.cncf.io/v1 kind: NetworkAttachmentDefinition metadata: name: next-net spec: config: |- { "cniVersion": "0.3.1", "name": "work-network", "type": "host-device", "device": "eth1", "ipam": { "type": "dhcp" } }
追加のネットワークを作成するには、次のコマンドを入力します。
$ oc apply -f <file>.yaml
ここで、
<file>
- YAML マニフェストを含むファイルの名前を指定します。
12.3. 仮想ルーティングおよび転送について
12.3.1. 仮想ルーティングおよび転送について
VRF (Virtual Routing and Forwarding) デバイスは IP ルールとの組み合わせにより、仮想ルーティングと転送ドメインを作成する機能を提供します。VRF は、CNF で必要なパーミッションの数を減らし、セカンダリーネットワークのネットワークトポロジーの可視性を強化します。VRF はマルチテナンシー機能を提供するために使用されます。たとえば、この場合、各テナントには固有のルーティングテーブルがあり、異なるデフォルトゲートウェイが必要です。
プロセスは、ソケットを VRF デバイスにバインドできます。バインドされたソケット経由のパケットは、VRF デバイスに関連付けられたルーティングテーブルを使用します。VRF の重要な機能として、これは OSI モデルレイヤー 3 以上にのみ影響を与えるため、LLDP などの L2 ツールは影響を受けません。これにより、ポリシーベースのルーティングなどの優先度の高い IP ルールが、特定のトラフィックを転送する VRF デバイスルールよりも優先されます。
12.3.1.1. Telecommunications Operator についての Pod のセカンダリーネットワークの利点
通信のユースケースでは、各 CNF が同じアドレス空間を共有する複数の異なるネットワークに接続される可能性があります。これらのセカンダリーネットワークは、クラスターのメインネットワーク CIDR と競合する可能性があります。CNI VRF プラグインを使用すると、ネットワーク機能は、同じ IP アドレスを使用して異なるユーザーのインフラストラクチャーに接続でき、複数の異なるお客様の分離された状態を維持します。IP アドレスは OpenShift Container Platform の IP スペースと重複します。CNI VRF プラグインは、CNF で必要なパーミッションの数も減らし、セカンダリーネットワークのネットワークトポロジーの可視性を高めます。
12.4. マルチネットワークポリシーの設定
クラスター管理者は、追加のネットワークのネットワークポリシーを設定できます。
macvlan の追加ネットワークのみに対して、マルチネットワークポリシーを指定することができます。ipvlan などの他の追加のネットワークタイプはサポートされていません。
12.4.1. マルチネットワークポリシーとネットワークポリシーの違い
MultiNetworkPolicy
API は、NetworkPolicy
API を実装していますが、いくつかの重要な違いがあります。
以下の場合は、
MultiNetworkPolicy
API を使用する必要があります。apiVersion: k8s.cni.cncf.io/v1beta1 kind: MultiNetworkPolicy
-
CLI を使用してマルチネットワークポリシーと対話する場合は、
multi-networkpolicy
リソース名を使用する必要があります。たとえば、oc get multi-networkpolicy <name>
コマンドを使用してマルチネットワークポリシーオブジェクトを表示できます。ここで、<name>
はマルチネットワークポリシーの名前になります。 macvlan 追加ネットワークを定義するネットワーク接続定義の名前でアノテーションを指定する必要があります。
apiVersion: k8s.cni.cncf.io/v1beta1 kind: MultiNetworkPolicy metadata: annotations: k8s.v1.cni.cncf.io/policy-for: <network_name>
ここで、
<network_name>
- ネットワーク接続定義の名前を指定します。
12.4.2. クラスターのマルチネットワークポリシーの有効化
クラスター管理者は、クラスターでマルチネットワークポリシーのサポートを有効にすることができます。
前提条件
-
OpenShift CLI (
oc
) をインストールします。 -
cluster-admin
権限を持つユーザーとしてクラスターにログインすること。
手順
以下の YAML で
multinetwork-enable-patch.yaml
ファイルを作成します。apiVersion: operator.openshift.io/v1 kind: Network metadata: name: cluster spec: useMultiNetworkPolicy: true
マルチネットワークポリシーを有効にするようにクラスターを設定します。
$ oc patch network.operator.openshift.io cluster --type=merge --patch-file=multinetwork-enable-patch.yaml
出力例
network.operator.openshift.io/cluster patched
12.4.3. マルチネットワークポリシーの使用
クラスター管理者は、マルチネットワークポリシーを作成、編集、表示、および削除することができます。
12.4.3.1. 前提条件
- クラスターのマルチネットワークポリシーサポートを有効にしている。
12.4.3.2. マルチネットワークポリシーの作成
マルチネットワークポリシーを作成し、クラスターの namespace に許可される Ingress または egress ネットワークトラフィックを記述する詳細なルールを定義することができます。
前提条件
-
クラスターは、
NetworkPolicy
オブジェクトをサポートするクラスターネットワークプロバイダーを使用する (例: OVN-Kubernetes ネットワークプロバイダー、またはmode: NetworkPolicy
が設定された OpenShift SDN ネットワークプロバイダー)。このモードは OpenShiftSDN のデフォルトです。 -
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
権限を持つユーザーとしてクラスターにログインしていること。 - マルチネットワークポリシーが適用される namespace で作業していること。
手順
ポリシールールを作成します。
<policy_name>.yaml
ファイルを作成します。$ touch <policy_name>.yaml
ここでは、以下のようになります。
<policy_name>
- マルチネットワークポリシーのファイル名を指定します。
作成したばかりのファイルで、以下の例のようなマルチネットワークポリシーを定義します。
すべての namespace のすべての Pod から ingress を拒否します。
apiVersion: k8s.cni.cncf.io/v1beta1 kind: MultiNetworkPolicy metadata: name: deny-by-default annotations: k8s.v1.cni.cncf.io/policy-for: <network_name> spec: podSelector: ingress: []
ここでは、以下のようになります。
<network_name>
- ネットワーク接続定義の名前を指定します。
同じ namespace のすべての Pod から ingress を許可します。
apiVersion: k8s.cni.cncf.io/v1beta1 kind: MultiNetworkPolicy metadata: name: allow-same-namespace annotations: k8s.v1.cni.cncf.io/policy-for: <network_name> spec: podSelector: ingress: - from: - podSelector: {}
ここでは、以下のようになります。
<network_name>
- ネットワーク接続定義の名前を指定します。
マルチネットワークポリシーオブジェクトを作成するには、以下のコマンドを入力します。
$ oc apply -f <policy_name>.yaml -n <namespace>
ここで、
<policy_name>
- マルチネットワークポリシーのファイル名を指定します。
<namespace>
- オプション: オブジェクトが現在の namespace 以外の namespace に定義されている場合は namespace を指定します。
出力例
multinetworkpolicy.k8s.cni.cncf.io/default-deny created
コンソールで cluster-admin
ロールが割り当てられたユーザーでログインした場合に、YAML ビューから直接、または Web コンソールのフォームから、クラスター内の任意の namespace にネットワークポリシーを作成できます。
12.4.3.3. マルチネットワークポリシーの編集
namespace のマルチネットワークポリシーを編集できます。
前提条件
-
クラスターは、
NetworkPolicy
オブジェクトをサポートするクラスターネットワークプロバイダーを使用する (例: OVN-Kubernetes ネットワークプロバイダー、またはmode: NetworkPolicy
が設定された OpenShift SDN ネットワークプロバイダー)。このモードは OpenShiftSDN のデフォルトです。 -
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
権限を持つユーザーとしてクラスターにログインしていること。 - マルチネットワークポリシーが存在する namespace で作業している。
手順
オプション: namespace のマルチネットワークポリシーオブジェクトを一覧表示するには、以下のコマンドを入力します。
$ oc get multi-networkpolicy
ここで、
<namespace>
- オプション: オブジェクトが現在の namespace 以外の namespace に定義されている場合は namespace を指定します。
マルチネットワークポリシーオブジェクトを編集します。
マルチネットワークポリシーの定義をファイルに保存した場合は、ファイルを編集して必要な変更を加えてから、以下のコマンドを入力します。
$ oc apply -n <namespace> -f <policy_file>.yaml
ここで、
<namespace>
- オプション: オブジェクトが現在の namespace 以外の namespace に定義されている場合は namespace を指定します。
<policy_file>
- ネットワークポリシーを含むファイルの名前を指定します。
マルチネットワークポリシーオブジェクトを直接更新する必要がある場合、以下のコマンドを入力できます。
$ oc edit multi-networkpolicy <policy_name> -n <namespace>
ここで、
<policy_name>
- ネットワークポリシーの名前を指定します。
<namespace>
- オプション: オブジェクトが現在の namespace 以外の namespace に定義されている場合は namespace を指定します。
マルチネットワークポリシーオブジェクトが更新されていることを確認します。
$ oc describe multi-networkpolicy <policy_name> -n <namespace>
ここで、
<policy_name>
- マルチネットワークポリシーの名前を指定します。
<namespace>
- オプション: オブジェクトが現在の namespace 以外の namespace に定義されている場合は namespace を指定します。
12.4.3.4. マルチネットワークポリシーの表示
namespace のマルチネットワークポリシーを検査できます。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
権限を持つユーザーとしてクラスターにログインしていること。 - マルチネットワークポリシーが存在する namespace で作業している。
手順
namespace のマルチネットワークポリシーを一覧表示します。
namespace で定義されたマルチネットワークポリシーオブジェクトを表示するには、以下のコマンドを実行します。
$ oc get multi-networkpolicy
オプション: 特定のマルチネットワークポリシーを検査するには、以下のコマンドを入力します。
$ oc describe multi-networkpolicy <policy_name> -n <namespace>
ここで、
<policy_name>
- 検査するマルチネットワークポリシーの名前を指定します。
<namespace>
- オプション: オブジェクトが現在の namespace 以外の namespace に定義されている場合は namespace を指定します。
12.4.3.5. マルチネットワークポリシーの削除
namespace のマルチネットワークポリシーを削除できます。
前提条件
-
クラスターは、
NetworkPolicy
オブジェクトをサポートするクラスターネットワークプロバイダーを使用する (例: OVN-Kubernetes ネットワークプロバイダー、またはmode: NetworkPolicy
が設定された OpenShift SDN ネットワークプロバイダー)。このモードは OpenShiftSDN のデフォルトです。 -
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
権限を持つユーザーとしてクラスターにログインしていること。 - マルチネットワークポリシーが存在する namespace で作業している。
手順
マルチネットワークポリシーオブジェクトを削除するには、以下のコマンドを入力します。
$ oc delete multi-networkpolicy <policy_name> -n <namespace>
ここで、
<policy_name>
- マルチネットワークポリシーの名前を指定します。
<namespace>
- オプション: オブジェクトが現在の namespace 以外の namespace に定義されている場合は namespace を指定します。
出力例
multinetworkpolicy.k8s.cni.cncf.io/default-deny deleted
12.4.4. 関連情報
12.5. Pod の追加のネットワークへの割り当て
クラスターユーザーとして、Pod を追加のネットワークに割り当てることができます。
12.5.1. Pod の追加ネットワークへの追加
Pod を追加のネットワークに追加できます。Pod は、デフォルトネットワークで通常のクラスター関連のネットワークトラフィックを継続的に送信します。
Pod が作成されると、追加のネットワークが割り当てられます。ただし、Pod がすでに存在する場合は、追加のネットワークをこれに割り当てることはできません。
Pod が追加ネットワークと同じ namespace にあること。
前提条件
-
OpenShift CLI (
oc
) をインストールします。 - クラスターにログインする。
手順
アノテーションを
Pod
オブジェクトに追加します。以下のアノテーション形式のいずれかのみを使用できます。カスタマイズせずに追加ネットワークを割り当てるには、以下の形式でアノテーションを追加します。
<network>
を、Pod に関連付ける追加ネットワークの名前に置き換えます。metadata: annotations: k8s.v1.cni.cncf.io/networks: <network>[,<network>,...] 1
- 1
- 複数の追加ネットワークを指定するには、各ネットワークをカンマで区切ります。カンマの間にはスペースを入れないでください。同じ追加ネットワークを複数回指定した場合、Pod は複数のネットワークインターフェースをそのネットワークに割り当てます。
カスタマイズして追加のネットワークを割り当てるには、以下の形式でアノテーションを追加します。
metadata: annotations: k8s.v1.cni.cncf.io/networks: |- [ { "name": "<network>", 1 "namespace": "<namespace>", 2 "default-route": ["<default-route>"] 3 } ]
Pod を作成するには、以下のコマンドを入力します。
<name>
を Pod の名前に置き換えます。$ oc create -f <name>.yaml
オプション: アノテーションが
Pod
CR に存在することを確認するには、<name>
を Pod の名前に置き換えて、以下のコマンドを入力します。$ oc get pod <name> -o yaml
以下の例では、
example-pod
Pod が追加ネットワークのnet1
に割り当てられています。$ oc get pod example-pod -o yaml apiVersion: v1 kind: Pod metadata: annotations: k8s.v1.cni.cncf.io/networks: macvlan-bridge k8s.v1.cni.cncf.io/networks-status: |- 1 [{ "name": "openshift-sdn", "interface": "eth0", "ips": [ "10.128.2.14" ], "default": true, "dns": {} },{ "name": "macvlan-bridge", "interface": "net1", "ips": [ "20.2.2.100" ], "mac": "22:2f:60:a5:f8:00", "dns": {} }] name: example-pod namespace: default spec: ... status: ...
- 1
k8s.v1.cni.cncf.io/networks-status
パラメーターは、オブジェクトの JSON 配列です。各オブジェクトは、Pod に割り当てられる追加のネットワークのステータスについて説明します。アノテーションの値はプレーンテキストの値として保存されます。
12.5.1.1. Pod 固有のアドレスおよびルーティングオプションの指定
Pod を追加のネットワークに割り当てる場合、特定の Pod でそのネットワークに関するその他のプロパティーを指定する必要がある場合があります。これにより、ルーティングの一部を変更することができ、静的 IP アドレスおよび MAC アドレスを指定できます。これを実行するには、JSON 形式のアノテーションを使用できます。
前提条件
- Pod が追加ネットワークと同じ namespace にあること。
-
OpenShift CLI (
oc
) をインストールします。 - クラスターにログインすること。
手順
アドレスおよび/またはルーティングオプションを指定する間に Pod を追加のネットワークに追加するには、以下の手順を実行します。
Pod
リソース定義を編集します。既存のPod
リソースを編集する場合は、以下のコマンドを実行してデフォルトエディターでその定義を編集します。<name>
を、編集するPod
リソースの名前に置き換えます。$ oc edit pod <name>
Pod
リソース定義で、k8s.v1.cni.cncf.io/networks
パラメーターを Pod のmetadata
マッピングに追加します。k8s.v1.cni.cncf.io/networks
は、追加のプロパティーを指定するだけでなく、NetworkAttachmentDefinition
カスタムリソース (CR) 名を参照するオブジェクト一覧の JSON 文字列を受け入れます。metadata: annotations: k8s.v1.cni.cncf.io/networks: '[<network>[,<network>,...]]' 1
- 1
<network>
を、以下の例にあるように JSON オブジェクトに置き換えます。一重引用符が必要です。
以下の例では、アノテーションで
default-route
パラメーターを使用して、デフォルトルートを持つネットワーク割り当てを指定します。apiVersion: v1 kind: Pod metadata: name: example-pod annotations: k8s.v1.cni.cncf.io/networks: ' { "name": "net1" }, { "name": "net2", 1 "default-route": ["192.0.2.1"] 2 }' spec: containers: - name: example-pod command: ["/bin/bash", "-c", "sleep 2000000000000"] image: centos/tools
デフォルトのルートにより、他のルートに指定されていないトラフィックがゲートウェイにルーティングされます。
OpenShift Container Platform のデフォルトのネットワークインターフェース以外のインターフェースへのデフォルトのルートを設定すると、Pod 間のトラフィックについて予想されるトラフィックが別のインターフェースでルーティングされる可能性があります。
Pod のルーティングプロパティーを確認する場合、oc
コマンドを Pod 内で ip
コマンドを実行するために使用できます。
$ oc exec -it <pod_name> -- ip route
また、Pod の k8s.v1.cni.cncf.io/networks-status
を参照して、JSON 形式の一覧のオブジェクトで default-route
キーの有無を確認し、デフォルトルートが割り当てられている追加ネットワークを確認することができます。
Pod に静的 IP アドレスまたは MAC アドレスを設定するには、JSON 形式のアノテーションを使用できます。これには、この機能をとくに許可するネットワークを作成する必要があります。これは、CNO の rawCNIConfig で指定できます。
以下のコマンドを実行して CNO CR を編集します。
$ oc edit networks.operator.openshift.io cluster
以下の YAML は、CNO の設定パラメーターについて説明しています。
Cluster Network Operator YAML の設定
name: <name> 1 namespace: <namespace> 2 rawCNIConfig: '{ 3 ... }' type: Raw
以下のオブジェクトは、macvlan CNI プラグインを使用して静的 MAC アドレスと IP アドレスを使用するための設定パラメーターについて説明しています。
静的 IP および MAC アドレスを使用した macvlan CNI プラグイン JSON 設定オブジェクト
{ "cniVersion": "0.3.1", "name": "<name>", 1 "plugins": [{ 2 "type": "macvlan", "capabilities": { "ips": true }, 3 "master": "eth0", 4 "mode": "bridge", "ipam": { "type": "static" } }, { "capabilities": { "mac": true }, 5 "type": "tuning" }] }
上記のネットワーク割り当ては、特定の Pod に割り当てられる静的 IP アドレスと MAC アドレスを指定するキーと共に、JSON 形式のアノテーションで参照できます。
以下を使用して Pod を編集します。
$ oc edit pod <name>
静的 IP および MAC アドレスを使用した macvlan CNI プラグイン JSON 設定オブジェクト
apiVersion: v1 kind: Pod metadata: name: example-pod annotations: k8s.v1.cni.cncf.io/networks: '[ { "name": "<name>", 1 "ips": [ "192.0.2.205/24" ], 2 "mac": "CA:FE:C0:FF:EE:00" 3 } ]'
静的 IP アドレスおよび MAC アドレスを同時に使用することはできません。これらは個別に使用することも、一緒に使用することもできます。
追加のネットワークを持つ Pod の IP アドレスと MAC プロパティーを検証するには、oc
コマンドを使用して Pod 内で ip コマンドを実行します。
$ oc exec -it <pod_name> -- ip a
12.6. 追加ネットワークからの Pod の削除
クラスターユーザーとして、追加のネットワークから Pod を削除できます。
12.6.1. 追加ネットワークからの Pod の削除
Pod を削除するだけで、追加のネットワークから Pod を削除できます。
前提条件
- 追加のネットワークが Pod に割り当てられている。
-
OpenShift CLI (
oc
) をインストールします。 - クラスターにログインする。
手順
Pod を削除するには、以下のコマンドを入力します。
$ oc delete pod <name> -n <namespace>
-
<name>
は Pod の名前です。 -
<namespace>
は Pod が含まれる namespace です。
-
12.7. 追加ネットワークの編集
クラスター管理者は、既存の追加ネットワークの設定を変更することができます。
12.7.1. 追加ネットワーク割り当て定義の変更
クラスター管理者は、既存の追加ネットワークに変更を加えることができます。追加ネットワークに割り当てられる既存の Pod は更新されません。
前提条件
- クラスター用に追加のネットワークを設定している。
-
OpenShift CLI (
oc
) をインストールします。 -
cluster-admin
権限を持つユーザーとしてログインしている。
手順
クラスターの追加ネットワークを編集するには、以下の手順を実行します。
以下のコマンドを実行し、デフォルトのテキストエディターで Cluster Network Operator (CNO) CR を編集します。
$ oc edit networks.operator.openshift.io cluster
-
additionalNetworks
コレクションで、追加ネットワークを変更内容で更新します。 - 変更を保存し、テキストエディターを終了して、変更をコミットします。
オプション: 以下のコマンドを実行して、CNO が
NetworkAttachmentDefinition
オブジェクトを更新していることを確認します。<network-name>
を表示する追加ネットワークの名前に置き換えます。CNO がNetworkAttachmentDefinition
オブジェクトを更新して変更内容が反映されるまでに遅延が生じる可能性があります。$ oc get network-attachment-definitions <network-name> -o yaml
たとえば、以下のコンソールの出力は
net1
という名前のNetworkAttachmentDefinition
オブジェクトを表示します。$ oc get network-attachment-definitions net1 -o go-template='{{printf "%s\n" .spec.config}}' { "cniVersion": "0.3.1", "type": "macvlan", "master": "ens5", "mode": "bridge", "ipam": {"type":"static","routes":[{"dst":"0.0.0.0/0","gw":"10.128.2.1"}],"addresses":[{"address":"10.128.2.100/23","gateway":"10.128.2.1"}],"dns":{"nameservers":["172.30.0.10"],"domain":"us-west-2.compute.internal","search":["us-west-2.compute.internal"]}} }
12.8. 追加ネットワークの削除
クラスター管理者は、追加のネットワーク割り当てを削除できます。
12.8.1. 追加ネットワーク割り当て定義の削除
クラスター管理者は、追加ネットワークを OpenShift Container Platform クラスターから削除できます。追加ネットワークは、割り当てられている Pod から削除されません。
前提条件
-
OpenShift CLI (
oc
) をインストールします。 -
cluster-admin
権限を持つユーザーとしてログインしている。
手順
クラスターから追加ネットワークを削除するには、以下の手順を実行します。
以下のコマンドを実行して、デフォルトのテキストエディターで Cluster Network Operator (CNO) を編集します。
$ oc edit networks.operator.openshift.io cluster
削除しているネットワーク割り当て定義の
additionalNetworks
コレクションから設定を削除し、CR を変更します。apiVersion: operator.openshift.io/v1 kind: Network metadata: name: cluster spec: additionalNetworks: [] 1
- 1
additionalNetworks
コレクションの追加ネットワーク割り当てのみの設定マッピングを削除する場合、空のコレクションを指定する必要があります。
- 変更を保存し、テキストエディターを終了して、変更をコミットします。
オプション: 以下のコマンドを実行して、追加ネットワーク CR が削除されていることを確認します。
$ oc get network-attachment-definition --all-namespaces
12.9. VRF へのセカンダリーネットワークの割り当て
12.9.1. VRF へのセカンダリーネットワークの割り当て
クラスター管理者は、CNI VRF プラグインを使用して、VRF ドメインの追加のネットワークを設定できます。このプラグインにより作成される仮想ネットワークは、指定する物理インターフェースに関連付けられます。
VRF を使用するアプリケーションを特定のデバイスにバインドする必要があります。一般的な使用方法として、ソケットに SO_BINDTODEVICE
オプションを使用できます。SO_BINDTODEVICE
は、渡されるインターフェース名で指定されているデバイスにソケットをバインドします (例: eth1
)。SO_BINDTODEVICE
を使用するには、アプリケーションに CAP_NET_RAW
機能がある必要があります。
ip vrf exec
コマンドを使用した VRF の使用は、OpenShift Container Platform Pod ではサポートされません。VRF を使用するには、アプリケーションを VRF インターフェースに直接バインドします。
12.9.1.1. CNI VRF プラグインを使用した追加のネットワーク割り当ての作成
Cluster Network Operator (CNO) は追加ネットワークの定義を管理します。作成する追加ネットワークを指定する場合、CNO は NetworkAttachmentDefinition
カスタムリソース (CR) を自動的に作成します。
Cluster Network Operator が管理する NetworkAttachmentDefinition
CR は編集しないでください。これを実行すると、追加ネットワークのネットワークトラフィックが中断する可能性があります。
CNI VRF プラグインで追加のネットワーク割り当てを作成するには、以下の手順を実行します。
前提条件
- OpenShift Container Platform CLI (oc) をインストールします。
- cluster-admin 権限を持つユーザーとして OpenShift クラスターにログインします。
手順
以下のサンプル CR のように、追加のネットワーク割り当て用の
Network
カスタムリソース(CR)を作成し、追加ネットワークのrawCNIConfig
設定を挿入します。YAML をadditional-network-attachment.yaml
ファイルとして保存します。apiVersion: operator.openshift.io/v1 kind: Network metadata: name: cluster spec: additionalNetworks: - name: test-network-1 namespace: additional-network-1 type: Raw rawCNIConfig: '{ "cniVersion": "0.3.1", "name": "macvlan-vrf", "plugins": [ 1 { "type": "macvlan", 2 "master": "eth1", "ipam": { "type": "static", "addresses": [ { "address": "191.168.1.23/24" } ] } }, { "type": "vrf", "vrfname": "example-vrf-name", 3 "table": 1001 4 }] }'
- 1
plugins
は一覧である必要があります。一覧の最初の項目は、VRF ネットワークのベースとなるセカンダリーネットワークである必要があります。一覧の 2 つ目の項目は、VRF プラグイン設定です。- 2
type
はvrf
に設定する必要があります。- 3
vrfname
は、インターフェースが割り当てられた VRF の名前です。これが Pod に存在しない場合は作成されます。- 4
- オプション。
table
はルーティングテーブル ID です。デフォルトで、tableid
パラメーターが使用されます。これが指定されていない場合、CNI は空のルーティングテーブル ID を VRF に割り当てます。
注記VRF は、リソースが
netdevice
タイプの場合にのみ正常に機能します。Network
リソースを作成します。$ oc create -f additional-network-attachment.yaml
以下のコマンドを実行して、CNO が
NetworkAttachmentDefinition
CR を作成していることを確認します。<namespace>
を、ネットワーク割り当ての設定時に指定した namespace に置き換えます(例:additional-network-1
)。$ oc get network-attachment-definitions -n <namespace>
出力例
NAME AGE additional-network-1 14m
注記CNO が CR を作成するまでに遅延が生じる可能性があります。
追加の VRF ネットワーク割り当てが正常であることの確認
VRF CNI が正しく設定され、追加のネットワーク割り当てが接続されていることを確認するには、以下を実行します。
- VRF CNI を使用するネットワークを作成します。
- ネットワークを Pod に割り当てます。
Pod のネットワーク割り当てが VRF の追加ネットワークに接続されていることを確認します。Pod にリモートシェルを実行し、以下のコマンドを実行します。
$ ip vrf show
出力例
Name Table ----------------------- red 10
VRF インターフェースがセカンダリーインターフェースのマスターであることを確認します。
$ ip link
出力例
5: net1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master red state UP mode
第13章 ハードウェアネットワーク
13.1. Single Root I/O Virtualization (SR-IOV) ハードウェアネットワークについて
Single Root I/O Virtualization (SR-IOV) 仕様は、単一デバイスを複数の Pod で共有できる PCI デバイス割り当てタイプの標準です。
SR-IOV を使用すると、準拠したネットワークデバイス (ホストノードで物理機能 (PF) として認識される) を複数の Virtual Function (VF) にセグメント化することができます。VF は他のネットワークデバイスと同様に使用されます。デバイスの SR-IOV ネットワークデバイスドライバーは、VF がコンテナーで公開される方法を判別します。
-
netdevice
ドライバー: コンテナーのnetns
内の通常のカーネルネットワークデバイス -
vfio-pci
ドライバー: コンテナーにマウントされるキャラクターデバイス
SR-IOV ネットワークデバイスは、ベアメタルまたは Red Hat Open Stack Platform (RHOSP)インフラ上にインストールされた OpenShift Container Platform クラスターにネットワークを追加して、高帯域または低遅延を確保する必要のあるアプリケーションに使用できます。
以下のコマンドを使用して、ノードで SR-IOV を有効にすることができます。
$ oc label node <node_name> feature.node.kubernetes.io/network-sriov.capable="true"
13.1.1. SR-IOV ネットワークデバイスを管理するコンポーネント
SR-IOV Network Operator は SR-IOV スタックのコンポーネントを作成し、管理します。以下の機能を実行します。
- SR-IOV ネットワークデバイスの検出および管理のオーケストレーション
-
SR-IOV Container Network Interface (CNI) の
NetworkAttachmentDefinition
カスタムリソースの生成 - SR-IOV ネットワークデバイスプラグインの設定の作成および更新
-
ノード固有の
SriovNetworkNodeState
カスタムリソースの作成 -
各
SriovNetworkNodeState
カスタムリソースのspec.interfaces
フィールドの更新
Operator は以下のコンポーネントをプロビジョニングします。
- SR-IOV ネットワーク設定デーモン
- SR-IOV Network Operator の起動時にワーカーノードにデプロイされるデーモンセット。デーモンは、クラスターで SR-IOV ネットワークデバイスを検出し、初期化します。
- SR-IOV ネットワーク Operator Webhook
- Operator カスタムリソースを検証し、未設定フィールドに適切なデフォルト値を設定する動的受付コントローラー Webhook。
- SR-IOV Network Resources Injector
-
SR-IOV VF などのカスタムネットワークリソースの要求および制限のある Kubernetes Pod 仕様のパッチを適用するための機能を提供する動的受付コントローラー Webhook。SR-IOV ネットワークリソースインジェクターは、 Pod 内の最初のコンテナーのみに
resource
フィールドを自動的に追加します。 - SR-IOV ネットワークデバイスプラグイン
- SR-IOV ネットワーク Virtual Function (VF) リソースの検出、公開、割り当てを実行するデバイスプラグイン。デバイスプラグインは、とりわけ物理デバイスでの制限されたリソースの使用を有効にするために Kubernetes で使用されます。デバイスプラグインは Kubernetes スケジューラーにリソースの可用性を認識させるため、スケジューラーはリソースが十分にあるノードで Pod をスケジュールできます。
- SR-IOV CNI プラグイン
- SR-IOV ネットワークデバイスプラグインから割り当てられる VF インターフェースを直接 Pod に割り当てる CNI プラグイン。
- SR-IOV InfiniBand CNI プラグイン
- SR-IOV ネットワークデバイスプラグインから割り当てられる InfiniBand (IB) VF インターフェースを直接 Pod に割り当てる CNI プラグイン。
SR-IOV Network Resources Injector および SR-IOV Network Operator Webhook は、デフォルトで有効にされ、default
の SriovOperatorConfig
CR を編集して無効にできます。
13.1.1.1. サポートされるプラットフォーム
SR-IOV Network Operator は、以下のプラットフォームに対応しています。
- ベアメタル
- Red Hat OpenStack Platform (RHOSP)
13.1.1.2. 対応デバイス
以下のネットワークインターフェースコントローラーは、OpenShift Container Platform でサポートされています。
表13.1 サポート対象のネットワークインターフェースコントローラー
製造元 | モデル | ベンダー ID | デバイス ID |
---|---|---|---|
Broadcom | BCM57414 | 14e4 | 16d7 |
Broadcom | BCM57508 | 14e4 | 1750 |
Intel | X710 | 8086 | 1572 |
Intel | XL710 | 8086 | 1583 |
Intel | XXV710 | 8086 | 158b |
Intel | E810-CQDA2 | 8086 | 1592 |
Intel | E810-2CQDA2 | 8086 | 1592 |
Intel | E810-XXVDA2 | 8086 | 159b |
Intel | E810-XXVDA4 | 8086 | 1593 |
Mellanox | MT27700 Family [ConnectX‑4] | 15b3 | 1013 |
Mellanox | MT27710 Family [ConnectX‑4 Lx] | 15b3 | 1015 |
Mellanox | MT27800 Family [ConnectX‑5] | 15b3 | 1017 |
Mellanox | MT28880 Family [ConnectX‑5 Ex] | 15b3 | 1019 |
Mellanox | MT28908 Family [ConnectX‑6] | 15b3 | 101b |
Mellanox | MT28908 Family [ConnectX‑6 Lx] | 15b3 | 101f |
サポートされるカードの最新の一覧と互換性のある OpenShift Container Platform バージョンについては、「OpenShift Single Root I/O Virtualization(SR-IOV)および PTP ハードウェアネットワークのサポートマトリックス 」を参照してください。
13.1.1.3. SR-IOV ネットワークデバイスの自動検出
SR-IOV Network Operator は、クラスターでワーカーノード上の SR-IOV 対応ネットワークデバイスを検索します。Operator は、互換性のある SR-IOV ネットワークデバイスを提供する各ワーカーノードの SriovNetworkNodeState カスタムリソース (CR) を作成し、更新します。
CR にはワーカーノードと同じ名前が割り当てられます。status.interfaces
一覧は、ノード上のネットワークデバイスについての情報を提供します。
SriovNetworkNodeState
オブジェクトは変更しないでください。Operator はこれらのリソースを自動的に作成し、管理します。
13.1.1.3.1. SriovNetworkNodeState オブジェクトの例
以下の YAML は、SR-IOV Network Operator によって作成される SriovNetworkNodeState
オブジェクトの例です。
SriovNetworkNodeState オブジェクト
apiVersion: sriovnetwork.openshift.io/v1 kind: SriovNetworkNodeState metadata: name: node-25 1 namespace: openshift-sriov-network-operator ownerReferences: - apiVersion: sriovnetwork.openshift.io/v1 blockOwnerDeletion: true controller: true kind: SriovNetworkNodePolicy name: default spec: dpConfigVersion: "39824" status: interfaces: 2 - deviceID: "1017" driver: mlx5_core mtu: 1500 name: ens785f0 pciAddress: "0000:18:00.0" totalvfs: 8 vendor: 15b3 - deviceID: "1017" driver: mlx5_core mtu: 1500 name: ens785f1 pciAddress: "0000:18:00.1" totalvfs: 8 vendor: 15b3 - deviceID: 158b driver: i40e mtu: 1500 name: ens817f0 pciAddress: 0000:81:00.0 totalvfs: 64 vendor: "8086" - deviceID: 158b driver: i40e mtu: 1500 name: ens817f1 pciAddress: 0000:81:00.1 totalvfs: 64 vendor: "8086" - deviceID: 158b driver: i40e mtu: 1500 name: ens803f0 pciAddress: 0000:86:00.0 totalvfs: 64 vendor: "8086" syncStatus: Succeeded
13.1.1.4. Pod での Virtual Function (VF) の使用例
SR-IOV VF が割り当てられている Pod で、Remote Direct Memory Access (RDMA) または Data Plane Development Kit (DPDK) アプリケーションを実行できます。
以下の例では、RDMA モードで Virtual Function (VF) を使用する Pod を示しています。
RDMA モードを使用する Pod
仕様
apiVersion: v1 kind: Pod metadata: name: rdma-app annotations: k8s.v1.cni.cncf.io/networks: sriov-rdma-mlnx spec: containers: - name: testpmd image: <RDMA_image> imagePullPolicy: IfNotPresent securityContext: runAsUser: 0 capabilities: add: ["IPC_LOCK","SYS_RESOURCE","NET_RAW"] command: ["sleep", "infinity"]
以下の例は、DPDK モードの VF のある Pod を示しています。
DPDK モードを使用する Pod
仕様
apiVersion: v1 kind: Pod metadata: name: dpdk-app annotations: k8s.v1.cni.cncf.io/networks: sriov-dpdk-net spec: containers: - name: testpmd image: <DPDK_image> securityContext: runAsUser: 0 capabilities: add: ["IPC_LOCK","SYS_RESOURCE","NET_RAW"] volumeMounts: - mountPath: /dev/hugepages name: hugepage resources: limits: memory: "1Gi" cpu: "2" hugepages-1Gi: "4Gi" requests: memory: "1Gi" cpu: "2" hugepages-1Gi: "4Gi" command: ["sleep", "infinity"] volumes: - name: hugepage emptyDir: medium: HugePages
13.1.1.5. コンテナーアプリケーションで使用する DPDK ライブラリー
オプションライブラリー の app-netutil
は、その Pod 内で実行されるコンテナーから Pod についてのネットワーク情報を収集するための複数の API メソッドを提供します。
このライブラリーは、DPDK (Data Plane Development Kit) モードの SR-IOV Virtual Function (VF) のコンテナーへの統合を支援します。このライブラリーは Golang API と C API の両方を提供します。
現時点で 3 つの API メソッドが実装されています。
GetCPUInfo()
- この機能は、コンテナーで利用可能な CPU を判別し、一覧を返します。
GetHugepages()
-
この機能は、各コンテナーの
Pod
仕様で要求される huge page メモリーの量を判別し、値を返します。 GetInterfaces()
- この機能は、コンテナーのインターフェースセットを判別し、インターフェースタイプとタイプ固有のデータと共に一覧を返します。戻り値には、インターフェースのタイプと、各インターフェースのタイプ固有のデータが含まれます。
ライブラリーのリポジトリーには、コンテナーイメージ dpdk-app-centos
をビルドするためのサンプル Dockerfile が含まれます。コンテナーイメージは、Pod 仕様の環境変数に応じて、l2fwd
、l3wd
または testpmd
の DPDK サンプルアプリケーションのいずれかを実行できます。コンテナーイメージは、app-netutil
ライブラリーをコンテナーイメージ自体に統合する例を提供します。ライブラリーを init コンテナーに統合することもできます。init コンテナーは必要なデータを収集し、データを既存の DPDK ワークロードに渡すことができます。
13.1.1.6. Downward API の Huge Page リソースの挿入
Pod 仕様に Huge Page のリソース要求または制限が含まれる場合、Network Resources Injector は Downward API フィールドを Pod 仕様に自動的に追加し、Huge Page 情報をコンテナーに提供します。
Network Resources Injector は、podnetinfo
という名前のボリュームを追加し、Pod の各コンテナー用に /etc/podnetinfo
にマウントされます。ボリュームは Downward API を使用し、Huge Page の要求および制限についてのファイルを追加します。ファイルの命名規則は以下のとおりです。
-
/etc/podnetinfo/hugepages_1G_request_<container-name>
-
/etc/podnetinfo/hugepages_1G_limit_<container-name>
-
/etc/podnetinfo/hugepages_2M_request_<container-name>
-
/etc/podnetinfo/hugepages_2M_limit_<container-name>
直前の一覧で指定されているパスは、app-netutil
ライブラリーと互換性があります。デフォルトで、ライブラリーは、/etc/podnetinfo
ディレクトリーのリソース情報を検索するように設定されます。Downward API パス項目を手動で指定する選択をする場合、app-netutil
ライブラリーは前述の一覧のパスに加えて以下のパスを検索します。
-
/etc/podnetinfo/hugepages_request
-
/etc/podnetinfo/hugepages_limit
-
/etc/podnetinfo/hugepages_1G_request
-
/etc/podnetinfo/hugepages_1G_limit
-
/etc/podnetinfo/hugepages_2M_request
-
/etc/podnetinfo/hugepages_2M_limit
Network Resources Injector が作成できるパスと同様に、前述の一覧のパスの末尾にはオプションで _<container-name>
サフィックスを付けることができます。
13.1.2. 次のステップ
- SR-IOV Network Operator のインストール
- オプション: SR-IOV Network Operator の設定
- SR-IOV ネットワークデバイスの設定
- OpenShift Virtualization を使用する場合: 仮想マシンの SR-IOV ネットワークデバイスの設定
- SR-IOV ネットワーク割り当ての設定
- Pod の SR-IOV の追加ネットワークへの追加
13.2. SR-IOV Network Operator のインストール
Single Root I/O Virtualization (SR-IOV) ネットワーク Operator をクラスターにインストールし、SR-IOV ネットワークデバイスとネットワークの割り当てを管理できます。
13.2.1. SR-IOV Network Operator のインストール
クラスター管理者は、OpenShift Container Platform CLI または Web コンソールを使用して SR-IOV Network Operator をインストールできます。
13.2.1.1. CLI: SR-IOV Network Operator のインストール
クラスター管理者は、CLI を使用して Operator をインストールできます。
前提条件
- SR-IOV に対応するハードウェアを持つノードでベアメタルハードウェアにインストールされたクラスター。
-
OpenShift CLI (
oc
) をインストールします。 -
cluster-admin
権限を持つアカウント。
手順
openshift-sriov-network-operator
namespace を作成するには、以下のコマンドを入力します。$ cat << EOF| oc create -f - apiVersion: v1 kind: Namespace metadata: name: openshift-sriov-network-operator annotations: workload.openshift.io/allowed: management EOF
OperatorGroup CR を作成するには、以下のコマンドを実行します。
$ cat << EOF| oc create -f - apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: sriov-network-operators namespace: openshift-sriov-network-operator spec: targetNamespaces: - openshift-sriov-network-operator EOF
SR-IOV Network Operator にサブスクライブします。
以下のコマンドを実行して OpenShift Container Platform のメジャーおよびマイナーバージョンを取得します。これは、次の手順の
channel
の値に必要です。$ OC_VERSION=$(oc version -o yaml | grep openshiftVersion | \ grep -o '[0-9]*[.][0-9]*' | head -1)
SR-IOV Network Operator の Subscription CR を作成するには、以下のコマンドを入力します。
$ cat << EOF| oc create -f - apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: sriov-network-operator-subscription namespace: openshift-sriov-network-operator spec: channel: "${OC_VERSION}" name: sriov-network-operator source: redhat-operators sourceNamespace: openshift-marketplace EOF
Operator がインストールされていることを確認するには、以下のコマンドを入力します。
$ oc get csv -n openshift-sriov-network-operator \ -o custom-columns=Name:.metadata.name,Phase:.status.phase
出力例
Name Phase sriov-network-operator.4.9.0-202110121402 Succeeded
13.2.1.2. Web コンソール: SR-IOV Network Operator のインストール
クラスター管理者は、Web コンソールを使用して Operator をインストールできます。
CLI を使用して Operator グループを作成する必要があります。
前提条件
- SR-IOV に対応するハードウェアを持つノードでベアメタルハードウェアにインストールされたクラスター。
-
OpenShift CLI (
oc
) をインストールします。 -
cluster-admin
権限を持つアカウント。
手順
SR-IOV Network Operator の namespace を作成します。
- OpenShift Container Platform Web コンソールで、Administration → Namespaces をクリックします。
- Create Namespace をクリックします。
-
Name フィールドに
openshift-sriov-network-operator
を入力し、Create をクリックします。
SR-IOV Network Operator をインストールします。
- OpenShift Container Platform Web コンソールで、Operators → OperatorHub をクリックします。
- 利用可能な Operator の一覧から SR-IOV Network Operator を選択してから Install をクリックします。
- Install Operator ページの A specific namespace on the cluster の下で、openshift-sriov-network-operator を選択します。
- Install をクリックします。
SR-IOV Network Operator が正常にインストールされていることを確認します。
- Operators → Installed Operators ページに移動します。
Status が InstallSucceeded の状態で、SR-IOV Network Operator が openshift-sriov-network-operator プロジェクトに一覧表示されていることを確認します。
注記インストール時に、 Operator は Failed ステータスを表示する可能性があります。インストールが後に InstallSucceeded メッセージを出して正常に実行される場合は、Failed メッセージを無視できます。
Operator がインストール済みとして表示されない場合に、さらにトラブルシューティングを実行します。
- Operator Subscriptions および Install Plans タブで、Status の下の失敗またはエラーの有無を確認します。
-
Workloads → Pods ページに移動し、
openshift-sriov-network-operator
プロジェクトで Pod のログを確認します。 YAML ファイルのnamespaceを確認してください。アノテーションが抜けている場合は、次のコマンドを使用して、アノテーション
workload.openshift.io/allowed=management
を Operator namespaceに追加できます。$ oc annotate ns/openshift-sriov-network-operator workload.openshift.io/allowed=management
注記シングルノード OpenShift (SNO) クラスターの場合には、namespaceにアノテーション
workload.openshift.io/allowed=management
が必要です。
13.2.2. 次のステップ
- オプション: SR-IOV Network Operator の設定
13.3. SR-IOV Network Operator の設定
Single Root I/O Virtualization (SR-IOV) ネットワーク Operator は、クラスターで SR-IOV ネットワークデバイスおよびネットワーク割り当てを管理します。
13.3.1. SR-IOV Network Operator の設定
通常、SR-IOV Network Operator 設定を変更する必要はありません。デフォルト設定は、ほとんどのユースケースで推奨されます。Operator のデフォルト動作がユースケースと互換性がない場合にのみ、関連する設定を変更する手順を実行します。
SR-IOV Network Operator は SriovOperatorConfig.sriovnetwork.openshift.io
CustomResourceDefinition リソースを追加します。Operator は、openshift-sriov-network-operator
namespace に default
という名前の SriovOperatorConfig カスタムリソース (CR) を自動的に作成します。
default
CR には、クラスターの SR-IOV Network Operator 設定が含まれます。Operator 設定を変更するには、この CR を変更する必要があります。
13.3.1.1. SR-IOV Network Operator config カスタムリソース
sriovoperatorconfig
カスタムリソースのフィールドは、以下の表で説明されています。
表13.2 SR-IOV Network Operator config カスタムリソース
フィールド | タイプ | 詳細 |
---|---|---|
|
|
SR-IOV Network Operator インスタンスの名前を指定します。デフォルト値は |
|
|
SR-IOV Network Operator インスタンスの namespace を指定します。デフォルト値は |
|
| 選択されたノードで SR-IOV Network Config Daemon のスケジューリングを制御するノードの選択オプションを指定します。デフォルトでは、このフィールドは設定されておらず、Operator はワーカーノードに SR-IOV Network Config デーモン セットを配置します。 |
|
|
新しいポリシーを適用してノードに NIC を構成する時に、ノードドレインプロセスを無効にするか、有効にするかを指定します。このフィールドを
シングルノードクラスターの場合は、Operator のインストール後にこのフィールドを |
|
|
Network Resources Injector デーモンセットを有効にするか無効にするかを指定します。デフォルトでは、このフィールドは |
|
|
Operator Admission Controller の Webhook デーモンセットを有効にするか無効にするかを指定します。デフォルトでは、このフィールドは |
|
|
Operator のログの冗長度を指定します。 |
13.3.1.2. Network Resources Injector について
Network Resources Injector は Kubernetes Dynamic Admission Controller アプリケーションです。これは、以下の機能を提供します。
- SR-IOV リソース名を SR-IOV ネットワーク割り当て定義アノテーションに従って追加するための、Pod 仕様でのリソース要求および制限の変更。
-
Pod のアノテーション、ラベル、および Huge Page の要求および制限を公開するための Downward API ボリュームでの Pod 仕様の変更。Pod で実行されるコンテナーは、公開される情報に
/etc/podnetinfo
パスでファイルとしてアクセスできます。
デフォルトで、Network Resources Injector は SR-IOV Network Operator によって有効にされ、すべてのコントロールプレーンノードでデーモンセットとして実行されます。以下は、3 つのコントロールプレーンノードを持つクラスターで実行される Network Resources Injector Pod の例です。
$ oc get pods -n openshift-sriov-network-operator
出力例
NAME READY STATUS RESTARTS AGE network-resources-injector-5cz5p 1/1 Running 0 10m network-resources-injector-dwqpx 1/1 Running 0 10m network-resources-injector-lktz5 1/1 Running 0 10m
13.3.1.3. SR-IOV Network Operator Admission Controller Webhook について
SR-IOV Network Operator Admission Controller Webbook は Kubernetes Dynamic Admission Controller アプリケーションです。これは、以下の機能を提供します。
-
作成時または更新時の
SriovNetworkNodePolicy
CR の検証 -
CR の作成または更新時の
priority
およびdeviceType
フィールドのデフォルト値の設定によるSriovNetworkNodePolicy
CR の変更
デフォルトで、SR-IOV Network Operator Admission Controller Webhook は Operator によって有効にされ、すべてのコントロールプレーンノードでデーモンセットとして実行されます。以下は、3 つのコントロールプレーンノードを持つクラスターで実行される Operator Admission Controller Webhook Pod の例です。
$ oc get pods -n openshift-sriov-network-operator
出力例
NAME READY STATUS RESTARTS AGE operator-webhook-9jkw6 1/1 Running 0 16m operator-webhook-kbr5p 1/1 Running 0 16m operator-webhook-rpfrl 1/1 Running 0 16m
13.3.1.4. カスタムノードセレクターについて
SR-IOV Network Config デーモンは、クラスターノード上の SR-IOV ネットワークデバイスを検出し、設定します。デフォルトで、これはクラスター内のすべての worker
ノードにデプロイされます。ノードラベルを使用して、SR-IOV Network Config デーモンが実行するノードを指定できます。
13.3.1.5. Network Resources Injector の無効化または有効化
デフォルトで有効にされている Network Resources Injector を無効にするか、または有効にするには、以下の手順を実行します。
前提条件
-
OpenShift CLI (
oc
) をインストールします。 -
cluster-admin
権限を持つユーザーとしてログインしている。 - SR-IOV Network Operator がインストールされていること。
手順
enableInjector
フィールドを設定します。<value>
をfalse
に置き換えて機能を無効にするか、またはtrue
に置き換えて機能を有効にします。$ oc patch sriovoperatorconfig default \ --type=merge -n openshift-sriov-network-operator \ --patch '{ "spec": { "enableInjector": <value> } }'
ヒントまたは、以下の YAML を適用して Operator を更新することもできます。
apiVersion: sriovnetwork.openshift.io/v1 kind: SriovOperatorConfig metadata: name: default namespace: openshift-sriov-network-operator spec: enableInjector: <value>
13.3.1.6. SR-IOV Network Operator Admission Controller Webhook の無効化または有効化
デフォルトで有効にされている なっている受付コントローラー Webhook を無効にするか、または有効にするには、以下の手順を実行します。
前提条件
-
OpenShift CLI (
oc
) をインストールします。 -
cluster-admin
権限を持つユーザーとしてログインしている。 - SR-IOV Network Operator がインストールされていること。
手順
enableOperatorWebhook
フィールドを設定します。<value>
をfalse
に置き換えて機能を無効するか、true
に置き換えて機能を有効にします。$ oc patch sriovoperatorconfig default --type=merge \ -n openshift-sriov-network-operator \ --patch '{ "spec": { "enableOperatorWebhook": <value> } }'
ヒントまたは、以下の YAML を適用して Operator を更新することもできます。
apiVersion: sriovnetwork.openshift.io/v1 kind: SriovOperatorConfig metadata: name: default namespace: openshift-sriov-network-operator spec: enableOperatorWebhook: <value>
13.3.1.7. SRIOV Network Config Daemon のカスタム NodeSelector の設定
SR-IOV Network Config デーモンは、クラスターノード上の SR-IOV ネットワークデバイスを検出し、設定します。デフォルトで、これはクラスター内のすべての worker
ノードにデプロイされます。ノードラベルを使用して、SR-IOV Network Config デーモンが実行するノードを指定できます。
SR-IOV Network Config デーモンがデプロイされるノードを指定するには、以下の手順を実行します。
configDaemonNodeSelector
フィールドを更新する際に、SR-IOV Network Config デーモンがそれぞれの選択されたノードに再作成されます。デーモンが再作成されている間、クラスターのユーザーは新規の SR-IOV Network ノードポリシーを適用したり、新規の SR-IOV Pod を作成したりできません。
手順
Operator のノードセレクターを更新するには、以下のコマンドを入力します。
$ oc patch sriovoperatorconfig default --type=json \ -n openshift-sriov-network-operator \ --patch '[{ "op": "replace", "path": "/spec/configDaemonNodeSelector", "value": {<node_label>} }]'
以下の例のように、
<node_label>
を適用するラベルに置き換えます:"node-role.kubernetes.io/worker": ""
ヒントまたは、以下の YAML を適用して Operator を更新することもできます。
apiVersion: sriovnetwork.openshift.io/v1 kind: SriovOperatorConfig metadata: name: default namespace: openshift-sriov-network-operator spec: configDaemonNodeSelector: <node_label>
13.3.1.8. 単一ノードのインストール用の SR-IOV Network Operator の設定
デフォルトでは、SR-IOV Network Operator は、ポリシーを変更するたびに、ノードからワークロードをドレイン (解放) します。Operator は、このアクションを実行して、再設定する前に Virtual Functionを使用しているワークロードがないことを確認します。
1 つのノードにインストールする場合には、ワークロードを受信するノードは他にありません。そのため、Operator は、単一のノードからワークロードがドレインされないように設定する必要があります。
以下の手順を実行してワークロードのドレインを無効にした後に、SR-IOV ネットワークインターフェースを使用しているワークロードを削除してから SR-IOV ネットワークノードのポリシーを変更する必要があります。
前提条件
-
OpenShift CLI (
oc
) をインストールします。 -
cluster-admin
権限を持つユーザーとしてログインしている。 - SR-IOV Network Operator がインストールされていること。
手順
disable Drain
フィールドをtrue
に設定するには、次のコマンドを入力します。$ oc patch sriovoperatorconfig default --type=merge \ -n openshift-sriov-network-operator \ --patch '{ "spec": { "disableDrain": true } }'
ヒントまたは、以下の YAML を適用して Operator を更新することもできます。
apiVersion: sriovnetwork.openshift.io/v1 kind: SriovOperatorConfig metadata: name: default namespace: openshift-sriov-network-operator spec: disableDrain: true
13.3.2. 次のステップ
13.4. SR-IOV ネットワークデバイスの設定
クラスターで Single Root I/O Virtualization (SR-IOV) デバイスを設定できます。
13.4.1. SR-IOV ネットワークノード設定オブジェクト
SR-IOV ネットワークノードポリシーを作成して、ノードの SR-IOV ネットワークデバイス設定を指定します。ポリシーの API オブジェクトは sriovnetwork.openshift.io
API グループの一部です。
以下の YAML は SR-IOV ネットワークノードポリシーについて説明しています。
apiVersion: sriovnetwork.openshift.io/v1 kind: SriovNetworkNodePolicy metadata: name: <name> 1 namespace: openshift-sriov-network-operator 2 spec: resourceName: <sriov_resource_name> 3 nodeSelector: feature.node.kubernetes.io/network-sriov.capable: "true" 4 priority: <priority> 5 mtu: <mtu> 6 needVhostNet: false 7 numVfs: <num> 8 nicSelector: 9 vendor: "<vendor_code>" 10 deviceID: "<device_id>" 11 pfNames: ["<pf_name>", ...] 12 rootDevices: ["<pci_bus_id>", ...] 13 netFilter: "<filter_string>" 14 deviceType: <device_type> 15 isRdma: false 16 linkType: <link_type> 17
- 1
- カスタムリソースオブジェクトの名前。
- 2
- SR-IOV Network Operator がインストールされている namespace を指定します。
- 3
- SR-IOV ネットワークデバイスプラグインのリソース名。1 つのリソース名に複数の SR-IOV ネットワークポリシーを作成できます。
- 4
- ノードセレクターは設定するノードを指定します。選択したノード上の SR-IOV ネットワークデバイスのみが設定されます。SR-IOV Container Network Interface (CNI) プラグインおよびデバイスプラグインは、選択したノードにのみデプロイされます。
- 5
- オプション: 優先度は
0
から99
までの整数値で指定されます。値が小さいほど優先度が高くなります。たとえば、10
の優先度は99
よりも高くなります。デフォルト値は99
です。 - 6
- オプション: Virtual Function (VF) の最大転送単位 (MTU)。MTU の最大値は、複数の異なるネットワークインターフェースコントローラー (NIC) に応じて異なります。
- 7
- オプション:
/dev/vhost-net
デバイスを Pod にマウントするには、needVhostNet
をtrue
に設定します。Data Plane Development Kit(DPDK)と共にマウントされた/dev/vhost-net
デバイスを使用して、トラフィックをカーネルネットワークスタックに転送します。 - 8
- SR-IOV 物理ネットワークデバイス用に作成する Virtual Function (VF) の数。Intel ネットワークインターフェースコントローラー (NIC) の場合、VF の数はデバイスがサポートする VF の合計よりも大きくすることはできません。Mellanox NIC の場合、VF の数は
128
よりも大きくすることはできません。 - 9
- NIC セレクターは、Operator が設定するデバイスを特定します。すべてのパラメーターの値を指定する必要はありません。意図せずにデバイスを選択しないように、ネットワークデバイスを極めて正確に特定することが推奨されます。
rootDevices
を指定する場合、vendor
、deviceID
、またはpfName
の値も指定する必要があります。pfNames
およびrootDevices
の両方を同時に指定する場合、それらが同一のデバイスを参照していることを確認します。netFilter
の値を指定する場合、ネットワーク ID は一意の ID であるためにその他のパラメーターを指定する必要はありません。 - 10
- オプション: SR-IOV ネットワークデバイスのベンダーの 16 進数コード。許可される値は
8086
および15b3
のみになります。 - 11
- オプション: SR-IOV ネットワークデバイスのデバイスの 16 進数コード。たとえば、
101b
は Mellanox ConnectX-6 デバイスのデバイス ID です。 - 12
- オプション: 1 つ以上のデバイスの物理機能 (PF) 名の配列。
- 13
- オプション: デバイスの PF 用の 1 つ以上の PCI バスアドレスの配列。以下の形式でアドレスを指定します:
0000:02:00.1
- 14
- オプション: プラットフォーム固有のネットワークフィルター。サポートされるプラットフォームは Red Hat OpenStack Platform (RHOSP) のみです。許可される値は、
openstack/NetworkID:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
の形式を使用します。xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
を、/var/config/openstack/latest/network_data.json
メタデータファイルの値に置き換えます。 - 15
- オプション: Virtual Function (VF) のドライバータイプ。許可される値は
netdevice
およびvfio-pci
のみです。デフォルト値はnetdevice
です。Mellanox NIC をベアメタルノードの DPDK モードで機能させるには、
netdevice
ドライバータイプを使用し、isRdma
をtrue
に設定します。 - 16
- オプション: Remote Direct Memory Access (RDMA) モードを有効にするかどうかを設定します。デフォルト値は
false
です。isRdma
パラメーターがtrue
に設定される場合、引き続き RDMA 対応の VF を通常のネットワークデバイスとして使用できます。デバイスはどちらのモードでも使用できます。isRdma
をtrue
に設定し、追加のneedVhostNet
をtrue
に設定して、Fast Datapath DPDK アプリケーションで使用する Mellanox NIC を設定します。 - 17
- オプション: VF のリンクタイプ。デフォルト値は、イーサネットの場合は
eth
です。InfiniBand のこの値をib
に変更します。linkType
がib
に設定されている場合、SR-IOV Network Operator Webhook によってisRdma
はtrue
に自動的に設定されます。linkType
がib
に設定されている場合、deviceType
はvfio-pci
に設定できません。SriovNetworkNodePolicy
ではlinkType
をeth
に設定しないでください。デバイスプラグインによって報告される利用可能なデバイスの数が正しくない数になる可能性があるためです。 - オプション: ハードウェアオフロードを有効にするには、
eSwitchMode
フィールドをswitchdev
に設定する必要があります。
13.4.1.1. SR-IOV ネットワークノードの設定例
以下の例では、InfiniBand デバイスの設定について説明します。
InfiniBand デバイスの設定例
apiVersion: sriovnetwork.openshift.io/v1 kind: SriovNetworkNodePolicy metadata: name: policy-ib-net-1 namespace: openshift-sriov-network-operator spec: resourceName: ibnic1 nodeSelector: feature.node.kubernetes.io/network-sriov.capable: "true" numVfs: 4 nicSelector: vendor: "15b3" deviceID: "101b" rootDevices: - "0000:19:00.0" linkType: ib isRdma: true
以下の例では、RHOSP 仮想マシンの SR-IOV ネットワークデバイスの設定について説明します。
仮想マシンの SR-IOV デバイスの設定例
apiVersion: sriovnetwork.openshift.io/v1 kind: SriovNetworkNodePolicy metadata: name: policy-sriov-net-openstack-1 namespace: openshift-sriov-network-operator spec: resourceName: sriovnic1 nodeSelector: feature.node.kubernetes.io/network-sriov.capable: "true" numVfs: 1 1 nicSelector: vendor: "15b3" deviceID: "101b" netFilter: "openstack/NetworkID:ea24bd04-8674-4f69-b0ee-fa0b3bd20509" 2
13.4.1.2. SR-IOV デバイスの Virtual Function (VF) パーティション設定
Virtual Function (VF) を同じ物理機能 (PF) から複数のリソースプールに分割する必要がある場合があります。たとえば、VF の一部をデフォルトドライバーで読み込み、残りの VF を vfio-pci
ドライバーで読み込む必要がある場合などです。このようなデプロイメントでは、SriovNetworkNodePolicy カスタムリソース (CR) の pfNames
セレクターは、以下の形式を使用してプールの VF の範囲を指定するために使用できます: <pfname>#<first_vf>-<last_vf>
たとえば、以下の YAML は、VF が 2
から 7
まである netpf0
という名前のインターフェースのセレクターを示します。
pfNames: ["netpf0#2-7"]
-
netpf0
は PF インターフェース名です。 -
2
は、範囲に含まれる最初の VF インデックス (0 ベース)です。 -
7
は、範囲に含まれる最後の VF インデックス (0 ベース)です。
以下の要件を満たす場合、異なるポリシー CR を使用して同じ PF から VF を選択できます。
-
numVfs
の値は、同じ PF を選択するポリシーで同一である必要があります。 -
VF インデックスは、
0
から<numVfs>-1
の範囲にある必要があります。たとえば、numVfs
が8
に設定されているポリシーがある場合、<first_vf>
の値は0
よりも小さくすることはできず、<last_vf>
は7
よりも大きくすることはできません。 - 異なるポリシーの VF の範囲は重複しないようにしてください。
-
<first_vf>
は<last_vf>
よりも大きくすることはできません。
以下の例は、SR-IOV デバイスの NIC パーティション設定を示しています。
ポリシー policy-net-1
は、デフォルトの VF ドライバーと共に PF netpf0
の VF 0
が含まれるリソースプール net-1
を定義します。ポリシー policy-net-1-dpdk
は、vfio
VF ドライバーと共に PF netpf0
の VF 8
から 15
までが含まれるリソースプール net-1-dpdk
を定義します。
ポリシー policy-net-1
:
apiVersion: sriovnetwork.openshift.io/v1 kind: SriovNetworkNodePolicy metadata: name: policy-net-1 namespace: openshift-sriov-network-operator spec: resourceName: net1 nodeSelector: feature.node.kubernetes.io/network-sriov.capable: "true" numVfs: 16 nicSelector: pfNames: ["netpf0#0-0"] deviceType: netdevice
ポリシー policy-net-1-dpdk
:
apiVersion: sriovnetwork.openshift.io/v1 kind: SriovNetworkNodePolicy metadata: name: policy-net-1-dpdk namespace: openshift-sriov-network-operator spec: resourceName: net1dpdk nodeSelector: feature.node.kubernetes.io/network-sriov.capable: "true" numVfs: 16 nicSelector: pfNames: ["netpf0#8-15"] deviceType: vfio-pci
13.4.2. SR-IOV ネットワークデバイスの設定
SR-IOV Network Operator は SriovNetworkNodePolicy.sriovnetwork.openshift.io
CustomResourceDefinition を OpenShift Container Platform に追加します。SR-IOV ネットワークデバイスは、SriovNetworkNodePolicy カスタムリソース (CR) を作成して設定できます。
SriovNetworkNodePolicy
オブジェクトで指定された設定を適用する際に、SR-IOV Operator はノードをドレイン (解放) する可能性があり、場合によってはノードの再起動を行う場合があります。
設定の変更が適用されるまでに数分かかる場合があります。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできる。 - SR-IOV Network Operator がインストールされていること。
- ドレイン (解放) されたノードからエビクトされたワークロードを処理するために、クラスター内に利用可能な十分なノードがあること。
- SR-IOV ネットワークデバイス設定についてコントロールプレーンノードを選択していないこと。
手順
-
SriovNetworkNodePolicy
オブジェクトを作成してから、YAML を<name>-sriov-node-network.yaml
ファイルに保存します。<name>
をこの設定の名前に置き換えます。 -
オプション: SR-IOV 対応クラスターノードに
SriovNetworkNodePolicy.Spec.NodeSelector
のラベルが付けられていない場合は、これらのノードにラベルを付けます。ノードのラベル付けに関する詳細は、「ノードでラベルを更新する方法について」を参照してください。
SriovNetworkNodePolicy
オブジェクトを作成します。$ oc create -f <name>-sriov-node-network.yaml
ここで、
<name>
はこの設定の名前を指定します。設定の更新が適用された後に、
sriov-network-operator
namespace のすべての Pod がRunning
ステータスに移行します。SR-IOV ネットワークデバイスが設定されていることを確認するには、以下のコマンドを実行します。
<node_name>
を、設定したばかりの SR-IOV ネットワークデバイスを持つノードの名前に置き換えます。$ oc get sriovnetworknodestates -n openshift-sriov-network-operator <node_name> -o jsonpath='{.status.syncStatus}'
関連情報
13.4.3. SR-IOV 設定のトラブルシューティング
SR-IOV ネットワークデバイスの設定の手順を実行した後に、以下のセクションではエラー状態の一部に対応します。
ノードの状態を