共计 5153 个字符，预计需要花费 13 分钟才能阅读完成。
Kubernetes 是用于构建高度可扩大零碎的弱小工具。后果，许多公司曾经开始或正在打算应用它来协调生产服务。可怜的是，像大多数弱小的技术一样，Kubernetes 也很简单。咱们整顿了以下清单，以帮忙你生产环境最佳实际 Kubernetes(Kubernetes 生产环境最佳实际)。
容器最佳实际
Kubernetes 提供了一种编排容器化服务的办法，因而，如果您没有按程序实际你的容器，那么集群一开始就不会处于良好状态。请依照以下提醒开始。
1、应用精简根底镜像
what：容器是内置在零碎镜像中的应用程序堆栈。从业务逻辑到内核的所有内容都打包在一起。最小的镜像会占用尽可能多的 OS，并迫使您显式增加所需的任何组件。
why：仅在您的容器中包含要应用的软件，同时具备性能和安全性方面的益处。磁盘上的字节数更少，复制镜像的网络流量更少，并且潜在的攻击者无法访问的工具也更少。
how：Alpine Linux 是一个风行的抉择，并具备宽泛的反对。
2、应用提供最佳失常运行工夫的注册表
what：注册表是镜像的存储库，使这些镜像可供下载和启动。在指定部署配置时，您须要指定从何处获取门路为 <registry> / <remote name>：<tag> 的镜像：
why：您的集群须要镜像去运行。
how：大多数云提供商都提供公有镜像注册表服务：Google 提供 Google 容器注册表，AWS 提供 Amazon ECR，Microsoft 提供 Azure 容器注册表。
认真调研，并抉择提供最佳失常运行工夫的私人注册表。因为您的群集将依附您的注册表来启动软件的较新版本，因而任何停机工夫都将阻止对正在运行的服务进行更新。
3、应用 ImagePullSecrets 对您的注册表进行身份验证
what：ImagePullSecrets 是 Kubernetes 对象，可让您的群集通过注册表进行身份验证，因而注册表能够抉择谁能够下载镜像。
why：如果您的注册表足够公开，能够让集群从中提取镜像，则表明注册表足够公开，须要身份验证。
how：Kubernetes 网站在配置 ImagePullSecrets 方面有很好的演练，该示例应用 Docker 作为示例注册表。
治理你的集群
微服务实质上是一团糟。应用微服务的许多益处来自在服务级别上强制职责拆散，无效地为后端的各个组件创立了形象。一些很好的例子是运行与业务逻辑拆散的数据库，运行软件的独自开发和生产版本，或拆散出程度可伸缩的流程。
具备不同服务执行不同职责的阴暗面是，它们不能被平等看待。值得庆幸的是，Kubernetes 为您提供了许多解决此问题的工具。
4、应用命名空间隔离环境
what：命名空间是 Kubernetes 中最根本，最弱小的分组机制。它们简直像虚构集群一样工作。默认状况下，Kubernetes 中的大多数对象仅限于一次影响单个名称空间。
why：大多数对象都是在命名空间范畴内定义的，因而您必须应用命名空间。鉴于它们提供了弱小的隔离性，因而它们非常适合隔离具备不同目标的环境，例如用户服务的生产环境和严格用于测试的环境，或者拆散反对单个应用程序的不同服务堆栈，例如放弃平安解决方案的工作负载与您本人的应用程序离开。一个好的教训法令是按资源分配划分名称空间：如果两组微服务将须要不同的资源池，请将它们放在独自的名称空间中。
how：它是大多数对象类型的元数据的一部分：
请留神，您应该始终创立本人的名称空间，而不要依赖“默认”名称空间。Kubernetes 的默认设置通常会为开发人员优化以最小的摩擦，这通常意味着甚至放弃最根本的安全措施。
5、通过 Labels 治理您的集群
what：Labels 是组织集群的最根本且可扩大的办法。它们容许您创立用于分隔 Kubernetes 对象的任意 key：value 对。例如，您能够创立一个标签密钥，将解决敏感信息的服务与不解决敏感信息的服务区离开。
why：如前所述，Kubernetes 应用标签进行组织，但更具体地说，它们用于抉择。这意味着，当您想给 Kubernetes 对象援用某个命名空间中的一组对象时（例如通知网络策略容许哪些服务互相通信），请应用它们的标签。因为它们代表了这种开放式组织类型，因而请尽最大致力使事件简单化，并且仅在须要选择权的中央创立标签。
how：标签是一个简略的规范字段，您能够将其增加到 YAML 文件中：
6、应用正文来跟踪重要的零碎更改等
what：正文是能够附加到 pod 的任意键值元数据，就像标签一样。然而，Kubernetes 不会读取或解决批注，因而围绕您能够和不能应用批注进行正文的规定相当宽松，并且不能用于抉择。
why：它们可帮忙您跟踪容器化应用程序的某些重要性能，例如版本号或首次启动的日期和工夫。仅在 Kubernetes 的上下文中，正文是一种无能为力的结构，然而当用于跟踪重要的零碎更改时，正文能够成为开发人员和经营团队的资产。
how：正文是相似于标签的规格字段。
让你的集群更加平安
好了，您曾经建设了集群并按所需形式组织了 - 当初呢？好吧，接下来是要确保一些平安。您可能会破费毕生的工夫来学习，但仍未发现有人能够侵入您零碎的所有形式。博客文章的内容空间要比毕生少得多，因而您必须满足一些强烈的倡议。
7、应用 RBAC 施行访问控制
what：RBAC（基于角色的访问控制）使您能够管制谁能够查看或批改群集的不同方面。
why：如果要遵循最小特权准则，则须要设置 RBAC 来限度群集用户和部署可能执行的操作。
how：如果要设置本人的集群（即不应用托管的 Kube 服务），请确保应用 ”–authorization-mode = Node，RBAC“启动您的 kube apiserver。如果应用托管的 Kubernetes 例如，您能够通过查问用于启动 kube apiserver 的命令来查看它是否设置为应用 RBAC。惟一通用的查看办法是在 kubectl cluster-info dump 的输入中查找“–authorization-mode …”。
RBAC 关上后，您须要更改默认权限以适宜您的需要。Kubernetes 我的项目站点在此处提供了无关设置角色和 RoleBindings 的演练。托管的 Kubernetes 服务须要启用 RBAC 的自定义步骤 - 请参阅 Google 的 GKE 指南或 Amazon 的 AKS 指南。
8、应用 Pod 安全策略避免危险行为
what：Pod 安全策略是一种资源，十分相似于 Deployment 或 Role，能够通过 kubectl 以雷同的形式创立和更新。每个都有一个标记汇合，可用来避免集群中特定的不平安行为。
why：如果创立 Kubernetes 的人认为限度这些行为足够重要，能够创立一个非凡的对象来解决它，那么它们很重要。
how：让他们工作可能会令人丧气。我倡议启动并运行 RBAC，而后在此处查看 Kubernetes 我的项目的指南。在我看来，最重要的应用是避免特权容器和对主机文件系统的写访问，因为它们代表了容器形象中一些较透露的局部。
9、应用网络策略施行网络管制 / 防火墙
what：网络策略是容许您明确申明容许哪些流量的对象，而 Kubernetes 将阻止所有其余不符合标准的流量。
why：限度群集中的网络流量是一项根本且重要的安全措施。默认状况下，Kubernetes 启用所有服务之间的开放式通信。保留此“默认凋谢”配置意味着与 Internet 连贯的服务与存储敏感信息的数据库仅一步之遥。
how：有一篇文章写的很好，具体详情查看这里。
10、应用 Secrets 来存储和治理必要的敏感信息
what：Secrets 是您如何在 Kubernetes 中存储敏感数据，包含明码，证书和令牌。
why：无论您是施行 TLS 还是限度拜访，您的服务都可能须要互相认证，与其余第三方服务或您的用户进行认证。
how：Kubernetes 我的项目在此处提供了指南。一个要害倡议：防止将秘密作为环境变量加载，因为在您的环境中领有秘密数据通常是不平安的。相同，将秘密装入容器中的只读卷中 - 您能够在本 Use Secrets 中找到一个示例。
11、应用镜像扫描辨认和修复镜像破绽
what：扫描仪查看镜像中装置的组件。从操作系统到应用程序堆栈的所有内容。扫描程序对于找出镜像所蕴含的软件版本中存在哪些破绽十分有用。
why：破绽始终在风行的开源软件包中发现。一些驰名的例子是 Heartbleed 和 Shellshock。您将想晓得这些破绽在零碎中的什么地位，以便您晓得哪些镜像可能须要更新。
how：扫描仪是基础设施中相当常见的局部 - 大多数云提供商都提供了产品。如果您想本人托管一些货色，那么开源 Clair 我的项目是一个受欢迎的抉择。
放弃集群稳固
Kubernetes 代表很高的技术栈。您领有在嵌入式内核上运行的应用程序，在 VM 中运行的应用程序（在某些状况下甚至在裸机上），以及 Kubernetes 本人的服务共享硬件。思考到所有这些因素，在物理和虚构畛域中很多事件都会出错，因而尽可能升高开发周期的危险十分重要。Kubernetes 四周的生态系统曾经开发了一系列最佳实际，以使事件尽可能保持一致。
12、遵循 CI / CD 办法
what：继续集成 / 继续部署是一种过程哲学。置信对代码库进行的每次批改都应减少增量值，并筹备投入生产。因而，如果代码库中的某些内容产生了更改，则可能要启动服务的新版本，以运行测试。
why：遵循 CI / CD 能够帮忙您的工程团队在日常工作中牢记品质。如果呈现问题，修复问题将成为整个团队的事不宜迟，因为尔后依赖于已合成的提交的所有更改也将被合成。
how：因为云部署软件的衰亡，CI / CD 越来越风行。因而，您能够从托管或自托管的泛滥杰出产品中进行抉择。如果您的团队比拟小，我建议您采纳托管路线，因为节俭的工夫和精力相对值得您付出额定的费用。
13、应用 Canary 办法进行更新
what：Canary 是一种将服务更改从代码库中的提交带给用户的办法。您启动了一个运行最新版本的新实例，而后将用户迟缓迁徙到新实例，从而逐步取得了对更新的信念，而不是一次全副替换。
why：无论您的单元测试和集成测试有多宽泛，它们都无奈齐全模仿生产中的运行 - 总是有可能某些性能无奈按预期运行。应用金丝雀能够限度用户接触这些问题。
how：Kubernetes 的可扩展性提供了许多路径来逐渐推出服务更新。最间接的办法是创立一个独自的部署，与以后正在运行的实例共享一个负载平衡器。这个想法是您扩大新的部署，同时缩减旧的部署，直到所有正在运行的实例都是新版本。
14、施行监控并将其与 SIEM 集成
what：监督意味着跟踪和记录您的服务正在做什么。
why：让咱们面对现实吧 - 不论您的开发人员如许杰出，无论您的平安专家如何致力地施展他们的聪明才智，事件都会出错。当他们这样做时，您将想晓得产生了什么，以确保您不会两次犯雷同的谬误。
how：胜利监督服务有两个步骤 - 须要对代码进行检测，并且须要将该检测的输入馈送到某个中央以进行存储，检索和剖析。执行检测的形式在很大水平上取决于您的工具链，然而疾速的网络搜寻应该能够让您有所作为。就存储输入而言，除非您有专门知识或需要，否则我倡议应用托管 SIEM（例如 Splunk 或 Sumo Logic）- 依据我的教训，DIY 始终是与任何存储相干的冀望工夫和精力的 10 倍。
深度倡议
一旦集群达到肯定规模后，您将发现手动执行所有最佳做法将变得不再可行，后果将给零碎的安全性和稳定性带来挑战。超过此阈值后，请思考以下主题：
15、应用服务网格治理服务间通信
what：服务网格是治理服务间通信的一种办法，能够无效地创立在施行服务时应用的虚构网络。
why：应用服务网格能够加重治理群集的一些较繁琐的方面，例如确保对通信进行正确的加密。
how：依据您对服务网格的抉择，启动和运行的复杂性可能千差万别。作为最罕用的服务网格，Istio 仿佛正在蓬勃发展，并且您的配置过程将在很大水平上取决于您的工作负载。
一个正告：如果您须要采纳一个服务网格，请尽早采纳它而不是稍后采纳它 - 逐步扭转集群中的通信款式可能会十分苦楚。
16、应用准入控制器解锁 Kubernetes 中的高级性能
what：准入控制器是一种很好的万能工具，可用于治理集群中产生的所有。它们容许您设置 Kubernetes 在启动时将参考的 Webhook。它们有两种模式：变异和验证。渐变准入控制器会在部署启动之前更改其配置。验证准入控制器会与您的 webhook 统一，以容许启动给定的部署。
why：它们的用例宽泛且数量泛滥–它们提供了一种通过自行开发的逻辑和限度来迭代地进步集群稳定性的好办法。
how：查看无关如何开始应用 Admission Controllers 的指南。
起源：开源 Linux
