生产环境使用K8s一年后，我们总结了这些经验教训

我的公众号「码农之屋」(id: Spider1818) ，分享的内容包括但不限于 Linux、网络、云计算虚拟化、容器Docker、OpenStack、Kubernetes、SDN、OVS、DPDK、Go、Python、C/C++编程技术等内容，欢迎大家关注。

---

2015年初，我们计划为开发团队搭建一套全新的部署平台，在此之前我们使用的是Amazon EC2。尽管AWS-based steup我们一直用得很好，但使用自定义脚本和工具自动化部署的设置，对于运维以外的团队来说不是很友好，特别是一些小团队——没有足够的资源来了解这些脚本和工具的细节。这其中的主要问题在于没有“部署单元（unit-of-deployment）”，该问题直接导致了开发与运维之间工作的断层，而容器化趋势看上去是一个不错的方案。

如果你还没有做好将Docker和Kubernetes落地到生产环境的准备，不妨参考参考我们的经验。我们已经在生产环境使用kubernetes一年多了。

从容器和容器编排工具开始

我们相信容器会是未来最主流的部署格式，这项技术让应用封装变得简单了许多。类似于Docker之类的工具提供了实际的容器，但我们还需要复制、故障排除等工具，以及可实现自动部署到多台机器的API，好让容器技术发挥出最大的作用。

在2015年初，Kubernetes、Docker Swarm等集成工具还不成熟，仅提供alpha版本。不过我们还是决定试一试，并选择了Docker Swarm。

我们用Docker Swarm来处理网络，利用Ambassador模式和一组脚本来实现自动化部署。这种方式难度之大，超乎想象，我们也因此收获了第一个教训：容器集成、网络、部署自动化是非常棘手的问题。

好在我们很快意识到了这一点，并决定将筹码压在Kubernetes身上——一款由Google、Red Hat、Core OS及一些对大规模部署颇有见地的组织提供支持的集成工具。

通过Kubernetes实现负载均衡

使用Kubernetes，需要对pods、services、replication controller等概念了然于心。好消息是，包括Kubernetes官方文档在内，网络上有海量资源，可以帮助你快速上手。

成功建立并运行Kubernetes集群后，即可通过kubectl（Kubernetes CLI）部署应用了。然而当我们想要自动化部署时，却发现光有kubectl是不够的。不过，在此之前我们需要解决另一个问题：如何从Internet访问部署的应用？

部署前的服务有一个IP地址，但这个地址仅在Kubernetes集群中可用。这意味着无法通过网络访问该服务！在Google Cloud Engine上运行时，Kubernetes会自动配置一个负载均衡用以访问应用；如果不在Google Cloud Engine上运行ÿ