这篇文章主要聊聊K8s开发那些事儿，包括K8s是哪个公司开发的、它作为开源项目的背景，以及k8是什么项目。还会谈到k8s开发工程师需要掌握的技能，比如k8s api开发教程和k8s operator开发。最后，会介绍一些好用的k8s开源管理平台和常见的k8s发行版，希望能给想入行或者正在学习的朋友一点参考。
k8s开发
现在搞k8s开发挺火的，很多公司都在把自己的应用往容器上迁。但说实话，刚开始接触的时候，那些yaml文件和各种资源对象看得人头大，经常配错一个参数就部署失败。不过熟悉了之后，发现它管理微服务确实很方便，就是学习曲线有点陡峭。
做k8s开发不仅仅是写写部署脚本，很多时候需要深入理解它的架构。比如你得知道etcd存了啥，controller manager在干嘛，光会用kubectl命令是远远不够的。我见过有人连Pod和Deployment的区别都搞不清楚，就敢说自己会k8s开发，结果上线出了大问题。
实际开发中，除了核心的编排功能，还得考虑网络、存储、监控这一大摊子事。比如服务怎么互相发现，日志怎么收集，这些都不是k8s自带了就能直接用的，需要结合很多第三方工具。社区生态虽然丰富，但选择太多有时候也是种烦恼。
k8s api开发教程
想自己写程序调用k8s，就得学它的API。网上教程很多，但质量参差不齐，有些用的还是老版本的客户端库，照着做根本跑不通。建议直接看官方文档，虽然英文的读着有点慢，但最准确，少走很多弯路。
用Go语言开发的话，官方提供的client-go库是首选。但它的接口设计有时候感觉挺绕的，初始化一个客户端就得一堆配置。而且不同资源对象的操作方式不太一样，需要花时间熟悉各种List、Watch、Update方法的具体用法，容易搞混。
除了直接写代码，也可以先用kubectl的--dry-run和-o yaml参数生成个模板，再改改用。或者用一些高级语言封装的SDK，比如Python的，可能写起来更顺手些。但底层原理最好还是懂，不然出了问题很难排查。
k8s开发工程师
这个岗位现在需求挺大的，但要求也不低。不是光会部署个Nginx就行的，公司一般希望你能搞定整个CI/CD流水线，把开发、测试、上线全流程用k8s串起来。有时候还得自己写Operator去管理一些有状态的应用，比如数据库。
面试的时候常问的有网络模型（像Flannel、Calico的区别）、存储卷怎么挂载、资源限制和配额、还有调度策略这些。光有理论还不行，最好有实际线上问题的处理经验，比如节点挂了怎么恢复，服务雪崩了怎么限流。
除了技术，沟通能力也挺重要。因为你需要和运维、测试、甚至业务开发的同学打交道，把k8s的那些概念用他们能听懂的话解释清楚。不然你在这边搞什么“声明式API”，人家根本不知道你在说啥。
k8s operator开发
Operator算是k8s里比较高级的开发模式了，简单说就是用自己的代码去扩展k8s，管理一些复杂的应用。比如你想自动备份和恢复一个数据库，光用原生的Deployment和StatefulSet可能不够，就得写个Operator。
开发Operator一般用Operator SDK这个框架，它帮你搭好了架子。但核心逻辑，也就是所谓的“调和循环”，还是得自己写明白。你要告诉程序，当用户想要的状态和实际集群里的状态不一样时，该怎么一步步操作去达到一致。
写Operator最麻烦的是处理各种异常情况。比如更新到一半失败了怎么回滚，网络断了怎么办。测试也很费劲，你不能老在真实的k8s集群里折腾，得用kind或者minikube搭本地环境模拟，但和线上环境总有差异。
k8s是哪个公司开发的
很多人以为k8s是谷歌原创的，这个说法对，但也不完全对。最早确实是谷歌内部搞了一个叫Borg的系统来管理容器，后来他们觉得这个思路好，就借鉴经验重新用Go语言写了一个开源的，也就是k8s，在2014年正式发布。
所以，虽然核心思想和经验来自谷歌，但k8s本身是一个开源项目，由社区共同推动的。谷歌把它捐给了云原生计算基金会。现在除了谷歌，红帽、微软、IBM这些大公司，还有无数个人开发者都在为它贡献代码。
有时候会听到有人把k8s和Docker公司比，其实不太对。Docker公司主要做容器运行时和工具，而k8s是做容器编排的，算是上下游关系。现在k8s成了事实标准，连Docker公司自己的产品都得去适配它。
k8s开源
k8s从诞生起就是开源的，代码放在GitHub上，谁都可以去看、去用、去改。这种开放的模式是它成功的关键，吸引了全球的开发者一起添砖加瓦。你想加个新功能或者修个bug，都可以提PR，当然审核挺严格的。
开源也意味着你可以随便改，然后自己内部用。但说实话，除非你是超级大厂，有很强的定制需求，否则一般不建议直接改核心代码。版本升级会是个噩梦，社区的新功能你也可能合并不进来，不如在扩展点上下功夫。
开源带来的另一个好处是生态繁荣。监控有Prometheus，日志有EFK，网络有一堆插件，管理平台也很多。你基本能找到任何你需要的工具，但反面就是技术选型很头疼，每个领域都有好几个流行的，得仔细对比。
k8是什么项目
“k8”这个叫法其实是Kubernetes的一个缩写，因为K和s中间有8个字母。它本身不是一个单独的项目，就是大家图省事对Kubernetes的昵称。新手有时候会搞混，以为这是两个不同的东西，其实说的是一回事。
有些人可能在网上搜“k8项目”，想找学习资料。这么搜可能找到的信息比较杂，因为很多博文或者论坛里会用这个简称。最好还是直接搜“Kubernetes”，这样找到的官方文档和系统教程会更多、更准确。
在技术讨论中，比如写邮件或者聊天时，用“k8s”或者“k8”都很常见，显得比较随意和亲切。但如果是正式文档或者给领导汇报，建议还是写全称“Kubernetes”，显得规范一些，避免不必要的误解。
k8s 开源项目
作为一个顶级的开源项目，k8s的治理结构挺正规的。有技术指导委员会，有各个特殊兴趣小组。你想参与的话，可以从写文档、修简单的bug开始，不一定要多高深的代码能力。社区对新人还是比较友好的。
这个项目的迭代速度非常快，基本上每三个月就出一个新的大版本。这意味着新功能多，但也要求使用者要不断学习跟进。有时候你刚摸熟一个版本，下一个版本就废弃了某个API，得赶紧改代码，挺有压力的。
除了核心的k8s项目，它周边有一大堆相关的开源子项目，比如做服务网格的Istio，做服务发现的CoreDNS。这些都算在k8s的生态圈里。有时候说“k8s开源项目”也可能指的是这个庞大的生态，而不单单是编排引擎本身。
好用的k8s开源管理平台
对于中小团队或者不想整天敲命令的人来说，有个图形化的管理平台太重要了。Rancher是这里面的老牌选手了，不仅能管理多个集群，还集成了一堆运维工具，功能很全。不过东西多了，部署和维护也相对复杂一些。
KubeSphere是近几年比较火的一个，界面做得挺漂亮，中文支持也好。它把 DevOps、微服务治理、监控日志这些功能都做成了可插拔的组件，你想要什么就开什么，比较灵活。安装起来比Rancher可能稍微简单点。
如果只是想要一个最轻量、最纯粹的管理面板，那可以看看Dashboard，这是k8s官方出的。功能比较基础，就是查看资源、创建和修改一些简单的yaml。但它胜在简单稳定，和k8s版本绑定，兼容性肯定没问题。
k8s 发行版
因为k8s原生安装配置挺麻烦的，所以就有很多公司做了打包好的发行版。最著名的就是红帽的OpenShift，它加了很多企业级的功能，比如安全策略、内置的CI/CD，但它是收费的，而且比较重，吃资源。
对于开发测试或者学习，Minikube和Kind这种单机版发行版是神器。Minikube是在虚拟机里跑一个单节点集群，Kind是用Docker容器来模拟节点，启动特别快。它们让你能在自己电脑上就体验k8s的大部分功能。
云厂商们也都有自己的托管k8s服务，比如GKE、EKS、AKS。这些也算是发行版，帮你把控制面板（Master节点）完全管理了，你只需要管工作节点。用起来省心，但就容易被一家云厂商绑住，迁移起来成本高。