Kubernetes深度实践（三）

如果是公网的Kubernetres集群可以省去不少烦恼，一般云供应商都会有完整的配套服务，包括存储和网络，但如果是自行搭建的集群就需要自行解决这两部分问题。

先说一下存储的选择，一般的话有一个分布式存储+Localstorage基本就够了。
分布式存储的话有许多开源方案的可选项，例如Ceph、GlusterFS、Longhorn等，使用分布式存储的话一定要记得要有一个时钟服务器，有好几次出问题都是因为服务器时间不同步导致的。
需要一个本地存储主要是考虑到在容器里面操作文件确实不方便，直接在hostpath里面操作的话可以省心不少。

下面说一下我选的存储，分布式存储用的是longhorn，本地存储用的是openebs_hostpath。之前分布式存储也试过用ceph，但总觉得重了点。使用longhorn的主要原因一方面在于它不会过多的修改我服务器上的设置另一方面还在于它配置简单而且还自带一个简洁的界面，并且可以很轻松的把数据备份到s3中。
openebs其实是能支持多种的存储实现，但是我只使用了他的hostpath存储，主要我也只想要一个hostpath的storageclass并且具备完整的备份和还原方案，可以让我安心存放数据就可以了。配合minio-operator和velero可以便捷的备份和还原数据，当然rke也有自带的hostpath storageclass，功能都差不多，具体选哪个都可以。还有安装velero的时候一定记得要设置--use-restic，不然会创建了备份却不会执行的问题。

网络方面主要需要解决两个问题
1、LoadBalance
2、DNS
一般LB都是公有云供应商才提供，自己搭建的话基本就只能选MetaLB了，它支持layer2模式和bgp模式。
layer2模式是功能不完整的负载均衡，它本质是没有负载均衡的功能的，只是把一个IP的流量导入到一个节点，然后通过kube-proxy导入到集群中具体的服务当中。当节点出现故障的时候流量会自动迁移到正常运行的节点中，从而实现故障转移。
bgp模式则可以实现真正的负载均衡功能，可以将流量导入到所有的节点，然后再由kube-proxy导入到集群之中。
dns的选择比较多，可以选择adgard或者DNSmasq等，选择很多，有个最基本的dns功能就可以，我一般会把dns直接挂到k8s集群里面，然后通过MetaLB把123端口暴露出去，这样即使容器挂了也能快速重启，一劳永逸的解决dns服务器问题。

解决完存储和网络，基础设施基本上就完整了，这一套下来已经可以搭建一个在生产环境上运行的高可用小型k8s集群了。