Kubernetes为什么会逐渐成为云计算的标准？

　谈及容器技术，毫不夸张地说，2017年是“Kubernetes的元年”。Kubernetes自2014年推出以来，一直保持稳步增长。

　　这要归功于云原生应用的兴起。准确来说，云原生更像是一种文化，更是一种潮流，它是云计算的一个必然导向。它的意义在于让云成为云化战略成功的基石，而不是阻碍，如果业务应用上云之后开发和运维人员比原先还痛苦，成本高企的话，这样的云我们宁愿不不上。

　　其实在 Kubernetes 出现之前，就已经有人提出了云原生的概念，如 2010 年 Paul Fremantle 就在他的博客中提出了云原生的核心理念，但是还没有切实的技术解决方案。而那时候 PaaS 才刚刚出现，PaaS 平台提供商 Heroku 提出了 12 因素（基准代码、依赖、配置、后端服务、发布、进程、端口绑定、并发、易处理、开发环境与线上环境等价、日志、管理进程）应用的理念，为构建 SaaS 应用提供了方法论，该理念在云原生时代依然适用。

　　Kubernetes 是一个相对较新的运行容器化负载的平台，它解决了这些问题。它原本是 Google 内部的一个项目，Kubernetes 在 2015 年被捐赠给了云原生计算基金会，并吸引了来自世界各地开源社区的开发人员。 Kubernetes 的设计基于 Google 15 年的在生产和开发环境运维的经验。由于它是开源的，任何人都可以下载并使用它，并实现其带来的优势。

　　云原生应用理念要求将环境配置存在应用运行的环境中，在K8s集群中，所有的环境配置都存在分布式共享存储Etcd中。Kubernetes还有一些操作对象是用来专门存储环境配置的。例如ConfigMap是存储通用的配置变量的。ConfigMap有点儿像一个统一的配置文件，使用户可以将分布式系统中用于不同模块的环境变量统一到一个对象中管理；而它与配置文件的区别在于它是存在集群的“环境”中的，并且支持Kubernetes集群中所有通用的操作调用方式。

　　再比如Secret是专门用来存储密钥对象的，它使得在Kubernetes集群中用到密码等私密信息时不必用明文环境变量来表示，从而加强密钥传递和保存的安全性。

　　更重要的是，云原生应用理念要求尽量保证开发、测试和生产环境的配置一致，但是同时这几个不同的环境又应该是彼此隔离。在Kubernetes集群中，不同的环境可以通过namespace进行隔离，保证彼此不互相干扰。

　　可以说，Kubernetes在像 OpenStack 这样的基础架构即服务（IaaS）和完整的平台即服务 （PaaS）的资源之间达到了最佳平衡，它的底层运行时实现完全由供应商控制。Kubernetes 提供了两个优势：对管理基础设施的抽象，以及深入裸机进行故障排除的工具和功能。