検索

26.7. Kuryr ネットワークプラグインから OVN-Kubernetes ネットワークプラグインへの移行

download PDF
重要

Kuryr から OVN-Kubernetes への移行は、テクノロジープレビュー機能のみです。テクノロジープレビュー機能は、Red Hat 製品サポートのサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではない場合があります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビューの機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。

Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。

Red Hat OpenStack Platform (RHOSP) 上で実行されるクラスターの管理者は、Kuryr SDN ネットワークプラグインから OVN-Kubernetes ネットワークプラグインに移行できます。

OVN-Kubernetes の詳細は、OVN-Kubernetes ネットワークプラグインについて を参照してください。

26.7.1. OVN-Kubernetes ネットワークプロバイダーへの移行

Red Hat OpenStack Platform (RHOSP) 上で実行されるクラスターを OVN-Kubernetes ネットワークプロバイダーに手動で移行できます。

重要

OVN-Kubernetes への移行は一方向のプロセスです。移行中、クラスターは短時間アクセスできなくなります。

26.7.1.1. OVN-Kubernetes ネットワークプロバイダーへの移行についての考慮点

Kubernetes namespace は、Kuryr によって別の RHOSP ネットワーキングサービス (Neutron) サブネットに保持されます。個々の Pod に割り当てられているサブネットと IP アドレスは、移行中には保持されません。

26.7.1.2. 移行プロセスの仕組み

次の表は、ユーザーが実行する手順とクラスターおよび Operator が実行するアクションを関連付けて、移行プロセスをまとめたものです。

表26.9 Kuryr から OVN-Kubernetes への移行プロセス
ユーザーが開始する手順移行アクティビティー

cluster という名前の Network.operator.openshift.io カスタムリソース (CR) の migration フィールドを OVNKubernetes に設定します。別の値に設定する前に、migration フィールドの値に null 値が出力されていることを確認してください。

Cluster Network Operator (CNO)
cluster という名前の Network.config.openshift.io CR のステータスを更新します。
Machine Config Operator (MCO)
OVN-Kubernetes に必要な更新を systemd 設定にデプロイします。デフォルトでは、MCO は一度にプールごとに 1 台のマシンを更新します。その結果、大規模なクラスターでは移行時間が長くなります。

Network.config.openshift.io CR の networkType フィールドを更新します。

CNO

以下のアクションを実行します。

  • Kuryr コントロールプレーン Pod (Kuryr CNI と Kuryr コントローラー) を破壊します。
  • OVN-Kubernetes コントロールプレーン Pod をデプロイします。
  • Multus オブジェクトを更新して、新しいネットワークプラグインを反映します。

クラスターの各ノードを再起動します。

クラスター
ノードの再起動時に、クラスターは OVN-Kubernetes クラスターネットワークの Pod に IP アドレスを割り当てます。

Kuryr が管理する残りのリソースをクリーンアップします。

クラスター
解放する必要がある RHOSP リソースと、設定する OpenShift Container Platform リソースを保持します。

26.7.2. OVN-Kubernetes ネットワークプラグインへの移行

クラスター管理者は、クラスターのネットワークプラグインを OVN-Kubernetes に変更できます。

重要

移行時に、クラスター内のすべてのノードを再起動する必要があります。クラスターが利用できないため、ワークロードが中断される可能性があります。サービスの中断が許容される場合にのみ移行を実行してください。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
  • etcd データベースの最新のバックアップが利用可能です。
  • 各ノードを手動で再起動できます。
  • 移行を計画しているクラスターは、エラーがなく、既知の良好な状態にあります。
  • Python インタープリターがインストールされている。
  • openstacksdk Python パッケージがインストールされている。
  • openstack CLI ツールがインストールされています。
  • 基盤となる RHOSP クラウドにアクセスできます。

手順

  1. 次のコマンドを実行して、クラスターネットワークの設定をバックアップします。

    $ oc get Network.config.openshift.io cluster -o yaml > cluster-kuryr.yaml
  2. CLUSTERID 変数を設定するには、次のコマンドを実行します。

    $ CLUSTERID=$(oc get infrastructure.config.openshift.io cluster -o=jsonpath='{.status.infrastructureName}')
  3. すべてのノードの移行を準備するには、次のコマンドを実行して、Cluster Network Operator 設定オブジェクトの migration フィールドを設定します。

    $ oc patch Network.operator.openshift.io cluster --type='merge' \
      --patch '{ "spec": { "migration": { "networkType": "OVNKubernetes" } } }'
    注記

    この手順では、OVN-Kubernetes はすぐにデプロイしません。migration フィールドを指定すると、新規マシン設定がクラスター内のすべてのノードに適用されるように Machine Config Operator (MCO) がトリガーされます。これにより、OVN-Kubernetes デプロイメント用にクラスターが準備されます。

  4. オプション: ネットワークインフラストラクチャー要件に合わせて、OVN-Kubernetes の次の設定をカスタマイズします。

    • 最大伝送単位 (MTU)
    • Geneve (Generic Network Virtualization Encapsulation) オーバーレイネットワークポート
    • OVN-Kubernetes IPv4 内部サブネット
    • OVN-Kubernetes IPv6 内部サブネット

    これらの設定をカスタマイズするには、次のコマンドを入力してカスタマイズします。

    $ oc patch Network.operator.openshift.io cluster --type=merge \
      --patch '{
        "spec":{
          "defaultNetwork":{
            "ovnKubernetesConfig":{
              "mtu":<mtu>,
              "genevePort":<port>,
              "v4InternalSubnet":"<ipv4_subnet>",
              "v6InternalSubnet":"<ipv6_subnet>"
        }}}}'

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

    mtu
    Geneve オーバーレイネットワークの MTU を指定します。この値は通常は自動的に設定されますが、クラスターにあるノードすべてが同じ MTU を使用しない場合、これを最小のノード MTU 値よりも 100 小さく設定する必要があります。
    port
    Geneve オーバーレイネットワークの UDP ポートを指定します。値が指定されない場合、デフォルトは 6081 になります。このポートは、Kuryr が使用する VXLAN ポートと同じにすることはできません。VXLAN ポートのデフォルト値は 4789 です。
    ipv4_subnet
    OVN-Kubernetes による内部使用のための IPv4 アドレス範囲を指定します。IP アドレス範囲が、OpenShift Container Platform インストールで使用される他のサブネットと重複しないようにする必要があります。IP アドレス範囲は、クラスターに追加できるノードの最大数より大きくする必要があります。デフォルト値は 100.64.0.0/16 です。
    ipv6_subnet
    OVN-Kubernetes による内部使用のための IPv6 アドレス範囲を指定します。IP アドレス範囲が、OpenShift Container Platform インストールで使用される他のサブネットと重複しないようにする必要があります。IP アドレス範囲は、クラスターに追加できるノードの最大数より大きくする必要があります。デフォルト値は fd98::/48 です。

    デフォルト値を変更する必要がない場合は、パッチのキーを省略します。

    mtu フィールドを更新するパッチコマンドの例

    $ oc patch Network.operator.openshift.io cluster --type=merge \
      --patch '{
        "spec":{
          "defaultNetwork":{
            "ovnKubernetesConfig":{
              "mtu":1200
        }}}}'

  5. 以下のコマンドを実行してマシン設定プールのステータスを確認します。

    $ oc get mcp

    MCO は各マシン設定プール内のマシンを更新する際に、各ノードを 1 つずつ再起動します。続行する前に、すべてのノードが更新されるまで待つ必要があります。

    正常に更新されたノードには、UPDATED=trueUPDATING=falseDEGRADED=false のステータスがあります。

    注記

    デフォルトでは、MCO は一度にプールごとに 1 台のマシンを更新します。大規模なクラスターは、小規模なクラスターよりも移行に時間がかかります。

  6. ホスト上の新規マシン設定のステータスを確認します。

    1. マシン設定の状態と適用されたマシン設定の名前をリスト表示するには、以下のコマンドを入力します。

      $ oc describe node | egrep "hostname|machineconfig"

      出力例

      kubernetes.io/hostname=master-0
      machineconfiguration.openshift.io/currentConfig: rendered-master-c53e221d9d24e1c8bb6ee89dd3d8ad7b 1
      machineconfiguration.openshift.io/desiredConfig: rendered-master-c53e221d9d24e1c8bb6ee89dd3d8ad7b 2
      machineconfiguration.openshift.io/reason:
      machineconfiguration.openshift.io/state: Done

    2. 前のステップの出力を確認します。次のステートメントが真である必要があります。

      • machineconfiguration.openshift.io/state フィールドの値は Done です。
      • machineconfiguration.openshift.io/currentConfig フィールドの値は、machineconfiguration.openshift.io/desiredConfig フィールドの値と等しくなります。
    3. マシン設定が正しいことを確認するには、以下のコマンドを入力します。

      $ oc get machineconfig <config_name> -o yaml | grep ExecStart

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

      <config_name>

      machineconfiguration.openshift.io/currentConfig フィールドからマシン設定の名前を指定します。

      マシン設定には、systemd 設定に以下の更新を含める必要があります。

      出力例

      ExecStart=/usr/local/bin/configure-ovs.sh OVNKubernetes

    4. ノードが NotReady 状態でスタックしている場合は、マシン設定デーモン Pod のログを調査し、エラーがあれば解決します。

      1. Pod をリスト表示するには、以下のコマンドを入力します。

        $ oc get pod -n openshift-machine-config-operator

        出力例

        NAME                                         READY   STATUS    RESTARTS   AGE
        machine-config-controller-75f756f89d-sjp8b   1/1     Running   0          37m
        machine-config-daemon-5cf4b                  2/2     Running   0          43h
        machine-config-daemon-7wzcd                  2/2     Running   0          43h
        machine-config-daemon-fc946                  2/2     Running   0          43h
        machine-config-daemon-g2v28                  2/2     Running   0          43h
        machine-config-daemon-gcl4f                  2/2     Running   0          43h
        machine-config-daemon-l5tnv                  2/2     Running   0          43h
        machine-config-operator-79d9c55d5-hth92      1/1     Running   0          37m
        machine-config-server-bsc8h                  1/1     Running   0          43h
        machine-config-server-hklrm                  1/1     Running   0          43h
        machine-config-server-k9rtx                  1/1     Running   0          43h

        設定デーモン Pod の名前は以下の形式になります。machine-config-daemon-<seq><seq> 値は、ランダムな 5 文字の英数字シーケンスになります。

      2. 以下のコマンドを入力して、直前の出力に表示される最初のマシン設定デーモン Pod の Pod ログを表示します。

        $ oc logs <pod> -n openshift-machine-config-operator

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

        <pod>
        マシン設定デーモン Pod の名前を指定します。
      3. 直前のコマンドの出力で示されるログ内のエラーを解決します。
  7. 移行を開始するには、次のいずれかのコマンドを使用して OVN-Kubernetes ネットワークプラグインを設定します。

    • クラスターネットワークの IP アドレスブロックを変更せずにネットワークプロバイダーを指定するには、以下のコマンドを入力します。

      $ oc patch Network.config.openshift.io cluster \
        --type='merge' --patch '{ "spec": { "networkType": "OVNKubernetes" } }'
    • 別のクラスターネットワーク IP アドレスブロックを指定するには、以下のコマンドを入力します。

      $ oc patch Network.config.openshift.io cluster \
        --type='merge' --patch '{
          "spec": {
            "clusterNetwork": [
              {
                "cidr": "<cidr>",
                "hostPrefix": "<prefix>"
              }
            ]
            "networkType": "OVNKubernetes"
          }
        }'

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

      <cidr>
      CIDR ブロックを指定します。
      <prefix>

      クラスター内の各ノードに割り当てられる CIDR ブロックのスライスを指定します。

      重要

      移行時に、サービスネットワークのアドレスブロックを変更することはできません。

      OVN-Kubernetes ネットワークプロバイダーはこのブロックを内部で使用するため、100.64.0.0/16 CIDR ブロックと重複する CIDR ブロックは使用できません。

  8. 次のコマンドを入力して、Multus デーモンセットのロールアウトが完了していることを確認します。

    $ oc -n openshift-multus rollout status daemonset/multus

    Multus Pod の名前は multus-<xxxxx> の形式で、<xxxxx> はランダムな文字のシーケンスです。Pod が再起動するまでにしばらく時間がかかる可能性があります。

    出力例

    Waiting for daemon set "multus" rollout to finish: 1 out of 6 new pods have been updated...
    ...
    Waiting for daemon set "multus" rollout to finish: 5 of 6 updated pods are available...
    daemon set "multus" successfully rolled out

  9. 移行を完了するには、クラスター内の各ノードを再起動します。たとえば、以下のような bash スクリプトを使用できます。このスクリプトは、ssh を使用して各ホストに接続でき、sudo がパスワードを要求しないように設定されていることを前提としています。

    #!/bin/bash
    
    for ip in $(oc get nodes  -o jsonpath='{.items[*].status.addresses[?(@.type=="InternalIP")].address}')
    do
       echo "reboot node $ip"
       ssh -o StrictHostKeyChecking=no core@$ip sudo shutdown -r -t 3
    done
    注記

    SSH アクセスが利用できない場合は、openstack コマンドを使用できます。

    $ for name in $(openstack server list --name ${CLUSTERID}\* -f value -c Name); do openstack server reboot $name; done

    あるいは、インフラストラクチャープロバイダーの管理ポータルを通じて各ノードを再起動できる場合もあります。それ以外の場合は、適切な機関に問い合わせて、SSH または管理ポータルと OpenStack クライアントを介して仮想マシンにアクセスしてください。

検証

  1. 移行が成功したことを確認し、移行リソースを削除します。

    1. ネットワークプラグインが OVN-Kubernetes であることを確認するには、次のコマンドを入力します。

      $ oc get network.config/cluster -o jsonpath='{.status.networkType}{"\n"}'

      status.networkType の値は OVNKubernetes である必要があります。

    2. クラスターノードが Ready 状態にあることを確認するには、以下のコマンドを実行します。

      $ oc get nodes
    3. Pod がエラー状態ではないことを確認するには、以下のコマンドを入力します。

      $ oc get pods --all-namespaces -o wide --sort-by='{.spec.nodeName}'

      ノードの Pod がエラー状態にある場合は、そのノードを再起動します。

    4. すべてのクラスター Operator が異常な状態にないことを確認するには、以下のコマンドを入力します。

      $ oc get co

      すべてのクラスター Operator のステータスは、AVAILABLE="True"PROGRESSING="False"DEGRADED="False" になります。クラスター Operator が利用できないか、そのパフォーマンスが低下する場合には、クラスター Operator のログで詳細を確認します。

      重要

      これまでの検証手順のいずれかでエラーが示された場合は、続行しないでください。クリーンアップ中に削除されたファイナライザーが原因で、Terminating 状態の Pod が発生する場合があります。これらはエラーを示すものではありません。

  2. 移行が完了し、クラスターが良好な状態にある場合は、次のコマンドを入力して、CNO 設定オブジェクトから移行設定を削除します。

    $ oc patch Network.operator.openshift.io cluster --type='merge' \
      --patch '{ "spec": { "migration": null } }'

26.7.3. 移行後のリソースのクリーンアップ

Kuryr ネットワークプラグインから OVN-Kubernetes ネットワークプラグインに移行した後、Kuryr が以前に作成したリソースをクリーンアップする必要があります。

注記

クリーンアッププロセスは、Python 仮想環境に依存して、使用するパッケージバージョンが Octavia オブジェクトのタグをサポートしていることを確認します。環境で少なくとも次のものを使用していることが確実な場合は、仮想環境は必要ありません。* openstacksdk バージョン 0.54.0 * python-openstackclient バージョン 5.5.0 * python-octaviaclient バージョン 2.3.0

前提条件

  • OpenShift Container Platform CLI (oc) をインストールしている。
  • Python インタープリターをインストールしている。
  • openstacksdk Python パッケージがインストールされている。
  • openstack CLI がインストールされている。
  • 基盤となる RHOSP クラウドにアクセスできます。
  • クラスター管理者 ロールを持つユーザーとしてクラスターにアクセスできます。

手順

  1. クリーンアップ Python 仮想環境を作成します。

    1. 環境用の一時ディレクトリーを作成します。以下に例を示します。

      $ python3 -m venv /tmp/venv

      /tmp/venv ディレクトリーにある仮想環境は、すべてのクリーンアップ例で使用されます。

    2. 仮想環境に入ります。以下に例を示します。

      $ source /tmp/venv/bin/activate
    3. 次のコマンドを実行して、仮想環境で pip コマンドをアップグレードします。

      (venv) $ pip install pip --upgrade
    4. 次のコマンドを実行して、必要な Python パッケージをインストールします。

      (venv) $ pip install openstacksdk==0.54.0 python-openstackclient==5.5.0 python-octaviaclient==2.3.0
  2. ターミナルで、次のコマンドを実行して、クラスター識別子と Kuryr 識別子に変数を設定します。

    1. cluster ID を設定します。

      (venv) $ CLUSTERID=$(oc get infrastructure.config.openshift.io cluster -o=jsonpath='{.status.infrastructureName}')
    2. cluster タグを設定します。

      (venv) $ CLUSTERTAG="openshiftClusterID=${CLUSTERID}"
    3. router ID を設定します。

      (venv) $ ROUTERID=$(oc get kuryrnetwork -A --no-headers -o custom-columns=":status.routerId"|head -n 1)
  3. 次のコマンドを実行して、指定されたリソースからファイナライザーを削除する Bash 関数を作成します。

    (venv) $ function REMFIN {
        local resource=$1
        local finalizer=$2
        for res in $(oc get $resource -A --template='{{range $i,$p := .items}}{{ $p.metadata.name }}|{{ $p.metadata.namespace }}{{"\n"}}{{end}}'); do
            name=${res%%|*}
            ns=${res##*|}
            yaml=$(oc get -n $ns $resource $name -o yaml)
            if echo "${yaml}" | grep -q "${finalizer}"; then
                echo "${yaml}" | grep -v  "${finalizer}" | oc replace -n $ns $resource $name -f -
            fi
        done
    }

    この関数は 2 つのパラメーターを受け取ります。最初のパラメーターはリソースの名前で、2 番目のパラメーターは削除するファイナライザーです。指定されたリソースがクラスターから削除され、その定義は、指定されたファイナライザーを除いて、コピーされたデータに置き換えられます。

  4. Kuryr ファイナライザーをサービスから削除するには、次のコマンドを入力します。

    (venv) $ REMFIN services kuryr.openstack.org/service-finalizer
  5. Kuryr service-subnet-gateway-ip サービスを削除するには、次のコマンドを入力します。

    (venv) $ if $(oc get -n openshift-kuryr service service-subnet-gateway-ip &>/dev/null); then
        oc -n openshift-kuryr delete service service-subnet-gateway-ip
    fi
  6. タグ付けされたすべての RHOSP ロードバランサーを Octavia から削除するには、次のコマンドを入力します。

    (venv) $ for lb in $(openstack loadbalancer list --tags $CLUSTERTAG -f value -c id); do
        openstack loadbalancer delete --cascade $lb
    done
  7. すべての KuryrLoadBalancer CR から Kuryr ファイナライザーを削除するには、次のコマンドを入力します。

    (venv) $ REMFIN kuryrloadbalancers.openstack.org kuryr.openstack.org/kuryrloadbalancer-finalizers
  8. openshift-kuryr namespace を削除するには、次のコマンドを入力します。

    (venv) $ oc delete namespace openshift-kuryr
  9. Kuryr サービスのサブネットをルーターから削除するには、次のコマンドを入力します。

    (venv) $ openstack router remove subnet $ROUTERID ${CLUSTERID}-kuryr-service-subnet
  10. Kuryr サービスネットワークを削除するには、次のコマンドを入力します。

    (venv) $ openstack network delete ${CLUSTERID}-kuryr-service-network
  11. すべての Pod から Kuryr ファイナライザーを削除するには、次のコマンドを入力します。

    (venv) $ REMFIN pods kuryr.openstack.org/pod-finalizer
  12. すべての KuryrPort CR から Kuryr ファイナライザーを削除するには、次のコマンドを入力します。

    (venv) $ REMFIN kuryrports.openstack.org kuryr.openstack.org/kuryrport-finalizer

    このコマンドは KuryrPort CR を削除します。

  13. Kuryr ファイナライザーをネットワークポリシーから削除するには、次のコマンドを入力します。

    (venv) $ REMFIN networkpolicy kuryr.openstack.org/networkpolicy-finalizer
  14. 残りのネットワークポリシーから Kuryr ファイナライザーを削除するには、次のコマンドを入力します。

    (venv) $ REMFIN kuryrnetworkpolicies.openstack.org kuryr.openstack.org/networkpolicy-finalizer
  15. Kuryr が作成したサブポートをトランクから削除するには、次のコマンドを入力します。

    (venv) $ read -ra trunks <<< $(python -c "import openstack; n = openstack.connect().network; print(' '.join([x.id for x in n.trunks(any_tags='$CLUSTERTAG')]))") && \
    i=0 && \
    for trunk in "${trunks[@]}"; do
        i=$((i+1))
        echo "Processing trunk $trunk, ${i}/${#trunks[@]}."
        subports=()
        for subport in $(python -c "import openstack; n = openstack.connect().network; print(' '.join([x['port_id'] for x in n.get_trunk('$trunk').sub_ports if '$CLUSTERTAG' in n.get_port(x['port_id']).tags]))"); do
            subports+=("$subport");
        done
        args=()
        for sub in "${subports[@]}" ; do
            args+=("--subport $sub")
        done
        if [ ${#args[@]} -gt 0 ]; then
            openstack network trunk unset ${args[*]} $trunk
        fi
    done
  16. KuryrNetwork CR からすべてのネットワークとサブネットを取得し、ポート、ルーターインターフェイス、およびネットワーク自体を削除するには、次のコマンドを入力します。

    (venv) $ mapfile -t kuryrnetworks < <(oc get kuryrnetwork -A --template='{{range $i,$p := .items}}{{ $p.status.netId }}|{{ $p.status.subnetId }}{{"\n"}}{{end}}') && \
    i=0 && \
    for kn in "${kuryrnetworks[@]}"; do
        i=$((i+1))
        netID=${kn%%|*}
        subnetID=${kn##*|}
        echo "Processing network $netID, ${i}/${#kuryrnetworks[@]}"
        # Remove all ports from the network.
        for port in $(python -c "import openstack; n = openstack.connect().network; print(' '.join([x.id for x in n.ports(network_id='$netID') if x.device_owner != 'network:router_interface']))"); do
            ( openstack port delete $port ) &
    
            # Only allow 20 jobs in parallel.
            if [[ $(jobs -r -p | wc -l) -ge 20 ]]; then
                wait -n
            fi
        done
        wait
    
        # Remove the subnet from the router.
        openstack router remove subnet $ROUTERID $subnetID
    
        # Remove the network.
        openstack network delete $netID
    done
  17. Kuryr セキュリティーグループを削除するには、次のコマンドを入力します。

    (venv) $ openstack security group delete ${CLUSTERID}-kuryr-pods-security-group
  18. すべてのタグ付きサブネットプールを削除するには、次のコマンドを入力します。

    (venv) $ for subnetpool in $(openstack subnet pool list --tags $CLUSTERTAG -f value -c ID); do
        openstack subnet pool delete $subnetpool
    done
  19. KuryrNetwork CR に基づくすべてのネットワークが削除されたことを確認するには、次のコマンドを入力します。

    (venv) $ networks=$(oc get kuryrnetwork -A --no-headers -o custom-columns=":status.netId") && \
    for existingNet in $(openstack network list --tags $CLUSTERTAG -f value -c ID); do
        if [[ $networks =~ $existingNet ]]; then
            echo "Network still exists: $existingNet"
        fi
    done

    コマンドによって既存のネットワークが返された場合は、続行する前にそれらを調査して削除してください。

  20. ネットワークポリシーに関連するセキュリティーグループを削除するには、次のコマンドを入力します。

    (venv) $ for sgid in $(openstack security group list -f value -c ID -c Description | grep 'Kuryr-Kubernetes Network Policy' | cut -f 1 -d ' '); do
        openstack security group delete $sgid
    done
  21. KuryrNetwork CR からファイナライザーを削除するには、次のコマンドを入力します。

    (venv) $ REMFIN kuryrnetworks.openstack.org kuryrnetwork.finalizers.kuryr.openstack.org
  22. Kuryr ルーターを削除するには、次のコマンドを入力します。

    (venv) $ if $(python3 -c "import sys; import openstack; n = openstack.connect().network; r = n.get_router('$ROUTERID'); sys.exit(0) if r.description != 'Created By OpenShift Installer' else sys.exit(1)"); then
        openstack router delete $ROUTERID
    fi

26.7.4. 関連情報

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.