为了提升k3s的使用体验，我们将推出由k3s开发人员撰写的“k3s黑魔法”系列文章来详细介绍k3s功能、原理等方面的内容。本篇文章是该系列的第二篇，文章详细介绍k3s的HA部署实践并探讨其原理。

同时，欢迎大家添加k3s助手（微信号：k3s2019），加入官方微信群和大家一起交流。

前 言

上一篇我们探讨了k3s单进程如何实现了对k8s各个服务的管理，我们通过单点部署的方式给大家展现了k3s运行时的效果。而在面向生产环境的实践中，高可用HA是我们无法避免的问题，k3s本身也历经多个版本的迭代，HA方案也进行了不断优化，形成了目前的比较稳定的HA方案。k3s的HA方案中，主要关注以下几点：

1. k3s 中的datastore如何选型？

2. k3s worker节点如何能够均衡访问master服务？

3. 除了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提供一个统一的访问入口，这可以使用以下方式实现：

1. L4层负载均衡器

2. Round-robin DNS

3. 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/dqlite）的方案更佳轻量级，可以理解为高可用版本的SQLite。k3s已经内置了DQLite，所以启用它是很方便的，由于DQLite的数据备份基于raft协议，所以基数个节点是比较稳妥的方式，部署过程参考官方文档即可：

https://rancher.com/docs/k3s/latest/en/installation/ha-embedded/

那么，我们可以总结一下，各个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/etcd/blob/master/etcdserver/etcdserverpb/rpc.proto）：

在这里插入图片描述

在kine中，这些接口都依次被实现（Lease相关还不支持），可以参考这里：

https://github.com/rancher/kine/tree/master/pkg/server 。

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/tcpproxy）来实现，参考：

https://github.com/rancher/k3s/blob/master/pkg/agent/loadbalancer/loadbalancer.go 。

tcpproxy需要获取真实的api-server的服务地址，这里主要靠worker与master建立的tunnel，也就是websocket数据通道获取，这个tunnel是k3s独有的。当api-server地址有更新，worker依靠websocket获取新的地址，同时更新worker中的tcpproxy的配置。

后 记

高可用是软件投产的基本标准，k3s目前已经GA，并提供了HA的方案。无论是在边缘场景中，还是开发测试中，都可以根据自身的需求选择合适的datastore以及对应的HA方式。DQLite的方案目前还是实验性质的，相信随着整个边缘计算生态的发展，这部分也会很快稳定可用。