高可用性組み込みetcd
組み込みetcd（HA）は、Raspberry PiのようなSDカードを使用する遅いディスク上でパフォーマンスの問題が発生する可能性があります。
なぜサーバーノードの数は奇数なのか？
HA組み込みetcdクラスターは、etcdがクォーラムを維持するために奇数のサーバーノードで構成されている必要があります。n台のサーバーを持つクラスターの場合、クォーラムは(n/2)+1です。奇数サイズのクラスターにノードを追加すると、クォーラムに必要なノードの数が常に増加します。奇数サイズのクラスターにノードを追加することは、マシンの数が増えるため一見良さそうに見えますが、クォーラムを失わずに故障できるノードの数は同じであるため、故障耐性は悪化します。
組み込みetcdを使用したHA K3sクラスターは以下で構成されます：
- Kubernetes APIを提供し、他のコントロールプレーンサービスを実行し、組み込みetcdデータストアをホストするサーバーノードが3 つ以上
- オプション：アプリケーションやサービスを実行するために指定されたエージェントノードが0個以上
- オプション：エージェントノードがクラスターに登録するための固定登録アドレス
大規模なHAクラスターを迅速にデプロイするには、関連プロジェクトを参照してください。
まず、クラスタリングを有効にするためにcluster-initフラグと、追加のサーバーをクラスターに参加させるための共有シークレットとして使用されるトークンを使用してサーバーノードを起動します。
curl -sfL https://get.k3s.io | K3S_TOKEN=SECRET sh -s - server \
--cluster-init \
--tls-san=<FIXED_IP> # オプション、固定登録アドレスを使用する場合に必要
最初のサーバーを起動した後、共有シークレットを使用して2番目と3番目のサーバーをクラスターに参加させます：
curl -sfL https://get.k3s.io | K3S_TOKEN=SECRET sh -s - server \
--server https://<サーバー1のIPまたはホスト名>:6443 \
--tls-san=<FIXED_IP> # オプション、固定登録アドレスを使用する場合に必要
2番目と3番目のサーバーがクラスターの一部になっていることを確認します：
$ kubectl get nodes
NAME STATUS ROLES AGE VERSION
server1 Ready control-plane,etcd,master 28m vX.Y.Z
server2 Ready control-plane,etcd,master 13m vX.Y.Z
server3 Ready control-plane,etcd,master 10m vX.Y.Z
これで高可用性のコントロールプレーンが完成しました。クラスター化に成功したサーバーは、追加のサーバーやエージェントノードを参加させるために--server引数で使用できます。追加のエージェントノードをクラスターに参加させる手順はサーバーと同じです：
curl -sfL https://get.k3s.io | K3S_TOKEN=SECRET sh -s - agent --server https://<サーバーのIPまたはホスト名>:6443
すべてのサーバーノードで同じでなければならないいくつかの設定フラグがあります：
- ネットワーク関連のフラグ：
--cluster-dns、--cluster-domain、--cluster-cidr、--service-cidr - 特定のコンポーネントのデプロイを制御するフラグ：
--disable-helm-controller、--disable-kube-proxy、--disable-network-policyおよび--disableに渡される任意のコンポーネント - 機能関連のフラグ：
--secrets-encryption
既存のシングルノードクラスター
v1.22.2+k3s1から利用可能
デフォルトの組み込みSQLiteデータベースを使用している既存のクラスターがある場合、K3sサーバーを--cluster-initフラグで再起動するだけでetcdに変換できます。それが完了すると、上記の手順で追加のインスタンスを追加できるようになります。
そのノードがすでにクラスターを初期化または参加したためにディスク上にetcdデータストアが見つかった場合、データストアの引数（--cluster-init、--server、--datastore-endpointなど）は無視されます。