为了提升k3s的使用体验，我们将推出由k3s开发人员撰写的“k3s黑魔法”系列文章来详细介绍k3s功能、原理等方面的内容。本篇文章是该系列的第二篇，文章详细介绍k3s的HA部署实践并探讨其原理。同时，欢迎大家添加k3s助手（微信号：k3s2019），加入官方微信群和大家一起交流。
前 言
上一篇我们探讨了k3s单进程如何实现了对k8s各个服务的管理，我们通过单点部署的方式给大家展现了k3s运行时的效果。而在面向生产环境的实践中，高可用HA是我们无法避免的问题，k3s本身也历经多个版本的迭代，HA方案也进行了不断优化，形成了目前的比较稳定的HA方案。k3s的HA方案中，主要关注以下几点：
- k3s 中的datastore如何选型？
- k3s worker节点如何能够均衡访问master服务？
- 除了datastore本身外，是否还需要依赖其他第三方组件？
带着这些疑问，我们先进行HA部署实践，然后进行原理上的探讨。
HA部署实践
目前，k3s支持SQLite/etcd/MySQL/PostgreSQL/DQLite等datastore，不同的datastore面向不同的使用场景。大部分用户使用默认参数安装时，都会使用到SQlite，而对于etcd，大家都已经再熟悉不过。所以我们这里选择大家熟知的MySQL来做HA的实践，PostgreSQL与MySQL类似，我们就不再重复。
对于MySQL本身的HA，由于我们并不是在DBA范畴讨论，所以我们直接使用公有云的RDS创建MySQL服务，并通过k3s来使用它。使用AWS创建MySQL服务非常简单，很容易我们就能得到一个服务实例，如下：
创建两个节点，以k3s v1.0版本为例，分别执行以下命令：
$ curl -sfL https://get.k3s.io | sh -s - server --datastore-endpoint='mysql://admin:Rancher2019k3s@tcp(k3s-mysql.csrskwupj33i.ca-central-1.rds.amazonaws.com:3306)/k3sdb'
# 注意database name不要加特殊字符在任意一个节点中，查看node情况：
$ kubectl get no
NAME STATUS ROLES AGE VERSION
ip-172-31-4-119 Ready master 7s v1.16.3-k3s.2
ip-172-31-7-200 Ready master 2m32s v1.16.3-k3s.2在我们添加一个worker节点之前，我们需要给多个k3s server提供一个统一的访问入口，这可以使用以下方式实现：
- L4层负载均衡器
- Round-robin DNS
- VIP或者弹性IP
本文采用比较简单的DNS方案，我们针对k3s server的IP，添加了对应的A记录，并得到了一个域名，使用这个域名我们就可以添加worker：
$ curl -sfL https://get.k3s.io | K3S_URL=https://k3s-t2.niusmallnan.club:6443 K3S_TOKEN=${K3S_TOKEN} sh -
$ kubectl get no
NAME STATUS ROLES AGE VERSION
ip-172-31-7-200 Ready master 15m v1.16.3-k3s.2
ip-172-31-4-119 Ready master 12m v1.16.3-k3s.2
ip-172-31-7-217 Ready <none> 25s v1.16.3-k3s.2这样两台k3s server同样具备worker属性，且我们又新增了一个纯粹的woker。而这台worker节点是如何连接k3s server的呢？之前的文章，我们探讨过worker节点依然会通过thread方式运行kubelet/kubeproxy，而这些组件也需要连接api-server获取资源状态，比如我们可以看kubelet的kubeconfig文件：
$ cat /var/lib/rancher/k3s/agent/kubelet.kubeconfig
apiVersion: v1
clusters:
- cluster:
server: https://127.0.0.1:42545
certificate-authority: /var/lib/rancher/k3s/agent/server-ca.crt
name: local
contexts:
- context:
cluster: local
namespace: default
user: user
name: Default
current-context: Default
kind: Config
preferences: {}
users:
- name: user
user:
client-certificate: /var/lib/rancher/k3s/agent/client-kubelet.crt
client-key: /var/lib/rancher/k3s/agent/client-kubelet.key我们可以看到kubelet访问的是本地的服务端口，所以worker节点中一定存在一个proxy来反向代理api-server，查看下面的配置，我们就能找到答案：
cat /var/lib/rancher/k3s/agent/etc/k3s-agent-load-balancer.json
{
"ServerURL": "https://k3s-t2.niusmallnan.club:6443",
"ServerAddresses": [
"172.31.4.119:6443",
"172.31.7.200:6443"
]
}进入数据库中，我们可以看到k3s存储的表结构，相当于把etcd那种kv模式改为关系型数据库模式，比如：
$ select * from kine limit 3\G;
…
…
…
*************************** 3. row ***************************
id: 3
name: /registry/apiregistration.k8s.io/apiservices/v1.apiextensions.k8s.io
created: 1
deleted: 0
create_revision: 0
prev_revision: 0
lease: 0
value: {"kind":"APIService","apiVersion":"apiregistration.k8s.io/v1beta1","metadata":{"name":"v1.apiextensions.k8s.io","uid":"c9109c3a-3475-42cb-a1e3-73ddb6161c55","creationTimestamp":"2019-11-19T09:18:06Z","labels":{"kube-aggregator.kubernetes.io/automanaged":"onstart"}},"spec":{"service":null,"group":"apiextensions.k8s.io","version":"v1","groupPriorityMinimum":16700,"versionPriority":15},"status":{"conditions":[{"type":"Available","status":"True","lastTransitionTime":"2019-11-19T09:18:06Z","reason":"Local","message":"Local APIServices are always available"}]}}
old_value: NULL
3 rows in set (0.00 sec)DQLite（https://github.com/canonical/...）的方案更佳轻量级，可以理解为高可用版本的SQLite。k3s已经内置了DQLite，所以启用它是很方便的，由于DQLite的数据备份基于raft协议，所以基数个节点是比较稳妥的方式，部署过程参考官方文档即可：
https://rancher.com/docs/k3s/...
那么，我们可以总结一下，各个datastore类型的使用场景，参考如下：
总的来说，k3s HA的基本模式，如下图所示：
HA实现原理
我们都知道k8s的默认datastore是etcd，而k3s是如何将针对etcd的相关操作，转化到其他类型的datastore上的呢？这里Rancher开发了一个新的组件叫kine（https://github.com/rancher/kine），由它来完成这项工作。k8s（k3s）的api-server默认使用etcd v3的存储接口，etcd v3中被k8s使用的接口大致如下（https://github.com/etcd-io/et...）：
在kine中，这些接口都依次被实现（Lease相关还不支持），可以参考这里：
https://github.com/rancher/ki... 。
kine将这些接口暴露给k3s的api-server。当我们给k3s设置相应的datastore-endpoint时，k3s的api-server还是配置连接etcd v3，但是etcd-servers的地址则配置为kine的服务地址，相当于所有的api读写操作都通过kine来处理，kine来把读写操作转给MySQL/PostgreSQL/SQLite等。如果我们设置真正的etcd backend，kine会略过并直接暴露真实的etcd-servers给k3s api-server。
worker节点中的api-server代理通过一个tcpproxy（http://github.com/google/tcpp...）来实现，参考：
https://github.com/rancher/k3... 。
tcpproxy需要获取真实的api-server的服务地址，这里主要靠worker与master建立的tunnel，也就是websocket数据通道获取，这个tunnel是k3s独有的。当api-server地址有更新，worker依靠websocket获取新的地址，同时更新worker中的tcpproxy的配置。
后 记
高可用是软件投产的基本标准，k3s目前已经GA，并提供了HA的方案。无论是在边缘场景中，还是开发测试中，都可以根据自身的需求选择合适的datastore以及对应的HA方式。DQLite的方案目前还是实验性质的，相信随着整个边缘计算生态的发展，这部分也会很快稳定可用。
