赵昕演讲的题目为《微服务治理平台产品化与应用微服务化》。随着微服务被越来越多的企业所了解和认识，针对微服务治理平台的需求和应用微服务化的需求也变得越来越强烈。因此，目前各厂商面临的问题是如何提供符合客户需求的微服务治理平台产品，以及如何协助客户来进行应用微服务化的问题。

针对微服务治理平台产品，目前在市场上有三种主要的形态：

• 适合虚拟或物理主机搭建的微服务治理平台产品
• 容器化的微服务治理平台产品
• 与PaaS平台结合使用的微服务治理平台产品。

以上各形态的微服务治理平台，都有其优缺点。适合传统方式搭建的微服务治理平台，其组件都需要单独的虚拟机或物理机部署，部署过程相对复杂。此外，其组件若要实现高可用，要按照传统方式采用多机热备部署，占用大量的主机资源。而且在此种方式下，微服务治理平台组件与应用的部署环境分离，加大了运维的工作量与运维难度。

以容器化方式部署的微服务治理平台，其组件可以运行在具备 Docker 环境的虚拟机或物理机上。与容器 PaaS 平台解耦，可以在不同厂家的平台上部署。但是其问题是微服务治理平台作为一个应用，其访问入口与 PaaS 入口割裂，不方便使用。

时速云的微服务治理平台是与时速云的 PaaS 平台结合成为一个整体交付给用户。首先，微服务治理平台组件作为应用部署，能够接受 PaaS 平台统一调度管理。同时，用户的微服务应用代码能够与时速云 PaaS 平台的 Devops 功能结合起来，通过流水线，自动的将开发代码项目构建成容器镜像，并在 PaaS 平台上部署起来。同时 PaaS 平台可以管理多个集群，用以将测试环境与生产环境进行分离管理。

服务治理平台，不是单一技术路线的产品，目前支持 spring cloud、service mesh、dubbo，可以为用户提供丰富的选择。同时，针对分布式部署的微服务，时速云的微服务治理平台还提供分布式事务组件，来保证事务的一致性。此外，为了满足容器集群内的应用与外部应用能够进行互相调用，我们还专门定制了 CSB 云服务总线，通过服务订阅的形式，将集群内外的应用 API 开放打通。

我们不仅仅提供治理平台，还希望针对不同的用户能更好与微服务开发结合起来，因此，平台还提供了微服务开发的模板，用户可以自行选择java版本、依赖等来创建自己的代码模板，实现快速上手开发微服务。

当提供了相对完毕的微服务治理平台之后，用户所面临的问题是如何将应用进行微服务化。针对此问题，赵昕进行了六个方面的阐述：

• 应用微服务化的需求及现况
• 应用微服务化的优势
• 应用微服务化的主要步骤
• 应用微服务化的方法
• 应用微服务化过程中的问题
• 咨询服务

目前用户的主要需求在于构建全新的微服务应用及现有的应用改造。但现况是用户的技术程度参差不齐，比如相当一部分用户并没有Docker使用的经验，或者用户有Docker 的使用经验也有应用微服务化的需求，再有用户已有应用微服务化的经验，但形态比较简单。因此，时速云认为应用的微服务化应用需要一套循序渐进的流程来实现：熟悉Docker、Kubernetes->选取试点应用进行容器化->迁移应用至云平台->微服务改造

赵昕表示应用微服务化的价值在于，与传统应用相比，微服务化的应用有诸多优点。

传统单体应用主要缺点有：

• 复杂性逐渐变高
• 技术债务逐渐上升
• 部署速度逐渐变慢
• 阻碍技术创新
• 无法按需伸缩

相比直线，微服务应用的主要优点有：

• 模块独立开发
• 模块独立部署
• 独立的可伸缩性
• 可重用性

因此，应用的微服务化必定会作为应用所演进的方向，为更多的用户接受与使用。

当用户面临微服务改造的时候，必然会经历微服务的拆分，赵昕认为主要有四种拆分方法：

基于业务逻辑拆分

将系统中的业务模块按照职责范围识别出来，每个单独的业务模块拆分为一个独立的服务。

基于可扩展拆分

将系统中的业务模块按照稳定性排序，将已经成熟和改动不大的服务拆分为稳定服务，将经常变化和迭代的服务拆分为变动服务。

基于可靠性拆分

将系统中的业务模块按照优先级排序，将可靠性要求高的核心服务和可靠性要求低的非核心服务拆分开来，然后重点保证核心服务的高可用。

基于性能拆分

基于性能拆分和基于可靠性拆分类似，将性能要求高或者性能压力大的模块拆分出来，避免性能压力大的服务影响其他服务。

但单纯的提出拆分方法，并不能很好满足用户各类应用微服务拆分的需求，因此，赵昕指出，平台提供商在提供治理平台的同时，还需要提供相应的咨询服务，结合微服务产品的实现，以及在项目落地过程中所遇到的问题，有针对性的提出微服务化的解决方案，这样才能实现产品更好的落地，也能帮助客户快速的实现应用的微服务化，达到平台提供商与客户在技术、经济层面的双赢。

Kubernetes以运行可扩展工作负载而闻名。它根据资源使用情况调整工作负载。扩展工作负载时，会创建更多应用程序实例。当应用程序对你的产品至关重要时，你希望确保即使在你的群集受资源压力下也会安排这些新实例。解决此问题的一个显而易见的解决方案是过度配置群集资源，以便为扩展情况提供一些闲置资源。这种方法通常有效，但成本更高，因为你必须为大多数时间闲置的资源付费。

Pod优先级和抢占是Kubernetes 1.14里一般可用的调度程序功能，它允许你在不过度配置群集的情况下为关键工作负载实现高水平的调度可信度。它还提供了一种方法来提高群集中的资源利用率，而不会牺牲基本工作负载的可靠性。

保证调度，控制成本

Kubernetes Cluster Autoscaler是K8s生态系统中的一款出色工具，可在你的应用程序需要时为你的群集添加更多节点。但是，群集自动缩放器有一些限制，可能不适用于所有用户：

• 它在物理集群中不起作用。
• 向群集添加更多节点的成本更高。
• 添加节点不是即时的，可能需要几分钟才能使这些节点可用于调度。

另一种选择是Pod优先级（Priority）和抢占（Preemption）。在此方法中，你将多个工作负载组合在一个群集中。例如，你可以在同一群集中运行CI/CD管道，ML工作负载和关键服务。当多个工作负载在同一群集中运行时，群集的大小大于用于仅运行关键服务的群集。如果你为关键服务提供最高优先级，并且CI/CD和ML工作负载的优先级较低，则当你的服务需要更多计算资源时，调度程序会抢占（驱逐）较低优先级工作负载的足够容量，例如ML工作负载，以允许所有你要安排的优先级较高的pod。

使用pod优先级和抢占，你可以在Autoscaler配置中为群集设置最大大小，以确保在不牺牲服务可用性的情况下控制成本。此外，抢占比向群集添加新节点要快得多。在几秒钟内就可以安排高优先级的pod，这对延迟敏感的服务至关重要。

提高集群资源利用率

运行关键服务的集群运营商会随着时间，粗略估计他们在集群中需要的节点数量，以实现高服务可用性。估计通常是保守的。此类估计会考虑流量突发以查找所需节点的数量。可以配置群集自动缩放器永远不会将群集的大小减小到此级别以下。唯一的问题是这种估计通常是保守的，而且大多数时候集群资源可能仍未得到充分利用。Pod优先级和抢占允许你通过在群集中运行非关键工作负载来显着提高资源利用率。

非关键工作负载可能具有多于群集可以运行的pod数量。如果对非关键工作负载给予负数优先级，则当非关键容器挂起时，Cluster Autoscaler不会向群集添加更多节点。因此，你不会产生更高的费用。当你的关键工作负载需要更多计算资源时，调度程序会抢占非关键容器并安排关键容器。

非关键pod填充了群集资源中的“空隙”，可在不增加成本的情况下提高资源利用率。

参与其中

如果你对此功能有反馈意见或有兴趣参与设计和开发，请加入Scheduling特别兴趣小组。

https://github.com/kubernetes/community/tree/master/sig-scheduling

来源：CNCF官微

来源：K8sMeetup社区

作者：bot、小君君

技术校对：星空下的文仔

Kubernetes 在过去几年中一直是云计算领域最著名的开源项目之一。

2018 年，Kubernetes 度过了自己的 4 岁生日。从 2014 年开源，到如今成功从 CNCF 孵化，它已成为容器编排的事实标准。虽然 Kubernetes 还很年轻，但它正如初升的朝阳，在过去几年中一往直前，为组织设计和部署应用程序带来全新定义。本文将回顾 2018 年 Kubernetes 的发展情况，同时展望它在 2019 年的前行之路。

分布式计算的新时代

当容器于 2008 年首次推出时，虚拟机（VM）还是云提供商和内部数据中心寻求优化数据中心资产的最佳选择。

在那时，VM 确实提供了良好的灵活性，但它也存在一些缺陷，如每个 VM 都需要在整个层（管理程序）中模拟完全可操作的系统，并大幅占用物理 CPU 资源。即使采用 Intel VT-x 和 AMD-V 等技术，使用 VM 的性能也远不如裸机运行。

在这个背景下，容器技术通过在所有镜像中共享相同的内核来解决这些缺陷。换句话说，来自不同镜像的流程可以在同一空间中运行，而内核负责保证它们之间的正确隔离，我们也可以设置限制镜像资源利用，对计算资源进行合理调配。占用内存更少，又不存在硬件仿真层，因此容器一经提出就迅速走红。

但随着容器广泛进入生产领域，人们很快也意识到一个事实，就是尽管在同一台计算机上部署容器很容易，但它在高可用性管理、灾难恢复和可伸缩性方面仍存在不少问题，优秀的编排层才是在生产中大规模部署容器的必要前提。

这些问题催生了一种名为容器编排系统的新型软件，这种软件也在过去五年中得到了普及。它们负责进行集群操作，协调调度、内存分配、安全性和网络，目的是确保所有镜像按规定工作。

经过激烈竞争，最后，于 2014 年开源的 Kubernetes 力克 Docker Swarm 和 Apache Mesos，成了容器编排领域当之无愧的胜者。它背靠 Google 多年实践，实现了对即时部署、弹性伸缩、健康检查与高可用性（HA）系统的全部覆盖，能为生产完整生命周期保驾护航。

Kubernetes 的 2018

Kubernetes 尚有不足

然而，随着 Kubernetes 被更广泛采用，它也为容器带来了挑战，这涉及从安全性到复杂性再到可扩展性的各个方面。

可扩展性包括两部分：基础架构的可扩展性和 API 的可扩展性。

谈到它，首先我们要理解一个概念：微服务。微服务是一项在云中部署应用和服务的技术，它允许公司将其应用程序分解为更小的专用代码包，根据需要进行独立调整和更新。虽然可用性很强，但与之俱来的是网络复杂性，企业难以管理用于构建应用程序的微服务之间的流量，也难以提高这些应用程序执行方式的安全性和可视性。

为了解决这个问题，现在许多供应商开始纷纷采用谷歌、IBM 和 Lyft 开发的开源项目 Istio，以帮助改进云原生网络。

近日，Nirmata （一家增强企业 DevOps 能力的容器初创公司）的一项研究显示，虽然 Kubernetes 未来可期，但它的复杂性已经成为项目继续发展的一个不可忽视的障碍。根据他们的调查报告，有超过 50% 的开发人员表示曾因 Kubernetes 的复杂操作有过不同程度的困扰。

对简单小型业务来说，Kubernetes 的体量太大了，不如直接用 shell 脚本来得高效直接。因此如果 Kubernetes 想要取得真正的成功，它还要在轻量级和化繁为简上做出更多努力。

同样的，安全性问题也不容小觑。去年，Kubernetes 出现的严重安全漏洞，攻击者可以利用该漏洞通过 Kubernetes API 服务器连接到后端服务器，利用 API 服务器的 TLS 凭证进行身份验证并发送任意请求，从企业防火墙内破坏应用和服务。

而同样是 2018 年，包括特斯拉、Weight Watchers 在内的多家公司也曾遭受 Kubernetes 环境的攻击，原因是他们把 Kubernetes 仪表板打开并暴露在互联网上。这些事故无疑会打击企业对 Kubernetes 的信心。

Kubernetes 的安全性问题是多维度的。一方面，对于一个运行在 Kubernetes 上的普通应用，真正业务代码只占 0.1%，不同的组件都可能存在不同的安全隐患；另一方面，企业的广泛使用和网络安全意识缺失也加剧了问题的严重性。

可喜的是，随着问题的暴露，社区中围绕 Kubernetes 安全的技术项目（如 Notary、TUF 以及谷歌 gVisor）在日益增多，开发者们也正积极地针对漏洞进行补丁和建议。

2019 年预测

随着越来越多的公司将 Kubernetes 视为转向现代化 IT 企业的路标，再结合 2018 年的发展情况，新的一年，我们可以对 Kubernetes 有以下展望：

• 2019 年，Kubernetes 将完成其作为首选、协调的主导地位；
• Kubernetes 与大数据的结合将是一种趋势；
• Kubernetes 快速变化的脚步不会停滞；
• Kubernetes 安全性或将成为焦点；
• IT 领导者将对他们的 Kubernetes 平台更加挑剔。

至于屏幕前的你 —— Kubernetes 最亲密的开发者，2019 年，你希望它将在哪些方面实现巨大突破呢？Kubernetes 有你，社区有你，让我们一起期待 Kubernetes 的成长！

1、检查Docker是否正在运行

在进行具体问题定位和处理之前，最好和最简单直观的方式是先看看docker引擎是否能够正常运行。有以下几种方法可以确认docker是否处于正常运行状态：

1）通过执行docker info命令可以直接确认docker是否正常运行：

$ sudo docker info

2）也可以使用操作系统的命令来检查docker是否正常运行：

$ sudo systemctl is-active docker
# 或者
$ sudo service docker status

3）可以使用ps或top等命令检查进程的进程是否有正常运行的dockerd。

2、解决daemon.json与启动脚本之间的冲突

在Docker中，守护程序会将所有数据都保存在一个根目录中。通过此目录，将能够跟踪到与Docker相关的所有内容，包括容器(containers)，镜像(images)，存储卷(volumes)，服务定义(service definition)和机密(secrets)。默认情况下，此根目录为：

• Linux环境：/var/lib/docker
• Windows环境：C:\ProgramData\docker

可以使用data-root配置选项将Docker守护程序的配置为使用其他目录 。由于Docker守护程序的状态保留在此根目录中，因此需要确保每个守护程序使用专用的目录。如果两个守护程序共享同一根目录（例如，NFS共享），将可能会导致故障的无法处理的情况。

在docker引擎中，如果使用了daemon.json文件，同时通过手动或使用启动脚本将选项传递给dockerd命令，并且这些选项间存在冲突，则会导致Docker无法启动，例如：

unable to configure the Docker daemon with file /etc/docker/daemon.json:
the following directives are specified both as a flag and in the configuration
file: hosts: (from flag: [unix:///var/run/docker.sock], from file: [tcp://127.0.0.1:2376])

如果看到类似于上述内容的错误，并且使用此标志手动启动守护程序，则可能需要调整命令字段或daemon.json以解决冲突。如果使用操作系统的初始脚本启动Docker，则可能需要以特定于操作系统的方式覆盖这些脚本中的默认值。

2.1 在DAEMON.JSON中使用HOSTS密钥

默认情况下，Docker会监听套接字(socket)。在Debian和Ubuntu操作系统中使用启动docker时，-H字段会一直被使用。如果在daemon.json指定了一个 hosts条目，则会导致配置冲突，从而导致Docker无法启动。为了解决此问题，请/etc/systemd/system/docker.service.d/docker.conf使用以下内容创建一个新文件，以删除默认情况下启动守护程序时使用的-H参数。

[Service]
ExecStart=
ExecStart=/usr/bin/dockerd

3、查看日志

守护程序的日志可以帮助诊断问题，docker守护程序日志的具体存储位置取决于操作系统配置和使用的日志记录子系统：

4、启用调试

在daemon.json文件中将 debug键的值设置为true就可以启用docker的调试模式，此方法适用于每个Docker平台。

1. daemon.json文件通常位于/etc/docker/目录，如果该文件尚不存在，则需要手动创建此文件。
2. 如果文件为空，请添加以下内容：

   {
     "debug": true
   }
   

   如果文件中已经包含JSON，则只需添加键值对”debug”: true，如果它不是文件中的最后最后一行，请在行尾添加“；”。同时需要确认log-level是否已设置为info或debug。默认值为info，可能的值包括debug，info，warn，error，fatal。

3. 向守护程序发送hup信号以使其重新加载新的配置。在Linux主机上，使用以下命令。

   $ sudo kill -SIGHUP $(pidof dockerd)
   

也可以手动停止Docker守护程序，并使用debug的-D字段标志重新启动它。

5、强制记录堆栈跟踪

如果守护程序没有响应，则可以通过向SIGUSR1守护程序发送信号来强制记录完整堆栈跟踪。

$ sudo kill -SIGUSR1 $(pidof dockerd)

这会强制记录堆栈跟踪，但不会停止守护程序。守护程序日志显示堆栈跟踪或包含堆栈跟踪的文件的路径（如果已记录到文件）。处理完SIGUSR1信号并将堆栈跟踪转储到日志后，守护程序继续运行。堆栈跟踪可用于确定守护程序中所有goroutine和线程的状态。

5.1 查看堆栈跟踪

可以使用以下方法之一查看Docker守护程序日志：

• 在Linux系统上执行journalctl -u docker.service命令；
• 在较旧的Linux系统上，查看/var/log/messages，/var/log/daemon.log或/var/log/docker.log

在Docker日志中查找如下消息：

...goroutine stacks written to /var/run/docker/goroutine-stacks-2017-06-02T193336z.log
...daemon datastructure dump written to /var/run/docker/daemon-data-2017-06-02T193336z.log

Docker保存这些堆栈跟踪和转储的位置取决于操作系统和配置，有时可以直接从堆栈跟踪和转储中获取有用的诊断信息。

参考资料：

1.《Configure and troubleshoot the Docker daemon》地址：https://docs.docker.com/config/daemon/

作者简介：
季向远，本文版权归原作者所有。

一年两次的 CNCF 调查让社区紧跟时代脉搏，更好地了解云原生技术的采用情况。这是 CNCF 第二次用普通话进行云原生调查，以更好地衡量亚洲公司如何采用开源和云原生技术。之前的普通话调查已于 2018 年 3 月进行。本文还将与 2018 年 8 月以来北美/欧洲最新的同文调查版本进行比较。

重要结论

• 自 2018 年 3 月以来，亚洲公共云和私有云的使用量增长 135%，而本地使用量下降 48%。
• 亚洲几乎所有容器管理工具的使用率都有所增长，现成商业解决方案总体增长 58%，本土解决方案增长 690%。Kubernetes 增长 11%。
• Kubernetes 集群在生产中的数量正在增加。运行 1-5 个生产集群的亚洲组织减少 37%，而运行 11-50 个集群的受访者增加 154%。
• 在亚洲，无服务器技术的使用率激增了 100%，29% 的受访者使用可安装软件，21% 的受访者使用托管平台。

300 人回复了中文版调查，其中 83% 来自亚洲，相比之下，我们 2018 年 3 月的调查中有 187 人回复。

CNCF 在中国, 日本和韩国共有 42 位会员，其中包括 4 位白金会员：阿里云, 富士通, 华为和京东 (JD.com)。其中 某些成员也是终端用户，包括：

• 京东 (JD.com)，第一家跻身全球财富 500 强的中国互联网公司，从 OpenStack 迁移至 Kubernetes，资源利用率提高 30%。
• 华为，作为世界上最大的电信设备制造商，迁移至云原生环境后，运营成本削减 20-30%。
• 据《福布斯》报道，2018 年世界上最具创新性的公司之一，雅虎日本利用 Kubernetes 自动进行生产部署 。
• 中国移动是中国最大的运营商之一，其使用容器代替虚拟机在平台上运行各种应用程序，利用 Kubernetes 提高资源利用率。

容器的增长

在开发周期的所有阶段均使用容器已经成为常态利用容器进行测试的人数大幅增加，从 2018 年 3 月的 24% 增加到 42%，另外 27% 的受访者提到未来计划采用。用于概念验证的容器使用也有所增加（从 8% 上升到 14%）。

随着容器的使用在所有开发阶段日益普遍，容器管理工具的使用也越来越多。自 2018 年 3 月以来，几乎所有容器管理工具的使用都大幅增加。

自 2018 年 3 月以来， Kubernetes 的使用量增长 11%。其他工具的使用也有所增加：

• Amazon ECS：从 13% 上升至 22%
• CAPS：从 1% 上升至 13%
• Cloud Foundry：从 1% 上升至 20%
• Docker Swarm：从 16% 上升至 27%
• Shell Scripts：从 5% 上升至 14%

也有 2018 年 3 月的调查中没有提及的两个新工具。16% 的受访者使用 Mesos，另外 8% 使用 Noman 进行容器管理。

现成的商业解决方案（Kubernetes, Docker Swarm, Mesos 等）总体增长 58%，而本土管理（Shell Scripts 和 CAPS）增长 690%，这表明本土解决方案在亚洲仍然很受欢迎，而北美和欧洲市场则不再青睐 COTS 解决方案。

云与本地部署

虽然北美和欧洲市场广泛使用本地解决方案 (64%)，但在亚洲市场，这一数字似乎在下降。在本次调查中，只有 31% 的受访者报告了使用本地解决方案，相比之下，2018 年 3 月这一比例为 60%。云使用率正在增长，43% 的受访者使用私有云（从 24% 上升，51% 的受访者使用公共云（从 16% 上升。

Kubernetes

至于在何处运营  Kubernetes，阿里巴巴仍是第一，38% 的受访者报告正在使用，但低于 2018 年 3 月的 52%。紧随阿里巴巴之后的是亚马逊网络服务 (AWS)，24% 的受访者提到使用，略低于 26%。

以前未报告过，但正在占据额外市场份额的新环境是华为云 (13%), VMware (6%), 百度云 (21%), 腾讯云 (7%)，IBM 云 (8%) 和 Packet (5%)。

这些回应中也显示，本地使用量下降，24% 的受访者报告说，他们在本地运行 Kubernetes，而 2018 年 3 月这一比例为 38%。OpenStack 的使用率也大幅下降，从 2018 年 3 月的 26% 降至 9%。

对于运行 Kubernetes 的组织而言，生产集群的数量也在增加。运行 1-5 个生产集群的受访者减少 37%，而运行 11-50 个集群的受访者增加 154%。尽管如此，受访者大多运营 6-10 个生产容器，29% 的受访者报告这一数字。

我们还向受访者询问了他们用于管理应用程序各个方面的工具：

封装

封装 Kubernetes 应用程序最流行的方法是 Managed Kubernetes Offerings (37%)，其次是 Ksonnet (27%) 和 Helm (24%)。

自动扩展

受访者主要对任务和队列处理应用程序 (44%) 和 Java 应用程序 (44%) 使用自动扩展。其次是无状态应用程序 (33%) 和有状态数据库 (29%)。

受访者未使用 Kubernetes 自动扩展功能的最大原因是因为，其使用第三方自动扩展解决方案 (32%)，不知道这些功能存在 (30%)，或者已经构建了自己的自动扩展解决方案 (26%)。

入口提供商 (Ingress Providers)

据报告，Kubernetes 最大的入口提供商是 F5 (36%), nginx (34 %) 和 GCP (22%)。

公开集群外部服务 (Cluster External Services)

公开集群外部服务最流行的方式是负载平衡器服务 (43%), 与第三方负载平衡器的集成 (37%)和 L7 入口 (35%)。

在拥有多个团队的组织中分离 Kubernetes

受访者使用命名空间 (49%), 单独集群 (42%)和仅使用标签 (34 %)，将组织内的多个团队分开。

分离 Kubernetes 应用程序

受访者主要使用单独的集群 (45%), 命名空间 (46%) 和标签 (33%)，分离他们的 Kubenetes 应用程序。

云原生项目

云原生项目在生产中有什么优点？受访者列举了前四个原因：

• 提高可用性 (47%)
• 改进可扩展性 (46%)
• 云便携性 (45%)
• 提高开发人员的工作效率 (45%)

与北美和欧洲市场相比，提高可用性和开发人员工作效率在亚洲市场更为重要，而更快的部署时间则不那么重要（只有 38% 的受访者提到了这一点，而在本调查的英文版本中这一比例为 50%。

至于生产和评估中使用的云原生项目：

自 2018 年 3 月以来，许多云原生项目的生产使用率有所增长。生产使用率最高的项目是：gRPC（从 13% 上升至 22%, Fluentd（从 7% 上升至 11%, Linkerd（从 7% 上升至 11%，OpenTracing（从 20% 上升至 27%。

评估云原生项目的受访者数量也在增长：gRPC（从 11% 上升到 20%), OpenTracing（从 18% 上升到 27%）和 Zipkin（从 9% 上升到 12%。

未来的挑战

随着云原生技术不断被采用，尤其是在生产中，仍然有挑战需要解决。受访者面临的最大挑战是：

• 缺乏培训 (46%)
• 难以选择编排解决方案 (30%)
• 复杂性 (28%)
• 寻找供应商支持 (28 %)
• 监控 (25%)

我们注意到一个有趣的现象，自 2018 年 3 月的上一次调查以来，随着更多资源用于解决这些问题，许多挑战已经显著减少。出现的一个新挑战是缺乏培训。虽然 CNCF 在过去的一年中在Kubernetes 培训方面投入了大量资金，包括 Kubernetes 管理员和应用程序开发人员的课程和认证，但我们仍在积极努力使这些课程和认证的翻译版本在亚洲更容易访问。CNCF 还与 Kubernetes 培训合作伙伴的全球网络合作，以扩展这些资源，并与Kubernetes 认证服务提供商]合作，帮助支持复杂的组织踏上云原生之旅。

无服务

无服务器技术的使用在使用此技术的组织中激增 50%，而 2018 年 3 月这一比例为 25%。在这 50% 中，29% 使用可安装软件，21% 使用托管平台。另外 17% 的受访者计划在未来 12-18 个月内采用这项技术。

对于可安装的无服务器平台，Apache openshill 最受欢迎，有 11% 的受访者提到正在使用。其次是 Dispatch (6%), FN (5%) 和 OpenFaaS, Kubeless，和 Fission，并列 4%。

对于托管式无服务器平台，AWS Lambda 最受欢迎，有 11% 的受访者提到正在使用。其次是 Azure Functions (8%)，阿里云 Compute Functions, 谷歌云 Functions 和Cloudflare Functions 并列 7%。

亚洲的无服务器使用量高于北美和欧洲市场，其中，38% 的组织使用无服务器技术。与可安装软件 (6%) 相比，托管平台 (32%) 也更受欢迎，而在亚洲，这两种选择的使用更均匀。使用的解决方案也多种多样，而 AWS Lambda 和 kubeness 显然是北美和欧洲的领导者。

关于回到 CNCF 项目，一小部分受访者现在正在评估 (3%)或在生产中使用 CloudEvents(2%)。CloudEvents 是由 CNCF 无服务器工作组 组织的一项工作，旨在创建以一种通用方式描述事件数据的规范。

云原生在中国生根发芽

随着云原生在中国的持续增长，学习有关这些技术的方法变得越来越重要。以下是受访者了解云原生技术的主要方式：

文档

50% 的受访者通过文档学习。 每个 CNCF 项目在网站上都有大量文档，可以在此处找到。尤其是 Kubernetes，目前正致力于采用多种语言翻译其文档和网站，包括日语, 韩语, 挪威语和汉语。

技术播客

48% 的受访者通过技术播客学习。有各种各样的云原生播客可供学习，例如，谷歌的 Kubernetes 播课和 Red Hat 的PodCTL b。此外，可以查看 您应当留意的 10 个中国技术播客。

技术网络研讨会

29% 的受访者通过技术网络研讨会学习。CNCF 每周星期二上午 10 点到 11 点举办一次网络研讨会系列。您可以查看即将到来的时间表，或查看 之前网络研讨会的录音和幻灯片。

商业案例研究

27% 的受访者通过商业案例学习。CNCF 收集了终端用户案例研究 ，而 Kubernetes 也保留了大量的Kubernetes 特定用户案例研究列表。

中国的云原生社区

随着云原生技术在亚洲的持续增长，CNCF 很期待本周在上海举办首届 KubeCon + CloudNativeCon 年会。有 1,500 多名与会者参加开幕式，我们期待看到云原生技术在全球范围内的持续增长。

若要了解最新的新闻和项目，请参加我们在亚洲举办的 22 场云原生交流会。我们期待着在即将举行的会议上与您见面！

衷心感谢每一位调查参与人员！

您也可以在这里查看过去调查的结果：

• 2018 年 8 月：生产中使用云原生技术增长 200%
• 2018 年 3 月：云技术在中国遍地开花
• 2017 年 12 月：云原生技术正在扩展生产应用程序
• 2017 年 6 月：调查显示，Kubernetes 是领先的编排平台
• 2017 年 1 月：Kubernetes 从测试走向生产
• 2016 年 6 月：容器调查
• 2016 年 3 月：容器调查结果

关于调查方法和受访者

受访者代表各种公司规模，其中大多数在 50-499 名员工范围内 (48%)。至于工作职能，受访者大多数为开发人员 (22%), 开发经理 (15%) 和 IT 经理 (12%)。

受访者代表了 31 个不同的行业，主要为软件 (13%) 和金融服务 (11%) 行业。

此项调查采用普通话进行。下列为其他人口学统计数据：

来源：CNCF官微，https://mp.weixin.qq.com/s/GtGICwYzvCJEuMDv5YDKBQ

近日，阿里巴巴揭露了内部架构全面容器化的历程，目前阿里巴巴和蚂蚁金服集团多数事业部门，都已经采用了阿里巴巴去年11月开源的企业级容器平台PouchContainer，这套平台也遵循开源容器标准OCI，可与Docker兼容。阿里巴巴透露，去年双11购物节也是靠PouchContainer才撑过爆量交易的需求，高峰期启动了超过百万个容器来执行交易程序。PouchContainer也针对不同应用场景所需的容器配置进行优化，包括了电商平台、数据库、串流计算、大数据分析等。目前PouchContainer也刚于9月正式发布了1.0版。
阿里巴巴指出，PouchContainer和其他容器平台最大不同是，特别考虑了后续维运的需求，在隔离、镜像推送优化、丰富容器模式、扩充性和核心兼容性（兼容于Docker、Kubernetes等）都有强化。

Windows Server 2019正式版来了，支持Kubernetes和Linux容器

微软新版企业级操作系统Windows Server 2019正式版正式在10月出炉，主打四大特色，包括了混合云、安全、应用程序平台及超融合基础架构。还新增了以浏览器为基础的服务器管理套件Windows Admin Center（1809版），可支持私有云和Azure的混合云应用架构，更容易将既有的Windows Server部署，连结至云端的Azure服务。而System Center 2019则要等到明年上半年才问世。

另外，在应用平台功能上，Windows Server 2019也将Server Core的容器镜像大小，也从5GB缩减了三分之一，以加速镜像的下载，并改善程序的兼容性，也支持Service Fabric、Kubernetes与Linux容器。另外在超融合基础架构部署上，新版也从过去只支持2个节点，增加到可部署到100个服务器的规模。微软也同时宣布将在2020年终止支持旧版的Windows Server 2008和Windows Server 2008 R2。

参考：https://www.ithome.com.tw/news/126430

https://www.ithome.com.tw/news/126431

在容器商用化市场竞赛上，Docker以简单易用的封装设计，掀起了容器技术的浪潮，相继成为了容器技术的标准，也带动了IT架构下个十年的变革。

虽然早在2006年就开始发展容器技术的Google慢了一步，但每周至少启用20亿个容器的大规模部署经验，让Google走上了另一条容器发展之路，也就是以提供大规模容器调度和集群管理为主的Kubernetes计划。

4年过去了，Docker和Kubernetes的地位显然互换，过去Docker是最多人琅琅上口的容器技术名词，现在主角则变成了Kubernetes。云端教父AWS云端架构策略副总裁Adrian Cockcroft曾指出，两者虽然都是运用容器技术，但最大的差异是，Docker是要解决应用程序开发（Developing）问题，而Kubernetes是要解决更上层的应用程序运维问题（Operation）。开发问题是早期的痛点，但随着企业越来越依赖容器技术，内部应用越来越多是云原生应用时，运维会是企业IT的新痛点。

运维管理需求是Kubernetes后来居上的关键

因为云原生应用大多采用微服务架构设计，结合容器技术，一支应用程序往往需要数十，甚至复杂者要上百个容器化微服务程序组成，企业若有1百支应用，就得管上数千，甚至上万个容器化微服务，运维管理就成了最大的挑战。这正是后来主打大规模容器集群管理的Kubernetes后来胜出的关键。

企业商软大厂也纷纷加入Kubernetes平台战局，不论是在云端服务或是私有PaaS平台上，来发展自己的Kubernetes产品。像微软更直接找来Kubernetes共同创办人Brendan Burns，负责率领Azure容器服务团队，自己混合云产品Azure Stack也大力支持Kubernetes。IBM同样也靠以Kubernetes为核心的PaaS软件IBM Cloud Private，要来抢攻企业私有云容器平台市场，尤其是微服务管理需求。

很早就支持Kubernetes的红帽，在2015年推出的OpenShift 3.0版中，不惜放弃自己的容器调度工具，开始支持Kubernetes，现在更成为了要通吃跨多云、混合云架构，又能通吃裸机、容器和VM的企业级通用应用管理平台。而虚拟化龙头VMware也不落人后，近来也改力推主打通吃多家IaaS公云和Kubernetes集群管理的容器服务PKS软件。连甲骨文都在旗下云端服务支持Kubernetes。

而云端容器托管服务这两年更进入了新的竞争阶段，不少云端业者相继将自己容器托管服务中的Container，改由Kubernetes取代，例如Azure的ACS早在去年就换成了AKS， IBM则是今年5月将Cloud Container Service更名为Cloud Kubernetes Service，简称IKS。Kubernetes取代了Container，成了容器服务的新代名词。

Google计划先让Helm格式成为Kubernetes App封装格式

但是，Google的Kubernetes布局，迟迟没有跨出云端，除了积极参与Kubernetes开源项目之外，就是全力发展GKE，试图打造出云端容器代管服务领导者的地位。直到今年Next云端产品大会举办前一周，Google低调地发布了一个消息，将原本GCP的服务快速安装入口网站（Cloud Launcher）更名为Google Cloud应用市场，开始卖起来各种第三方软件厂商开发的商业软件。

其中最特别的是，这个App市场中设置了企业级Kubernetes App类型，也就是Kubernetes App市场。使用GCP的企业，可以直接在这个App市场，购买想要用的Kubernetes App。Nginx、Spark、Elasticsearch、WordPress、Cassandra等13家软件公司，开始透过Kubernetes App的形式销售企业级软件。

Google还预告要制订一个Kubernetes App的标准，就像OCI容器镜像那样的容器应用打包形式，Google试图要让通过Kubernetes封装管理套件Helm打包的Kubernetes App也能成为一种流通用的封装格式。

不同Docker容器化应用，得将所有程序封装到单一个镜像中，Helm可以将组合一支应用系统的多个微服务程序各自的镜像，打包到一套应用程序包中封装，更符合大型企业应用或复杂云端原生应用的需求。

和Helm封装形式的通用化和专用市场形式的出现，让Kubernetes App成了容器化应用的新格式，这是Google新一代AP层的成形，打下第一个基础。

GKE On-Prem主机首次公开

到了Next大会第一天开场演讲中，正当Google现场示范如何管理部署在两地的GKE容器集群时，突然秀出其中一套GKE的部署地点，竟然就在Next大会举办地点Moscone Center。随即，舞台上也出现了这台GKE主机，Google Cloud云端基础架构资深副总裁Urs Hölzle当场宣布，云端GKE服务将推出软件版本GKE On-Prem，可安装于企业内部机房服务器中。

Urs Hölzle宣布，Google将以GKE On-Prem软件，搭配开源微服务管理平台Istio，组成一套混合云软件称为Cloud Services Platform。GKE On-Prem的管理接口和云端GKE服务完全相同，企业可以将云端GKE上的服务，搬到自己机房，而不用改变管理运维方法。企业运维人员通过Google Cloud Console就可以同时管理云端的GKE服务和部署于自己机房的GKE On-Prem环境。

而Istio则是一套采取服务网格（Service Mesh）架构，来管理大量微服务的软件，可以将多个Kubernetes集群，集中到单一套服务网格中，来管理，并能支持跨Kubernetes集群联机，也能确保每个集群都套用一致的管理政策。不只Google，红帽同样也在自己的OpenShift上要支持Istio，同样都是看上企业未来大量微服务管理的需求。

不只如此，GKE On-Prem软件也强化了多项混合云整合机制，如企业可使用也可和云端GKE整合，不用建立复杂VPN。另外也可通用云端身份或自己的身份验证服务来登入GKE On-Prem。

运算工作可以跨不同GKE云端集群或自家的GKE集群间移动。企业可自建一个本地端Prometheus来监控GKE On-Prem，也可用云端的Stackdriver服务来监控本地端的GKE On-Prem集群。

不同于云端GKE，本地端GKE软件可存取持久性储存服务来部署大型应用，例如复杂的数据库。Google云端部署工具Cloud Build也可用来部署本地端GKE On-Prem上的容器应用。而Kubernetes应用市场上的Kubernetes应用，果不其然，也可部署到本地端的GKE On-Prem环境中。

Google的Cloud Services Platform战略布局，不只是涵盖了混合云、企业私有云、Kubernetes App市场，还要让自家无服务器服务，能部署到GKE On-Prem上，来进入企业内部。

Google企业混合云架构的最后一块拼图

Urs Hölzle表示，Kubernetes已经成为企业基础架构的部署标准之一，也因此，Google现在更进一步要用GKE On-Prem软件来补齐企业混合云架构的最后一块拼图。Google新策略是将云带到你身边。要让企业内部环境（on premise）到云端环境的管理工具能一致化，从网络到应用程序都能用同样的管理方式。

而他没说出口的是，如此一来，借助GKE On-Prem软件和Cloud Services Platform布局，Kubernetes已经成为了企业全新的应用层，甚至可以说是新一代的应用服务器层，未来的Kubernetes云原生应用，可以在这一层快速部署，任意调度扩充和迁移，就像是新一代的通用AP层基础架构。

原文：https://www.ithome.com.tw/news/125469

1、整体分析

对于Docker来说，存在镜像、容器、存储卷和网络这些对象。因此，也就会生产相对应的这些对象，这些对象会占据磁盘空间。当这些对象不在被使用时，为了不占据额外的磁盘空间，就需要对这些对象进行清理，即进行垃圾清理。在docker 1.13版本之后，提供了对各种对象的prune命令，也提供了清理所有对象类型的docker system prune命令。但在docker 1.13之前的版本，则需要提供其他方式进行垃圾清理。

2、垃圾清理

2.1 docker v1.13之后版本的垃圾清理

2.1.1 容器

在停止容器时，系统并不会知道删除这个容器，除非在运行此容器时设置了–rm字段。停止后的容器仍然会占据磁盘的存储空间，通过docker container prune能够删除这些被停止后的容器。

$ docker container prune
WARNING! This will remove all stopped containers.
Are you sure you want to continue? [y/N] y

执行此命令时，默认会提示是否继续。如果在执行命令是设置了-f或–force字段，则会直接删除已所有已停止的容器。默认情况下，此命令执行时会删除所有的已停止的容器，也可以通过设置–filter字段，来过滤所要删除的容器。例如，下面的命令仅仅删除停止超过24小时的容器。

$ docker container prune --filter "until=24h"

2.1.2 镜像

通过执行docker images prune命令可以清除所有不再使用的镜像，默认情况下此命令仅仅清除状态为dangling的镜像。状态为dangling的镜像为未被打标签和没有被任何容器引用的镜像。

$ docker image prune

WARNING! This will remove all dangling images.
Are you sure you want to continue? [y/N] y

如果要移除所有未被使用的镜像，则通过设置-a字段来实现：

$ docker image prune -a

WARNING! This will remove all images without at least one container associated to them.
Are you sure you want to continue? [y/N] y

执行此命令时，默认会提示是否继续。如果在执行命令是设置了-f或–force字段，则会直接进行删除操作。可以通过设置–filter字段，来过滤所要删除的镜像。例如，下面的命令仅仅删除停止创建超过24小时的镜像。

$ docker image prune -a --filter "until=24h"

2.1.3 存储卷

存储卷可以被一个或者多个容器使用，也会占据磁盘空间。为保持数据，存储卷永远都不会自动被删除。

$ docker volume prune

WARNING! This will remove all volumes not used by at least one container.
Are you sure you want to continue? [y/N] y

执行此命令时，默认会提示是否继续。如果在执行命令是设置了-f或–force字段，则会直接进行删除操作。默认情况下，此命令执行时会删除所有的未被使用的存储卷，也可以通过设置–filter字段，来过滤所要删除的存储卷。例如，下面的命令仅仅删除label值为keep的存储卷。

$ docker volume prune --filter "label!=keep"

2.1.4 网络

docker网络并不会占据磁盘空间，但是会创建iptables规则，桥网络设备和路由表。因此，但如何不再使用这些资源时，应该对其进行清理。

$ docker network prune

WARNING! This will remove all networks not used by at least one container.
Are you sure you want to continue? [y/N] y

执行此命令时，默认会提示是否继续。如果在执行命令是设置了-f或–force字段，则会直接进行删除操作。默认情况下，此命令执行时会删除所有的未被使用的网络，也可以通过设置–filter字段，来过滤所要删除的网络。例如，下面的命令仅仅为被使用超过24小时的网络。

$ docker network prune --filter "until=24h"

2.1.5 删除所有的对象

通过docker system prune命令能够快速的删除所有的未被使用的对象，包括镜像、容器、网络和存储卷。在docker 17.06.0之前，存储卷会同时被清理。在docker 17.06.1之后，需要通过设置–volumes字段，才会同时清理存储卷。

$ docker system prune

WARNING! This will remove:
        - all stopped containers
        - all networks not used by at least one container
        - all dangling images
        - all build cache
Are you sure you want to continue? [y/N] y

如果所使用的docker 17.06.1之后的版本，则需要在命令后添加–volumes字段来清理存储卷的内容。

$ docker system prune --volumes

WARNING! This will remove:
        - all stopped containers
        - all networks not used by at least one container
        - all volumes not used by at least one container
        - all dangling images
        - all build cache
Are you sure you want to continue? [y/N] y

2.2 docker v1.13之前版本的垃圾清理

2.2.1 容器

在停止容器时，系统并不会知道删除这个容器，除非在运行此容器时设置了–rm字段。停止后的容器仍然会占据磁盘的存储空间，通过docker rm能够删除这些被停止后的容器。通过下面的命令能够清除所有已停止的容器。

$ docker rm $(docker ps -a -q)

2.2.2 镜像

通过执行docker rmi命令可以清除所有不再使用的镜像，一般情况下仅仅清除状态为dangling的镜像。状态为dangling的镜像为未被打标签和没有被任何容器引用的镜像。

$ docker rmi $(docker images -q -f "dangling=true")

2.2.3 存储卷

存储卷可以被一个或者多个容器使用，也会占据磁盘空间。为了保持数据，存储卷永远都不会自动被删除。

$ docker volume rm $(docker volume ls -q -f dangling=true)

参考资料

1.《docker container prune》地址：https://docs.docker.com/engine/reference/commandline/container_prune/

2.《Prune unused Docker objects》地址：https://docs.docker.com/config/pruning/

3.《docker image prune》地址：https://docs.docker.com/engine/reference/commandline/image_prune/

4.《docker volume prune》地址：https://docs.docker.com/engine/reference/commandline/volume_prune/

5.《docker network prune》地址：https://docs.docker.com/engine/reference/commandline/network_prune/

作者简介：
季向远，北京神舟航天软件技术有限公司。本文版权归原作者所有。

京东首席架构师刘海锋与云原生计算基金会（CNCF）坐下来谈论云原生、京东的Kubernetes实施，以及对其它考虑开始采用开源的公司分享一些技巧和心得。以下是他们的采访。

CNCF：您如何看待您的CNCF成员资格和云原生技术，帮助京东实现“零售即服务”的愿景？

海锋：我们零售即服务（RaaS）战略的目标是开放我们的能力和资源，以增强我们的合作伙伴、供应商和其他行业的能力。这非常符合我们对开源技术的承诺。我们已经从参与的CNCF项目中获益匪浅，我们对CNCF的新承诺使我们能够与行业顶级开发商、最终用户和供应商建立更强大的合作关系，并最终使我们能够为开源社区贡献更多。我们正开发新的容器原生技术以实现我们的RaaS愿景，加入CNCF是我们迈出的重要一步。

CNCF：Kubernetes对您的公司和/或开发团队有何影响？

海锋：京东是Kubernetes最早期采用者之一。公司目前管理世界上最大的Kubernetes集群，多集群超过20,000多个裸机服务分布在多个地区的数据中心。

CNCF：Kubernetes如何帮助京东进行人工智能或大数据分析以彻底改变电子商务？

海锋：JDOS是我们定制和优化的Kubernetes版本，支持广泛的工作负载和应用程序，包括大数据和AI。JDOS提供了一个统一平台管理物理机和虚拟机，包括容器化GPU，并支持大数据和深度学习框架，如Flink、Spark、Storm和TensorFlow即服务。通过共同调度在线服务以及大数据和AI计算任务，我们显著地提高资源利用率并降低IT成本。

CNCF：京东运行的Kubernetes集群有多大？请描述一下您的团队使用Kubernetes。

海锋：JD目前管理世界上最大的Kubernetes集群，多集群超过20,000多个裸机服务分布在多个地区的数据中心

CNCF：Kubernetes和云原生如何赋能京东的开发者？哪些是他们现在能做而以前做不到的？

海锋：旧的部署工具对不同环境需要不同的流程，包括应用程序打包、容器应用程序、部署、配置和缩放。整个过程既复杂又耗时。Kubernetes的引入大大简化了流程。现在，应用程序自动打包成镜像并近乎实时地部署到容器中。缩放现在是一个简单的一键操作，可以在几秒内完成。

CNCF：京东运营世界上最大的Kubernetes集群之一，公司是如何克服障碍？

海锋：我们一直监控系统的性能。过去，为解决性能的问题，我们收集并分析了几个关键绩效指标，并生成了详细的瓶颈分析报告。然后，我们通过删除不必要的函数和优化默认的调度程序来定制Kubernetes。我们还增强了多个控制器以避免级联故障。此外，我们还开发了用于检查、监控、报警和故障处理的操作工具包，帮助操作员排除故障并快速解决可能出现的任何问题。

CNCF：京东刚刚庆祝大名鼎鼎的6月18日全民年中购物节（“618”），在18天期间交易量超过247亿美元。这是很大量的订单。您能谈谈您的系统如何处理这么多的订单吗？

海锋：JDOS使用基于预测的算法，主动分配资源以满足预测需求，提高资源利用率。它还提供毫秒级弹性扩展，处理极端工作负载。我们每年举办的618全民年中购物节，今年的交易量达到了247亿美元。我们的平台有超过3亿客户，在此期间我们看到显着的流量高峰。我们调度了大约460,000个容器（Pod）和3,000,000个CPU核心，以支持大量订单。

CNCF：告诉我们您的Vitess使用情况。有什么影响？

海锋：我们的弹性数据库是世界上规模最大、最复杂的Vitess部署之一。我们已经成功地扩展了Vitess，在JD的Kubernetes平台上管理大量复杂的交易数据。显著的功能包括支持RocksDB和TokuDB作为新的存储引擎、自动重新分片、自动负载平衡和迁移。我们的系统目前管理2,600个MySQL集群、9,000个MySQL实例、350,000个表、1,600亿条记录和65T数据，支持京东的各种业务应用程序和服务。Vitess的使用使我们能够更灵活、更有效地管理资源，从而显著降低运营和维护成本。我们正积极与CNCF社区合作，向Vitess添加子查询支持和全域交易等新功能。

CNCF：您公司对Kubernetes和其它云原生技术（GitLab、Jenkins、Logstash、HarbourElasticsearch和Prometheus）的下一步是什么？

海锋：我们的容器化平台通过在Kubernetes上部署DevOps堆栈来分离应用程序和基础架构层，包括Vitess、Prometheus、GitLab、Jenkins、Logstash、Harbour和Elasticsearch等。我们贡献了代码到其中一些项目。我们希望将来能够做出更多贡献。我们认为可以真正增加价值的一个例子是Vitess，CNCF的可扩展MySQL集群管理项目。我们不仅是Vitess的最大最终用户，也是一个非常活跃和重要的贡献者。我们期待与CNCF社区的其他人一起为Vitess添加新功能，包括子查询支持、全域交易等。另外，我们正在扩展Prometheus以创建实时和高性能的监控系统。我们希望改进Kubernetes以支持多种不同的工作负载，并希望为Kubernetes贡献代码。

我们也计划发布我们的内部自研项目。在github.com/tiglabs上能找到很多。我们还计划提出新的CNCF项目。其中一个项目是ContainerFS。它是一个与Kubernetes无缝集成的大规模容器原生集群文件系统。

CNCF：您目前也正在评估哪些技术或实践（DevOps，CI / CD）？

海锋：我们正在积极开发以云原生或容器原生软件和技术为中心的开源项目，从计算、存储和中间件到应用程序。其中一个重点是用于各种工作负载的容器平台，包括在线服务、数据分析、边缘计算和物联网。另一个重点是容器平台的可扩展和高性能数据存储。

CNCF：对于刚刚开始使用云原生的其他中国公司，最重要的事情是什么？

海锋：借助Docker、Kubernetes和微服务，您可以从云原生获得很多价值而无需承受高额成本。云原生解决方案不仅可以在云中运行。它非常灵活，可以部署在内部环境、私有云、公共云和混合环境中。重要的是要密切关注新技术和行业趋势，利用开源技术并积极参与开源社区。

CNCF：对于希望部署云原生基础架构的其他公司，您有什么建议？

海锋：从生态系统的角度考虑如何满足您的业务需求，包括容器化基础设施、数据存储、微服务平台、消息传递和监控系统等。在容器编排和管理方面，Kubernetes是事实上的标准，是肯定的能押注的。您还应该利用新兴的无服务器架构来简化应用程序开发、打包、部署和管理的过程。

CNCF：为什么云原生对京东的商业是如此势在必行？

海锋：除了我们的商家外，我们拥有超过3亿客户，我们的基础设施必须具有可扩展性和极高的效率。五年前，我们的产品图像系统中有大约20亿个图像。今天，有超过一万亿，这个数字每天增加1亿。此外，作为中国最大的在线或离线零售商，同时也是中国最大的电子商务物流基础设施的运营商，完全由内部自力开发，我们的业务复杂且日新月异。因此，我们的基础架构必须非常灵活，并支持广泛的工作负载和应用场景，如在线服务、数据分析、AI、供应链、财务、物联网或边缘计算等。云原生技术非常适合处理我们不断变化的需求。

CNCF：这是京东加入的第一个开源基金会吗？

海锋：对。我们坚定地相信开源，并且与我们自己的战略密切配合。通过CNCF，我们的目标是与开源社区建立更多更强大的交流互动，并充分发现为开源社区做出贡献的潜在互利。作为全球以收入计算第三大互联网公司，京东已经开发了许多领先的技术创新，我们认识到我们有责任在开源社区中发挥领导作用。

CNCF：您打算如何与CNCF携手合作？

海锋：我们可以合作的领域是无限的。当我们推进一些新项目，加入CNCF并与其他成员合作将非常有帮助。此外，CNCF为我们提供了平台，提高我们某些项目的推广认识，招募领先的开发者，进行协作并为我们的工作做出贡献。

CNCF：您对KubeCon + CloudNativeCon中国论坛的内容感到兴奋吗？

海锋：我们期待与行业顶级开发商、最终用户和供应商会面，并继续了解最新的技术发展。我们还计划展示自己的工作，并确定与公司、最终用户和独立开发者的潜在合作机会。

想更多地了解中国的技术领导者如何利用云原生技术？11月14日至15日，参与我们在上海举办的首届KubeCon + CloudNativeCon中国论坛。希望能在那里见到您！

从2017年9月开始，公有云服务商DigitalOcean开始每季发布开发者调查报告。每一季的报告，都会根据当时IT趋势而有所差异，像今年3月所发布的报告，就针对欧盟个资保护法GDPR，以及FCC决定废止网络中立性的政策，了解使用者的想法。这次该公司发布的使用者调查报告，访问了全球近5,000名开发者，了解各企业对容器、（无服务器）Serverless以及其他软件开发工具的使用趋势。

「容器技术的开发动能仍在增强」，DigitalOcean表示，随着容器技术、容器调度管理工具的快速进步，已经有49％的使用者开始利用容器技术，在软件开发上，容器技术已经可说是开发者必备的工具之一。相比之下，Serverless应用仍处于早期采用阶段，半数开发者对Serverless技术相当陌生。至于已经尝试使用该技术的开发者，「监控及除错是他们碰上最大的挑战。」

当Docker公司将容器技术热潮掀起时，Docker容器的快速开启、快速部署，以及高移植性等特性马上就受到开发者的热烈欢迎。调查报告显示，有39％的开发者认为，容器技术的高度扩充性是此技术带来最大的效益。而第二个受到使用者青睐的特质，就是让软件开发变得更简单（24％）。值得注意的是，容器技术的便捷性，能解决企业被特定厂商死锁的特质，也受到10％的开发者认同。

而利用容器技术镜像建立标准交付格式，也是开发圈加快应用交付的常见用法。在CI/CD流程与容器应用整合中，有42％的受访者表示，他们会结合持续整合、持续交付工具，加速容器应用生命周期的自动化。

在提到容器技术时，也一定会谈到容器调度工具的导入。当基础架构规格超过一定程度时，必须仰赖这些工具管理庞大的容器集群。果不其然，Kubernetes以42％的使用率拔得此份调查头筹。而Docker Swarm仍然有一定影响力，有35％的开发者仍继续使用该工具。而原本与Kubernetes、Docker Swarm三分天下的Mesos，仅剩3％的开发者使用。

不过，DigitalOcean表示，已经开始用容器的开发者，仍有52％还未导入容器调度平台。在调查容器调度工具议题中，DigitalOcean也发现几个有趣的结论。在1至5人的微型企业，Docker Swarm的使用率（41％）比Kubernetes（31％）还更高。而使用容器调度工具的开发者，超过半数（51％）每周都因此省下至少5小时的维运时间。

除了容器技术，Serverless应用也是这次DigitalOcean的调查重点。除云端容器服务，当今公有云厂商也开始建立Serverless应用平台，插入这块新市场。调查开始使用Serverless应用的用户群体中，结果显示，58％的用户导入了AWS Lambda作为Serverless应用执行平台，殿后的是Google Cloud Functions（23％），而微软Azure Functions则以10％拿下第三名。

比照容器技术调查，DigitalOcean也访问使用者，了解Serverless技术带来的优点。而该技术最受青睐的特色，就是省去使用者自行建立服务器的成本（33％），其次则是让开发者能花更多时间改善应用（28％）。再者是让应用能更快速部署（23％）。

而历经三五年酝酿的容器技术，在厂商、社群积极推广下已逐渐成熟。相比之下，Serverless应用还属于早期采用阶段。尚未熟悉该技术的开发者，有81％受访者表示，会在今年起深入了解研究。而已经导入Serverless应用的开发者，最多人碰上的挑战是该应用不易监控、除错（27％）。而当今Serverless应用也相当依赖公有云厂商服务，因此，其中有25％开发者担心被厂商绑定，20％更表示导入Serverless应用，得依赖第三方厂商提供的解决方案。

图片来源：DigitalOcean

有39％的开发者认为，容器技术的高度扩充性是此技术带来最大的效益。而第二个受到使用者青睐的特质，就是让软件开发变得更简单（24％）。

图片来源：DigitalOcean

Kubernetes以42％的使用率拔得此份调查头筹。而Docker Swarm仍然有一定影响力，有35％的开发者仍继续使用该工具。而原本与Kubernetes、Docker Swarm三分天下的Mesos，仅剩3％的开发者使用。

图片来源：DigitalOcean

开始应用Serverless技术的企业，58％的使用者导入了AWS Lambda作为Serverless应用执行平台，殿后的是Google Cloud Functions（23％），而微软Azure Functions则以10％拿下第三名。

图片来源：DigitalOcean

开发者使用容器搭配的程序语言，按照使用排名依序是JavaScript（57％）、Python（46％）、PHP（36％）、Go（28％）、Java（27％）等。

原文：https://www.ithome.com.tw/news/124290

今天，我们兴奋地公布Kubernetes 1.11版本——亦是2018年这一项目的第二个发布版本！

今天发布的版本旨在不断推进Kubernetes的成熟度、可扩展性与灵活性，同时亦标志着其研发团队在过去一年中的努力工作取得了重大进展。这一最新版本的主要亮点集中在网络层面，以beta测试形式开放来自SIG-API Machinery与SIG-Node的两项主要功能，同时进一步增强在此前两个版本中已经得到高度重视的存储功能。在这一最新版本中，用户将能够更轻松地将任意基础设施——无论云平台还是内部环境——接入Kubernetes当中。

本版本当中最值得关注的，是增加了两项备受期待的功能，分别为：基于IPVS的集群内负载均衡，以及将CoreDNS作为集群DNS的附加选项——这意味着生产应用的可扩展性与灵活性都将得到提升。

下面，我们将就最新版本的核心特性展开讨论：

基于IPVS的集群内服务负载均衡正式上线

在本次版本中，基于IPVS的集群内服务负载均衡功能已经趋于稳定。IPVS（即IP虚拟服务器）能够提供高性能内核负载均衡功能，且其编程接口较iptables更为简单。这一变化使得网络吞吐量更上一层楼、提供更低的编程延迟，同时亦使由Kubernetes Service模式组成的集群范围内分布式负载均衡器获得更高的可扩展性水平。目前IPVS仍不属于默认设置，但大家已经可以利用其处理生产流量。

CoreDNS正式上线

CoreDNS现在被正式作为集群DNS附加选项，且在用户使用kubeadm时默认生效。CoreDNS是一套灵活且可扩展的权威DNS服务器，可直接与Kubernetes API相集成。相较于原有DNS服务器，CoreDNS的移动部件更少——仅包含单一可执行文件与单一进程，且允许用户通过创建自定义DNS条目以支持更为灵活的用例。其同样使用Go语言编写而成，因此天然具备更理想的安全性水平。感兴趣的朋友可以点击此处参阅关于CoreDNS的更多细节信息。

动态Kubelet配置步入Beta测试阶段

通过这项改进，用户可以将新的Kubelet配置部署在运行中的集群之内。在此之前，Kubelet需要通过命令行标记进行配置，这导致我们很难对运行中的集群进行Kubelet配置更新。在此次beta功能的帮助下，用户将能够通过API服务器随时配置运行中集群内的Kubelet。

定制化资源定义现在可定义多个版本

定制化资源定义不再局限于对单一版本的定制化资源作出定义。如今，利用此项beta测试功能，用户可以为资源定义多个版本。未来，其还将进一步扩展以支持版本间自动转换功能。目前，该功能允许定制化资源作者“以安全变更的方式实现版本升级，例如由v1beta1切换至v1”，并为发生变化的资源创建迁移路径。

定制化资源定义如今还能够支持“状态”与“规模”两类子资源，这些子资源可与各类监控与高可用性框架相集成。这两项变化显著提升了在生产环境中利用定制化资源定义运行云原生应用程序的能力。

CSI增强

容器存储接口（简称CSI）在之前的几个版本当中一直得到高度关注。在1.10版本以beta形式发布之后，1.11版本进一步增强了CSI功能。1.11版本为CSI带来了对原始数据块分卷的alph支持能力，将CSI与新的kubelet插件注册机制相集成，同时降低了向CSI插件传递秘密凭证的难度。

新的存储功能

对持久分卷进行在线大小调整已经以alpha测试功能的形式引入新版本。这意味着用户能够增加持久分卷的大小，而完全无需终止pod并卸载对应分卷。用户可以更新VPC以提交新的分卷大小请求，kubelet则负责完成文件系统的大小调整。

动态最大分卷数量以alpha测试版的形式加入新版本。这项新功能使得入树分卷插件能够指定可接入节点的最大分卷数量，且允许根据节点类型的区别设定不同最大分卷量。在此之前，这些限制需要通过硬编码形式或配置环境变量来实现。

StorageObjectInUseProtection功能目前已经迎来稳定版本，并可防止绑定至持久分卷声明的持久分卷以及由pod使用的持久分卷声明遭到删除。此项安全措施将有助于防止用户不小心删除绑定至运行中pod的PV或PVC。

社区中的各个特别兴趣小组（简称SIG）都将继续立足各自专业领域实现呼声最高的增强、修复与功能。关于SIG的完整内容列表，请点击此处参阅发行版说明。

正式上线

Kubernetes 1.11目前已经可通过GitHub进行下载。要开始使用Kubernetes，请点击此处参阅相关交互式教程。

您也可以利用Kubeadm安装1.11版本。1.11.0版本将以Deb与RPM软件包的形式提供，并于6月28日通过Kubeadm集群安装器进行安装。

原文链接：Kubernetes 1.11: In-Cluster Load Balancing and CoreDNS Plugin Graduate to General Availability

来源：http://www.dockone.io/article/6050

1、Prometheus介绍和架构

1.1 Prometheus介绍

Prometheus是一个开源的系统监视和警报工具包，自2012成立以来，许多公司和组织采用了Prometheus。它现在是一个独立的开源项目，并独立于任何公司维护。在2016年，Prometheus加入云计算基金会作为Kubernetes之后的第二托管项目。
Prometheus的关键特性如下：

• 由度量名和键值对标识的时间序列数据的多维数据模型
• 灵活的查询语言
• 不依赖于分布式存储；单服务器节点是自治的
• 通过HTTP上的拉模型实现时间序列收集
• 通过中间网关支持推送时间序列
• 通过服务发现或静态配置发现目标
• 图形和仪表板支持的多种模式

Prometheus的组件：

Prometheus生态由多个组件组成，并且这些组件大部分是可选的：

• Prometheus服务器，用于获取和存储时间序列数据；
• 仪表应用数据的客户端类库(Client Library)
• 支持临时性工作的推网关(Push Gateway)
• 特殊目的的输出者(Exporter)，提供被监控组件信息的 HTTP 接口，例如HAProxy、StatsD、MySQL、Nginx和Graphite等服务都有现成的输出者接口
• 处理告警的告警管理器（Alert Manager）
• 其它支持工具

Prometheus的整体架构

Prometheus从jobs获取度量数据，也直接或通过推送网关获取临时jobs的度量数据。它在本地存储所有被获取的样本，并在这些数据运行规则，对现有数据进行聚合和记录新的时间序列，或生成警报。通过Grafana或其他API消费者，可以可视化的查看收集到的数据。下图显示了Pometheus的整体架构和生态组件：

Prometheus的整体工作流程：

1）Prometheus 服务器定期从配置好的 jobs 或者 exporters 中获取度量数据；或者接收来自推送网关发送过来的 度量数据。

2）Prometheus 服务器在本地存储收集到的度量数据，并对这些数据进行聚合；

3）运行已定义好的 alert.rules，记录新的时间序列或者向告警管理器推送警报。

4）告警管理器根据配置文件，对接收到的警报进行处理，并通过email等途径发出告警。

5）Grafana等图形工具获取到监控数据，并以图形化的方式进行展示。

1.2 Prometheus关键概念

1.2.1 数据模型

Prometheus从根本上将所有数据存储为时间序列：属于相同度量标准和同一组标注尺寸的时间戳值流。除了存储的时间序列之外，普罗米修斯可能会生成临时派生时间序列作为查询的结果。

• 度量名称和标签：每个时间序列都是由度量标准名称和一组键值对（也称为标签）组成唯一标识。度量名称指定被测量的系统的特征（例如：http_requests_total-接收到的HTTP请求的总数）。它可以包含ASCII字母和数字，以及下划线和冒号。它必须匹配正则表达式[a-zA-Z_:][a-zA-Z0-9_:]*。标签启用Prometheus的维度数据模型：对于相同度量标准名称，任何给定的标签组合都标识该度量标准的特定维度实例。查询语言允许基于这些维度进行筛选和聚合。更改任何标签值（包括添加或删除标签）都会创建新的时间序列。标签名称可能包含ASCII字母，数字以及下划线。他们必须匹配正则表达式[a-zA-Z_][a-zA-Z0-9_]*。以__开始的标签名称保留给供内部使用。

• 样本：实际的时间序列，每个序列包括：一个 float64 的值和一个毫秒级的时间戳。

• 格式：给定度量标准名称和一组标签，时间序列通常使用以下格式来标识：

  <metric name>{<label name>=<label value>, ...}
  

  例如，时间序列的度量名称为api_http_requests_total，标签method=”POST”和handler=”/messages”，则标记为：

  api_http_requests_total{method="POST", handler="/messages"}

1.2.2 度量类型

Prometheus 客户端库主要提供Counter、Gauge、Histogram和Summery四种主要的 metric 类型：

• Counter(计算器)：Counter是一种累加的度量，它的值只能增加或在重新启动时重置为零。例如，您可以使用计数器来表示提供的请求数，已完成的任务或错误的数量。不要使用计数器来表达可减少的值。例如，不要使用Counter来计算当前正在运行的进程的数量，而是使用Gauge。
• Gauge(测量)：Gauge表示单个数值，表达可以任意地上升和下降的度量。Gauge通常用于测量值，例如温度或当前的内存使用情况，但也可以表达上升和下降的“计数”，如正在运行的goroutines的数量。

• Histogram(直方图)：Histogram样本观测（例如：请求持续时间或响应大小），并将它们计入配置的桶中。它也提供所有观测值的总和。具有<basename>基本度量标准名称的histogram的在获取数据期间会显示多个时间序列：
  • 观察桶的累计计数器，暴露为 <basename>_bucket{le=”<upper inclusive bound>”}
  • 所有观察值的总和，暴露为<basename>_sum
  • 已观察到的事件的计数，暴露为<basename>_count（等同于<basename>_bucket{le=”+Inf”}）

  Summery：类似于Histogram，Summery样本观察（通常是请求持续时间和响应大小）。虽然它也提供观测总数和所有观测值的总和，但它计算滑动时间窗内的可配置分位数。在获取数据期间，具有<basename>基本度量标准名称的Summery会显示多个时间序列：

  • 流动φ分位数（0≤φ≤1）的观察事件，暴露为<basename>{quantile=”<φ>”}
  • 所有观察值的总和，暴露为<basename>_sum
  • 已经观察到的事件的计数，暴露为<basename>_count

1.2.3 工作和实例

按照Prometheus的说法，可以获取数据的端点被称为实例（instance），通常对应于一个单一的进程。具有相同目的的实例集合（例如为了可伸缩性或可靠性而复制的进程）称为作业（job）。

例如，具有四个复制实例的API服务器作业：

• 工作： api-server
  • 实例1： 1.2.3.4:5670
  • 实例2： 1.2.3.4:5671
  • 实例3： 5.6.7.8:5670
  • 实例4： 5.6.7.8:5671

自动生成标签和时间序列

当Prometheus获取目标时，它会自动附加一些标签到所获取的时间序列中，以识别获取目标：

• job：目标所属的配置作业名称。
• instance：<host>:<port>被抓取的目标网址部分。

如果这些标签中的任何一个已经存在于抓取的数据中，则行为取决于honor_labels配置选项。

对于每个实例抓取，Prometheus会在以下时间序列中存储一个样本：

• up{job=”<job-name>”, instance=”<instance-id>”}：1 如果实例健康，即可达；或者0抓取失败。
• scrape_duration_seconds{job=”<job-name>”, instance=”<instance-id>”}：抓取的持续时间。
• scrape_samples_post_metric_relabeling{job=”<job-name>”, instance=”<instance-id>”}：应用度量标准重新标记后剩余的样本数。
• scrape_samples_scraped{job=”<job-name>”, instance=”<instance-id>”}：目标暴露的样本数量。

up时间序列是实例可用性的监控。

1.3 使用Helm在Kubernetes中部署Prometheus

1.3.1 环境要求

• 已有Kubernetes 1.6+环境；
• 已部署helm客户端和tiller服务端（请参考：https://docs.helm.sh/using_helm/#installing-helm）：
  • 在Kubernetes中创建了具备足够权限访问权限的service account；
  • 并通过此service account在Kubernetes部署了tiller服务端（请参考：https://docs.helm.sh/using_helm/#role-based-access-control）。
• 在Kubernetes中提供2个容量大于10g的持久化存储卷。

1.3.2 Helm chart配置

下表列示了Prometheus chart的配置参数和默认值：