来自 SDXCentral 的调查：一年以内部署容器的人数增加了562%｜航海日志 Vol.26

时间 2019-11-30

标签来自 sdxcentral 调查一年 1年以内部署容器人数增加 562% 航海日志 vol.26 vol 繁體版

原文原文链接

➤ 来自 SDXCentral 的调查，一年以内部署容器的量级增加了562%

来自 SDXCentral 的2017年集装箱和云计算报告的重要发现之一是，对于容器技术的部署在过去两年中稳步增加，而且将在应用平台领域超越虚拟机（VM）。在 2016 年，只有 8％的受访者部署容器，而今年有 45 ％已经在使用。html

该报告着重于云计算和自动化领域，关注了企业和其余受访者面临的挑战。其中，有 62% 的受访者采用容器技术的主要缘由是由于其使用的效率；有 58%的受访者是由于其比虚拟机的开销更低；同时有 47%的受访者是由于其更易于管理。经过将应用程序从底层基础结构中分离出来, 以及标准化的升级机制, 这些特性让应用程序的测试和部署速度更快, 同时具有更高的应用程序可移植性和更好的安全性。node

同时，最受欢迎的编排平台是 Kubernetes 占比为 64％，Docker Swarm 占比为36％，Apache Mesos / Mesosphere 占比为18％。最初在 Google 开发的 Kubernetes 具备良好的行业支持，而且是 CNCF 项目的一部分。Docker 公司开发的 Docker Swarm 针对Docker Engine 进行了优化，并在 Docker Swarm 之上创建了一个管理堆栈。Docker 还与微软合做，支持内置于 Windows Server 2016 和 Microsoft Azure 。docker

➤ Kubernetes 1.8.0 alpha.3 测试版本发布bootstrap

Kubernetes 距离 alpha2 发布过去1个多月后，Kubernetes 1.8 第 3 个测试版 alpha.3 已经发布了，这次相比 alpha2 更新的内容较多主要一些变化有：api

删除无用的 kubectl 命令 apiversions, clusterinfo, resize, rollingupdate, run-container, update安全
从 kube – controller – manager 中删除无用的 flags : replication-controller-lookup-cache-size, replicaset-lookup-cache-size, and daemonset-lookup-cache-size
bash
Beta 版的 Annotations service.beta.kubernetes.io/external-traffic 和service.beta.kubernetes.io/healthcheck-nodeport 已删除。（请使用 service.spec.externalTrafficPolicy 和 service.spec.healthCheckNodePort 代替）app
使用AWS提供的群集须要使用 ClusterID 标记 nodes 和 resources 。编辑器
RBAC：该 system:node Role 再也不自动授予新集群的 system:nodes Group。建议使用 Node 受权模式受权节点。ide
StatefulSet：删除 pod.alpha.kubernetes.io/initialized Annotation 。
从 kube-apiserver 中删除 –insecure-allow-any-token 。
将默认的 kubeadm bootstrap token TTL 从无限时长更改成 24 小时。若是依旧但愿使用以前的 TTL，请使用 kubeadm init –token-ttl 0/ kubeadm token create –ttl 0。

➤ Docker 小贴士：拆分 Dockerfile 中的长指令行

拆分 Dockerfile 中的长指令行可以使 Dockerfile 更容易阅读。让咱们来看看这是如何作的。

就我来讲，在编码或处理配置文件时，我尽可能限制每行79个字符。它不只仅是一个标准，并且也刚好是我在2560x1440显示器上的Sublime中温馨地打开3个窗口的完美宽度。

在编写Dockefile的时候，你可能会将命令高效的链接在一块儿。可是，这样作会致使指令行变的至关长。

举例来讲，看看这个122字符的命令：

RUN wget -O myfile.tar.gz http://example.com/myfile.tar.gz && tar -xvf myfile.tar.gz -C /usr/src/myapp && rm myfile.tar.gz复制代码

在代码编辑器中，这将所有在1行中显示。水平浏览这一整行命令是至关费力的。

然而，咱们能够把它拆分开来

RUN wget -O myfile.tar.gz http://example.com/myfile.tar.gz \
    && tar -xvf myfile.tar.gz -C /usr/src/myapp \
    && rm myfile.tar.gz复制代码

这样看起来是否是清楚多了？

反斜杠是在类Unix操做系统上将长行分解成多行的标准方法。因为大多数Docker镜像是使用某种形式的Linux基本镜像构建的，因此反斜杠在这里也适用。赶忙在你的Dockerfile中尝试一下吧！

➤ 容器监控简介

容器让咱们的工做变的更加轻松容易，不管是对于开发或者生产。然而，与以前的开发模式相比，容器化也带来了新的问题。容器监控是一个彻底不一样的“猛兽”，让咱们来看看缘由所在。

容器监控的不一样之处

您如今已经建立并部署了两个容器。如今须要作什么呢？我须要在个人容器中安装一个监视代理来监控容器内部的状况？

不！容器的优势之一是部署的容器的大小。咱们只安装保证容器正常运行的那些必须的东西。很少很多。

容器的寿命比虚拟机要短得多。根据最新的DataDog Container调查，容器的平均寿命为2.5天。如此高的变化率，咱们的监控软件彻底不能跟上咱们修改应用的速度。

此外，容器使应用的横向扩展和恢复变的很是容易。咱们须要了解容器状态的更改和全部应用运行实例的位置。咱们监控系统必须可以应对这些变化，而且在应用扩展和恢复时进行快速跟踪。

监控容器

容器的监控是无代理的。也就是说，咱们不会在监视器中安装监控代理。一般，咱们在每一个主机上的容器的workload旁边的附加容器中运行监视软件来监视容器。这些监视容器用于监视主机和容器。

在这一点上，许多人混淆头脑，问“另外一个容器是如何监视主机和主机上运行的容器的？” 大多数监视容器将根目录从主机挂载到容器。经过挂载根目录，监视应用将在进程状态发生改变时更新，反之亦然。咱们为何要关注进程而不是容器？容器就是进程，这是监控应用程序经过了解进程什么时候转换为统计信息以及进程与应用程序之间的关联的神奇之处。

哪一个是最好的监控解决方案？

选择正确的监控解决方案不只仅是开源 vs. 商业产品。选择解决方案时要谨慎考虑的问题--解决方案是否与容器协调器集成在一块儿，是否基于云，是否运行内部部署，是否应用集成，以及社区是否支持。这些主题中的每个自己均可以成为选择解决方案的决定性因素。若是您想进一步探索这些主题，请了解 Docker 容器的监控和管理。

为了更好地协助您的决策过程，我建立了一个监控解决方案 Spider Graph Google 电子表格，以帮助您将目标与不一样的产品进行可视化。

监控解决方案图说明：

值范围从 1(最不重要)到 5(最重要)。

“监控目标”行是每一个类别的基准
填写 Coloumn A 中的名称，并与监控解决方案进行比较
使用 Spider Graph 来肯定不一样解决方案的功能
将目标基准值与不一样的解决方案进行比较

您能够将监视解决方案 Spider 图进行比较。

总结

通过比较，您应该更加了解哪一个监控解决方案最适合您的项目了。

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

参考连接

https://www.infoq.com/news/2017/08/containers-sdxcentral-survey
https://www.kubernetes.org.cn/2581.html
https://nickjanetakis.com/blog/docker-tip-17-breaking-up-long-lines-in-your-dockerfile
https://www.brianchristner.io/introduction-to-container-monitoring/

做者介绍

莫非 Beck：DaoCloud 微服务攻城狮，吃饱了就困的一流段子手。

刘玺元 Boring：DaoCloud 市场部门（伪）萌新程序猿。

▼ 点这儿，查阅上一期的航海日志