この文書は自動機械翻訳技術を使用して翻訳されています。正確な翻訳を提供するように努めておりますが、翻訳された内容の完全性、正確性、信頼性については一切保証いたしません。相違がある場合は、元の英語版英語が優先され、正式なテキストとなります。

ウィットネスノード

SUSE Virtualization 本番環境にデプロイされたクラスターは、ノードとポッドの管理のためにコントロールプレーンを必要とします。典型的な三ノードクラスターには、各々がコントロールプレーンコンポーネントの完全なセットを含む三つの管理ノードがあります。重要なコンポーネントの一つはetcdで、Kubernetesはそのデータ（設定、状態、メタデータ）を保存するためにetcdを使用します。etcdノードの数は常に奇数でなければなりません（例えば、SUSE Virtualizationではデフォルトの数は3です）。これは定足数が維持されることを保証するためです。

いくつかの状況では、管理ノードにワークロードやユーザーデータをデプロイすることを避ける必要があるかもしれません。これらの状況では、1つのクラスターノードに_witness_の役割を割り当てることができ、etcdクラスターのメンバーとして機能することに制限されます。ウィットネスノードは、メンバーの定足数（ノードの過半数）を確立する責任があり、クラスターの状態に対する更新に同意する必要があります。

ウィットネスノードはデータを保存しませんが、etcdノードのためのハードウェア推奨事項は依然として考慮されるべきです。リソースが限られたハードウェアを使用すると、クラスターのパフォーマンスに大きな影響を与えます。これは、記事遅いetcdパフォーマンス（パフォーマンステストと最適化）で説明されています。

SUSE Virtualization は、二つの管理ノードと一つのウィットネスノード（オプションで1つ以上のワーカーノード）を持つクラスターをサポートします。ノードの役割の詳細については、役割管理を参照してください。

ノードは、クラスターに参加する際にのみ_witness_の役割を割り当てることができます。各クラスターにはウィットネスノードを1つしか持たせることができません。

ウィットネスノード付きのSUSE Virtualizationクラスターの作成

新しく作成されたクラスターに参加する際に、ノードに_witness_の役割を割り当てることができます。

次の例では、三つのノードを持つクラスターが作成され、ノード`harvester-node-1`に_witness_の役割が割り当てられました。`harvester-node-1`はリソース消費が少なく、etcd機能のみを持っています。

NAME↑               STATUS   ROLE                         VERSION               PODS     CPU      MEM    %CPU    %MEM    CPU/A    MEM/A AGE
harvester-node-0    Ready    control-plane,etcd,master    v1.27.10+rke2r1         70    1095    10143      10      63    10000    15976 4d13h
harvester-node-1    Ready    etcd                         v1.27.10+rke2r1          7     258     2258       2      14    10000    15976 4d13h
harvester-node-2    Ready    control-plane,etcd,master    v1.27.10+rke2r1         36     840     6905       8      43    10000    15976 4d13h

クラスターには三つのノードが必要なため、プロモートコントローラーは他の二つのノードを昇格させます。その後、クラスターには二つのコントロールプレーンノードと一つのウィットネスノードで構成されます。

ウィットネスノード上のワークロード

ウィットネスノードは、以下の必須ワークロードのみを実行します。

harvester-node-manager
cloud-controller-manager
etcd
kube-proxy
rke2-canal
rke2-multus

ウィットネスノードを含むクラスターをアップグレードする

一般的なアップグレード要件と手順は、ウィットネスノードを持つクラスターに適用されます。ただし、そのようなクラスターに劣化したボリュームが存在する場合、アップグレード操作が失敗する可能性があります。

ウィットネスノードを持つクラスターのLonghornレプリカ

SUSE Virtualizationは、ブロックデバイスボリュームの管理のために、分散ブロックストレージシステムであるLonghornを使用します。Longhornは、管理ノードとワーカーノードにプロビジョニングされますが、データを保存しないウィットネスノードにはプロビジョニングされません。

Longhornは、可用性を高めるために各ボリュームのレプリカを作成します。レプリカには、ボリュームのスナップショットのチェーンが含まれており、各スナップショットは前のスナップショットからの変更を保存します。SUSE Virtualizationでは、デフォルトのStorageClass `harvester-longhorn`のレプリカ数の値は`3`です。

制限

ウィットネスノードは、データを保存しません。これは、3ノードのクラスター（ワーカーノードなし）では、各Longhornボリュームに対して2つのレプリカのみが作成されることを意味します。ただし、デフォルトのStorageClass `harvester-longhorn`は、高可用性のためにレプリカ数の値が`3`です。このStorageClassを使用してボリュームを作成すると、Longhornは構成された数のレプリカを作成できません。これにより、ボリュームがLonghorn UIで*劣化*としてマークされます。

要約すると、クラスター構成に一致するStorageClassを使用する必要があります。

2つの管理ノード + 1つのウィットネスノード：*レプリカの数*パラメータを*2*に設定して、新しいデフォルトのStorageClassを作成します。これにより、各Longhornボリュームに対して2つのレプリカのみが作成されることが保証されます。
2つの管理ノード + 1つのウィットネスノード + 1つ以上のワーカーノード：既存のデフォルトのStorageClassを使用できます。