随着容器及微服务技术的发展，部署和管理容器及运行于容器之中的微服务成为挑战。2014年，Google整合了内部容器集群管理系统Borg和Omega的优点，发布了作为容器orchestration系统的Kubernetes。随后在与Docker Swarm， Apache Mesos的竞争中脱颖而出，目前几乎成为事实上的标准。当前，世界上有30家以上的公司发布Kubernetes发行版，主要的公用云服务商AWS，Azure, Google Cloud都提供基于Kubernetes的容器服务(Container-as-a-Service)。
然而，企业在实际生产环境中部署和运行Kubernetes环境的过程中，依然面临着一些挑战，需要企业IT去解决。笔者之前曾经对几家使用Kubernetes的企业进行调研，总结起来主要有以下五个痛点。
企业的IT基础设施多种多样
当前，人们可以很容易地在多台同类型的服务器中部署一套Kubernetes集群，除Kubernetes自身携带的安装工具以外，很多发行商也提供了非常方便使用的自动部署工具。然而，企业通常有复杂的IT基础设施，机房里有不同类型的服务器，存储及网络设备。此时，自动部署，安装，配置以及升级就会变得复杂。
一个选择是，使用Ansile或者其他工具对多样的服务器，存储设备及网络设备进行抽象，屏蔽细节差异，并且提供自动部署，安装，配置。
一套Kubernetes集群无法满足所有需要
企业通常有着不同的应用团队，多样的应用组合，甚至有时会对集群有着相互冲突的需求。因此，一般说来，一个Kubernetes集群无法满足所有的需要，企业通常会部署多套相互独立的Kubernetes集群。
针对该需求，有两个方案：
1）可以对Kubernetes使用Tenant（租户）的概念对用户的使用权限进行增强。比如，允许某个租户在配额允许的范围内能获得容器服务。
2）对多套Kubernetes集群，甚至包括使用的公有云服务进行统一的云管平台。
开发团队通常分布在多个office或者位于不同的地域
考虑到单个集群的容灾需求，不同地域之间的网络时延以及不同国家在数据安全方面的规定，企业通常不会为分布在世界各地的开发团队建立一个巨大而统一的Kubernetes集群。通常，企业IT会根据地理位置，应用类型，数据属地要求，以及开发，测试和生产环境等因素来创建单独的Kubernetes集群。
这种情况下，拥有一套集中管理和监控Kubernetes集群的系统来管理不同站点的基础设施和集群，并且提供集中的用户认证及访问权限控制，将极大程度上有助于提升运营效率，简化部署和升级。
Kubernentes只负责容器或应用的Orchestration
开发，部署和运行大规模的企业级云原生应用需要的绝不仅仅是容器的Orchestration。比如，IT运维人员仍然需要创建防火墙，负载均衡，数据库，DNS服务等；基础设施的运维仍然需要人们来操作，比如物理主机的维护，硬盘的添加及替换，物理主机的添加，删除及替换等；依然需要容量规划，需要监控资源的分配和使用，计算，存储及网络的性能等。Kubernetes并没有考虑这些问题。
企业对容器中的应用需要容灾策略
无论是否容器化，任何关键应用及数据需要被保护，以免收到自然灾害影响。目前市场上并没有针对Kubernetes上的关键应用的备份及灾害恢复方案。
企业需要设计一套跨物理位置的远程数据同步和灾害恢复方案，以便保护关键业务数据，并且在某站点发生灾难时，被保护的业务应用在另一个站点别自动拉起。
目前，Kubernetes似乎已经成为容器集群系统的事实上的标准，然而，企业如果想使用Kubernetes，还有安装，分布式管理，运维，容灾等方面的工作要考虑。这也正是Kubernetes发行商和容器解决方案提供商的机遇。
