【编者的话】本文是关于在生产中使用Kubernetes系列的一部分。第一部分介绍了Kubernetes和监控工具的基础知识；第二部分涵盖了Kubernetes报警的最佳实践；第三部分对Kubernetes故障排除，特别是服务发现进行了介绍，最后一部分是监控Kubernetes的实际使用案例。
将Docker引入生产环境，既是一门科学，同时也是一门艺术。我们与WayBlazer的Kevin Kuhl和Kevin Cashman一起讨论有关Docker和Kubernetes的监控、选择正确的关注指标、决定使用Kubernetes来运行何种程序以及诊断Kubernetes故障转移中的“多米诺效应”。
Update：在写完这篇文章的一年后，我们与Wayblazer的Kevin Kuhl、Kevin Cashman再次进行了讨论，并在他们的Kubernetes部署安全性方面增加了一些新的有洞察力的细节。
WayBlazer介绍
WayBlazer是世界上第一个专注于向旅游行业提供人工智能技术的认知推荐引擎。结合IBM Watson和专有认知计算技术，WayBlazer的AI技术对旅行者搜索历史提供的线索进行分析，以便为他们的旅行提供个性化的酒店推荐、见解、图像和当地文化。个性化内容与酒店推荐相结合可提高在线参与度并提高旅行者转化率。
该公司总部位于得克萨斯州奥斯汀，由经验丰富的旅游、科技企业家领导，其中包括Travelocity的创始人/ Kayak.com的创始人主席，IBM前任总经理Watson，以及Sabre Hospitality Solutions的前总裁。
你的环境是什么样的？
我们是一家AWS商店，所以可以想象我们会大量使用EC2。 同时我们还使用了许多AWS服务，这些服务易于使用，价格可取，而且管理得很好。 这些都能使我们的生活变得更轻松。 不久之前，我们开始使用Kubernetes，现在我们在EC2节点之上运行了十几个Kubernetes工作节点（有时甚至更多）。 每个节点运行约15-20个容器。 另外，我们有许多Kubernetes命名空间，如prod、test以及project-specific。
在上述环境中，我们运行了许多不同的服务。 我们的前端是JavaScript，API服务在Node.js上运行。 同时Java服务处理主要逻辑，还有一些在Python中运行的辅助应用程序。
我们使用Sysdig Monitor和AWS Cloudwatch来监控集群。我们依靠许多Kubernetes和AWS平台功能来保护集群内的应用程序，但同时也开始使用Sysdig Secure来加强集群的运行时防御能力。
你在Kubernetes内运行一切应用吗？
不是的。 我们的方法是首先说“它应该在Kubernetes中运行吗？”，但在有些领域，我们的答案是否定的。 不在Kubernetes中运行的应用，要么是功能需求不匹配，要么是性能达不到要求。
最显而易见的，我们的无状态服务通常运行在Kubernetes中，这简直是个完美的选择。 然而有状态的服务，例如图形数据库，还不是很适合。 也许使用PetSets最终能够做到这一点，但现在不行。 最后，我们的批处理作业或者定时作业通常不会运行在Kubernetes上。 同样，这是Kubernetes正在发展的方向，但现在不能满足我们的需求。
从安全和访问的角度来看，Docker，AWS，Kubernetes和其他服务都需要监控，而且从应用程序性能角度来看也是如此。 是如何做到同时监控这一切呢？
我们先谈谈平台安全保护。 从一开始我们使用kubernetes TLS——这能控制对kube-ctl的访问。 从网络角度来看，Amazon ELB是安全的，并可以保护应用程序免于暴露于外。 这对集群免于外力攻击非常给力。 然而，这些工具无法保证集群内没有发生任何不利事件。接下来当我们深入讨论Sysdig Secure时会再谈这个问题。
从传统的监控角度来看，我们仅依靠AWS Cloudwatch提供的主机级监控。 这在使用Docker和Kubernetes，也就是更静态的体系架构之前是没有问题的。 而且，相对静态的体系架构下，可以从基础设施的监控信息中获得关于应用程序性能的更多信息。 迁移到Kubernetes后发生了改变， 我们需要在容器和服务级别进行监控。
Kubernetes默认提供Heapster和Grafana，这是我们的第一次尝试。 为了使用和管理这些组件，我们投入了大量的时间和努力。 鉴于我们是由两人组成的运维团队，这显然不是值得我们投入大量时间的方式。 我们需要一个功能全面，健壮监控功能，并且易于开展工作的监控工具。
所以对于我们来说，这排除了自己组合组件的方式。 我们最终选择了符合需求的商业产品。 实际上，我们仍然使用CloudWatch监控基本的AWS指标，同时使用Sysdig用于更高级别的内容。 尽管在监控底层基础设施方面存在一些重复，但没有任何影响。
Kubernetes是否会影响Docker的监控？ 并保护它？
是的，但Kubernetes影响很多方面，而不仅仅是监控。 如果我们回到为什么选Kubernetes这一问题上，一方面是它能精确地描述它在做什么，并且有它自己的语言来描述它：namespace，deployment等等。 这种“语言”统一了容器技术的使用方式。 这使得与工程师，运维人员或者任何参与到软件开发过程的人员的交流变得容易。
为了获取更加具体的监控信息，到目前为止，迁移到Kubernetes最重要，最明显的原因是对深入了解以Kubernetes为中心和以服务为中心的代码视图。实际上，很多软件可以通过与Docker API交互来监控基础设施级别的Docker容器，但他们不知道容器的具体信息。了解构成API服务的容器组，或者某个容器是某个Pod/ReplicaSet的一部分是非常有价值的，这使我们重新定义了对监控的需求。
对安全性有类似的思路：一个从以服务、Kubernetes为中心角度，且可以了解容器内部所发生事情的安全工具，比只通过镜像名区分容器或容器组的工具强大得多。
好吧，既然我们正在和你一起写这篇文章，我们都可以十分肯定地假设WayBlazer选择了Sysdig。 为什么？
是的。 我们现在使用了整个Sysdig容器智能平台——Sysdig Monitor，Sysdig Secure和开源故障排除工具。 Sysdig是一个优秀的集成基础设施监控、Kubernetes集群监控的工具。 基本上没有其他工具具有如此能力，通常我们都需要这两部分的监控才能在生产环境中运行容器。
Sysdig加强了Kubernetes的语言通用性。 它了解Kubernetes的基本结构。 不需要告诉Sysdig任何信息，也不必去适应它。 一旦部署了Sysdig，就可以获得想要的服务级别的指标信息，命令历史记录以及安全策略违规记录。
所有这些都来自一个统一的Agent。 在添加Sysdig Secure之前，Sysdig Monitor已经运行了大约18个月，我们只需添加一个额外的conf变量到Sysdig agent YAML文件中，Kubernetes Daemonset便会负责剩下的事情。
另外重要的一点是Sysdig可以获得容器内部更多的应用程序或以代码为中心的应用程序视图。 虽然我们十分关注基础架构指标，但同时也关注应用程序的监控信息。 Sysdig可以做到开箱即用，甚至当Kubernetes正在对Docker容器进行扩缩容。
所有这些方面都降低了成本，也提升了我们的效率。 这意味着我们不必为了将Kubernetes元数据转换成衡量指标而花费精力，也不必过多考虑如何使用我们的系统。
一旦应用程序部署在生产环境中，该如何保护呢？
上文已经提到了平台能提供安全性。 但是，我们仍然需要一些能够为运行时行为提供安全性的服务。 这些行为可能发生在主机级别，应用程序级别或系统中其他任何地方。 我欣赏Sysdig Secure，因为除了拥有以服务为中心的策略来提醒或阻止行为之外，还能让我们深入了解系统内发生的所有事情。 明确没有发生的事情的确能使人安心很多。
运行时安全最让人担心的问题是（1）谁在登录系统，他们在做什么；（2）是否有人正在修改系统内重要的文件？ Sysdig安全策略默认已经对登录，远程shell连接，未经授权的连接以及其他一些行为进行了防御和提醒，所以只需要为自定义应用程序创建一些特定的策略。 我们需要更高的优先级和更严格定义的安全策略。
就上文所描述的可见性，Secure提供历史命令查看就是一个很好的例子。 它提供查看系统中所执行的一切内容的能力，从微服务、到主机或容器等等，总之，一切我想看的内容。 另外，Sysdig Monitor的另一功能是可以及时查看指标信息，这也非常有用。 现在，如果将这两者结合在一起会非常有用。 如果在监控页面（显示内存，响应时间信息等）中看到不正常信息或事件，便可以回到命令历史记录获得更多信息，如是否有人在该服务或容器上运行了新的东西？
让我们更深入一点。 什么是最重要的监控指标？ 你一天到晚最想知道什么？
有趣的是，我们正在讨论Docker监控，但却没有真正地监控Docker。而是专注于监控应用程序，并在某种程度上监控Kubernetes以向我们提供有关应用程序运行的环境信息。 我们经常使用Docker相关信息进行故障排除，这是我们基础架构栈中的另一个层面，并且可能经常提供帮助我们解决棘手问题的信息。 以下是我们在应用程序级别监控的一些关键内容：
- 请求时间：我们密切关注前端和API的请求和响应时间。如果出现问题或变化，这些是需要首先关注的指标。 例如，一次新构建可能会导致应用程序执行失败，或者，一次网络配置错误可能会对用户产生负面影响。
- 后端查询响应时间：这些可能直接与数据库或Java后端相关。 当然，这是寻找潜在问题的好地方，也是改善系统的机会。 如果通常情况下，查询运行缓慢，便可以将其返回给团队进行研究和修复。
- 堆使用和垃圾回收：虽然不经常使用，但我们已经使用这些数据来调试基于JVM级数据的数据仓库。 从应用程序级别来看，我们确实需要关注这些资源指标。
接下来是Kubernetes。 以下是我们关注的内容：
- Pod重启和容器计数：告诉我们是否有变化发生。
- 启动失败：这些是可以用来关联其他指标的重要事件，无论是应用还是基础架构。
- 服务请求延迟：这一点极具挑战。 它涉及汇总来自特定服务的所有容器的延迟信息，并以一个统一的视图呈现。 这是在监控中使用“Kubernetes视点”的最佳例子。
- 容器平均资源利用率：我们最近在Kubernetes中添加了资源请求和限制机制，这意味着我们可以更有效地追踪资源利用率。 相比根据主机级别CPU和内存信息来监控资源利用率，我们选择根据分配给特定容器的资源来进行监控。 这能在资源分配问题上更早的提示警告，而不是仅仅在主机利用率级别进行监控。
关键节点上高CPU、内存和磁盘使用率，我们已经有了报警机制。 你也需要这些功能。
能谈谈你监控Kubernetes“多米诺骨牌效应”的故事吗？
这是我们在EC2中运行Kubernetes时早就经历的一件事。 我们的第一个警告指标是API高延迟的警报。 但此时延迟时间开始降低，虽然我们已准备好在必要时采取行动，但系统似乎稳定了。
但很快我们明白了问题的严重性。 我们看到了Kubernetes管理的节点缩容的警报。 我们立即查看了Sysdig，注意到蓝线在下降。 这不太好，但事情还没有结束。 Kubernetes正在干掉相关容器，并移到另一个节点。
然后同时看到磁盘和内存使用率都非常高。 这是最后的警告。 然后整个系统崩溃了。
基本上这就是多米诺骨牌效应——Kubernetes对第一个节点做了failvoer，它在内存耗尽时清除了所有容器。 此时，某些服务上并不存在对内存使用的请求和限制。
问题在于集群中的其他节点的磁盘使用已经比较高了，以至于无法为需要迁移的容器保留足够的空间。
我们很快就能够扩大自动伸缩组并修复一些节点，让系统恢复正常。 但这通常来说比较痛苦，而且很不理想。在之后对此的回顾汇总，我们很有趣的发现，能够通过Sysdig查看到整个事情。 然后在一天内与团队一起发布了一个可靠的关于系统行为的报告。 同时我们整理了一份完整的操作列表，其中有在系统达到特定阈值、限制条件、扩容策略等的具体操作。 这使我们的系统更加健壮。
你能总结一下在Docker监控方面的经验教训吗？
我们的经验表明，采用Kubernetes和Docker会对监控方法产生很大影响。 就像Kubernetes使我们可以从一个更加service-centric的视角来对待整个基础设置，监控策略也会以同样的方式发生变化。
你需要在监控系统中使用基于基础架构的视图（监控的标准方式）和以服务为中心的视图（监控的新方法），以在生产环境中运行容器。
确保你的监控系统能够强化Kubernetes的语言通用性。 它必须了解Kubernetes开箱即用的基本结构。 而且你不应该告诉他任何信息。 一旦部署，就可以获得服务级别的监控信息。
另外重要的一点你的工具应该在容器中看到更多的应用程序信息或以代码为中心的应用程序视图。 尽管我们密切关注基础架构指标，但我们仍然专注于监控应用程序，不管Kubernetes正在启动或停止Docker容器。
所有这些方面都降低了成本，也提升了我们的效率。 这意味着我们不必为了将Kubernetes元数据转换成衡量指标而花费精力，也不必过多考虑如何使用我们的系统。
希望你喜欢Kubernetes监控这一系列文章！ 如果你想了解更多，下面我们的首席执行官和创始人Loris Degioanni在CloudNativeCon / KubeCon “You’re Monitoring Kubernetes Wrong”的演讲。
视频： https://v.qq.com/x/page/c0603u1t44l.html
