关于 Kubernetes 和容器化的一些随想

这段时间在不少群里争论过关于 Kubernetes 和容器化的一些事，干脆总结下一些碎碎念作为一个概括吧。本文仅代表个人立场，不代表商业观点

容器化

目前很主流的一个观点，是能上容器尽可能上容器，说实话这个想法实际上是有一定的合理性的，去 review 这个想法，我们需要去看一下容器这个东西，给我们带来了什么样的改变

容器首先毫无疑问，会给我们带来非常多的好处：

那么，看起来我们是不是可以无脑用容器？不，不是，我们需要再来 Review 一下，容器化后我们所要面临的一些弊端：

容器安全性问题，目前最主流的容器实现（此处点名 Docker）本质上而言还是基于 CGroups + NS 来进行资源与进程隔离。那么其安全性将会是一个非常值得考量的问题。毕竟 Docker 越权与逃逸漏洞年年有，年年新。那么这意味着我们是需要去有一个系统的机制去规范我们容器的使用，来保证相关的越权点能被把控在一个可控的范围内。而另一个方向是镜像安全问题，大家都是面向百度/CSDN/Google/Stackoverflow 编(fu)程(zhi)选手，那么势必会出现一个情况，当我们遇到一个问题，搜索一番，直接复制点 Dockerfile 下来，这个时候，将会存在很大的风险点，毕竟谁也不知道 base image 里加了啥料不是？
容器的网络问题。当我们启动若干个镜像后，那么容器之间的网络互通怎么处理？而大家生产环境，肯定不止一个机器那么少，那么跨主机的情况下，怎么样去进行容器间的通信，同时保证网络的稳定性？
容器的调度与运维的问题，当我一个机器高负载的时候，怎么样去将该机器上的一些容器调度到其余的机器上？而怎么样去探知一个容器是否存活？如果一个容器 crash 了，怎么样重新拉起？
容器具体的细节问题，比如镜像怎么样构建与打包？怎么样上传？乃至说怎么样去排查一些 corner case 的问题？

我们做一个业务决策的时候，我们肯定不会是因为某个技术够先进，够舒服，而是需要去衡量这个业务决策的 ROI，同时在利弊之间做一个 Trade-Off，用容器化这件事来说吧，我们来思考下我们可能迁移容器常见的几个误区：

我们想对利用容器做资源隔离！那么问题来了，用 systemd + cgroup 这样简便的方法做和容器之间有什么区别？是容器的成本更低？
我们想践行 Devops 所以想上容器化！实际上 Devops 和容器化关联并不算大，它更多的是一种方法论，一个团队之间内部协作的一套方法论。不精确的来讲，是通过自动化，流程改进，SOP 引入等手段，将一套服务的分发与运维更为简便化。换句话说，在我们去践行 Devops 这一套方法论的时候，实际上不是一个技术问题，而是一个制度问题（讲个笑话，Devops 的开发不需要写脚本）。在其中，无论是我们传统的 Ansible 等运维手段，还是一些自动化测试的方法与框架，都可以成为 Devops 的一部分。那么这里还是一个问题，我们为什么要用容器？是因为传统的工具践行 Devops 的 cost 远高于用容器化的？

从这两个例子大家能看出来，当我们去做容器化这件事的时候，一定要思考的问题是，容器化是真正解决了我们什么痛点，还是只是因为它看起来够先进，够屌，能为我简历背书？

前面聊到容器化的几个问题，促成了以 Kubernetes 为代表的容器编排体系的诞生。大家在想，哇，既然解决了这个问题，那么我们再来聊聊这个问题

首先我已经忽略掉自建 Kubernetes 集群的场景了，因为那不是一般人能 Hold 住的。那么我们来看一下，依托公有云使用的情况吧，以阿里云为例，点开页面，然后我们见到这样张图

images

好了，提问：

VPC 是什么？
Kubernetes 1.16.9 和 1.14.8 有什么区别
Docker 19.03.5 和阿里云安全沙箱 1.1.0 是什么，有什么区别
专有网络是什么？
虚拟交换机是什么？
网络插件是什么？Flannel 和 Terway 又是什么？有什么区别？当你翻了翻文档，然后文档告诉你，Terway 是阿里云基于 Calico 魔改的 CNI 插件。那么 CNI 插件是什么？Calico 是什么？
Pod CIDR 是什么怎么设？
Service CIDR 是什么怎么设？
SNAT 是什么怎么设？
安全组怎么配置？
Kube-Proxy 是什么？iptables 和 IPVS 有什么区别？怎么选？