Red Hat Summit第23章 Kubernetes NMState
23.1. ノードのネットワーク状態と設定の監視と更新
Kubernetes NMState Operator をインストールしたら、Operator を使用してクラスターのノードのネットワーク状態とネットワーク設定を監視および更新できます。
NMState Operator のインストール方法の詳細は、Kubernetes NMState Operator を参照してください。
br-ex ブリッジ (OVN-Kubernetes によって管理される Open vSwitch ブリッジ) を変更する設定を指定することはできません。ただし、カスタマイズした br-ex ブリッジを設定することはできます。
詳細は、インストーラーでプロビジョニングされるクラスターのベアメタルへのデプロイ、または ユーザーがプロビジョニングしたクラスターをベアメタルにインストール ドキュメントの「カスタマイズされた br-ex ブリッジを含むマニフェストオブジェクトの作成」を参照してください。
23.1.1. CLI を使用したノードのネットワーク状態の表示
ノードのネットワーク状態は、クラスター内のすべてのノードのネットワーク設定です。NodeNetworkState オブジェクトはクラスター内のすべてのノードにあります。このオブジェクトは定期的に更新され、ノードのネットワークの状態を取得します。
手順
クラスターのすべての
NodeNetworkStateオブジェクトをリスト表示します。$ oc get nnsNodeNetworkStateオブジェクトを検査して、そのノードにネットワークを表示します。この例の出力は、明確にするために編集されています。$ oc get nns node01 -o yaml出力例
apiVersion: nmstate.io/v1 kind: NodeNetworkState metadata: name: node011 status: currentState:2 dns-resolver: # ... interfaces: # ... route-rules: # ... routes: # ... lastSuccessfulUpdateTime: "2020-01-31T12:14:00Z"3
23.1.2. Web コンソールからのノードのネットワーク状態の表示
管理者は、OpenShift Container Platform Web コンソールを使用して、NodeNetworkState リソースとネットワークインターフェイスを観察し、ネットワークの詳細にアクセスできます。
手順
Networking
NodeNetworkState に移動します。 NodeNetworkState ページでは、
NodeNetworkStateリソースと、ノード上に作成された対応するインターフェイスのリストを表示できます。Interface state、Interface type、および IP に基づく フィルター、または Name または Label の条件に基づく検索バーを使用して、表示されるNodeNetworkStateリソースを絞り込むことができます。-
NodeNetworkStateリソースに関する詳細情報にアクセスするには、Name 列にリストされているNodeNetworkStateリソース名をクリックします。 -
NodeNetworkStateリソースの Network Details セクションをデプロイメントして表示するには、> アイコンをクリックします。あるいは、Network interface 列の下の各インターフェイスタイプをクリックして、ネットワークの詳細を表示することもできます。
23.1.3. NodeNetworkConfigurationPolicy マニフェストを作成します。
NodeNetworkConfigurationPolicy (NNCP) マニフェストファイルは、Kubernetes NMState Operator が OpenShift Container Platform クラスター内に存在するノードのネットワークを設定するために使用するポリシーを定義します。
ノードのネットワークポリシーをノードに適用すると、Kubernetes NMState Operator によって、ノードのネットワークポリシーの詳細に従ってノードのネットワークが設定されます。
OpenShift CLI (oc) または OpenShift Container Platform Web コンソールを使用して NNCP を作成できます。インストール後のタスクとして、NNCP を作成したり、既存の NNCP を編集したりできます。
NNCP を作成する前に、「各種インターフェイスのポリシー設定例」のドキュメントを一読してください。
NNCP を削除する必要がある場合は、oc delete nncp コマンドを使用して削除アクションを完了できます。ただし、このコマンドではブリッジインターフェイスなどのオブジェクトは削除されません。
ノードにインターフェイスを追加したノードネットワークポリシーを削除しても、そのノード上のポリシー設定は変更されません。同様に、インターフェイスを削除してもポリシーは削除されません。これは、Pod またはノードが再起動されるたびに、Kubernetes NMState Operator が、削除されたインターフェイスを再度追加するためです。
NNCP、ノードネットワークポリシー、およびインターフェイスを実際に削除するには、通常、次の操作が必要です。
-
NNCP を編集し、ファイルからインターフェイスの詳細を削除します。ファイルから
name、state、typeパラメーターは削除しないでください。 -
NNCP の
interfaces.stateセクションにstate: absentを追加します。 -
oc apply -f <nncp_file_name>を実行します。Kubernetes NMState Operator がクラスター内の各ノードにノードネットワークポリシーを適用すると、各ノードに存在するすべてのインターフェイスが absent とマークされます。 -
oc delete nncpを実行して NNCP を削除します。
関連情報
23.1.4. Web コンソールからのポリシーの管理
NodeNetworkConfigurationPolicy マニフェストをクラスターに適用して、ノードからのインターフェイスの追加または削除など、ノードネットワーク設定を更新できます。Web コンソールからポリシーを管理するには、Networking メニューの NodeNetworkConfigurationPolicy ページで作成されたポリシーのリストにアクセスします。このページでは、ポリシーを作成、更新、監視、削除できます。
23.1.4.1. ポリシーステータスの監視
NodeNetworkConfigurationPolicy ページからポリシーのステータスを監視できます。このページには、クラスター内に作成されたすべてのポリシーが次の列を含む表形式で表示されます。
- 名前
- 作成されたポリシーの名前。
- 一致したノード
- ポリシーが適用されるノードの数。これは、ノードセレクターに基づくノードのサブセット、またはクラスター上のすべてのノードのいずれかになります。
- ノードのネットワーク状態
- 一致したノードの実行状態。制定状態をクリックすると、ステータスの詳細情報が表示されます。
目的のポリシーを見つけるには、Filter オプションを使用するか、検索オプションを使用して、制定状態に基づいてリストをフィルターできます。
23.1.4.2. ポリシーの作成
Web コンソールでフォームまたは YAML を使用してポリシーを作成できます。
手順
-
Networking
NodeNetworkConfigurationPolicy に移動します。 NodeNetworkConfigurationPolicy ページで Create をクリックし、From Form オプションを選択します。
既存のポリシーがない場合は、Create NodeNetworkConfigurationPolicy をクリックして、フォームを使用してポリシーを作成することもできます。
注記YAML を使用してポリシーを作成するには、Create をクリックし、With YAML オプションを選択します。次の手順は、フォームを使用してポリシーを作成する場合にのみ適用されます。
- オプション: Apply this NodeNetworkConfigurationPolicy only to specific subsets of nodes using the node selector チェックボックスをオンにして、ポリシーを適用する必要があるノードを指定します。
- Policy name フィールドにポリシー名を入力します。
- オプション: Description フィールドにポリシーの説明を入力します。
オプション: Policy Interface(s) セクションでは、編集可能なフィールドにプリセット値が設定されたブリッジインターフェイスがデフォルトで追加されます。次の手順を実行して値を編集します。
- Interface name フィールドにインターフェイスの名前を入力します。
- Network state ドロップダウンからネットワーク状態を選択します。デフォルトで選択されている値は Up です。
Type ドロップダウンからインターフェイスのタイプを選択します。使用可能な値は、Bridge、Bonding、および Ethernet です。デフォルトで選択されている値は Bridge です。
注記フォームを使用した VLAN インターフェイスの追加はサポートされていません。VLAN インターフェイスを追加するには、YAML を使用してポリシーを作成する必要があります。ポリシーを追加すると、フォームを使用してポリシーを編集できません。
オプション: IP 設定セクションで、IPv4 チェックボックスをオンにしてインターフェイスに IPv4 アドレスを割り当て、IP アドレス割り当ての詳細を設定します。
- IP address をクリックしてインターフェイスを静的 IP アドレスで設定するか、DHCP をクリックして IP アドレスを自動割り当てします。
IP address オプションを選択した場合は、IPV4 address フィールドに IPv4 アドレスを、Prefix length フィールドに接頭辞長を入力します。
DHCP オプションを選択した場合は、無効にするオプションのチェックを外します。使用可能なオプションは、Auto-DNS、Auto-routes、および Auto-gateway です。すべてのオプションがデフォルトで選択されています。
- オプション: Port フィールドにポート番号を入力します。
- オプション: STP を有効にするには、Enable STP チェックボックスをオンにします。
- オプション: ポリシーにインターフェイスを追加するには、Add another interface to the policy をクリックします。
- オプション: ポリシーからインターフェイスを削除するには、インターフェイスの横にあるアイコン をクリックします。
注記または、ページ上部の Edit YAML をクリックして、YAML を使用してフォームの編集を続けることもできます。
- Create をクリックしてポリシーの作成を完了します。
23.1.5. ポリシーの更新
23.1.5.1. フォームを使用してポリシーを更新する
手順
-
Networking
NodeNetworkConfigurationPolicy に移動します。 -
NodeNetworkConfigurationPolicy ページで、編集するポリシーの横にあるアイコン
を選択し、Edit をクリックします。
- 更新するフィールドを編集します。
- Save をクリックします。
フォームを使用した VLAN インターフェイスの追加はサポートされていません。VLAN インターフェイスを追加するには、YAML を使用してポリシーを作成する必要があります。ポリシーを追加すると、フォームを使用してポリシーを編集することはできません。
23.1.5.2. YAML を使用したポリシーの更新
手順
-
Networking
NodeNetworkConfigurationPolicy に移動します。 - NodeNetworkConfigurationPolicy ページで、編集するポリシーの Name 列の下にあるポリシー名をクリックします。
- YAML タブをクリックし、YAML を編集します。
- Save をクリックします。
23.1.5.3. ポリシーの削除
手順
-
Networking
NodeNetworkConfigurationPolicy に移動します。 -
NodeNetworkConfigurationPolicy ページで、削除するポリシーの横にあるアイコン
を選択し、Delete をクリックします。
- ポップアップウィンドウで、削除を確認するポリシー名を入力し、Delete をクリックします。
23.1.6. CLI を使用したポリシーの管理
23.1.6.1. ノード上でのインターフェイスの作成
NodeNetworkConfigurationPolicy (NNCP) マニフェストをクラスターに適用して、クラスター内のノードにインターフェイスを作成します。マニフェストには、インターフェイスの要求された設定の詳細が含まれます。
デフォルトでは、マニフェストはクラスター内のすべてのノードに適用されます。インターフェイスを特定ノードに追加するには、ノードセレクターの spec: nodeSelector パラメーターおよび適切な <key>:<value> を追加します。
複数の nmstate 対応ノードを同時に設定できます。この設定は、並列のノードの 50% に適用されます。このストラテジーでは、ネットワーク接続に障害が発生した場合にクラスター全体が使用できなくなるのを回避します。クラスターの特定の部分にポリシー設定を並行して適用するには、NodeNetworkConfigurationPolicy マニフェスト設定ファイルで maxUnavailable パラメーターを使用します。
ノードが 2 つある場合に、maxUnavailable パラメーターを 50% に設定した NNCP マニフェストをこれらのノードに適用すると、1 つのノードに NNCP 設定が反映されます。その後、maxUnavailable パラメーターを 50% に設定した追加の NNCP マニフェストファイルを導入すると、この NCCP は最初の NNCP とは別に適用されます。つまり、2 つの NNCP マニフェストによってノードに不適切な設定が適用されると、クラスターの半分を確実に機能させることができなくなります。
手順
NodeNetworkConfigurationPolicyマニフェストを作成します。以下の例は、すべてのワーカーノードで Linux ブリッジを設定し、DNS リゾルバーを設定します。apiVersion: nmstate.io/v1 kind: NodeNetworkConfigurationPolicy metadata: name: br1-eth1-policy1 spec: nodeSelector:2 node-role.kubernetes.io/worker: ""3 maxUnavailable: 34 desiredState: interfaces: - name: br1 description: Linux bridge with eth1 as a port5 type: linux-bridge state: up ipv4: dhcp: true enabled: true auto-dns: false bridge: options: stp: enabled: false port: - name: eth1 dns-resolver:6 config: search: - example.com - example.org server: - 8.8.8.8- 1
- ポリシーの名前。
- 2
- オプション:
nodeSelectorパラメーターを含めない場合、ポリシーはクラスター内のすべてのノードに適用されます。 - 3
- この例では
node-role.kubernetes.io/worker: ""ノードセレクターを使用し、クラスター内のすべてのワーカーノードを選択します。 - 4
- オプション: ポリシー設定を同時に適用できる nmstate 対応ノードの最大数を指定します。このパラメーターは、
"10%"などのパーセンテージ値 (文字列)、または3などの絶対値 (数値) のいずれかに設定できます。 - 5
- オプション: インターフェイスの人間が判読できる説明。
- 6
- オプション:DNS サーバーの検索およびサーバー設定を指定します。
ノードのネットワークポリシーを作成します。
$ oc apply -f br1-eth1-policy.yaml1 - 1
- ノードネットワーク設定ポリシーマニフェストのファイル名。
関連情報
23.1.6.2. ノード上でのノードネットワークポリシー更新の確認
ノードネットワークポリシーを適用する際に、NodeNetworkConfigurationEnactment オブジェクトがクラスター内のすべてのノードについて作成されます。ノードネットワーク設定の enactment (実行) は、そのノードでのポリシーの実行ステータスを表す読み取り専用オブジェクトです。ポリシーがノードに適用されない場合、そのノードの enactment (実行) にはトラブルシューティングのためのトレースバックが含まれます。
手順
ポリシーがクラスターに適用されていることを確認するには、ポリシーとそのステータスをリスト表示します。
$ oc get nncpオプション: ポリシーの設定に想定されている以上の時間がかかる場合は、特定のポリシーの要求される状態とステータスの状態を検査できます。
$ oc get nncp <policy> -o yamlオプション: ポリシーのすべてのノード上での設定に想定されている以上の時間がかかる場合は、クラスターの enactment (実行) のステータスをリスト表示できます。
$ oc get nnceオプション: 特定の enactment (実行) の設定 (失敗した設定のエラーレポートを含む) を表示するには、以下を実行します。
$ oc get nnce <node>.<policy> -o yaml
23.1.6.3. ノードからインターフェイスの削除
NodeNetworkConfigurationPolicy オブジェクトを編集し、インターフェイスの state を absent に設定して、クラスターの 1 つ以上のノードからインターフェイスを削除できます。
ノードからインターフェイスを削除しても、ノードのネットワーク設定は以前の状態に自動的に復元されません。以前の状態に復元する場合、そのノードのネットワーク設定をポリシーで定義する必要があります。
ブリッジまたはボンディングインターフェイスを削除すると、そのブリッジまたはボンディングインターフェイスに以前に接続されたか、それらの下位にあるノード NIC は down の状態になり、到達できなくなります。接続が失われないようにするには、同じポリシーでノード NIC を設定し、ステータスを up にし、DHCP または静的 IP アドレスのいずれかになるようにします。
インターフェイスを追加したポリシーを削除しても、ノード上のポリシーの設定は変更されません。NodeNetworkConfigurationPolicy はクラスターのオブジェクトですが、このオブジェクトは要求される設定のみを表します。同様に、インターフェイスを削除してもポリシーは削除されません。
手順
インターフェイスの作成に使用する
NodeNetworkConfigurationPolicyマニフェストを更新します。以下の例は Linux ブリッジを削除し、接続が失われないように DHCP でeth1NIC を設定します。apiVersion: nmstate.io/v1 kind: NodeNetworkConfigurationPolicy metadata: name: <br1-eth1-policy>1 spec: nodeSelector:2 node-role.kubernetes.io/worker: ""3 desiredState: interfaces: - name: br1 type: linux-bridge state: absent4 - name: eth15 type: ethernet6 state: up7 ipv4: dhcp: true8 enabled: true9 - 1
- ポリシーの名前。
- 2
- オプション:
nodeSelectorパラメーターを含めない場合、ポリシーはクラスター内のすべてのノードに適用されます。 - 3
- この例では
node-role.kubernetes.io/worker: ""ノードセレクターを使用し、クラスター内のすべてのワーカーノードを選択します。 - 4
- 状態を
absentに変更すると、インターフェイスが削除されます。 - 5
- ブリッジインターフェイスから接続が解除されるインターフェイスの名前。
- 6
- インターフェイスのタイプ。この例では、イーサネットネットワークインターフェイスを作成します。
- 7
- インターフェイスの要求された状態。
- 8
- オプション:
dhcpを使用しない場合は、静的 IP を設定するか、IP アドレスなしでインターフェイスを出ることができます。 - 9
- この例では
ipv4を有効にします。
ノード上でポリシーを更新し、インターフェイスを削除します。
$ oc apply -f <br1-eth1-policy.yaml>1 - 1
- ポリシーマニフェストのファイル名。
23.1.7. 異なるインターフェイスのポリシー設定の例
ポリシーをノードに適用する場合は、さまざまな NodeNetworkConfigurationPolicy (NNCP) マニフェスト設定例を読む前に、クラスターが最適なパフォーマンス状態で実行されるように次の要素を考慮してください。
-
ポリシーを複数のノードに適用する必要がある場合は、ターゲットノードごとに
NodeNetworkConfigurationPolicyマニフェストを作成します。Kubernetes NMState Operator は、定義済みの NNCP を持つ各ノードにポリシーを不特定の順序で適用します。この方法でポリシーのスコープを設定すると、ポリシーの適用にかかる時間が短縮されますが、クラスターの設定にエラーがある場合はクラスター全体が停止するリスクがあります。この種のエラーを回避するには、最初に一部のノードに NNCP を適用し、これらのノードに対して NNCP が正しく設定されていることを確認してから、残りのノードにポリシーを適用します。 -
多数のノードにポリシーを適用する必要があるが、すべてのノードに対して 1 つの NNCP のみを作成する場合、Kubernetes NMState Operator は各ノードにポリシーを順番に適用します。クラスターの設定ファイルの
maxUnavailableパラメーターを使用して、ターゲットノードに対するポリシー適用の速度と範囲を設定できます。パラメーターのパーセンテージ値を低く設定すると、ポリシー適用を受信しているノードのごく一部に障害が影響する場合に、クラスター全体の障害が発生するリスクを軽減できます。 -
2 つの NNCP マニフェストで
maxUnavailableパラメーターを50%に設定すると、ポリシー設定がクラスター内のノードの 100% に適用されます。 - ノードが再起動すると、Kubernetes NMState Operator はノードにポリシーを適用する順序を制御できなくなります。Kubernetes NMState Operator は、相互依存するポリシーを順番に適用する場合があります。その結果、ネットワークオブジェクトがデグレード状態になることがあります。
- 関連するすべてのネットワーク設定を 1 つのポリシーで指定することを検討してください。
23.1.7.1. 例: イーサネットインターフェイスノードネットワークの設定ポリシー
NodeNetworkConfigurationPolicy マニフェストをクラスターに適用してクラスター内のノードにイーサネットインターフェイスを作成します。
以下の YAML ファイルは、イーサネットインターフェイスのマニフェストの例です。これには、独自の情報で置き換える必要のあるサンプルの値が含まれます。
apiVersion: nmstate.io/v1
kind: NodeNetworkConfigurationPolicy
metadata:
name: eth1-policy
spec:
nodeSelector:
kubernetes.io/hostname: <node01>
desiredState:
interfaces:
- name: eth1
description: Configuring eth1 on node01
type: ethernet
state: up
ipv4:
dhcp: true
enabled: true - 1
- ポリシーの名前。
- 2
- オプション:
nodeSelectorパラメーターを含めない場合、ポリシーはクラスター内のすべてのノードに適用されます。 - 3
- この例では、
hostnameノードセレクターを使用します。 - 4
- インターフェイスの名前。
- 5
- オプション: 人間が判読できるインターフェイスの説明。
- 6
- インターフェイスのタイプ。この例では、イーサネットネットワークインターフェイスを作成します。
- 7
- 作成後のインターフェイスの要求された状態。
- 8
- オプション:
dhcpを使用しない場合は、静的 IP を設定するか、IP アドレスなしでインターフェイスを出ることができます。 - 9
- この例では
ipv4を有効にします。
23.1.7.2. 例: Linux ブリッジインターフェイスノードネットワーク設定ポリシー
NodeNetworkConfigurationPolicy マニフェストをクラスターに適用してクラスター内のノード上に Linux ブリッジインターフェイスを作成します。
以下の YAML ファイルは、Linux ブリッジインターフェイスのマニフェストの例です。これには、独自の情報で置き換える必要のあるサンプルの値が含まれます。
apiVersion: nmstate.io/v1
kind: NodeNetworkConfigurationPolicy
metadata:
name: br1-eth1-policy
spec:
nodeSelector:
kubernetes.io/hostname: <node01>
desiredState:
interfaces:
- name: br1
description: Linux bridge with eth1 as a port
type: linux-bridge
state: up
ipv4:
dhcp: true
enabled: true
bridge:
options:
stp:
enabled: false
port:
- name: eth1 - 1
- ポリシーの名前。
- 2
- オプション:
nodeSelectorパラメーターを含めない場合、ポリシーはクラスター内のすべてのノードに適用されます。 - 3
- この例では、
hostnameノードセレクターを使用します。 - 4
- インターフェイスの名前。
- 5
- オプション: 人間が判読できるインターフェイスの説明。
- 6
- インターフェイスのタイプ。この例では、ブリッジを作成します。
- 7
- 作成後のインターフェイスの要求された状態。
- 8
- オプション:
dhcpを使用しない場合は、静的 IP を設定するか、IP アドレスなしでインターフェイスを出ることができます。 - 9
- この例では
ipv4を有効にします。 - 10
- この例では
stpを無効にします。 - 11
- ブリッジが接続されるノードの NIC。
23.1.7.3. 例: VLAN インターフェイスノードネットワークの設定ポリシー
NodeNetworkConfigurationPolicy マニフェストをクラスターに適用してクラスター内のノード上に VLAN インターフェイスを作成します。
1 つの NodeNetworkConfigurationPolicy マニフェストで、ノードの VLAN インターフェイスに関連するすべての設定を定義します。たとえば、同じ NodeNetworkConfigurationPolicy マニフェストで、ノードの VLAN インターフェイスと VLAN インターフェイスの関連ルートを定義します。
ノードが再起動すると、Kubernetes NMState Operator はポリシーを適用する順序を制御できません。したがって、関連するネットワーク設定に別々のポリシーを使用すると、Kubernetes NMState Operator がこれらのポリシーを順番に適用するため、ネットワークオブジェクトがデグレード状態になる可能性があります。
以下の YAML ファイルは、VLAN インターフェイスのマニフェストの例です。これには、独自の情報で置き換える必要のあるサンプルの値が含まれます。
apiVersion: nmstate.io/v1
kind: NodeNetworkConfigurationPolicy
metadata:
name: vlan-eth1-policy
spec:
nodeSelector:
kubernetes.io/hostname: <node01>
desiredState:
interfaces:
- name: eth1.102
description: VLAN using eth1
type: vlan
state: up
vlan:
base-iface: eth1
id: 102 - 1
- ポリシーの名前。
- 2
- オプション:
nodeSelectorパラメーターを含めない場合、ポリシーはクラスター内のすべてのノードに適用されます。 - 3
- この例では、
hostnameノードセレクターを使用します。 - 4
- インターフェイスの名前。ベアメタルにデプロイする場合、
<interface_name>.<vlan_number>VLAN 形式のみがサポートされます。 - 5
- オプション: 人間が判読できるインターフェイスの説明。
- 6
- インターフェイスのタイプ。以下の例では VLAN を作成します。
- 7
- 作成後のインターフェイスの要求された状態。
- 8
- VLAN が接続されているノードの NIC。
- 9
- VLAN タグ。
23.1.7.4. 例: ボンドインターフェイスノードネットワークの設定ポリシー
NodeNetworkConfigurationPolicy マニフェストをクラスターに適用してノード上にボンドインターフェイスを作成します。
OpenShift Container Platform は以下の bond モードのみをサポートします。
-
mode=1 active-backup
-
mode=2 balance-xor
-
mode=4 802.3ad
その他のボンディングモードはサポートされていません。
以下の YAML ファイルは、ボンドインターフェイスのマニフェストの例です。これには、独自の情報で置き換える必要のあるサンプルの値が含まれます。
apiVersion: nmstate.io/v1
kind: NodeNetworkConfigurationPolicy
metadata:
name: bond0-eth1-eth2-policy
spec:
nodeSelector:
kubernetes.io/hostname: <node01>
desiredState:
interfaces:
- name: bond0
description: Bond with ports eth1 and eth2
type: bond
state: up
ipv4:
dhcp: true
enabled: true
link-aggregation:
mode: active-backup
options:
miimon: '140'
port:
- eth1
- eth2
mtu: 1450 - 1
- ポリシーの名前。
- 2
- オプション:
nodeSelectorパラメーターを含めない場合、ポリシーはクラスター内のすべてのノードに適用されます。 - 3
- この例では、
hostnameノードセレクターを使用します。 - 4
- インターフェイスの名前。
- 5
- オプション: 人間が判読できるインターフェイスの説明。
- 6
- インターフェイスのタイプ。この例では、ボンドを作成します。
- 7
- 作成後のインターフェイスの要求された状態。
- 8
- オプション:
dhcpを使用しない場合は、静的 IP を設定するか、IP アドレスなしでインターフェイスを出ることができます。 - 9
- この例では
ipv4を有効にします。 - 10
- ボンドのドライバーモード。この例では、アクティブなバックアップモードを使用します。
- 11
- オプション: この例では、miimon を使用して 140ms ごとにボンドリンクを検査します。
- 12
- ボンド内の下位ノードの NIC。
- 13
- オプション: ボンドの Maximum Transmission Unit (MTU)指定がない場合、この値はデフォルトで
1500に設定されます。
23.1.7.5. 例: 同じノードネットワーク設定ポリシーでの複数のインターフェイス
同じノードネットワーク設定ポリシーで複数のインターフェイスを作成できます。これらのインターフェイスは相互に参照でき、単一のポリシーマニフェストを使用してネットワーク設定をビルドし、デプロイできます。
以下の YAML ファイルの例では、2 つの NIC 間に bond10 という名前のボンドと、ボンドに接続する bond10.103 という名前の VLAN を作成します。
apiVersion: nmstate.io/v1
kind: NodeNetworkConfigurationPolicy
metadata:
name: bond-vlan
spec:
nodeSelector:
kubernetes.io/hostname: <node01>
desiredState:
interfaces:
- name: bond10
description: Bonding eth2 and eth3
type: bond
state: up
link-aggregation:
mode: balance-xor
options:
miimon: '140'
port:
- eth2
- eth3
- name: bond10.103
description: vlan using bond10
type: vlan
state: up
vlan:
base-iface: bond10
id: 103
ipv4:
dhcp: true
enabled: true - 1
- ポリシーの名前。
- 2
- オプション:
nodeSelectorパラメーターを含めない場合、ポリシーはクラスター内のすべてのノードに適用されます。 - 3
- この例では、
hostnameノードセレクターを使用します。 - 4 11
- インターフェイスの名前。
- 5 12
- オプション: 人間が判読できるインターフェイスの説明。
- 6 13
- インターフェイスのタイプ。
- 7 14
- 作成後のインターフェイスの要求された状態。
- 8
- ボンドのドライバーモード。
- 9
- オプション: この例では、miimon を使用して 140ms ごとにボンドリンクを検査します。
- 10
- ボンド内の下位ノードの NIC。
- 15
- VLAN が接続されているノードの NIC。
- 16
- VLAN タグ。
- 17
- オプション: dhcp を使用しない場合は、静的 IP を設定するか、IP アドレスなしでインターフェイスを出ることができます。
- 18
- この例では ipv4 を有効にします。
23.1.7.6. 例: Virtual Function のノードネットワーク設定ポリシー (テクノロジープレビュー)
NodeNetworkConfigurationPolicy マニフェストを適用して、既存のクラスター内の Single Root I/O Virtualization (SR-IOV) ネットワーク Virtual Function (VF) のホストネットワーク設定を更新します。
SR-IOV ネットワーク VF のホストネットワーク設定の更新は、テクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品サポートのサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではない場合があります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
NodeNetworkConfigurationPolicy マニフェストを既存のクラスターに適用して、次のタスクを完了できます。
- VF の QoS ホストネットワークを設定して、パフォーマンスを最適化します。
- ネットワークインターフェイスの VF を追加、削除、または更新します。
- VF ボンディング設定を管理します。
SR-IOV Network Operator を通じて管理もされる物理機能で NMState を使用して SR-IOV VF のホストネットワーク設定を更新するには、関連する SriovNetworkNodePolicy リソースの externallyManaging パラメーターを true に設定する必要があります。詳細は、関連情報 セクションを参照してください。
次の YAML ファイルは、VF の QoS ポリシーを定義するマニフェストの例です。このファイルにはサンプル値が含まれていますが、これは独自の情報に置き換える必要があります。
apiVersion: nmstate.io/v1
kind: NodeNetworkConfigurationPolicy
metadata:
name: qos
spec:
nodeSelector:
node-role.kubernetes.io/worker: ""
desiredState:
interfaces:
- name: ens1f0
description: Change QOS on VF0
type: ethernet
state: up
ethernet:
sr-iov:
total-vfs: 3
vfs:
- id: 0
max-tx-rate: 200 - 1
- ポリシーの名前。
- 2
- オプション:
nodeSelectorパラメーターを含めない場合、ポリシーはクラスター内のすべてのノードに適用されます。 - 3
- この例は、
workerロールを持つすべてのノードに適用されます。 - 4
- 物理機能 (PF) ネットワークインターフェイスの名前。
- 5
- オプション: 人間が判読できるインターフェイスの説明。
- 6
- インターフェイスのタイプ。
- 7
- 設定後のインターフェイスの要求された状態。
- 8
- VF の総数。
- 9
- ID
0を持つ VF を識別します。 - 10
- VF の最大伝送速度 (Mbps) を設定します。このサンプル値は、200 Mbps のレートを設定します。
次の YAML ファイルは、VF 上に VLAN インターフェイスを作成し、それをボンディングされたネットワークインターフェイスに追加するマニフェストの例です。これには、独自の情報で置き換える必要のあるサンプルの値が含まれます。
apiVersion: nmstate.io/v1
kind: NodeNetworkConfigurationPolicy
metadata:
name: addvf
spec:
nodeSelector:
node-role.kubernetes.io/worker: ""
maxUnavailable: 3
desiredState:
interfaces:
- name: ens1f0v1
type: ethernet
state: up
- name: ens1f0v1.477
type: vlan
state: up
vlan:
base-iface: ens1f0v1
id: 477
- name: bond0
description: Add vf
type: bond
state: up
link-aggregation:
mode: active-backup
options:
primary: ens1f1v0.477
port:
- ens1f1v0.477
- ens1f0v0.477
- ens1f0v1.477 - 1
- ポリシーの名前。
- 2
- オプション:
nodeSelectorパラメーターを含めない場合、ポリシーはクラスター内のすべてのノードに適用されます。 - 3
- この例は、
workerロールを持つすべてのノードに適用されます。 - 4
- VF ネットワークインターフェイスの名前。
- 5
- VLAN ネットワークインターフェイスの名前。
- 6
- VLAN インターフェイスがアタッチされている VF ネットワークインターフェイス。
- 7
- ボンディングネットワークインターフェイスの名前。
- 8
- オプション: 人間が判読できるインターフェイスの説明。
- 9
- インターフェイスのタイプ。
- 10
- 設定後のインターフェイスの要求された状態。
- 11
- ボンディングのボンディングポリシー。
- 12
- 割り当てられたプライマリーボンディングポート。
- 13
- ボンディングされたネットワークインターフェイスのポート。
- 14
- この例では、この VLAN ネットワークインターフェイスが、追加インターフェイスとしてボンディングされたネットワークインターフェイスに追加されています。
23.1.7.7. 例: VRF インスタンスノードのネットワーク設定ポリシーを使用したネットワークインターフェイス
NodeNetworkConfigurationPolicy カスタムリソース (CR) を適用して、Virtual Routing and Forwarding (VRF) インスタンスをネットワークインターフェイスに関連付けます。
VRF インスタンスとネットワークインターフェイスの関連付けは、テクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
VRF インスタンスをネットワークインターフェイスに関連付けることにより、トラフィックの分離、独立したルーティングの決定、およびネットワークリソースの論理的な分離をサポートできます。
仮想ルート転送 (VRF) を設定する場合、VRF 値を 1000 未満のテーブル ID に変更する必要があります。1000 より大きい値は OpenShift Container Platform 用に予約されているためです。
ベアメタル環境では、MetalLB を使用して、VRF インスタンスに属するインターフェイスを通じてロードバランサーサービスを通知できます。詳細は、関連情報 セクションを参照してください。
次の YAML ファイルは、VRF インスタンスをネットワークインターフェイスに関連付ける例です。これには、独自の情報で置き換える必要のあるサンプルの値が含まれます。
apiVersion: nmstate.io/v1
kind: NodeNetworkConfigurationPolicy
metadata:
name: vrfpolicy
spec:
nodeSelector:
vrf: "true"
maxUnavailable: 3
desiredState:
interfaces:
- name: ens4vrf
type: vrf
state: up
vrf:
port:
- ens4
route-table-id: 2 23.1.8. ノード上に IP over InfiniBand インターフェイスを作成する
OpenShift Container Platform Web コンソールでは、InfiniBand (IPoIB) モードをサポートする NVIDIA Network Operator などの Red Hat 認定サードパーティー Operator をインストールできます。サードパーティー Operator は、通常、OpenShift Container Platform クラスター内のリソースを管理するために他のベンダーのインフラストラクチャーと組み合わせて使用します。クラスター内のノードに IPoIB インターフェイスを作成するには、NodeNetworkConfigurationPolicy (NNCP) マニフェストファイルで InfiniBand (IPoIB) インターフェイスを定義する必要があります。
OpenShift Container Platform のドキュメントでは、NodeNetworkConfigurationPolicy (NNCP) マニフェストファイルで IPoIB インターフェイス設定を定義する方法についてのみ説明しています。設定手順の大部分については、NVIDIA およびその他のサードパーティーベンダーのドキュメントを参照してください。Red Hat のサポートは、NNCP 設定以外には適用されません。
NVIDIA Operator の詳細は、Getting Started with Red Hat OpenShift (NVIDIA Docs Hub) を参照してください。
前提条件
- IPoIB インターフェイスをサポートする Red Hat 認定サードパーティー Operator をインストールした。
手順
NodeNetworkConfigurationPolicy(NNCP) マニフェストファイルを作成または編集し、ファイル内で IPoIB インターフェイスを指定します。apiVersion: nmstate.io/v1 kind: NodeNetworkConfigurationPolicy metadata: name: worker-0-ipoib spec: # ... interfaces: - description: "" infiniband: mode: datagram1 pkey: "0xffff"2 ipv4: address: - ip: 100.125.3.4 prefix-length: 16 dhcp: false enabled: true ipv6: enabled: false name: ibp27s0 state: up identifier: mac-address3 mac-address: 20:00:55:04:01:FE:80:00:00:00:00:00:00:00:02:C9:02:00:23:13:924 type: infiniband5 # ...- 1
datagramは IPoIB インターフェイスのデフォルトモードであり、このモードではパフォーマンスとレイテンシーが最適化されます。connectedモードはサポートされているモードですが、周辺ネットワークデバイスとのノードの接続性を高めるために最大転送単位 (MTU) 値を調整する必要がある場合にのみ、このモードを使用することを検討してください。- 2
- 文字列または整数値をサポートします。このパラメーターは、NVIDIA などのサードパーティーベンダーとの認証および暗号化通信を目的としたインターフェイスの保護キー (P-key) を定義します。
Noneおよび0xffffの値は、InfiniBand システムの基本インターフェイスの保護キーを示します。 - 3
- サポートされている値は、
name、デフォルト値、およびmac-addressです。name値は、指定されたインターフェイス名を持つインターフェイスに設定を適用します。 - 4
- インターフェイスの MAC アドレスを指定します。IP-over-InfiniBand (IPoIB) インターフェイスの場合、アドレスは 20 バイトの文字列です。
- 5
- インターフェイスのタイプを
infinibandに設定します。
次のコマンドを実行して、クラスター内の各ノードに NNCP 設定を適用します。Kubernetes NMState Operator は、各ノードに IPoIB インターフェイスを作成できます。
$ oc apply -f <nncp_file_name>1 - 1
<nncp_file_name>は、NNCP ファイルの名前に置き換えます。
23.1.9. ブリッジに接続された NIC の静的 IP の取得
NIC の静的 IP のキャプチャーは、テクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
23.1.9.1. 例: ブリッジに接続された NIC から静的 IP アドレスを継承する Linux ブリッジインターフェイスノードネットワーク設定ポリシー
クラスター内のノードに Linux ブリッジインターフェイスを作成し、単一の NodeNetworkConfigurationPolicy マニフェストをクラスターに適用して NIC の静的 IP 設定をブリッジに転送します。
以下の YAML ファイルは、Linux ブリッジインターフェイスのマニフェストの例です。これには、独自の情報で置き換える必要のあるサンプルの値が含まれます。
apiVersion: nmstate.io/v1
kind: NodeNetworkConfigurationPolicy
metadata:
name: br1-eth1-copy-ipv4-policy
spec:
nodeSelector:
node-role.kubernetes.io/worker: ""
capture:
eth1-nic: interfaces.name=="eth1"
eth1-routes: routes.running.next-hop-interface=="eth1"
br1-routes: capture.eth1-routes | routes.running.next-hop-interface := "br1"
desiredState:
interfaces:
- name: br1
description: Linux bridge with eth1 as a port
type: linux-bridge
state: up
ipv4: "{{ capture.eth1-nic.interfaces.0.ipv4 }}"
bridge:
options:
stp:
enabled: false
port:
- name: eth1
routes:
config: "{{ capture.br1-routes.routes.running }}"- 1
- ポリシーの名前。
- 2
- オプション:
nodeSelectorパラメーターを含めない場合、ポリシーはクラスター内のすべてのノードに適用されます。この例ではnode-role.kubernetes.io/worker: ""ノードセレクターを使用し、クラスター内のすべてのワーカーノードを選択します。 - 3
- ブリッジを接続するノード NIC への参照。
- 4
- インターフェイスのタイプ。この例では、ブリッジを作成します。
- 5
- ブリッジインターフェイスの IP アドレス。この値は、
spec.capture.eth1-nicエントリーにより参照される NIC の IP アドレスと一致します。 - 6
- ブリッジが接続されるノードの NIC。
23.1.10. 例: IP 管理
次の設定スニペットの例は、さまざまな IP 管理方法を示しています。
これらの例では、ethernet インターフェイスタイプを使用して、ポリシー設定に関連するコンテキストを表示しつつ、サンプルを単純化します。これらの IP 管理のサンプルは、他のインターフェイスタイプでも使用できます。
23.1.10.1. 静的
以下のスニペットは、イーサネットインターフェイスで IP アドレスを静的に設定します。
# ...
interfaces:
- name: eth1
description: static IP on eth1
type: ethernet
state: up
ipv4:
dhcp: false
address:
- ip: 192.168.122.250
prefix-length: 24
enabled: true
# ...- 1
- この値を、インターフェイスの静的 IP アドレスに置き換えます。
23.1.10.2. IP アドレスなし
以下のスニペットでは、インターフェイスに IP アドレスがないことを確認できます。
# ...
interfaces:
- name: eth1
description: No IP on eth1
type: ethernet
state: up
ipv4:
enabled: false
# ...
インターフェイスを無効にするために ipv4.enabled パラメーターと ipv6.enabled パラメーターの両方を false に設定する場合は、必ず state パラメーターを up に設定してください。この設定で state: down を設定すると、自動 DHCP 割り当てによりインターフェイスは DHCP IP アドレスを受け取ります。
23.1.10.3. 動的ホストの設定
以下のスニペットは、動的 IP アドレス、ゲートウェイアドレス、および DNS を使用するイーサネットインターフェイスを設定します。
# ...
interfaces:
- name: eth1
description: DHCP on eth1
type: ethernet
state: up
ipv4:
dhcp: true
enabled: true
# ...以下のスニペットは、動的 IP アドレスを使用しますが、動的ゲートウェイアドレスまたは DNS を使用しないイーサネットインターフェイスを設定します。
# ...
interfaces:
- name: eth1
description: DHCP without gateway or DNS on eth1
type: ethernet
state: up
ipv4:
dhcp: true
auto-gateway: false
auto-dns: false
enabled: true
# ...23.1.10.4. メディアアクセス制御 (MAC) アドレス
ネットワークインターフェイスの名前を使用する代わりに、MAC アドレスを使用してネットワークインターフェイスを識別することができます。ネットワークインターフェイス名は、オペレーティングシステムの設定の変更など、さまざまな理由で変更される可能性があります。一方で、各ネットワークインターフェイスには、変更されない一意の MAC アドレスがあります。そのため、MAC アドレスを使用すると、特定のネットワークインターフェイスをより永続的に識別すことができます。
identifier パラメーターでサポートされている値は、デフォルトの name 値と mac-address 値です。name 値は、指定されたインターフェイス名を持つインターフェイスに設定を適用します。
identifier パラメーターに mac-address 値を使用すると、MAC アドレスがネットワークインターフェイスの識別子であることが指定されます。identifier の値を mac-address に設定する場合は、その後に続く mac-address パラメーターフィールドに特定の MAC アドレスを入力する必要があります。
name パラメーターの値を指定することもできますが、identifier: mac-address 値を設定すると、ネットワークインターフェイスのプライマリー識別子として MAC アドレスが使用されることになります。間違った MAC アドレスを指定した場合、nmstate によって無効な引数のエラーが報告されます。
次のスニペットでは、イーサネットデバイスのプライマリー識別子として MAC アドレスを指定します。デバイスの名前は eth1、MAC アドレスは 8A:8C:92:1A:F6:98 です。
# ...
interfaces:
- name: eth1
profile-name: wan0
type: ethernet
state: up
identifier: mac-address
mac-address: 8A:8C:92:1A:F6:98
# ...23.1.10.5. DNS
デフォルトでは、nmstate API は DNS 値をネットワークインターフェイスに保存するのではなく、グローバルに保存します。特定の状況では、DNS 値を保存するようにネットワークインターフェイスを設定する必要があります。
DNS 設定の設定は、/etc/resolv.conf ファイルの変更に相当します。
ネットワークインターフェイスの DNS 設定を定義するには、最初にネットワークインターフェイスの YAML 設定ファイルで dns-resolver セクションを指定する必要があります。NNCP 設定をネットワークインターフェイスに適用するには、oc apply -f <nncp_file_name> コマンドを実行する必要があります。
次の例は、DNS 値をグローバルに保存するデフォルトの状況を示しています。
ネットワークインターフェイスなしで静的 DNS を設定します。ホストノード上の
/etc/resolv.confファイルを更新する場合、NodeNetworkConfigurationPolicy(NNCP) マニフェストでインターフェイス (IPv4 または IPv6) を指定する必要はありません。DNS 値をグローバルに保存するネットワークインターフェイスの DNS 設定の例
apiVersion: nmstate.io/v1 kind: NodeNetworkConfigurationPolicy metadata: name: worker-0-dns-testing spec: nodeSelector: kubernetes.io/hostname: <target_node> desiredState: dns-resolver: config: search: - example.com - example.org server: - 2001:db8:f::1 - 192.0.2.251 # ...重要次の例に示すように、NNCP ファイルの
dns-resolver.configセクションで DNS オプションを指定できます。# ... desiredState: dns-resolver: config: options: - timeout:2 - attempts:3 # ...ネットワークインターフェイスから DNS オプションを削除する場合は、NNCP に次の設定を適用してから
oc apply -f <nncp_file_name>コマンドを実行します。# ... dns-resolver: config: {} interfaces: [] # ...
次の例は、DNS 値を格納するためにネットワークインターフェイスを設定する必要がある状況を示しています。
静的 DNS ネームサーバーを動的 DNS ネームサーバーよりも優先する場合は、ネットワークインターフェイス YAML 設定ファイルで、Dynamic Host Configuration Protocol (DHCP) または IPv6 自動設定 (
autoconf) メカニズムのいずれかを実行するインターフェイスを定義します。DHCPv4 ネットワークプロトコルから取得した DNS ネームサーバーに
192.0.2.1を追加する設定の例# ... dns-resolver: config: server: - 192.0.2.1 interfaces: - name: eth1 type: ethernet state: up ipv4: enabled: true dhcp: true auto-dns: true # ...nmstateAPI を使用して DNS 値をグローバルに保存するデフォルトの方法を採用するのではなく、DNS 値を保存するようにネットワークインターフェイスを設定する必要がある場合は、ネットワークインターフェイス YAML ファイルで静的 DNS 値と静的 IP アドレスを設定できます。重要ネットワークインターフェイスレベルで DNS 値を保存すると、インターフェイスを Open vSwitch (OVS) ブリッジ、Linux ブリッジ、ボンディングなどのネットワークコンポーネントに接続した後に、名前解決の問題が発生する可能性があります。
インターフェイスレベルで DNS 値を保存する設定の例
# ... dns-resolver: config: search: - example.com - example.org server: - 2001:db8:1::d1 - 2001:db8:1::d2 - 192.0.2.1 interfaces: - name: eth1 type: ethernet state: up ipv4: address: - ip: 192.0.2.251 prefix-length: 24 dhcp: false enabled: true ipv6: address: - ip: 2001:db8:1::1 prefix-length: 64 dhcp: false enabled: true autoconf: false # ...ネットワークインターフェイスに静的 DNS 検索ドメインと動的 DNS ネームサーバーを設定する場合は、ネットワークインターフェイスの YAML 設定ファイルで、Dynamic Host Configuration Protocol (DHCP) または IPv6 自動設定 (
autoconf) メカニズムのいずれかを実行する動的インターフェイスを定義します。example.comおよびexample.orgの静的 DNS 検索ドメインと動的 DNS ネームサーバー設定を指定する設定の例# ... dns-resolver: config: search: - example.com - example.org server: [] interfaces: - name: eth1 type: ethernet state: up ipv4: enabled: true dhcp: true auto-dns: true ipv6: enabled: true dhcp: true autoconf: true auto-dns: true # ...
23.1.10.6. 静的ルーティング
以下のスニペットは、インターフェイス eth1 に静的ルートおよび静的 IP を設定します。
dns-resolver:
config:
# ...
interfaces:
- name: eth1
description: Static routing on eth1
type: ethernet
state: up
ipv4:
dhcp: false
enabled: true
address:
- ip: 192.0.2.251
prefix-length: 24
routes:
config:
- destination: 198.51.100.0/24
metric: 150
next-hop-address: 192.0.2.1
next-hop-interface: eth1
table-id: 254
# ...
静的ルートを設定する際に、カスタマイズされた br-ex ブリッジを手動で設定していない限り、OVN-Kubernetes br-ex ブリッジをネクストホップインターフェイスとして使用することはできません。
詳細は、インストーラーでプロビジョニングされるクラスターのベアメタルへのデプロイ、または ユーザーがプロビジョニングしたクラスターをベアメタルにインストール ドキュメントの「カスタマイズされた br-ex ブリッジを含むマニフェストオブジェクトの作成」を参照してください。
'%20d='M201.5%20305.5c-13.8%200-24.9-11.1-24.9-24.6%200-13.8%2011.1-24.9%2024.9-24.9%2013.6%200%2024.6%2011.1%2024.6%2024.9%200%2013.6-11.1%2024.6-24.6%2024.6zM504%20256c0%20137-111%20248-248%20248S8%20393%208%20256%20119%208%20256%208s248%20111%20248%20248zm-132.3-41.2c-9.4%200-17.7%203.9-23.8%2010-22.4-15.5-52.6-25.5-86.1-26.6l17.4-78.3%2055.4%2012.5c0%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.3%2024.9-24.9s-11.1-24.9-24.9-24.9c-9.7%200-18%205.8-22.1%2013.8l-61.2-13.6c-3-.8-6.1%201.4-6.9%204.4l-19.1%2086.4c-33.2%201.4-63.1%2011.3-85.5%2026.8-6.1-6.4-14.7-10.2-24.1-10.2-34.9%200-46.3%2046.9-14.4%2062.8-1.1%205-1.7%2010.2-1.7%2015.5%200%2052.6%2059.2%2095.2%20132%2095.2%2073.1%200%20132.3-42.6%20132.3-95.2%200-5.3-.6-10.8-1.9-15.8%2031.3-16%2019.8-62.5-14.9-62.5zM302.8%20331c-18.2%2018.2-76.1%2017.9-93.6%200-2.2-2.2-6.1-2.2-8.3%200-2.5%202.5-2.5%206.4%200%208.6%2022.8%2022.8%2087.3%2022.8%20110.2%200%202.5-2.2%202.5-6.1%200-8.6-2.2-2.2-6.1-2.2-8.3%200zm7.7-75c-13.6%200-24.6%2011.1-24.6%2024.9%200%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.1%2024.9-24.6%200-13.8-11-24.9-24.9-24.9z'/%3e%3c/svg%3e){kind=small}