本文讲的是为什么CoreOS携手开源？【编者的话】本文通过日常研发中遇到的问题，提出引入开源项目的重要性，介绍了CoreOS协助创立的CNCF以及它赞助的一些项目，同时也介绍了Kubernetes社区的一些现状和未来发展的展望。
【3 天烧脑式容器存储网络训练营 | 深圳站】本次培训以容器存储和网络为主题，包括：Docker Plugin、Docker storage driver、Docker Volume Pulgin、Kubernetes Storage机制、容器网络实现原理和模型、Docker网络实现、网络插件、Calico、Contiv Netplugin、开源企业级镜像仓库Harbor原理及实现等。
CoreOS构建开源软件。为什么携手开源软件呢？因为要解决的问题规模巨大，在宏观的层面需要革新。预计：
- 今时今日有3,646,000,000的因特网用户；
- 29,000,000的软件开发者和IT从业者；
- 去年新增了238,975,082的因特网用户；
- 全球大概有100,000,000左右的服务器。
显然我们作为软件工程师和管理员是忙不过来的。开源软件是使这一扩展成为财富的关键，大家在各种环境中合作处理最难的操作问题，例如管理安全性、可靠性以及可移植性。
大概三年半前，我们开始一起用工具套件解决分布式系统中解锁计算可移植层。随着Container Linux、Docker、Kubernetes等的引入，基于软件容器的生态系统开始形成。
构建Container Linux
CoreOS Container Linux，为容器世界创造的开源操作系统，大概四年前开始研发，设计理念是容器把Linux推向了一个全新的道路，需要对安全、性能以及宽平台多方面支持的全新版本。因此我们构建了一个有快速发布Linux内核特性的OS，尤其是在容器化优化方面。
Container Linux
现在被广泛的采用运行于各种云平台以及裸金属平台上。
CoreOS创建CNCF中的开源项目：rkt和CNI
至此，我们已经协助建立了CNCF（the Cloud Native Computing Foundation）并且捐助了包含
rkt
和
CNI
等一些关键容器技术。这些开源项目由CoreOS工程师发起并且在容器生态系统中的成功提供了一定的帮助。
最新的
rkt发布版本
自从被加入到CNCF以来，第一次对于帮助促进这次发布的社区成员表示了极大的感谢。本次发布新加入了很多贡献者，同时也提出了基于Xen stage1的建议。
CNI
是容器中的网络系统插件，它使得类似Kubernetes之类的管理平台更容易的支持IPAM、SDN或者其它网络方案。CoreOS几年前创造了CNI，以实现跨容器的解决方案和计算环境之间简单网络的可互相操作性。CNI有着一个蓬勃发展的第三方网络解决方案社区，用户可以从那里选择网络插件加入到Kubernetes容器架构中去。我们很高兴看到这些广泛采用的系统加入到CNCF中。
对于Prometheus监控引擎的贡献
监控架构软件和系统对于创建一个可靠的生产环境至关重要，
Promethus
事实上是Kubernetes生态系统的监控系统。鉴于其重要性，CoreOS在这个项目上投入了一定的人力并且把项目往可扩展性方向做出了很有意义的推进。社区对于可扩展性的关注是即将推出的
Prometheus 2.0版本
的前沿和中心，这个版本提供了时序存储层上的很大提升，旨在解决当前工作负载的瞬态性。
Celebrating Clair 2.0
Clair是CoreOS建立的一个安全项目，完成容器镜像的静态分析并将它的内容和公共漏洞数据库相关联。
Quay安全扫描
的核心就是Clair，但是它也支持其它许多需要容器镜像扫描的项目。
今天我们庆祝
Clair 2.0
的发布，包含Alpine Linux扫描等附加功能。这是个重要的里程碑的发布，感谢参与的43的贡献者。
联盟的Kubernetes状态
我们致力于创建一个强有力的Kubernetes开发社区，有着与之匹配的客户和合作伙伴的更广泛的社区。去年Kubernetes社区已经达成了几个重要的里程碑，包括几个稳定版本，一群增长中的贡献者，另外Kubernetes指导委员会的启动也帮助组织项目在未来几年进一步发展。
项目治理和发布
Kubernetes处理问题的空间是巨大的！Kubernetes社区发展快速的原因是由于社区组织的能力组织成了一个个的小团队，称为
特别兴趣组
。这些组织可以从横向跨项目的问题，如集群安装或认证/授权到更多的纵向问题，如Azure集成。然而当需要对创建新的资源库、划分新的发布版本包括新的API或者删除未进过测试的代码等操作跨SIG决定的时候，谁做出最后的确定就很不清晰。
几个月前，Kubernetes社区创立了一个
管理引导委员会
在如何处理这类问题上做出建议。最近引导委员会发布了一系列重要的建议和文档包括成立
Kubernetes指导委员会
全职解决项目组织问题。计划八月初建立Kubernetes指导委员会。
未来的展望
最后，让我们期待接下来几个Kubernetes发布版本里的一些特性和能力。我从
LWN
的Jon Corbet对常规Linux内核的预测获得启发。然后我的工作比Jon的更容易，Kubernetes社区开发了一个相对中心化的特性以及设计计划系统，因此对于这些预测，我有很高的信心相信它们都会成真。
核心部署API正在转向稳定
：这很容易预测，因为Kubernetes社区的很多人都致力于将它实现。Kubernetes社区正在快速地把重要的API添加到项目中，例如通过DaemonSets支持长时间运行的节点服务、通过StatefulSets支持静态状态应用以及通过Deployments支持滚动升级等工作负载。这些API已经被用户的很多发布版本证明且已经做好了转成稳定版本的准备。
一致性和自动集群配置
：Kubernetes有很多动态的部分，从API server和Scheduler到kubelet和kube-proxy。这些每个组件都需要获取密文和可调参数。现在这些都是通过命令行参数实现；但是管理这些组件非常困难，需要重启才能更新，而且对于版本更新来说是不大可能的。目前正在研发通过配置文件映射到称为组件配置的API对象，使配置更加一致，更容易自动化。
通过TPRs扩展和API的聚合
：对于创建集群应用的人们来说，Kubernetes的API已经成为了一个很便捷的系统。这是因为这些API有着友好的命令行工具，基于角色的接入控制并且可以插入很多用户认证系统。因此，人们创建了许多应用并将资源保存到Kubernetes中，这些资源称为
第三方资源
，另外还有个新的
API聚合
子系统用来启动API，可以在server端验证，和Kubernetes API版本集成，并且后台可以是不同的数据存储。
应用在Kubernetes API之上编译
：基于Kubernetes API的扩展能力，已经出现了虚火基于该API的应用。这包含从数据库、认证鉴权以及用户应用特定工作流的
许多应用
。这些应用的管理员将可以利用Kubernetes提供的所有功能包括日志、调试和监控工具等。
更多的用Metrics API监控驱动API
：并不是只有外部应用才被Kubernetes中新的API聚合启动。SIG Instrumentation现在正在创立一个metrics API服务器，可以随着现如今用户创建的越来越大规模的集群而扩展。这也使得Kubernetes内部更多的监控驱动决定系统变得可能：基于用户的指标自用扩缩，更好的首选管理工具就更容易插入到例如Prometheus等时序数据库中。
朝着光明的未来迈进
非常感谢所有人和我们在许多开源容器生态环境中关键项目中一起工作并取得成功。我们鼓励你们加入到开源和分布式系统的旅程中。或者，跟我们合作吧！
CoreOS正在招聘
。
原文链接：Why CoreOS Builds with Open Source（翻译：李桦）
原文发布时间为：2017-07-03
本文作者：李桦
本文来自云栖社区合作伙伴Dockerone.io，了解相关信息可以关注Dockerone.io。
原文标题：为什么CoreOS携手开源？
