构建生产就绪的K8S集群的16点清单

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的指南。