了解命令：
基础命令：k3d node create
选项：
extraCPnode：k3d用于创建最终节点名称的基本名称。
role=server：设置节点的角色为控制平面。
image rancher/k3s:v1.19.3-k3s2：指定要使用的K3s镜像。
从这里可以看出，我们从不同的角度进行检查以确保新的控制平面节点正常运行。
增加了这个额外的节点之后，我们就可以进行最后的测试了：降低node0！
HA：重型装甲防撞车node0通常是我们的KUBECONFIG所指的节点（用IP或主机名表示），因此我们的kubectl应用程序试图连接到它来运行不同的命令。
由于我们正在使用容器，所以“破坏“一个节点的最好方法是直接停止容器。
docker stop k3d-k3s-default-server-0
请注意：Docker和k3d命令会立即显示状态变化。然而，Kubernetes集群需要很短的时间才能看到状态变化为NotReady。
此外，我们的集群仍然使用Kubectl响应我们的命令。
现在是时候再次参考负载均衡器k3d所用的时间，以及它对于让我们继续访问K3s集群的重要性。
从外部连接的角度来看，虽然负载均衡器内部切换到了下一个可用节点，但我们仍使用相同的IP/主机。这种抽象为我们节省了很多经理，并且这是k3d最有用的功能之一。
让我们看一下集群的状态：
kubectl get all --all-namespaces
一切看起来正常。如果我们再具体看一下Pods，那么我们会发现，K3s通过在其他节点上重新创建运行在故障节点上的pods来自动自愈：
kubectl get pods --all-namespaces --output wide
最终，为了展示HA的强大以及k3s如何管理它，让我们重启node0，然后我们会看到它被重新纳入集群，好像什么都没有发生。
docker start k3d-k3s-default-server-0
我们的集群是稳定的并且所有节点都再次正常运行。
现在我们可以删除本地HA集群，因为它已经完成了它的使命。此外，我们知道我们可以轻松创建一个新的集群。
使用以下命令即可清理我们的HA集群：
k3d cluster delete
虽然我们在本地、容器中创建了单节点和HA集群，我们仍然可以看到K3s在新的etcd嵌入式DB下的表现，如果我们在裸机或虚拟机上部署K3s，其作用方式相同。
也就是说，k3d在管理方面帮助很大。它默认创建了一个负载均衡器，允许永久连接到K3s集群，同时抽象了所有的任务。如果它部署在容器外，我们需要手动完成这一步骤。
在本文中，我们已经看到了使用k3d设置高可用性K3s集群是多么容易。如果你尚未尝试，强烈推荐你根据本教程进行实践，它们都是开源且易用的。