This documentation is for a release that is no longer maintained
See documentation for the latest supported version 3 or the latest supported version 4.ネットワーク
クラスターネットワークの設定および管理
概要
第1章 ネットワークについて リンクのコピーリンクがクリップボードにコピーされました!
Kubernetes は、確実に 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 によって到達可能になります。
第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 では、インストーラーと同様に、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>
$ ssh -i <ssh-key-path> core@<master-hostname>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
第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
$ oc get -n openshift-network-operator deployment/network-operatorCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME READY UP-TO-DATE AVAILABLE AGE network-operator 1/1 1 1 56m
NAME READY UP-TO-DATE AVAILABLE AGE network-operator 1/1 1 1 56mCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行して、Cluster Network Operator の状態を表示します。
oc get clusteroperator/network
$ oc get clusteroperator/networkCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE network 4.4.0 True False False 50m
NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE network 4.4.0 True False False 50mCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のフィールドは、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
$ oc describe network.config/clusterCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.3. Cluster Network Operator のステータス表示 リンクのコピーリンクがクリップボードにコピーされました!
oc describe コマンドを使用して、Cluster Network Operator のステータスを検査し、その詳細を表示することができます。
手順
以下のコマンドを実行して、Cluster Network Operator のステータスを表示します。
oc describe clusteroperators/network
$ oc describe clusteroperators/networkCopy to Clipboard Copied! Toggle word wrap Toggle overflow
3.4. Cluster Network Operator ログの表示 リンクのコピーリンクがクリップボードにコピーされました!
oc logs コマンドを使用して、Cluster Network Operator ログを表示できます。
手順
以下のコマンドを実行して、Cluster Network Operator のログを表示します。
oc logs --namespace=openshift-network-operator deployment/network-operator
$ oc logs --namespace=openshift-network-operator deployment/network-operatorCopy to Clipboard Copied! Toggle word wrap Toggle overflow
Open Virtual Networking (OVN) Kubernetes ネットワークプラグインは、テクノロジープレビュー機能です。テクノロジープレビュー機能は Red Hat の実稼働環境でのサービスレベルアグリーメント (SLA) ではサポートされていないため、Red Hat では実稼働環境での使用を推奨していません。Red Hat は実稼働環境でこれらを使用することを推奨していません。これらの機能は、近々発表予定の製品機能をリリースに先駆けてご提供することにより、お客様は機能性をテストし、開発プロセス中にフィードバックをお寄せいただくことができます。
OVN テクノロジープレビュー機能のサポート範囲についての詳細は、https://access.redhat.com/articles/4380121 を参照してください。
3.5. Cluster Network Operator (CNO) の設定 リンクのコピーリンクがクリップボードにコピーされました!
クラスターネットワークの設定は、Cluster Network Operator (CNO) 設定の一部として指定され、cluster という名前の CR オブジェクトに保存されます。CR は operator.openshift.io API グループの Network API のパラメーターを指定します。
defaultNetwork パラメーターのパラメーター値を CNO CR に設定することにより、OpenShift Container Platform クラスターのクラスターネットワーク設定を指定できます。以下の CR は、CNO のデフォルト設定を表示し、設定可能なパラメーターと有効なパラメーターの値の両方について説明しています。
Cluster Network Operator CR
- 1
- Pod ID アドレスの割り当て、サブネット接頭辞の長さの個別ノードへの割り当てに使用される IP アドレスのブロックを指定する一覧です。
- 2
- サービスの IP アドレスのブロック。OpenShift SDN Container Network Interface (CNI) ネットワークプロバイダーは、サービスネットワークの単一 IP アドレスブロックのみをサポートします。
- 3
- クラスターネットワークのデフォルトの CNI ネットワークプロバイダーを設定します。
- 4
- このオブジェクトのパラメーターは、Kubernetes ネットワークプロキシー (kube-proxy) 設定を指定します。OVN-Kubernetes デフォルト CNI ネットワークプロバイダーを使用している場合、kube-proxy 設定は機能しません。
- 5
iptablesルールの更新期間。デフォルト値は30sです。有効な接尾辞には、s、m、およびhなどが含まれ、これらについては、Go Package time ドキュメントで説明されています。注記OpenShift Container Platform 4.3 以降で強化されたパフォーマンスの向上により、
iptablesSyncPeriodパラメーターを調整する必要はなくなりました。- 6
iptablesルールを更新する前の最小期間。このパラメーターにより、更新の頻度が高くなり過ぎないようにできます。有効な接尾辞には、s、m、およびhなどが含まれ、これらについては、Go Package time で説明されています。
3.5.1. OpenShift SDN デフォルト CNI ネットワークプロバイダーの設定パラメーター リンクのコピーリンクがクリップボードにコピーされました!
以下の YAML オブジェクトは、OpenShift SDN デフォルト Container Network Interface (CNI) ネットワークプロバイダーの設定パラメーターについて説明しています。
クラスターのインストール時にのみデフォルト CNI ネットワークプロバイダーの設定を変更することができます。
3.5.2. OVN-Kubernetes デフォルト CNI ネットワークプロバイダーの設定パラメーター リンクのコピーリンクがクリップボードにコピーされました!
以下の YAML オブジェクトは OVN-Kubernetes デフォルト CNI ネットワークプロバイダーの設定パラメーターについて説明しています。
クラスターのインストール時にのみデフォルト CNI ネットワークプロバイダーの設定を変更することができます。
defaultNetwork:
type: OVNKubernetes
ovnKubernetesConfig:
mtu: 1400
genevePort: 6081
defaultNetwork:
type: OVNKubernetes
ovnKubernetesConfig:
mtu: 1400
genevePort: 6081
3.5.3. Cluster Network Operator の設定例 リンクのコピーリンクがクリップボードにコピーされました!
以下の例のように、CNO の完全な CR オブジェクトが表示されます。
Cluster Network Operator のサンプル CR
第4章 OpenShift Container Platform の DNS Operator リンクのコピーリンクがクリップボードにコピーされました!
DNS Operator は、Pod に対して名前解決サービスを提供するために CoreDNS をデプロイし、これを管理し、OpenShift 内での 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
$ oc get -n openshift-dns-operator deployment/dns-operatorCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME READY UP-TO-DATE AVAILABLE AGE dns-operator 1/1 1 1 23h
NAME READY UP-TO-DATE AVAILABLE AGE dns-operator 1/1 1 1 23hCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc getコマンドを使用して DNS Operator の状態を表示します。oc get clusteroperator/dns
$ oc get clusteroperator/dnsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE dns 4.1.0-0.11 True False False 92m
NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE dns 4.1.0-0.11 True False False 92mCopy to Clipboard Copied! Toggle word wrap Toggle overflow AVAILABLE、PROGRESSINGおよびDEGRADEDは、Operator のステータスについての情報を提供します。AVAILABLEは、CoreDNS デーモンセットからの 1 つ以上の Pod がAvailableステータス条件を報告する場合はTrueになります。
4.2. デフォルト DNS の表示 リンクのコピーリンクがクリップボードにコピーされました!
すべての新規 OpenShift Container Platform インストールには、default という名前の dns.operator があります。
手順
oc describeコマンドを使用してデフォルトのdnsを表示します。oc describe dns.operator/default
$ oc describe dns.operator/defaultCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow クラスターのサービス CIDR を見つけるには、
oc getコマンドを使用します。oc get networks.config/cluster -o jsonpath='{$.status.serviceNetwork}'$ oc get networks.config/cluster -o jsonpath='{$.status.serviceNetwork}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow
出力例
[172.30.0.0/16]
[172.30.0.0/16]
4.3. DNS 転送の使用 リンクのコピーリンクがクリップボードにコピーされました!
DNS 転送を使用すると、指定のゾーンにどのネームサーバーを使用するかを指定することで、ゾーンごとに etc/resolv.conf で特定される転送設定をオーバーライドできます。
手順
defaultという名前の DNS Operator オブジェクトを変更します。oc edit dns.operator/default
$ oc edit dns.operator/defaultCopy to Clipboard Copied! Toggle word wrap Toggle overflow これにより、
Serverに基づく追加のサーバー設定ブロックを使用してdns-defaultという名前の ConfigMap を作成し、更新できます。クエリーに一致するゾーンを持つサーバーがない場合、名前解決は/etc/resolv.confで指定されたネームサーバーにフォールバックします。DNS の例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記serversが定義されていないか、または無効な場合、ConfigMap にはデフォルトサーバーのみが含まれます。ConfigMap を表示します。
oc get configmap/dns-default -n openshift-dns -o yaml
$ oc get configmap/dns-default -n openshift-dns -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以前のサンプル DNS に基づく DNS ConfigMap の例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
forwardPluginへの変更により、CoreDNS デーモンセットのローリング更新がトリガーされます。
関連情報
- DNS 転送の詳細は、CoreDNS forward のドキュメント を参照してください。
4.4. DNS Operator のステータス リンクのコピーリンクがクリップボードにコピーされました!
oc describe コマンドを使用して、DNS Operator のステータスを検査し、その詳細を表示することができます。
手順
DNS Operator のステータスを表示します。
oc describe clusteroperators/dns
$ oc describe clusteroperators/dns
4.5. DNS Operator ログ リンクのコピーリンクがクリップボードにコピーされました!
oc logs コマンドを使用して、DNS Operator ログを表示できます。
手順
DNS Operator のログを表示します。
oc logs -n openshift-dns-operator deployment/dns-operator -c dns-operator
$ oc logs -n openshift-dns-operator deployment/dns-operator -c dns-operator
第5章 ベアメタルクラスターでの SCTP (Stream Control Transmission Protocol) の使用 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、クラスターで SCTP (Stream Control Transmission Protocol) を使用できます。
5.1. OpenShift Container Platform での SCTP (Stream Control Transmission Protocol) のサポート リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、クラスターのホストで SCTP を有効にできます。{op-system-first} では、SCTP モジュールはデフォルトで無効になっています。
SCTP は、IP ネットワークの上部で実行される信頼できるメッセージベースのプロトコルです。
これを有効にすると、SCTP を Pod、サービス、およびネットワークポリシーでプロトコルとして使用できます。Service オブジェクトは、type パラメーターを ClusterIP または NodePort のいずれかの値に設定して定義する必要があります。
5.1.1. SCTP プロトコルを使用した設定例 リンクのコピーリンクがクリップボードにコピーされました!
protocol パラメーターを Pod またはサービスリソース定義の SCTP 値に設定して、Pod またはサービスを SCTP を使用するように設定できます。
以下の例では、Pod は SCTP を使用するように設定されています。
以下の例では、サービスは SCTP を使用するように設定されています。
以下の例では、NetworkPolicy オブジェクトは、特定のラベルの付いた Pod からポート 80 の SCTP ネットワークトラフィックに適用するように設定されます。
5.2. SCTP (Stream Control Transmission Protocol) の有効化 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、クラスターのワーカーノードでブラックリストに指定した SCTP カーネルモジュールを読み込み、有効にできます。
前提条件
-
OpenShift CLI (
oc) をインストールしている。 -
cluster-adminロールを持つユーザーとしてクラスターにアクセスできる。
手順
以下の YAML 定義が含まれる
load-sctp-module.yamlという名前のファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow MachineConfigオブジェクトを作成するには、以下のコマンドを入力します。oc create -f load-sctp-module.yaml
$ oc create -f load-sctp-module.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow オプション: MachineConfig Operator が設定変更を適用している間にノードのステータスを確認するには、以下のコマンドを入力します。ノードのステータスが
Readyに移行すると、設定の更新が適用されます。oc get nodes
$ oc get nodesCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.3. SCTP (Stream Control Transmission Protocol) が有効になっていることの確認 リンクのコピーリンクがクリップボードにコピーされました!
SCTP がクラスターで機能することを確認するには、SCTP トラフィックをリッスンするアプリケーションで Pod を作成し、これをサービスに関連付け、公開されたサービスに接続します。
前提条件
-
クラスターからインターネットにアクセスし、
ncパッケージをインストールすること。 -
OpenShift CLI (
oc) をインストールします。 -
cluster-adminロールを持つユーザーとしてクラスターにアクセスできる。
手順
SCTP リスナーを起動する Pod を作成します。
以下の YAML で Pod を定義する
sctp-server.yamlという名前のファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを入力して Pod を作成します。
oc create -f sctp-server.yaml
$ oc create -f sctp-server.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
SCTP リスナー Pod のサービスを作成します。
以下の YAML でサービスを定義する
sctp-service.yamlという名前のファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow サービスを作成するには、以下のコマンドを入力します。
oc create -f sctp-service.yaml
$ oc create -f sctp-service.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
SCTP クライアントの Pod を作成します。
以下の YAML で
sctp-client.yamlという名前のファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow Podオブジェクトを作成するには、以下のコマンドを入力します。oc apply -f sctp-client.yaml
$ oc apply -f sctp-client.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
サーバーで SCTP リスナーを実行します。
サーバー Pod に接続するには、以下のコマンドを入力します。
oc rsh sctpserver
$ oc rsh sctpserverCopy to Clipboard Copied! Toggle word wrap Toggle overflow SCTP リスナーを起動するには、以下のコマンドを入力します。
nc -l 30102 --sctp
$ nc -l 30102 --sctpCopy to Clipboard Copied! Toggle word wrap Toggle overflow
サーバーの SCTP リスナーに接続します。
- ターミナルプログラムで新規のターミナルウィンドウまたはタブを開きます。
sctpserviceサービスの IP アドレスを取得します。以下のコマンドを入力します。oc get services sctpservice -o go-template='{{.spec.clusterIP}}{{"\n"}}'$ oc get services sctpservice -o go-template='{{.spec.clusterIP}}{{"\n"}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow クライアント Pod に接続するには、以下のコマンドを入力します。
oc rsh sctpclient
$ oc rsh sctpclientCopy to Clipboard Copied! Toggle word wrap Toggle overflow SCTP クライアントを起動するには、以下のコマンドを入力します。
<cluster_IP>をsctpserviceサービスのクラスター IP アドレスに置き換えます。nc <cluster_IP> 30102 --sctp
# nc <cluster_IP> 30102 --sctpCopy to Clipboard Copied! Toggle word wrap Toggle overflow
第6章 ネットワークポリシー リンクのコピーリンクがクリップボードにコピーされました!
6.1. ネットワークポリシーについて リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、トラフィックをクラスター内の Pod に制限するネットワークポリシーを定義できます。
6.1.1. ネットワークポリシーについて リンクのコピーリンクがクリップボードにコピーされました!
Kubernetes ネットワークポリシーをサポートする Kubernetes Container Network Interface (CNI) プラグインを使用するクラスターでは、ネットワークの分離は NetworkPolicy オブジェクトによって完全に制御されます。OpenShift Container Platform 4.4 では、OpenShift SDN はデフォルトのネットワーク分離モードでのネットワークポリシーの使用をサポートしています。
Kubernetes v1 ネットワークポリシー機能は、egress ポリシータイプおよび IPBlock 以外は OpenShift Container Platform で利用できます。
ネットワークポリシーは、ホストのネットワーク namespace には適用されません。ホストネットワークが有効にされている Pod はネットワークポリシールールによる影響を受けません。
デフォルトで、プロジェクトのすべての Pod は他の Pod およびネットワークのエンドポイントからアクセスできます。プロジェクトで 1 つ以上の Pod を分離するには、そのプロジェクトで NetworkPolicy オブジェクトを作成し、許可する着信接続を指定します。プロジェクト管理者は独自のプロジェクト内で NetworkPolicy オブジェクトの作成および削除を実行できます。
Pod が 1 つ以上の NetworkPolicy オブジェクトのセレクターで一致する場合、Pod はそれらの 1 つ以上の NetworkPolicy オブジェクトで許可される接続のみを受け入れます。NetworkPolicy オブジェクトによって選択されていない Pod は完全にアクセス可能です。
以下のサンプル NetworkPolicy オブジェクトは、複数の異なるシナリオをサポートすることを示しています。
すべてのトラフィックを拒否します。
プロジェクトに deny by default (デフォルトで拒否) を実行させるには、すべての Pod に一致するが、トラフィックを一切許可しない
NetworkPolicyオブジェクトを追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow OpenShift Container Platform Ingress コントローラーからの接続のみを許可します。
プロジェクトで OpenShift Container Platform Ingress コントローラーからの接続のみを許可するには、以下の
NetworkPolicyオブジェクトを追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow Ingress コントローラーが
endpointPublishingStrategy: HostNetworkで設定されている場合、Ingress コントローラー Pod はホストネットワーク上で実行されます。ホストネットワーク上で実行されている場合、Ingress コントローラーからのトラフィックにnetid:0Virtual Network ID (VNID) が割り当てられます。Ingress Operator に関連付けられる namespace のnetidは異なるため、allow-from-openshift-ingressネットワークポリシーのmatchLabelはdefaultIngress コントローラーからのトラフィックに一致しません。defaultnamespace にはnetid:0VNID が割り当てられるため、defaultnamespace にnetwork.openshift.io/policy-group: ingressでラベルを付けて、defaultIngress コントローラーからのトラフィックを許可できます。プロジェクト内の Pod からの接続のみを受け入れます。
Pod が同じプロジェクト内の他の Pod からの接続を受け入れるが、他のプロジェクトの Pod からの接続を拒否するように設定するには、以下の
NetworkPolicyオブジェクトを追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow Pod ラベルに基づいて HTTP および HTTPS トラフィックのみを許可します。
特定のラベル (以下の例の
role=frontend) の付いた Pod への HTTP および HTTPS アクセスのみを有効にするには、以下と同様のNetworkPolicyオブジェクトを追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow namespace および Pod セレクターの両方を使用して接続を受け入れます。
namespace と Pod セレクターを組み合わせてネットワークトラフィックのマッチングをするには、以下と同様の
NetworkPolicyオブジェクトを使用できます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
NetworkPolicy オブジェクトは加算されるものです。 つまり、複数の NetworkPolicy オブジェクトを組み合わせて複雑なネットワーク要件を満すことができます。
たとえば、先の例で定義された NetworkPolicy オブジェクトの場合、同じプロジェト内に allow-same-namespace と allow-http-and-https ポリシーの両方を定義することができます。これにより、ラベル role=frontend の付いた Pod は各ポリシーで許可されるすべての接続を受け入れます。つまり、同じ namespace の Pod からのすべてのポート、およびすべての namespace の Pod からのポート 80 および 443 での接続を受け入れます。
6.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 から許可する必要のある特定のトラフィックを可能にします。
6.1.3. 次のステップ リンクのコピーリンクがクリップボードにコピーされました!
- ネットワークポリシーの作成
- オプション: デフォルトネットワークポリシーの定義
6.1.4. 追加リソース リンクのコピーリンクがクリップボードにコピーされました!
6.2. ネットワークポリシーの作成 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、namespace のネットワークポリシーを作成できます。
6.2.1. ネットワークポリシーの作成 リンクのコピーリンクがクリップボードにコピーされました!
クラスターのプロジェクトに許可される Ingress ネットワークトラフィックを記述する詳細なルールを定義するには、ネットワークポリシーを作成できます。
前提条件
-
クラスターは、
NetworkPolicyオブジェクトをサポートするデフォルトの CNI ネットワークプロバイダーを使用している (例:mode: NetworkPolicyが設定された OpenShift SDN ネットワークプロバイダー)。このモードは OpenShiftSDN のデフォルトです。 -
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてクラスターにログインしていること。
手順
ポリシールールを作成します。
-
<policy-name>.yamlファイルを作成します。<policy-name>はポリシールールを記述します。 作成したばかりのファイルで、以下の例のようなポリシーオブジェクトを定義します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- ポリシーオブジェクトの名前を指定します。
-
以下のコマンドを実行してポリシーオブジェクトを作成します。
oc create -f <policy-name>.yaml -n <project>
$ oc create -f <policy-name>.yaml -n <project>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下の例では、新規
NetworkPolicyオブジェクトがproject1という名前のプロジェクトに作成されます。oc create -f default-deny.yaml -n project1
$ oc create -f default-deny.yaml -n project1Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
networkpolicy "default-deny" created
networkpolicy "default-deny" createdCopy to Clipboard Copied! Toggle word wrap Toggle overflow
6.2.2. サンプル NetworkPolicy オブジェクト リンクのコピーリンクがクリップボードにコピーされました!
以下は、サンプル NetworkPolicy オブジェクトにアノテーションを付けます。
6.3. ネットワークポリシーの表示 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、namespace のネットワークポリシーを表示できます。
6.3.1. ネットワークポリシーの表示 リンクのコピーリンクがクリップボードにコピーされました!
クラスターのネットワークポリシーを一覧表示できます。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてクラスターにログインしていること。
手順
クラスターで定義された
NetworkPolicyオブジェクトを表示するには、以下のコマンドを実行します。oc get networkpolicy
$ oc get networkpolicyCopy to Clipboard Copied! Toggle word wrap Toggle overflow
6.3.2. サンプル NetworkPolicy オブジェクト リンクのコピーリンクがクリップボードにコピーされました!
以下は、サンプル NetworkPolicy オブジェクトにアノテーションを付けます。
6.4. ネットワークポリシーの編集 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、namespace の既存のネットワークポリシーを編集できます。
6.4.1. ネットワークポリシーの編集 リンクのコピーリンクがクリップボードにコピーされました!
namespace のネットワークポリシーを編集できます。
前提条件
-
クラスターは、
NetworkPolicyオブジェクトをサポートするデフォルトの CNI ネットワークプロバイダーを使用している (例:mode: NetworkPolicyが設定された OpenShift SDN ネットワークプロバイダー)。このモードは OpenShiftSDN のデフォルトです。 -
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてクラスターにログインしていること。
手順
オプション: 現在の
NetworkPolicyオブジェクトを一覧表示します。特定の namespace のポリシーオブジェクトを一覧表示するには、以下のコマンドを入力します。
<namespace>をプロジェクトの namespace に置き換えます。oc get networkpolicy -n <namespace>
$ oc get networkpolicy -n <namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow クラスター全体についてのポリシーオブジェクトを一覧表示するには、以下のコマンドを入力します。
oc get networkpolicy --all-namespaces
$ oc get networkpolicy --all-namespacesCopy to Clipboard Copied! Toggle word wrap Toggle overflow
NetworkPolicyオブジェクトを編集します。ネットワークポリシーの定義をファイルに保存した場合は、ファイルを編集して必要な変更を加えてから、以下のコマンドを入力します。
<policy-file>を、オブジェクト定義が含まれるファイルの名前に置き換えます。oc apply -f <policy-file>.yaml
$ oc apply -f <policy-file>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow NetworkPolicyオブジェクトを直接更新する必要がある場合、以下のコマンドを入力できます。<policy-name>をNetworkPolicyオブジェクトの名前に置き換え、<namespace>をオブジェクトが存在するプロジェクトの名前に置き換えます。oc edit <policy-name> -n <namespace>
$ oc edit <policy-name> -n <namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
NetworkPolicyオブジェクトが更新されていることを確認します。<namespace>をオブジェクトが存在するプロジェクトの名前に置き換えます。oc get networkpolicy -n <namespace> -o yaml
$ oc get networkpolicy -n <namespace> -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
6.4.2. サンプル NetworkPolicy オブジェクト リンクのコピーリンクがクリップボードにコピーされました!
以下は、サンプル NetworkPolicy オブジェクトにアノテーションを付けます。
6.4.3. 関連情報 リンクのコピーリンクがクリップボードにコピーされました!
6.5. ネットワークポリシーの削除 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、namespace からネットワークポリシーを削除できます。
6.5.1. ネットワークポリシーの削除 リンクのコピーリンクがクリップボードにコピーされました!
ネットワークポリシーを削除することができます。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてクラスターにログインしていること。
手順
NetworkPolicyオブジェクトを削除するには、以下のコマンドを入力します。<policy-name>をオブジェクトの名前に置き換えます。oc delete networkpolicy <policy-name>
$ oc delete networkpolicy <policy-name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
6.6. 新規プロジェクトのデフォルトネットワークポリシーの作成 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、新規プロジェクトの作成時にネットワークポリシーを自動的に含めるように新規プロジェクトテンプレートを変更できます。新規プロジェクトのカスタマイズされたテンプレートがまだない場合には、まずテンプレートを作成する必要があります。
6.6.1. 新規プロジェクトのテンプレートの変更 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、デフォルトのプロジェクトテンプレートを変更し、新規プロジェクトをカスタム要件に基づいて作成することができます。
独自のカスタムプロジェクトテンプレートを作成するには、以下を実行します。
手順
-
cluster-admin権限を持つユーザーとしてログインしている。 デフォルトのプロジェクトテンプレートを生成します。
oc adm create-bootstrap-project-template -o yaml > template.yaml
$ oc adm create-bootstrap-project-template -o yaml > template.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
オブジェクトを追加するか、または既存オブジェクトを変更することにより、テキストエディターで生成される
template.yamlファイルを変更します。 プロジェクトテンプレートは、
openshift-confignamespace に作成される必要があります。変更したテンプレートを読み込みます。oc create -f template.yaml -n openshift-config
$ oc create -f template.yaml -n openshift-configCopy to Clipboard Copied! Toggle word wrap Toggle overflow Web コンソールまたは CLI を使用し、プロジェクト設定リソースを編集します。
Web コンソールの使用
- Administration → Cluster Settings ページに移動します。
- Global Configuration をクリックし、すべての設定リソースを表示します。
- Project のエントリーを見つけ、Edit YAML をクリックします。
CLI の使用
project.config.openshift.io/clusterリソースを編集します。oc edit project.config.openshift.io/cluster
$ oc edit project.config.openshift.io/clusterCopy to Clipboard Copied! Toggle word wrap Toggle overflow
specセクションを、projectRequestTemplateおよびnameパラメーターを組み込むように更新し、アップロードされたプロジェクトテンプレートの名前を設定します。デフォルト名はproject-requestです。カスタムプロジェクトテンプレートを含むプロジェクト設定リソース
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 変更を保存した後、変更が正常に適用されたことを確認するために、新しいプロジェクトを作成します。
6.6.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
$ oc edit template <project_template> -n openshift-configCopy to Clipboard Copied! Toggle word wrap Toggle overflow <project_template>を、クラスターに設定したデフォルトテンプレートの名前に置き換えます。デフォルトのテンプレート名はproject-requestです。テンプレートでは、各
NetworkPolicyオブジェクトを要素としてobjectsパラメーターに追加します。objectsパラメーターは、1 つ以上のオブジェクトのコレクションを受け入れます。以下の例では、
objectsパラメーターのコレクションにいくつかのNetworkPolicyオブジェクトが含まれます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow オプション: 以下のコマンドを実行して、新規プロジェクトを作成し、ネットワークポリシーオブジェクトが正常に作成されることを確認します。
新規プロジェクトを作成します。
oc new-project <project>
$ oc new-project <project>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<project>を、作成しているプロジェクトの名前に置き換えます。
新規プロジェクトテンプレートのネットワークポリシーオブジェクトが新規プロジェクトに存在することを確認します。
oc get networkpolicy
$ oc get networkpolicy NAME POD-SELECTOR AGE allow-from-openshift-ingress <none> 7s allow-from-same-namespace <none> 7sCopy to Clipboard Copied! Toggle word wrap Toggle overflow
6.7. ネットワークポリシーを使用したマルチテナントモードの設定 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、マルチテナントネットワークの分離を実行するようにネットワークポリシーを設定できます。
6.7.1. ネットワークポリシーを使用したマルチテナント分離の設定 リンクのコピーリンクがクリップボードにコピーされました!
他のプロジェクト namespace の Pod およびサービスから分離できるようにプロジェクトを設定できます。
前提条件
-
クラスターは、
NetworkPolicyオブジェクトをサポートするデフォルトの CNI ネットワークプロバイダーを使用している (例:mode: NetworkPolicyが設定された OpenShift SDN ネットワークプロバイダー)。このモードは OpenShiftSDN のデフォルトです。 -
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてクラスターにログインしていること。
手順
以下の
NetworkPolicyオブジェクトを作成します。allow-from-openshift-ingressという名前のポリシー:Copy to Clipboard Copied! Toggle word wrap Toggle overflow allow-from-openshift-monitoringという名前のポリシー。Copy to Clipboard Copied! Toggle word wrap Toggle overflow allow-same-namespaceという名前のポリシー:Copy to Clipboard Copied! Toggle word wrap Toggle overflow
defaultIngress コントローラー設定にspec.endpointPublishingStrategy: HostNetworkの値が設定されている場合、ラベルをdefaultOpenShift Container Platform namespace に適用し、Ingress コントローラーとプロジェクト間のネットワークトラフィックを許可する必要があります。defaultIngress コントローラーがHostNetworkエンドポイント公開ストラテジーを使用するかどうかを判別します。oc get --namespace openshift-ingress-operator ingresscontrollers/default \ --output jsonpath='{.status.endpointPublishingStrategy.type}'$ oc get --namespace openshift-ingress-operator ingresscontrollers/default \ --output jsonpath='{.status.endpointPublishingStrategy.type}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 直前のコマンドによりエンドポイント公開ストラテジーが
HostNetworkとして報告される場合には、defaultnamespace にラベルを設定します。oc label namespace default 'network.openshift.io/policy-group=ingress'
$ oc label namespace default 'network.openshift.io/policy-group=ingress'Copy to Clipboard Copied! Toggle word wrap Toggle overflow
以下のコマンドを実行し、
NetworkPolicyオブジェクトが現在のプロジェクトに存在することを確認します。oc get networkpolicy <policy-name> -o yaml
$ oc get networkpolicy <policy-name> -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下の例では、
allow-from-openshift-ingressNetworkPolicyオブジェクトが表示されています。oc get -n project1 networkpolicy allow-from-openshift-ingress -o yaml
$ oc get -n project1 networkpolicy allow-from-openshift-ingress -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
6.7.2. 次のステップ リンクのコピーリンクがクリップボードにコピーされました!
第7章 複数ネットワーク リンクのコピーリンクがクリップボードにコピーされました!
7.1. 複数ネットワークについて リンクのコピーリンクがクリップボードにコピーされました!
Kubernetes では、コンテナーネットワークは Container Network Interface (CNI) を実装するネットワークプラグインに委任されます。
OpenShift Container Platform は、Multus CNI プラグインを使用して CNI プラグインのチェーンを許可します。クラスターのインストール時に、デフォルト の Pod ネットワークを設定します。デフォルトのネットワークは、クラスターのすべての通常のネットワークトラフィックを処理します。利用可能な CNI プラグインに基づいて 追加のネットワーク を定義し、1 つまたは複数のネットワークを Pod に割り当てることができます。必要に応じて、クラスターの複数のネットワークを追加で定義することができます。これは、スイッチまたはルーティングなどのネットワーク機能を提供する Pod を設定する場合に柔軟性を実現します。
7.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 設定は、インターフェイスの作成方法を定義します。
7.1.2. OpenShift Container Platform の追加ネットワーク リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform は、クラスターに追加のネットワークを作成するために使用する以下の CNI プラグインを提供します。
- bridge: ブリッジベースの追加ネットワークを作成する ことで、同じホストにある Pod が相互に、かつホストと通信できます。
- host-device: ホストデバイスの追加ネットワークを作成する ことで、Pod がホストシステム上の物理イーサネットネットワークデバイスにアクセスすることができます。
- macvlan: macvlan ベースの追加ネットワークを作成 することで、ホスト上の Pod が物理ネットワークインターフェイスを使用して他のホストやそれらのホストの Pod と通信できます。macvlan ベースの追加ネットワークに割り当てられる各 Pod には固有の MAC アドレスが割り当てられます。
- ipvlan: ipvlan ベースの追加ネットワークを作成する ことで、macvlan ベースの追加ネットワークと同様に、ホスト上の Pod が他のホストやそれらのホストの Pod と通信できます。macvlan ベースの追加のネットワークとは異なり、各 Pod は親の物理ネットワークインターフェイスと同じ MAC アドレスを共有します。
- SR-IOV: SR-IOV ベースの追加ネットワークを作成する ことで、Pod を ホストシステム上の SR-IOV 対応ハードウェアの仮想機能 (VF) インターフェイスに割り当てることができます。
7.2. Pod の追加のネットワークへの割り当て リンクのコピーリンクがクリップボードにコピーされました!
クラスターユーザーとして、Pod を追加のネットワークに割り当てることができます。
7.2.1. Pod の追加ネットワークへの追加 リンクのコピーリンクがクリップボードにコピーされました!
Pod を追加のネットワークに追加できます。Pod は、デフォルトネットワークで通常のクラスター関連のネットワークトラフィックを継続的に送信します。
Pod が作成されると、追加のネットワークが割り当てられます。ただし、Pod がすでに存在する場合は、追加のネットワークをこれに割り当てることはできません。
Pod が追加ネットワークと同じ namespace にあること。
前提条件
-
OpenShift CLI (
oc) をインストールしている。 - クラスターにログインする。
手順
アノテーションを
Podオブジェクトに追加します。以下のアノテーション形式のいずれかのみを使用できます。カスタマイズせずに追加ネットワークを割り当てるには、以下の形式でアノテーションを追加します。
<network>を、Pod に関連付ける追加ネットワークの名前に置き換えます。metadata: annotations: k8s.v1.cni.cncf.io/networks: <network>[,<network>,...]metadata: annotations: k8s.v1.cni.cncf.io/networks: <network>[,<network>,...]1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 複数の追加ネットワークを指定するには、各ネットワークをコンマで区切ります。コンマの間にはスペースを入れないでください。同じ追加ネットワークを複数回指定した場合、Pod は複数のネットワークインターフェイスをそのネットワークに割り当てます。
カスタマイズして追加のネットワークを割り当てるには、以下の形式でアノテーションを追加します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Pod を作成するには、以下のコマンドを入力します。
<name>を Pod の名前に置き換えます。oc create -f <name>.yaml
$ oc create -f <name>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow オプション: アノテーションが
PodCR に存在することを確認するには、<name>を Pod の名前に置き換えて、以下のコマンドを入力します。oc get pod <name> -o yaml
$ oc get pod <name> -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下の例では、
example-podPod が追加ネットワークのnet1に割り当てられています。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
k8s.v1.cni.cncf.io/networks-statusパラメーターは、オブジェクトの JSON 配列です。各オブジェクトは、Pod に割り当てられる追加のネットワークのステータスについて説明します。アノテーションの値はプレーンテキストの値として保存されます。
7.2.1.1. Pod 固有のアドレスおよびルーティングオプションの指定 リンクのコピーリンクがクリップボードにコピーされました!
Pod を追加のネットワークに割り当てる場合、特定の Pod でそのネットワークに関するその他のプロパティーを指定する必要がある場合があります。これにより、ルーティングの一部を変更することができ、静的 IP アドレスおよび MAC アドレスを指定できます。これを実行するには、JSON 形式のアノテーションを使用できます。
前提条件
- Pod が追加ネットワークと同じ namespace にあること。
-
OpenShift コマンドラインインターフェイス (
oc) のインストール。 - クラスターにログインすること。
手順
アドレスおよび/またはルーティングオプションを指定する間に Pod を追加のネットワークに追加するには、以下の手順を実行します。
Podリソース定義を編集します。既存のPodリソースを編集する場合は、以下のコマンドを実行してデフォルトエディターでその定義を編集します。<name>を、編集するPodリソースの名前に置き換えます。oc edit pod <name>
$ oc edit pod <name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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>,...]]'metadata: annotations: k8s.v1.cni.cncf.io/networks: '[<network>[,<network>,...]]'1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<network>を、以下の例にあるように JSON オブジェクトに置き換えます。一重引用符が必要です。
以下の例では、アノテーションで
default-routeパラメーターを使用して、デフォルトルートを持つネットワーク割り当てを指定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
デフォルトのルートにより、他のルートに指定されていないトラフィックがゲートウェイにルーティングされます。
OpenShift Container Platform のデフォルトのネットワークインターフェイス以外のインターフェイスへのデフォルトのルートを設定すると、Pod 間のトラフィックについて予想されるトラフィックが別のインターフェイスでルーティングされる可能性があります。
Pod のルーティングプロパティーを確認する場合、oc コマンドを Pod 内で ip コマンドを実行するために使用できます。
oc exec -it <pod_name> -- ip route
$ 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
$ oc edit networks.operator.openshift.io clusterCopy to Clipboard Copied! Toggle word wrap Toggle overflow
以下の YAML は、CNO の設定パラメーターについて説明しています。
Cluster Network Operator YAML の設定
以下のオブジェクトは、macvlan CNI プラグインを使用して静的 MAC アドレスと IP アドレスを使用するための設定パラメーターについて説明しています。
静的 IP および MAC アドレスを使用した macvlan CNI プラグイン JSON 設定オブジェクト
上記のネットワーク割り当ては、特定の Pod に割り当てられる静的 IP アドレスと MAC アドレスを指定するキーと共に、JSON 形式のアノテーションで参照できます。
以下を実行して必要な Pod を編集します。
oc edit pod <name>
$ oc edit pod <name>
静的 IP および MAC アドレスを使用した macvlan CNI プラグイン JSON 設定オブジェクト
静的 IP アドレスおよび MAC アドレスを同時に使用することはできません。これらは個別に使用することも、一緒に使用することもできます。
追加のネットワークを持つ Pod の IP アドレスと MAC プロパティーを検証するには、oc コマンドを使用して Pod 内で ip コマンドを実行します。
oc exec -it <pod_name> -- ip a
$ oc exec -it <pod_name> -- ip a
7.3. 追加ネットワークからの Pod の削除 リンクのコピーリンクがクリップボードにコピーされました!
クラスターユーザーとして、追加のネットワークから Pod を削除できます。
7.3.1. 追加ネットワークからの Pod の削除 リンクのコピーリンクがクリップボードにコピーされました!
Pod を削除するだけで、追加のネットワークから Pod を削除できます。
前提条件
- 追加のネットワークが Pod に割り当てられている。
-
OpenShift CLI (
oc) をインストールしている。 - クラスターにログインする。
手順
Pod を削除するには、以下のコマンドを入力します。
oc delete pod <name> -n <namespace>
$ oc delete pod <name> -n <namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
<name>は Pod の名前です。 -
<namespace>は Pod が含まれる namespace です。
-
7.4. ブリッジネットワークの設定 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、ブリッジの Container Network Interface (CNI) プラグインを使用して、クラスターの追加ネットワークを設定できます。設定時に、ノード上のすべての Pod が仮想スイッチに接続されます。各 Pod には追加のネットワークの IP アドレスが割り当てられます。
7.4.1. ブリッジ CNI プラグインを使用した追加ネットワーク割り当ての作成 リンクのコピーリンクがクリップボードにコピーされました!
Cluster Network Operator (CNO) は追加ネットワークの定義を管理します。作成する追加ネットワークを指定する場合、CNO は NetworkAttachmentDefinition オブジェクトを自動的に作成します。
Cluster Network Operator が管理する NetworkAttachmentDefinition オブジェクトは編集しないでください。これを実行すると、追加ネットワークのネットワークトラフィックが中断する可能性があります。
前提条件
-
OpenShift CLI (
oc) をインストールしている。 -
cluster-admin権限を持つユーザーとしてログインしている。
手順
クラスターの追加ネットワークを作成するには、以下の手順を実施します。
以下のコマンドを実行して CNO CR を編集します。
oc edit networks.operator.openshift.io cluster
$ oc edit networks.operator.openshift.io clusterCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のサンプル CR のように、作成される追加ネットワークの設定を追加して、作成している CR を変更します。
以下の YAML はブリッジ CNI プラグインを設定します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 追加ネットワーク割り当て定義の設定を指定します。
- 変更を保存し、テキストエディターを終了して、変更をコミットします。
オプション: 以下のコマンドを実行して、CNO が
NetworkAttachmentDefinitionオブジェクトを作成していることを確認します。CNO が CR を作成するまでに遅延が生じる可能性があります。oc get network-attachment-definitions -n <namespace>
$ oc get network-attachment-definitions -n <namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME AGE test-network-1 14m
NAME AGE test-network-1 14mCopy to Clipboard Copied! Toggle word wrap Toggle overflow
7.4.1.1. ブリッジの設定 リンクのコピーリンクがクリップボードにコピーされました!
ブリッジ Container Network Interface (CNI) プラグインを使用する追加ネットワーク割り当ての設定は、以下の 2 つの部分に分けて提供されます。
- Cluster Network Operator (CNO) の設定
- CNI プラグインの設定
CNO 設定では、追加ネットワーク割り当ての名前と割り当てを作成する namespace を指定します。このプラグインは、CNO 設定の rawCNIConfig パラメーターで指定される JSON オブジェクトで設定されます。
以下の YAML は、CNO の設定パラメーターについて説明しています。
Cluster Network Operator YAML の設定
以下のオブジェクトは、ブリッジ CNI プラグインの設定パラメーターについて説明しています。
ブリッジ CNI プラグイン JSON 設定オブジェクト
- 1
- CNO 設定に以前に指定した
nameパラメーターの値を指定します。 - 2
- 使用する仮想ブリッジの名前を指定します。ブリッジインターフェイスがホストに存在しない場合は、これが作成されます。デフォルト値は
cni0です。 - 3
- IPAM CNI プラグインの設定オブジェクトを指定します。プラグインは、ネットワーク割り当て定義についての IP アドレスの割り当てを管理します。
- 4
- 仮想ネットワークから外すトラフィックについて IP マスカレードを有効にするには、
trueに設定します。すべてのトラフィックのソース IP アドレスは、ブリッジの IP アドレスに書き換えられます。ブリッジに IP アドレスがない場合は、この設定は影響を与えません。デフォルト値はfalseです。 - 5
- IP アドレスをブリッジに割り当てるには
trueに設定します。デフォルト値はfalseです。 - 6
- ブリッジを仮想ネットワークのデフォルトゲートウェイとして設定するには、
trueに設定します。デフォルト値はfalseです。isDefaultGatewayがtrueに設定される場合、isGatewayも自動的にtrueに設定されます。 - 7
- 仮想ブリッジの事前に割り当てられた IP アドレスの割り当てを許可するには、
trueに設定します。falseに設定される場合、重複サブセットの IPv4 アドレスまたは IPv6 アドレスが仮想ブリッジに割り当てられるとエラーが発生します。デフォルト値はfalseです。 - 8
- 仮想ブリッジが受信時に使用した仮想ポートでイーサネットフレームを送信できるようにするには、
trueに設定します。このモードは、Reflective Relay (リフレクティブリレー) としても知られています。デフォルト値はfalseです。 - 9
- ブリッジで無作為検出モード (Promiscuous Mode) を有効にするには、
trueに設定します。デフォルト値はfalseです。 - 10
- 仮想 LAN (VLAN) タグを整数値として指定します。デフォルトで、VLAN タグは割り当てません。
- 11
- 最大転送単位 (MTU) を指定された値に設定します。デフォルト値はカーネルによって自動的に設定されます。
7.4.1.1.1. ブリッジ設定の例 リンクのコピーリンクがクリップボードにコピーされました!
以下の例では、bridge-net という名前の追加のネットワークを設定します。
- 1
- CNI 設定オブジェクトは YAML 文字列として指定されます。
7.4.1.2. IPAM CNI プラグインの設定 リンクのコピーリンクがクリップボードにコピーされました!
IPAM Container Network Interface (CNI) プラグインは、他の CNI プラグインに IP アドレス管理 (IPAM) を提供します。DHCP を使用して、静的 IP アドレスの割り当てまたは動的 IP アドレスの割り当てのいずれかに IPAM を設定することができます。指定する DHCP サーバーは、追加のネットワークから到達可能である必要があります。
以下の JSON 設定オブジェクトは設定できるパラメーターについて説明しています。
7.4.1.2.1. 静的 IP アドレス割り当ての設定 リンクのコピーリンクがクリップボードにコピーされました!
以下の JSON は、静的 IP アドレスの割り当ての設定について説明しています。
静的割り当ての設定
- 1
- 仮想インターフェイスに割り当てる IP アドレスを記述する配列。IPv4 と IPv6 の IP アドレスの両方がサポートされます。
- 2
- 指定する IP アドレスおよびネットワーク接頭辞。たとえば、
10.10.21.10/24を指定すると、追加のネットワークに IP アドレスの10.10.21.10が割り当てられ、ネットマスクは255.255.255.0になります。 - 3
- egress ネットワークトラフィックをルーティングするデフォルトのゲートウェイ。
- 4
- Pod 内で設定するルートを記述する配列。
- 5
- CIDR 形式の IP アドレス範囲 (
192.168.17.0/24、またはデフォルトルートの0.0.0.0/0)。 - 6
- ネットワークトラフィックがルーティングされるゲートウェイ。
- 7
- オプション: DNS 設定。
- 8
- DNS クエリーの送信先となる 1 つ以上の IP アドレスの配列。
- 9
- ホスト名に追加するデフォルトのドメイン。たとえば、ドメインが
example.comに設定されている場合、example-hostの DNS ルックアップクエリーはexample-host.example.comとして書き換えられます。 - 10
- DNS ルックアップのクエリー時に非修飾ホスト名に追加されるドメイン名の配列 (例:
example-host)。
7.4.1.2.2. 動的 IP アドレス割り当ての設定 リンクのコピーリンクがクリップボードにコピーされました!
以下の JSON は、DHCP を使用した動的 IP アドレスの割り当ての設定について説明しています。
Pod は、作成時に元の DHCP リースを取得します。リースは、クラスターで実行している最小限の DHCP サーバーデプロイメントで定期的に更新する必要があります。
DHCP サーバーのデプロイメントをトリガーするには、以下の例にあるように Cluster Network Operator 設定を編集して shim ネットワーク割り当てを作成する必要があります。
shim ネットワーク割り当ての定義例
DHCP 割り当ての設定
{
"ipam": {
"type": "dhcp"
}
}
{
"ipam": {
"type": "dhcp"
}
}
7.4.1.2.3. 静的 IP アドレス割り当ての設定例 リンクのコピーリンクがクリップボードにコピーされました!
静的 IP アドレスの割り当てに IPAM を設定することができます。
7.4.1.2.4. DHCP を使用した動的 IP アドレス割り当ての設定例 リンクのコピーリンクがクリップボードにコピーされました!
DHCP に IPAM を設定できます。
{
"ipam": {
"type": "dhcp"
}
}
{
"ipam": {
"type": "dhcp"
}
}
7.4.2. 次のステップ リンクのコピーリンクがクリップボードにコピーされました!
7.5. macvlan ネットワークの設定 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、macvlan CNI プラグインを使用して、クラスターの追加のネットワークを設定できます。Pod がネットワークに割り当てられている場合、プラグインはホストの親インターフェイスからサブインターフェイスを作成します。各サブデバイスに対して固有のハードウェアの MAC アドレスが生成されます。
このプラグインがサブインターフェイス用に生成する固有の MAC アドレスは、クラウドプロバイダーのセキュリティーポリシーとの互換性がない場合があります。
7.5.1. macvlan CNI プラグインを使用した追加ネットワーク割り当ての作成 リンクのコピーリンクがクリップボードにコピーされました!
Cluster Network Operator (CNO) は追加ネットワークの定義を管理します。作成する追加ネットワークを指定する場合、CNO は NetworkAttachmentDefinition オブジェクトを自動的に作成します。
Cluster Network Operator が管理する NetworkAttachmentDefinition オブジェクトは編集しないでください。これを実行すると、追加ネットワークのネットワークトラフィックが中断する可能性があります。
前提条件
-
OpenShift CLI (
oc) をインストールしている。 -
cluster-admin権限を持つユーザーとしてログインしている。
手順
クラスターの追加ネットワークを作成するには、以下の手順を実施します。
以下のコマンドを実行して CNO CR を編集します。
oc edit networks.operator.openshift.io cluster
$ oc edit networks.operator.openshift.io clusterCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のサンプル CR のように、作成される追加ネットワークの設定を追加して、作成している CR を変更します。
以下の YAML は、macvlan CNI プラグインを設定します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 追加ネットワーク割り当て定義の設定を指定します。
- 変更を保存し、テキストエディターを終了して、変更をコミットします。
オプション: 以下のコマンドを実行して、CNO が
NetworkAttachmentDefinitionオブジェクトを作成していることを確認します。CNO が CR を作成するまでに遅延が生じる可能性があります。oc get network-attachment-definitions -n <namespace>
$ oc get network-attachment-definitions -n <namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME AGE test-network-1 14m
NAME AGE test-network-1 14mCopy to Clipboard Copied! Toggle word wrap Toggle overflow
7.5.1.1. macvlan CNI プラグインの設定 リンクのコピーリンクがクリップボードにコピーされました!
以下の YAML は、macvlan Container Network Interface (CNI) プラグインの設定パラメーターについて説明しています。
macvlan YAML の設定
- 1
- 作成している追加ネットワーク割り当ての名前を指定します。名前は指定された
namespace内で一意である必要があります。 - 2
- ネットワークの割り当てを作成する namespace を指定します。値が指定されない場合は、
defaultnamespace が使用されます。 - 3
- 仮想インターフェイスに関連付けるイーサネットインターフェイス。
masterの値が指定されない場合、ホストシステムのプライマリーイーサネットインターフェイスが使用されます。 - 4
- 仮想ネットワークのトラフィックの可視性を設定します。
bridge、passthru、private、またはvepaのいずれかである必要があります。modeの値が指定されない場合、デフォルトの値はbridgeになります。 - 5
- 最大転送単位 (MTU) を指定された値に設定します。デフォルト値はカーネルによって自動的に設定されます。
- 6
- IPAM CNI プラグインの設定オブジェクトを指定します。プラグインは、割り当て定義についての IP アドレスの割り当てを管理します。
7.5.1.1.1. macvlan 設定の例 リンクのコピーリンクがクリップボードにコピーされました!
以下の例では、macvlan-net という名前の追加のネットワークを設定します。
7.5.1.2. IPAM CNI プラグインの設定 リンクのコピーリンクがクリップボードにコピーされました!
IPAM Container Network Interface (CNI) プラグインは、他の CNI プラグインに IP アドレス管理 (IPAM) を提供します。DHCP を使用して、静的 IP アドレスの割り当てまたは動的 IP アドレスの割り当てのいずれかに IPAM を設定することができます。指定する DHCP サーバーは、追加のネットワークから到達可能である必要があります。
以下の YAML 設定は設定可能なパラメーターについて説明しています。
IPAM CNI プラグイン YAML 設定オブジェクト
ipamConfig: type: <type> ...
ipamConfig:
type: <type>
...
7.5.1.2.1. 静的 IPAM 設定 YAML リンクのコピーリンクがクリップボードにコピーされました!
以下の YAML は、静的 IP アドレスの割り当ての設定について説明しています。
静的 IPAM 設定 YAML
- 1
- 仮想インターフェイスに割り当てる IP アドレスを定義するマッピングのコレクション。IPv4 と IPv6 の IP アドレスの両方がサポートされます。
- 2
- 指定する IP アドレスおよびネットワーク接頭辞。たとえば、
10.10.21.10/24を指定すると、追加のネットワークに IP アドレスの10.10.21.10が割り当てられ、ネットマスクは255.255.255.0になります。 - 3
- egress ネットワークトラフィックをルーティングするデフォルトのゲートウェイ。
- 4
- Pod 内で設定するルートを記述するマッピングのコレクション。
- 5
- CIDR 形式の IP アドレス範囲 (
192.168.17.0/24、またはデフォルトルートの0.0.0.0/0)。 - 6
- ネットワークトラフィックがルーティングされるゲートウェイ。
- 7
- オプション: DNS 設定。
- 8
- DNS クエリーを送信する 1 つ以上の IP アドレスのコレクション。
- 9
- ホスト名に追加するデフォルトのドメイン。たとえば、ドメインが
example.comに設定されている場合、example-hostの DNS ルックアップクエリーはexample-host.example.comとして書き換えられます。 - 10
- DNS ルックアップのクエリー時に非修飾ホスト名に追加されるドメイン名の配列 (例:
example-host)。
7.5.1.2.2. 動的 IPAM 設定 YAML リンクのコピーリンクがクリップボードにコピーされました!
以下の YAML は、静的 IP アドレスの割り当ての設定について説明しています。
動的 IPAM 設定 YAML
ipamConfig: type: DHCP
ipamConfig:
type: DHCP
7.5.1.2.3. 静的 IP アドレス割り当ての設定例 リンクのコピーリンクがクリップボードにコピーされました!
以下の例は、静的 IP アドレスの IPAM 設定を示しています。
7.5.1.2.4. 動的 IP アドレス割り当ての設定例 リンクのコピーリンクがクリップボードにコピーされました!
以下の例では、DHCP の IPAM 設定を示しています。
ipamConfig: type: DHCP
ipamConfig:
type: DHCP
7.5.2. 次のステップ リンクのコピーリンクがクリップボードにコピーされました!
7.6. ipvlan ネットワークの設定 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、ipvlan Container Network Interface (CNI) プラグインを使用して、クラスターの追加ネットワークを設定できます。このプラグインにより作成される仮想ネットワークは、指定する物理インターフェイスに関連付けられます。
7.6.1. IPVLAN CNI プラグインを使用した追加のネットワーク割り当ての作成 リンクのコピーリンクがクリップボードにコピーされました!
Cluster Network Operator (CNO) は追加ネットワークの定義を管理します。作成する追加ネットワークを指定する場合、CNO は NetworkAttachmentDefinition オブジェクトを自動的に作成します。
Cluster Network Operator が管理する NetworkAttachmentDefinition オブジェクトは編集しないでください。これを実行すると、追加ネットワークのネットワークトラフィックが中断する可能性があります。
前提条件
-
OpenShift CLI (
oc) をインストールしている。 -
cluster-admin権限を持つユーザーとしてログインしている。
手順
クラスターの追加ネットワークを作成するには、以下の手順を実施します。
以下のコマンドを実行して CNO CR を編集します。
oc edit networks.operator.openshift.io cluster
$ oc edit networks.operator.openshift.io clusterCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のサンプル CR のように、作成される追加ネットワークの設定を追加して、作成している CR を変更します。
以下の YAML は IPVLAN CNI プラグインを設定します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 追加ネットワーク割り当て定義の設定を指定します。
- 変更を保存し、テキストエディターを終了して、変更をコミットします。
オプション: 以下のコマンドを実行して、CNO が
NetworkAttachmentDefinitionオブジェクトを作成していることを確認します。CNO が CR を作成するまでに遅延が生じる可能性があります。oc get network-attachment-definitions -n <namespace>
$ oc get network-attachment-definitions -n <namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME AGE test-network-1 14m
NAME AGE test-network-1 14mCopy to Clipboard Copied! Toggle word wrap Toggle overflow
7.6.1.1. IPVLAN の設定 リンクのコピーリンクがクリップボードにコピーされました!
IPVLAN Container Network Interface (CNI) プラグインを使用する追加のネットワーク割り当ての設定は、以下の 2 つの部分に分けて提供されます。
- Cluster Network Operator (CNO) の設定
- CNI プラグインの設定
CNO 設定では、追加ネットワーク割り当ての名前と割り当てを作成する namespace を指定します。このプラグインは、CNO 設定の rawCNIConfig パラメーターで指定される JSON オブジェクトで設定されます。
以下の YAML は、CNO の設定パラメーターについて説明しています。
Cluster Network Operator YAML の設定
以下のオブジェクトは、IPVLAN CNI プラグインの設定パラメーターについて説明しています。
IPVLAN CNI プラグイン JSON 設定オブジェクト
- 1
- CNO 設定に以前に指定した
nameパラメーターの値を指定します。 - 2
- 仮想ネットワークの操作モードを指定します。この値は、
l2、l3、またはl3sである必要があります。デフォルト値はl2です。 - 3
- ネットワーク割り当てに関連付けるイーサネットインターフェイスを指定します。
masterが指定されない場合、デフォルトのネットワークルートのインターフェイスが使用されます。 - 4
- 最大転送単位 (MTU) を指定された値に設定します。デフォルト値はカーネルによって自動的に設定されます。
- 5
- IPAM CNI プラグインの設定オブジェクトを指定します。プラグインは、割り当て定義についての IP アドレスの割り当てを管理します。
7.6.1.1.1. IPVLAN 設定例 リンクのコピーリンクがクリップボードにコピーされました!
以下の例では、ipvlan-net という名前の追加のネットワークを設定します。
- 1
- CNI 設定オブジェクトは YAML 文字列として指定されます。
7.6.1.2. IPAM CNI プラグインの設定 リンクのコピーリンクがクリップボードにコピーされました!
IPAM Container Network Interface (CNI) プラグインは、他の CNI プラグインに IP アドレス管理 (IPAM) を提供します。DHCP を使用して、静的 IP アドレスの割り当てまたは動的 IP アドレスの割り当てのいずれかに IPAM を設定することができます。指定する DHCP サーバーは、追加のネットワークから到達可能である必要があります。
以下の JSON 設定オブジェクトは設定できるパラメーターについて説明しています。
7.6.1.2.1. 静的 IP アドレス割り当ての設定 リンクのコピーリンクがクリップボードにコピーされました!
以下の JSON は、静的 IP アドレスの割り当ての設定について説明しています。
静的割り当ての設定
- 1
- 仮想インターフェイスに割り当てる IP アドレスを記述する配列。IPv4 と IPv6 の IP アドレスの両方がサポートされます。
- 2
- 指定する IP アドレスおよびネットワーク接頭辞。たとえば、
10.10.21.10/24を指定すると、追加のネットワークに IP アドレスの10.10.21.10が割り当てられ、ネットマスクは255.255.255.0になります。 - 3
- egress ネットワークトラフィックをルーティングするデフォルトのゲートウェイ。
- 4
- Pod 内で設定するルートを記述する配列。
- 5
- CIDR 形式の IP アドレス範囲 (
192.168.17.0/24、またはデフォルトルートの0.0.0.0/0)。 - 6
- ネットワークトラフィックがルーティングされるゲートウェイ。
- 7
- オプション: DNS 設定。
- 8
- DNS クエリーの送信先となる 1 つ以上の IP アドレスの配列。
- 9
- ホスト名に追加するデフォルトのドメイン。たとえば、ドメインが
example.comに設定されている場合、example-hostの DNS ルックアップクエリーはexample-host.example.comとして書き換えられます。 - 10
- DNS ルックアップのクエリー時に非修飾ホスト名に追加されるドメイン名の配列 (例:
example-host)。
7.6.1.2.2. 動的 IP アドレス割り当ての設定 リンクのコピーリンクがクリップボードにコピーされました!
以下の JSON は、DHCP を使用した動的 IP アドレスの割り当ての設定について説明しています。
Pod は、作成時に元の DHCP リースを取得します。リースは、クラスターで実行している最小限の DHCP サーバーデプロイメントで定期的に更新する必要があります。
DHCP サーバーのデプロイメントをトリガーするには、以下の例にあるように Cluster Network Operator 設定を編集して shim ネットワーク割り当てを作成する必要があります。
shim ネットワーク割り当ての定義例
DHCP 割り当ての設定
{
"ipam": {
"type": "dhcp"
}
}
{
"ipam": {
"type": "dhcp"
}
}
7.6.1.2.3. 静的 IP アドレス割り当ての設定例 リンクのコピーリンクがクリップボードにコピーされました!
静的 IP アドレスの割り当てに IPAM を設定することができます。
7.6.1.2.4. DHCP を使用した動的 IP アドレス割り当ての設定例 リンクのコピーリンクがクリップボードにコピーされました!
DHCP に IPAM を設定できます。
{
"ipam": {
"type": "dhcp"
}
}
{
"ipam": {
"type": "dhcp"
}
}
7.6.2. 次のステップ リンクのコピーリンクがクリップボードにコピーされました!
7.7. ホストデバイスネットワークの設定 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、ホストデバイス Container Network Interface (CNI) プラグインを使用して、クラスターの追加ネットワークを設定できます。このプラグインは、指定されたネットワークデバイスを、ホストのネットワーク namespace から Pod のネットワーク namespace に移動することを可能にします。
7.7.1. ホストデバイス CNI プラグインを使用した追加ネットワーク割り当ての作成 リンクのコピーリンクがクリップボードにコピーされました!
Cluster Network Operator (CNO) は追加ネットワークの定義を管理します。作成する追加ネットワークを指定する場合、CNO は NetworkAttachmentDefinition オブジェクトを自動的に作成します。
Cluster Network Operator が管理する NetworkAttachmentDefinition オブジェクトは編集しないでください。これを実行すると、追加ネットワークのネットワークトラフィックが中断する可能性があります。
前提条件
-
OpenShift CLI (
oc) をインストールしている。 -
cluster-admin権限を持つユーザーとしてログインしている。
手順
クラスターの追加ネットワークを作成するには、以下の手順を実施します。
以下のコマンドを実行して CNO CR を編集します。
oc edit networks.operator.openshift.io cluster
$ oc edit networks.operator.openshift.io clusterCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のサンプル CR のように、作成される追加ネットワークの設定を追加して、作成している CR を変更します。
以下の YAML は、ホストデバイス CNI プラグインを設定します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 追加ネットワーク割り当て定義の設定を指定します。
- 変更を保存し、テキストエディターを終了して、変更をコミットします。
オプション: 以下のコマンドを実行して、CNO が
NetworkAttachmentDefinitionオブジェクトを作成していることを確認します。CNO が CR を作成するまでに遅延が生じる可能性があります。oc get network-attachment-definitions -n <namespace>
$ oc get network-attachment-definitions -n <namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME AGE test-network-1 14m
NAME AGE test-network-1 14mCopy to Clipboard Copied! Toggle word wrap Toggle overflow
7.7.1.1. ホストデバイスの設定 リンクのコピーリンクがクリップボードにコピーされました!
ホストデバイス Container Network Interface (CNI) プラグインを使用する追加ネットワーク割り当ての設定は、以下の 2 つの部分に分けて提供されます。
- Cluster Network Operator (CNO) の設定
- CNI プラグインの設定
CNO 設定では、追加ネットワーク割り当ての名前と割り当てを作成する namespace を指定します。このプラグインは、CNO 設定の rawCNIConfig パラメーターで指定される JSON オブジェクトで設定されます。
以下の YAML は、CNO の設定パラメーターについて説明しています。
Cluster Network Operator YAML の設定
device、hwaddr、 kernelpath、または pciBusID のいずれかのパラメーターを設定してネットワークデバイスを指定します。
以下のオブジェクトは、ホストデバイス CNI プラグインの設定パラメーターについて説明しています。
ホストデバイス CNI プラグイン JSON 設定オブジェクト
7.7.1.1.1. ホストデバイス設定例 リンクのコピーリンクがクリップボードにコピーされました!
以下の例では、hostdev-net という名前の追加のネットワークを設定します。
- 1
- CNI 設定オブジェクトは YAML 文字列として指定されます。
7.7.1.2. IPAM CNI プラグインの設定 リンクのコピーリンクがクリップボードにコピーされました!
IPAM Container Network Interface (CNI) プラグインは、他の CNI プラグインに IP アドレス管理 (IPAM) を提供します。DHCP を使用して、静的 IP アドレスの割り当てまたは動的 IP アドレスの割り当てのいずれかに IPAM を設定することができます。指定する DHCP サーバーは、追加のネットワークから到達可能である必要があります。
以下の JSON 設定オブジェクトは設定できるパラメーターについて説明しています。
7.7.1.2.1. 静的 IP アドレス割り当ての設定 リンクのコピーリンクがクリップボードにコピーされました!
以下の JSON は、静的 IP アドレスの割り当ての設定について説明しています。
静的割り当ての設定
- 1
- 仮想インターフェイスに割り当てる IP アドレスを記述する配列。IPv4 と IPv6 の IP アドレスの両方がサポートされます。
- 2
- 指定する IP アドレスおよびネットワーク接頭辞。たとえば、
10.10.21.10/24を指定すると、追加のネットワークに IP アドレスの10.10.21.10が割り当てられ、ネットマスクは255.255.255.0になります。 - 3
- egress ネットワークトラフィックをルーティングするデフォルトのゲートウェイ。
- 4
- Pod 内で設定するルートを記述する配列。
- 5
- CIDR 形式の IP アドレス範囲 (
192.168.17.0/24、またはデフォルトルートの0.0.0.0/0)。 - 6
- ネットワークトラフィックがルーティングされるゲートウェイ。
- 7
- オプション: DNS 設定。
- 8
- DNS クエリーの送信先となる 1 つ以上の IP アドレスの配列。
- 9
- ホスト名に追加するデフォルトのドメイン。たとえば、ドメインが
example.comに設定されている場合、example-hostの DNS ルックアップクエリーはexample-host.example.comとして書き換えられます。 - 10
- DNS ルックアップのクエリー時に非修飾ホスト名に追加されるドメイン名の配列 (例:
example-host)。
7.7.1.2.2. 動的 IP アドレス割り当ての設定 リンクのコピーリンクがクリップボードにコピーされました!
以下の JSON は、DHCP を使用した動的 IP アドレスの割り当ての設定について説明しています。
Pod は、作成時に元の DHCP リースを取得します。リースは、クラスターで実行している最小限の DHCP サーバーデプロイメントで定期的に更新する必要があります。
DHCP サーバーのデプロイメントをトリガーするには、以下の例にあるように Cluster Network Operator 設定を編集して shim ネットワーク割り当てを作成する必要があります。
shim ネットワーク割り当ての定義例
DHCP 割り当ての設定
{
"ipam": {
"type": "dhcp"
}
}
{
"ipam": {
"type": "dhcp"
}
}
7.7.1.2.3. 静的 IP アドレス割り当ての設定例 リンクのコピーリンクがクリップボードにコピーされました!
静的 IP アドレスの割り当てに IPAM を設定することができます。
7.7.1.2.4. DHCP を使用した動的 IP アドレス割り当ての設定例 リンクのコピーリンクがクリップボードにコピーされました!
DHCP に IPAM を設定できます。
{
"ipam": {
"type": "dhcp"
}
}
{
"ipam": {
"type": "dhcp"
}
}
7.7.2. 次のステップ リンクのコピーリンクがクリップボードにコピーされました!
7.8. 追加ネットワークの編集 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、既存の追加ネットワークの設定を変更することができます。
7.8.1. 追加ネットワーク割り当て定義の変更 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、既存の追加ネットワークに変更を加えることができます。追加ネットワークに割り当てられる既存の Pod は更新されません。
前提条件
- クラスター用に追加のネットワークを設定している。
-
OpenShift CLI (
oc) をインストールしている。 -
cluster-admin権限を持つユーザーとしてログインしている。
手順
クラスターの追加ネットワークを編集するには、以下の手順を実行します。
以下のコマンドを実行し、デフォルトのテキストエディターで Cluster Network Operator (CNO) CR を編集します。
oc edit networks.operator.openshift.io cluster
$ oc edit networks.operator.openshift.io clusterCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
additionalNetworksコレクションで、追加ネットワークを変更内容で更新します。 - 変更を保存し、テキストエディターを終了して、変更をコミットします。
オプション: 以下のコマンドを実行して、CNO が
NetworkAttachmentDefinitionオブジェクトを更新していることを確認します。<network-name>を表示する追加ネットワークの名前に置き換えます。CNO がNetworkAttachmentDefinitionオブジェクトを更新して変更内容が反映されるまでに遅延が生じる可能性があります。oc get network-attachment-definitions <network-name> -o yaml
$ oc get network-attachment-definitions <network-name> -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow たとえば、以下のコンソールの出力は
net1という名前のNetworkAttachmentDefinitionオブジェクトを表示します。oc get network-attachment-definitions net1 -o go-template='{{printf "%s\n" .spec.config}}'$ 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"]}} }Copy to Clipboard Copied! Toggle word wrap Toggle overflow
7.9. 追加ネットワークの削除 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、追加のネットワーク割り当てを削除できます。
7.9.1. 追加ネットワーク割り当て定義の削除 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、追加ネットワークを OpenShift Container Platform クラスターから削除できます。追加ネットワークは、割り当てられている Pod から削除されません。
前提条件
-
OpenShift CLI (
oc) をインストールしている。 -
cluster-admin権限を持つユーザーとしてログインしている。
手順
クラスターから追加ネットワークを削除するには、以下の手順を実行します。
以下のコマンドを実行して、デフォルトのテキストエディターで Cluster Network Operator (CNO) を編集します。
oc edit networks.operator.openshift.io cluster
$ oc edit networks.operator.openshift.io clusterCopy to Clipboard Copied! Toggle word wrap Toggle overflow 削除しているネットワーク割り当て定義の
additionalNetworksコレクションから設定を削除し、CR を変更します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
additionalNetworksコレクションの追加ネットワーク割り当てのみの設定マッピングを削除する場合、空のコレクションを指定する必要があります。
- 変更を保存し、テキストエディターを終了して、変更をコミットします。
オプション: 以下のコマンドを実行して、追加ネットワーク CR が削除されていることを確認します。
oc get network-attachment-definition --all-namespaces
$ oc get network-attachment-definition --all-namespacesCopy to Clipboard Copied! Toggle word wrap Toggle overflow
7.10. PTP の設定 リンクのコピーリンクがクリップボードにコピーされました!
Precision Time Protocol (PTP) ハードウェアはテクノロジープレビュー機能です。テクノロジープレビュー機能は Red Hat の実稼働環境でのサービスレベルアグリーメント (SLA) ではサポートされていないため、Red Hat では実稼働環境での使用を推奨していません。Red Hat は実稼働環境でこれらを使用することを推奨していません。テクノロジープレビューの機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
7.10.1. PTP ハードウェアについて リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform には、ノード上で PTP ハードウェアを使用する機能が含まれます。linuxptp サービスは、PTP 対応ハードウェアを搭載したノードで設定できます。
PTP Operator は、ベアメタルインフラストラクチャーでのみプロビジョニングされるクラスターの PTP 対応デバイスと連携します。
PTP Operator をデプロイし、OpenShift Container Platform コンソールを使用して PTP をインストールできます。PTP Operator は、linuxptp サービスを作成し、管理します。Operator は以下の機能を提供します。
- クラスター内の PTP 対応デバイスを検出します。
- linuxptp サービスの設定を管理します。
7.10.2. PTP Operator のインストール リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、OpenShift Container Platform CLI または Web コンソールを使用して PTP Operator をインストールできます。
7.10.2.1. CLI: PTP Operator のインストール リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、CLI を使用して Operator をインストールできます。
前提条件
- PTP に対応するハードウェアを持つノードでベアメタルハードウェアにインストールされたクラスター。
-
OpenShift CLI (
oc) をインストールしている。 -
cluster-admin権限を持つユーザーとしてログインしている。
手順
PTP Operator の namespace を作成するには、以下のコマンドを入力します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Operator の Operator グループを作成するには、以下のコマンドを入力します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow PTP Operator にサブスクライブします。
以下のコマンドを実行して、OpenShift Container Platform のメジャーおよびマイナーバージョンを環境変数として設定します。これは次の手順で
channelの値として使用されます。OC_VERSION=$(oc version -o yaml | grep openshiftVersion | \ grep -o '[0-9]*[.][0-9]*' | head -1)$ OC_VERSION=$(oc version -o yaml | grep openshiftVersion | \ grep -o '[0-9]*[.][0-9]*' | head -1)Copy to Clipboard Copied! Toggle word wrap Toggle overflow PTP Operator のサブスクリプションを作成するには、以下のコマンドを入力します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Operator がインストールされていることを確認するには、以下のコマンドを入力します。
oc get csv -n openshift-ptp \ -o custom-columns=Name:.metadata.name,Phase:.status.phase
$ oc get csv -n openshift-ptp \ -o custom-columns=Name:.metadata.name,Phase:.status.phaseCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Name Phase ptp-operator.4.4.0-202006160135 Succeeded
Name Phase ptp-operator.4.4.0-202006160135 SucceededCopy to Clipboard Copied! Toggle word wrap Toggle overflow
7.10.2.2. Web コンソール: PTP Operator のインストール リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、Web コンソールを使用して Operator をインストールできます。
先のセクションで説明されているように namespace および Operator グループを作成する必要があります。
手順
OpenShift Container Platform Web コンソールを使用して PTP Operator をインストールします。
- OpenShift Container Platform Web コンソールで、Operators → OperatorHub をクリックします。
- 利用可能な Operator の一覧から PTP Operator を選択してから Install をクリックします。
- Create Operator Subscription ページの A specific namespace on the cluster の下で openshift-ptp を選択します。次に、Subscribe をクリックします。
オプション: 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 のログを確認します。
7.10.3. PTP ネットワークデバイスの自動検出 リンクのコピーリンクがクリップボードにコピーされました!
PTP Operator は NodePtpDevice.ptp.openshift.io カスタムリソース定義 (CRD) を OpenShift Container Platform に追加します。PTP Operator はクラスターで、各ノードの PTP 対応ネットワークデバイスを検索します。Operator は、互換性のある PTP デバイスを提供する各ノードの NodePtpDevice カスタムリソース (CR) オブジェクトを作成し、更新します。
1 つの CR がノードごとに作成され、ノードと同じ名前を共有します。.status.devices 一覧は、ノード上の PTP デバイスについての情報を提供します。
以下は、PTP Operator によって作成される NodePtpDevice CR の例です。
7.10.4. Linuxptp サービスの設定 リンクのコピーリンクがクリップボードにコピーされました!
PTP Operator は PtpConfig.ptp.openshift.io カスタムリソース定義 (CRD) を OpenShift Container Platform に追加します。PtpConfig カスタムリソース (CR) オブジェクトを作成して、Linuxptp サービス (ptp4l、phc2sys) を設定できます。
前提条件
-
OpenShift CLI (
oc) をインストールしている。 -
cluster-admin権限を持つユーザーとしてログインしている。 - PTP Operator がインストールされていること。
手順
以下の
PtpConfigCR を作成してから、YAML を<name>-ptp-config.yamlファイルに保存します。<name>をこの設定の名前に置き換えます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
PtpConfigCR の名前を指定します。- 2
- PTP Operator がインストールされている namespace を指定します。
- 3
- 1 つ以上の
profileオブジェクトの配列を指定します。 - 4
- プロファイルオブジェクトを一意に識別するために使用されるプロファイルオブジェクトの名前を指定します。
- 5
ptp4lサービスで使用するネットワークインターフェイス名を指定します (例:ens787f1)。- 6
ptp4lサービスのシステム設定オプション (例:-s -2) を指定します。これには、インターフェイス名-i <interface>およびサービス設定ファイル-f /etc/ptp4l.confを含めないでください。これらは自動的に追加されます。- 7
phc2sysサービスのシステム設定オプション (例:-a -r) を指定します。- 8
profileがノードに適用される方法を定義する 1 つ以上のrecommendオブジェクトの配列を指定します。- 9
profileセクションに定義されるprofileオブジェクト名を指定します。- 10
0から99までの整数値でpriorityを指定します。数値が大きいほど優先度が低くなるため、99の優先度は10よりも低くなります。ノードがmatchフィールドで定義されるルールに基づいて複数のプロファイルに一致する場合、優先順位の高い プロファイルがそのノードに適用されます。- 11
matchルールを、nodeLabelまたはnodeNameで指定します。- 12
nodeLabelを、ノードオブジェクトのnode.Labelsのkeyで指定します。- 13
nodeNameをノードオブジェクトのnode.Nameで指定します。
以下のコマンドを実行して CR を作成します。
oc create -f <filename>
$ oc create -f <filename>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<filename>を、先の手順で作成したファイルの名前に置き換えます。
オプション:
PtpConfigプロファイルが、nodeLabelまたはnodeNameに一致するノードに適用されることを確認します。oc get pods -n openshift-ptp -o wide
$ oc get pods -n openshift-ptp -o wideCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
第8章 ハードウェアネットワーク リンクのコピーリンクがクリップボードにコピーされました!
8.1. Single Root I/O Virtualization (SR-IOV) ハードウェアネットワークについて リンクのコピーリンクがクリップボードにコピーされました!
Single Root I/O Virtualization (SR-IOV) 仕様は、単一デバイスを複数の Pod で共有できる PCI デバイス割り当てタイプの標準です。
SR-IOV を使用すると、準拠したネットワークデバイス (ホストノードで物理機能 (PF) として認識される) を複数の仮想機能 (VF) にセグメント化することができます。VF は他のネットワークデバイスと同様に使用されます。デバイスの SR-IOV デバイスドライバーは、VF がコンテナーで公開される方法を判別します。
-
netdeviceドライバー: コンテナーのnetns内の通常のカーネルネットワークデバイス -
vfio-pciドライバー: コンテナーにマウントされるキャラクターデバイス
高帯域幅または低レイテンシーを必要とするアプリケーション用に、OpenShift Container Platform クラスターの追加のネットワークと共に SR-IOV ネットワークデバイスを使用できます。
8.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 Operator の起動時にワーカーノードにデプロイされる DaemonSet。デーモンは、クラスターで SR-IOV ネットワークデバイスを検出し、初期化します。
- SR-IOV Operator Webhook
- Operator カスタムリソースを検証し、未設定フィールドに適切なデフォルト値を設定する動的受付コントローラー Webhook。
- SR-IOV Network Resources Injector
- SR-IOV VF などのカスタムネットワークリソースの要求および制限のある Kubernetes Pod 仕様のパッチを適用するための機能を提供する動的受付コントローラー Webhook。
- SR-IOV ネットワークデバイスプラグイン
- SR-IOV ネットワーク Virtual Function (VF) リソースの検出、公開、割り当てを実行するデバイスプラグイン。デバイスプラグインは、とりわけ物理デバイスでの制限されたリソースの使用を有効にするために Kubernetes で使用されます。デバイスプラグインは Kubernetes スケジューラーにリソースの可用性を認識させるため、スケジューラーはリソースが十分にあるノードで Pod をスケジュールできます。
- SR-IOV CNI プラグイン
- SR-IOV デバイスプラグインから割り当てられる VF インターフェイスを直接 Pod に割り当てる CNI プラグイン。
SR-IOV Network Resources Injector および SR-IOV Network Operator Webhook は、デフォルトで有効にされ、default の SriovOperatorConfig CR を編集して無効にできます。
8.1.1.1. サポートされるデバイス リンクのコピーリンクがクリップボードにコピーされました!
以下の Network Interface Card (NIC) モデルは、OpenShift Container Platform でサポートされています。
-
Intel XXV710 25GbE SFP28 (ベンダー ID
0x8086およびデバイス ID0x158b) -
Mellanox MT27710 Family [ConnectX-4 Lx] 25GbE dual-port SFP28 (ベンダー ID
0x15b3およびデバイス ID0x1015) -
Mellanox MT27800 Family [ConnectX-5] 25GbE dual-port SFP28 (ベンダー ID
0x15b3およびデバイス ID0x1017) -
Mellanox MT27800 Family [ConnectX-5] 100GbE (ベンダー ID
0x15b3およびデバイス ID0x1017)
8.1.1.2. SR-IOV ネットワークデバイスの自動検出 リンクのコピーリンクがクリップボードにコピーされました!
SR-IOV Network Operator は、クラスターでワーカーノード上の SR-IOV 対応ネットワークデバイスを検索します。Operator は、互換性のある SR-IOV ネットワークデバイスを提供する各ワーカーノードの SriovNetworkNodeState カスタムリソース (CR) を作成し、更新します。
CR にはワーカーノードと同じ名前が割り当てられます。status.interfaces 一覧は、ノード上のネットワークデバイスについての情報を提供します。
SriovNetworkNodeState オブジェクトは変更しないでください。Operator はこれらのリソースを自動的に作成し、管理します。
8.1.1.2.1. SriovNetworkNodeState オブジェクトの例 リンクのコピーリンクがクリップボードにコピーされました!
以下の YAML は、SR-IOV Network Operator によって作成される SriovNetworkNodeState オブジェクトの例です。
SriovNetworkNodeState オブジェクト
8.1.1.3. 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 仕様
以下の例は、DPDK モードの VF のある Pod を示しています。
DPDK モードを使用する Pod 仕様
オプションのライブラリーは、コンテナーで実行されるアプリケーションによる Pod 関連のネットワーク情報を収集を支援するために利用できます。このライブラリーは 'app-netutil' と呼ばれます。app-netutil GitHub リポジトリー でライブラリーのソースコードを参照してください。
このライブラリーは、DPDK モードの SR-IOV VF のコンテナーへの統合を容易にすることを目的としています。ライブラリーは、GO API と C API、および両方の言語の使用例を提供します。
また、サンプルの Docker イメージ 'dpdk-app-centos' も用意されています。このイメージは、Pod 仕様の l2fwd、l3wd または testpmd の環境変数に基づいて、以下の DPDK サンプルアプリケーションのいずれかを実行できます。この Docker イメージは、app-netutil をコンテナーイメージ自体に統合するサンプルを提供します。ライブラリーも、必要なデータを収集し、データを既存の DPDK ワークロードに渡す init-container に統合できます。
8.1.2. 次のステップ リンクのコピーリンクがクリップボードにコピーされました!
8.2. SR-IOV Network Operator のインストール リンクのコピーリンクがクリップボードにコピーされました!
Single Root I/O Virtualization (SR-IOV) ネットワーク Operator をクラスターにインストールし、SR-IOV ネットワークデバイスとネットワークの割り当てを管理できます。
8.2.1. SR-IOV Network Operator のインストール リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、OpenShift Container Platform CLI または Web コンソールを使用して SR-IOV Network Operator をインストールできます。
8.2.1.1. CLI: SR-IOV Network Operator のインストール リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、CLI を使用して Operator をインストールできます。
前提条件
- SR-IOV に対応するハードウェアを持つノードでベアメタルハードウェアにインストールされたクラスター。
-
OpenShift CLI (
oc) をインストールしている。 -
cluster-admin権限を持つアカウント。
手順
openshift-sriov-network-operatornamespace を作成するには、以下のコマンドを入力します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow OperatorGroup CR を作成するには、以下のコマンドを実行します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow SR-IOV Network Operator にサブスクライブします。
以下のコマンドを実行して OpenShift Container Platform のメジャーおよびマイナーバージョンを取得します。これは、次の手順の
channelの値に必要です。OC_VERSION=$(oc version -o yaml | grep openshiftVersion | \ grep -o '[0-9]*[.][0-9]*' | head -1)$ OC_VERSION=$(oc version -o yaml | grep openshiftVersion | \ grep -o '[0-9]*[.][0-9]*' | head -1)Copy to Clipboard Copied! Toggle word wrap Toggle overflow SR-IOV Network Operator の Subscription CR を作成するには、以下のコマンドを入力します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Operator がインストールされていることを確認するには、以下のコマンドを入力します。
oc get csv -n openshift-sriov-network-operator \ -o custom-columns=Name:.metadata.name,Phase:.status.phase
$ oc get csv -n openshift-sriov-network-operator \ -o custom-columns=Name:.metadata.name,Phase:.status.phaseCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Name Phase sriov-network-operator.4.4.0-202006160135 Succeeded
Name Phase sriov-network-operator.4.4.0-202006160135 SucceededCopy to Clipboard Copied! Toggle word wrap Toggle overflow
8.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 をクリックします。 -
Filter by name フィールドに、
openshift-sriov-network-operatorを入力します。 -
結果の一覧から
openshift-sriov-network-operatorをクリックした後、YAML をクリックします。 namespace 定義に以下のスタンザを追加して namespace を更新します。
labels: openshift.io/run-level: "1"labels: openshift.io/run-level: "1"Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Save をクリックします。
SR-IOV ネットワーク Operator をインストールします。
- OpenShift Container Platform Web コンソールで、Operators → OperatorHub をクリックします。
- 利用可能な Operator の一覧から SR-IOV Network Operator を選択してから Install をクリックします。
- Create Operator Subscription ページの A specific namespace on the cluster の下で、openshift-sriov-network-operator を選択します。
- Subscribe をクリックします。
SR-IOV ネットワーク 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 のログを確認します。
8.2.2. 次のステップ リンクのコピーリンクがクリップボードにコピーされました!
- オプション: SR-IOV ネットワーク Operator の設定
8.3. SR-IOV Network Operator の設定 リンクのコピーリンクがクリップボードにコピーされました!
Single Root I/O Virtualization (SR-IOV) ネットワーク Operator は、クラスターで SR-IOV ネットワークデバイスおよびネットワーク割り当てを管理します。
8.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 を変更する必要があります。
SriovOperatorConfig オブジェクトは、Operator を設定するための複数のフィールドを提供します。
-
enableInjectorを使用すると、プロジェクト管理者は Network Resources Injector デーモンセットを有効または無効にすることができます。 -
enableOperatorWebhookを使用すると、プロジェクト管理者は Operator Admission Controller webhook デーモンセットを有効または無効にすることができます。 -
configDaemonNodeSelectorを使用すると、プロジェクト管理者は選択したノードで SR-IOV Network Config Daemon をスケジュールできます。
8.3.1.1. Network Resources Injector について リンクのコピーリンクがクリップボードにコピーされました!
Network Resources Injector は Kubernetes Dynamic Admission Controller アプリケーションです。これは、以下の機能を提供します。
-
SR-IOV リソース名を SR-IOV ネットワーク割り当て定義アノテーションに従って追加するための、
Pod仕様でのリソース要求および制限の変更。 -
Pod のアノテーションおよびラベルを
/etc/podnetinfoパスの下にあるファイルとして公開するための、Downward API ボリュームでのPod仕様の変更。
デフォルトで、Network Resources Injector は SR-IOV Operator によって有効にされ、すべてのマスターノードでデーモンセットとして実行されます。以下は、3 つのマスターノードを持つクラスターで実行される Network Resources Injector Pod の例です。
oc get pods -n openshift-sriov-network-operator
$ 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
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
8.3.1.2. SR-IOV Operator Admission Controller Webhook について リンクのコピーリンクがクリップボードにコピーされました!
SR-IOV Operator Admission Controller Webbook は Kubernetes Dynamic Admission Controller アプリケーションです。これは、以下の機能を提供します。
-
作成時または更新時の
SriovNetworkNodePolicyCR の検証 -
CR の作成または更新時の
priorityおよびdeviceTypeフィールドのデフォルト値の設定によるSriovNetworkNodePolicyCR の変更
デフォルトで、SR-IOV Operator Admission Controller Webhook は Operator によって有効にされ、すべてのマスターノードでデーモンセットとして実行されます。以下は、3 つのマスターノードを持つクラスターで実行される Operator Admission Controller Webhook Pod の例です。
oc get pods -n openshift-sriov-network-operator
$ 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
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
8.3.1.3. カスタムノードセレクターについて リンクのコピーリンクがクリップボードにコピーされました!
SR-IOV Network Config デーモンは、クラスターノード上の SR-IOV ネットワークデバイスを検出し、設定します。デフォルトで、これはクラスター内のすべての worker ノードにデプロイされます。ノードラベルを使用して、SR-IOV Network Config デーモンが実行するノードを指定できます。
8.3.1.4. Network Resources Injector の無効化または有効化 リンクのコピーリンクがクリップボードにコピーされました!
デフォルトで有効にされている Network Resources Injector を無効にするか、または有効にするには、以下の手順を実行します。
前提条件
-
OpenShift CLI (
oc) をインストールしている。 -
cluster-admin権限を持つユーザーとしてログインしている。 - SR-IOV Operator がインストールされていること。
手順
enableInjectorフィールドを設定します。<value>をfalseに置き換えて機能を無効にするか、またはtrueに置き換えて機能を有効にします。oc patch sriovoperatorconfig default \ --type=merge -n openshift-sriov-network-operator \ --patch '{ "spec": { "enableInjector": <value> } }'$ oc patch sriovoperatorconfig default \ --type=merge -n openshift-sriov-network-operator \ --patch '{ "spec": { "enableInjector": <value> } }'Copy to Clipboard Copied! Toggle word wrap Toggle overflow
8.3.1.5. SR-IOV Operator Admission Controller Webhook の無効化または有効化 リンクのコピーリンクがクリップボードにコピーされました!
デフォルトで有効にされている なっている受付コントローラー Webhook を無効にするか、または有効にするには、以下の手順を実行します。
前提条件
-
OpenShift CLI (
oc) をインストールしている。 -
cluster-admin権限を持つユーザーとしてログインしている。 - SR-IOV Operator がインストールされていること。
手順
enableOperatorWebhookフィールドを設定します。<value>をfalseに置き換えて機能を無効するか、trueに置き換えて機能を有効にします。oc patch sriovoperatorconfig default --type=merge \ -n openshift-sriov-network-operator \ --patch '{ "spec": { "enableOperatorWebhook": <value> } }'$ oc patch sriovoperatorconfig default --type=merge \ -n openshift-sriov-network-operator \ --patch '{ "spec": { "enableOperatorWebhook": <value> } }'Copy to Clipboard Copied! Toggle word wrap Toggle overflow
8.3.1.6. 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 のノードセレクターを更新するには、以下のコマンドを入力します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下の例のように、
<node-label>を適用するラベルに置き換えます:"node-role.kubernetes.io/worker": ""
8.3.2. 次のステップ リンクのコピーリンクがクリップボードにコピーされました!
8.4. SR-IOV ネットワークデバイスの設定 リンクのコピーリンクがクリップボードにコピーされました!
クラスターで Single Root I/O Virtualization (SR-IOV) デバイスを設定できます。
8.4.1. SR-IOV ネットワークノード設定オブジェクト リンクのコピーリンクがクリップボードにコピーされました!
SriovNetworkNodePolicy オブジェクトを定義することで、ノードの SR-IOV ネットワークデバイス設定を指定します。オブジェクトは sriovnetwork.openshift.io API グループの一部です。
以下の YAML は SriovNetworkNodePolicy オブジェクトについて説明しています。
- 1
- CR オブジェクトの名前。
- 2
- SR-IOV Operator がインストールされている namespace。
- 3
- SR-IOV デバイスプラグインのリソース名。1 つのリソース名に複数の
SriovNetworkNodePolicyオブジェクトを作成できます。 - 4
- 設定されたノードを選択するノードセレクター。選択したノード上の SR-IOV ネットワークデバイスのみが設定されます。SR-IOV Container Network Interface (CNI) プラグインおよびデバイスプラグインは、選択したノードにのみデプロイされます。
- 5
- オプション:
0から99までの整数値。数値が小さいほど優先度が高くなります。したがって、10は99よりも優先度が高くなります。デフォルト値は99です。 - 6
- オプション: 仮想機能 (VF) の最大転送単位 (MTU)。MTU の最大値は NIC モデルによって異なります。
- 7
- SR-IOV 物理ネットワークデバイス用に作成する仮想機能 (VF) の数。Intel Network Interface Card (NIC) の場合、VF の数はデバイスがサポートする VF の合計よりも大きくすることはできません。Mellanox NIC の場合、VF の数は
128よりも大きくすることはできません。 - 8
nicSelectorマッピングは、Operator が設定するデバイスを選択します。すべてのパラメーターの値を指定する必要はありません。意図せずにデバイスを選択しないように、ネットワークデバイスを極めて正確に特定することが推奨されます。rootDevicesを指定する場合、vendor、deviceID、またはpfNameの値も指定する必要があります。pfNamesおよびrootDevicesの両方を同時に指定する場合、それらが同一のデバイスをポイントすることを確認します。- 9
- オプション: SR-IOV ネットワークデバイスのベンダー 16 進コード。許可される値は
8086および15b3のみになります。 - 10
- オプション: SR-IOV ネットワークデバイスのデバイス 16 進コード。許可される値は
158b、1015、および1017のみになります。 - 11
- オプション: 1 つ以上のデバイスの物理機能 (PF) 名の配列。
- 12
- デバイスの PF 用の 1 つ以上の PCI バスアドレスの配列。以下の形式でアドレスを指定します:
0000:02:00.1 - 13
- オプション: 仮想機能 (VF) のドライバータイプ。許可される値は
netdeviceおよびvfio-pciのみです。デフォルト値はnetdeviceです。注記Mellanox カードをベアメタルノードの Data Plane Development Kit (DPDK) モードで機能させるには、
netdeviceドライバータイプを使用し、isRdmaをtrueに設定します。 - 14
- オプション: Remote Direct Memory Access (RDMA) モードを有効にするかどうか。デフォルト値は
falseです。注記isRDMAパラメーターがtrueに設定される場合、引き続き RDMA 対応の VF を通常のネットワークデバイスとして使用できます。デバイスはどちらのモードでも使用できます。
8.4.1.1. SR-IOV デバイスの仮想機能 (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"]
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:
ポリシー policy-net-1-dpdk:
8.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>をこの設定の名前に置き換えます。 SriovNetworkNodePolicy CR を作成します。
oc create -f <name>-sriov-node-network.yaml
$ oc create -f <name>-sriov-node-network.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow ここで、
<name>はこの設定の名前を指定します。設定の更新が適用された後に、
sriov-network-operatornamespace のすべての Pod がRunningステータスに移行します。SR-IOV ネットワークデバイスが設定されていることを確認するには、以下のコマンドを実行します。
<node_name>を、設定したばかりの SR-IOV ネットワークデバイスを持つノードの名前に置き換えます。oc get sriovnetworknodestates -n openshift-sriov-network-operator <node_name> -o jsonpath='{.status.syncStatus}'$ oc get sriovnetworknodestates -n openshift-sriov-network-operator <node_name> -o jsonpath='{.status.syncStatus}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow
8.4.3. 次のステップ リンクのコピーリンクがクリップボードにコピーされました!
8.5. SR-IOV イーサネットネットワーク割り当ての設定 リンクのコピーリンクがクリップボードにコピーされました!
クラスター内の Single Root I/O Virtualization (SR-IOV) デバイスのイーサネットネットワーク割り当てを設定できます。
8.5.1. イーサネットデバイス設定オブジェクト リンクのコピーリンクがクリップボードにコピーされました!
イーサネットネットワークデバイスは、SriovNetwork オブジェクトを定義して設定できます。
以下の YAML は SriovNetwork オブジェクトについて説明しています。
- 1
- オブジェクトの名前。SR-IOV Network Operator は、同じ名前を持つ
NetworkAttachmentDefinitionオブジェクトを作成します。 - 2
- SR-IOV Network Operator がインストールされている namespace を指定します。
- 3
- この追加ネットワークの SR-IOV ハードウェアを定義する
SriovNetworkNodePolicyオブジェクトのspec.resourceNameパラメーターの値。 - 4
SriovNetworkオブジェクトのターゲット namespace。ターゲット namespace の Pod のみを追加ネットワークに割り当てることができます。- 5
- オプション: 追加ネットワークの仮想 LAN (VLAN) ID。整数値は
0から4095である必要があります。デフォルト値は0です。 - 6
- オプション: VF の spoof チェックモード。許可される値は、文字列の
"on"および"off"です。重要指定する値を引用符で囲む必要があります。そうしないと、オブジェクトは SR-IOV ネットワーク Operator によって拒否されます。
- 7
- YAML ブロックスケーラーとしての IPAM CNI プラグインの設定オブジェクトプラグインは、割り当て定義についての IP アドレスの割り当てを管理します。
- 8
- オプション: Virtual Function (VF) のリンク状態。許可される値は、
enable、disable、およびautoです。 - 9
- オプション: VF の最大伝送レート (Mbps)。
- 10
- オプション: VF の最小伝送レート (Mbps)。この値は、最大伝送レート以下である必要があります。注記
Intel NIC は
minTxRateパラメーターをサポートしません。詳細は、BZ#1772847 を参照してください。 - 11
- オプション: VF の IEEE 802.1p 優先度レベル。デフォルト値は
0です。 - 12
- オプション: VF の信頼モード。許可される値は、文字列の
"on"および"off"です。重要指定する値を引用符で囲む必要があります。囲まないと、SR-IOV Network Operator はオブジェクトを拒否します。
- 13
- オプション: この追加ネットワークに設定する機能。IP アドレスのサポートを有効にするには、
"{ "ips": true }"を指定できます。または、MAC アドレスのサポートを有効にするには"{ "mac": true }"を指定します。
8.5.1.1. IPAM CNI プラグインの設定 リンクのコピーリンクがクリップボードにコピーされました!
IPAM Container Network Interface (CNI) プラグインは、他の CNI プラグインに IP アドレス管理 (IPAM) を提供します。DHCP を使用して、静的 IP アドレスの割り当てまたは動的 IP アドレスの割り当てのいずれかに IPAM を設定することができます。指定する DHCP サーバーは、追加のネットワークから到達可能である必要があります。
以下の JSON 設定オブジェクトは設定できるパラメーターについて説明しています。
8.5.1.1.1. 静的 IP アドレス割り当ての設定 リンクのコピーリンクがクリップボードにコピーされました!
以下の JSON は、静的 IP アドレスの割り当ての設定について説明しています。
静的割り当ての設定
- 1
- 仮想インターフェイスに割り当てる IP アドレスを記述する配列。IPv4 と IPv6 の IP アドレスの両方がサポートされます。
- 2
- 指定する IP アドレスおよびネットワーク接頭辞。たとえば、
10.10.21.10/24を指定すると、追加のネットワークに IP アドレスの10.10.21.10が割り当てられ、ネットマスクは255.255.255.0になります。 - 3
- egress ネットワークトラフィックをルーティングするデフォルトのゲートウェイ。
- 4
- Pod 内で設定するルートを記述する配列。
- 5
- CIDR 形式の IP アドレス範囲 (
192.168.17.0/24、またはデフォルトルートの0.0.0.0/0)。 - 6
- ネットワークトラフィックがルーティングされるゲートウェイ。
- 7
- オプション: DNS 設定。
- 8
- DNS クエリーの送信先となる 1 つ以上の IP アドレスの配列。
- 9
- ホスト名に追加するデフォルトのドメイン。たとえば、ドメインが
example.comに設定されている場合、example-hostの DNS ルックアップクエリーはexample-host.example.comとして書き換えられます。 - 10
- DNS ルックアップのクエリー時に非修飾ホスト名に追加されるドメイン名の配列 (例:
example-host)。
8.5.1.1.2. 動的 IP アドレス割り当ての設定 リンクのコピーリンクがクリップボードにコピーされました!
以下の JSON は、DHCP を使用した動的 IP アドレスの割り当ての設定について説明しています。
Pod は、作成時に元の DHCP リースを取得します。リースは、クラスターで実行している最小限の DHCP サーバーデプロイメントで定期的に更新する必要があります。
SR-IOV ネットワーク Operator は DHCP サーバーデプロイメントを作成しません。Cluster Network Operator は最小限の DHCP サーバーデプロイメントを作成します。
DHCP サーバーのデプロイメントをトリガーするには、以下の例にあるように Cluster Network Operator 設定を編集して shim ネットワーク割り当てを作成する必要があります。
shim ネットワーク割り当ての定義例
DHCP 割り当ての設定
{
"ipam": {
"type": "dhcp"
}
}
{
"ipam": {
"type": "dhcp"
}
}
8.5.1.1.3. 静的 IP アドレス割り当ての設定例 リンクのコピーリンクがクリップボードにコピーされました!
静的 IP アドレスの割り当てに IPAM を設定することができます。
8.5.1.1.4. DHCP を使用した動的 IP アドレス割り当ての設定例 リンクのコピーリンクがクリップボードにコピーされました!
DHCP に IPAM を設定できます。
{
"ipam": {
"type": "dhcp"
}
}
{
"ipam": {
"type": "dhcp"
}
}
8.5.2. SR-IOV の追加ネットワークの設定 リンクのコピーリンクがクリップボードにコピーされました!
SriovNetwork オブジェクト を作成して、SR-IOV ハードウェアを使用する追加のネットワークを設定できます。SriovNetwork オブジェクトの作成時に、SR-IOV Operator は NetworkAttachmentDefinition オブジェクトを自動的に作成します。
SriovNetwork オブジェクトが running 状態の Pod に割り当てられている場合、これを変更したり、削除したりしないでください。
前提条件
-
OpenShift CLI (
oc) をインストールしている。 -
cluster-admin権限を持つユーザーとしてログインしている。
手順
SriovNetworkオブジェクトを作成してから、YAML を<name>.yamlファイルに保存します。<name>はこの追加ネットワークの名前になります。オブジェクト仕様は以下の例のようになります。Copy to Clipboard Copied! Toggle word wrap Toggle overflow オブジェクトを作成するには、以下のコマンドを入力します。
oc create -f <name>.yaml
$ oc create -f <name>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow ここで、
<name>は追加ネットワークの名前を指定します。オプション: 以下のコマンドを実行して、直前の手順で作成した
SriovNetworkオブジェクトに関連付けられたNetworkAttachmentDefinitionオブジェクトが存在することを確認するには、以下のコマンドを入力します。<namespace>をSriovNetworkオブジェクトで指定した networkNamespace に置き換えます。oc get net-attach-def -n <namespace>
$ oc get net-attach-def -n <namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
8.5.3. 次のステップ リンクのコピーリンクがクリップボードにコピーされました!
8.5.4. 関連情報 リンクのコピーリンクがクリップボードにコピーされました!
8.6. Pod の SR-IOV の追加ネットワークへの追加 リンクのコピーリンクがクリップボードにコピーされました!
Pod を既存の Single Root I/O Virtualization (SR-IOV) ネットワークに追加できます。
8.6.1. ネットワーク割り当てのランタイム設定 リンクのコピーリンクがクリップボードにコピーされました!
Pod を追加のネットワークに割り当てる場合、ランタイム設定を指定して Pod の特定のカスタマイズを行うことができます。たとえば、特定の MAC ハードウェアアドレスを要求できます。
Pod 仕様にアノテーションを設定して、ランタイム設定を指定します。アノテーションキーは k8s.v1.cni.cncf.io/networks で、ランタイム設定を記述する JSON オブジェクトを受け入れます。
8.6.1.1. イーサネットベースの SR-IOV 割り当てのランタイム設定 リンクのコピーリンクがクリップボードにコピーされました!
以下の JSON は、イーサネットベースの SR-IOV ネットワーク割り当て用のランタイム設定オプションを説明しています。
- 1
- SR-IOV ネットワーク割り当て定義 CR の名前。
- 2
- オプション: SR-IOV ネットワーク割り当て定義 CR で定義されるリソースタイプから割り当てられる SR-IOV デバイスの MAC アドレス。この機能を使用するには、
SriovNetworkオブジェクトで{ "mac": true }も指定する必要があります。 - 3
- オプション: SR-IOV ネットワーク割り当て定義 CR で定義されるリソースタイプから割り当てられる SR-IOV デバイスの IP アドレス。IPv4 と IPv6 アドレスの両方がサポートされます。この機能を使用するには、
SriovNetworkオブジェクトで{ "ips": true }も指定する必要があります。
ランタイム設定の例
8.6.2. Pod の追加ネットワークへの追加 リンクのコピーリンクがクリップボードにコピーされました!
Pod を追加のネットワークに追加できます。Pod は、デフォルトネットワークで通常のクラスター関連のネットワークトラフィックを継続的に送信します。
Pod が作成されると、追加のネットワークが割り当てられます。ただし、Pod がすでに存在する場合は、追加のネットワークをこれに割り当てることはできません。
Pod が追加ネットワークと同じ namespace にあること。
ネットワークの割り当てが SR-IOV Network Operator によって管理される場合、SR-IOV Network Resource Injector は resource フィールドを Pod オブジェクトに自動的に追加します。
Deployment オブジェクトまたは ReplicationController オブジェクトの SR-IOV ハードウェアネットワークを指定する場合、 NetworkAttachmentDefinition オブジェクトの namespace を指定する必要があります。詳細は、以下の BZ#1846333 および BZ#1840962 のバグを参照してください。
前提条件
-
OpenShift CLI (
oc) をインストールしている。 - クラスターにログインする。
- SR-IOV Operator のインストール。
-
Pod を割り当てる
SriovNetworkオブジェクトを作成します。
手順
アノテーションを
Podオブジェクトに追加します。以下のアノテーション形式のいずれかのみを使用できます。カスタマイズせずに追加ネットワークを割り当てるには、以下の形式でアノテーションを追加します。
<network>を、Pod に関連付ける追加ネットワークの名前に置き換えます。metadata: annotations: k8s.v1.cni.cncf.io/networks: <network>[,<network>,...]metadata: annotations: k8s.v1.cni.cncf.io/networks: <network>[,<network>,...]1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 複数の追加ネットワークを指定するには、各ネットワークをコンマで区切ります。コンマの間にはスペースを入れないでください。同じ追加ネットワークを複数回指定した場合、Pod は複数のネットワークインターフェイスをそのネットワークに割り当てます。
カスタマイズして追加のネットワークを割り当てるには、以下の形式でアノテーションを追加します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Pod を作成するには、以下のコマンドを入力します。
<name>を Pod の名前に置き換えます。oc create -f <name>.yaml
$ oc create -f <name>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow オプション: アノテーションが
PodCR に存在することを確認するには、<name>を Pod の名前に置き換えて、以下のコマンドを入力します。oc get pod <name> -o yaml
$ oc get pod <name> -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下の例では、
example-podPod が追加ネットワークのnet1に割り当てられています。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
k8s.v1.cni.cncf.io/networks-statusパラメーターは、オブジェクトの JSON 配列です。各オブジェクトは、Pod に割り当てられる追加のネットワークのステータスについて説明します。アノテーションの値はプレーンテキストの値として保存されます。
8.6.3. Non-Uniform Memory Access (NUMA) で配置された SR-IOV Pod の作成 リンクのコピーリンクがクリップボードにコピーされました!
NUMA で配置された SR-IOV Pod は、restricted または single-numa-node Topology Manager ポリシーで同じ NUMA ノードから割り当てられる SR-IOV および CPU リソースを制限することによって作成できます。
前提条件
-
OpenShift CLI (
oc) をインストールすること。 -
LatencySensitive プロファイルを有効にし、CPU マネージャーのポリシーを
staticに設定する。
手順
以下の SR-IOV Pod 仕様を作成してから、YAML を
<name>-sriov-pod.yamlファイルに保存します。<name>をこの Pod の名前に置き換えます。以下の例は、SR-IOV Pod 仕様を示しています。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行して SR-IOV Pod のサンプルを作成します。
oc create -f <filename>
$ oc create -f <filename>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<filename>を、先の手順で作成したファイルの名前に置き換えます。
sample-podが Guaranteed QoS を指定して設定されていることを確認します。oc describe pod sample-pod
$ oc describe pod sample-podCopy to Clipboard Copied! Toggle word wrap Toggle overflow sample-podが排他的 CPU を指定して割り当てられていることを確認します。oc exec sample-pod -- cat /sys/fs/cgroup/cpuset/cpuset.cpus
$ oc exec sample-pod -- cat /sys/fs/cgroup/cpuset/cpuset.cpusCopy to Clipboard Copied! Toggle word wrap Toggle overflow sample-podに割り当てられる SR-IOV デバイスと CPU が同じ NUMA ノード上にあることを確認します。oc exec sample-pod -- cat /sys/fs/cgroup/cpuset/cpuset.cpus
$ oc exec sample-pod -- cat /sys/fs/cgroup/cpuset/cpuset.cpusCopy to Clipboard Copied! Toggle word wrap Toggle overflow
8.6.4. 関連情報 リンクのコピーリンクがクリップボードにコピーされました!
8.7. 高パフォーマンスのマルチキャストの使用 リンクのコピーリンクがクリップボードにコピーされました!
Single Root I/O Virtualization (SR-IOV) ハードウェアネットワーク上でマルチキャストを使用できます。
8.7.1. 高パフォーマンスのマルチキャストの設定 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift SDN デフォルト Container Network Interface (CNI) ネットワークプロバイダーは、デフォルトネットワーク上の Pod 間のマルチキャストをサポートします。これは低帯域幅の調整またはサービスの検出での使用に最も適しており、高帯域幅のアプリケーションには適していません。インターネットプロトコルテレビ (IPTV) やマルチポイントビデオ会議など、ストリーミングメディアなどのアプリケーションでは、Single Root I/O Virtualization (SR-IOV) ハードウェアを使用してネイティブに近いパフォーマンスを提供できます。
マルチキャストに追加の SR-IOV インターフェイスを使用する場合:
- マルチキャストパッケージは、追加の SR-IOV インターフェイス経由で Pod によって送受信される必要があります。
- SR-IOV インターフェイスに接続する物理ネットワークは、OpenShift Container Platform で制御されないマルチキャストルーティングとトポロジーを判別します。
8.7.2. マルチキャストでの SR-IOV インターフェイスの使用 リンクのコピーリンクがクリップボードにコピーされました!
以下の手順では、サンプルのマルチキャスト用の SR-IOV インターフェイスを作成します。
前提条件
-
OpenShift CLI (
oc) をインストールしている。 -
cluster-adminロールを持つユーザーとしてクラスターにログインする必要があります。
手順
SriovNetworkNodePolicyオブジェクトを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow SriovNetworkオブジェクトを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow マルチキャストアプリケーションで Pod を作成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
NET_ADMIN機能は、アプリケーションがマルチキャスト IP アドレスを SR-IOV インターフェイスに割り当てる必要がある場合にのみ必要です。それ以外の場合は省略できます。
8.8. DPDK および RDMA モードでの仮想機能 (VF) の使用 リンクのコピーリンクがクリップボードにコピーされました!
Single Root I/O Virtualization (SR-IOV) ネットワークハードウェアは、Data Plane Development Kit (DPDK) および Remote Direct Memory Access (RDMA) で利用できます。
8.8.1. DPDK および RDMA モードでの仮想機能 (VF) の使用例 リンクのコピーリンクがクリップボードにコピーされました!
Data Plane Development Kit (DPDK) はテクノロジープレビュー機能です。テクノロジープレビュー機能は Red Hat の実稼働環境でのサービスレベルアグリーメント (SLA) ではサポートされていないため、Red Hat では実稼働環境での使用を推奨していません。Red Hat は実稼働環境でこれらを使用することを推奨していません。テクノロジープレビューの機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲についての詳細は、https://access.redhat.com/ja/support/offerings/techpreview/ を参照してください。
Remote Direct Memory Access (RDMA) はテクノロジープレビュー機能です。テクノロジープレビュー機能は Red Hat の実稼働環境でのサービスレベルアグリーメント (SLA) ではサポートされていないため、Red Hat では実稼働環境での使用を推奨していません。Red Hat は実稼働環境でこれらを使用することを推奨していません。テクノロジープレビューの機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
8.8.2. 前提条件 リンクのコピーリンクがクリップボードにコピーされました!
-
OpenShift CLI (
oc) をインストールしている。 -
cluster-admin権限を持つユーザーとしてログインしている。 - SR-IOV Network Operator がインストールされていること。
8.8.3. Intel NIC を使用した DPDK モードでの仮想機能 (VF) の使用例 リンクのコピーリンクがクリップボードにコピーされました!
手順
以下の
SriovNetworkNodePolicyオブジェクトを作成してから、YAML をintel-dpdk-node-policy.yamlファイルに保存します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 仮想機能 (VF) のドライバータイプを
vfio-pciに指定します。
注記SriovNetworkNodePolicyの各オプションに関する詳細は、SR-IOV ネットワークデバイスの設定セクションを参照してください。SriovNetworkNodePolicyオブジェクトで指定された設定を適用する際に、SR-IOV Operator はノードをドレイン (解放) する可能性があり、場合によってはノードの再起動を行う場合があります。設定の変更が適用されるまでに数分の時間がかかる場合があります。エビクトされたワークロードを処理するために、クラスター内に利用可能なノードが十分にあることを前もって確認します。設定の更新が適用された後に、
openshift-sriov-network-operatornamespace のすべての Pod がRunningステータスに変更されます。以下のコマンドを実行して
SriovNetworkNodePolicyオブジェクトを作成します。oc create -f intel-dpdk-node-policy.yaml
$ oc create -f intel-dpdk-node-policy.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下の
SriovNetworkオブジェクトを作成してから、YAML をintel-dpdk-network.yamlファイルに保存します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- IPAM CNI プラグインの空のオブジェクト
"{}"を指定します。DPDK はユーザー空間モードで機能し、IP アドレスは必要ありません。
注記SriovNetworkの各オプションに関する詳細は、SR-IOV の追加ネットワークの設定セクションを参照してください。以下のコマンドを実行して
SriovNetworkNodePolicyオブジェクトを作成します。oc create -f intel-dpdk-network.yaml
$ oc create -f intel-dpdk-network.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下の
Pod仕様を作成してから、YAML をintel-dpdk-pod.yamlファイルに保存します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
SriovNetworkオブジェクトのintel-dpdk-networkが作成される同じtarget_namespaceを指定します。Pod を異なる namespace に作成する場合、target_namespaceをPod仕様およびSriovNetowrkオブジェクトの両方で変更します。- 2
- アプリケーションとアプリケーションが使用する DPDK ライブラリーが含まれる DPDK イメージを指定します。
- 3
- コンテナー内の hugepage メモリーを割り当てるためにアプリケーションが必要とする
IPC_LOCK機能を指定します。 - 4
- hugepage ボリュームを、
/dev/hugepagesの下にある DPDK Pod にマウントします。hugepage ボリュームは、medium がHugepagesに指定されている emptyDir ボリュームタイプでサポートされます。 - 5
- オプション: DPDK Pod に割り当てられる DPDK デバイスの数を指定します。このリソース要求および制限は、明示的に指定されていない場合、SR-IOV ネットワークリソースインジェクターによって自動的に追加されます。SR-IOV ネットワークリソースインジェクターは、SR-IOV Operator によって管理される受付コントローラーコンポーネントです。これはデフォルトで有効にされており、デフォルト
SriovOperatorConfigCR でenableInjectorオプションをfalseに設定して無効にすることができます。 - 6
- CPU の数を指定します。DPDK Pod には通常、kubelet から排他的 CPU を割り当てる必要があります。これは、CPU マネージャーポリシーを
staticに設定し、GuaranteedQoS を持つ Pod を作成して実行されます。 - 7
- hugepage サイズ
hugepages-1Giまたはhugepages-2Miを指定し、DPDK Pod に割り当てられる hugepage の量を指定します。2Miおよび1Gihugepage を別々に設定します。1Gihugepage を設定するには、カーネル引数をノードに追加する必要があります。たとえば、カーネル引数default_hugepagesz=1GB、hugepagesz=1Gおよびhugepages=16を追加すると、16*1Gihugepage がシステムの起動時に割り当てられます。
以下のコマンドを実行して DPDK Pod を作成します。
oc create -f intel-dpdk-pod.yaml
$ oc create -f intel-dpdk-pod.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
8.8.4. Mellanox NIC を使用した DPDK モードでの仮想機能 (VF) の使用例 リンクのコピーリンクがクリップボードにコピーされました!
手順
以下の
SriovNetworkNodePolicyオブジェクトを作成してから、YAML をmlx-dpdk-node-policy.yamlファイルに保存します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記SriovNetworkNodePolicyの各オプションに関する詳細は、SR-IOV ネットワークデバイスの設定セクションを参照してください。SriovNetworkNodePolicyオブジェクトで指定された設定を適用する際に、SR-IOV Operator はノードをドレイン (解放) する可能性があり、場合によってはノードの再起動を行う場合があります。設定の変更が適用されるまでに数分の時間がかかる場合があります。エビクトされたワークロードを処理するために、クラスター内に利用可能なノードが十分にあることを前もって確認します。設定の更新が適用された後に、
openshift-sriov-network-operatornamespace のすべての Pod がRunningステータスに変更されます。以下のコマンドを実行して
SriovNetworkNodePolicyオブジェクトを作成します。oc create -f mlx-dpdk-node-policy.yaml
$ oc create -f mlx-dpdk-node-policy.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下の
SriovNetworkオブジェクトを作成してから、YAML をmlx-dpdk-network.yamlファイルに保存します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- IPAM CNI プラグインの設定オブジェクトを YAML ブロックスケーラーとして指定します。プラグインは、割り当て定義についての IP アドレスの割り当てを管理します。
注記SriovNetworkの各オプションに関する詳細は、SR-IOV の追加ネットワークの設定セクションを参照してください。以下のコマンドを実行して
SriovNetworkNodePolicyオブジェクトを作成します。oc create -f mlx-dpdk-network.yaml
$ oc create -f mlx-dpdk-network.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下の
Pod仕様を作成してから、YAML をmlx-dpdk-pod.yamlファイルに保存します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
SriovNetworkオブジェクトのmlx-dpdk-networkが作成される同じtarget_namespaceを指定します。Pod を異なる namespace に作成する場合、target_namespaceをPod仕様およびSriovNetowrkオブジェクトの両方で変更します。- 2
- アプリケーションとアプリケーションが使用する DPDK ライブラリーが含まれる DPDK イメージを指定します。
- 3
- コンテナー内の hugepage メモリーを割り当てるためにアプリケーションが必要とする
IPC_LOCK機能、およびアプリケーションがネットワークインターフェイスにアクセスするためにNET_RAWを指定します。 - 4
- hugepage ボリュームを、
/dev/hugepagesの下にある DPDK Pod にマウントします。hugepage ボリュームは、medium がHugepagesに指定されている emptyDir ボリュームタイプでサポートされます。 - 5
- オプション: DPDK Pod に割り当てられる DPDK デバイスの数を指定します。このリソース要求および制限は、明示的に指定されていない場合、SR-IOV ネットワークリソースインジェクターによって自動的に追加されます。SR-IOV ネットワークリソースインジェクターは、SR-IOV Operator によって管理される受付コントローラーコンポーネントです。これはデフォルトで有効にされており、デフォルト
SriovOperatorConfigCR でenableInjectorオプションをfalseに設定して無効にすることができます。 - 6
- CPU の数を指定します。DPDK Pod には通常、kubelet から排他的 CPU を割り当てる必要があります。これは、CPU マネージャーポリシーを
staticに設定し、GuaranteedQoS を持つ Pod を作成して実行されます。 - 7
- hugepage サイズ
hugepages-1Giまたはhugepages-2Miを指定し、DPDK Pod に割り当てられる hugepage の量を指定します。2Miおよび1Gihugepage を別々に設定します。1Gihugepage を設定するには、カーネル引数をノードに追加する必要があります。
以下のコマンドを実行して DPDK Pod を作成します。
oc create -f mlx-dpdk-pod.yaml
$ oc create -f mlx-dpdk-pod.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
8.8.5. Mellanox NIC を使った RDMA モードでの仮想機能 (VF) の例 リンクのコピーリンクがクリップボードにコピーされました!
RoCE (RDMA over Converged Ethernet) は、OpenShift Container Platform で RDMA を使用する場合に唯一サポートされているモードです。
手順
以下の
SriovNetworkNodePolicyオブジェクトを作成してから、YAML をmlx-rdma-node-policy.yamlファイルに保存します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記SriovNetworkNodePolicyの各オプションに関する詳細は、SR-IOV ネットワークデバイスの設定セクションを参照してください。SriovNetworkNodePolicyオブジェクトで指定された設定を適用する際に、SR-IOV Operator はノードをドレイン (解放) する可能性があり、場合によってはノードの再起動を行う場合があります。設定の変更が適用されるまでに数分の時間がかかる場合があります。エビクトされたワークロードを処理するために、クラスター内に利用可能なノードが十分にあることを前もって確認します。設定の更新が適用された後に、
openshift-sriov-network-operatornamespace のすべての Pod がRunningステータスに変更されます。以下のコマンドを実行して
SriovNetworkNodePolicyオブジェクトを作成します。oc create -f mlx-rdma-node-policy.yaml
$ oc create -f mlx-rdma-node-policy.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下の
SriovNetworkオブジェクトを作成してから、YAML をmlx-rdma-network.yamlファイルに保存します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- IPAM CNI プラグインの設定オブジェクトを YAML ブロックスケーラーとして指定します。プラグインは、割り当て定義についての IP アドレスの割り当てを管理します。
注記SriovNetworkの各オプションに関する詳細は、SR-IOV の追加ネットワークの設定セクションを参照してください。以下のコマンドを実行して
SriovNetworkNodePolicyオブジェクトを作成します。oc create -f mlx-rdma-network.yaml
$ oc create -f mlx-rdma-network.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下の
Pod仕様を作成してから、YAML をmlx-rdma-pod.yamlファイルに保存します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
SriovNetworkオブジェクトのmlx-rdma-networkが作成される同じtarget_namespaceを指定します。Pod を異なる namespace に作成する場合、target_namespaceをPod仕様およびSriovNetowrkオブジェクトの両方で変更します。- 2
- アプリケーションとアプリケーションが使用する RDMA ライブラリーが含まれる RDMA イメージを指定します。
- 3
- コンテナー内の hugepage メモリーを割り当てるためにアプリケーションが必要とする
IPC_LOCK機能を指定します。 - 4
- hugepage ボリュームを、
/dev/hugepagesの下にある RDMA Pod にマウントします。hugepage ボリュームは、medium がHugepagesに指定されている emptyDir ボリュームタイプでサポートされます。 - 5
- CPU の数を指定します。RDMA Pod には通常、kubelet から排他的 CPU を割り当てる必要があります。これは、CPU マネージャーポリシーを
staticに設定し、GuaranteedQoS を持つ Pod を作成して実行されます。 - 6
- hugepage サイズ
hugepages-1Giまたはhugepages-2Miを指定し、RDMA Pod に割り当てられる hugepage の量を指定します。2Miおよび1Gihugepage を別々に設定します。1Gihugepage を設定するには、カーネル引数をノードに追加する必要があります。
以下のコマンドを実行して RDMA Pod を作成します。
oc create -f mlx-rdma-pod.yaml
$ oc create -f mlx-rdma-pod.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
第9章 OpenShift SDN デフォルト CNI ネットワークプロバイダー リンクのコピーリンクがクリップボードにコピーされました!
9.1. OpenShift SDN デフォルト CNI ネットワークプロバイダーについて リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform は、Software Defined Networking (SDN) アプローチを使用して、クラスターのネットワークを統合し、OpenShift Container Platform クラスターの Pod 間の通信を可能にします。OpenShift SDN により、このような Pod ネットワークが確立され、メンテナーンスされます。 OpenShift SDN は Open vSwitch (OVS) を使用してオーバーレイネットワークを設定します。
OpenShift SDN では以下のように、Pod ネットワークを設定するための SDN モードを 3 つ提供します。
- ネットワークポリシーモードは、プロジェクト管理者が NetworkPolicy オブジェクト を使用して独自の分離ポリシーを設定することを可能にします。ネットワークポリシーは、OpenShift Container Platform 4.4 のデフォルトモードです。
- multitenant モードは、Pod およびサービスのプロジェクトレベルの分離を行います。異なるプロジェクトの Pod は、異なるプロジェクトの Pod およびサービスにパケットを送信したり、それらからパケットを受信したりすることができません。プロジェクトの分離を無効にし、クラスター全体のすべての Pod およびサービスにネットワークトラフィックを送信したり、それらの Pod およびサービスからネットワークトラフィックを受信したりすることができます。
- サブネット モードは、すべての Pod が他のすべての Pod およびサービスと通信できる Pod ネットワークを提供します。ネットワークポリシーモードは、サブネットモードと同じ機能を提供します。
9.1.1. サポートされるデフォルトの CNI ネットワークプロバイダー機能マトリクス リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform は、OpenShift SDN と OVN-Kubernetes の 2 つのサポート対象のオプションをデフォルトの Container Network Interface (CNI) ネットワークプロバイダーに提供します。以下の表は、両方のネットワークプロバイダーの現在の機能サポートをまとめたものです。
| 機能 | OpenShift SDN | OVN-Kubernetes [1] |
|---|---|---|
| Egress IP | サポート対象 | サポート対象外 |
| Egress ファイアウォール [2] | サポート対象 | サポート対象外 |
| Egress ルーター | サポート対象 | サポート対象外 |
| Kubernetes ネットワークポリシー | 一部サポート対象 [3] | サポート対象 |
| マルチキャスト | サポート対象 | サポート対象 |
- OpenShift Container Platform 4.4 では、テクノロジープレビュー機能としてのみ利用できます。
- egress ファイアウォールは、OpenShift SDN では egress ネットワークポリシーとしても知られています。これはネットワークポリシーの egress とは異なります。
-
egress ルールおよび一部の
ipBlockルールをサポートしません。
9.2. プロジェクトの egress IP の設定 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、OpenShift SDN デフォルト Container Network Interface (CNI) ネットワークプロバイダーが 1 つ以上の egress IP アドレスをプロジェクトに割り当てるように設定できます。
9.2.1. プロジェクトの egress トラフィックについての egress IP アドレスの割り当て リンクのコピーリンクがクリップボードにコピーされました!
プロジェクトの egress IP アドレスを設定することにより、指定されたプロジェクトからのすべての外部送信接続が同じ固定ソース IP アドレスを共有します。外部リソースは、egress IP アドレスに基づいて特定のプロジェクトからのトラフィックを認識できます。プロジェクトに割り当てられる egress IP アドレスは、トラフィックを特定の宛先に送信するために使用される egress ルーターとは異なります。
egress IP アドレスは、ノードのプライマリーネットワークインターフェイスの追加 IP アドレスとして実装され、ノードのプライマリー IP アドレスと同じサブネットにある必要があります。
egress IP アドレスは、ifcfg-eth0 などのように Linux ネットワーク設定ファイルで設定することはできません。
一部のクラウドまたは仮想マシンソリューションを使用する場合に、プライマリーネットワークインターフェイスで追加の IP アドレスを許可するには追加の設定が必要になる場合があります。
egress IP アドレスは、NetNamespace オブジェクトの egressIPs パラメーターを設定して namespace に割り当てることができます。egress IP がプロジェクトに関連付けられた後に、 OpenShift SDN は 2 つの方法で Egress IP をホストに割り当てることを可能にします。
- 自動的に割り当てる 方法では、egress IP アドレス範囲はノードに割り当てられます。
- 手動で割り当てる 方法では、1 つ以上の egress IP アドレスの一覧がノードに割り当てられます。
egress IP アドレスを要求する namespace は、それらの egress IP アドレスをホストできるノードに一致し、egress IP アドレスはそれらのノードに割り当てられます。egressIPs パラメーターが NetNamespace オブジェクトに設定されるものの、ノードがその egress IP アドレスをホストしない場合、namespace からの egress トラフィックはドロップされます。
ノードの高可用性は自動的に実行されます。egress IP アドレスをホストするノードが到達不可能であり、egress IP アドレスをホストできるノードがある場合、egress IP アドレスは新規ノードに移行します。到達不可能なノードが再びオンラインに戻ると、ノード間で egress IP アドレスのバランスを図るために egress IP アドレスは自動的に移行します。
手動で割り当てられた egress IP アドレスと、自動的に割り当てられた egress IP アドレスは同じノードで使用することができません。IP アドレス範囲から egress IP アドレスを手動で割り当てる場合、その範囲を自動の IP 割り当てで利用可能にすることはできません。
OpenShift SDN をマルチテナントモードで使用する場合、それらに関連付けられたプロジェクトによって別の namespace に参加している namespace と共に egress IP アドレスを使用することはできません。たとえば、project1 および project2 に oc adm pod-network join-projects --to=project1 project2 コマンドを実行して参加している場合、どちらもプロジェクトも egress IP アドレスを使用できません。詳細は、BZ#1645577 を参照してください。
9.2.1.1. 自動的に割り当てられた egress IP アドレスを使用する場合の考慮事項 リンクのコピーリンクがクリップボードにコピーされました!
egress IP アドレスの自動割り当て方法を使用する場合、以下の考慮事項が適用されます。
-
各ノードの
HostSubnetリソースのegressCIDRsパラメーターを設定して、ノードでホストできる egress IP アドレスの範囲を指定します。OpenShift Container Platform は、指定する IP アドレス範囲に基づいてHostSubnetリソースのegressIPsパラメーターを設定します。 - 自動割り当てモードを使用する場合、namespace ごとに単一の egress IP アドレスのみがサポートされます。
namespace の egress IP アドレスをホストするノードに到達できない場合、OpenShift Container Platform は互換性のある egress IP アドレス範囲を持つ別のノードに egress IP アドレスを再割り当てします。自動割り当て方法は、追加の IP アドレスをノードに関連付ける柔軟性のある環境にインストールされたクラスターに最も適しています。
9.2.1.2. 手動で割り当てられた egress IP アドレスを使用する場合の考慮事項 リンクのコピーリンクがクリップボードにコピーされました!
egress IP アドレスに手動割り当て方法を使用する場合、以下の考慮事項が適用されます。
-
各ノードの
HostSubnetリソースのegressIPsパラメーターを設定して、ノードでホストできる IP アドレスを指定します。 - namespace ごとに複数の egress IP アドレスがサポートされます。
namespace に複数の egress IP アドレスがある場合、最初の egress IP アドレスをホストするノードに到達できない場合、OpenShift Container Platform は最初の egress IP アドレスが再び到達可能になるまで、次に利用可能な egress IP アドレスの使用に自動的に切り替えます。
この方法は、パブリッククラウド環境にインストールされたクラスター用に推奨されます。この場合、追加の IP アドレスをノードに関連付ける上で制限がある場合があります。
9.2.2. namespace の自動的に割り当てられた egress IP アドレスの有効化 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform では、1 つ以上のノードで特定の namespace の egress IP アドレスの自動的な割り当てを有効にできます。
前提条件
-
OpenShift CLI (
oc) をインストールしている。 -
cluster-adminロールを持つユーザーとしてクラスターにアクセスできる。
手順
以下の JSON を使用して、
NetNamespaceオブジェクトを egress IP アドレスで更新します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow たとえば、
project1を IP アドレスの 192.168.1.100 に、project2を IP アドレスの 192.168.1.101 に割り当てるには、以下を実行します。oc patch netnamespace project1 --type=merge -p \ '{"egressIPs": ["192.168.1.100"]}' oc patch netnamespace project2 --type=merge -p \ '{"egressIPs": ["192.168.1.101"]}'$ oc patch netnamespace project1 --type=merge -p \ '{"egressIPs": ["192.168.1.100"]}' $ oc patch netnamespace project2 --type=merge -p \ '{"egressIPs": ["192.168.1.101"]}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下の JSON を使用して、各ホストの
egressCIDRsパラメーターを設定して egress IP アドレスをホストできるノードを示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow たとえば、
node1およびnode2を、192.168.1.0 から 192.168.1.255 の範囲で egress IP アドレスをホストするように設定するには、以下を実行します。oc patch hostsubnet node1 --type=merge -p \ '{"egressCIDRs": ["192.168.1.0/24"]}' oc patch hostsubnet node2 --type=merge -p \ '{"egressCIDRs": ["192.168.1.0/24"]}'$ oc patch hostsubnet node1 --type=merge -p \ '{"egressCIDRs": ["192.168.1.0/24"]}' $ oc patch hostsubnet node2 --type=merge -p \ '{"egressCIDRs": ["192.168.1.0/24"]}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow OpenShift Container Platform はバランスを取りながら特定の egress IP アドレスを利用可能なノードに自動的に割り当てます。この場合、egress IP アドレス 192.168.1.100 を
node1に、egress IP アドレス 192.168.1.101 をnode2に割り当て、その逆も行います。
9.2.3. namespace の手動で割り当てられた egress IP アドレスの設定 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform で、1 つ以上の egress IP アドレスを namespace に関連付けることができます。
前提条件
-
OpenShift CLI (
oc) をインストールしている。 -
cluster-adminロールを持つユーザーとしてクラスターにアクセスできる。
手順
以下の JSON オブジェクトを必要な IP アドレスで指定して、
NetNamespaceオブジェクトを更新します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow たとえば、
project1プロジェクトを192.168.1.100の IP アドレスに割り当てるには、以下を実行します。oc patch netnamespace project1 --type=merge \ -p '{"egressIPs": ["192.168.1.100"]}'$ oc patch netnamespace project1 --type=merge \ -p '{"egressIPs": ["192.168.1.100"]}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow egressIPsを異なるノードの 2 つ以上の IP アドレスに設定し、高可用性を確保することができます。複数の egress IP アドレスが設定される場合、Pod は egress の一覧にある最初の IP を使用しますが、IP アドレスをホストするノードが失敗する場合、Pod は短時間の遅延の後に一覧にある次の IP の使用に切り替えます。egress IP をノードホストに手動で割り当てます。
egressIPsパラメーターを、ノードホストのHostSubnetオブジェクトに設定します。以下の JSON を使用して、そのノードホストに割り当てる必要のある任意の数の IP を含めることができます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow たとえば、
node1に Egress IP192.168.1.100、192.168.1.101、および192.168.1.102が設定されるように指定するには、以下を実行します。oc patch hostsubnet node1 --type=merge -p \ '{"egressIPs": ["192.168.1.100", "192.168.1.101", "192.168.1.102"]}'$ oc patch hostsubnet node1 --type=merge -p \ '{"egressIPs": ["192.168.1.100", "192.168.1.101", "192.168.1.102"]}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 直前の例では、
project1のすべての egress トラフィックは、指定された egress IP をホストするノードにルーティングされてから、その IP アドレスに (NAT を使用して) 接続されます。
9.3. 外部 IP アドレスへのアクセスを制御するための egress ファイアウォールの設定 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、OpenShift Container Platform クラスター外に出るプロジェクトのプロジェクについて、egress トラフィックを制限する egress ファイアウォールを作成できます。
9.3.1. egress ファイアウォールのプロジェクトでの機能 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、 egress ファイアウォール を使用して、一部またはすべての Pod がクラスター内からアクセスできる外部ホストを制限できます。egress ファイアウォールポリシーは以下のシナリオをサポートします。
- Pod の接続を内部ホストに制限し、パブリックインターネットへの接続を開始できないようにする。
- Pod の接続をパブリックインターネットに制限し、OpenShift Container Platform クラスター外にある内部ホストへの接続を開始できないようにする。
- Pod は OpenShift Container Platform クラスター外の指定された内部サブネットまたはホストにアクセスできません。
- Pod は特定の外部ホストにのみ接続することができます。
egress ファイアウォールポリシーは、EgressNetworkPolicy カスタムリソース (CR) オブジェクトを作成し、IP アドレス範囲を CIDR 形式で指定するか、または DNS 名を指定して設定します。たとえば、指定された IP 範囲へのあるプロジェクトへのアクセスを許可する一方で、別のプロジェクトへの同じアクセスを拒否することができます。または、アプリケーション開発者の (Python) pip mirror からの更新を制限したり、更新を承認されたソースからの更新のみに強制的に制限したりすることができます。
egress ファイアウォールポリシーを設定するには、ネットワークポリシーまたはマルチテナントモードのいずれかを使用するように OpenShift SDN を設定する必要があります。
ネットワークポリシーモードを使用している場合、egress ポリシーは namespace ごとに 1 つのポリシーとのみ互換性を持ち、グローバルプロジェクトなどのネットワークを共有するプロジェクトでは機能しません。
egress ファイアウォールルールは、ルーターを通過するトラフィックには適用されません。ルート CR オブジェクトを作成するパーミッションを持つユーザーは、禁止されている宛先を参照するルートを作成することにより、egress ネットワークポリシールールをバイパスできます。
9.3.1.1. egress ファイアウォールの制限 リンクのコピーリンクがクリップボードにコピーされました!
egress ファイアウォールには以下の制限があります。
- いずれのプロジェクトも複数の EgressNetworkPolicy オブジェクトを持つことができません。
- 最大 50 のルールを持つ最大 1 EgressNetworkPolicy オブジェクトはプロジェクトごとに定義できます。
-
defaultプロジェクトは egress ネットワークポリシーを使用できません。 マルチテナントモードで OpenShift SDN デフォルト Container Network Interface (CNI) ネットワークプロバイダーを使用する場合、以下の制限が適用されます。
-
グローバルプロジェクトは egress ファイアウォールを使用できません。
oc adm pod-network make-projects-globalコマンドを使用して、プロジェクトをグローバルにすることができます。 -
oc adm pod-network join-projectsコマンドを使用してマージされるプロジェクトでは、結合されたプロジェクトのいずれでも egress ファイアウォールを使用することはできません。
-
グローバルプロジェクトは egress ファイアウォールを使用できません。
上記の制限のいずれかに違反すると、プロジェクトの egress ネットワークポリシーに障害が発生し、すべての外部ネットワークトラフィックがドロップされる可能性があります。
9.3.1.2. egress ネットワークポリシールールのマッチング順序 リンクのコピーリンクがクリップボードにコピーされました!
egress ネットワークポリシールールは、最初から最後へと定義された順序で評価されます。Pod からの egress 接続に一致する最初のルールが適用されます。この接続では、後続のルールは無視されます。
9.3.1.3. DNS (Domain Name Server) 解決の仕組み リンクのコピーリンクがクリップボードにコピーされました!
egress ファイアウォールポリシールールのいずれかで DNS 名を使用する場合、ドメイン名の適切な解決には、以下の制限が適用されます。
- ドメイン名の更新は、ローカルの非権威サーバーのドメインの TTL (time to live) 値に基づいてポーリングされます。
- Pod は、必要に応じて同じローカルネームサーバーからドメインを解決する必要があります。そうしない場合、egress ファイアウォールコントローラーと Pod によって認識されるドメインの IP アドレスが異なる可能性があります。ホスト名の IP アドレスが異なる場合、egress ファイアウォールは一貫して実行されないことがあります。
- egress ファイアウォールコントローラーおよび Pod は同じローカルネームサーバーを非同期にポーリングするため、Pod は egress コントローラーが実行する前に更新された IP アドレスを取得する可能性があります。これにより、競合状態が生じます。この現時点の制限により、EgressNetworkPolicy オブジェクトのドメイン名の使用は、IP アドレスの変更が頻繁に生じないドメインの場合にのみ推奨されます。
egress ファイアウォールは、DNS 解決用に Pod が置かれるノードの外部インターフェイスに Pod が常にアクセスできるようにします。
ドメイン名を egress ファイアウォールで使用し、DNS 解決がローカルノード上の DNS サーバーによって処理されない場合は、Pod でドメイン名を使用している場合には DNS サーバーの IP アドレスへのアクセスを許可する egress ファイアウォールを追加する必要があります。
9.3.2. EgressNetworkPolicy カスタムリソース (CR) オブジェクト リンクのコピーリンクがクリップボードにコピーされました!
以下の YAML は EgressNetworkPolicy CR オブジェクトについて説明しています。
9.3.2.1. EgressNetworkPolicy ルール リンクのコピーリンクがクリップボードにコピーされました!
以下の YAML は egress ファイアウォールルールオブジェクトについて説明しています。egress キーは、単一または複数のオブジェクトの配列を予想します。
egress:
- type: <type>
to:
cidrSelector: <cidr>
dnsName: <dns-name>
egress:
- type: <type>
to:
cidrSelector: <cidr>
dnsName: <dns-name>
9.3.2.2. EgressNetworkPolicy CR オブジェクトの例 リンクのコピーリンクがクリップボードにコピーされました!
以下の例では、複数の egress ファイアウォールポリシールールを定義します。
9.3.3. egress ファイアウォールポリシーオブジェクトの作成 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、プロジェクトの egress ファイアウォールポリシーオブジェクトを作成できます。
プロジェクトに EgressNetworkPolicy オブジェクトがすでに定義されている場合、既存のポリシーを編集して egress ファイアウォールルールを変更する必要があります。
前提条件
- OpenShift SDN デフォルト Container Network Interface (CNI) ネットワークプロバイダープラグインを使用するクラスター。
-
OpenShift CLI (
oc) をインストールしている。 - クラスター管理者としてクラスターにログインする必要があります。
手順
ポリシールールを作成します。
-
<policy-name>.yamlファイルを作成します。 この場合、<policy-name>は egress ポリシールールを記述します。 - 作成したファイルで、egress ポリシーオブジェクトを定義します。
-
以下のコマンドを入力してポリシーオブジェクトを作成します。
oc create -f <policy-name>.yaml -n <project>
$ oc create -f <policy-name>.yaml -n <project>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下の例では、新規の EgressNetworkPolicy オブジェクトが
project1という名前のプロジェクトに作成されます。oc create -f default-rules.yaml -n project1
$ oc create -f default-rules.yaml -n project1Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
egressnetworkpolicy.network.openshift.io/default-rules created
egressnetworkpolicy.network.openshift.io/default-rules createdCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
オプション: 後に変更できるように
<policy-name>.yamlを保存します。
9.4. プロジェクトの egress ファイアウォールの編集 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、既存の egress ファイアウォールのネットワークトラフィックルールを変更できます。
9.4.1. EgressNetworkPolicy オブジェクトの編集 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、プロジェクトの egress ファイアウォールを更新できます。
前提条件
- OpenShiftSDN ネットワークプラグインを使用するクラスター。
-
OpenShift CLI (
oc) のインストール。 - クラスター管理者としてクラスターにログインする必要があります。
手順
プロジェクトの既存の egress ネットワークポリシーオブジェクトを編集するには、以下の手順を実行します。
プロジェクトの EgressNetworkPolicy オブジェクトの名前を検索します。
<project>をプロジェクトの名前に置き換えます。oc get -n <project> egressnetworkpolicy
$ oc get -n <project> egressnetworkpolicyCopy to Clipboard Copied! Toggle word wrap Toggle overflow オプション: egress ネットワークファイアウォールの作成時に EgressNetworkPolicy オブジェクトのコピーを保存しなかった場合には、以下のコマンドを入力してコピーを作成します。
oc get -n <project> \ egressnetworkpolicy <name> \ -o yaml > <filename>.yaml
$ oc get -n <project> \1 egressnetworkpolicy <name> \2 -o yaml > <filename>.yaml3 Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを入力し、EgressNetworkPolicy オブジェクトを置き換えます。
<filename>を、更新された EgressNetworkPolicy オブジェクトを含むファイルの名前に置き換えます。oc replace -f <filename>.yaml
$ oc replace -f <filename>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
9.4.2. EgressNetworkPolicy カスタムリソース (CR) オブジェクト リンクのコピーリンクがクリップボードにコピーされました!
以下の YAML は EgressNetworkPolicy CR オブジェクトについて説明しています。
9.4.2.1. EgressNetworkPolicy ルール リンクのコピーリンクがクリップボードにコピーされました!
以下の YAML は egress ファイアウォールルールオブジェクトについて説明しています。egress キーは、単一または複数のオブジェクトの配列を予想します。
egress:
- type: <type>
to:
cidrSelector: <cidr>
dnsName: <dns-name>
egress:
- type: <type>
to:
cidrSelector: <cidr>
dnsName: <dns-name>
9.4.2.2. EgressNetworkPolicy CR オブジェクトの例 リンクのコピーリンクがクリップボードにコピーされました!
以下の例では、複数の egress ファイアウォールポリシールールを定義します。
9.5. プロジェクトからの egress ファイアウォールの削除 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、プロジェクトから egress ファイアウォールを削除して、OpenShift Container Platform クラスター外に出るプロジェクトからネットワークトラフィックについてのすべての制限を削除できます。
9.5.1. EgressNetworkPolicy オブジェクトの削除 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、プロジェクトから Egress ファイアウォールを削除できます。
前提条件
- OpenShiftSDN ネットワークプラグインを使用するクラスター。
-
OpenShift CLI (
oc) のインストール。 - クラスター管理者としてクラスターにログインする必要があります。
手順
プロジェクトの egress ネットワークポリシーオブジェクトを削除するには、以下の手順を実行します。
プロジェクトの EgressNetworkPolicy オブジェクトの名前を検索します。
<project>をプロジェクトの名前に置き換えます。oc get -n <project> egressnetworkpolicy
$ oc get -n <project> egressnetworkpolicyCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを入力し、EgressNetworkPolicy オブジェクトを削除します。
<project>をプロジェクトの名前に、<name>をオブジェクトの名前に置き換えます。oc delete -n <project> egressnetworkpolicy <name>
$ oc delete -n <project> egressnetworkpolicy <name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
9.6. egress ルーター Pod の使用についての考慮事項 リンクのコピーリンクがクリップボードにコピーされました!
9.6.1. Egress ルーター Pod について リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform egress ルーター Pod は、他の用途で使用されていないプライベートソース IP アドレスを使用して、指定されたリモートサーバーにトラフィックをリダイレクトします。これにより、特定の IP アドレスからのアクセスのみを許可するように設定されたサーバーにネットワークトラフィックを送信できます。
egress ルーター Pod はすべての発信接続のために使用されることが意図されていません。多数の egress ルーター Pod を作成することで、ネットワークハードウェアの制限を引き上げられる可能性があります。たとえば、すべてのプロジェクトまたはアプリケーションに egress ルーター Pod を作成すると、ソフトウェアの MAC アドレスのフィルターに戻る前にネットワークインターフェイスが処理できるローカル MAC アドレス数の上限を超えてしまう可能性があります。
egress ルーターイメージには Amazon AWS, Azure Cloud またはレイヤー 2 操作をサポートしないその他のクラウドプラットフォームとの互換性がありません。 それらに macvlan トラフィックとの互換性がないためです。
9.6.1.1. Egress ルーターモード リンクのコピーリンクがクリップボードにコピーされました!
リダイレクトモードでは、egress ルーター Pod は、トラフィックを独自の IP アドレスから 1 つ以上の宛先 IP アドレスにリダイレクトするために iptables ルールをセットアップします。予約されたソース IP アドレスを使用する必要のあるクライアント Pod は、宛先 IP に直接接続するのでなく、egress ルーターに接続するように変更される必要があります。
HTTP プロキシーモードでは、egress ルーター Pod はポート 8080 で HTTP プロキシーとして実行されます。このモードは、HTTP または HTTPS ベースのサービスと通信するクライアントの場合にのみ機能しますが、通常それらを機能させるのにクライアント Pod への多くの変更は不要です。環境変数を設定することで、数多くのプログラムは HTTP プロキシーを使用するように指示されます。
DNS プロキシーモードでは、egress ルーター Pod は、トラフィックを独自の IP アドレスから 1 つ以上の宛先 IP アドレスに送信する TCP ベースのサービスの DNS プロキシーとして実行されます。予約されたソース IP アドレスを使用するには、クライアント Pod は、宛先 IP アドレスに直接接続するのでなく、egress ルーター Pod に接続するように変更される必要があります。この修正により、外部の宛先でトラフィックが既知のソースから送信されているかのように処理されます。
リダイレクトモードは、HTTP および HTTPS 以外のすべてのサービスで機能します。HTTP および HTTPS サービスの場合は、HTTP プロキシーモードを使用します。IP アドレスまたはドメイン名を持つ TCP ベースのサービスの場合は、DNS プロキシーモードを使用します。
9.6.1.2. egress ルーター Pod の実装 リンクのコピーリンクがクリップボードにコピーされました!
egress ルーター Pod の設定は、初期化コンテナーで実行されます。このコンテナーは特権付きコンテキストで実行され、macvlan インターフェイスを設定して iptables ルールを設定できます。初期化コンテナーが iptables ルールの設定を終了すると、終了します。次に、egress ルーター Pod はコンテナーを実行して egress ルーターのトラフィックを処理します。使用されるイメージは、egress ルーターモードによって異なります。
環境変数は、egress-router イメージが使用するアドレスを判別します。イメージは macvlan インターフェイスを、 EGRESS_SOURCE をその IP アドレスとして使用し、EGRESS_GATEWAY をゲートウェイの IP アドレスとして使用するように設定します。
ネットワークアドレス変換 (NAT) ルールは、TCP ポートまたは UDP ポート上の Pod のクラスター IP アドレスへの接続が EGRESS_DESTINATION 変数で指定される IP アドレスの同じポートにリダイレクトされるように設定されます。
クラスター内の一部のノードのみが指定されたソース IP アドレスを要求でき、指定されたゲートウェイを使用できる場合、受け入れ可能なノードを示す nodeName または nodeSelector を指定することができます。
9.6.1.3. デプロイメントに関する考慮事項 リンクのコピーリンクがクリップボードにコピーされました!
egress ルーター Pod は追加の IP アドレスおよび MAC アドレスをノードのプライマリーネットワークインターフェイスに追加します。その結果、ハイパーバイザーまたはクラウドプロバイダーを、追加のアドレスを許可するように設定する必要がある場合があります。
- {rh-openstack-first}
OpenShift Container Platform を {rh-openstack} でデプロイしている場合、OpenStack 環境で IP および MAC アドレスのホワイトリストを作成する必要があります。 これを行わないと、通信は失敗します。
openstack port set --allowed-address \ ip_address=<ip_address>,mac_address=<mac_address> <neutron_port_uuid>
$ openstack port set --allowed-address \ ip_address=<ip_address>,mac_address=<mac_address> <neutron_port_uuid>Copy to Clipboard Copied! Toggle word wrap Toggle overflow - {rh-virtualization-first}
- {rh-virtualization} を使用している場合は、仮想インターフェイスカード (vNIC) に No Network Filter を選択する必要があります。
- VMware vSphere
- VMware vSphere を使用している場合は、vSphere 標準スイッチのセキュリティー保護についての VMWare ドキュメント を参照してください。vSphere Web クライアントからホストの仮想スイッチを選択して、VMWare vSphere デフォルト設定を表示し、変更します。
とくに、以下が有効にされていることを確認します。
9.6.1.4. フェイルオーバー設定 リンクのコピーリンクがクリップボードにコピーされました!
ダウンタイムを回避するには、以下の例のように Deployment リソースで egress ルーター Pod をデプロイできます。サンプルのデプロイメント用に新規 Service オブジェクトを作成するには、oc expose deployment/egress-demo-controller コマンドを使用します。
9.6.2. 関連情報 リンクのコピーリンクがクリップボードにコピーされました!
9.7. リダイレクトモードでの egress ルーター Pod のデプロイ リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、トラフィックを指定された宛先 IP アドレスにリダイレクトするように設定された egress ルーター Pod をデプロイできます。
9.7.1. リダイレクトモードの egress ルーター Pod 仕様 リンクのコピーリンクがクリップボードにコピーされました!
Pod オブジェクトで egress ルーター Pod の設定を定義します。以下の YAML は、リダイレクトモードでの egress ルーター Pod の設定のフィールドについて説明しています。
- 1
egress-routerコンテナーを起動する前に、プライマリーネットワークインターフェイスで macvlan ネットワークインターフェイスを作成し、そのインターフェイスを Pod ネットワーク namespace に移動します。引用符を"true"値の周囲に含める必要があります。プライマリーネットワークインターフェイス以外のネットワークインターフェイスで macvlan インターフェイスを作成するには、アノテーションの値を該当インターフェイスの名前に設定します。たとえば、eth1を使用します。- 2
- ノードが置かれている物理ネットワークの IP アドレスは egress ルーター Pod で使用するために予約されます。オプション: サブネットの長さ
/24接尾辞を組み込み、ローカルサブネットへの適切なルートがセットアップされるようにできます。サブネットの長さを指定しない場合、egress ルーターはEGRESS_GATEWAY変数で指定されたホストにのみアクセスでき、サブネットの他のホストにはアクセスできません。 - 3
- ノードで使用されるデフォルトゲートウェイと同じ値です。
- 4
- トラフィックの送信先となる外部サーバー。この例では、Pod の接続は
203.0.113.25にリダイレクトされます。 ソース IP アドレスは192.168.12.99です。
egress ルーター Pod 仕様の例
9.7.2. egress 宛先設定形式 リンクのコピーリンクがクリップボードにコピーされました!
egress ルーター Pod がリダイレクトモードでデプロイされる場合、以下のいずれかの形式を使用してリダイレクトルールを指定できます。
-
<port> <protocol> <ip_address>: 指定される<port>への着信接続が指定される<ip_address>の同じポートにリダイレクトされます。<protocol>はtcpまたはudpのいずれかになります。 -
<port> <protocol> <ip_address> <remote_port>: 接続が<ip_address>の別の<remote_port>にリダイレクトされるのを除き、上記と同じになります。 -
<ip_address>: 最後の行が単一 IP アドレスである場合、それ以外のポートの接続はその IP アドレスの対応するポートにリダイレクトされます。フォールバック IP アドレスがない場合、他のポートでの接続は拒否されます。
以下の例では、複数のルールが定義されます。
-
最初の行はローカルポート
80から203.0.113.25のポート80にトラフィックをリダイレクトします。 -
2 番目と 3 番目の行では、ローカルポート
8080および8443を、203.0.113.26のリモートポート80および443にリダイレクトします。 - 最後の行は、先のルールで指定されていないポートのトラフィックに一致します。
設定例
80 tcp 203.0.113.25 8080 tcp 203.0.113.26 80 8443 tcp 203.0.113.26 443 203.0.113.27
80 tcp 203.0.113.25
8080 tcp 203.0.113.26 80
8443 tcp 203.0.113.26 443
203.0.113.27
9.7.3. リダイレクトモードでの egress ルーター Pod のデプロイ リンクのコピーリンクがクリップボードにコピーされました!
リダイレクトモードでは、egress ルーター Pod は、トラフィックを独自の IP アドレスから 1 つ以上の宛先 IP アドレスにリダイレクトするために iptables ルールをセットアップします。予約されたソース IP アドレスを使用する必要のあるクライアント Pod は、宛先 IP に直接接続するのでなく、egress ルーターに接続するように変更される必要があります。
前提条件
-
OpenShift CLI (
oc) をインストールしている。 -
cluster-admin権限を持つユーザーとしてログインしている。
手順
- egress ルーター Pod の作成
他の Pod が egress ルーター Pod の IP アドレスを見つられるようにするには、以下の例のように、egress ルーター Pod を参照するサービスを作成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Pod がこのサービスに接続できるようになります。これらの接続は、予約された egress IP アドレスを使用して外部サーバーの対応するポートにリダイレクトされます。
9.7.4. 関連情報 リンクのコピーリンクがクリップボードにコピーされました!
9.8. HTTP プロキシーモードでの egress ルーター Pod のデプロイ リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、トラフィックを指定された HTTP および HTTPS ベースのサービスにプロキシーするように設定された egress ルーター Pod をデプロイできます。
9.8.1. HTTP モードの egress ルーター Pod 仕様 リンクのコピーリンクがクリップボードにコピーされました!
Pod オブジェクトで egress ルーター Pod の設定を定義します。以下の YAML は、HTTP モードでの egress ルーター Pod の設定のフィールドについて説明しています。
- 1
egress-routerコンテナーを起動する前に、プライマリーネットワークインターフェイスで macvlan ネットワークインターフェイスを作成し、そのインターフェイスを Pod ネットワーク namespace に移動します。引用符を"true"値の周囲に含める必要があります。プライマリーネットワークインターフェイス以外のネットワークインターフェイスで macvlan インターフェイスを作成するには、アノテーションの値を該当インターフェイスの名前に設定します。たとえば、eth1を使用します。- 2
- ノードが置かれている物理ネットワークの IP アドレスは egress ルーター Pod で使用するために予約されます。オプション: サブネットの長さ
/24接尾辞を組み込み、ローカルサブネットへの適切なルートがセットアップされるようにできます。サブネットの長さを指定しない場合、egress ルーターはEGRESS_GATEWAY変数で指定されたホストにのみアクセスでき、サブネットの他のホストにはアクセスできません。 - 3
- ノードで使用されるデフォルトゲートウェイと同じ値です。
- 4
- プロキシーの設定方法を指定する文字列または YAML の複数行文字列です。これは、init コンテナーの他の環境変数ではなく、HTTP プロキシーコンテナーの環境変数として指定されることに注意してください。
9.8.2. egress 宛先設定形式 リンクのコピーリンクがクリップボードにコピーされました!
egress ルーター Pod が HTTP プロキシーモードでデプロイされる場合、以下の形式のいずれかを使用してリダイレクトルールを指定できます。これはすべてのリモート宛先への接続を許可することを意味します。 設定の各行には、許可または拒否する接続の 1 つのグループを指定します。
-
IP アドレス (例:
192.168.1.1) は該当する IP アドレスへの接続を許可します。 -
CIDR 範囲 (例:
192.168.1.0/24) は CIDR 範囲への接続を許可します。 -
ホスト名 (例:
www.example.com) は該当ホストへのプロキシーを許可します。 -
*.が前に付けられているドメイン名 (例:*.example.com) は該当ドメインおよびそのサブドメインのすべてへのプロキシーを許可します。 -
先の一致 (match) 式のいずれかの後に来る
!は接続を拒否します。 -
最後の行が
*の場合、明示的に拒否されていないすべてのものが許可されます。それ以外の場合、許可されないすべてのものが拒否されます。
* を使用してすべてのリモート宛先への接続を許可することもできます。
設定例
!*.example.com !192.168.1.0/24 192.168.2.1 *
!*.example.com
!192.168.1.0/24
192.168.2.1
*
9.8.3. HTTP プロキシーモードでの egress ルーター Pod のデプロイ リンクのコピーリンクがクリップボードにコピーされました!
HTTP プロキシーモードでは、egress ルーター Pod はポート 8080 で HTTP プロキシーとして実行されます。このモードは、HTTP または HTTPS ベースのサービスと通信するクライアントの場合にのみ機能しますが、通常それらを機能させるのにクライアント Pod への多くの変更は不要です。環境変数を設定することで、数多くのプログラムは HTTP プロキシーを使用するように指示されます。
前提条件
-
OpenShift CLI (
oc) をインストールしている。 -
cluster-admin権限を持つユーザーとしてログインしている。
手順
- egress ルーター Pod の作成
他の Pod が egress ルーター Pod の IP アドレスを見つられるようにするには、以下の例のように、egress ルーター Pod を参照するサービスを作成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
httpポートが常に8080に設定されていることを確認します。
http_proxyまたはhttps_proxy変数を設定して、クライアント Pod (egress プロキシー Pod ではない) を HTTP プロキシーを使用するように設定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 先の手順で作成したサービス。
注記すべてのセットアップに
http_proxyおよびhttps_proxy環境変数が必要になる訳ではありません。上記を実行しても作業用セットアップが作成されない場合は、Pod で実行しているツールまたはソフトウェアについてのドキュメントを参照してください。
9.8.4. 関連情報 リンクのコピーリンクがクリップボードにコピーされました!
9.9. DNS プロキシーモードでの egress ルーター Pod のデプロイ リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、トラフィックを指定された DNS 名および IP アドレスにプロキシーするように設定された egress ルーター Pod をデプロイできます。
9.9.1. DNS モードの egress ルーター Pod 仕様 リンクのコピーリンクがクリップボードにコピーされました!
Pod オブジェクトで egress ルーター Pod の設定を定義します。以下の YAML は、DNS モードでの egress ルーター Pod の設定のフィールドについて説明しています。
- 1
egress-routerコンテナーを起動する前に、プライマリーネットワークインターフェイスで macvlan ネットワークインターフェイスを作成し、そのインターフェイスを Pod ネットワーク namespace に移動します。引用符を"true"値の周囲に含める必要があります。プライマリーネットワークインターフェイス以外のネットワークインターフェイスで macvlan インターフェイスを作成するには、アノテーションの値を該当インターフェイスの名前に設定します。たとえば、eth1を使用します。- 2
- ノードが置かれている物理ネットワークの IP アドレスは egress ルーター Pod で使用するために予約されます。オプション: サブネットの長さ
/24接尾辞を組み込み、ローカルサブネットへの適切なルートがセットアップされるようにできます。サブネットの長さを指定しない場合、egress ルーターはEGRESS_GATEWAY変数で指定されたホストにのみアクセスでき、サブネットの他のホストにはアクセスできません。 - 3
- ノードで使用されるデフォルトゲートウェイと同じ値です。
- 4
- 1 つ以上のプロキシー宛先の一覧を指定します。
- 5
- オプション: DNS プロキシーログ出力を
stdoutに出力するために指定します。
9.9.2. egress 宛先設定形式 リンクのコピーリンクがクリップボードにコピーされました!
ルーターが DNS プロキシーモードでデプロイされる場合、ポートおよび宛先マッピングの一覧を指定します。宛先には、IP アドレスまたは DNS 名のいずれかを使用できます。
egress ルーター Pod は、ポートおよび宛先マッピングを指定するために以下の形式をサポートします。
- ポートおよびリモートアドレス
-
送信元ポートおよび宛先ホストは、2 つのフィールド形式 (
<port> <remote_address>) を使用して指定できます。
ホストには、IP アドレスまたは DNS 名を指定できます。DNS 名を指定すると、DNS 解決が起動時に行われます。特定のホストについては、プロキシーは、宛先ホスト IP アドレスへの接続時に、宛先ホストの指定された送信元ポートに接続されます。
ポートとリモートアドレスペアの例
80 172.16.12.11 100 example.com
80 172.16.12.11
100 example.com
- ポート、リモートアドレス、およびリモートポート
-
送信元ポート、宛先ホスト、および宛先ポートは、
<port> <remote_address> <remote_port>の 3 つのフィールドからなる形式を使用して指定できます。
3 つのフィールド形式は、2 つのフィールドバージョンと同じように動作しますが、宛先ポートが送信元ポートとは異なる場合があります。
ポート、リモートアドレス、およびリモートポートの例
8080 192.168.60.252 80 8443 web.example.com 443
8080 192.168.60.252 80
8443 web.example.com 443
9.9.3. DNS プロキシーモードでの egress ルーター Pod のデプロイ リンクのコピーリンクがクリップボードにコピーされました!
DNS プロキシーモードでは、egress ルーター Pod は、トラフィックを独自の IP アドレスから 1 つ以上の宛先 IP アドレスに送信する TCP ベースのサービスの DNS プロキシーとして機能します。
前提条件
-
OpenShift CLI (
oc) をインストールしている。 -
cluster-admin権限を持つユーザーとしてログインしている。
手順
- egress ルーター Pod の作成
egress ルーター Pod のサービスを作成します。
以下の YAML 定義が含まれる
egress-router-service.yamlという名前のファイルを作成します。spec.portsを、EGRESS_DNS_PROXY_DESTINATION環境変数に先に定義したポートの一覧に設定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下に例を示します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow サービスを作成するには、以下のコマンドを入力します。
oc create -f egress-router-service.yaml
$ oc create -f egress-router-service.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow Pod がこのサービスに接続できるようになります。これらの接続は、予約された egress IP アドレスを使用して外部サーバーの対応するポートにプロキシー送信されます。
9.9.4. 関連情報 リンクのコピーリンクがクリップボードにコピーされました!
9.10. 設定マップからの egress ルーター Pod 宛先一覧の設定 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、egress ルーター Pod の宛先マッピングを指定する ConfigMap オブジェクトを定義できます。設定の特定の形式は、egress ルーター Pod のタイプによって異なります。形式についての詳細は、特定の egress ルーター Pod のドキュメントを参照してください。
9.10.1. 設定マップを使用した egress ルーター宛先マッピングの設定 リンクのコピーリンクがクリップボードにコピーされました!
宛先マッピングのセットのサイズが大きいか、またはこれが頻繁に変更される場合、設定マップを使用して一覧を外部で維持できます。この方法の利点は、設定マップを編集するパーミッションを cluster-admin 権限を持たないユーザーに委任できることです。egress ルーター Pod には特権付きコンテナーを必要とするため、cluster-admin 権限を持たないユーザーは Pod 定義を直接編集することはできません。
egress ルーター Pod は、設定マップが変更されても自動的に更新されません。更新を取得するには、egress ルーター Pod を再起動する必要があります。
前提条件
-
OpenShift CLI (
oc) をインストールしている。 -
cluster-admin権限を持つユーザーとしてログインしている。
手順
以下の例のように、egress ルーター Pod のマッピングデータが含まれるファイルを作成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 空の行とコメントをこのファイルに追加できます。
このファイルから
ConfigMapオブジェクトを作成します。oc delete configmap egress-routes --ignore-not-found
$ oc delete configmap egress-routes --ignore-not-foundCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc create configmap egress-routes \ --from-file=destination=my-egress-destination.txt
$ oc create configmap egress-routes \ --from-file=destination=my-egress-destination.txtCopy to Clipboard Copied! Toggle word wrap Toggle overflow 直前のコマンドで、
egress-routes値は、作成するConfigMapオブジェクトの名前で、my-egress-destination.txtはデータの読み取り元のファイルの名前です。egress ルーター Pod 定義を作成し、environment スタンザの
EGRESS_DESTINATIONフィールドにconfigMapKeyRefスタンザを指定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
9.10.2. 関連情報 リンクのコピーリンクがクリップボードにコピーされました!
9.11. プロジェクトのマルチキャストの有効化 リンクのコピーリンクがクリップボードにコピーされました!
9.11.1. マルチキャストについて リンクのコピーリンクがクリップボードにコピーされました!
IP マルチキャストを使用すると、データが多数の IP アドレスに同時に配信されます。
現時点で、マルチキャストは低帯域幅の調整またはサービスの検出での使用に最も適しており、高帯域幅のソリューションとしては適していません。
OpenShift Container Platform の Pod 間のマルチキャストトラフィックはデフォルトで無効にされます。OpenShift SDN デフォルト Container Network Interface (CNI) ネットワークプロバイダーを使用している場合、プロジェクトごとにマルチキャストを有効にできます。
networkpolicy 分離モードで OpenShift SDN ネットワークプラグインを使用する場合は、以下を行います。
-
Pod によって送信されるマルチキャストパケットは、
NetworkPolicyオブジェクトに関係なく、プロジェクトの他のすべての Pod に送信されます。Pod はユニキャストで通信できない場合でもマルチキャストで通信できます。 -
1 つのプロジェクトの Pod によって送信されるマルチキャストパケットは、
NetworkPolicyオブジェクトがプロジェクト間の通信を許可する場合であっても、それ以外のプロジェクトの Pod に送信されることはありません。
multinenant 分離モードで OpenShift SDN ネットワークプラグインを使用する場合は、以下を行います。
- Pod で送信されるマルチキャストパケットはプロジェクトにあるその他の全 Pod に送信されます。
- あるプロジェクトの Pod によって送信されるマルチキャストパケットは、各プロジェクトが結合し、マルチキャストが結合した各プロジェクトで有効にされている場合にのみ、他のプロジェクトの Pod に送信されます。
9.11.2. Pod 間のマルチキャストの有効化 リンクのコピーリンクがクリップボードにコピーされました!
プロジェクトの Pod でマルチキャストを有効にすることができます。
前提条件
-
OpenShift CLI (
oc) をインストールしている。 -
cluster-adminロールを持つユーザーとしてクラスターにログインする必要があります。
手順
以下のコマンドを実行し、プロジェクトのマルチキャストを有効にします。
<namespace>を、マルチキャストを有効にする必要のある namespace に置き換えます。oc annotate netnamespace <namespace> \ netnamespace.network.openshift.io/multicast-enabled=true$ oc annotate netnamespace <namespace> \ netnamespace.network.openshift.io/multicast-enabled=trueCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証手順
マルチキャストがプロジェクトについて有効にされていることを確認するには、以下の手順を実行します。
現在のプロジェクトを、マルチキャストを有効にしたプロジェクトに切り替えます。
<project>をプロジェクト名に置き換えます。oc project <project>
$ oc project <project>Copy to Clipboard Copied! Toggle word wrap Toggle overflow マルチキャストレシーバーとして機能する Pod を作成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow マルチキャストセンダーとして機能する Pod を作成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow マルチキャストリスナーを起動します。
Pod の IP アドレスを取得します。
POD_IP=$(oc get pods mlistener -o jsonpath='{.status.podIP}')$ POD_IP=$(oc get pods mlistener -o jsonpath='{.status.podIP}')Copy to Clipboard Copied! Toggle word wrap Toggle overflow マルチキャストリスナーを起動するには、新しいターミナルウィンドウまたはタブで以下のコマンドを入力します。
oc exec mlistener -i -t -- \ socat UDP4-RECVFROM:30102,ip-add-membership=224.1.0.1:$POD_IP,fork EXEC:hostname$ oc exec mlistener -i -t -- \ socat UDP4-RECVFROM:30102,ip-add-membership=224.1.0.1:$POD_IP,fork EXEC:hostnameCopy to Clipboard Copied! Toggle word wrap Toggle overflow
マルチキャストトランスミッターを開始します。
Pod ネットワーク IP アドレス範囲を取得します。
CIDR=$(oc get Network.config.openshift.io cluster \ -o jsonpath='{.status.clusterNetwork[0].cidr}')$ CIDR=$(oc get Network.config.openshift.io cluster \ -o jsonpath='{.status.clusterNetwork[0].cidr}')Copy to Clipboard Copied! Toggle word wrap Toggle overflow マルチキャストメッセージを送信するには、以下のコマンドを入力します。
oc exec msender -i -t -- \ /bin/bash -c "echo | socat STDIO UDP4-DATAGRAM:224.1.0.1:30102,range=$CIDR,ip-multicast-ttl=64"$ oc exec msender -i -t -- \ /bin/bash -c "echo | socat STDIO UDP4-DATAGRAM:224.1.0.1:30102,range=$CIDR,ip-multicast-ttl=64"Copy to Clipboard Copied! Toggle word wrap Toggle overflow マルチキャストが機能している場合、直前のコマンドは以下の出力を返します。
mlistener
mlistenerCopy to Clipboard Copied! Toggle word wrap Toggle overflow
9.12. プロジェクトのマルチキャストの無効化 リンクのコピーリンクがクリップボードにコピーされました!
9.12.1. Pod 間のマルチキャストの無効化 リンクのコピーリンクがクリップボードにコピーされました!
プロジェクトの Pod でマルチキャストを無効にすることができます。
前提条件
-
OpenShift CLI (
oc) をインストールしている。 -
cluster-adminロールを持つユーザーとしてクラスターにログインする必要があります。
手順
以下のコマンドを実行して、マルチキャストを無効にします。
oc annotate netnamespace <namespace> \ netnamespace.network.openshift.io/multicast-enabled-$ oc annotate netnamespace <namespace> \1 netnamespace.network.openshift.io/multicast-enabled-Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- マルチキャストを無効にする必要のあるプロジェクトの
namespace。
9.13. OpenShift SDN を使用したネットワーク分離の設定 リンクのコピーリンクがクリップボードにコピーされました!
クラスターが OpenShift SDN CNI プラグインのマルチテナント分離モードを使用するように設定されている場合、各プロジェクトはデフォルトで分離されます。ネットワークトラフィックは、マルチテナント分離モードでは、異なるプロジェクトの Pod およびサービス間で許可されません。
プロジェクトのマルチテナント分離の動作を 2 つの方法で変更することができます。
- 1 つ以上のプロジェクトを結合し、複数の異なるプロジェクトの Pod とサービス間のネットワークトラフィックを可能にします。
- プロジェクトのネットワーク分離を無効にできます。これはグローバルにアクセスできるようになり、他のすべてのプロジェクトの Pod およびサービスからのネットワークトラフィックを受け入れます。グローバルにアクセス可能なプロジェクトは、他のすべてのプロジェクトの Pod およびサービスにアクセスできます。
9.13.1. 前提条件 リンクのコピーリンクがクリップボードにコピーされました!
- クラスターは、マルチテナント分離ノードで OpenShift SDN Container Network Interface (CNI) プラグインを使用するように設定されている必要があります。
9.13.2. プロジェクトの結合 リンクのコピーリンクがクリップボードにコピーされました!
2 つ以上のプロジェクトを結合し、複数の異なるプロジェクトの Pod とサービス間のネットワークトラフィックを可能にします。
前提条件
-
OpenShift CLI (
oc) をインストールしている。 -
cluster-adminロールを持つユーザーとしてクラスターにログインする必要があります。
手順
以下のコマンドを使用して、プロジェクトを既存のプロジェクトネットワークに参加させます。
oc adm pod-network join-projects --to=<project1> <project2> <project3>
$ oc adm pod-network join-projects --to=<project1> <project2> <project3>Copy to Clipboard Copied! Toggle word wrap Toggle overflow または、特定のプロジェクト名を指定する代わりに
--selector=<project_selector>オプションを使用し、関連付けられたラベルに基づいてプロジェクトを指定できます。オプション: 以下のコマンドを実行し、結合した Pod ネットワークを表示します。
oc get netnamespaces
$ oc get netnamespacesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 同じ Pod ネットワークのプロジェクトには、NETID 列に同じネットワーク ID があります。
9.13.3. プロジェクトの分離 リンクのコピーリンクがクリップボードにコピーされました!
他のプロジェクトの Pod およびサービスがその Pod およびサービスにアクセスできないようにするためにプロジェクトを分離することができます。
前提条件
-
OpenShift CLI (
oc) をインストールしている。 -
cluster-adminロールを持つユーザーとしてクラスターにログインする必要があります。
手順
クラスターのプロジェクトを分離するには、以下のコマンドを実行します。
oc adm pod-network isolate-projects <project1> <project2>
$ oc adm pod-network isolate-projects <project1> <project2>Copy to Clipboard Copied! Toggle word wrap Toggle overflow または、特定のプロジェクト名を指定する代わりに
--selector=<project_selector>オプションを使用し、関連付けられたラベルに基づいてプロジェクトを指定できます。
9.13.4. プロジェクトのネットワーク分離の無効化 リンクのコピーリンクがクリップボードにコピーされました!
プロジェクトのネットワーク分離を無効にできます。
前提条件
-
OpenShift CLI (
oc) をインストールしている。 -
cluster-adminロールを持つユーザーとしてクラスターにログインする必要があります。
手順
プロジェクトの以下のコマンドを実行します。
oc adm pod-network make-projects-global <project1> <project2>
$ oc adm pod-network make-projects-global <project1> <project2>Copy to Clipboard Copied! Toggle word wrap Toggle overflow または、特定のプロジェクト名を指定する代わりに
--selector=<project_selector>オプションを使用し、関連付けられたラベルに基づいてプロジェクトを指定できます。
9.14. kube-proxy の設定 リンクのコピーリンクがクリップボードにコピーされました!
Kubernetes メットワークプロキシー (kube-proxy) は各ノードで実行され、Cluster Network Operator (CNO) で管理されます。kube-proxy は、サービスに関連付けられたエンドポイントの接続を転送するためのネットワークルールを維持します。
9.14.1. iptables ルールの同期について リンクのコピーリンクがクリップボードにコピーされました!
同期の期間は、Kubernetes ネットワークプロキシー (kube-proxy) がノードで iptables ルールを同期する頻度を定めます。
同期は、以下のイベントのいずれかが生じる場合に開始します。
- サービスまたはエンドポイントのクラスターへの追加、またはクラスターからの削除などのイベントが発生する。
- 最後の同期以後の時間が kube-proxy に定義される同期期間を超過している。
9.14.2. kube-proxy 設定パラメーター リンクのコピーリンクがクリップボードにコピーされました!
以下の kubeProxyConfig パラメーターを変更することができます。
OpenShift Container Platform 4.3 以降で強化されたパフォーマンスの向上により、iptablesSyncPeriod パラメーターを調整する必要はなくなりました。
| パラメーター | 説明 | 値 | デフォルト |
|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
9.14.3. kube-proxy 設定の変化 リンクのコピーリンクがクリップボードにコピーされました!
クラスターの Kubernetes ネットワークプロキシー設定を変更することができます。
前提条件
-
OpenShift CLI (
oc) をインストールしている。 -
cluster-adminロールで実行中のクラスターにログインします。
手順
以下のコマンドを実行して、
Network.operator.openshift.ioカスタムリソース (CR) を編集します。oc edit network.operator.openshift.io cluster
$ oc edit network.operator.openshift.io clusterCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のサンプル CR のように、kube-proxy 設定への変更内容で、CR の
kubeProxyConfigパラメーターを変更します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow ファイルを保存し、テキストエディターを編集します。
構文は、ファイルを保存し、エディターを終了する際に
ocコマンドによって検証されます。変更内容に構文エラーが含まれる場合、エディターはファイルを開き、エラーメッセージを表示します。以下のコマンドを実行して、設定の更新を確認します。
oc get networks.operator.openshift.io -o yaml
$ oc get networks.operator.openshift.io -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow オプション: 以下のコマンドを実行し、Cluster Network Operator が設定変更を受け入れていることを確認します。
oc get clusteroperator network
$ oc get clusteroperator networkCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE network 4.1.0-0.9 True False False 1m
NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE network 4.1.0-0.9 True False False 1mCopy to Clipboard Copied! Toggle word wrap Toggle overflow 設定の更新が正常に適用されると、
AVAILABLEフィールドがTrueになります。
第10章 OVN-Kubernetes デフォルト CNI ネットワークプロバイダー リンクのコピーリンクがクリップボードにコピーされました!
10.1. OVN-Kubernetes デフォルト Container Network Interface (CNI) ネットワークプロバイダーについて リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform クラスターは、Pod およびサービスネットワークに仮想化ネットワークを使用します。OVN-Kubernetes Container Network Interface (CNI) プラグインは、デフォルトのクラスターネットワークのネットワークプロバイダーです。
10.1.1. OVN-Kubernetes の機能 リンクのコピーリンクがクリップボードにコピーされました!
OVN-Kubernetes デフォルト Container Network Interface (CNI) ネットワークプロバイダーは、以下の機能を実装します。
- Open Virtual Network (OVN) を使用してネットワークトラフィックフローを管理します。OVN はコミュニティーで開発され、ベンダーに依存しないネットワーク仮想化ソリューションです。
- ingress および egress ルールを含む Kubernetes ネットワークポリシーのサポートを実装します。
- ノード間にオーバーレイネットワークを作成するには、VXLAN ではなく GENEVE (Generic Network Virtualization Encapsulation) プロトコルを使用します。
10.1.2. サポートされるデフォルトの CNI ネットワークプロバイダー機能マトリクス リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform は、OpenShift SDN と OVN-Kubernetes の 2 つのサポート対象のオプションをデフォルトの Container Network Interface (CNI) ネットワークプロバイダーに提供します。以下の表は、両方のネットワークプロバイダーの現在の機能サポートをまとめたものです。
| 機能 | OVN-Kubernetes [1] | OpenShift SDN |
|---|---|---|
| Egress IPs | サポート対象外 | サポート対象 |
| Egress ファイアウォール [2] | サポート対象外 | サポート対象 |
| Egress ルーター | サポート対象外 | サポート対象 |
| Kubernetes ネットワークポリシー | サポート対象 | 一部サポート対象 [3] |
| マルチキャスト | サポート対象 | サポート対象 |
- OpenShift Container Platform 4.4 では、テクノロジープレビュー機能としてのみ利用できます。
- egress ファイアウォールは、OpenShift SDN では egress ネットワークポリシーとしても知られています。これはネットワークポリシーの egress とは異なります。
-
egress ルールおよび一部の
ipBlockルールをサポートしません。
10.1.3. OVN-Kubernetes の公開メトリクス リンクのコピーリンクがクリップボードにコピーされました!
OVN-Kubernetes デフォルト Container Network Interface (CNI) ネットワークプロバイダーは、Prometheus ベースの OpenShift Container Platform クラスターモニタリングスタックで使用される特定のメトリクスを公開します。
| 名前 | 説明 |
|---|---|
|
| Pod が作成された時点から Pod が OVN-Kubernetes によってアノテーションが付けられる時点に生じるレイテンシー。レイテンシーが高いほど、Pod がネットワーク接続で利用可能になる前に経過する時間が長くなります。 |
10.2. プロジェクトのマルチキャストの有効化 リンクのコピーリンクがクリップボードにコピーされました!
Open Virtual Networking (OVN) Kubernetes ネットワークプラグインは、テクノロジープレビュー機能です。テクノロジープレビュー機能は Red Hat の実稼働環境でのサービスレベルアグリーメント (SLA) ではサポートされていないため、Red Hat では実稼働環境での使用を推奨していません。Red Hat は実稼働環境でこれらを使用することを推奨していません。これらの機能は、近々発表予定の製品機能をリリースに先駆けてご提供することにより、お客様は機能性をテストし、開発プロセス中にフィードバックをお寄せいただくことができます。
OVN テクノロジープレビュー機能のサポート範囲についての詳細は、https://access.redhat.com/articles/4380121 を参照してください。
OpenShift Container Platform 4.4 では、バグにより、同じ namespace にあるが、異なるノードに割り当てられている Pod がマルチキャストで通信できなくなります。詳細は、BZ#1843695 を参照してください。
10.2.1. マルチキャストについて リンクのコピーリンクがクリップボードにコピーされました!
IP マルチキャストを使用すると、データが多数の IP アドレスに同時に配信されます。
現時点で、マルチキャストは低帯域幅の調整またはサービスの検出での使用に最も適しており、高帯域幅のソリューションとしては適していません。
OpenShift Container Platform の Pod 間のマルチキャストトラフィックはデフォルトで無効にされます。OVN-Kubernetes デフォルト Container Network Interface (CNI) ネットワークプロバイダーを使用している場合には、プロジェクトごとにマルチキャストを有効にすることができます。
10.2.2. Pod 間のマルチキャストの有効化 リンクのコピーリンクがクリップボードにコピーされました!
プロジェクトの Pod でマルチキャストを有効にすることができます。
前提条件
-
OpenShift CLI (
oc) をインストールしている。 -
cluster-adminロールを持つユーザーとしてクラスターにログインする必要があります。
手順
以下のコマンドを実行し、プロジェクトのマルチキャストを有効にします。
<namespace>を、マルチキャストを有効にする必要のある namespace に置き換えます。oc annotate namespace <namespace> \ k8s.ovn.org/multicast-enabled=true$ oc annotate namespace <namespace> \ k8s.ovn.org/multicast-enabled=trueCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証手順
マルチキャストがプロジェクトについて有効にされていることを確認するには、以下の手順を実行します。
現在のプロジェクトを、マルチキャストを有効にしたプロジェクトに切り替えます。
<project>をプロジェクト名に置き換えます。oc project <project>
$ oc project <project>Copy to Clipboard Copied! Toggle word wrap Toggle overflow マルチキャストレシーバーとして機能する Pod を作成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow マルチキャストセンダーとして機能する Pod を作成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow マルチキャストリスナーを起動します。
Pod の IP アドレスを取得します。
POD_IP=$(oc get pods mlistener -o jsonpath='{.status.podIP}')$ POD_IP=$(oc get pods mlistener -o jsonpath='{.status.podIP}')Copy to Clipboard Copied! Toggle word wrap Toggle overflow マルチキャストリスナーを起動するには、新しいターミナルウィンドウまたはタブで以下のコマンドを入力します。
oc exec mlistener -i -t -- \ socat UDP4-RECVFROM:30102,ip-add-membership=224.1.0.1:$POD_IP,fork EXEC:hostname$ oc exec mlistener -i -t -- \ socat UDP4-RECVFROM:30102,ip-add-membership=224.1.0.1:$POD_IP,fork EXEC:hostnameCopy to Clipboard Copied! Toggle word wrap Toggle overflow
マルチキャストトランスミッターを開始します。
Pod ネットワーク IP アドレス範囲を取得します。
CIDR=$(oc get Network.config.openshift.io cluster \ -o jsonpath='{.status.clusterNetwork[0].cidr}')$ CIDR=$(oc get Network.config.openshift.io cluster \ -o jsonpath='{.status.clusterNetwork[0].cidr}')Copy to Clipboard Copied! Toggle word wrap Toggle overflow マルチキャストメッセージを送信するには、以下のコマンドを入力します。
oc exec msender -i -t -- \ /bin/bash -c "echo | socat STDIO UDP4-DATAGRAM:224.1.0.1:30102,range=$CIDR,ip-multicast-ttl=64"$ oc exec msender -i -t -- \ /bin/bash -c "echo | socat STDIO UDP4-DATAGRAM:224.1.0.1:30102,range=$CIDR,ip-multicast-ttl=64"Copy to Clipboard Copied! Toggle word wrap Toggle overflow マルチキャストが機能している場合、直前のコマンドは以下の出力を返します。
mlistener
mlistenerCopy to Clipboard Copied! Toggle word wrap Toggle overflow
10.3. プロジェクトのマルチキャストの無効化 リンクのコピーリンクがクリップボードにコピーされました!
Open Virtual Networking (OVN) Kubernetes ネットワークプラグインは、テクノロジープレビュー機能です。テクノロジープレビュー機能は Red Hat の実稼働環境でのサービスレベルアグリーメント (SLA) ではサポートされていないため、Red Hat では実稼働環境での使用を推奨していません。Red Hat は実稼働環境でこれらを使用することを推奨していません。これらの機能は、近々発表予定の製品機能をリリースに先駆けてご提供することにより、お客様は機能性をテストし、開発プロセス中にフィードバックをお寄せいただくことができます。
OVN テクノロジープレビュー機能のサポート範囲についての詳細は、https://access.redhat.com/articles/4380121 を参照してください。
10.3.1. Pod 間のマルチキャストの無効化 リンクのコピーリンクがクリップボードにコピーされました!
プロジェクトの Pod でマルチキャストを無効にすることができます。
前提条件
-
OpenShift CLI (
oc) をインストールしている。 -
cluster-adminロールを持つユーザーとしてクラスターにログインする必要があります。
手順
以下のコマンドを実行して、マルチキャストを無効にします。
oc annotate namespace <namespace> \ k8s.ovn.org/multicast-enabled-$ oc annotate namespace <namespace> \1 k8s.ovn.org/multicast-enabled-Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- マルチキャストを無効にする必要のあるプロジェクトの
namespace。
第11章 ルートの作成 リンクのコピーリンクがクリップボードにコピーされました!
11.1. ルート設定 リンクのコピーリンクがクリップボードにコピーされました!
11.1.1. ルートのタイムアウトの設定 リンクのコピーリンクがクリップボードにコピーされました!
Service Level Availability (SLA) で必要とされる、低タイムアウトが必要なサービスや、バックエンドでの処理速度が遅いケースで高タイムアウトが必要なサービスがある場合は、既存のルートに対してデフォルトのタイムアウトを設定することができます。
前提条件
- 実行中のクラスターでデプロイ済みの Ingress コントローラーが必要になります。
手順
oc annotateコマンドを使用して、ルートにタイムアウトを追加します。oc annotate route <route_name> \ --overwrite haproxy.router.openshift.io/timeout=<timeout><time_unit>$ oc annotate route <route_name> \ --overwrite haproxy.router.openshift.io/timeout=<timeout><time_unit>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- サポートされる時間単位は、マイクロ秒 (us)、ミリ秒 (ms)、秒 (s)、分 (m)、時間 (h)、または日 (d) です。
以下の例では、2 秒のタイムアウトを
myrouteという名前のルートに設定します。oc annotate route myroute --overwrite haproxy.router.openshift.io/timeout=2s
$ oc annotate route myroute --overwrite haproxy.router.openshift.io/timeout=2sCopy to Clipboard Copied! Toggle word wrap Toggle overflow
11.1.2. HTTP Strict Transport Security の有効化 リンクのコピーリンクがクリップボードにコピーされました!
HTTP Strict Transport Security (HSTS) ポリシーは、ホストで HTTPS トラフィックのみを許可するセキュリティーの拡張機能です。デフォルトで、すべての HTTP 要求はドロップされます。これは、web サイトとの対話の安全性を確保したり、ユーザーのためにセキュアなアプリケーションを提供するのに役立ちます。
HSTS が有効にされると、HSTS はサイトから Strict Transport Security ヘッダーを HTTPS 応答に追加します。リダイレクトするルートで insecureEdgeTerminationPolicy 値を使用し、HTTP を HTTPS に送信するようにします。ただし、HSTS が有効にされている場合は、要求の送信前にクライアントがすべての要求を HTTP URL から HTTPS に変更するためにリダイレクトの必要がなくなります。これはクライアントでサポートされる必要はなく、max-age=0 を設定することで無効にできます。
HSTS はセキュアなルート (edge termination または re-encrypt) でのみ機能します。この設定は、HTTP またはパススルールートには適していません。
手順
ルートに対して HSTS を有効にするには、
haproxy.router.openshift.io/hsts_header値を edge termination または re-encrypt ルートに追加します。apiVersion: v1 kind: Route metadata: annotations: haproxy.router.openshift.io/hsts_header: max-age=31536000;includeSubDomains;preloadapiVersion: v1 kind: Route metadata: annotations: haproxy.router.openshift.io/hsts_header: max-age=31536000;includeSubDomains;preload1 2 3 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
max-ageは唯一の必須パラメーターです。これは、HSTS ポリシーが有効な期間 (秒単位) を測定します。クライアントは、ホストから HSTS ヘッダーのある応答を受信する際には常にmax-ageを更新します。max-ageがタイムアウトになると、クライアントはポリシーを破棄します。- 2
includeSubDomainsはオプションです。これが含まれる場合、クライアントに対し、ホストのすべてのサブドメインがホストと同様に処理されるように指示します。- 3
preloadはオプションです。max-ageが 0 より大きい場合、preloadをhaproxy.router.openshift.io/hsts_headerに組み込むことにより、外部サービスはこのサイトをそれぞれの HSTS プリロード一覧に含めることができます。たとえば、Google などのサイトはpreloadが設定されているサイトの一覧を作成します。ブラウザーはこれらの一覧を使用し、サイトと対話する前でも HTTPS 経由で通信できるサイトを判別できます。preload設定がない場合、ブラウザーはヘッダーを取得するために HTTPS 経由でサイトと通信している必要があります。
11.1.3. スループット関連の問題のトラブルシューティング リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform でデプロイされるアプリケーションでは、特定のサービス間で非常に長い待ち時間が発生するなど、ネットワークのスループットの問題が生じることがあります。
Pod のログが問題の原因を指摘しない場合は、以下の方法を使用してパフォーマンスの問題を分析します。
ping または tcpdump などのパケットアナライザーを使用して Pod とそのノード間のトラフィックを分析します。
たとえば、問題を生じさせる動作を再現している間に各 Pod で tcpdump ツールを実行します。両サイトでキャプチャーしたデータを確認し、送信および受信タイムスタンプを比較して Pod への/からのトラフィックの待ち時間を分析します。待ち時間は、ノードのインターフェイスが他の Pod やストレージデバイス、またはデータプレーンからのトラフィックでオーバーロードする場合に OpenShift Container Platform で発生する可能性があります。
tcpdump -s 0 -i any -w /tmp/dump.pcap host <podip 1> && host <podip 2>
$ tcpdump -s 0 -i any -w /tmp/dump.pcap host <podip 1> && host <podip 2>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
podipは Pod の IP アドレスです。oc get pod <pod_name> -o wideコマンドを実行して Pod の IP アドレスを取得します。
tcpdump は 2 つの Pod 間のすべてのトラフィックが含まれる
/tmp/dump.pcapのファイルを生成します。理想的には、ファイルサイズを最小限に抑えるために問題を再現するすぐ前と問題を再現したすぐ後ににアナライザーを実行することが良いでしょう。以下のようにノード間でパケットアナライザーを実行することもできます (式から SDN を排除する)。tcpdump -s 0 -i any -w /tmp/dump.pcap port 4789
$ tcpdump -s 0 -i any -w /tmp/dump.pcap port 4789Copy to Clipboard Copied! Toggle word wrap Toggle overflow ストリーミングのスループットおよび UDP スループットを測定するために iperf などの帯域幅測定ツールを使用します。ボトルネックの特定を試行するには、最初に Pod から、次にノードからツールを実行します。
- iperf のインストールおよび使用についての詳細は、こちらの Red Hat ソリューション を参照してください。
11.1.4. Cookie に使用によるルートのステートフル性の維持 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform は、すべてのトラフィックを同じエンドポイントにヒットさせることによりステートフルなアプリケーションのトラフィックを可能にするスティッキーセッションを提供します。ただし、エンドポイント Pod が再起動、スケーリング、または設定の変更などによって終了する場合、このステートフル性はなくなります。
OpenShift Container Platform は Cookie を使用してセッションの永続化を設定できます。Ingress コントローラーはユーザー要求を処理するエンドポイントを選択し、そのセッションの Cookie を作成します。Cookie は要求の応答として戻され、ユーザーは Cookie をセッションの次の要求と共に送り返します。Cookie は Ingress コントローラーに対し、セッションを処理しているエンドポイントを示し、クライアント要求が Cookie を使用して同じ Pod にルーティングされるようにします。
11.1.4.1. Cookie を使用したルートのアノテーション リンクのコピーリンクがクリップボードにコピーされました!
ルート用に自動生成されるデフォルト名を上書きするために Cookie 名を設定できます。これにより、ルートトラフィックを受信するアプリケーションが Cookie 名を認識できるようになります。Cookie を削除すると、次の要求でエンドポイントの再選択が強制的に実行される可能性があります。そのためサーバーがオーバーロードしている場合には、クライアントからの要求を取り除き、それらの再分配を試行します。
手順
必要な Cookie 名でルートにアノテーションを付けます。
oc annotate route <route_name> router.openshift.io/<cookie_name>="-<cookie_annotation>"
$ oc annotate route <route_name> router.openshift.io/<cookie_name>="-<cookie_annotation>"Copy to Clipboard Copied! Toggle word wrap Toggle overflow たとえば、
my_cookie_annotationというアノテーションでmy_routeにmy_cookieという Cookie 名のアノテーションを付けるには、以下を実行します。oc annotate route my_route router.openshift.io/my_cookie="-my_cookie_annotation"
$ oc annotate route my_route router.openshift.io/my_cookie="-my_cookie_annotation"Copy to Clipboard Copied! Toggle word wrap Toggle overflow Cookie を保存し、ルートにアクセスします。
curl $my_route -k -c /tmp/my_cookie
$ curl $my_route -k -c /tmp/my_cookieCopy to Clipboard Copied! Toggle word wrap Toggle overflow
11.1.5. ルート固有のアノテーション リンクのコピーリンクがクリップボードにコピーされました!
Ingress コントローラーは、公開するすべてのルートのデフォルトオプションを設定できます。個別のルートは、アノテーションに個別の設定を指定して、デフォルトの一部を上書きできます。
| 変数 | 説明 | デフォルトで使用される環境変数 |
|---|---|---|
|
|
ロードバランシングアルゴリズムを設定します。使用できるオプションは |
パススルールートの |
|
|
関連の接続を追跡する cookie の使用を無効にします。 | |
|
| このルートに使用するオプションの cookie を指定します。名前は、大文字、小文字、数字、"_" または "-" を任意に組み合わせて指定する必要があります。デフォルトは、ルートのハッシュ化された内部キー名です。 | |
|
| ルーターからバッキングされる Pod に対して許容される接続最大数を設定します。注意: Pod が複数ある場合には、それぞれに対応する接続数を設定できますが、ルーターが複数ある場合には、ルーター間の連携がなく、それぞれの接続回数はルーターの数と同じとなります。ただし、複数のルーターがある場合は、それらのルーター間で調整は行われず、それぞれがこれに複数回接続する可能性があります。設定されていない場合または 0 に設定されている場合には制限はありません。 | |
|
|
レート制限機能を有効にするために | |
|
| IP アドレスで共有される同時 TCP 接続の数を制限します。 | |
|
| IP アドレスが HTTP 要求を実行できるレートを制限します。 | |
|
| IP アドレスが TCP 接続を行うレートを制限します。 | |
|
| ルートのサーバー側のタイムアウトを設定します。(TimeUnits) |
|
|
| バックエンドのヘルスチェックの間隔を設定します。(TimeUnits) |
|
|
| ルートのホワイトリストを設定します。ホワイトリストは、承認したソースアドレスの IP アドレスおよび CIDR 範囲の一覧をスペース区切りにします。ホワイトリストに含まれていない IP アドレスからの要求は破棄されます。 | |
|
| edge terminated または re-encrypt ルートの Strick-Transport-Security ヘッダーを設定します。 |
環境変数を編集することはできません。
ルート設定のカスタムタイムアウト
- 1
- HAProxy 対応の単位 (
us、ms、s、m、h、d) で新規のタイムアウトを指定します。単位が指定されていない場合は、msがデフォルトになります。
パススルールートのサーバー側のタイムアウト値を低く設定し過ぎると、WebSocket 接続がそのルートで頻繁にタイムアウトする可能性があります。
特定の IP アドレスを 1 つだけ許可するルート
metadata:
annotations:
haproxy.router.openshift.io/ip_whitelist: 192.168.1.10
metadata:
annotations:
haproxy.router.openshift.io/ip_whitelist: 192.168.1.10
複数の IP アドレスを許可するルート
metadata:
annotations:
haproxy.router.openshift.io/ip_whitelist: 192.168.1.10 192.168.1.11 192.168.1.12
metadata:
annotations:
haproxy.router.openshift.io/ip_whitelist: 192.168.1.10 192.168.1.11 192.168.1.12
IP アドレスの CIDR ネットワークを許可するルート
metadata:
annotations:
haproxy.router.openshift.io/ip_whitelist: 192.168.1.0/24
metadata:
annotations:
haproxy.router.openshift.io/ip_whitelist: 192.168.1.0/24
IP アドレスと IP アドレスの CIDR ネットワークの両方を許可するルート
metadata:
annotations:
haproxy.router.openshift.io/ip_whitelist: 180.5.61.153 192.168.1.0/24 10.0.0.0/8
metadata:
annotations:
haproxy.router.openshift.io/ip_whitelist: 180.5.61.153 192.168.1.0/24 10.0.0.0/8
11.1.6. ルートの受付ポリシーの設定 リンクのコピーリンクがクリップボードにコピーされました!
管理者およびアプリケーション開発者は、同じドメイン名を持つ複数の namespace でアプリケーションを実行できます。これは、複数のチームが同じホスト名で公開されるマイクロサービスを開発する組織を対象としています。
複数の namespace での要求の許可は、namespace 間の信頼のあるクラスターに対してのみ有効にする必要があります。有効にしないと、悪意のあるユーザーがホスト名を乗っ取る可能性があります。このため、デフォルトの受付ポリシーは複数の namespace 間でのホスト名の要求を許可しません。
前提条件
- クラスター管理者の権限。
手順
以下のコマンドを使用して、
ingresscontrollerリソース変数の.spec.routeAdmissionフィールドを編集します。oc -n openshift-ingress-operator patch ingresscontroller/default --patch '{"spec":{"routeAdmission":{"namespaceOwnership":"InterNamespaceAllowed"}}}' --type=merge$ oc -n openshift-ingress-operator patch ingresscontroller/default --patch '{"spec":{"routeAdmission":{"namespaceOwnership":"InterNamespaceAllowed"}}}' --type=mergeCopy to Clipboard Copied! Toggle word wrap Toggle overflow イメージコントローラー設定例
spec: routeAdmission: namespaceOwnership: InterNamespaceAllowed ...spec: routeAdmission: namespaceOwnership: InterNamespaceAllowed ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow
11.2. セキュリティー保護されたルート リンクのコピーリンクがクリップボードにコピーされました!
以下のセクションでは、カスタム証明書を使用して re-encrypt および edge ルートを作成する方法を説明します。
パブリックエンドポイントを使用して Microsoft Azure にルートを作成する場合、リソース名は制限されます。特定の用語を使用するリソースを作成することはできません。Azure が制限する語の一覧は、Azure ドキュメントの Resolve reserved resource name errors を参照してください。
11.2.1. カスタム証明書を使用した re-encrypt ルートの作成 リンクのコピーリンクがクリップボードにコピーされました!
oc create route コマンドを使用し、カスタム証明書と共に reencrypt TLS termination を使用してセキュアなルートを設定できます。
前提条件
- PEM エンコードされたファイルに証明書/キーのペアがなければなりません。 ここで、証明書はルートホストに対して有効である必要があります。
- 証明書チェーンを完了する PEM エンコードされたファイルの別の CA 証明書が必要です。
- PEM エンコードされたファイルの別の宛先 CA 証明書が必要です。
- 公開する必要のあるサービスが必要です。
パスワードで保護されるキーファイルはサポートされません。キーファイルからパスフレーズを削除するには、以下のコマンドを使用します。
openssl rsa -in password_protected_tls.key -out tls.key
$ openssl rsa -in password_protected_tls.key -out tls.key
手順
この手順では、カスタム証明書および reencrypt TLS termination を使用して Route リソースを作成します。以下では、証明書/キーのペアが現在の作業ディレクトリーの tls.crt および tls.key ファイルにあることを前提としています。また、Ingress コントローラーがサービスの証明書を信頼できるように宛先 CA 証明書を指定する必要もあります。必要な場合には、証明書チェーンを完了するために CA 証明書を指定することもできます。tls.crt、 tls.key、cacert.crt、および (オプションで) ca.crt を実際のパス名に置き換えます。frontend を、公開する必要のある Service リソースに置き換えます。www.example.com を適切な名前に置き換えます。
reencrypt TLS 終端およびカスタム証明書を使用してセキュアな
Routeリソースを作成します。oc create route reencrypt --service=frontend --cert=tls.crt --key=tls.key --dest-ca-cert=destca.crt --ca-cert=ca.crt --hostname=www.example.com
$ oc create route reencrypt --service=frontend --cert=tls.crt --key=tls.key --dest-ca-cert=destca.crt --ca-cert=ca.crt --hostname=www.example.comCopy to Clipboard Copied! Toggle word wrap Toggle overflow 結果として生成される
Routeリソースを検査すると、以下のようになります。セキュアなルートの YAML 定義
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 他のオプションについては、
oc create route reencrypt --helpを参照してください。
11.2.2. カスタム証明書を使用した edge ルートの作成 リンクのコピーリンクがクリップボードにコピーされました!
oc create route コマンドを使用し、edge TLS termination とカスタム証明書を使用してセキュアなルートを設定できます。edge ルートの場合、Ingress コントローラーは、トラフィックを宛先 Pod に転送する前に TLS 暗号を終了します。ルートは、Ingress コントローラーがルートに使用する TLS 証明書およびキーを指定します。
前提条件
- PEM エンコードされたファイルに証明書/キーのペアがなければなりません。 ここで、証明書はルートホストに対して有効である必要があります。
- 証明書チェーンを完了する PEM エンコードされたファイルの別の CA 証明書が必要です。
- 公開する必要のあるサービスが必要です。
パスワードで保護されるキーファイルはサポートされません。キーファイルからパスフレーズを削除するには、以下のコマンドを使用します。
openssl rsa -in password_protected_tls.key -out tls.key
$ openssl rsa -in password_protected_tls.key -out tls.key
手順
この手順では、カスタム証明書および edge TLS termination を使用して Route リソースを作成します。以下では、証明書/キーのペアが現在の作業ディレクトリーの tls.crt および tls.key ファイルにあることを前提としています。必要な場合には、証明書チェーンを完了するために CA 証明書を指定することもできます。tls.crt、 tls.key、および (オプションで) ca.crt を実際のパス名に置き換えます。frontend を、公開する必要のあるサービスの名前に置き換えます。www.example.com を適切な名前に置き換えます。
edge TLS termination およびカスタム証明書を使用して、セキュアな
Routeリソースを作成します。oc create route edge --service=frontend --cert=tls.crt --key=tls.key --ca-cert=ca.crt --hostname=www.example.com
$ oc create route edge --service=frontend --cert=tls.crt --key=tls.key --ca-cert=ca.crt --hostname=www.example.comCopy to Clipboard Copied! Toggle word wrap Toggle overflow 結果として生成される
Routeリソースを検査すると、以下のようになります。セキュアなルートの YAML 定義
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 他のオプションについては、
oc create route edge --helpを参照してください。
第12章 ingress クラスタートラフィックの設定 リンクのコピーリンクがクリップボードにコピーされました!
12.1. ingress クラスタートラフィックの設定の概要 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform は、クラスター内で実行されるサービスを使ってクラスター外からの通信を可能にする以下の方法を提供します。
以下の方法が推奨されます。以下は、これらの方法の優先される順です。
- HTTP/HTTPS を使用する場合は Ingress コントローラーを使用する。
- HTTPS 以外の TLS で暗号化されたプロトコルを使用する場合、たとえば、SNI ヘッダーを使用する TLS の場合は、Ingress コントローラーを使用します。
-
それ以外の場合は、ロードバランサー、外部 IP、または
NodePortを使用します。
| 方法 | 目的 |
|---|---|
| HTTP/HTTPS トラフィックおよび HTTPS 以外の TLS で暗号化されたプロトコル (TLS と SNI ヘッダーの使用など) へのアクセスを許可します。 | |
| プールから割り当てられた IP アドレスを使った非標準ポートへのトラフィックを許可します。 | |
| 特定の IP アドレスを使った非標準ポートへのトラフィックを許可します。 | |
| クラスターのすべてのノードでサービスを公開します。 |
12.2. サービスの ExternalIP の設定 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、トラフィックをクラスター内のサービスに送信できるクラスター外の IP アドレスブロックを指定できます。
この機能は通常、ベアメタルハードウェアにインストールされているクラスターに最も役立ちます。
12.2.1. 前提条件 リンクのコピーリンクがクリップボードにコピーされました!
- ネットワークインフラストラクチャーは、外部 IP アドレスのトラフィックをクラスターにルーティングする必要があります。
12.2.2. ExternalIP について リンクのコピーリンクがクリップボードにコピーされました!
クラウド以外の環境では、OpenShift Container Platform は ExternalIP 機能を使用して外部 IP アドレスの Service オブジェクトの spec.externalIPs フィールドへの割り当てをサポートします。これにより、サービスに割り当てられた追加の仮想 IP アドレスが公開されます。これはクラスターに定義されたサービスネットワーク外にある可能性があります。type=NodePort が設定されたサービスと同様に外部 IP 機能で設定されたサービスにより、トラフィックを負荷分散のためにローカルノードに転送することができます。
ネットワークインフラストラクチャーを設定し、定義する外部 IP アドレスブロックがクラスターにルーティングされるようにする必要があります。
OpenShift Container Platform は以下の機能を追加して Kubernetes の ExternalIP 機能を拡張します。
- 設定可能なポリシーによる外部 IP アドレスの使用の制限
- 要求時の外部 IP アドレスのサービスへの自動割り当て
デフォルトでは、cluster-admin 権限を持つユーザーのみが、spec.externalIPs[] が外部 IP アドレスブロック内に定義された IP アドレスに設定された Service オブジェクトを作成できます。
ExternalIP 機能の使用はデフォルトで無効にされます。これは、外部 IP アドレスへのクラスター内のトラフィックがそのサービスにダイレクトされるため、セキュリティー上のリスクを生じさせる可能性があります。これにより、クラスターユーザーは外部リソースについての機密性の高いトラフィックをインターセプトできるようになります。
この機能は、クラウド以外のデプロイメントでのみサポートされます。クラウドデプロイメントの場合、クラウドの自動デプロイメントのためにロードバランサーサービスを使用し、サービスのエンドポイントをターゲットに設定します。
以下の方法で外部 IP アドレスを割り当てることができます。
- 外部 IP の自動割り当て
-
OpenShift Container Platform は、
spec.type=LoadBalancerを設定してServiceオブジェクトを作成する際に、IP アドレスをautoAssignCIDRsCIDR ブロックからspec.externalIPs[]配列に自動的に割り当てます。この場合、OpenShift Container Platform はロードバランサーサービスタイプのクラウド以外のバージョンを実装し、IP アドレスをサービスに割り当てます。自動割り当てはデフォルトで無効にされており、以下のセクションで説明されているように、これはクラスター管理者が設定する必要があります。 - 外部 IP の手動割り当て
-
OpenShift Container Platform は
Serviceオブジェクトの作成時にspec.externalIPs[]配列に割り当てられた IP アドレスを使用します。別のサービスによってすでに使用されている IP アドレスを指定することはできません。
12.2.2.1. ExternalIP の設定 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform での外部 IP アドレスの使用は、cluster という名前の Network.config.openshift.io CR の以下のフィールドで管理されます。
-
spec.externalIP.autoAssignCIDRsは、サービスの外部 IP アドレスを選択する際にロードバランサーによって使用される IP アドレスブロックを定義します。OpenShift Container Platform は、自動割り当て用の単一 IP アドレスブロックのみをサポートします。これは、ExternalIP をサービスに手動で割り当てる際に、制限された数の共有 IP アドレスのポート領域を管理しなくてはならない場合よりも単純になります。自動割り当てが有効な場合には、spec.type=LoadBalancerが設定されたServiceオブジェクトには外部 IP アドレスが割り当てられます。 -
spec.externalIP.policyは、IP アドレスを手動で指定する際に許容される IP アドレスブロックを定義します。OpenShift Container Platform は、spec.externalIP.autoAssignCIDRsで定義される IP アドレスブロックにポリシールールを適用しません。
ルーティングが正しく行われると、設定された外部 IP アドレスブロックからの外部トラフィックは、サービスが公開する TCP ポートまたは UDP ポートを介してサービスのエンドポイントに到達できます。
割り当てる IP アドレスブロックがクラスター内の 1 つ以上のノードで終了することを確認する必要があります。
OpenShift Container Platform は IP アドレスの自動および手動割り当ての両方をサポートしており、それぞれのアドレスは 1 つのサービスの最大数に割り当てられることが保証されます。これにより、各サービスは、ポートが他のサービスで公開されているかによらず、自らの選択したポートを公開できます。
OpenShift Container Platform の autoAssignCIDRs で定義された IP アドレスブロックを使用するには、ホストのネットワークに必要な IP アドレスの割り当ておよびルーティングを設定する必要があります。
以下の YAML は、外部 IP アドレスが設定されたサービスについて説明しています。
spec.externalIPs[] が設定された Service オブジェクトの例
12.2.2.2. 外部 IP アドレスの割り当ての制限 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、IP アドレスブロックを指定して許可および拒否できます。
spec.ExternalIP.policy フィールドを指定して、policy オブジェクトが定義された IP アドレスポリシーを設定します。ポリシーオブジェクトには以下の形があります。
ポリシーの制限を設定する際に、以下のルールが適用されます。
-
policy={}が設定される場合、spec.ExternalIPs[]が設定されているServiceオブジェクトの作成は失敗します。これは OpenShift Container Platform のデフォルトです。 -
policy=nullが設定される場合、spec.ExternalIPs[]が IP アドレスに設定されるServiceオブジェクトの作成は許可されます。 policyが設定され、policy.allowedCIDRs[]またはpolicy.rejectedCIDRs[]のいずれかが設定される場合、以下のルールが適用されます。-
allowedCIDRs[]とrejectedCIDRs[]の両方が設定される場合、rejectedCIDRs[]がallowedCIDRs[]よりも優先されます。 -
allowedCIDRs[]が設定される場合、spec.ExternalIPs[]が設定されているServiceオブジェクトの作成は、指定された IP アドレスが許可される場合にのみ正常に実行されます。 -
rejectedCIDRs[]が設定される場合、spec.ExternalIPs[]が設定されているServiceオブジェクトの作成は、指定された IP アドレスが拒否されていない場合にのみ正常に実行されます。
-
12.2.2.3. ポリシーオブジェクトの例 リンクのコピーリンクがクリップボードにコピーされました!
以下に続く例では、複数のポリシー設定の例を示します。
以下の例では、ポリシーは OpenShift Container Platform が外部 IP アドレスが指定されたサービスを作成するのを防ぎます。
Serviceオブジェクトのspec.externalIPs[]に指定された値を拒否するポリシーの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下の例では、
allowedCIDRsおよびrejectedCIDRsフィールドの両方が設定されます。許可される、および拒否される CIDR ブロックの両方を含むポリシーの例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下の例では、
policyはnullに設定されます。nullに設定されている場合、oc get networks.config.openshift.io -o yamlを入力して設定オブジェクトを検査する際に、policyフィールドは出力に表示されません。Serviceオブジェクトのspec.externalIPs[]に指定された値を許可するポリシーの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow
12.2.3. ExternalIP アドレスブロックの設定 リンクのコピーリンクがクリップボードにコピーされました!
ExternalIP アドレスブロックの設定は、cluster という名前の Network カスタムリソース (CR) で定義されます。ネットワーク CR は config.openshift.io API グループに含まれます。
クラスターのインストール時に、Cluster Version Operator (CVO) は cluster という名前のネットワーク CR を自動的に作成します。このタイプのその他の CR オブジェクトの作成はサポートされていません。
以下の YAML は ExternalIP 設定について説明しています。
cluster という名前の network.config.openshift.io CR
以下の YAML は、policy スタンザのフィールドについて説明しています。
Network.config.openshift.io policy スタンザ
policy: allowedCIDRs: [] rejectedCIDRs: []
policy:
allowedCIDRs: []
rejectedCIDRs: []
外部 IP 設定の例
外部 IP アドレスプールの予想される複数の設定が以下の例で表示されています。
以下の YAML は、自動的に割り当てられた外部 IP アドレスを有効にする設定について説明しています。
spec.externalIP.autoAssignCIDRsが設定された設定例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下の YAML は、許可された、および拒否された CIDR 範囲のポリシールールを設定します。
spec.externalIP.policyが設定された設定例Copy to Clipboard Copied! Toggle word wrap Toggle overflow
12.2.4. クラスターの外部 IP アドレスブロックの設定 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、以下の ExternalIP を設定できます。
-
Serviceオブジェクトのspec.clusterIPフィールドを自動的に設定するために OpenShift Container Platform によって使用される ExternalIP アドレスブロック。 -
IP アドレスを制限するポリシーオブジェクトは
Serviceオブジェクトのspec.clusterIP配列に手動で割り当てられます。
前提条件
-
OpenShift CLI (
oc) をインストールしている。 -
cluster-adminロールを持つユーザーとしてクラスターにアクセスできる。
手順
オプション: 現在の外部 IP 設定を表示するには、以下のコマンドを入力します。
oc describe networks.config cluster
$ oc describe networks.config clusterCopy to Clipboard Copied! Toggle word wrap Toggle overflow 設定を編集するには、以下のコマンドを入力します。
oc edit networks.config cluster
$ oc edit networks.config clusterCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下の例のように ExternalIP 設定を変更します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
externalIPスタンザの設定を指定します。
更新された ExternalIP 設定を確認するには、以下のコマンドを入力します。
oc get networks.config cluster -o go-template='{{.spec.externalIP}}{{"\n"}}'$ oc get networks.config cluster -o go-template='{{.spec.externalIP}}{{"\n"}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow
12.2.5. 次のステップ リンクのコピーリンクがクリップボードにコピーされました!
12.3. Ingress コントローラーを使用した Ingress クラスターの設定 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform は、クラスター内で実行されるサービスを使ってクラスター外からの通信を可能にする方法を提供します。この方法は Ingress コントローラーを使用します。
12.3.1. Ingress コントローラーおよびルートの使用 リンクのコピーリンクがクリップボードにコピーされました!
Ingress Operator は Ingress コントローラーおよびワイルドカード DNS を管理します。
Ingress コントローラーの使用は、OpenShift Container Platform クラスターへの外部アクセスを許可するための最も一般的な方法です。
Ingress コントローラーは外部要求を許可し、設定されたルートに基づいてそれらをプロキシー送信するよう設定されます。これは、HTTP、SNI を使用する HTTPS、SNI を使用する TLS に限定されており、SNI を使用する TLS で機能する Web アプリケーションやサービスには十分な設定です。
管理者と連携して Ingress コントローラーを設定します。外部要求を許可し、設定されたルートに基づいてそれらをプロキシー送信するように Ingress コントローラーを設定します。
管理者はワイルドカード DNS エントリーを作成してから Ingress コントローラーを設定できます。その後は管理者に問い合わせることなく edge Ingress コントローラーと連携できます。
一連のルートが各種プロジェクトで作成される場合、ルートのセット全体が一連の Ingress コントローラーで利用可能になります。それぞれの Ingress コントローラーはルートのセットからのルートを許可します。デフォルトで、すべての Ingress コントローラーはすべてのルートを許可します。
Ingress コントローラー:
- デフォルトでは 2 つのレプリカがあるので、これは 2 つのワーカーノードで実行する必要があります。
- 追加のノードにレプリカを組み込むためにスケールアップすることができます。
このセクションの手順では、クラスターの管理者が事前に行っておく必要のある前提条件があります。
12.3.2. 前提条件 リンクのコピーリンクがクリップボードにコピーされました!
以下の手順を開始する前に、管理者は以下の条件を満たしていることを確認する必要があります。
- 要求がクラスターに到達できるように、クラスターネットワーク環境に対して外部ポートをセットアップします。
クラスター管理者ロールを持つユーザーが 1 名以上いることを確認します。このロールをユーザーに追加するには、以下のコマンドを実行します。
oc adm policy add-cluster-role-to-user cluster-admin username
oc adm policy add-cluster-role-to-user cluster-admin usernameCopy to Clipboard Copied! Toggle word wrap Toggle overflow - OpenShift Container Platform クラスターを、1 つ以上のマスターと 1 つ以上のノード、およびクラスターへのネットワークアクセスのあるクラスター外のシステムと共に用意します。この手順では、外部システムがクラスターと同じサブセットにあることを前提とします。別のサブセットの外部システムに必要な追加のネットワーク設定については、このトピックでは扱いません。
12.3.3. プロジェクトおよびサービスの作成 リンクのコピーリンクがクリップボードにコピーされました!
公開するプロジェクトおよびサービスが存在しない場合、最初にプロジェクトを作成し、次にサービスを作成します。
プロジェクトおよびサービスがすでに存在する場合は、サービスを公開してルートを作成する手順に進みます。
前提条件
-
クラスター管理者として
ocCLI をインストールし、ログインします。
手順
サービスの新規プロジェクトを作成します。
oc new-project <project_name>
$ oc new-project <project_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下は例になります。
oc new-project myproject
$ oc new-project myprojectCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc new-appコマンドを使用してサービスを作成します。以下は例になります。oc new-app \ -e MYSQL_USER=admin \ -e MYSQL_PASSWORD=redhat \ -e MYSQL_DATABASE=mysqldb \ registry.redhat.io/rhscl/mysql-80-rhel7$ oc new-app \ -e MYSQL_USER=admin \ -e MYSQL_PASSWORD=redhat \ -e MYSQL_DATABASE=mysqldb \ registry.redhat.io/rhscl/mysql-80-rhel7Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行して新規サービスが作成されていることを確認します。
oc get svc -n myproject
$ oc get svc -n myprojectCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE mysql-80-rhel7 ClusterIP 172.30.63.31 <none> 3306/TCP 4m55s
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE mysql-80-rhel7 ClusterIP 172.30.63.31 <none> 3306/TCP 4m55sCopy to Clipboard Copied! Toggle word wrap Toggle overflow デフォルトで、新規サービスには外部 IP アドレスがありません。
12.3.4. ルートの作成によるサービスの公開 リンクのコピーリンクがクリップボードにコピーされました!
oc expose コマンドを使用して、サービスをルートとして公開することができます。
手順
サービスを公開するには、以下を実行します。
- OpenShift Container Platform にログインします。
公開するサービスが置かれているプロジェクトにログインします。
oc project project1
$ oc project project1Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行してルートを公開します。
oc expose service <service_name>
$ oc expose service <service_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下は例になります。
oc expose service mysql-80-rhel7
$ oc expose service mysql-80-rhel7Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
route "mysql-80-rhel7" exposed
route "mysql-80-rhel7" exposedCopy to Clipboard Copied! Toggle word wrap Toggle overflow cURL などのツールを使用し、サービスのクラスター IP アドレスを使用してサービスに到達できることを確認します。
curl <pod_ip>:<port>
$ curl <pod_ip>:<port>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下は例になります。
curl 172.30.131.89:3306
$ curl 172.30.131.89:3306Copy to Clipboard Copied! Toggle word wrap Toggle overflow このセクションの例では、クライアントアプリケーションを必要とする MySQL サービスを使用しています。
Got packets out of orderのメッセージと共に文字ストリングを取得する場合は、このサービスに接続されていることになります。MySQL クライアントがある場合は、標準 CLI コマンドでログインします。
mysql -h 172.30.131.89 -u admin -p
$ mysql -h 172.30.131.89 -u admin -pCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Enter password: Welcome to the MariaDB monitor. Commands end with ; or \g. MySQL [(none)]>
Enter password: Welcome to the MariaDB monitor. Commands end with ; or \g. MySQL [(none)]>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
12.3.5. ルートラベルを使用した Ingress コントローラーのシャード化の設定 リンクのコピーリンクがクリップボードにコピーされました!
ルートラベルを使用した Ingress コントローラーのシャード化とは、Ingress コントローラーがルートセレクターによって選択される任意 namespace の任意のルートを提供することを意味します。
Ingress コントローラーのシャード化は、一連の Ingress コントローラー間で着信トラフィックの負荷を分散し、トラフィックを特定の Ingress コントローラーに分離する際に役立ちます。たとえば、Company A のトラフィックをある Ingress コントローラーに指定し、Company B を別の Ingress コントローラーに指定できます。
手順
router-internal.yamlファイルを編集します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow Ingress コントローラーの
router-internal.yamlファイルを適用します。oc apply -f router-internal.yaml
# oc apply -f router-internal.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow Ingress コントローラーは、
type: shardedというラベルのある namespace のルートを選択します。
12.3.6. namespace ラベルを使用した Ingress コントローラーのシャード化の設定 リンクのコピーリンクがクリップボードにコピーされました!
namespace ラベルを使用した Ingress コントローラーのシャード化とは、Ingress コントローラーが namespace セレクターによって選択される任意の namespace の任意のルートを提供することを意味します。
Ingress コントローラーのシャード化は、一連の Ingress コントローラー間で着信トラフィックの負荷を分散し、トラフィックを特定の Ingress コントローラーに分離する際に役立ちます。たとえば、Company A のトラフィックをある Ingress コントローラーに指定し、Company B を別の Ingress コントローラーに指定できます。
手順
router-internal.yamlファイルを編集します。cat router-internal.yaml
# cat router-internal.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Ingress コントローラーの
router-internal.yamlファイルを適用します。oc apply -f router-internal.yaml
# oc apply -f router-internal.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow Ingress コントローラーは、
type: shardedというラベルのある namespace セレクターによって選択される namespace のルートを選択します。
12.3.7. 関連情報 リンクのコピーリンクがクリップボードにコピーされました!
- Ingress Operator はワイルドカード DNS を管理します。詳細は、OpenShift Container Platform の Ingress Operator 、Installing a cluster on bare metal、および Installing a cluster on vSphere を参照してください。
12.4. ロードバランサーを使用した ingress クラスターの設定 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform は、クラスター内で実行されるサービスを使ってクラスター外からの通信を可能にする方法を提供します。この方法では、ロードバランサーを使用します。
12.4.1. ロードバランサーを使用したトラフィックのクラスターへの送信 リンクのコピーリンクがクリップボードにコピーされました!
特定の外部 IP アドレスを必要としない場合、ロードバランサーサービスを OpenShift Container Platform クラスターへの外部アクセスを許可するよう設定することができます。
ロードバランサーサービスは固有の IP を割り当てます。ロードバランサーには単一の edge ルーター IP があります (これは仮想 IP (VIP) の場合もありますが、初期の負荷分散では単一マシンになります。
プールが設定される場合、これはクラスター管理者によってではなく、インフラストラクチャーレベルで実行されます。
このセクションの手順では、クラスターの管理者が事前に行っておく必要のある前提条件があります。
12.4.2. 前提条件 リンクのコピーリンクがクリップボードにコピーされました!
以下の手順を開始する前に、管理者は以下の条件を満たしていることを確認する必要があります。
- 要求がクラスターに到達できるように、クラスターネットワーク環境に対して外部ポートをセットアップします。
クラスター管理者ロールを持つユーザーが 1 名以上いることを確認します。このロールをユーザーに追加するには、以下のコマンドを実行します。
oc adm policy add-cluster-role-to-user cluster-admin username
oc adm policy add-cluster-role-to-user cluster-admin usernameCopy to Clipboard Copied! Toggle word wrap Toggle overflow - OpenShift Container Platform クラスターを、1 つ以上のマスターと 1 つ以上のノード、およびクラスターへのネットワークアクセスのあるクラスター外のシステムと共に用意します。この手順では、外部システムがクラスターと同じサブセットにあることを前提とします。別のサブセットの外部システムに必要な追加のネットワーク設定については、このトピックでは扱いません。
12.4.3. プロジェクトおよびサービスの作成 リンクのコピーリンクがクリップボードにコピーされました!
公開するプロジェクトおよびサービスが存在しない場合、最初にプロジェクトを作成し、次にサービスを作成します。
プロジェクトおよびサービスがすでに存在する場合は、サービスを公開してルートを作成する手順に進みます。
前提条件
-
クラスター管理者として
ocCLI をインストールし、ログインします。
手順
サービスの新規プロジェクトを作成します。
oc new-project <project_name>
$ oc new-project <project_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下は例になります。
oc new-project myproject
$ oc new-project myprojectCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc new-appコマンドを使用してサービスを作成します。以下は例になります。oc new-app \ -e MYSQL_USER=admin \ -e MYSQL_PASSWORD=redhat \ -e MYSQL_DATABASE=mysqldb \ registry.redhat.io/rhscl/mysql-80-rhel7$ oc new-app \ -e MYSQL_USER=admin \ -e MYSQL_PASSWORD=redhat \ -e MYSQL_DATABASE=mysqldb \ registry.redhat.io/rhscl/mysql-80-rhel7Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行して新規サービスが作成されていることを確認します。
oc get svc -n myproject
$ oc get svc -n myprojectCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE mysql-80-rhel7 ClusterIP 172.30.63.31 <none> 3306/TCP 4m55s
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE mysql-80-rhel7 ClusterIP 172.30.63.31 <none> 3306/TCP 4m55sCopy to Clipboard Copied! Toggle word wrap Toggle overflow デフォルトで、新規サービスには外部 IP アドレスがありません。
12.4.4. ルートの作成によるサービスの公開 リンクのコピーリンクがクリップボードにコピーされました!
oc expose コマンドを使用して、サービスをルートとして公開することができます。
手順
サービスを公開するには、以下を実行します。
- OpenShift Container Platform にログインします。
公開するサービスが置かれているプロジェクトにログインします。
oc project project1
$ oc project project1Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行してルートを公開します。
oc expose service <service_name>
$ oc expose service <service_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下は例になります。
oc expose service mysql-80-rhel7
$ oc expose service mysql-80-rhel7Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
route "mysql-80-rhel7" exposed
route "mysql-80-rhel7" exposedCopy to Clipboard Copied! Toggle word wrap Toggle overflow cURL などのツールを使用し、サービスのクラスター IP アドレスを使用してサービスに到達できることを確認します。
curl <pod_ip>:<port>
$ curl <pod_ip>:<port>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下は例になります。
curl 172.30.131.89:3306
$ curl 172.30.131.89:3306Copy to Clipboard Copied! Toggle word wrap Toggle overflow このセクションの例では、クライアントアプリケーションを必要とする MySQL サービスを使用しています。
Got packets out of orderのメッセージと共に文字ストリングを取得する場合は、このサービスに接続されていることになります。MySQL クライアントがある場合は、標準 CLI コマンドでログインします。
mysql -h 172.30.131.89 -u admin -p
$ mysql -h 172.30.131.89 -u admin -pCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Enter password: Welcome to the MariaDB monitor. Commands end with ; or \g. MySQL [(none)]>
Enter password: Welcome to the MariaDB monitor. Commands end with ; or \g. MySQL [(none)]>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
12.4.5. ロードバランサーサービスの作成 リンクのコピーリンクがクリップボードにコピーされました!
以下の手順を使用して、ロードバランサーサービスを作成します。
前提条件
- 公開するプロジェクトとサービスがあること。
手順
ロードバランサーサービスを作成するには、以下を実行します。
- OpenShift Container Platform にログインします。
公開するサービスが置かれているプロジェクトを読み込みます。
oc project project1
$ oc project project1Copy to Clipboard Copied! Toggle word wrap Toggle overflow マスターノードでテキストファイルを開き、以下のテキストを貼り付け、必要に応じてファイルを編集します。
ロードバランサー設定ファイルのサンプル
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - ファイルを保存し、終了します。
以下のコマンドを実行してサービスを作成します。
oc create -f <file-name>
$ oc create -f <file-name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下に例を示します。
oc create -f mysql-lb.yaml
$ oc create -f mysql-lb.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行して新規サービスを表示します。
oc get svc
$ oc get svcCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE egress-2 LoadBalancer 172.30.22.226 ad42f5d8b303045-487804948.example.com 3306:30357/TCP 15m
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE egress-2 LoadBalancer 172.30.22.226 ad42f5d8b303045-487804948.example.com 3306:30357/TCP 15mCopy to Clipboard Copied! Toggle word wrap Toggle overflow 有効にされたクラウドプロバイダーがある場合、サービスには外部 IP アドレスが自動的に割り当てられます。
マスターで cURL などのツールを使用し、パブリック IP アドレスを使用してサービスに到達できることを確認します。
curl <public-ip>:<port>
$ curl <public-ip>:<port>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下に例を示します。
curl 172.29.121.74:3306
$ curl 172.29.121.74:3306Copy to Clipboard Copied! Toggle word wrap Toggle overflow このセクションの例では、クライアントアプリケーションを必要とする MySQL サービスを使用しています。
Got packets out of orderのメッセージと共に文字ストリングを取得する場合は、このサービスに接続していることになります。MySQL クライアントがある場合は、標準 CLI コマンドでログインします。
mysql -h 172.30.131.89 -u admin -p
$ mysql -h 172.30.131.89 -u admin -pCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Enter password: Welcome to the MariaDB monitor. Commands end with ; or \g. MySQL [(none)]>
Enter password: Welcome to the MariaDB monitor. Commands end with ; or \g. MySQL [(none)]>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
12.5. サービスの外部 IP を使用した ingress クラスタートラフィックの設定 リンクのコピーリンクがクリップボードにコピーされました!
外部 IP アドレスをサービスに割り当てることで、これをクラスター外のトラフィックで使用できるようにします。通常、これはベアメタルハードウェアにインストールされているクラスターの場合にのみ役立ちます。外部ネットワークインフラストラクチャーは、トラフィックをサービスにルーティングするように正しく設定される必要があります。
12.5.1. 前提条件 リンクのコピーリンクがクリップボードにコピーされました!
- クラスターは ExternalIP が有効にされた状態で設定されます。詳細は、サービスの ExternalIP の設定 について参照してください。
12.5.2. ExternalIP のサービスへの割り当て リンクのコピーリンクがクリップボードにコピーされました!
ExternalIP をサービスに割り当てることができます。クラスターが ExternalIP を自動的に割り当てするように設定されている場合、ExternalIP をサービスに手動で割り当てる必要がない場合があります。
手順
オプション: ExternalIP で使用するために設定される IP アドレス範囲を確認するには、以下のコマンドを入力します。
oc get networks.config cluster -o jsonpath='{.spec.externalIP}{"\n"}'$ oc get networks.config cluster -o jsonpath='{.spec.externalIP}{"\n"}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow autoAssignCIDRsが設定されている場合、spec.externalIPsフィールドが指定されていない場合、 OpenShift Container Platform は ExternalIP を新規Serviceオブジェクトに自動的に割り当てます。ExternalIP をサービスに割り当てます。
新規サービスを作成する場合は、
spec.externalIPsフィールドを指定し、1 つ以上の有効な IP アドレスの配列を指定します。以下に例を示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow ExternalIP を既存のサービスに割り当てる場合は、以下のコマンドを入力します。
<name>をサービス名に置き換えます。<ip_address>を有効な ExternalIP アドレスに置き換えます。コンマで区切られた複数の IP アドレスを指定できます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下に例を示します。
oc patch svc mysql-55-rhel7 -p '{"spec":{"externalIPs":["192.174.120.10"]}}'$ oc patch svc mysql-55-rhel7 -p '{"spec":{"externalIPs":["192.174.120.10"]}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
"mysql-55-rhel7" patched
"mysql-55-rhel7" patchedCopy to Clipboard Copied! Toggle word wrap Toggle overflow
ExternalIP アドレスがサービスに割り当てられていることを確認するには、以下のコマンドを入力します。新規サービスに ExternalIP を指定した場合、まずサービスを作成する必要があります。
oc get svc
$ oc get svcCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE mysql-55-rhel7 172.30.131.89 192.174.120.10 3306/TCP 13m
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE mysql-55-rhel7 172.30.131.89 192.174.120.10 3306/TCP 13mCopy to Clipboard Copied! Toggle word wrap Toggle overflow
12.5.3. 関連情報 リンクのコピーリンクがクリップボードにコピーされました!
12.6. NodePort を使用した ingress クラスタートラフィックの設定 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform は、クラスター内で実行されるサービスを使ってクラスター外からの通信を可能にする方法を提供します。この方法は NodePort を使用します。
12.6.1. NodePort を使用したトラフィックのクラスターへの送信 リンクのコピーリンクがクリップボードにコピーされました!
NodePort-type Service リソースを使用して、クラスター内のすべてのノードの特定のポートでサービスを公開します。ポートは Service リソースの .spec.ports[*].nodePort フィールドで指定されます。
ノードポートを使用するには、追加のポートリソースが必要です。
NodePort は、ノードの IP アドレスの静的ポートでサービスを公開します。NodePort はデフォルトで 30000 から 32767 の範囲に置かれます。つまり、 NodePort はサービスの意図されるポートに一致しないことが予想されます。たとえば、ポート 8080 はノードのポート 31020 として公開できます。
管理者は、外部 IP アドレスがノードにルーティングされることを確認する必要があります。
NodePort および外部 IP は独立しており、両方を同時に使用できます。
このセクションの手順では、クラスターの管理者が事前に行っておく必要のある前提条件があります。
12.6.2. 前提条件 リンクのコピーリンクがクリップボードにコピーされました!
以下の手順を開始する前に、管理者は以下の条件を満たしていることを確認する必要があります。
- 要求がクラスターに到達できるように、クラスターネットワーク環境に対して外部ポートをセットアップします。
クラスター管理者ロールを持つユーザーが 1 名以上いることを確認します。このロールをユーザーに追加するには、以下のコマンドを実行します。
oc adm policy add-cluster-role-to-user cluster-admin <user_name>
$ oc adm policy add-cluster-role-to-user cluster-admin <user_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow - OpenShift Container Platform クラスターを、1 つ以上のマスターと 1 つ以上のノード、およびクラスターへのネットワークアクセスのあるクラスター外のシステムと共に用意します。この手順では、外部システムがクラスターと同じサブセットにあることを前提とします。別のサブセットの外部システムに必要な追加のネットワーク設定については、このトピックでは扱いません。
12.6.3. プロジェクトおよびサービスの作成 リンクのコピーリンクがクリップボードにコピーされました!
公開するプロジェクトおよびサービスが存在しない場合、最初にプロジェクトを作成し、次にサービスを作成します。
プロジェクトおよびサービスがすでに存在する場合は、サービスを公開してルートを作成する手順に進みます。
前提条件
-
クラスター管理者として
ocCLI をインストールし、ログインします。
手順
サービスの新規プロジェクトを作成します。
oc new-project <project_name>
$ oc new-project <project_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下は例になります。
oc new-project myproject
$ oc new-project myprojectCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc new-appコマンドを使用してサービスを作成します。以下は例になります。oc new-app \ -e MYSQL_USER=admin \ -e MYSQL_PASSWORD=redhat \ -e MYSQL_DATABASE=mysqldb \ registry.redhat.io/rhscl/mysql-80-rhel7$ oc new-app \ -e MYSQL_USER=admin \ -e MYSQL_PASSWORD=redhat \ -e MYSQL_DATABASE=mysqldb \ registry.redhat.io/rhscl/mysql-80-rhel7Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行して新規サービスが作成されていることを確認します。
oc get svc -n myproject
$ oc get svc -n myprojectCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE mysql-80-rhel7 ClusterIP 172.30.63.31 <none> 3306/TCP 4m55s
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE mysql-80-rhel7 ClusterIP 172.30.63.31 <none> 3306/TCP 4m55sCopy to Clipboard Copied! Toggle word wrap Toggle overflow デフォルトで、新規サービスには外部 IP アドレスがありません。
12.6.4. ルートの作成によるサービスの公開 リンクのコピーリンクがクリップボードにコピーされました!
oc expose コマンドを使用して、サービスをルートとして公開することができます。
手順
サービスを公開するには、以下を実行します。
- OpenShift Container Platform にログインします。
公開するサービスが置かれているプロジェクトにログインします。
oc project project1
$ oc project project1Copy to Clipboard Copied! Toggle word wrap Toggle overflow アプリケーションのノードポートを公開するには、以下のコマンドを入力します。OpenShift Container Platform は
30000-32767範囲の利用可能なポートを自動的に選択します。oc expose dc mysql-80-rhel7 --type=NodePort --name=mysql-ingress
$ oc expose dc mysql-80-rhel7 --type=NodePort --name=mysql-ingressCopy to Clipboard Copied! Toggle word wrap Toggle overflow オプション: サービスが公開されるノードポートで利用可能なことを確認するには、以下のコマンドを入力します。
oc get svc -n myproject
$ oc get svc -n myprojectCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE mysql-80-rhel7 ClusterIP 172.30.217.127 <none> 3306/TCP 9m44s mysql-ingress NodePort 172.30.107.72 <none> 3306:31345/TCP 39s
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE mysql-80-rhel7 ClusterIP 172.30.217.127 <none> 3306/TCP 9m44s mysql-ingress NodePort 172.30.107.72 <none> 3306:31345/TCP 39sCopy to Clipboard Copied! Toggle word wrap Toggle overflow オプション:
oc new-appコマンドによって自動的に作成されたサービスを削除するには、以下のコマンドを入力します。oc delete svc mysql-80-rhel7
$ oc delete svc mysql-80-rhel7Copy to Clipboard Copied! Toggle word wrap Toggle overflow
第13章 クラスター全体のプロキシーの設定 リンクのコピーリンクがクリップボードにコピーされました!
実稼働環境では、インターネットへの直接アクセスを拒否し、代わりに HTTP または HTTPS プロキシーを使用することができます。既存クラスターのプロキシーオブジェクトを変更 するか、または新規クラスターの install-config.yaml ファイルでプロキシー設定を行うことにより、OpenShift Container Platform をプロキシーを使用するように設定できます。
クラスター全体のプロキシーは、ユーザーによってプロビジョニングされるインフラストラクチャーのインストールを使用している場合や、サポートされるプロバイダーに、仮想プライベートクラウドや仮想ネットワークなどの独自のネットワークを提供する場合にのみサポートされます。
13.1. 前提条件 リンクのコピーリンクがクリップボードにコピーされました!
クラスターがアクセスする必要のあるサイト を確認し、プロキシーをバイパスする必要があるかどうかを判断します。デフォルトで、すべてのクラスター egress トラフィック (クラスターをホストするクラウドのクラウドプロバイダー API に対する呼び出しを含む) はプロキシーされます。プロキシーオブジェクトの
spec.noProxyフィールドにサイトを追加し、必要に応じてプロキシーをバイパスします。注記Proxy オブジェクトの
status.noProxyフィールドには、インストール設定のnetworking.machineNetwork[].cidr、networking.clusterNetwork[].cidr、およびnetworking.serviceNetwork[]フィールドの値が設定されます。Amazon Web Services (AWS)、Google Cloud Platform (GCP)、Microsoft Azure、および {rh-openstack-first} へのインストールの場合、
Proxyオブジェクトのstatus.noProxyフィールドは、インスタンスメタデータのエンドポイント (169.254.169.254) で設定されます。
13.2. クラスター全体のプロキシーの有効化 リンクのコピーリンクがクリップボードにコピーされました!
プロキシーオブジェクトは、クラスター全体の egress プロキシーを管理するために使用されます。プロキシーを設定せずにクラスターがインストールまたはアップグレードされると、プロキシーオブジェクトは引き続き生成されますが、spec は設定されません。以下に例を示します。
クラスター管理者は、この cluster プロキシーオブジェクトを変更して OpenShift Container Platform のプロキシーを設定できます。
cluster という名前のプロキシーオブジェクトのみがサポートされ、追加のプロキシーは作成できません。
前提条件
- クラスター管理者のパーミッション。
-
OpenShift Container Platform
ocCLI ツールがインストールされている。
手順
HTTPS 接続のプロキシーに必要な追加の CA 証明書が含まれる ConfigMap を作成します。
注記プロキシーのアイデンティティー証明書が RHCOS 信頼バンドルからの認証局によって署名される場合は、これを省略できます。
以下の内容で
user-ca-bundle.yamlというファイルを作成して、PEM でエンコードされた証明書の値を指定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow このファイルから ConfigMap を作成します。
oc create -f user-ca-bundle.yaml
$ oc create -f user-ca-bundle.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
oc editコマンドを使用してプロキシーオブジェクトを変更します。oc edit proxy/cluster
$ oc edit proxy/clusterCopy to Clipboard Copied! Toggle word wrap Toggle overflow プロキシーに必要なフィールドを設定します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- クラスター外の HTTP 接続を作成するために使用するプロキシー URL。URL スキームは
httpである必要があります。 - 2
- クラスター外で HTTPS 接続を作成するために使用するプロキシー URL。これが指定されていない場合、HTTP および HTTPS 接続の両方に
httpProxyが使用されます。 - 3
- プロキシーを除外するための宛先ドメイン名、ドメイン、IP アドレス、または他のネットワーク CIDR のコンマ区切りの一覧。ドメインのすべてのサブドメインを組み込むために、ドメインの前に
.を入力します。*を使用し、すべての宛先のプロキシーをバイパスします。networking.machineNetwork[].cidrに含まれていないワーカーをスケールアップする場合、 それらをこの一覧に追加し、接続の問題を防ぐ必要があることに注意してください。 - 4
httpProxyおよびhttpsProxyの値をステータスに書き込む前の readiness チェックに使用するクラスター外の 1 つ以上の URL。- 5
- HTTPS 接続のプロキシーに必要な追加の CA 証明書が含まれる、
openshift-confignamespace の ConfigMap の参照。ここで参照する前に ConfigMap が存在している必要があります。このフィールドは、プロキシーのアイデンティティー証明書が RHCOS 信頼バンドルからの認証局によって署名されない限り必要になります。
- 変更を適用するためにファイルを保存します。
13.3. クラスター全体のプロキシーの削除 リンクのコピーリンクがクリップボードにコピーされました!
cluster プロキシーオブジェクトは削除できません。クラスターからプロキシーを削除するには、プロキシーオブジェクトからすべての spec フィールドを削除します。
前提条件
- クラスター管理者のパーミッション。
-
OpenShift Container Platform
ocCLI ツールがインストールされている。
手順
oc editコマンドを使用してプロキシーを変更します。oc edit proxy/cluster
$ oc edit proxy/clusterCopy to Clipboard Copied! Toggle word wrap Toggle overflow プロキシーオブジェクトからすべての
specフィールドを削除します。以下に例を示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 変更を適用するためにファイルを保存します。
第14章 カスタム PKI の設定 リンクのコピーリンクがクリップボードにコピーされました!
Web コンソールなどの一部のプラットフォームコンポーネントは、通信にルートを使用し、それらと対話するために他のコンポーネントの証明書を信頼する必要があります。カスタムのパブリックキーインフラストラクチャー (PKI) を使用している場合は、プライベートに署名された CA 証明書がクラスター全体で認識されるようにこれを設定する必要があります。
プロキシー API を使用して、クラスター全体で信頼される CA 証明書を追加できます。インストール時またはランタイム時にこれを実行する必要があります。
インストール 時に、クラスター全体のプロキシーを設定します。プライベートに署名された CA 証明書は、
install-config.yamlファイルのadditionalTrustBundle設定で定義する必要があります。インストールプログラムは、定義した追加の CA 証明書が含まれる
user-ca-bundleという名前の ConfigMap を生成します。次に Cluster Network Operator は、これらの CA 証明書を {op-system-first} 信頼バンドルにマージするtrusted-ca-bundleConfigMap を作成します。この ConfigMap はプロキシーオブジェクトのtrustedCAフィールドで参照されます。-
ランタイム 時に、デフォルトのプロキシーオブジェクトを変更して、プライベートに署名された CA 証明書を追加 します (これは、クラスターのプロキシー有効化のワークフローの一部です)。これには、クラスターで信頼される必要があるプライベートに署名された CA 証明書が含まれる ConfigMap を作成し、次にプライベートに署名された証明書の ConfigMap を参照する
trustedCAでプロキシーリソースを変更することが関係します。
インストーラー設定の additionalTrustBundle フィールドおよびプロキシーリソースの trustedCA フィールドは、クラスター全体の信頼バンドルを管理するために使用されます。 additionalTrustBundle はインストール時に使用され、プロキシーの trustedCA がランタイム時に使用されます。
trustedCA フィールドは、クラスターコンポーネントによって使用されるカスタム証明書とキーのペアを含む ConfigMap の参照です。
14.1. インストール時のクラスター全体のプロキシーの設定 リンクのコピーリンクがクリップボードにコピーされました!
実稼働環境では、インターネットへの直接アクセスを拒否し、代わりに HTTP または HTTPS プロキシーを使用することができます。プロキシー設定を install-config.yaml ファイルで行うことにより、新規の OpenShift Container Platform クラスターをプロキシーを使用するように設定できます。
前提条件
-
既存の
install-config.yamlファイルが必要です。 クラスターがアクセスする必要のあるサイトを確認し、プロキシーをバイパスする必要があるかどうかを判別します。デフォルトで、すべてのクラスター egress トラフィック (クラスターをホストするクラウドについてのクラウドプロバイダー API に対する呼び出しを含む) はプロキシーされます。
Proxyオブジェクトのspec.noProxyフィールドにサイトを追加し、必要に応じてプロキシーをバイパスします。注記Proxyオブジェクトのstatus.noProxyフィールドには、インストール設定のnetworking.machineNetwork[].cidr、networking.clusterNetwork[].cidr、およびnetworking.serviceNetwork[]フィールドの値が設定されます。Amazon Web Services (AWS)、Google Cloud Platform (GCP)、Microsoft Azure、および {rh-openstack-first} へのインストールの場合、
Proxyオブジェクトのstatus.noProxyフィールドは、インスタンスメタデータのエンドポイント (169.254.169.254) で設定されます。
手順
install-config.yamlファイルを編集し、プロキシー設定を追加します。以下に例を示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- クラスター外の HTTP 接続を作成するために使用するプロキシー URL。URL スキームは
httpである必要があります。追加のプロキシー設定が必要ではなく、追加の CA を必要とする MITM の透過的なプロキシーネットワークを使用する場合には、httpProxy値を指定することはできません。 - 2
- クラスター外で HTTPS 接続を作成するために使用するプロキシー URL。このフィールドが指定されていない場合、HTTP および HTTPS 接続の両方に
httpProxyが使用されます。追加のプロキシー設定が必要ではなく、追加の CA を必要とする MITM の透過的なプロキシーネットワークを使用する場合には、httpsProxy値を指定することはできません。 - 3
- プロキシーを除外するための宛先ドメイン名、ドメイン、IP アドレス、または他のネットワーク CIDR のコンマ区切りの一覧。ドメインのすべてのサブドメインを組み込むために、ドメインの前に
.を入力します。*を使用し、すべての宛先のプロキシーをバイパスします。 - 4
- 指定されている場合、インストールプログラムは HTTPS 接続のプロキシーに必要な 1 つ以上の追加の CA 証明書が含まれる
user-ca-bundleという名前の設定マップをopenshift-confignamespace に生成します。次に Cluster Network Operator は、これらのコンテンツを {op-system-first} 信頼バンドルにマージするtrusted-ca-bundle設定マップを作成し、この設定マップはProxyオブジェクトのtrustedCAフィールドで参照されます。additionalTrustBundleフィールドは、プロキシーのアイデンティティー証明書が {op-system} 信頼バンドルからの認証局によって署名されない限り必要になります。追加のプロキシー設定が必要ではなく、追加の CA を必要とする MITM の透過的なプロキシーネットワークを使用する場合には、MITM CA 証明書を指定する必要があります。
注記インストールプログラムは、プロキシーの
readinessEndpointsフィールドをサポートしません。- ファイルを保存し、OpenShift Container Platform のインストール時にこれを参照します。
インストールプログラムは、指定の install-config.yaml ファイルのプロキシー設定を使用する cluster という名前のクラスター全体のプロキシーを作成します。プロキシー設定が指定されていない場合、cluster Proxy オブジェクトが依然として作成されますが、これには spec がありません。
cluster という名前の Proxy オブジェクトのみがサポートされ、追加のプロキシーを作成することはできません。
14.2. クラスター全体のプロキシーの有効化 リンクのコピーリンクがクリップボードにコピーされました!
プロキシーオブジェクトは、クラスター全体の egress プロキシーを管理するために使用されます。プロキシーを設定せずにクラスターがインストールまたはアップグレードされると、プロキシーオブジェクトは引き続き生成されますが、spec は設定されません。以下に例を示します。
クラスター管理者は、この cluster プロキシーオブジェクトを変更して OpenShift Container Platform のプロキシーを設定できます。
cluster という名前のプロキシーオブジェクトのみがサポートされ、追加のプロキシーは作成できません。
前提条件
- クラスター管理者のパーミッション。
-
OpenShift Container Platform
ocCLI ツールがインストールされている。
手順
HTTPS 接続のプロキシーに必要な追加の CA 証明書が含まれる ConfigMap を作成します。
注記プロキシーのアイデンティティー証明書が RHCOS 信頼バンドルからの認証局によって署名される場合は、これを省略できます。
以下の内容で
user-ca-bundle.yamlというファイルを作成して、PEM でエンコードされた証明書の値を指定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow このファイルから ConfigMap を作成します。
oc create -f user-ca-bundle.yaml
$ oc create -f user-ca-bundle.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
oc editコマンドを使用してプロキシーオブジェクトを変更します。oc edit proxy/cluster
$ oc edit proxy/clusterCopy to Clipboard Copied! Toggle word wrap Toggle overflow プロキシーに必要なフィールドを設定します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- クラスター外の HTTP 接続を作成するために使用するプロキシー URL。URL スキームは
httpである必要があります。 - 2
- クラスター外で HTTPS 接続を作成するために使用するプロキシー URL。これが指定されていない場合、HTTP および HTTPS 接続の両方に
httpProxyが使用されます。 - 3
- プロキシーを除外するための宛先ドメイン名、ドメイン、IP アドレス、または他のネットワーク CIDR のコンマ区切りの一覧。ドメインのすべてのサブドメインを組み込むために、ドメインの前に
.を入力します。*を使用し、すべての宛先のプロキシーをバイパスします。networking.machineNetwork[].cidrに含まれていないワーカーをスケールアップする場合、 それらをこの一覧に追加し、接続の問題を防ぐ必要があることに注意してください。 - 4
httpProxyおよびhttpsProxyの値をステータスに書き込む前の readiness チェックに使用するクラスター外の 1 つ以上の URL。- 5
- HTTPS 接続のプロキシーに必要な追加の CA 証明書が含まれる、
openshift-confignamespace の ConfigMap の参照。ここで参照する前に ConfigMap が存在している必要があります。このフィールドは、プロキシーのアイデンティティー証明書が RHCOS 信頼バンドルからの認証局によって署名されない限り必要になります。
- 変更を適用するためにファイルを保存します。
14.3. Operator を使用した証明書の挿入 リンクのコピーリンクがクリップボードにコピーされました!
カスタム CA 証明書が ConfigMap 経由でクラスターに追加されると、Cluster Network Operator はユーザーによってプロビジョニングされる CA 証明書およびシステム CA 証明書を単一バンドルにマージし、信頼バンドルの挿入を要求する Operator にマージされたバンドルを挿入します。
Operator は、以下のラベルの付いた空の ConfigMap を作成してこの挿入を要求します。
config.openshift.io/inject-trusted-cabundle="true"
config.openshift.io/inject-trusted-cabundle="true"
Operator は、この ConfigMap をコンテナーのローカル信頼ストアにマウントします。
信頼された CA 証明書の追加は、証明書が {op-system-first} 信頼バンドルに含まれていない場合にのみ必要になります。
証明書の挿入は Operator に制限されません。Cluster Network Operator は、空の ConfigMap が config.openshift.io/inject-trusted-cabundle=true ラベルを使用して作成される場合に、すべての namespace で証明書を挿入できます。
ConfigMap はすべての namespace に置くことができますが、ConfigMap はカスタム CA を必要とする Pod 内の各コンテナーに対してボリュームとしてマウントされる必要があります。以下は例になります。