容器技术和 Kubernetes 的下一站在哪里？ | 航海日志 Vol.37

Posted 2021-04-16 道客船长

1.容器技术和 Kubernetes 的下一站在哪里？

2.Overclock Lab 投注于 Kubernetes，帮助公司自动化云基础架构

3.Docker 镜像支持多平台架构

➤ 容器技术和 Kubernetes 的下一站在哪里？

 

想知道容器技术的路在何方？跟着钱的方向看就对了。有很多这样的证据都指向了这个趋向：有 451 个调查项目表明，到 2020 年容器技术的整体市场将达到约 27 亿美元，与2016 年的 7.62 亿相比，增长了整整 3.5 倍。

 

这爆炸增长的背后有一个非常明显的根本因素：迅速增长的容器化需求。而与之相同的：随着对于容器技术采用的增长，对于容器编排工具的采用也随之增长。

 

来自The New Stack 的最新数据调查显示，容器技术的不断普及是容器编排工具采用的最重要催化剂：有60%的广泛在生产环境部中署容器的受访者表示他们也在生产环境中广泛使用 Kubernetes。另有 19 %的受访者表示，他们正处于广泛采用 Kubernetes 的初级阶段。与此同时，处在在生产环境中部署容器的初始阶段的受访者中，只有5%广泛使用 Kubernetes -- 但有 58 %的人表示他们预备这样做。由上可得，他们之间是一个鸡与蛋的关系。

 

大多数专家都认为，编排工具对容器可扩展的长期管理至关重要，并且也更符合容器市场发展的需求。Cockroach 实验室的软件工程师 Alex Robinson 说：“容器编排的下一个趋势将是扩大采用范围。”

 

其格局转变迅速，我们才刚刚开始意识到其未来蕴含的潜力。所以我们和 Robinson 以及其他从业者一起参与了调研，通过大众的视角，来看看容器编排的下一步发展 -- 即 Kubernetes 本身的发展。

容器业务将转为主流

我们正站在大多数重大技术变革的浪潮之巅，在这之上我们从小心翼翼到悬崖跳水般的常态化使用。对大型企业来说，这创造了新的需求，让对主流业务的采用变得更加简单。

 

Robinson 表示：“早期技术变革的淘金期已经逐步放缓，现阶段我们需要更为注重的是稳定性和可用性。这也意味着新的编排工具的发布将逐步减少，取而代之的是：更多的安全选项、管理工具和功能，这能更容易利用主流业务系统中已有的灵活性。

复杂性将被降低

在相关的领域，我们更期望能将努力放到减少一些组织在第一次投身于容器业务时所面临的复杂性上。就像上面提到的那样，部署容器可能是“容易的”，但需要投放更多的关注在长期管理容器之上。

来自 Codemill AB 的开发人员 My Karlsson 表示：“如今的容器编排工具非常复杂，许多的用户都无法对其进行充分的利用。一些新用户往往挣扎在让单个或小型容器配置的独立运行上，特别是遭遇如果应用程序不是一开始为其设计的情况的。不过也存在很多的手段来简化复杂应用程序的编排，让技术更为易用。”

 

对于混合云和多云的关注持续增加

随着容器和容器编排的采用不断增长，越来越多的组织将从一个起点 -- 即在单一环境中运行非关键的工作负载，转换到跨多个环境的更复杂用例。对于许多公司来说，这意味着需要在全球范围内跨混合云和多云环境管理容器化的应用程序（特别是容器化的微服务）。

有行业的专业人士表明：“容器和 Kubernetes 实现了混合云和应用程序的可移植性”。CloudBees 的高级软件工程师 Carlos Sanchez 表示：“我相信容器组织将会得到推动不断发展，实现诸如无缝多区域和多云部署等非常受欢迎的功能。” 

继续整合平台和工具

技术的合并是共同的趋势 -- 对于容器编排来说也不例外。

Sumo Logic 公司分析主管 Ben Newton 表示：“随着容器化成为主流，工程师们正在利用极少的技术来运行他们的（微服务和）容器，而 Kubernetes 已成为主流的容器编排平台，并将远远超过其他平台。很多公司将采用 Kubernetes 来推动云原生的方法，因为 Kubernetes 提供了一个非常明确的手段来减少对特定云生态系统的依赖。”

说到 Kubernetes，下一站又是什么?

Kubernetes 有着长远目标，社区也在为这个目标进行着努力。下面是几位专家对于 Kubernetes 下一站的展望： 
“

  Vision 1：

运营商将会不断发展和成熟，使运行在 Kubernetes 上的应用程序能够完全自我管理。使用OpenTracing 和服务网格框架（如 istio）在 Kubernetes 上部署和监控微服务将有助于形成新的可能性。

  Vision 2：

Kubernetes 继续扩大其所能支持的应用类型。当你可以在同一平台上运行传统应用程序，云原生应用程序，大数据应用程序，以及HPC或以GPU为中心的应用程序时，它可以释放大量架构灵活性。

  Vision 3：

随着Kubernetes变得更加占统治地位，我希望看到更多的运营机制正常化，尤其是与第三方管理和监控平台的整合。

  Vision 4：

在不久的将来，或许可以在没有 Docker 的情况下运行同样，查找存储的改进，以支持企业的功能，如数据快照和在线调整卷大小。

  Vision 5：

现在 Kubernetes 社区越来越重视管理有状态的应用程序。如果你不是在提供远程永久磁盘的云中运行，那么现在管理 Kubernetes 中的状态是非常困难的，但是在多个方面（包括Kubernetes 和外部供应商）都在努力改进这一点。

”

➤ Overclock Lab 投注于 Kubernetes，帮助公司自动化云基础架构

前端时间道客船长为您报道了《》Kubernetes 的发展势不可遏。近期，Overclock Labs 希望让开发人员能够更轻松地跨云部署，并管理他们的应用程序。为此，该公司正在开发工具来自动化分布式云基础架构。毫不意外，Overclock Labs 将赌注押容器上，尤其是 Kubernetes 容器编排工具上。

该公司预计利用此前未公开的资金轮来开发 DISCO，其代表用于无服务计算操作的分布式基础结构。但这些高级服务究竟会是什么样子还有待观察，目前公司的首要任务是在未来几个月内发布 DISCO，然后在其周围建立一个生态系统。

➤ Docker 镜像支持多平台架构

真正的多平台工作负载的可移植性一直被誉为企业计算的“圣杯”。多年来，各种各样的虚拟化策略都在尝试去接近这样的目标。一方面，虚拟机和硬件的虚拟化已经做够灵活，你可以在同一台主机上混合地搭配操作系统（甚至是 CPU 架构），但这会带来很多的开销。但是基于语言的虚拟运行时不具有封装所有系统级的应用程序依赖性的打包格式，这使得他们不适合于通用部署和配置管理。

Docker 使用现有的 Linux 内核功能来提供类似于虚拟机可用的隔离特性。“标准的集装箱”的比喻与这些隔离原理相结合，并立即激发了许多开发商的兴趣。有了这种新的运输隐喻，速度和敏捷性就会打破虚拟机大小和速度限制，从而影响开发人员的工作流程。从那以后，容器化的热潮就像野火一样发展起来，但让我们回到亨利·福特式的难题：“只要是 Linux上 的 x86_64 CPU 架构，你就可以在任何地方运行一个容器。”

随着 Docker 和对容器容器技术的兴趣的不断增长，包括 Raspberry Pi 爱好者，FreeBSD，Solaris，ARM 微服务器，OpenPOWER 和 z/Linux 社区在内的许多其他UNIX 和 Linux 用户群体都渴望加入热潮之中，迅速应用 Docker 容器引擎和其他必需的组件到他们的 UNIX 和 CPU 特定的体系结构之中。同时，微软也投身于此，并在Windows Server 内核中增加了容器化的功能，与 Docker 一起将 Docker 引擎移植到 Windows 之上。在哥本哈根的 DockerCon 上，Michael Friis 和我在他们的演讲“ Docker：Multi-Arch All Things”中分享了这个多平台的旅程。” 

演讲视频：https://blog.docker.com/2017/11/multi-arch-all-the-things/

这一期的『航海日志』就到这里，看下彩蛋