【编者的话】当容器和Kubernetes的IT管理团队把本地变更部署在消费环境的时分，往往面对很多要学习的东西。

最近我们廓清了一些大家在停止Kubernetes实验的时分所见到的常见的曲解。其中最大的一个曲解就是：在消费环境中运转Kubernetes和开发测试环境并无两样。

答案：是不一样的。

Avi Network公司的结合开创人兼首席技术官Ranga Rajagopalan以为：“关于Kubernetes，容器和微效劳来说，实验环境和消费环境有庞大的不同。复杂的运转和安全、牢靠的运转是不一样的”。

Ranga Rajagopalan的意见中有一个重要的论点：上述成绩不只仅只是存在于Kubernetes，异样也存在于容器和微效劳。部署容器相对复杂;而在消费环境运维和缩放容器(包括容器化的微效劳)是成绩复杂的缘由。

容器和容器的编排工具通常都是成套出现的。New Stack公司之行停止了一项调查，调查发现当组织为了处置运维所面对的应战，去寻觅更弱小的技术的时分，容器反过去推进了Kubernetes的普及。虽然也有其他的工具，Kubernetes还是快速成为了编排工具和选择的代名词。像Rajagopalan说的那样，在沙箱里运转Kubernetes和在消费环境中运转Kubernetes有庞大的不同。

通常IT专业人士和团队运维小规模的Kubernetes环境，当这个环境转向消费环境部署的时分，这些人将有很多东西需求面对和学习。“你一定想在上消费环境之前扫清这些常见的曲解，这里有IT指导者和团队需求了解的知识”。

误区1：在开发测试环境运转Kubernetes能帮你片面了解运维的需求

理想：在开发测试环境运转Kubernetes能帮你走一些捷径，你可以不必面抵消费环境所带来的运营负载。

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

Portworx的结合开创人兼CEO Murli Thirumale将开发测试环境和消费环境的不同与矫捷和牢靠，高功用的矫捷做了类比。

“开发团队的目的是在开发和测试新运用和代码的时分完成运用的矫捷;而同时运维人员的目的是运用和数据的牢靠性，可伸缩性，安全性和功用。后者需求一个弱小的，企业级的，经过测试和验证的平台。”

自动化曾经成为了在消费环境中采用Kubernetes(或许深刻所说的容器)的迫切需求。

Coda Global的架构师Ranjan Bhagitrathan以为“消费集群必须经过自动化部署。消费集群一定要具有可复制性，从而完成全体消费环境的分歧性，同时可复制性也对灾难恢复有所协助”。

Bhagitrathan同时也以为版本控制抵消费环境运维至关重要，“对一切事情停止版本控制，比如效劳部署的配置文件，策略等等，假设能够也包括完成基础架构即代码的代码命令。这能确保你的环境是相反的。同时也要确保容器镜像有版本控制，不要只是用“最新镜像”这样的名字来个镜像打标签，这样很容易惹起混乱”。

误区2：你曾经失掉了牢靠性和安全性

理想：假设你只在非消费环境实验过Kubernetes。你能够没取得牢靠性和安全性，或许目前没有。

好音讯是你最终会做到，由于上消费环境之前，需求做规划和架构设计。

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

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

“在测试开发环境中开放一切的网络端口是十分不错的，很能够一切的效劳都能相互衔接。Kubernetes默许设置一切网络衔接开放。但这不是一个成熟消费环境所应有的设置，一旦步入消费阶段，停机和大规模攻击会给业务带来风险“。

“当任务转移到容器和微效劳的时分，构建高牢靠，高可用的系统是十分有价值的任务。编排工具帮你完成这部分任务，但这并不举手可得。安全性也是一样。”

“我们要做很多事情来增加针对Kubernetes的攻击，经过增强网络策略来实施最低权限模型，并且限制效劳只和需求的效劳衔接是十分关键的。”

在消费环境中，容器镜像的安全破绽可以很快变的很严重，要挟能够是受限的或许基本不在本地。(whereas the threat may be limited or non-existent locally.)

Bhagirathan说，“要留意你的容器镜像采用的基础镜像是什么，尽能够用受信任的官方镜像或许本人入手制造。用未知的镜像也容许以帮你很快的跑起效劳，但也带来了安全成绩。比如，你一定不想你的Kubernetes系统给别人挖比特币做贡献。”

红帽公司的安全策略师Kirsten Newcomer鼓舞人们经过10个层次来思索容器安全——包括容器堆栈层(比如容器主机和注册)，容器生命周期(API管理)。有关10层的细节信息以及如何运用在Kubernetes这样的容器编排工具，请参阅Newcomer的播客或许白皮书：https://www.redhat.com/en/enga ... yaAAA。

误区3：编排工具让缩放变得易如反掌

理想：虽然很多软件专业人士都以为Kubernetes这样的容器编排引擎关于容器扩展性来说是必不可少的，但是以为编排工具能立刻让缩放变得复杂是错误的，特别是当你第一次在消费环境中运用它时。

Sumo Logic公司的初级技术产品经理Frank Reno以为“自动缩放改动了一切，数据越来越大，你的监控系统需求依据数据量来扩展。在消费环境运转之前，Kubernetes的一切组件都不能被很好的了解。毕竟确保Kubernetes系统的安康运转，API效劳器和其他控制组件能依据需求缩放而不是自动的。”

开发和测试环境让事情变得过于复杂，而真正的环境需求这样，或那样的需求，并且需求不断维护。

“在开发测试环境可以十分复杂跳过一些基础设置，比如确保你能用到特定的资源，并且限制央求，”Reno说，“假设在消费环境不这样设置，你的好日子就算到头了。”

向上或向下扩展群集是一个很好的例子，当你在本地停止实验时，它能够看起来很复杂，但在消费环境中缩放变得清楚更具应战性。

(责任编辑：admin)