来源：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的配置参数和默认值：

1、持久化存储卷和声明介绍

PersistentVolume（PV）用于为用户和管理员提供如何提供和消费存储的API，PV由管理员在集群中提供的存储。它就像Node一样是集群中的一种资源。PersistentVolume 也是和存储卷一样的一种插件，但其有着自己独立的生命周期。PersistentVolumeClaim (PVC)是用户对存储的请求，类似于Pod消费Node资源，PVC消费PV资源。Pod能够请求特定的资源(CPU和内存)，声明请求特定的存储大小和访问模式。PV是一个系统的资源，因此没有所属的命名空间。

2、持久化存储卷和声明的生命周期

在Kubernetes集群中，PV 作为存储资源存在。PVC 是对PV资源的请求和使用，也是对PV存储资源的”提取证”，而Pod通过PVC来使用PV。PV 和 PVC 之间的交互过程有着自己的生命周期，这个生命周期分为5个阶段：

• 供应(Provisioning)：即PV的创建，可以直接创建PV（静态方式），也可以使用StorageClass动态创建
• 绑定（Binding）：将PV分配给PVC
• 使用（Using）：Pod通过PVC使用该Volume
• 释放（Releasing）：Pod释放Volume并删除PVC
• 回收（Reclaiming）：回收PV，可以保留PV以便下次使用，也可以直接从云存储中删除

根据上述的5个阶段，存储卷的存在下面的4种状态：

• Available：可用状态，处于此状态表明PV以及准备就绪了，可以被PVC使用了。
• Bound：绑定状态，表明PV已被分配给了PVC。
• Released：释放状态，表明PVC解绑PV，但还未执行回收策略。
• Failed：错误状态，表明PV发生错误。

2.1 供应（Provisioning）

供应是为集群提供可用的存储卷，在Kubernetes中有两种持久化存储卷的提供方式：静态或者动态。

2.1.1 静态(Static)

PV是由Kubernetes的集群管理员创建的，PV代表真实的存储，PV提供的这些存储对于集群中所有的用户都是可用的。它们存在于Kubernetes API中，并可被Pod作为真实存储使用。在静态供应的情况下，由集群管理员预先创建PV，开发者创建PVC和Pod，Pod通过PVC使用PV提供的存储。静态供应方式的过程如下图所示：

2.1.2 动态（Dynamic）

对于动态的提供方式，当管理员创建的静态PV都不能够匹配用户的PVC时，集群会尝试自动为PVC提供一个存储卷，这种提供方式基于StorageClass。在动态提供方向，PVC需要请求一个存储类，但此存储类必须有管理员预先创建和配置。集群管理员需要在API Server中启用DefaultStorageClass的接入控制器。动态供应过程如下图所示：

2.2 绑定

在Kubernetes中，会动态的将PVC与可用的PV的进行绑定。在kubernetes的Master中有一个控制回路，它将监控新的PVC，并为其查找匹配的PV（如果有），并把PVC和PV绑定在一起。如果一个PV曾经动态供给到了一个新的PVC，那么这个回路会一直绑定这个PV和PVC。另外，用户总是能得到它们所要求的存储，但是volume可能超过它们的请求。一旦绑定了，PVC绑定就是专属的，无论它们的绑定模式是什么。

如果没有匹配的PV，那么PVC会无限期的处于未绑定状态，一旦存在匹配的PV，PVC绑定此PV。比如，就算集群中存在很多的50G的PV，需要100G容量的PVC也不会匹配满足需求的PV。直到集群中有100G的PV时，PVC才会被绑定。PVC基于下面的条件绑定PV，如果下面的条件同时存在，则选择符合所有要求的PV进行绑定:

1）如果PVC指定了存储类，则只会绑定指定了同样存储类的PV；

2）如果PVC设置了选择器，则选择器去匹配符合的PV;

3）如果没有指定存储类和设置选取器，PVC会根据存储空间容量大小和访问模式匹配符合的PV。

2.3 使用

Pod把PVC作为卷来使用，Kubernetes集群会通过PVC查找绑定的PV，并将其挂接至Pod。对于支持多种访问方式的卷，用户在使用 PVC 作为卷时，可以指定需要的访问方式。一旦用户拥有了一个已经绑定的PVC，被绑定的PV就归该用户所有。用户能够通过在Pod的存储卷中包含的PVC，从而访问所占有的PV。

2.４释放

当用户完成对卷的使用时，就可以利用API删除PVC对象了，而且还可以重新申请。删除PVC后，对应的持久化存储卷被视为“被释放”，但这时还不能给其他的PVC使用。之前的PVC数据还保存在卷中，要根据策略来进行后续处理。

2.5 回收

PV的回收策略向集群阐述了在PVC释放卷时，应如何进行后续工作。目前可以采用三种策略：保留，回收或者删除。保留策略允许重新申请这一资源。在PVC能够支持的情况下，删除策略会同时删除卷以及AWS EBS/GCE PD或者Cinder卷中的存储内容。如果插件能够支持，回收策略会执行基础的擦除操作（rm -rf /thevolume/*），这一卷就能被重新申请了。

2.5.1 保留

保留回收策略允许手工回收资源。当PVC被删除，PV将仍然存储，存储卷被认为处于已释放的状态。但是，它对于其他的PVC是不可用的，因为以前的数据仍然保留在数据中。管理员能够通过下面的步骤手工回收存储卷：

1）删除PV：在PV被删除后，在外部设施中相关的存储资产仍然还在；

2）手工删除遗留在外部存储中的数据；

3）手工删除存储资产，如果需要重用这些存储资产，则需要创建新的PV。

2.5.2 循环

警告：此策略将会被遗弃。建议后续使用动态供应的模式。

循环回收会在存储卷上执行基本擦除命令：rm -rf /thevolume/*，使数据对于新的ＰＶＣ可用。

2.5.3 删除

对于支持删除回收策略的存储卷插件，删除即会从Kubernetes中移除PV，也会从相关的外部设施中删除存储资产，例如AWS EBS, GCE PD, Azure Disk或者Cinder存储卷。

3、持久化存储卷

在Kubernetes中，PV通过各种插件进行实现，当前支持下面这些类型的插件：

• GCEPersistentDisk
• AWSElasticBlockStore
• AzureFile
• AzureDisk
• FC (Fibre Channel)
• FlexVolume
• Flocker
• NFS
• iSCSI
• RBD (Ceph Block Device)
• CephFS
• Cinder (OpenStack block storage)
• Glusterfs
• VsphereVolume
• Quobyte Volumes
• HostPath (Single node testing only – local storage is not supported in any way and WILL NOT WORK in a multi-node cluster)
• VMware Photon
• Portworx Volumes
• ScaleIO Volumes
• StorageOS

持久化存储卷的可以通过YAML配置文件进行，并指定使用哪个插件类型，下面是一个持久化存储卷的YAML配置文件。在此配置文件中要求提供5Gi的存储空间，存储模式为Filesystem ，访问模式是ReadWriteOnce，通过Recycle回收策略进行持久化存储卷的回收，指定存储类为slow，使用nfs的插件类型。需要注意的是，nfs服务需要提供存在。

apiVersion:v1
kind:PersistentVolume
metadata:
  name:pv0003
spec:
  capacity: #容量
     storage:5Gi
  volumeMode:Filesystem #存储卷模式
  accessModes: #访问模式
  - ReadWriteOnce
  persistentVolumeReclaimPolicy:Recycle #持久化卷回收策略
  storageClassName:slow #存储类
  mountOptions: #挂接选项
   - hard
   - nfsvers=4.1
  nfs:
     path:/tmp
     server:172.17.0.2 

3.1 容量（Capacity）

一般来说，PV会指定存储容量。这里通过使用PV的capcity属性进行设置。目前，capcity属性仅有storage（存储大小）这唯一一个资源需要被设置。

3.2 存储卷模式（Volume Mode）

在kubernetes v1.9之前的版本，存储卷模式的默认值为filesystem，不需要指定。在v1.9版本，用户可以指定volumeMode的值，除了支持文件系统外（file system）也支持块设备（raw block devices）。volumeMode是一个可选的参数，如果不进行设定，则默认为Filesystem。

3.3 访问模式（Access Modes）

只要资源提供者支持，持久卷能够通过任何方式加载到主机上。每种存储都会有不同的能力，每个PV的访问模式也会被设置成为该卷所支持的特定模式。例如NFS能够支持多个读写客户端，但某个NFS PV可能会在服务器上以只读方式使用。每个PV都有自己的一系列的访问模式，这些访问模式取决于PV的能力。

访问模式的可选范围如下：

•   ReadWriteOnce：该卷能够以读写模式被加载到一个节点上。
•   ReadOnlyMany：该卷能够以只读模式加载到多个节点上。
•   ReadWriteMany：该卷能够以读写模式被多个节点同时加载。

在 CLI 下，访问模式缩写为：

•   RWO：ReadWriteOnce
•   ROX：ReadOnlyMany
•   RWX：ReadWriteMany

一个卷不论支持多少种访问模式，同时只能以一种访问模式加载。例如一个 GCEPersistentDisk既能支持ReadWriteOnce，也能支持ReadOnlyMany。

3.4 类（Class）

在PV中可以指定存储类，通过设置storageClassName字段进行设置。如果设置了存储类，则此PV只能被绑定到也指定了此存储类的PVC。在以前的版本中，使用注释volume.beta.kubernetes.io/storage-class字段来指定存储类，而不是storageClassName字段来指定存储类。 此注释仍然可用，但是，在将来的版本中将会被废弃。

3.5 回收策略

当前的回收策略可选值包括：

• Retain-持久化卷被释放后，需要手工进行回收操作。
• Recycle-基础擦除（“rm-rf /thevolume/*”）
• Delete-相关的存储资产，例如AWSEBS或GCE PD卷一并删除。

目前，只有NFS和HostPath支持Recycle策略，AWSEBS、GCE PD支持Delete策略。

3.6 挂接选项（Mount Options）

当持久化卷被挂接至Pod上时，管理员能够指定额外的挂接选项。但不是所有的持久化卷类型都支持挂接选项，下面的存储卷类型支持挂接选项：

• GCEPersistentDisk
• AWSElasticBlockStore
• AzureFile
• AzureDisk
• NFS
• iSCSI
• RBD (Ceph Block Device)
• CephFS
• Cinder (OpenStack block storage)
• Glusterfs
• VsphereVolume
• Quobyte Volumes
• VMware Photon

挂接选项不会进行验证，因此如果如果设置不正确，则会失败。在以前的版本中，使用volume.beta.kubernetes.io/mount-options注释指定挂接选项，而不是使用mountOptions字段。此注释仍然可用，但是在将来的版本中将会被废弃。

4、持久化卷声明

下面是一个名称为myclaim的PVC YAML配置文件，它的访问模式为ReadWriteOnce，存储卷模式是Filesystem，需要的存储空间大小为8Gi，指定的存储类为slow，并设置了标签选择器和匹配表达式。

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: myclaim
spec:
  accessModes: #访问模式
    - ReadWriteOnce
  volumeMode: Filesystem #存储卷模式
  resources: #资源
    requests:
      storage: 8Gi
  storageClassName: slow #存储类
  selector: #选择器
    matchLabels:
      release: "stable"
    matchExpressions: #匹配表达式
      - {key: environment, operator: In, values: [dev]}

4.1 选择器

在PVC中，可以通过标签选择器来进一步的过滤PV。仅仅与选择器匹配的PV才会被绑定到PVC中。选择器的组成如下：

• matchLabels： 只有存在与此处的标签一样的PV才会被PVC选中；
• matchExpressions ：匹配表达式由键、值和操作符组成，操作符包括In, NotIn, Exists和DoesNotExist，只有符合表达式的PV才能被选择。

如果同时设置了matchLabels和matchExpressions，则会进行求与，即只有同时满足上述匹配要求的PV才会被选择。

4.2 存储类

如果PVC使用storageClassName字段指定一个存储类，那么只有指定了同样的存储类的PV才能被绑定到PVC上。对于PVC来说，存储类并不是必须的。依赖于安装方法，可以在安装过程中使用add-on管理器将默认的StorageClass部署至Kubernetes集群中。当PVC指定了选择器，并且指定了StorageClass，则在匹配PV时，取两者之间的与：即仅仅同时满足存储类和带有要求标签值的PV才能被匹配上。

4.3 PVC作为存储卷

Pod通过使用PVC来访问存储，而PVC必须和使用它的Pod在同一个命名空间中。Pod会同一个命名空间中选择一个合适的PVC，并使用PVC为其获取存储卷，并将PV挂接到主机和Pod上。

kind:Pod
apiVersion:v1
metadata:
  name:mypod
spec:
  containers:
  - name:myfrontend
    image:dockerfile/nginx
     volumeMounts: #挂接存储卷
     - mountPath:"/var/www/html" #挂接的路径
       name:mypd #所要挂接的存储卷的名称
 volumes: #定义存储卷
 - name:mypd
   persistentVolumeClaim: #所使用的持久化存储卷声明
     claimName:myclaim

参考资料

1.《Configure a Pod to Use a PersistentVolume for Storage》地址：https://kubernetes.io/docs/tasks/configure-pod-container/configure-persistent-volume-storage/

2.《Persistent Volumes》地址：https://kubernetes.io/docs/concepts/storage/persistent-volumes/

3.《Persistent Storage》地址：https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/persistent-storage.md

4.《PersistentVolume v1 core》地址：https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.10/#persistentvolume-v1-core

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

1、基于kubernetes devops的整体方案

本文以Kubernetes为基础，为基于java语言研发团队提供一套完整的devops解决方案。在此方案中，开发人员基于eclipse集成开发环境进行代码；开发人员所开发的代码交由由gitlab进行托管、版本管理和分支管理；代码的依赖更新和构建工作由Maven进行处理；为了提升工作效率和代码质量，在devops中引入SonarQube进行代码检查；对于打包构建后代码，交由docker进行镜像构建，并在私有镜像仓库中对镜像进行管理；最后，devops会将自动从私有镜像仓库从拉取镜像，并在Rancher中进行部署。

基于此devops解决方案的整体工作过程如下所示：

1）开发人员基于eclipse集成开发环境镜像代码开发的，将代码到gitlab中进行托管；

2）jenkins从gitlab拉取代码；

3）jenkins调用Maven对代码进行打包构建；

4）jenkins调用docker构建镜像；

5）jenkins将构建好的镜像上传至基于Nexus的私有镜像仓库；

6）jenkins拉取镜像，并部署镜像至Rancher中。

2、组件安装部署

此部分描述需要为devops部署的组件，根据整体方案，devops需要使用gitlab、jenkins、nexus、maven、docker和kubernetes这些组件和系统。其中，gitlab、jenkins、nexus都在kubernetes中安装部署，在jenkins中包含了maven；docker直接在物理机提供，对于docker的部署不在此部分进行阐述。

2.1 代码托管工具-Gitlab

在本文的方案中，代码的托管基于Gitlab。下面是在Kubernetes中部署gitlab的YAML配置文件，在此文件中定义了gitlab部署和服务。gitlab部署使用的镜像为gitlab/gitlab-ce:latest，并暴露了443、80和22这三个端口，并通过NFS对配置文件、日志和数据进行持久化。在服务中，端口的类型为NodePort，即允许集群外的用户可以通过映射在主机节点上的端口对gitlab进行访问。

#------------------------定义代理服务-------------------------
apiVersion: v1
kind: Service
metadata:
  name: gitlab
spec:
  type: NodePort
  ports:
  # Port上的映射端口
  - port: 443
    targetPort: 443
    name: gitlab443
  - port: 80
    targetPort: 80
    name: gitlab80
  - port: 22
    targetPort: 22
    name: gitlab22
  selector:
    app: gitlab
---

# ------------------------定义Gitlab的部署 -----------------------

apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2
kind: Deployment
metadata:
  name: gitlab
spec:
  selector:
    matchLabels:
      app: gitlab
  revisionHistoryLimit: 2
  template:
    metadata:
      labels:
        app: gitlab
    spec:
      containers:
      # 应用的镜像
      - image: gitlab/gitlab-ce 
        name: gitlab
        imagePullPolicy: IfNotPresent
        # 应用的内部端口
        ports:
        - containerPort: 443
          name: gitlab443
        - containerPort: 80
          name: gitlab80
        - containerPort: 22
          name: gitlab22
        volumeMounts:
        # gitlab持久化
        - name: gitlab-persistent-config
          mountPath: /etc/gitlab
        - name: gitlab-persistent-logs
          mountPath: /var/log/gitlab
        - name: gitlab-persistent-data
          mountPath: /var/opt/gitlab
      imagePullSecrets:
      - name: devops-repo
      volumes:
      # 使用nfs互联网存储
      - name: gitlab-persistent-config
        nfs:
          server: 192.168.8.150
          path: /k8s-nfs/gitlab/config
      - name: gitlab-persistent-logs
        nfs:
          server: 192.168.8.150
          path: /k8s-nfs/gitlab/logs
      - name: gitlab-persistent-data
        nfs:
          server: 192.168.8.150
          path: /k8s-nfs/gitlab/data

通过kubectl命令工具，执行如下的命令，在kubernetes集群中部署gitlab：

$ kubectl create -f {path}/gitlab.yaml

2.2 镜像仓库-Nexus

在本文的devops方案中，采用Nexus作为docker私有镜像仓库和maven的远程仓库。下面是在Kubernetes中部署Nexus的YAML配置文件，在此文件中定义了Nexus部署和服务。Nexus部署使用的镜像为sonatype/nexus3:latest，并暴露了8081、5001这两个端口，并通过NFS对配置文件、日志和数据进行持久化。在服务中，端口的类型为NodePort，即允许集群外的用户可以通过映射在主机节点上的端口对nexus进行访问。其中，5001作为docker私有镜像仓库的端口。

#------------------------定义Nexus代理服务-------------------------
apiVersion: v1
kind: Service
metadata:
  name: nexus3
spec:
  type: NodePort
  ports:
  # Port上的映射端口
  - port: 8081
    targetPort: 8081
    name: nexus8081
  - port: 5001
    targetPort: 5001
    name: nexus5001
  selector:
    app: nexus3
---
#-----------------------定义Nexus部署-------------------------
apiVersion: apps/v1beta2
kind: Deployment
metadata:
   name: nexus3
   labels:
     app: nexus3
spec:
   replicas: 1 #副本数为3
   selector: #选择器
     matchLabels:
       app: nexus3 #部署通过app：nginx标签选择相关资源
   template: #Pod的模板规范
     metadata:
       labels:
         app: nexus3 #Pod的标签
     spec:
       imagePullSecrets:
       - name: devops-repo
       containers: #容器
       - name: nexus3
         image: sonatype/nexus3
         imagePullPolicy: IfNotPresent
         ports: #端口
         - containerPort: 8081
           name: nexus8081
         - containerPort: 5001
           name: nexus5001
         volumeMounts:
         - name: nexus-persistent-storage
           mountPath: /nexus-data
       volumes:
       # 宿主机上的目录
       - name: nexus-persistent-storage
         nfs:
           server: 192.168.8.150
           path: /k8s-nfs/nexus

通过kubectl命令工具，执行如下的命令，在kubernetes集群中部署nexus：

$ kubectl create -f {path}/nexus.yaml

2.3 流水线工具-Jenkins

2.3.1 jenkins安装部署

在本文的devops方案中，采用jenkins作为流水线工具。下面是在Kubernetes中部署jenkins的YAML配置文件，在此文件中定义了jenkins部署和服务。jenkins部署使用的镜像为lw96/java8-jenkins-maven-git-vim:latest，并暴露了8080这个端口，并通过NFS对配置文件和数据进行持久化。在服务中，端口的类型为NodePort，即允许集群外的用户可以通过映射在主机节点上的端口对jenkins进行访问。另外，在此镜像中也提供maven和java。

#------------------------定义代理服务-------------------------
apiVersion: v1
kind: Service
metadata:
  name: jenkins-devops
spec:
  type: NodePort
  ports:
  # Port上的映射端口 
  - port: 8080
    targetPort: 8080
    name: pipeline8080
  selector:
    app: jenkins-devops
---

# ------------------------定义mysql的部署 -----------------------
apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2
kind: Deployment
metadata:
  name: jenkins-devops
spec:
  selector:
    matchLabels:
      app: jenkins-devops
  revisionHistoryLimit: 2
  template:
    metadata:
      labels:
        app: jenkins-devops
    spec:
      containers:
      # 应用的镜像
      - image: 10.0.32.148:1008/lw96/java8-jenkins-maven-git-vim
        name: jenkins-devops
        imagePullPolicy: IfNotPresent
        # 应用的内部端口
        ports:
        - containerPort: 8080
          name: pipeline8080 
        volumeMounts:
        # jenkins-devops持久化
        - name: pipeline-persistent
          mountPath: /etc/localtime
        # jenkins-devops持久化
        - name: pipeline-persistent
          mountPath: /jenkins
        # jenkins-devops持久化
        - name: pipeline-persistent-repo
          mountPath: /root/.m2/repository
        - name: pipeline-persistent-mnt
          mountPath: /mnt
      volumes:
      # 使用nfs互联网存储
      - name: pipeline-persistent
        nfs:
          server: 192.168.8.150
          path: /k8s-nfs/jenkins-devops
      - name: pipeline-persistent-mnt
        nfs:
          server: 192.168.8.150
          path: /k8s-nfs/jenkins-devops/mnt
      - name: pipeline-persistent-repo
        nfs:
          server: 192.168.8.150
          path: /k8s-nfs/jenkins-devops/repo

通过kubectl命令工具，执行如下的命令，在kubernetes集群中部署jenkins：

$ kubectl create -f {path}/jenkins-devops.yaml

注意，后续将执行下面的操作：

• 将Kubernetes集群的kubeconfig文件拷贝到192.168.8.150主机的/k8s-nfs/jenkins-devops/mnt目录下；
• 将maven的settings.xml文件拷贝至到192.168.8.150主机的/k8s-nfs/jenkins-devops/repo目录下；
• 将maven的依赖插件包拷贝至到192.168.8.150主机的/k8s-nfs/jenkins-devops/repo目录下。

3、 devops平台搭建

3.1 nexus设置

nexus在devops中承担两个功能，作为maven的远程仓库和作为docker的私有镜像仓库。

在本文中，使用nexus默认安装的maven-snapshots、maven-releases和maven-public这三个仓库。

并为docker创建一个名为registry的私有镜像仓库，其端口为5001：

3.2 maven设置

maven负责管理代码的依赖关系和构建。maven通过settings.xml文件设置运行环境，包括与远程仓库的连接。本文中的settings.xml如下所示，http://nexus3:8081中的nexus3是在kubernetes中的服务名称。将settings.xml拷贝至192.168.8.150机器的/k8s-nfs/jenkins-devops/repo目录下。

<?xml version="1.0" encoding="UTF-8"?>
<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0"
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 http://maven.apache.org/xsd/settings-1.0.0.xsd">
  <pluginGroups>
  </pluginGroups>
  <proxies>
  </proxies>
  <servers>
     <server>     
      <id>maven-release</id>     
      <username>admin</username>     
      <password>admin123</password>     
    </server>     
    <server>     
      <id>maven-snapshots</id>     
      <username>admin</username>     
      <password>admin123</password>     
    </server>     
  </servers>

  <mirrors>
    <mirror>        
     <id>nexus</id>         
     <url>http://nexus3:8081/repository/maven-public/</url>        
     <mirrorOf>*</mirrorOf>        
   </mirror>     
 </mirrors> 

  <profiles>
  <profile>
      <id>maven-release</id>
      <activation>
        <activeByDefault>true</activeByDefault>
      </activation>
      <repositories>
        <repository>
          <id>maven-release</id>
          <name>Repository for Release</name>
          <url>http://nexus3:8081/repository/maven-releases/</url>
     <releases>
     <enabled>false</enabled>
     </releases>
     <snapshots>
     <enabled>true</enabled>
     </snapshots>
        </repository>
      </repositories>
    </profile>

  <profile>
      <id>maven-snapshots</id>
      <activation>
        <activeByDefault>true</activeByDefault>
      </activation>
      <repositories>
        <repository>
          <id>maven-release</id>
          <name>Repository for Release</name>
          <url>http://nexus3:8081/repository/maven-snapshots/</url>
     <releases>
     <enabled>false</enabled>
     </releases>
     <snapshots>
     <enabled>true</enabled>
     </snapshots>
        </repository>
      </repositories>
    </profile>
  </profiles>
</settings>

3.3 docker设置

为了能够支持将远程提交的代码构建成镜像，以及将构建好的镜像上传至镜像仓库需要在/etc/docker/daemon.json的文件中添加下面的内容。其中，10.0.32.163:32476为镜像仓库的地址和端口，tcp://0.0.0.0:4243为对外暴露的地址和端口。

{
"hosts":["tcp://0.0.0.0:4243","unix:///var/run/docker.sock"],
"insecure-registries":["10.0.32.163:32476"]
}

并通过执行下面的命令重启docker服务：

$ systemctl daemon-reload
$ systemctl restart docker

3.4 jenkins设置

3.4.1 安装插件

jenkins作为devops平台的流程线工具，需要从gitlab中获取代码，并提交给maven进行构建；在代码构建成功后，调用docker构建镜像，并将上传至基于Nexus的私有镜像仓库；最终，在Kubernetes中部署和运行镜像。为了实现上述能力，需要在jenkins中安装如下插件：

• git plugin：与gitlab集成的插件，用于获取代码；
• maven plugin：与maven集成的插件，用于构建代码；
• CloudBees Docker Build and Publish plugin：与docker集成的插件，用于构建docker镜像，并上传至镜像仓库；
• Kubernetes Continuous Deploy Plugin：与kubernetes集成的插件，用于将镜像部署到kubernetes环境。

3.4.2 maven设置

在jenkins中的“全局工具配置”页面，设置maven的安装信息，name可以按照自己的喜好填写，MAVEN_HOME为maven的安装地址，此处为/opt/maven。

4、devops持续集成示例

1）安装git客户端和创建密钥

在工作计算上安装git客户端，并通过下面的命令创建ssh密钥：

ssh-keygen -t rsa -C "your.email@example.com" -b 4096

执行上述命令后，会在本地的～/.ssh目录创建id_rsa.pub(公钥)和id_rsa(私钥)。

2）在gitlab创建oms项目

进入gitlab，并创建一个名称为oms的项目。

在gitlab中添加所创建的公钥：

3）在eclipse中进行代码开发

在eclipse中创建类型为maven的oms项目，并进行代码开发。在完成代码开发后，将代码上传至gitlab中进行代码托管。

4）在jenkins中创建oms项目

进入jenkins，创建一个名称为oms的maven项目。

5）在jenkins中设置获取代码信息

在jenkins中，进入oms的配置页面，在源代码管理处设置获取源代码的相关信息。

• Repository URL：项目在gitlab中的地址；
• Credentials：访问gitlab的认证方式；
• Branch Specifier：代码的分支。

此处访问gitlab的认证方式为“SSH Username with private key”，Private Key的值来自于～/.ssh目录下id_rsa(私钥)的内容。

6）在jenkins中设置构建和上传镜像信息

在oms项目的配置的“Docker Build and Publish”部分，填写如下的信息；

• Repository Name：镜像的名称；
• Tag：镜像的版本；
• Docker Host URI：docker服务的地址和端口；
• Docker registry URL：docker镜像仓库的地址；
• Registry credentials：镜像仓库的认证方式。

7）在jenkins中设置部署容器信息

在oms项目的配置的“Deploy to Kubernetes”部分，填写如下的信息；

• Kubernetes Cluster Credentials：Kubernetes集群的认证方式；
• Path：kubeconfig文件的所在地址；
• Config Files：构建YAML配置文件。

8）在jenkins中执行oms构建

在oms项目创建和设置完成后，可以对项目进行构建操作。通过一键操作，jenkins将会完成从构建、打包成镜像和部署的所有工作内容：

• 从gitlab中获取oms的代码；
• 提交给maven进行构建；
• 调用docker构建镜像；
• 上传镜像至Nexus的私有镜像仓库；
• 部署镜像到kubernetes集群。

9）在kubernetes中查看部署情况

进入kubernetes(本文使用的为Rancher系统)界面，在default命名空间下，可以看到已部署的oms。

参考材料

1.《User documentation》地址：http://10.0.32.163:32269/help/user/index.md

2.《CloudBees Docker Build and Publish plugin》地址：https://wiki.jenkins.io/display/JENKINS/CloudBees+Docker+Build+and+Publish+plugin

3.《Kubernetes Continuous Deploy Plugin》地址：https://wiki.jenkins.io/display/JENKINS/Kubernetes+Continuous+Deploy+Plugin

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

微信公众号：ik8s