K8S应用于生产环境 vs. K8s应用于开发环境的4个空想

当容器和K8S的IT管理团队把本地变更部署在生产环境的时候，往往面对很多要学习的东西。

最近我们澄清了一些大家在进行K8S实验的时候所面对的常见的误解。其中最大的一个误解就是：在生产环境中运行K8S和开发测试环境并无两样。

答案：是不一样的。

Avi Network公司的联合创始人兼首席技术官Ranga Rajagopalan认为：“对于K8S，容器和微服务来说，实验环境和生产环境有巨大的不同。简单的运行和安全，可靠的运行是不一样的”。

Ranga Rajagopalan的意见中有一个重要的论点：上述问题不仅仅只是存在于K8S，同样也存在于容器和微服务。部署容器相对简单；而在生产环境运维和缩放容器（包括容器化的微服务）是问题复杂的原因。

容器和容器的编排 工具 通常都是成套出现的。New Stack公司之前进行了一项调查，调查发现当组织为了解决运维所面对的挑战，去寻找更强大的技术的时候，容器反过来推动了K8S的普及。虽然也有其他的工具，K8S还是快速成为了编排工具和选择的代名词。像Rajagopalan说的那样，在沙箱里运行K8S和在生产环境中运行K8S有巨大的不同。

通常IT专业人士和团队运维小规模的K8S环境，当这个环境转向生产环境部署的时候，这些人将有很多东西需要面对和学习。“你肯定想在上生产环境之前扫清这些常见的误解,这里有IT领导者和团队需要了解的知识”。

空想#1:在开发测试环境运行K8S能帮你全面了解运维的需求

现实：在开发测试环境运行K8S能帮你走一些捷径，你可以不必面对生产环境所带来的运营负载。

Wei Lien Dang， StackRox的产品副总裁认为“开发测试环境和生产环境的最大不同源自于运维和安全，在运维测试环境你根本不用在乎集群宕机。

Portworx的联合创始人兼CEO Murli Thirumale将开发测试环境和生产环境的不同与敏捷和可靠，高性能的敏捷做了类比。

“开发团队的目标是在开发和测试新应用和代码的时候实现应用的敏捷；而同时运维人员的目标是应用和数据的可靠性，可伸缩性，安全性和性能。后者需要一个强大的，企业级的，经过测试和验证的平台。

自动化已经成为了在生产环境中采用K8S（或者通俗所说的容器）的迫切需求。

Coda Global的架构师Ranjan Bhagitrathan认为“生产集群必须通过自动化部署。生产集群一定要具备可复制性，从而实现整体生产环境的一致性，同时可复制性也对灾难恢复有所帮助”。

Bhagitrathan同时也认为版本控制对生产环境运维至关重要，“对所有事情进行版本控制，比如服务部署的配置文件，策略等等，如果可能也包括实现基础架构即代码的代码命令。这能确保你的环境是相同的。同时也要确保容器镜像有版本控制，不要只是用“最新镜像”这样的名字来个镜像打标签，这样很容易引起混乱。

空想#2：你已经得到了可靠性和安全性

现实：如果你只在非生产环境试验过K8S。你可能没获得可靠性和安全性，或者目前没有。

好消息是你最终会做到，因为上生产环境之前，需要做规划和架构设计。

AquaSecurity的联合创始人兼 CTO Amir Jerbi认为“很显然，在生产环境，性能，可伸缩性，高可用性和安全性方面所面对的挑战更严峻。所以在架构阶段规划生产环境需求，并且把安全，伸缩控制，Helm charts集成在K8S部署的定义中是极为重要的”

Dang分享了一个测试开发环境如何导致过度自信的例子：

“开放所有的网络端口在测试开发环境中是非常不错的，很可能所有的服务都能互相连接。K8S默认设置所有网络连接开放。但这不是一个成熟生产环境所应有的设置，一旦步入生产阶段，停机和大规模攻击会给业务带来风险“。

“当工作转移到容器和微服务的时候，构建高可靠，高可用的系统是非常有价值的工作。编排工具帮你实现这部分工作，但这并不举手可得。安全性也是一样。”

“我们要做很多事情来减少针对K8S的攻击，通过加强网络策略来实施最低权限模型，并且限制服务只和需要的服务连接是非常关键的。”

在生产环境中，容器镜像的安全漏洞可以很快变的很严重，威胁可能是受限的或者根本不在本地。

（whereas the threat may be limited or non-existent locally.）

Bhagirathan说，“要注意你的容器镜像采用的基础镜像是什么，尽可能用受信任的官方镜像或者自己动手制作。用未知的镜像也许可以帮你很快的跑起服务，但也带来了安全问题。比如，你肯定不想你的K8S系统给别人挖比特币做贡献。”

红帽公司的安全策略师 Kirsten Newcomer 鼓励人们通过10个层次来考虑容器安全- 包括容器堆栈层（比如容器主机和注册），容器生命周期（API管理）。有关10层的细节信息以及如何应用在K8S这样的容器编排工具，请参阅Newcomer的播客或者白皮书 https://www.redhat.com/en/enga ... yaAAA

空想#3编排工具让缩放变得易如反掌

事实：虽然很多软件专业人士都认为K8S这样的容器编排引擎对于容器扩展性来说是必不可少的，但是认为编排工具能立即让缩放变得简单是错误的，特别是当你第一次在生产环境中使用它。

Sumo Logic公司的高级技术产品经理 Frank Reno认为“自动缩放改变了一切，数据越来越大，你的监控系统需要根据数据量来扩展。在运行成产环境之前，K8S的所有组件都不能被很好的了解。毕竟确保K8S系统的健康运行，API服务器和其他控制组件能根据需求缩放不是自动的。

开发和测试环境让事情变得过于简单，而真正的环境需要这样，或那样的需求，并且需要一直维护。

“在开发测试环境可以非常简单跳过一些基础设置，比如确保你能用到特定的资源，并且限制请求”Reno说，“如果在生产环境不这样设置，你的好日子就算到头了”

向上或向下扩展群集是一个很好的例子，当你在本地进行实验时，它可能看起来很简单，但在生产环境中缩放变得明显更具挑战性。

“生产集群，与开发或模拟集群相反，在扩展方面遇到更多的痛点，” WhiteSource的首席执行官Rami Sass说。 “尽管应用程序的横向扩展在Kubernetes中非常简单，但DevOps [团队]还需要考虑其它方面，特别是保持服务在线的同时扩展基础架构。 重要的是确保主要服务，负责漏洞和安全的报警系统分布在群集的节点上，并使之有状态，这样在向下扩展时不会丢失任何数据。“

和其它挑战一样，这是合理规划和利用资源的问题。

“了解你的缩放需求，为它们做计划，更重要的是：做测试！” Coda Global公司的Bhagirathan提出了建议。“你的生产环境应该能承担更高的负荷”

空想#4: K8S在哪运行都没区别

现实：正如同在开发人员的笔记本上运行K8S和生产环境中运行K8S有区别一样，环境会导致差别。

一个常见的误解是（假设）Kubernetes在本地运行正常，那么它可以在任何地方正常工作，”Bitnami的首席执行官兼联合创始人Daniel Lopez说道，他用云平台之间的差异来应证这个假设的是错误的。 “虽然Kubernetes如果能够有效地提供一致的环境，但供应商之间仍存在显着差异 。

Lopez还指出，生产环境的部署需要那些不只作用于本地的组件，比如监控，日志和证书管理，以及凭据。你需要考虑这些因素，这也是导致开发/测试和生产环境之间差距扩大的关键问题之一。

这也是综合性问题，不仅K8S需要考虑,也包括容器和微服务，更广泛的来说，在混合云和多云环境也需要考虑。

“公共 - 私有部署比纸面上看起来更棘手，因为许多必要的服务，如负载平衡和防火墙，都是专有的。 在实验室中运行良好的容器在具有不同工具的云环境中运行可能根本不工作 - 或者至少不安全 -，“Avi Networks的Rajagopalan说。 “这就是为什么像Istio这样的服务网格技术受到如此多关注的原因。 不管容器运行在哪，他们都提供相同的应用程序服务，因此你不必考虑基础架构 - 这是容器最重要的一点“。