k3s高可用部署实践及其原理



为了提升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层负载均衡器

    1. Round-robin DNS

    2. 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/l ... dded/

那么,我们可以总结一下,各个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/etc ... proto):

在这里插入图片描述

在kine中,这些接口都依次被实现(Lease相关还不支持),可以参考这里:

https://github.com/rancher/kin ... erver

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 ... er.go

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

后 记

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

0 个评论

要回复文章请先登录注册