VMware Integrated OpenStack 7.0.1 | 2020 年 11 月 19 日 | ビルド 17200834

リリース ノートに追加または更新された内容をご確認ください。

リリース ノートの概要

このリリース ノートには、次のトピックが含まれています。

VMware Integrated OpenStack について

VMware Integrated OpenStack は、統合プロセスを効率化することで、OpenStack クラウド インフラストラクチャのデプロイを大幅に簡略化します。VMware Integrated OpenStack には事前設定なしですぐに使用できる OpenStack 機能と、vCenter Server で仮想アプライアンスとして稼動するデプロイ マネージャの vApp を介した簡単な構成ワークフローが備わっています。

新機能

  • 最新バージョンの VMware 製品のサポート:VMware Integrated OpenStack 7.0.1 は、VMware vSphere 7.0u1、NSX-T Data Center 3.1 および NSX Data Center for vSphere 6.4.8 をサポートしており、これらと完全な互換性があります
  • 新機能と機能拡張:
    • ステートフル DHCPv6 のサポート:データ プレーンでの IP アドレスの指定に、SLAAC と DHCPv6 のいずれかを選択できるようになりました。この機能を利用するには、Neutron Policy Plugin と NSX-T 3.1 が必要です。
    • Neutron ポートの allowed-address-pairs 設定における IP アドレスの CIDR 形式のサポート。この機能を利用するには、Neutron Policy Plugin と NSX-T 3.1 が必要です。
  • アップグレード手順の向上:
    • VMware Integrated OpenStack 5.1 デプロイに FWaaS v1 が有効になっているファイアウォールが含まれている場合、バージョン 7.0.1 に直接アップグレードできます。FWaaS v1 は自動的に FWaaS v2 に移行されます。

バージョン 7.0.1 へのアップグレード

VMware Integrated OpenStack 7.0.1 にアップグレードするには、viocli patch コマンドを使用してパッチを適用します。

既存の VMware Integrated OpenStack 7.0 デプロイにパッチを適用することも、デプロイなしで VMware Integrated OpenStack 7.0 OVA にパッチを適用することもできます。パッチは、次のシナリオに適用されます。

パッチ適用の手順については、『VMware Integrated OpenStack のインストールおよび構成ガイド』の「VMware Integrated OpenStack 7.0.1 パッチの適用」を参照してください。

互換性

非推奨に関する通知 

  • Neutron FWaaSv2 は以降のバージョンで廃止される予定です。
  • 次のネットワーク機能は廃止されています。以降のリリースで削除される予定です。
    • Neutron 用の NSX Data Center for vSphere ドライバ。
    • NSX-T Management Plugin for Neutron は、NSX-T Policy Plugin に置き換えられます。
    • TVD プラグイン。単一の VMware Integrated OpenStack デプロイで、NSX Data Center for vSphere バックエンドと NSX-T Data Center バックエンドを使用できます。

利用可能な言語

VMware Integrated OpenStack は英語、および簡体字中国語、繁体字中国語、日本語、韓国語、フランス語、ドイツ語、スペイン語の 7 つの追加言語でご利用になれます。

次の項目には ASCII 文字のみを含める必要があります。

  • OpenStack リソース(プロジェクト、ユーザー、イメージなど)の名前
  • インフラストラクチャ コンポーネント(ESXi ホスト、ポート グループ、データセンター、データストアなど)の名前
  • LDAP および Active Directory の属性 

VMware Integrated OpenStack 用オープン ソース コンポーネント

VMware Integrated OpenStack で配布されるオープン ソース ソフトウェア コンポーネントに適用される著作権情報とライセンスは、製品ダウンロード ページの [オープン ソース] タブで入手できます。VMware Integrated OpenStack のコンポーネントの公開パッケージをダウンロードすることもできます。これらのコンポーネントは GPL、LGPL、または他の同様なライセンスで管理されており、ライセンスに沿ってソース コードまたはソース コードの変更内容を公開する必要があります。

解決した問題

解決された問題には、次のトピックが含まれます。

    アップグレード

    次のアップグレードの問題は、今回のリリースで修正されました。

    • VMware Integrated OpenStack 5.x から 7.0 へのアップグレードが LDAP 構成によって失敗する。

      LDAP が構成され、Active Directory ドメイン名がドメイン情報なしで設定されている場合、アップグレード スクリプトが失敗します。

    • 大規模環境で VMware Integrated OpenStack 5.x から 7.0 へのアップグレードが失敗する。

      大規模環境で VMware Integrated OpenStack 5.x から 7.0 にアップグレードすると、vCenter Server の検出サービスが失敗し、次のエラー メッセージが表示されます:「要求エンティティが大きすぎます: 制限は 3145728 です」。

    • バージョン 5.x で作成したファイアウォールが VMware Integrated OpenStack 7.0 への直接アップグレード後に表示されない

      VMware Integrated OpenStack 5.x は FWaaS v1 を使用します。VMware Integrated OpenStack 7.0 は FWaaS v2 を使用します。アップグレード前の FWaaS v1 から FWaaS v2 への移行は不要になりました。

    • 複数の操作を同時に実行すると Neutron サービスが ToozConnectionError を報告する

      NSX-V プラグインを使用して VMware Integrated OpenStack 5.x から 7.0 にアップグレードした後、ネットワーク関連の操作を実行すると、特に複数の操作が同時に実行されている期間に、Neutron サービスが ToozConnectionError を報告します。

      この問題は本リリースで修正されていますが、引き続き neutron-server レプリカ番号を 1 に設定する必要があります。

    • VMware Integrated OpenStack 7.0 へのアップグレード後、次のエラーで Heat スタックがデプロイに失敗する:AuthorizationFailure

      VMware Integrated OpenStack 5.x から 7.0 にアップグレードした後、次のエラーで Heat スタックがデプロイに失敗します:AuthorizationFailure。これは、heat.conf ファイルに構成されているユーザー認証情報が引き継がれないためです。

    • keystone.conf の一部の認証方法がアップグレード中に引き継がれない。

      「application_credential」などのサポートされていない認証方法は、VMware Integrated OpenStack 5.1 から VMware Integrated OpenStack 7.0 へのアップグレード中に引き継がれません。

    • VMware Integrated OpenStack 7.0 へのアップグレード後、Neutron 割り当て詳細への要求が失敗する。

      VMware Integrated OpenStack 5.x で loadbalancer 関連割り当てを設定した場合、VMware Integrated OpenStack 7.0 へのアップグレード後に Neutron 割り当てを要求できません。

    一般

    次の一般的な問題は、今回のリリースで修正されました。

    • NSX-T Edge ID が nsx_id と異なる場合、VMware Integrated OpenStack 7.0 のデプロイが失敗する。

      Edge ID と NSX ID の値が異なる場合、新しい VMware Integrated OpenStack 7.0 のデプロイが NSX-T 2.5.1 での Neutron サーバ エラー「vmware_nsxlib.v3.exceptions.ResourceNotFound: リソースがバックエンドで見つかりませんでした」で失敗します。

    • 仮想デバイスのロールのタグ付けで正しい値が返されない。

      タグ付けされたデバイスのハードウェア アドレスは、metaData サービスから正しく返されません。

    • データベース ポッドの再起動後に整合性のないデータが表示される

      データベース ポッドが再起動されると、1 つ以上のポッドがリーダー ノードであると表示されることがあります。これらのポッドは単一のクラスタを形成しません。

    • 仮想マシンがルーター IPv6 ゲートウェイにアクセスできない。

      VMware Integrated OpenStack 7.0 環境に NSX-V 6.4.8 があると、仮想マシンはルーター IPv6 ゲートウェイにアクセスできません。

    • LatencySensitivity が「高」の仮想マシンを作成すると、プロパティ「ethernetx.cTxPerDev」が「1」に設定される

      LatencySensitivity が「高」の仮想マシンを作成する場合、cTxPerDev は自動的に「1」に設定されません。
      cTxPerDev の設定は、「hw:vifs_multi_thread」プロパティに合わせて行う必要があります。

    • Horizon のユーザー インターフェイスを日本語で表示できない

      エンド ユーザーは、言語設定を変更した後でも Horizon で日本語のユーザー インターフェイスを表示できません。

    • 「viocli delete deployment」コマンドを実行すると、vCenter Server のコンテンツ ライブラリに保存されているバックアップ ファイルが削除される

      コマンド viocli delete deployment を実行すると、警告メッセージが表示されずに vCenter Server のコンテンツ ライブラリに保存されたバックアップ ファイルが削除されます。現在では、コマンドを実行すると警告メッセージが表示され、管理者が確認した後に削除が実行されるようになりました。

    • vCenter Server の instanceUuid に大文字が含まれている場合、GUI を使用した OpenStack のデプロイが失敗する。

      GUI を使用して OpenStack をデプロイする際に、vCenter Server の instanceUuid に大文字が含まれていると、生成される Nova コンピューティング名に大文字が含まれ、VMware Integrated OpenStack のデプロイが失敗します。Kubernetes では大文字を含む名前は利用できないため、Nova コンピューティング CR を作成できません。

    • VMware Integrated OpenStack 6.0 または 7.0 デプロイで、VIP 経由の Heat オートスケール URL へのアクセスが失敗する

      VIP 経由の Heat オートスケール URL へのアクセスが次の SSLError で失敗します:「証明書を検証できませんでした」

    • Heat スタックが次のエラーで失敗する:DesignateClientPlugin object has no attribute _get_service_name.

      Heat スタック(ポートとレコードセットを作成)が次のエラーで失敗します:
      ERROR: Property error: : resources.ha_proxy_vip_shared_dns.properties.zone: : 'DesignateClientPlugin' object has no attribute '_get_service_name'.

    • RBAC が設定されたネットワークで loadbalancer を作成できない

      RBAC が設定されたネットワークで LB を作成しようとすると、次のようなエラーで失敗します:「create failed: No details.: DriverError: Driver error: Router 9e7c00b4-1e96-44fc-bcc5-ab9a7a9ef334 could not be found」

    • ロード バランサの作成時に、Neutron で次のドライバ エラーが報告される:lbaas-listener 要求が正しくありません。NSX バックエンドで仮想サーバの作成に失敗しました。​

      Neutron で次のドライバ エラーが報告されます:「lbaas-listener 要求が正しくありません: NSX バックエンドで仮想サーバの作成に失敗しました。」​これは、複数のリスナーに同じ証明書がある場合に発生します。

    • Octavia LB の削除が --cascade オプションで失敗する

      「--cascade」オプションで Octavia ロード バランサを削除すると、ロード バランサが「PENDING_DELETE」の状態のままになります。

    • DVS プラグインを使用したデプロイで、許可されたアドレス ペアによる Neutron ポートの作成が失敗し、UnboundLocalError がログに記録される。

      DVS プラグインを使用した VMware Integrated OpenStack 7.0 デプロイで、許可されたアドレス ペアで Neutron ポートを作成すると、API 呼び出しが HTTP/500 エラーで失敗することがあります。Neutron ログには、次の形式の例外が表示されます:「POST failed.: UnboundLocalError: local variable 'port_security' referenced before assignment」この問題は、Python 2.7 から Python 3.7 への切り替えのため、VMware Integrated OpenStack 7.0 で変数の範囲に関する例外が導入されたことが原因で発生します。この問題は、DVS プラグインのみに影響します。

    • NSX-V プラグインで、nsxv_use_routers_as_lbaas_platform フラグが有効な場合、ロードバランサを削除するとサービス エッジで conntrack テーブルがフラッシュされる。

      上記のシナリオでロードバランサを削除すると、LBaaSv2 ドライバによって仮想 IP アドレスがサービス エッジ アプライアンスから削除されます。
      これにより、エッジの conntrack テーブルがフラッシュされます。エッジがその他のロードバランサ オブジェクトをホストしている場合、これらのロードバランサへの接続が切断されます。

    • vRealize Log Insight 8.1.1 以降へのログ転送が機能しないことがある

      バージョン 8.1.1 以降、vRealize Log Insight では VMware Integrated OpenStack 7.0 でログ転送に使用されるポート 9000 で SSL 接続がデフォルトで有効になっています。ただし、VMware Integrated OpenStack 7.0 ではこのポートが HTTP エンドポイントと見なされるため、vRealize Log Insight 8.1.1 では現在、VMware Integrated OpenStack ログを受信できません。この問題を解決するために、VMware Integrated OpenStack 7.0.1 では、Web クライアントから vRealize Log Insight ポート 9543 を HTTPS エンドポイントとして使用するための方法を提供しています。ポート 9000 を引き続き HTTP エンドポイントとして使用する場合、vRealize Log Insight 8.1.1 以降では [SSL 接続] を無効にします。

    • Cinder バックアップ サービスが正常に起動および実行されない。

      「rpc.statd が実行中ですが、リモート ロックに必要です」というエラーにより、Cinder-backup ポッドでバックアップ NFS をマウントできません。

    既知の問題

    既知の問題には、次のトピックが含まれます。

      アップグレード

      アップグレードの実行前に、次の問題を考慮する必要があります。
      • VMware Integrated OpenStack 5.x から 7.0 へのアップグレード後、Horizon の操作でログイン画面に繰り返しリダイレクトされる

        アップグレード後、Horizon ポッドまたは Ingress ポッドで次のような問題が発生することがあります。ポッドを再作成すると、機能は通常の状態に復元されます。

        回避策:次の手順を実行して、Horizon ポッドまたは Ingress ポッドを再作成します。

        1. 管理仮想マシンに SSH 接続します。
        2. Horizon ポッドを再作成するには、次のコマンドを使用します。
          kubectl get pods -n openstack|grep horizon-server| awk '{print $1}'|xargs kubectl -n openstack delete pod 
        3. Ingress ポッドを再作成するには、次のコマンドを使用します。
          kubectl get pods -n openstack|grep '^ingress' | awk '{print $1}'|xargs kubectl -n openstack delete pod
      • コンピューティング クラスタを含まない vCenter Server インスタンスは、アップグレード中に保持されない

        VMware Integrated OpenStack 5.1 デプロイに vCenter Server インスタンスが含まれていて、そのインスタンスからデプロイに追加されたコンピューティング ノードがない場合、VMware Integrated OpenStack 7.0 にアップグレード後、vCenter Server インスタンスに関するこれらの設定は保持されません。

        回避策:アップグレードの終了後に、目的の vCenter Server インスタンスを VMware Integrated OpenStack 7.0 デプロイに追加します。

      • ロード バランサを Neutron-LBaaS から Octavia に移行すると、メンバーのないロード バランサが表示されない

        メンバーのないロード バランサは使用されないため、移行されません。バックエンドの実装がないため、Neutron データベースの同期中に表示されなくなります。

        回避策:移行前に、使用されていないロード バランサを削除します。

      • VMware Integrated OpenStack 5.1.0.4 からのアップグレード後も、古い Nova サービスが存在している

        VMware Integrated OpenStack 7.0 へのアップグレード後に、5.1.0.4 からのレガシー Nova サービスが「down」になっています。

        [root@vioadmin1-vioshim-5dbf477dc4-2lh7s ~]# nova service-list
        +---------------------------------------------------------------------------
        | Id | Binary | Host | Zone | Status | State 
        | Updated_at | Disabled Reason | Forced down 
        |+--------------------------------------------------------------------------
        | cbe3345a-4daa-41fa-8133-60302e369533 | nova-conductor | controller02 | internal | enabled | down 
        | 2020-04-29T14:58:20.000000 | - | False |
        | cb2ebf3c-53e1-493b-979e-471a1bd2e3b9 | nova-conductor | controller01 | internal | enabled | down 
        | 2020-04-29T14:58:20.000000 | - | False |
        | 669d979a-26a2-4b85-a139-a6705a3b04f8 | nova-scheduler | controller02 | internal | enabled | down 
        | 2020-04-29T14:58:23.000000 | - | False |
        | f97b8c40-ab45-4e9c-ac3d-675f1600d5ad | nova-scheduler | controller01 | internal | enabled | down 
        | 2020-04-29T14:58:23.000000 | - | False |
        | 39312d81-841e-4399-b178-f9b7d47eba1b | nova-consoleauth | controller02 | internal | enabled | down 
        | 2020-04-29T14:58:17.000000 | - | False |
        | 793480c6-6503-4fc2-a89e-fe20a3700efb | nova-consoleauth | controller01 | internal | enabled | down 
        | 2020-04-29T14:58:16.000000 | - | False |
        |04T05:15:54.000000 | - | False |

        回避策:「down」状態のサービスを削除します。

        1. Nova CR を更新します。
          viocli update nova nova-xxx
        2. manifests パラメータに cron_job_service_cleaner: true を設定します。以下に例を示します。
          conf:
            nova:
              neutron:
                metadata_proxy_shared_secret: .Secret:managedencryptedpasswords:data.metadata_proxy_shared_secret
              vmware:
                passthrough: "false"
                tenant_vdc: "false"
          manifests: 
            cron_job_service_cleaner: true
        3. CR を保存し、すべての Nova ポッドが再作成されるまで待機します。

        約 1 時間後、cronjob により「down」状態のすべてのサービスが削除されます。

      • VMware Integrated OpenStack 7.0 へのアップグレード後、NSX-V 環境でメタデータ サービスにアクセスできなくなる。

        NSX-V プラグインを使用して VMware Integrated OpenStack 5.x から 7.0 にアップグレードすると、メタデータ プロキシ エッジが VMware Integrated OpenStack API ネットワークからルーティング可能でない場合はメタデータ サービスにアクセスできません。

        回避策:各コントローラ ノードにログインして、eth0 NIC を介したゲートウェイ経由でルートをメタデータ プロキシ サービスに追加します。

        1. コントローラ ノードを一覧表示します。
          osctl get nodes
        2. 各コントローラ ノードにログインします。
          viossh <CONTROLLER_NODE_NAME>
        3. ルートをメタデータ プロキシ サービスに追加します。
          sudo ip route add <metadata_proxy_ip1> via <metadata_proxy_gateway> dev eth0
          sudo ip route add <metadata_proxy_ip2> via <metadata_proxy_gateway> dev eth0
      • VMware Integrated OpenStack 5.1 からのアップグレード後、LDAP ユーザーがログインできない

        VMware Integrated OpenStack 5.1 からのアップグレード後、LDAP ユーザーが VMware Integrated OpenStack 7.0 にログインできません。

        回避策:VMware Integrated OpenStack 5.1 のリリース後、Keystone Community のコードで変更が実行されています。この問題を回避するには、ユーザー データベースを更新する必要があります。ナレッジベースの記事 KB79373 を参照してください。

      • 指定コンポーネントが VMware Integrated OpenStack 5.x で有効になっている場合、7.0 へのアップグレード後に VMware Integrated OpenStack 5.x で作成されたゾーンを更新できない

        VMware Integrated OpenStack 5.x の指定コンポーネントのアーキテクチャは、VMware Integrated OpenStack 7.0 のアーキテクチャと異なります。VMware Integrated OpenStack 5.x で、指定ゾーンのマスター IP アドレスは、ロード バランサ ノードのパブリック IP アドレスに対応します。ただし、VMware Integrated OpenStack 7.0 へのアップグレード後、7.0 テスト ベッドではロード バランサ ノードのパブリック IP アドレスが使用されないため、ゾーンではそのマスター IP アドレスに対し AXFR 要求を行うことができません。

        回避策:5.x で作成されたゾーンのマスター IP アドレスをパブリック VIP に手動で更新します。以下の手順は、bind9 バックエンドでアップデートを実行する方法を示しています。bind9 サーバで modzone 操作がサポートされている必要があります。

        1. designate-worker-XXXXX ポッドを選択し、ログインします。
          osctl exec -it designate-worker-XXXXX bash
        2. VMware Integrated OpenStack 5.1 で作成された指定ゾーンに関する情報を取得します。以下の例では、bind9 サーバの IP アドレスは 192.168.111.254 で、指定ゾーンは test.com です。
          rndc -s 192.168.111.254 -p 953 -k /etc/designate/rndc.key showzone test.com.
          zone "test.com" { type slave; file "slave.test.com.1b10d5ec-e39c-449d-b1e1-c7bf1fba02e5"; masters { 192.168.112.162 port 5354; 192.168.112.163 port 5354;}; }; 
        3. 指定ゾーンのマスター IP アドレスを VMware Integrated OpenStack 7.0 のパブリック VIP に更新します。以下の例では、VMware Integrated OpenStack 7.0 のパブリック VIP は 192.168.112.160 です。
          rndc -s 192.168.111.254 -p 953 -k /etc/designate/rndc.key modzone test.com '{ type slave; file "slave.test.com.1b10d5ec-e39c-449d-b1e1-c7bf1fba02e5"; masters { 192.168.112.160 port 5354; }; };'

      一般的な問題

       

      • パブリック API のレート制限を使用できない

        VMware Integrated OpenStack 7.0 では、パブリック API にレート制限を適用できません。

        回避策:なし。この機能は、この後のバージョンで提供されます。

      • VMware Integrated OpenStack 7.0 にアップグレードした後、デフォルトのプールを既存の LBaaS リスナーに追加することができない

        VMware Integrated OpenStack 5.1 では、LBaaS リスナーのデフォルトのプールの変更はサポートされていません。この機能は、VMware Integrated OpenStack 7.0 でサポートされています。ただし、デフォルトのプールを持たない VMware Integrated OpenStack 5.1 で LBaaS リスナーを作成すると、VMware Integrated OpenStack 7.0 にアップグレードした後でも、リスナーにデフォルトのプールを追加することはできません。

        回避策:影響を受けるリスナーを削除し、再度作成します。

      • ルーターに接続されていないプライベート サブネットを使用してロード バランサを作成すると、エラー状態になる

        MP プラグインや Policy Plugin などの Neutron NSX-T プラグインでは、ルーターに接続されていないプライベート サブネットを使用してロード バランサを作成すると、ロード バランサにエラーが発生しますが、エラーがユーザーに報告されません。

        回避策:ルーターに接続されているサブネットを使用してロード バランサを作成します。

      • 一部のファイアウォール グループ、ポリシー、ルールが、Horizon ファイアウォール ダッシュボードに表示されない

        Horizon ファイアウォール ダッシュボードは、共有フラグが true または false に設定されたファイアウォール グループ、ポリシー、ルールを表示するように設計されています。共有フラグが未設定の場合、ファイアウォール グループ、ポリシー、ルールは表示されません。

        回避策:OpenStack CLI では共有フラグの設定が必須ではないため、OpenStack CLI を使用してファイアウォール グループ、ポリシー、ルールをリストできます。または、Horizon ファイアウォール ダッシュボード内の共有フラグが未設定のすべてのレコードについて、値をゼロまたは false に更新することができます。論理的には、false は未設定と等価です。例:

        update firewall_groups_v2 set shared=0 where shared is NULL;
        update firewall_policies_v2 set shared=0 where shared is NULL;
        update firewall_rules_v2 set shared=0 where shared is NULL;

      • イメージを Glance にアップロードすると、完了する前にタイムアウトになる

        Horizon または CLI のいずれかを使用している場合、サイズの大きいイメージを Glance にアップロードすると、完了する前にタイムアウトになることがあります。

        • Horizon ユーザー インターフェイスを使用している場合は、イメージは Horizon の一時フォルダにアップロードされてから Glance にアップロードされます。Horizon のセッションの時間制限は 1 時間です。アップロード操作が 1 時間以内に完了しなかった場合、セッションは終了し、イメージのアップロード プロセスは中止されます。
        • CLI を使用している場合は、イメージは glance-api の作業フォルダにアップロードされます。このフォルダでは、イメージの形式が変換されることがあります。その後、イメージは Glance データストアに転送されます。イメージが大きすぎる場合、プロセスはタイムアウトになり、中止されることがあります。

        回避策:余分なステップである Horizon の一時フォルダへのアップロードを削除してアップロード時間を短縮するには、CLI を使用してイメージをアップロードします。サイズの大きいイメージの場合、CLI を実行しているクライアントからアクセス可能な Web サーバに配置してから、glance async import コマンドを使用してイメージをアップロードします。https://docs.openstack.org/python-glanceclient/latest/cli/details.html#glance-task-create を参照してください。

        たとえば、以下のコマンドを使用して、URL からイメージをインポートできます:https://raw.githubusercontent.com/arnaudleg/openstack-cli-tests/master/files/cirros-0.3.0-i386-disk.vmdk:

        glance task-create --type import --input '{"import_from_format": "vmdk", "import_from": "https://raw.githubusercontent.com/arnaudleg/openstack-cli-tests/master/files/cirros-0.3.0-i386-disk.vmdk", "image_properties": {"name": "cirros-imported", "disk_format": "vmdk", "container_format": "bare", "vmware_adaptertype": "ide", "vmware_disktype": "streamOptimized", "vmware_ostype": "otherGuest"}}'

      • ポッドが保留の状態に移行する。VMware Integrated OpenStack 管理サーバまたはコントローラのステータスが「準備ができていません」に変わる。

        この状況は、VMware Integrated OpenStack 管理サーバとコントローラ仮想マシンでのリソースの競合が原因で発生します。kubelet が適切な時間内にタスクを完了できない場合、Kubernetes ノードに「準備ができていません」とマークされます。Kubernetes は、使用可能な他のノードにポッドを再度スケジュール設定します。他のノードが使用できない場合、ポッドは保留の状態になります。コンパクトなセットアップでは、単一ノードでのポッドの集約度の高さに比例して、この問題に対してより脆弱になります。

        回避策:Kubernetes ノードのステータスを「準備ができていません」から「準備完了」に変更するには、systemctl restart kubelet を使用して kubelet サービスを再起動します。この問題に永続的に対処するには、スケールアウトしてコントローラ ノードを追加し、各ノードの負荷を軽減します。

      • OpenStack のデプロイ時に誤った認証情報を入力すると、ウィザードは正しい認証情報を認識できないことがある

        OpenStack のデプロイ プロセスで、vCenter Server または NSX Manager の認証情報を正しく入力しなかった場合、ウィザードは正しい認証情報を認識できないことがあります。誤った情報を削除して、正しい認証情報を入力しても、ウィザードは検証に失敗することがあります。

        回避策:デプロイ ウィザードを閉じて、もう一度開きます。

      • セキュリティ グループの IPv4 アドレス ブロックとして CIDR 0.0.0.0/x を使用すると、NSX-V バックエンドで「any」に変換される

        セキュリティ グループ ルールに CIDR 0.0.0.0/x(x > 0、x < = 32)が設定されている場合、VMware Integrated OpenStack プラグインによって NSX-V バックエンドで「any」に変換されます。これは、IPv6 で ::/x(x>0、x<=128)を使用してセキュリティ グループ ルールを設定した場合にも適用されます。

        回避策:0.0.0.0/x または ::/x アドレス ブロックは使用しないでください。

      • デフォルトのリポジトリの場所が、Photon OS 3.0 で変更される

        VMware Integrated OpenStack 7.0 では、Photon OS 3.0 が LCM およびコントローラ仮想マシンの OS として使用されます。デフォルトのリポジトリの場所は、2020 年 11 月 25 日に bintray.com から packages.vmware.com に変わります。この変更は、tdnf コマンドでインストールされたソフトウェア パッケージに影響します。

        回避策:Bintray のすべてのパッケージは、packages.vmware.com で使用できます。パッケージにアクセスするには、デフォルトのリポジトリの場所を新しいリポジトリに変更します。詳細については、こちらを参照してください。

      check-circle-line exclamation-circle-line close-line
      Scroll to top icon