12 练习篇：K8s 集群配置测验 第二部分的内容围绕 Kubernetes 核心组件的安装配置一一给大家拆解了一遍，当前集群组件最主流的配置就是这些：containerd、kubeadm、IPVS、Calico、kube-dns。读者通过官方文档就可以独立配置一套集群，只是笔者发现，因为集群配置的过度复杂，能获得的环境也是千差万别，很难得到统一的认知。本篇测验的目的就是带着大家一起校验一遍我们学习到的经验，一起搭建一套集群的全过程，以此来校验我们掌握的集群知识。

环境

从第一天接触容器技术之后，我们想解决的问题就是环境依赖问题。因为 Docker 是让环境包裹这应用一起制作成镜像分发的。等我们配置 Kubernetes 集群的时候，我们操作的最小单元是 Pod，你可以理解为是一个容器组，这个容器组并不是简单的把一组容器放一起就完事了。它的设计巧妙之处在于以 pause 为核心的基础容器把相关应用的所有环境依赖都掌握在自己的运行时里面。其它相关业务容器只是加入到这个运行时里面，这些业务容器出现问题并不会破坏环境。这是 Kubernetes 构建业务集群的核心设计，非常巧妙的解决了应用服务的可用性问题。

现在我们要选择操作系统的版本了。你会发现并没有任何官方文档说过，哪一个版本是指定的。其实官方并没有这样的约定。因为容器的目的就是解决环境的依赖，但是这么多年的演进，说的更清楚一点，我们仍然有一个核心依赖就是 Kernel 依赖搞不定。Kernel 的特性会决定容器的特性，我们一般在选择上会参考 Docker 的版本来定，主流的有 18.09、19.03 等。你发现没有，你并不能保证在特定的环境下这些 Docker 版本没有问题，这就是我们在配置生产环境中出现问题自己埋下的坑。

如果你是企业内部使用，最好的办法是建立基准线，明确版本号，在大量实践的基础上投入人力来维护这个版本的稳定性。因为容器技术发展很快，现在 Kubernetes 已经和 Docker 越来越规避，都在使用 containerd 来支持底层容器运行时的管理，作为用户我们是无法回避这个。这里又突显一个问题，因为组件的变革，我到底应该选择哪个版本呢，它们稳定吗？因为 Kubernetes 是开源社区推动的软件，我们一定要遵循开源的方式来使用这些软件才能得到正确的经验。

我总结出来的经验如下，方便大家参考：

1. x86-64 仍然是当前对容器最好的系统架构体系，目前主流的系统聚集在 redhat/centos 7.x 系列，Ubuntu 16.04 系列。对于内核红帽系主要在 3.10 以上，Ubuntu 能到 4.4 以上。有些用户会通过开源 kernel 仓库把红帽系的 Kernel 升级到 4.4，也比较常见。升级内核的代价就是引入很多未知的模块，让系统变得不稳定。ARM 系统架构会对整个 Kubernetes 组件的文件格式产生兼容性要求，在选择适配的时候，一定要注意有没有准备好 Kubernetes 相应的组件。总结下来，主流的操作系统主要是红帽的 7.x 系列和 Ubuntu LTS 系列 16.04。升级大版本操作系统对 Kubernetes 来说，需要做很多适配工作，目前开源社区是不太可能帮用户做的。一定注意。

2. Kubernetes 的版本更新很快，整个社区会维护 3 个主线版本，如现在主要为 1.16.x、1.17.x、1.18.x。这个 x 版本号差不多 2 周就一个迭代，主要是修复 Bug。很多团队在使用上总结了一些技巧，比如取奇数版本或者偶数版本作为自己的主力版本，这个做法的目的就是规避最新版本带来的不稳定性。并不是说奇数版本好或者是偶数版本稳定，这是纯属瞎猜。作为开源软件，它的质量是社区在维护，落实到用户这里，就是大家都是小白鼠，需要在自己的环境试验验证组件的可靠性。总结下来，主流的环境还是选择比最新版本低 1 个或者 2 个子版本作为周期来当做自己的软件来维护。维护开源软件不是免费的，它是通过大家的努力才能保证组件的使用可靠性的。

\3. 除了 Kubernetes 主线版本的选择我们应该延迟 1 到 2 个版本之外，对于其它附属组件如 Calico、kube-dns、Containerd 等，应该需要选择最新版本。主要原因在于它们是一线运行的组件，被调用的次数是更多的，发现问题的机会更突出。越早发现问题越快得到修复。这又是开源里面的原则，就是越早发现、越早修复，组件越稳定。很多用户在组件选择上，会比较保守，导致很多修复过的 Bug 还存在于你的集群中，让不确定性得到蔓延。总结下来，跑容器的一线组件应该使用最新版本，越早发现，你的程序越稳固。言下之意，当开源小白鼠，咱们也要有对策，通过自动化测试的环境，把这些组件多测测。

\4. 很多以为 Kubernetes 安装上之后就完事大吉，环境的事情就不用操心了。诚然，通过容器确实可以解决一部分运维的问题。但是应用架构的可靠性并不能依靠 Kubernetes 。为什么在有了 容器之后，在 DevOps 领域开始引入了 SRE 的概念，就是说业务保障一直是业务核心能力，不能依赖 Kubernetes。用了 Kubernetes 之后，你更要关注架构的稳定性。

kubeadm 的配置测验

kubeadm 推出的初衷是为了用更平滑的方式来安装、升级 Kubernetes。在早期我是排斥的，因为二进制的安装方式好像更简洁，排错也更方便。但是随着安装经验的丰富，我发现二进制的安装还是无法标准化，配置起来手工操作的地方很多，无法满足一键安装的目的。

kubeadm 是唯一被官方认可的安装项目，可以说明社区对它云原生的安装配置方式的认可。这里引出的问题就是 kubeadm 是不是安装的结果都是一样呢？

不是的。它考虑的单机模式，高可用模式，组件混合镜像模式，组件分组镜像模式，这些让用户在安装的时候会遇到很多选择，也会产生出一些不可知的问题。因为 kubeadm 的版本的不同，它的安装过程和细节都会微调，我们应该尽量使用最新版本的 kubeadm 来安装，这样就可以得到很多一键部署的好处。很多原来手工需要做的事情，如自签名证书的签发都是 kubeadm 自动帮你做了，另外如安装之前的环境调优的参数也会自动帮你生成。这些操作都是之前需要手工考虑并自己手工执行的。

目前笔者的经验就是：以官方文档为基准，选择最新版本的 kubeadm 为最佳组件，然后做 Kubernetes 的安装规划工作，目前还没有碰到什么难题。

Calico、IPVS、kube-dns 组件的配置测验

很多用户谈到容器网络就色变，因为之前容器网络的方案太多，让用户根本选择不清楚。每家都说自己的网络方案好，但是其实每家的解决方案都不是最完美的方案。

目前，容器网络方案并没有官方推荐的方案。从 Kubernetes 官方文档中介绍到，网络这个范畴是不包括在集群组件中的。这是社区的选择，无可厚非。但是我们安装集群，如果没有配置网络，这个 Kubernetes 是无法承载业务容器的。为了这个实际问题，我们要选择一个合适的方案。

为什么说 Calico 是当前最理想的方案，主要原因是它的配置简单，在 100 台物理机规模下通过 IPIP 模式创建的容器网络，性能已经接近主机网卡模式，损耗很小。这个是以前版本的 Calico 无法解决的，现在最新版本经过测试发现性能提升不少。

对于 kube-dns，它对容器网络还是有依赖，只有你有了容器网络之后，kube-dns 才能正常工作。目前主流的是 CoreDns，在 100 台物理机下同样性能很好，目前运行上并没有遇到什么大问题。

IPVS 是 Kernel 的内核模块，主要代替 kube-proxy 的南北向流量。但是因为它的功能还是局限在 proxy 之上，对于 kube-proxy 的东西向流量的支持还是不行的，需要靠 iptables 来转换。华为通过压测发现之前用 iptables 来解决南北向流量的性能瓶颈，这才提出的 IPVS 的方案。随着现在 eBPF 可编程数据包的出现，让 IPVS 的方案开始进入到一个过度阶段。因为 eBPF 技术不仅仅支持南北向，也能支持东西向，可以完美替换到 iptables 的工作能力。毕竟 iptables 是为防火墙设计的，复杂并动态变更的规则会对系统带来影响，从而导致对业务的影响，这些都是用户不愿意看到的。

总结下来，这些组件的配置目前来看都有默认配置，基本上配置一次就不用更改，大家只要能验证能否正常工作就可以，没有必要花费太大精力在这些组件的配置上。

总结

所谓 Kubernetes 的配置测验，依靠的是大家动手去安装，单靠例子的示范很难让你获得一手的经验。但是测验的目的是让你能明白在安装过程中遇到的问题和解决方案。我们要感受到开源软件的不同之处，它利用社区的力量来维护版本的稳定性。大家安装的时候肯定会遇到这样那样的问题，除了自己验证排错之外，你可以理直气壮的在社区的问题列表栏上写下自己的问题，方便大家互通有无。很多国内的用户并没有理解这种交互带来的价值，因为开源运动是一种社交活动，它依赖用户的互动，如果大家都不去反馈，这个软件只会变的越来越差。

大家要理解 kubeadm 的意义，就是未来可能更多的配置要被默认值替代，大家只需要一键执行就可以获得一套性能可观的 Kubernetes 环境。这个需要时间，我们可以期待。

参考：

参考资料

https://learn.lianglianglee.com/%e4%b8%93%e6%a0%8f/Kubernetes%20%e5%ae%9e%e8%b7%b5%e5%85%a5%e9%97%a8%e6%8c%87%e5%8d%97/12%20%e7%bb%83%e4%b9%a0%e7%af%87%ef%bc%9aK8s%20%e9%9b%86%e7%be%a4%e9%85%8d%e7%bd%ae%e6%b5%8b%e9%aa%8c.md