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

➤ 容器错误隔离排查

拥抱容器的主要优势之一是“轻量级虚拟化”。 因为每一个容器只是容器化过程的薄层，用户能够得到巨大的效率，例如经过增长每一个主机的容器密度，或以很是快的速度将容器拓展。 然而，正如本文中的故障排除故事将显示的那样，这种轻量级虚拟化的代价是在全部容器之间共享底层内核，在某些状况下，这可能会致使容器用户一般考虑不到的不良影响。 这个故障排除故事涉及不少。 我将从基础开始，以后再处理了更复杂的状况，但愿读者能从中得到更多价值。

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 限制，最重要的是，他们中没有一个初始化就使用许多系统资源。 两个集装箱之间的冲突变的更加微妙起来。

//*想看完整内容请持续关注 DaoCloud ，咱们将后期在文章中发布。*//

➤ 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 吉祥物。