注意事项 佩雷夫 ：当我们的团队领导者在IBM Cloud博客上看到这些资料时，他们所经历的兴奋是不言而喻的，这是传说中的十二要素应用程序的一种“扩展”。 作者提出的问题不仅是耳边的问题，而且是至关重要的，即 与日常生活息息相关。 他们的理解不仅对DevOps工程师有用，对于开发在Kubernetes中运行的现代应用程序的开发人员也很有用。众所周知的
12要素应用方法是用于开发微服务的一组明确定义的规则。 它们被广泛用于运行，扩展和部署应用程序。 在IBM Cloud Private平台上，我们在开发容器化应用程序时遵循相同的12条原则。 文章“
Kubernetes和12要素应用程序 ”讨论了使用这12个要素的细节（Kubernetes容器编排模型支持它们）。
考虑开发在Kubernetes的控制下工作的容器化微服务的原理，我们得出以下结论：以上12个因素是完全正确的，但其他因素对于组织生产环境也非常重要：
- 可观察的
- 可预测性 （可计划的） ；
- 可升级性（可升级） ；
- 最低权限
- 可控性 （可审核） ；
- 安全 （安全） ；
- 可测的
让我们仔细研究这些原则，并尝试评估其重要性。 为了保持一致性，我们将它们添加到现有的-相应地，我们将从XIII开始...
原则十三：可观察性
应用程序应提供有关其当前状态和指标的信息。分布式系统可能难以管理，因为许多微服务已集成到应用程序中。 实际上，各种齿轮必须协调运动才能使机构（应用程序）正常工作。 如果其中一项微服务发生故障，则系统应自动检测到并进行纠正。 Kubernetes提供了出色的救援机制，例如准备和
活跃性测试 。
在他们的帮助下，Kubernetes可以确保该应用程序准备好接收流量。 如果准备就绪失败，Kubernetes将停止向该Pod发送流量，直到下一次测试表明Pod已准备好为止。
假设我们有一个包含3个微服务的应用程序：前端，业务逻辑和数据库。 为了使应用程序能够正常工作，在接受流量之前，前端必须确保业务逻辑和数据库已准备就绪。 这可以使用准备测试来完成-它使您可以确保所有依赖项都在起作用。
动画显示，直到准备就绪测试表明准备就绪为止，才会发送对Pod的请求：
运行中的就绪测试：Kubernetes使用就绪探针来检查Pod是否准备好接收流量测试共有三种类型：使用HTTP，TCP请求和命令。 您可以控制测试的配置，例如，指示启动频率，成功/失败阈值以及等待答案的时间。 对于活动度测试，您需要设置一个非常重要的参数
initialDelaySeconds 。 确保仅在应用程序就绪后才开始测试。 如果此参数设置不正确，应用程序将不断重启。 实施方法如下：
livenessProbe: # an http probe httpGet: path: /readiness port: 8080 initialDelaySeconds: 20 periodSeconds: 5
通过活动性测试，Kubernetes会检查您的应用程序是否正在运行。 如果应用程序正常运行，则Kubernetes不会执行任何操作。 如果它“死了”，Kubernetes将移除该吊舱并启动一个新的吊舱作为回报。 这对应于无状态微服务需求及其可回收性（
因子IX，可处置性 ）。 下面的动画说明了Kubernetes在未通过活力测试后重新启动Pod的情况：
进行活泼性测试：Kubernetes检查吊舱是否“活着”这些测试的巨大优势在于，您可以按任何顺序部署应用程序，而不必担心依赖关系。
但是，我们发现这些测试不足以用于生产环境。 通常，应用程序具有自己的指标，需要跟踪这些指标，例如每秒的事务数。 客户端为其设置阈值并配置通知。 IBM Cloud Private通过基于角色的访问控制系统，以高度安全的Prometheus和Grafana监视堆栈来填补这一空白。 有关更多信息，请参阅“
IBM Cloud Private集群监视”部分。
Prometheus从端点指标收集目标数据。 您的应用程序应使用以下注释指定端点指标：
prometheus.io/scrape: 'true'
之后，Prometheus会自动检测端点并从端点收集度量（如以下动画所示）：
定制指标的收集注意事项 佩雷夫 ：朝相反的方向旋转箭头会更正确，因为Prometheus会走动并轮询端点，而Grafana本身会从Prometheus获取数据，但是从一般的角度来看，这并不是那么关键。原则十四：可预测性
应用程序应提供资源需求的可预测性。想象一下，有一个指南选择了您的团队来尝试Kubernetes项目。 您努力创建一个合适的环境。 结果是一个演示示范性响应时间和性能的应用程序。 然后另一个团队加入了工作。 她创建了自己的应用程序，并在相同的环境中启动了它。 启动第二个应用程序后，第一个应用程序的性能突然下降。 在这种情况下，应在可用于容器的计算资源（CPU和内存）中查找此行为的原因。 他们缺乏的可能性很高。 问题出现了：如何保证应用程序所需的计算资源分配？
Kubernetes有一个很好的选择，它允许您设置资源的最小值和容器的限制。 最低保证。 如果容器需要资源，则Kubernetes仅在该资源可以提供的主机上运行它。 另一方面，上限确保容器的食欲不超过特定值。
容器的最低要求和限制以下YAML代码片段显示了计算资源的调整：
resources: requests: memory: "64Mi" cpu: "150m" limits: memory: "64Mi" cpu: "200m"
注意事项 佩雷夫 ：有关在Kubernetes中提供资源，请求和限制的更多信息，请参阅我们最近的报告及其评论“ Kubernetes中的自动缩放和资源管理 ”以及K8s文档 。对于生产环境中的管理员来说，另一个有趣的机会是为
命名空间设置配额。 如果设置了配额，Kubernetes将不会创建未在此命名空间中为其定义请求/限制的容器。 下图显示了为命名空间设置配额的示例：
命名空间的配额原则十五。 可更新性
应用程序应更新前几代的数据格式。通常，需要修补运行中的生产应用程序，以消除漏洞或扩展功能。 重要的是，更新必须在不中断工作的情况下进行。 Kubernetes提供
了一种滚动更新
机制 ，使您无需停机即可更新应用程序。 使用此机制，您可以一次按pod进行更新，而无需停止整个服务。 这是此过程的示意图（在其上，应用程序更新为第二版本）：
相应的YAML描述的示例：
minReadySeconds: 5 strategy: # , type: RollingUpdate rollingUpdate: maxSurge: 1 maxUnavailable: 1
注意
maxUnavailable和
maxSurge ：
maxUnavailable一个可选参数，用于设置在更新过程中可能不可用的Pod的最大数量。 尽管它是可选的，但仍然值得设置一个特定的值来保证服务的可用性。maxSurge是另一个可选但很关键的参数。 它设置了可以创建的豆荚的最大数量，超出了所需数量。
原则十六：最低特权
容器应至少具有特权。这听起来很悲观，但是您应该将容器中的每个分辨率视为潜在的漏洞（请参见插图）。 例如，如果容器以root用户身份运行，则有权访问它的任何人都可以在其中注入恶意进程。 Kubernetes提供了
Pod安全策略 （PSP），以限制对文件系统，主机端口，Linux功能等的访问。 IBM Cloud Private提供了一组现成的PSP，当在命名空间中配置容器时，它们会绑定到容器。 有关更多信息，请参见
将名称空间与Pod安全策略结合使用 。
所有解决方案都是潜在的攻击手段原则十七：可控性
您需要知道所有关键任务操作的人员，时间，地点和时间。可控性对于使用Kubernetes集群或应用程序进行的任何操作都是至关重要的。 例如，如果应用程序处理信用卡交易，则需要启用审核才能对每个交易进行控制跟踪。 IBM Cloud Private使用行业标准的
Cloud Auditing Data Federation （CADF），它对于特定的云实现是不变的。 有关更多信息，请参阅
IBM Cloud Private中的审计日志记录 。
CADF事件包含以下数据：
initiator_id执行该操作的用户的ID；target_uri目标CADF URI（例如：数据/安全性/项目）；action要执行的action ，通常是operation: resource_type 。
原则十八：安全性（标识，网络，范围，证书）
有必要保护应用程序和资源免受陌生人的侵害。此项应另作文章。 只需说生产应用程序需要端到端保护就可以了。 IBM Cloud Private采取以下措施来确保生产环境的安全性：
- 认证：身份验证；
- 授权：经过身份验证的用户访问权限检查；
- 证书管理：使用数字证书，包括创建，存储和续订；
- 数据保护：确保传输和存储数据的安全性；
- 网络安全性和隔离性：防止未经授权的用户和进程访问网络；
- 漏洞顾问：确定图像中的漏洞；
- 突变顾问：检测容器中的突变。
有关更多信息，请参阅《
IBM Cloud Private Security Guide》 。
特别值得注意的是证书管理器。
IBM Cloud Private的这项服务基于
Jetstack开源项目。 通过证书管理器，您可以为在IBM Cloud Private上运行的服务颁发和管理证书。 它支持公共证书和自签名证书，并与
kubectl和基于角色的访问控制完全集成。
原则十九：可测量性
就部门之间的配额和结算而言，应可测量该应用程序的使用。最终，公司必须支付IT成本（请参见下图）。 专用于运行容器的计算资源必须是可衡量的，并且使用群集的组织必须负责。 确保遵循原则XIV-可预测性。 IBM Cloud Private提供了一项
会计服务 ，该
服务收集每个容器的计算资源数据，并在命名空间级别将它们组合起来以进行进一步的计算（作为对价或对价的一部分）。
应用程序的使用必须是可衡量的结论
我希望您喜欢本文中提出的主题，并指出了您已经在使用的因素并考虑了那些仍在观望中的因素。
有关更多信息，我建议您熟悉我们在上海KubeCon 2019
上的表演
录制 。 在其中，
Michael Elder和
我讨论了基于Kubernetes的容器编排的12 + 7原则。
译者的PS
另请参阅我们的博客：