我认为CNCF上所有其它的毕业项目加起来都没有Kubernetes名气大，Kubernetes又简称k8s，k8s在CNCF毕业项目页的简介是Scheduling & Orchestration，调度与编排；点击进入k8s的简介页面Kubernetes | CNCF：
Kubernetes is an open-source system for automating deployment, scaling, and management of containerized applications。k8s是一个自动部署、扩展、管理容器化应用程序的开源系统。
Kubernetes was accepted to CNCF on March 10, 2016 at the Incubating maturity level and then moved to the Graduated maturity level on March 6, 2018。2016年进入孵化期，而2018年进入毕业期。
k8s是非常复杂的，多少人为他写了一本本书，下面是部分著作：
- 《Kubernetes权威指南：从Docker到Kubernetes实践全接触（第4版）》
- 《Kubernetes源码剖析》
- 《每天5分钟玩转Kubernetes》
- 《Kubernetes实战》
- 《Kubernetes进阶实战》
- 《Kubernetes生产化实践之路》
- 《Kubernetes权威指南：企业级容器云实战》
- 《从 Kubernetes 到云原生—— 云原生应用之路》
不管是开发人员还是运维人员，看完这些书是不是都晕了。再去k8s的官网文档页Kubernetes Documentation | Kubernetes 看看，文档内容也不是英文差的同志能看明白的，更不用说系统安装之麻烦复杂，记得2020年我安装时，当时资源都被墙挡住了，本来就怕麻烦，后来干脆在生产环境放弃了。
因为K8s太复杂了，所以出现一些简化版本的Kubernetes发行版，旨在让云原生技术的落地部署更轻松。这些发行版通常基于Kubernetes，但进行了裁剪、扩展或优化，以简化部署和管理过程。以下是一些常见的简化版本的Kubernetes发行版：
- K3s: 是一个轻量级的Kubernetes替代品，由Rancher Labs开发。K3s删除了Edge和IoT相关的功能，以及Traefik等组件，从而减小了体积和资源消耗。
- k8e: 本意为kuber easy，是一个Kubernetes的极简发行版，基于K3s。它进行了裁剪（去掉了Edge/IoT相关功能、Traefix等）、扩展（加入ingress、sidecar实现、cilium等），并使用cilium作为cni的实现。
- MicroK8s: 是Canonical公司开发的轻量级Kubernetes发行版，专为开发、测试和CI/CD工作负载设计。它易于安装和配置，并包含一个易于使用的命令行界面。
- Minikube: 是另一个轻量级的Kubernetes发行版，专为在单个节点上运行Kubernetes而设计。它提供了本地集群的快速设置，适合开发和测试。
- OpenShift: 是Red Hat开发的企业级Kubernetes发行版。它提供了额外的功能和管理工具，如应用管理、身份验证和授权、容器镜像构建和部署等。
Python界有名言：Life is short，you need Python。人生苦短，我用Python。
我则说：人生苦短，我用swarm，不用k8s。
2020年当时做技术选型，在调研了swarm, mesos和k8s之后，尽管业界宣称：容器编排三巨头Swarm、Mesos 和 Kubernetes 的大战已经宣告结束，Kubernetes 成为了无可争议的赢家，Swarm和Mesos没搞头了，但是我还是毫不犹豫地选择了Docker Swarm。我的一个客户环境就几十台服务器，何必用k8s这个庞然大物呢，不要为了技术而技术。
上个月看科技新闻，mesos所在的研发支持公司似乎垮了，好在当时没有选择mesos，而docker、docker swarm一直存在着，没有听说有什么毁灭性打击。
在容器与容器编排管理方面，我选择了docker、docker swarm和portainer，都是比较轻量级的，非常容易上手，运维人员工作量也不大，需要学习的知识点不多。对于小型业务集群，一百台Linux服务器以内的硬件规模，我建议不必一定要学大公司上k8s，docker swarm可以试一试，基本都是能胜任业务系统需求的。
当然，docker swarm的功能肯定不如k8s强大，在我的运维经验里，swarm有一个明显的缺点让我难受：一个节点垮掉之后，swarm会在其它在线的节点上把容器运行起来，保持系统docker stack编排文件里指定的容器实例数量，然而，这个垮掉的节点up起来之后，swarm集群管理能力却不能把其它节点上运行的容器转移过来，达到集群使用硬件资源的平衡，只有后来新run的docker stack才能被优先分配到这个up起来的节点上，这明显不是我们想要的动态平衡功能。我不知道现在的docker swarm是否已经具有了这一功能，从这一点看swarm对资源合理性管理还是比较粗糙，只有我们自己写Python脚本通过API去暴力平衡。
Portainer系统并不是完全的开源系统，我用了它的社区版，它的页面刷新速度有点慢，API接口也不丰富，想做一些功能对接集成进我的运维系统，还是不如人意，但是还是马马虎虎能用的。
我本来是打定了懒主意不去学习k8s技术栈的，我们一直在AI方面采购国内两家大企业的系统，都是单机版的，早期都是直接在Linux系统上运行他们的C++、Java和Python程序，我好一整子没去管他们的系统更新，一直由具体运维团队的同志去安装和升级维护，去年去线上运维巡检一番，这两家竟然都换成了k8s系统来管理应用程序，在单机系统上安装了一大堆东西，主要包括k8s系列和prometheus+grafana系列，一看都吐血了，运维人员都不管它，不会的东西干脆不理。
更搞笑的是，有一次其中一家的系统由于数据爆满出故障了，联系厂家运维人员来支持，发现他根本不熟悉自己业务系统在k8s运行情况，害得我自己来查k8s操作命令，自己来分析他们的应用程序分布情况和调用链情况来定位问题，最终解决问题。
看来k8s是避不掉的了，我们平台对这两家公司的AI产品依赖很大，逼迫我们走上了学习k8s的漫漫之路。
k8s源自于Google这家伟大的公司，IT人没有不知道Google的了，在Google众多产品技术方向中有两个深深影响了世界：
1）三篇论文导致了Hadoop诞生，从而让世界在大数据开源领域百花齐放。
2）容器编排调度Borg系统开源出来形成如今的k8s系统和生态，从而让世界在云原生开源领域走向了工业级水平。
这两个方面有一个共同的特点，就是对成千上万台硬件系统进行管理，对成百上千个微服务系统进行大集群管理，保持7*24小时，保证99.999999%服务能力是很不容易的。
大数据如今的批量计算和实时计算，最重要的开源系统就是Spark和Flink，现在也都宣称能在k8s上进行部署了，那么大数据应用程序和云原生应用程序都能在k8s上编排调度了，这个情况更引诱我们去投入k8s的学习了。当然，真实情况不是我们想换就换的，Hadoop集群跑得好好的，没事瞎折腾去做迁移就是自己找死。
最后，还是建议学习一下kubernetes技术，即使不用也了解一下其思想也不错，在具体的公司技术栈选型，要根据自己公司的业务规模和人力情况做合适的选择，合适是最好的。
