由浅入深，带你进行容器错误隔离排查｜航海日志 Vol.19

汇总一周容器圈热点资讯，让开发者了解最 in 的容器技术，让企业熟知最实时的国内外容器行业动态。

容器错误隔离排查

拥抱容器的主要优点之一是“轻量级虚拟化”。 由于每个容器只是容器化过程的薄层，用户可以获得巨大的效率，例如通过增加每个主机的容器密度，或以非常快的速度将容器拓展。 然而，正如本文中的故障排除故事将显示的那样，这种轻量级虚拟化的代价是在所有容器之间共享底层内核，在某些情况下，这可能会导致容器用户通常考虑不到的不良影响。 这个故障排除故事涉及很多。 我将从基础开始，之后再处理了更复杂的情况，希望读者能从中获得更多价值。

1.隔离：优点

我们从容器化的基础开始，对于这些例子，我们将使用非常熟悉的 Docker 容器运行时。由于所有容器用户都非常了解，一旦创建了一个容器，默认情况下就会有非常大的隔离：容器化文件系统与外部隔离（通过安装命名空间），容器中的进程就像是主机上只有一个（通过 PID 命名空间）等等。

还有一些附加选项，也可以限制容器可以消耗的物理资源量。这通过cgroup实现，并且在每个主机部署多个容器时强加这些约束是至关重要的。例如，让我们运行两个容器，确保第一个容器可以只占用系统 CPU 的10％：

$ sudo docker run –cpu-quota = 80000 –name container1 stress $ sudo docker run –name container2 stress

我们使用 -cpu-quota 参数以绝对值（相对于我的 8 核心主机）来指定 CPU 限制，但是 cgroups 和 Docker 都支持其他方法来设置这样的限制，例如通过分配相对权重。然后，我们可以使用容器监控工具验证限制是否正确执行：

CPU占用百分比

事实上，第一个容器不能超过全部CPU消耗的 10 ％。监视容器的更多详细信息，请参阅本文关于 CPU 和内存限制执行。 我们也可以将 Docker 容器内存使用限制为 512 MB：

$ sudo docker run -m 512m – name container1 stress

运行一个可以在Docker容器内快速分配内存的程序，我们可以看到该容器很快被杀死，Docker 生成一个容器 OOM（Out Of Memory）事件。

容器内存不足

这些是限制资源的基本原语：内核为所有正在运行的容器执行它们，就像传统的虚拟机管理程序一样将它们应用于正在运行的虚拟机。然而，容器和内核之间的紧密耦合也带来了其他的挑战，在下一节将进行探讨。

2.隔离：缺点

前几天，我们的一位客户遇到了一个问题：容器化应用程序的性能在很大程度上取决于哪几个容器同时安排在同一主机上。 特别是当集群控制者（在这种情况下是 Kubernetes ）决定在主机上安排两种特定类型的容器映像（我们称之为“工作者”和“ trasher ”）时，容器化应用程序的性能将会缓慢而稳定地恶化。

首先，使用上面探讨的 cgroup 原语，确定容器在 CPU /内存/ IO 方面受到了适当的限制，这似乎是微不足道的。 经过深入检查，事实证明，集装箱已经受到 Kubernetes 限制，最重要的是，他们中没有一个初始化就使用许多系统资源。 两个集装箱之间的冲突变的更加微妙起来。

Bucketbench：比较容器运行时性能

2016年， IBM 团队创建了 OpenWhisk 无服务器平台（现在是一个 Apache 孵化项目），希望挖掘基于 Docker 引擎的功能执行程序的一些性能问题。

经过一番讨论，我们需要一种方式来对容器生命周期事件和运行时组件进行比较。 鉴于听说过 runC 和 containerd，于是决定创建一个基于 Golang 的框架，以便针对一组可配置的容器引擎运行一系列的容器生命周期命令，于是诞生了 bucketbench。

目前，bucketbench 具有 Docker，runC 和 containerd 的驱动程序实现，特别是对于 containerd，有两个驱动程序：一个使用 ctr 客户端操作的是 0.2.x 分支（由当前的 Docker 引擎版本使用），另一个驱动程序使用了目标 containerd 1.0 的 gRPC 客户端库，该库将尽快发布。每个驱动程序实现以下生命周期命令：创建，运行，停止，删除，暂停和恢复。 任何可以实现这些简单命令的容器引擎都可以作为驱动程序实现添加到 bucketbench 中。

班加罗尔聚会 – Docker 网络疑难解答演示

Docker 班加罗尔团队非常活跃，致力于 Docker 及其周边生态系统。 近日在 IBM 办公室举行了一次包括 Moby，Linuxkit，Windows Docker 和 Docker 多阶段构建在内的多主题聚会。会议进行了“ Docker 网络 – 常见问题和故障排除注意事项”的演示，重点思考了以下几点：

网络是一个复杂的主题，Docker 网络在每个版本中不断发展，这使得人们很难找出最佳实践。

当应用从开发到生产，网络需求发生变化，典型的方法并不总是有用。

企业客户有许多遗留应用程序，并且网络需要满足将旧的非容器应用与新的基于容器的微服务相连接。

相关链接：

幻灯片：

https://www.slideshare.net/SreenivasMakam/docker-networking-common-issues-and-troubleshooting-techniques

视频：

https://www.youtube.com/watch?v=ChGBJysUAo8&feature=youtu.be

Docker 监控：Docker 中监视 Java 应用程序的五大核心

在容器中运行应用程序是大型分布式系统部署越来越流行的方式。 Java VM的特点使其成为基于容器的基础架构的理想语言。 通过众多组件，在容器中监视 Java 应用程序需要规划和选择正确的工具来实现。

1. 使日志更易用

当然，Java 自己可以生成应用程序日志，但是通常需要额外的工具来使它们更易于阅读和使用。 有诸如 Splunk 和 Elastic stack 之类的成熟日志收集处理工具，或者相对较小（但不逊色的）工具，如Sumo Logic，Graylog，Loggly，PaperTrail，Logentries和Stackify。

2. 性能监控

应用程序性能监视（APM）工具有助于识别代码或基础架构中的性能瓶颈。 这是一个复杂的系统，拥有诸如 AppDynamics，Dynatrace 和 New Relic 等众所周知的工具，以及少量的开源选项。

3. 错误跟踪

应用程序会产生错误，但是由于今天复杂的交织和分布式代码库，通常很难直接找到错误的源头。 错误跟踪工具旨在通过监控生产中的应用程序来帮助您解决此问题。

4. 容器指标

容器本质上是小型，独立的机器，所以类似的指标（如 CPU 和内存使用量）对于跟踪高级应用程序问题仍然很重要。 我将主要在这里覆盖基于 Docker 的容器，但是会提到一个工具是否支持其他选项。

5. 编排

随着容器基础设施变得越来越复杂，您需要编排工具来构建应用程序并根据需求进行更改，并在容器和机器遇到问题时保持一致性。 这个领域有一小部分主要参与者，它们都是提供衡量指标监控的解决方案，因为它是必不可少的组成部分。（译者注：DCE 是您的好选择 ）

英国伯明翰 Serverless Fusion 会议

Alex Ellis 前往英国的西米德兰兹，首次访问了 Fusion 聚会组，探讨了如何开始使用功能即服务（FaaS）构建 Serverless 应用程序。

FaaS 是一个开源项目，欢迎贡献，了解有关使用 FaaS 的 Serverless，请查看文后链接。

这一期的『航海日志』就到这里，下期再浪～

参考链接

• https://sysdig.com/blog/container-isolation-gone-wrong
• https://integratedcode.us/2017/06/29/bucketbench-comparing-container-runtime-performance
• https://sreeninet.wordpress.com/2017/07/02/docker-networking-troubleshooting-presentation
• http://blog.takipi.com/docker-monitoring-5-methods-for-monitoring-java-applications-in-docker/
• https://www.slideshare.net/AlexEllis11/zero-to-serverless-in-60-seconds-anywhere?ref=https://blog.alexellis.io/faas-at-fusion

作者介绍

夏岩：DaoCloud 技术顾问，伪の全栈工程师 && 语言爱好者。

杨雪颖 Misha：DaoCloud 技术顾问，能文能撸码の通用型选手，兼 Labs 吉祥物。

未经允许不得转载：DaoCloud道客博客 » 由浅入深，带你进行容器错误隔离排查｜航海日志 Vol.19