建设 Kubernetes 生产环境的 16条建议

集群的最基本且可扩展的方法。它们容许您建立用于分隔Kubernetes对象的任意key：value对。例如，您能够建立一个标签密钥，将处理敏感信息的服务与不处理敏感信息的服务区分开。

why：如前所述，Kubernetes使用标签进行组织，但更具体地说，它们用于选择。这意味着，当您想给Kubernetes对象引用某个命名空间中的一组对象时（例如告诉网络策略容许哪些服务相互通讯），请使用它们的标签。因为它们表明了这种开放式组织类型，所以请尽最大努力使事情简单化，而且仅在须要选择权的地方建立标签。

how：标签是一个简单的规范字段，您能够将其添加到YAML文件中：

六、使用注释来跟踪重要的系统更改等

what：注释是能够附加到pod的任意键值元数据，就像标签同样。可是，Kubernetes不会读取或处理批注，所以围绕您能够和不能使用批注进行注释的规则至关宽松，而且不能用于选择。

why：它们可帮助您跟踪容器化应用程序的某些重要功能，例如版本号或首次启动的日期和时间。仅在Kubernetes的上下文中，注释是一种无能为力的构造，可是当用于跟踪重要的系统更改时，注释能够成为开发人员和运营团队的资产。

how：注释是相似于标签的规格字段。

让你的集群更加安全

好了，您已经创建了集群并按所需方式组织了-如今呢？好吧，接下来是要确保一些安全。您可能会花费一辈子的时间来学习，但仍未发现有人能够侵入您系统的全部方式。博客文章的内容空间要比一辈子少得多，所以您必须知足一些强烈的建议。

七、使用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指南。

八、使用Pod安全策略防止危险行为

what：Pod安全策略是一种资源，很是相似于Deployment或Role，能够经过kubectl以相同的方式建立和更新。每一个都有一个标志集合，可用来防止集群中特定的不安全行为。

why：若是建立Kubernetes的人认为限制这些行为足够重要，能够建立一个特殊的对象来处理它，那么它们很重要。

how：让他们工做可能会使人沮丧。我建议启动并运行RBAC，而后在此处查看Kubernetes项目的指南。在我看来，最重要的使用是防止特权容器和对主机文件系统的写访问，由于它们表明了容器抽象中一些较泄漏的部分。

九、使用网络策略实施网络控制/防火墙

what：网络策略是容许您明确声明容许哪些流量的对象，而Kubernetes将阻止全部其余不符合标准的流量。

why：限制群集中的网络流量是一项基本且重要的安全措施。默认状况下，Kubernetes启用全部服务之间的开放式通讯。保留此“默认开放”配置意味着与Internet链接的服务与存储敏感信息的数据库仅一步之遥。

how：有一篇文章写的很好，具体详情查看这里。

十、使用Secrets来存储和管理必要的敏感信息

what：Secrets是您如何在Kubernetes中存储敏感数据，包括密码，证书和令牌。

why：不管您是实施TLS仍是限制访问，您的服务均可能须要相互认证，与其余第三方服务或您的用户进行认证。

how：Kubernetes项目在此处提供了指南。一个关键建议：避免将机密做为环境变量加载，由于在您的环境中拥有机密数据一般是不安全的。相反，将机密装入容器中的只读卷中-您能够在本 Use Secrets中找到一个示例。

十一、使用镜像扫描识别和修复镜像漏洞

what：扫描仪检查镜像中安装的组件。从操做系统到应用程序堆栈的全部内容。扫描程序对于找出镜像所包含的软件版本中存在哪些漏洞很是有用。

why：漏洞一直在流行的开源软件包中发现。一些著名的例子是Heartbleed和Shellshock。您将想知道这些漏洞在系统中的什么位置，以便您知道哪些镜像可能须要更新。

how：扫描仪是基础设施中至关常见的部分-大多数云提供商都提供了产品。若是您想本身托管一些东西，那么开源Clair项目是一个受欢迎的选择。

保持集群稳定

Kubernetes表明很高的技术栈。您拥有在嵌入式内核上运行的应用程序，在VM中运行的应用程序（在某些状况下甚至在裸机上），以及Kubernetes本身的服务共享硬件。考虑到全部这些因素，在物理和虚拟领域中不少事情都会出错，所以尽量下降开发周期的风险很是重要。Kubernetes周围的生态系统已经开发了一系列最佳实践，以使事情尽量保持一致。

十二、遵循CI / CD方法

what：持续集成/持续部署是一种过程哲学。相信对代码库进行的每次修改都应增长增量值，并准备投入生产。所以，若是代码库中的某些内容发生了更改，则可能要启动服务的新版本，以运行测试。

why：遵循CI / CD能够帮助您的工程团队在平常工做中牢记质量。若是出现问题，修复问题将成为整个团队的当务之急，由于此后依赖于已分解的提交的全部更改也将被分解。

how：因为云部署软件的兴起，CI / CD愈来愈流行。所以，您能够从托管或自托管的众多出色产品中进行选择。若是您的团队比较小，我建议您采用托管路线，由于节省的时间和精力绝对值得您付出额外的费用。

1三、使用Canary方法进行更新

what：Canary是一种将服务更改从代码库中的提交带给用户的方法。您启动了一个运行最新版本的新实例，而后将用户缓慢迁移到新实例，从而逐渐得到了对更新的信心，而不是一次所有交换。

why：不管您的单元测试和集成测试有多普遍，它们都没法彻底模拟生产中的运行-老是有可能某些功能没法按预期运行。使用金丝雀能够限制用户接触这些问题。

how：Kubernetes的可扩展性提供了许多途径来逐步推出服务更新。最直接的方法是建立一个单独的部署，与当前正在运行的实例共享一个负载平衡器。这个想法是您扩展新的部署，同时缩减旧的部署，直到全部正在运行的实例都是新版本。

1四、实施监控并将其与SIEM集成

what：监视意味着跟踪和记录您的服务正在作什么。

why：让咱们面对现实吧-无论您的开发人员多么出色，不管您的安全专家如何努力地发挥他们的聪明才智，事情都会出错。当他们这样作时，您将想知道发生了什么，以确保您不会两次犯相同的错误。

how：成功监视服务有两个步骤-须要对代码进行检测，而且须要将该检测的输出馈送到某个地方以进行存储，检索和分析。执行检测的方式在很大程度上取决于您的工具链，可是快速的网络搜索应该可让您有所做为。就存储输出而言，除非您有专门知识或需求，不然我建议使用托管SIEM（例如Splunk或Sumo Logic）-根据个人经验，DIY始终是与任何存储相关的指望时间和精力的10倍。

深度建议

一旦集群达到必定规模后，您将发现手动执行全部最佳作法将变得再也不可行，结果将给系统的安全性和稳定性带来挑战。超过此阈值后，请考虑如下主题：

1五、使用服务网格管理服务间通讯

what：服务网格是管理服务间通讯的一种方法，能够有效地建立在实施服务时使用的虚拟网络。

why：使用服务网格能够减轻管理群集的一些较繁琐的方面，例如确保对通讯进行正确的加密。

how：根据您对服务网格的选择，启动和运行的复杂性可能千差万别。做为最经常使用的服务网格，Istio彷佛正在蓬勃发展，而且您的配置过程将在很大程度上取决于您的工做负载。

一个警告：若是您须要采用一个服务网格，请尽早采用它而不是稍后采用它-逐渐改变集群中的通讯样式可能会很是痛苦。

1六、使用准入控制器解锁Kubernetes中的高级功能

what：准入控制器是一种很好的万能工具，可用于管理集群中发生的一切。它们容许您设置Kubernetes在启动时将参考的Webhook。它们有两种形式：变异和验证。突变准入控制器会在部署启动以前更改其配置。验证准入控制器会与您的webhook一致，以容许启动给定的部署。

why：它们的用例普遍且数量众多–它们提供了一种经过自行开发的逻辑和限制来迭代地提升集群稳定性的好方法。

how：查看有关如何开始使用Admission Controllers的指南。

来源：开源Linux