This article is part of an Virtualization Technology tutorial series. Make sure to check out my other articles as well:
根据 Sysdig 发表的年度 [Docker]((https://riboseyim.github.io/2017/08/21/DevOps-Docker/) 用户报告,在容器市场 Docker 仍然是事实上的行业标准,但是其它品牌的容器运行环境正在发展;Kubernetes 仍然是容器编排领域的王者。报告的数据来源主要依据 Sysdig Monitor 和 Sysdig Secure cloud service 提供的容器使用状况的实时快照报告,它们从容器健康、性能和安全性等方面提供度量指标和可视化服务。样本集包括垂直行业和各类规模不等的大中型企业,地域覆盖北美洲、拉丁美洲、EMEA(欧洲、中东、非洲)和亚太地区。与去年一样,这份报告并不是用来代表整个容器市场。因为数据仅限于 Sysdig 客户,所以对于那些选择商业和开源解决方案的公司来说不具有代表性。但是来自 90000 个容器用户汇总数据,确实提供了了解真实生产环境容器使用状况的独特视角。
2018 Docker 用户报告 - Sysdig Edition
容器应用排行榜
容器部署应用榜首:Java Virtual Machines (JVM)。在容器时代之前,Java 就广泛应用于企业级服务,目前两者 —— Java 和容器更加紧密地融合到了一起。
我们还看到数据库解决方案的使用在增加, 例如在容器环境中运行 PostgreSQL 和 MongoDB 。这是一个信号, 表明在容器中部署有状态服务已经成为现实。容器的短暂性,让许多人对于在容器中运行高价值数据服务抱有怀疑态度, 但是市场回答了问题的解决方案--即为微服务设计的持久、便携和共享存储。数据显示, 客户开始转向完全由容器驱动的环境。
容器密度
在2017年每个主机的容器数的中位数是 10 。2018年,这个数字上升到 15,同比增长 50% 。另一方面,我们看到一个客户的单台主机上运行了 154 个容器,比我们去年观察到的最大 95 个增长了。
容器运行环境
Docker still reigns, but we’re seeing what might be the first signs of cracks in the dam.
事实上的容器运行环境依然是[Docker]((https://riboseyim.github.io/2017/08/21/DevOps-Docker/)。我们在 2017 年的报告中没有提及其他容器运行环境的详细信息, 因为在当时 Docker 的占有率接近 99% 。但是, 鉴于最近的一些变化: Red Hat 收购 CoreOS 的 (RKT 的制造商),以及 Open Container Initiative (OCI) 项目 — 旨在推进容器运行环境和镜像标准化。
事实上,在过去的一年里, 客户对其他平台的使用增加了。CoreOS RKT 显著增长到 12% , Mesos containerizer 占有 4% 。LXC 也在增长, 尽管从业人员规模比例还较低。数据显示, 客户在生产环境中使用 "non-Docker" 解决方案更加便利了。
容器存活周期
95% 的容器存活时间低于一周。
容器和服务的生存时间是多少? 我们观察了容器、容器镜像和服务的数量, 它们在短时间内开始并停止, 存活10秒或更短, 或者一周或更长。下图显示不同间隔内的容器百分比。 11% 的容器活了不到10秒。大部分容器(27%) 的生存期在五分钟之内。
为什么这么多的容器寿命如此之短呢?我们知道许多定制的系统都是按照需求来扩展的。容器被创建, 做他们的工作, 然后离开。例如, 一个客户为他们在 Jenkins 创建的每个作业配置一个容器,执行变更测试, 然后关闭容器。对他们来说, 类似活动每天会发生上千次。(Jenkins:一个用 Java 编写的开源持续集成工具,MIT许可证。它支持软件配置管理工具,如CVS、Subversion 和 Git 等,可以执行基于 Apache Ant 和 Apache Maven 的项目,以及任意的Shell 脚本/批处理命令。)
镜像存活周期
我们还观察了容器镜像的使用时间。通过查看这些数据, 我们了解到客户在 DevOps CI/CD 流程的一部分中是如何频繁地进行新的容器更新部署的。 一小部分 -- 一个百分点--在不到10秒内更新。69% 的容器镜像在一周的跨度内更新。
服务存活周期
"服务的寿命是多少?" 在 Kubernetes 中, 服务抽象定义了一组提供特定函数以及如何访问它们的 Pods 。服务允许 Pods 在不影响应用程序的情况下注销和复制。例如, 一个群集可以运行一个 Node.js JavaScript 运行时服务、MySQL 数据库服务和 NGINX 前端服务。
我们看到大多数服务(67%)生存期超过一周。少量的服务在更频繁的基础上被停止, 但是对于大多数客户来说, 目标是让应用程序 24 小时持续工作。容器和 Pods 可能会来了又走, 但是服务持续处于启动并且可用状态。
容器编排器
First place goes to Kubernetes, followed by Kubernetes and then Kubernetes.
例如, Mesosphere 能够在 DC/OS 环境中部署和管理 "Kubernetes-as-a-service"。可以将多个 Kubernetes 群集部署在一个 Mesosphere 群集上。
今年 Docker Swarm 的排名上升到第二位, 超过了基于 Mesos 的工具。根据 Sysdig ServiceVision 我们能自动标识出是否使用编排器, 并将逻辑基础结构对象与容器度量关联起来。在 2018 年, Kubernetes 可以确保领先地位。
-
Swarm 的进入门槛 例如, 微软使用 Kubernetes 为其 Azure Kubernetes 服务 (AKS), IBM 的云容器服务和私有云产品也是基于 Kubernetes 。即使是 Docker 和 Mesosphere 也增加支持了 Kubernetes 的功能。
-
Docker 企业版, 具有通用控制平面 (Universal Control Plane (UCP) ), 在许多操作层面上降低了启动 Swarm 的门槛。
容器集群大小
Mesos owns the big cluster game.
”集群大小对与组织选择编排器的影响是什么?“ 这项研究显示基于 Mesos 的编排器, 包括 Mesos Marathon 和 Mesosphere DC/OS 降至第三位。在使用 Mesos 的地方, 部署的容器数(中位数)比 Kubernetes 环境多 50% 。鉴于 Mesos 倾向于在大规模的容器和云部署, 所以这是有意义的。因此, 虽然 Mesos 集群的数量较少, 但是 Mesos 集群通常是意味着更大的企业规模。
我们的客户, 往往是更大的企业(在私有数据中心运行 Sysdig 解决方案)采用 OpenShift 的数量比我们的 SaaS 客户数量还要多。 Rancher Labs 于 2015 年出现, 为 Docker Swarm 和 Kubernetes 提供支持。直到 2017 年, Rancher (“大农场主”)才完全兼容 Kubernetes 作为其编排器。
Kubernetes 分发版
今年我们分析了使用 Kubernetes 的“品牌”分布, 看看在使用的 Kubernetes 是开源版本, 或由特定供应商提供的软件包。我们发现开源 Kubernetes 继续占有最大的份额, 但是 OpenShift 似乎正在取得突破进展, Rancher 也占有了一些份额。
OpenShift 获得接受不应该是一个惊喜。Kubernetes 于 2014 年诞生于 Google , Red Hat 也发布了该平台的 OpenShift 分发版, 并提出了针对企业客户实现 Kubernetes 的目标。
容器健康与应用性能监控
了解用户体验的四个“黄金信号” :延迟(latency),流量(traffic),错误(errors)和饱和度(saturation)。 响应时间(Response time)是配置最广泛的告警类型,紧随其后的是正常运行时间(uptime)和停机告警。基于主机的告警是最常用的,包括主要资源指标 - CPU ,内存和磁盘使用率等仍然被广泛使用。用户想知道托管 Docker 的服务器(物理机,虚拟机或云实例)是否处于资源紧张或达到容量上限的状态。这些告警的触发条件通常设置在利用率达到 80%-95% 之间。
同时,出现了越来越多的以容器为中心的资源告警。最主要有两种风格:
- 1)资源利用率
- 2)容器数量
默认情况下容器没有资源限制 。鉴于客户越来越注意容器限制方面的告警,这意味着他们正在使用 Docker运行时配置来控制容器使用内存,CPU或磁盘I / O 的上限,用户希望知道何时会超出阈值,应用程序的性能风险需要处于可控状态。
对于容器数量来说,这个问题通常与用户至少需要 X 个给定类型的容器并运行以提供所需的服务级别有关,特别是在微服务部署中。例如,“我知道如果需要确保应用程序运行良好,至少有三个 NGINX 容器可用。如果任何一个有问题,我都想知道。”
基于编排的告警(Orchestration-focused alerts) 也越来越受欢迎。与我们 2017 年的报告类似,“Pod Restart Count” 位列榜首。在一个 Pod 中,一个或多个容器是定位相同、共同调度(通常作为微服务的一部分)。如果某个容器重新启动太频繁,则表示存在可能影响应用程序性能的问题。
Kubernetes 管理员也经常使用 基于事件的告警( Event-based alerts ) 。与基于度量的告警相比,它的区别在于,监控程序需要查找环境中生成的事件消息,例如 Kurthnetes “CrashLoopBackoff” 条件 — 代表 Pod 反复失败或重启,或者“Liveness probe failed”,表示容器是否为活跃和运行。这些告警有助于 DevOps 工程师快速定位问题。
Http 错误可能表明软件或基础架构存在问题,最终会影响性能。
Alerts are not a one-size-fits-all approach.
告警不是一种万能的方法。有时需要设置基于指定范围的告警,无论是逻辑或物理实体,还是整个基础结构(注:Sysdig 通过标签实现)。
在 2018 年的研究中,用于确定告警范围的最常用标签与 Kubernetes 有关(Scoping by pods),命名空间(namespace)紧随其后。特定的容器范围(Container specific scoping)也很受欢迎,包括容器名称,容器镜像和容器 ID 。2018年再次名列榜首的是云服务提供商标签,通常针对“名称”,“环境”,“ID”和“区域”标签以区分开发、测试和生产资源,以及标记云数据中心的位置。
容器和基础设施自定义监控指标
There’s no one custom metrics format to rule them all.
"在环境中运行容器的客户,使用自定义指标的比例是多少,都是哪些?"
55% 的 Sysdig SaaS 用户使用与 Java 应用程序相关的 JMX 指标。这与我们看到的 Java 应用程序部署非常广泛的事实一致。 StatsD 占有 29% 的份额,Prometheus 占有 20% 的份额(预计这个数字会随着时间的推移而增长)。
容器注册
It’s a split decision - registries are critical but there’s no clear leader.
注册管理机构至关重要,但是目前没有明确的领导者。 容器注册表(container registry)是任何容器部署的基本组件。市场上有许多解决方案:一些是公共的,一些是私有的,一些是作为服务提供,一些是作为本地软件(private registry)部署。
2018 年前三名中,Google Container Registry(GCR)的比例最高,其次是 Quay ,之后是 Docker和 Amazon Elastic Container Registry(ECR)。 GCR 和 ACR 都是完全基于云托管的(private Docker container registries)。Quay 和 Docker 既可以用作本地解决方案也可以在云中运行(注:Sysdig 的用户群只有 50% 能够清楚地识别出容器注册方案)
New approaches are maturing and helping organizations develop applications more quickly to solve real business challenges and compete in the digital marketplace.
扩展阅读: 网络安全专题合辑《Cyber-Security Manual》
- Cyber-Security: Linux 容器安全的十重境界
- Cyber-Security: 警惕 Wi-Fi 漏洞,争取安全上网
- Cyber-Security: Web应用安全:攻击、防护和检测
- Cyber-Security: IPv6 & Security
- Cyber-Security: OpenSSH 并不安全
- Cyber-Security: Linux/XOR.DDoS 木马样本分析
- 浅谈基于数据分析的网络态势感知
- Packet Capturing:关于网络数据包的捕获、过滤和分析
- 新一代Ntopng网络流量监控—可视化和架构分析
- Cyber-Security: 事与愿违的后门程序 | Economist
- Cyber-Security: 美国网络安全立法策略
- Cyber-Security: 香港警务处拟增设网络安全与科技罪案总警司
扩展阅读:DevOps 漫谈系列
更多精彩内容扫码关注公众号:RiboseYim's Blog