Kubernetes实践
来自： http://dockone.io/article/1016
Kubernetes已经成为我们立足于基础设施降低技术实现门槛的重要手段与组成部分：
- 推动Docker实施
- 简化容器管理
- 引导开发人员了解基础设施
- 实现持续集成与交付
为了实现以上目标，我们从根本上采纳Kubernetes并将自身DevOps团队转化为云平台团队，并以容器与微服务作为技术形式。其中包括构建一系列工具以解决自身长期面对的原有技术问题。
问题所在
最大的难题在于，云计算仍是种新生事物，而我们也还非常年轻。我们在起步之初仍然秉持着使用传统数据中心的心态。我们自行管理全部服务：MySQL、Cassandra、Aerospike、Memcache以及其它种种。我们设置虚拟机的方式与大家使用传统服务器的方式非常相似，在其中安装我们的应用程序并利用Nagios或者Ganglia对其加以管理。
遗憾的是，这种思维方式与以云为核心的理念可以说完全对立。相较于云方案以服务为形式的思路，我们一直立足于服务器思考问题。另外，相较于利用自动规模伸缩、微服务或者受管虚拟机等现代云方案，我们更多使用脚本化设置、服务器部署并尽可能避免供应商锁定状况的发生。
这些方式本身并不是不好，只是往往效率不甚理想。这类方式并不能充分发挥变更所能带来的优势，而云却能够快速实现变更并将其纳入业务流程。这同时也意味着在必须做出变更时，这些变化因素对我们来说可谓数据中心正常运行的天敌，但在云端来看它们却仅仅处于能够小规模快速起效的调整举措。
解决方案
以Kubernetes为工具促进Docker实施
随着Docker逐步成为技术行业中的一大重要力量，ShareThis公司的工程师们也开始对其进行测试并取得了良好的收效。事实很快证明，我们需要在企业中为每款应用部署与之相匹配的容器，从而显著简化开发环境下的测试工作。
某些应用能够更快融入到Docker环境当中，这是因为它们本身比较简单并且与其它系统组件的关联性较弱。对这些关联性不强的应用，我们得以利用Fig（Fig正是Docker Compose的初始名称）对其加以管理。当然，我们的大部分数据通道或者关联性应用还是太过粗糙，并不能够直接实现Docker化。在这种情况下，单凭Docker的力量显然无法解决问题。
2015年年末，我们对于原有基础设施的不满情绪终于积累到了临界点。为了彻底获得应对能力，我们开始评估Docker工具、ECS、Kubernetes以及Mesosphere。我们很快得出结论，发现Kubernetes拥有更为稳定的运行表现，而且能够为我们的基础设施带来较竞争对手更出色的用户友好度。作为一家企业，我们得以轻松实现将全部基础设施迁移至Kubernetes之上的目标，并以此为基础进一步实现基础设施与Docker间的合并。
工程师们最初对抱有怀疑态度。然而在亲眼见证了应用程序规模能够轻松达到每应用数百个实例的显著成效之后，他们开始欢呼雀跃。现在，推动我们向Docker迈进的不仅是固有痛点，同时技术层面的巨大潜力也真正调动起了我们的积极性。这使我们得以快速实现原本极为困难的负载迁移。目前，我们已经将Kubernetes运行在多个葱黄人的65套大型虚拟机系统当中，并计划在未来几个月内将这一数字进一步提升至100套。我们的Kubernetes集群每天并行处理着8000万条请求，而未来数月我们计划将这一处理能力直接提升至每天20亿条请求。
利用Kubernetes作为工具管理容器
我们最初计划利用Docker处理开发任务，而非大规模将其引入生产环境。其中最大的矛盾点在于，我们并没有以规模化方式管理Docker组件的能力——具体包括了解哪些容器运行在哪些位置、当个部署版本正处于运行状态、某款应用的当前状态如何以及如何管理子网与VPC等等。面对这些难题，我们根本没办法利用其作为生产平台。很明显，我们需要庞大的工具供应解决上述问题。
而在审视Kubernetes时，我们发现其中拥有几大能够立刻抓住用户眼球的关键特性：
- 可以被轻松安装在AWS之上（而我们的全部应用亦运行于此）
- Dockerfile可通过一个yaml/json文件为复制控制器提供目录路径
- 各Pod能够轻松实现数量层面的规模伸缩
- 我们能够轻松在Kubernetes集群当中对AWS之上的虚拟机数量进行规模伸缩
- 滚动部署与回滚机制建立于工具体系之内
- 每个Pod都可通过运行状态检查实现监控
- 服务端点受该工具管理
- 拥有积极且充满活力的技术社区
遗憾的是，工具供应的最大问题在于其无法适应我们的原有基础设施——其只能提供一套作为迁移目标的潜在基础设施方案。另外，一系列网络局限使得我们无法直接将自己的应用程序转移至新的VPC之上。再有，对如此众多的应用程序进行重新调整要求开发人员们不得不面对众多原本通常由系统管理员以及运维团队负责处理的问题。
以Kubernetes为工具引导开发人员熟悉基础设施
当我们决定由原本的Chef平台转向Kubernetes时，我觉得我们那时候还并不理解自身可能面对的各类潜在问题。我们实际上一直在以各种不同的方式利用各种不同的网络配置进行服务器运行，而且其整体设计思路与Kubernetes VPC的精简风格完全不符。
在生产环境下，我们跨越多个区域运行有AWS VPC与AWS经典服务。这意味着我们需要面向多种不同应用程序管理大量拥有不同访问控制机制的子网体系。我们新近上线的应用程序非常安全，而且并不具备公共端点。这意味着我们拥有的是一整套VPC互连、网络地址翻译（简称NAT）以及以不同配置运行着的代理机制的复杂集合。
在Kubernetes的世界当中，VPC是惟一的组成部分。所有Pod在理论层面上都能够彼此通信，而服务端点也经过明确定义。开发人员们能够轻松解决部分细节问题，同时消除大部分运维需求。
我们最终决定将全部基础设施/DevOps开发人员转变成应用程序开发人员（不开玩笑）。我们在雇佣之初就要求他们具备开发技术基础而非运维技术基础，因此这项决策其实并不像听起来那么不切实际。
在此之后，我们决定将整体工程技术部门转型为运维部门。开发人员天然具备出色的灵活性，他们热爱挑战并乐于学习。这一点非常重要。就在1个月之后，我们的企业已经由原本拥有数位DevOps人员的状态，成功转化成每名工程师都有能力对业务架构进行修改。
而针对网络、产品化、问题解决、根源分析等目标的人员培训工作也顺利使得Kubernetes以规模化方式上线。在头一个月里，我一直在抓耳挠腮地反思自己的决定会不会带来大麻烦。但两个月之后，可行性已经开始初步显现。三个月后，我们每周能够实现十次部署。四个月宾，每周40款应用顺利上线。当时我们有30%的应用程序已经顺利完成迁移，这样的结果岂止出色，简直令人难以置信。Kubernetes让我们得以从一家“被基础设施拖累”的企业成功转型成为一家“受基础设施推动”的企业。
以Kubernetes为手段实现持续集成与交付
我们是如何实现每周超过40项部署任务的？简单来讲，就是在迁移的同时实现了技术集成与部署（简称CI/CD）能力。我们部署在Kubernetes中的第一款应用是Jenkins，而在此之后每款介入其中的应用都被添加到Jenkins内。随着工作的不断推进，我们得以将Kubernetes内的Pod添加以及移除之前的一切工作都由Jenkins以自动化方式实现，而且其实施速度甚至超过了我们的追踪能力。有趣的是，我们的规模伸缩难题现在已经变成另一种困扰——我们希望一次性推出的变更太多，人们需要排队等待自己的变更按顺序上线。我们目前的目标是每周通过新基础设施实现100次部署。如果我们能够继续推进迁移工作并立足于Kubernetes与Jenkins保持这种持续集成/交付流程，那么这一目标完全可以达成。
未来展望
接下来我们需要彻底完成迁移任务。这方面问题已经多数得到解决，而其中最麻烦的部分其实是当前手头的工作比较单调乏味。将负载从原有基础设施中迁移出去意味着我们需要变更网络配置，从而实现面向Kubernetes VPC以及跨越各区域的访问能力。这仍然是一项严峻挑战，而我们也在积极加以解决。
另外，一部分服务在Kubernetes中的表现并不尽如人意——例如状态化分布式数据库。幸运的是，我们通常可以将这些负载迁移至第三方平台并由其负责打理。在此轮迁移工作结束时，我们将只需要运行Kubernetes之上的各Pod，这也意味着我们的基础设施将得到进一步简化。
当然，天下没有免费的午餐; 将全部基础设施迁移至Kubernetes意味着我们需要雇佣水平高超的Kubernetes技术专家。我们的团队已经按照基础设施形式进行重组，他们也正忙于通过应用程序开发（这也应该是他们的本职工作）实现业务价值。然而，我们目前还不具备能够始终紧跟Kubernetes与云计算最新特性的工程师队伍。
考虑到这一点，我们已经任命一名工程师建立新的“云平台团队”，并将招聘几位新成员填充进来。他们将负责开发相应工具，帮助我们借此更好地同Kubernetes相交互，同时管理全部云资源。除此之外，他们还将对Kubernetes源代码以及部分Kubernetes SIG做出调整，如果可能还需要为该开源项目提供代码贡献。
总结陈词
总结来讲，Kubernetes给人的第一印象似乎有点生人勿近的意味，但其实际复杂程度与颠覆性水平并不像我们想象的那么夸张。而在另一方面，Kubernetes也给我们带来了丰厚的回报——让我们成为一家能够根据客户愿望以最快速度做出反应的企业。