本リリース ノートには、次のトピックが含まれています。
|
VMware vSphere with Tanzu 8.0 | 2022 年 10 月 11 日 これらのリリース ノートへの追加や更新を確認してください。 |
vSphere with Tanzu 8.0 には、次の新機能および機能強化が含まれています。
ワークロード管理構成の監視
スーパーバイザーの有効化、無効化、およびアップグレードのステータスをより詳細に追跡できるようになりました。スーパーバイザーの有効化、無効化、またはアップグレードを開始すると、スーパーバイザーは、制御プレーン仮想マシンなどの各コンポーネントに関連付けられたさまざまな条件に到達することで、目的の状態への到達を試行します。各条件のステータスの追跡、関連する警告の表示、ステータスの再試行、到達した条件およびそのタイムスタンプの表示を行うことができます。
vSphere Zones
vSphere Zone は、アベイラビリティ ゾーンを vSphere クラスタに割り当てることができるようにする新しい構造です。複数の vSphere Zone にスーパーバイザーをデプロイすると、特定のアベイラビリティ ゾーンおよび障害ドメインに Tanzu Kubernetes Grid クラスタをプロビジョニングできます。これにより、複数のクラスタにわたってワークロードを実行することができ、ハードウェアとソフトウェアの障害に対する回復性が向上します。
マルチクラスタ スーパーバイザー
vSphere Zone を使用すると、スーパーバイザーを複数の vSphere クラスタにわたってデプロイし、Tanzu Kubernetes Grid クラスタに高可用性と障害ドメインを提供できます。このリリースは、Metro クラスタ環境を対象としていません。マルチクラスタ スーパーバイザーのユースケースでは、vSphere クラスタを単一の物理データセンター内の個別のラックに配置します。続いて、各 vSphere クラスタを個別の vSphere Zone に追加します。これにより、ローカライズされたハードウェアおよびソフトウェアの障害に対するフェイルオーバーと回復性が提供されます。ゾーン、ラック、または vSphere クラスタがオフラインになると、スーパーバイザーが障害を検出し、別の vSphere Zone でワークロードを再開します。
スーパーバイザーによる Kubernetes 1.23 のサポート
このリリースでは、Kubernetes 1.23 のサポートが追加され、Kubernetes 1.20 のサポートが廃止されます。このリリースでサポートされている Kubernetes のバージョンは、1.23、1.22、および 1.21 です。Kubernetes バージョン 1.20 で実行されているスーパーバイザーは、バージョン 1.21 に自動的にアップグレードされます。これにより、すべてのスーパーバイザーがサポートされているバージョンの Kubernetes で実行されるようになります。
SecurityPolicy CRD による一貫したネットワーク ポリシーの提供
SecurityPolicy カスタム リソース定義では、Kubernetes クラスタ内の仮想マシンとポッドの両方のネットワーク セキュリティ制御を構成できます。
vCenter Server の再起動中に DevOps ユーザーがボリューム操作またはステートフル アプリケーションのデプロイを開始すると、操作が失敗することがある
この問題は、ワークロード ストレージ管理ユーザー アカウントがロックされ、スーパーバイザーで実行される vSphere CSI プラグインが認証に失敗するために発生します。その結果、ボリューム操作が失敗し、InvalidLogin エラーが表示されます。
ログ ファイル /var/log/vmware/vpxd/vpxd.log には、次のメッセージが記録されます。
Authentication failed: The account of the user trying to authenticate is locked.:: The account of the user trying to authenticate is locked.:: User account locked: {Name: workload_storage_management-<id>, Domain: <domain>})
回避策：
アカウントのロック解除時間を取得します。
vSphere Client で、[管理] に移動し、[Single Sign-On] の下の [構成] をクリックします。
[ローカル アカウント] タブをクリックします。
[ロックアウト ポリシー] で、ロック解除時間（秒単位）を取得します。
kubectl 向けの vSphere プラグインを使用してスーパーバイザーで認証します。
kubectl vsphere login –server IP-ADDRESS --vsphere-username USERNAME
vmware-system-csi- 名前空間内の vsphere-csi-controller のデプロイの元のレプリカ数をメモします。
kubectl get deployment vsphere-csi-controller -n vmware-system-csi -o=jsonpath='{.spec.replicas}'
original-replica-count
vsphere-csi-controller のデプロイのレプリカ数をゼロにスケールダウンします。
kubectl scale --replicas=0 deployment vsphere-csi-controller -n vmware-system-csi
[ロック解除時間] に示されている秒数だけ待機します。
vsphere-csi-controller のデプロイのレプリカ数を元の値にスケールアップします。
kubectl scale --replicas=original-replica-count deployment vsphere-csi-controller -n vmware-system-csi
vSAN などの共有データストアから複数の FCD とボリュームを削除すると、パフォーマンスが変化する場合がある
このパフォーマンスの変化は、修正された問題が原因で発生する可能性があります。この問題が未修正の状態では、FCD の削除操作が失敗した後に、古い FCD とボリュームがデータストアに残っていました。
回避策：なし。パフォーマンスの変化に関係なく、通常どおりに削除操作を実行できます。
Tanzu Kubernetes Grid クラスタを含むスーパーバイザー名前空間を削除すると、スーパーバイザー内のパーシステント ボリュームの要求が終了中の状態のままになる場合がある
この問題が生じるのは、システムが名前空間を削除して、Tanzu Kubernetes Grid クラスタ内のポッドからボリュームを分離するときにリソースの競合が発生した場合です。
スーパーバイザー名前空間の削除は不完全なままになり、vSphere Client では名前空間が終了中の状態と表示されます。Tanzu Kubernetes Grid クラスタ内のポッドに関連付けられたパーシステント ボリュームの要求も終了中の状態のままになります。
次のコマンドを実行すると、「Operation cannot be fulfilled on persistentvolumeclaims」というエラーが表示されます。
kubectl vsphere login --server=IP-ADDRESS --vsphere-username USERNAME
kubectl logs vsphere-csi-controller-pod-name -n vmware-system-csi -c vsphere-syncer
failed to update PersistentVolumeClaim: \\\"<pvc-name>\\\" on namespace: \\\"<supervisor-namespace>\\\".エラー：Operation cannot be fulfilled on persistentvolumeclaims \\\"<pvc-name>\\\": the object has been modified; please apply your changes to the latest version and try again\
回避策：
次のコマンドを使用して、問題を修正します。
kubectl vsphere login --server=IP-ADDRESS --vsphere-username USERNAME
kubectl patch pvc <pvc-name> -n <supervisor-namespace> -p '{"metadata":{"finalizers":[]}}' --type=merge
クラスタのキャパシティを超えるリソース制限を持つセルフサービス名前空間テンプレートを vSphere 管理者が構成すると、アラートがトリガされない
vSphere 管理者がクラスタのキャパシティを超えるリソースの制限を構成すると、DevOps エンジニアはそのテンプレートを使用して、リソースの多い vSphere Pod をデプロイする場合があります。その結果、ワークロードが失敗することがあります。
回避策：なし
vCenter Server と vSphere with Tanzu のアップグレード後、クラスタのノードに接続されていると表示されるボリュームが原因で、Tanzu Kubernetes Grid クラスタがアップグレードを完了できない
Tanzu Kubernetes Grid クラスタのアップグレードに失敗すると、ボリュームがクラスタのノードに接続されていると表示され、クリアされないことがあります。この問題は、アップストリーム Kubernetes の問題が原因で発生する可能性があります。
回避策：
次のコマンドを使用して、スケジュール設定が無効になっている TKG クラスタ ノードに関する情報を取得します。
kubectl get node tkc_node_name -o yaml
例：
# kubectl get node gcm-cluster-antrea-1-workers-pvx5v-5b9c4dbcc7-28p95 -o yaml
apiVersion: v1
kind: Node
metadata:
annotations:
cluster.x-k8s.io/cluster-name: gcm-cluster-antrea-1
cluster.x-k8s.io/cluster-namespace: c1-gcm-ns
cluster.x-k8s.io/machine: gcm-cluster-antrea-1-workers-pvx5v-5b9c4dbcc7-28p95
cluster.x-k8s.io/owner-kind: MachineSet
cluster.x-k8s.io/owner-name: gcm-cluster-antrea-1-workers-pvx5v-5b9c4dbcc7
csi.volume.kubernetes.io/nodeid: '{"csi.vsphere.vmware.com":"gcm-cluster-antrea-1-workers-pvx5v-5b9c4dbcc7-28p95"}'
kubeadm.alpha.kubernetes.io/cri-socket: /run/containerd/containerd.sock
node.alpha.kubernetes.io/ttl: "0"
volumes.kubernetes.io/controller-managed-attach-detach: "true"
….
….
volumesAttached:
- devicePath: ""
name: kubernetes.io/csi/csi.vsphere.vmware.com^943bd457-a6cb-4f3d-b1a5-e301e6fa6095-59c73cea-4b75-407d-8207-21a9a25f72fdstatus.volumeAttached プロパティで、このノードに vSphere CSI ボリュームがあるかどうかを確認します。ボリュームがある場合は、次の手順に進みます。
手順 1 で特定したノードでポッドが実行されていないことを確認します。次のコマンドを使用します。
kubectl get pod -o wide | grep tkc_node_name
例：
kubectl get pod -o wide | grep gcm-cluster-antrea-1-workers-pvx5v-5b9c4dbcc7-28p95このコマンドの出力が空の場合は、ポッドがないことを示します。手順 1 の出力には、ポッドがないノードに接続されているボリュームが表示されているため、次の手順に進みます。
すべてのノード オブジェクトに関する情報を取得して、同じボリュームが別のノードに接続されていることを確認します。
kubectl get node -o yaml
例：
同じボリューム名が 2 つの TKG クラスタ ノード オブジェクトに表示されます。
On old node - "gcm-cluster-antrea-1-workers-pvx5v-5b9c4dbcc7-28p95"
volumesAttached:
- devicePath: ""
name: kubernetes.io/csi/csi.vsphere.vmware.com^943bd457-a6cb-4f3d-b1a5-e301e6fa6095-59c73cea-4b75-407d-8207-21a9a25f72fd
On new node "gcm-cluster-antrea-1-workers-pvx5v-84486fc97-ndh88"
volumesAttached:
- devicePath: ""
name: kubernetes.io/csi/csi.vsphere.vmware.com^943bd457-a6cb-4f3d-b1a5-e301e6fa6095-59c73cea-4b75-407d-8207-21a9a25f72fd
...
volumesInUse:
- kubernetes.io/csi/csi.vsphere.vmware.com^943bd457-a6cb-4f3d-b1a5-e301e6fa6095-59c73cea-4b75-407d-8207-21a9a25f72fd
...ボリューム名のボリューム ハンドルに基づいて PV を検索します。
上記の例では、ボリューム名は kubernetes.io/csi/csi.vsphere.vmware.com^943bd457-a6cb-4f3d-b1a5-e301e6fa6095-59c73cea-4b75-407d-8207-21a9a25f72fd です。ボリューム ハンドルは 943bd457-a6cb-4f3d-b1a5-e301e6fa6095-59c73cea-4b75-407d-8207-21a9a25f72fd です。
次のコマンドを使用して、すべての PV を取得し、上記のボリューム ハンドルを検索します。
kubectl get pv -o yaml
上記の例では、そのボリューム ハンドルを使用する PV は pvc-59c73cea-4b75-407d-8207-21a9a25f72fd です。
volumeattachment コマンドを使用して、前の手順で見つかった PV を検索します。
kubectl get volumeattachment | grep pv_name
例：
# kubectl get volumeattachment | grep pvc-59c73cea-4b75-407d-8207-21a9a25f72fd
NAME ATTACHER PV NODE ATTACHED AGE
csi-2ae4c02588d9112d551713e31dba4aab4885c124663ae4fcbb68c632f0f46d3e csi.vsphere.vmware.com pvc-59c73cea-4b75-407d-8207-21a9a25f72fd gcm-cluster-antrea-1-workers-pvx5v-84486fc97-ndh88 true 3d20hノード gcm-cluster-antrea-1-workers-pvx5v-5b9c4dbcc7-28p95 ではなく、ノード gcm-cluster-antrea-1-workers-pvx5v-84486fc97-ndh88 に接続されているボリューム接続を確認できます。これは、gcm-cluster-antrea-1-workers-pvx5v-5b9c4dbcc7-28p95 の status.volumeAttached が正しくないことを示します。
古い volumeAttached エントリをノード オブジェクトから削除します。
kubectl edit node tkc_node_name
例：
kubectl edit node gcm-cluster-antrea-1-workers-pvx5v-5b9c4dbcc7-28p95
古いボリューム エントリを status.volumeAttached から削除します。
status.volumeAttached プロパティで、すべての古いボリュームに対して上記の手順を繰り返します。
WCPMachines がまだ存在する場合は手動で削除し、数分間待ってからクラスタを調整します。
# kubectl get wcpmachines -n c1-gcm-ns
NAMESPACE NAME ZONE PROVIDERID IPADDR
c1-gcm-ns gcm-cluster-antrea-1-workers-jrc58-zn6wl vsphere://423c2281-d1bd-9f91-0e87-b155a9d291a1 192.168.128.17
# kubectl delete wcpmachine gcm-cluster-antrea-1-workers-jrc58-zn6wl -n c1-gcm-ns
wcpmachine.infrastructure.cluster.vmware.com "gcm-cluster-antrea-1-workers-jrc58-zn6wl" deleted