关于K8S的5点我所知道的

‌1. Kubernetes 1.20版本不再支持Docker作为容器运行时‌

这一变化的主要原因包括以下几点：

‌复杂性和资源开销‌：Docker除了运行容器外，还提供影像仓库、容器构建等额外功能，这些功能在Kubernetes场景下往往是多余的，增加了系统的复杂性和资源开销‌。

标准化‌：通过支持更轻量的运行时，如containerd和CRI-O，Kubernetes能够更好地符合容器运行时接口（CRI）标准，确保更好的兼容性和灵活性‌。

‌安全性‌：使用更轻量的运行时可以减少系统的攻击面，提供更为细粒度的安全策略‌。

架构简化‌：Kubernetes引入了CRI标准，这是一组标准化接口，使得Kubernetes的核心组件Kubelet能够与任何支持CRI的容器运行时进行通信，从而简化了Kubernetes的代码库，提升了系统的效率和稳定性‌。

2. K8S升级要一个版本一个版本升级，跨版本升级极有可能出事故

K8S版本向下兼容性非常差，不建议跨版本升级。K8S集群建议部署时分多个集群部署，可分成非核心应用集群和核心应用集群。升级时先升级非核心应用集群，长期观察没有问题后再升级核心应用集群。

某滴1年前的大事故，晚上高峰期无法打车据说就是K8S集群升级的事故。

3. K8S版本兼容性差还体现在插件也需要指定版本才能适配

具体对应关系请参考官方说明，例如：

参考 Calico 官方兼容性矩阵 确认你使用的 Kubernetes 版本是否支持当前安装的 Calico 版本:

https://docs.tigera.io/calico/latest/getting-started/kubernetes/requirements

4. 避免将K8S直接部署在容器中

直接部署在容器中可能会引起循环依赖的问题，在特殊场景中出现问题。我之前就遇到过，在虚拟机中调用K8S的API，因为那个API在机器中没有对应目录和文件时就创建，有的话直接使用。而它本来使用的意思是之前启动过已经建好了。

后来我们在新机房用容器部署，在老版本K8S集群创建的容器上也没有问题，但是新版本K8S集群创建的容器本身就有上面提到的文件和文件夹。而调用K8S接口直接修改了本机文件，导致容器异常，服务无法使用。

5. K8S要注意网络模型

之前做过一个项目，我们的私有云为了容灾和按需扩容需要，也与公有云合作，按需购买它们的物理机并部署K8S集群。我负责可行性验证。

在使用我们之前运维给的镜像部署了K8S管理端后，创建的容器无法联网。后来发现是由于运维给的镜像配置写死了网络模型使用桥接模式，而公有云用的是NAT模式。桥接模式说白了就是跟虚拟机一样每个容器单独分配IP，而NAT模式的流量是通过主机转发。网络模式不匹配所以连不上网。