1同行回答
开源容器编排引擎Kubernetes不是一个管理平台，也不该被认为是一个管理平台。整个编排的要点就是确实的自动化系统来帮助部署和大规模应用的管理，不需要在每一个地方和每一步中介入人力。如果你使用的工具和Kubernetes不支持自动化，那么你就没有真正利用编排的优势。
为了实现这个目的，以下7种方法能够让你在生产中自动化Kubernetes集群。
01
日志
Logging
任何Kubernetes生产环境都严重依赖log。在Kenzan，我们特地尝试将平台日志从应用日志中分离。实现这个可能需要非常不同的工具和应用，或者可以通过在日志中进行过滤和标记来完成。与任何分布式系统一样，日志为精准追踪特定的调用提供非常重要的依据，即使它们在不同的微服务上，也能够识别出根本原因。
02
自我修复
Self-Healing
我们相信，你的系统几乎不可能在没有自我修复能力的情况下实现高的正常运行时间率，特别是在一个分布式环境中。Kubernetes可以定期的监控pod和容器的健康，并且立即采取行动解决遇到的问题。Kubernetes本地识别的两种对象类型是podstatus和containerstatus。
容器探查（活性调查和准备情况调查）让你定义你希望Kubernetes如何监视容器是否存在和准备就绪。准备情况调查格外有用，因为它实际上会离开pods，但如果探测失败，就不会为它们提供流量服务。
但是需要注意的是，当然自我修复功能是很好的（例如每半小时重启），它们也会掩盖应用的问题。需要足够强大的监控和日志功能来发现任何可能存在问题。
03
弹性测试
Resilience Testing
根据应用测试的需要，弹性测试应该成为平台的一部分。在应用的任何层级失败都是可恢复的，因此不会有任何停机时间。在我们的经验中，只有在开发团队预先知道他们的工作将通过广泛的弹性测试进行时，防弹应用才可行。
虽然能通过最简单的人工方法来进行一类弹性测试，例如人工关闭数据库或任意删除pods，我们的经验证明了这些方法在被自动化时更有效。虽然Netflix的Chaos Monkey是个非常强大、有用的弹性测试工具，在Amazon Web Service中运行，但它不是为了Kubernetes构建的。庆幸的是，在Kubernetes领域中有新兴的弹性测试框架，其中两个是fabric8 Chaos Monkey（fabric8集成开发环境的一部分）和kube-monkey。
04
常规审计
Routine Auditing
无论你放了多少检查和平衡，Kubernetes生产环境将从常规维护和审计中受益。这些审计将覆盖题目而正常的监控则不会覆盖。传统上，审计作为人工流程来进行，但是这个空间中的自动化工具是快速和显著改进的。
05
自动缩放
Autoscaling
对于Kubernetes，缩放通常意味着以下两件事之一：
· 缩放pods
· 在集群中缩放节点
缩放pods是最常见的扩展形式之一。这将增加更多的服务实例，并让它们准备开始接受流量。典型的pod层级扩展是用Heapster度量来决定是否需要创建新的实例。我们实际上设置最小pod数很低，相信Kubernetes Horizontal Pod Autoscaler来正确设置最佳副本数量。我们总是设置每个集群最小值大于1个副本，避免单点失败情况。
扩展节点是比较少见的情况，但是对于高弹性的应用来说是非常有用的扩展机制。节点扩展将需要支持IaaS（AWS，GCP等等）来扩展和注册到Kubernetes集群中。这个过程可以人工完成，尽管我们不建议这么做。通常我们用工具来自动化单个节点的缩放（例如Kubernetes Repo）。节点级的autoscaler主要将做两件事，第一个是当需要时增加更多的节点，第二个是移除未充分使用的节点。
06
资源分配
Resource Quotas
资源分配可以让你在Kubernetes平台里限制namespace，确保一个应用不会消耗掉所有资源和影响其他应用。设置资源分配有一点挑战。在我们的经验中，我们发现通过预期负载来分解namespace和使用一个比例来计算集群的百分比是最有策略的开始。运行Heapster允许使用kubectl top {node | pod} 命令，它显示了当前节点或pod资源使用，有时候对于分配也有帮助。从这点来说，如果你的分割是对的，就使用监控和审计来确定。
07
容器资源限制
Container Resource Constraints
搞清楚单个容器或pod需要多少资源已经变成一项艺术。以前，开发人员团队已经把他们的评估方法变的比需要的更强。我们尝试执行一些层级的负载测试来了解它是如何失败的，然后适当分配资源。Netfilix创造这个方法“挤压测试”。