CoreOS Fest 系列之第二篇: Systemd、Go、Calico、Sysdig

  1. 云栖社区>
  2. DockOne.io>
  3. 博客>
  4. 正文

CoreOS Fest 系列之第二篇: Systemd、Go、Calico、Sysdig

轩墨 2017-09-26 11:48:00 浏览1615
展开阅读全文
本文讲的是CoreOS Fest 系列之第二篇: Systemd、Go、Calico、Sysdig【编者的话】在 CoreOS Fest 第二天的会议中,演讲者展示了多个开源项目和工具,包括 Systemd 和 CoreOS 、 Go 语言和容器、 Calico 项目、 Sysdig 等。

在 CoreOS Fest 的第一天会议中,陆续介绍了 CoreOS 的架构、规划和规范。第二天的会议,演讲者展示了多个开源项目和工具,包括 systemd-nspawn 、 Calico 项目和 Sysdig 等。上述项目大多数已经开发了一年有余,但是大部分 CoreOS Fest 的与会者是第一次了解这些项目。

不仅是会议的内容吸引人,更引人注意的是,在过去的一年多时间内,社区开发了大量支持 Linux 容器的新工具。在 Linux 领域,如此快的发展速度,前所未见。在以容器为核心的新型基础设中, systemd 是一个基础组件,它是 Linux 的新型初始化系统,支持容器的开箱即用。

Systemd 和 CoreOS

Red Hat 的 Lennart Poettering 就 Systemd 和 CoreOS 做了演讲,他介绍了集成容器管理功能的 systemd 工具。与其它的初始化系统相比,用 systemd 构建容器更有优势。 systemd 提供了在单机上管理不同容器所需的所有工具。

他首先指出,这次并不是代表 Red Hat 官方的报告。然后,他花了很多时间介绍 Red Hat 的 systemd 团队。这个团队并不是一个产品团队,他说:「我们自认为是一个研究部门,而不是一个产品团队」。

这种表态解释了 systemd 选择某些技术的原因,例如,选择 Btrfs 作为 systemd-nspawn 模板和容器的主要文件系统。「人们都说 btrfs 是一个不稳定的文件系统。但是, btrfs 项目团队正在努力解决该文件系统存在的基础性问题」,他说。而且,在一个不稳定的文件系统上运行容器,这是可以接受的,因为数据被保存在外部的卷上,而不是在容器内(译者注:即没有保存在这个不稳定的文件系统上)。

systemd 包含多个支持容器的守护进程,即 systemd-machinedsystemd-networkd 和 systemd-resolved 。总的来说,所有的 systemd 进程都兼容容器,因为「更多时候,我们是在容器中而不是裸机上测试 systemd 」。这么做的好处是,不用重启开发用的笔记本电脑,就可以测试 systemd 进程。Poettering 认为集成容器是 Linux 的一项重要特性,他说:「容器应该默认集成到 Linux 操作系统中,就像 Zones 已经成为 Solaris 操作系统的一部分」。

systemd 团队的目标是保持 systemd 中立,不仅支持 rkt 容器,还支持 docker, libvirt-lxcOpenVZ 等。 systemd 提供了很多与容器相关的功能,它是一个偏底层的工具,不提供复杂的用户界面。像 CoreOS 和kubernetes 等项目可以调用 systemd 的功能,完成对容器的基本操作。

在 systemd 中,管理容器的主要工具是 systemd-machined 及其命令行工具 machinectl 。有了它,用户能够列出所有的容器,启动和关停容器,甚至交互登录到容器中。 systemd-machined 实际上是容器的注册中心,任何容器都可以注册。 systemd-machined 配合 systemd ,执行 systemd-run -M ,就能在容器中执行任何命令。 systemd-machined 运行的容器,会出现在 ps 命令的列表或者 GNOME 的系统监控器中。

systemd-nspawn 是一个轻量的容器执行器,它是一个像 docker 那样能够启动和关停容器的工具。 为 systemd-nspawn 指定任何包含主引导记录( MBR )或者 GUID 分区表的文件系统或者块设备,它就能启动一个容器。如果用户只需要具备基本功能、免配置的容器, systemd-nspawn 是一个很有吸引力的选择。 rkt 底层也是调用 systemd-nspawn 运行容器。

systemd-networkd 是管理网络的 systemd 守护进程,而 systemd-resolved 是解析主机名字的 systemd 守护进程,它们都支持容器。 systemd-networkd 自动启动容器的网络,利用 DHCP 为容器分配内部的网络地址。 systemd-resolved 使用本地链路多播名字解析( link-local multicast name resolution, LLMNR )系统,为容器提供主机名。 LLMNR 是 Microsoft 发明的自动名字发现系统,初衷是用在客户端应用和移动设备中,但是它也可以用于网络环境中容器之间的彼此发现。

根据 Poettering 的演讲,看起来 systemd 是 Docker 公司的 libcontainer 以及其它容器初始化和管理工具的强力替代。由于大部分 Linux 发行版的最新版都会集成 systemd ,大多数用户将能够立即使用 systemd 。这也能解释为什么容器领域的大多数公司都选择编排作为主攻点,因为 systemd 本身不提供容器编排功能。

Go 语言和容器

CoreOS 公司 CEO Alex Polvi 做主题演讲时宣布 CoreOS 公司将赞助第二届 Gophercon —— Go 语言开发者大会。 有 6 家 Gophercon 赞助商都是容器公司,约占赞助商总数的 1/4 。这是有原因的,无论 CoreOS 公司还是 Docker 公司,它们使用的主要编程语言都是 go 。 Polvi 如此说道:「只有使用 go 语言才能开发出 Etcd 」。

我听的每一个演讲,我到的每一个会议室,人们都在谈论 go 语言,用它写代码。 EtcdfleetSwarm, Kubernetes, Kurma 等容器工具应用或者服务都是用 Go 语言编写的。 Linux 容器平台的崛起,同样是 Go 语言的崛起。

Go 语言始于 2007 年 Google 公司的一个内部项目,共有 3 个开发者。现在, go 语言项目的贡献者已经超过 500 人。 Go 是一个使用 BSD 许可的开源项目,但是仍然由 Google 公司把持,所有的贡献者都需要与 Google 公司签署贡献者许可协议( Contributor License Agreement, CLA )。 Go 逐渐成为实现可扩展基础设施的「自动化语言」。之前, 人们已经普遍使用 go 语言实现网络代理、云服务器管理工具、分布式搜索引擎和冗余数据存储。很自然地,人们继续选择 go 实现容器工具应用。

由于 CoreOS 与 go 的紧密联系, Brad Fitzpatrick 的报告主题是 go 语言的持续构建基础设施。他是 LiveJournal, memcached 和 OpenID 的开发者,现在是 Google 公司 go 语言团队的一员。他展示了在很多平台上测试 go 语言的自动构建平台。构建平台刚开始时是一个 Google 应用引擎( Google Application Engine )应用,加上桌子上一排的移动设备,然后发展成今天这个样子。他还讲述了持续构建基础设施的历史和工作机制。

Go 是一种编译型而不是解释型编程语言。编译得到的二进制程序,能够在多种平台上执行。每个版本的 go 语言在发布之前,首先要在 Google 公司机器实验室拥有的几百种平台上成功地构建。只有在各种 Linux 平台构建 go 语言时才会用到容器,其它很多平台并不支持容器,像 MAC OS X 和 Android 平台就必须使用专用的硬件,因此容器在自动构建平台中的作用比较小。你可以在这里 看到 go 语言在各个平台的构建结果,哪些成功了,哪些失败了。

Calico 项目

其实 Calico 项目 已经开源差不多一年了。当核心开发者 Spike Curtis 报告时,大多数与会者是第一次听说这个项目。 Calico 是一个多主机路由软件,还包含一个分布式防火墙。 Calico 是专门为容器和虚拟机尤其是 docker 和 OpenStack 环境设计的。 Metaswitch Networks 公司用 python 语言开发 Calico ,它也是唯一提供 Calico 商业化支持的公司。看起来, calico 有望成为这样一种解决方案:用户能够在生产环境部署容器,同时保证严格的安全。

「还记得三层架构吗?」 Curtis 抱怨说,「管理员现在还是这样管理网络。第一层是外部网络,中间是 web 资源所在的隔离区( demilitarized zone, DMZ),最后是数据层,要求保证最严格的安全」。

编排好网络中的容器,运行微服务,这种模式打破了三层模型。首先,微服务是根据服务的提供者而不是服务的安全特征划分的;其次,编排框架假设数据中心网络是无区分的,也不支持安全分层的概念;最重要的是,你得为几百个微服务定义安全策略和区域,这不像以前,网络管理员只要设定几十个策略和区域就行了。 Curtis 说,「这就像是一个动物园,所有围墙都被推到了」。

然而,就安全而言,微服务也为带来了机会。每个微服务只做一件事情,它的安全需求也相对简单。因此,可以更细致地划分服务,又不增加整体的复杂性, calico 就是这么做的。

Calico 为每个容器或者虚拟机分配一个独立的 IP 地址,然后在每台物理主机上定义包含这些 IP 地址的 iptables 规则,实现了防火墙功能。 Calico 用保存在 etcd 的标签定义每个服务,用一个 JSON 格式的配置文件定义允许访问当前服务的其它服务,以及这个服务是否可通过 Internet 访问。

只要编排框架支持为每个服务分配一个 IP 地址,就可以集成使用 calico 。Curtis 演示了 calico 与 kubernetes 的集成,包括用扩展的 pod 定义来设定每个容器的安全设置。 Apache Mesos 正在实现为每个服务分配一个 IP 地址的功能,暂时还不能集成 calico 。

Sysdig

最后一个「新」项目是 Sysdig ,就像 calico 项目一样, 它也是一年多以前就发布了,但是大部分与会者都是第一次听说这个项目。站在 sysdig 背后的公司是 Sysdig Cloud ,它为 sysdig 的用户提供商业化支持。 Sysdig Cloud 公司 CEO Loris Degioanni 展示了这款工具。

Sysdig 是一个网络流监控系统,部分功能实现为一个 Linux 内核模块。这个模块捕捉了所有的网络流,特别是容器之间的网络包。用户还可以用 Lua 语言编写网络流信息的过滤器,然后把过滤得到的信息聚合在一起,进行统计分析。你可以把它视为 wireshark 和 tcpdump 的高级版本,尤其是支持容器。

Degioanni 说,sysdig 比 Google 的 cAdvisor 项目高明,因为 cAdvisor 只报告容器占用的全部 CPU 、内存和网络,而 sysdig 还能够提供网络流的发送方、接收方和内容。例如,用户可以找出对某个数据库的查询,搞清楚为什么两个 IP 地址之间的网络通信延误得厉害。

Degioanni 还展示了即将发布的 sysdig 的文本用户界面,这是一个基于 curses 的开源项目。有了它,系统管理员能够用 ssh 登录到系统,执行交互的监控任务。他演示了如何深入检查和汇总容器之间的网络通信,还演示了如何调查网络延迟。在 Sysdig Cloud 公司的展台,工作人员演示了商业化产品—— sysdig 的图形界面,用户只需点击多层嵌套的服务器、 pod 和容器,就可以查看对应的网络流。

小结

我从 CoreOS Fest 大会了解了这么多的新项目、新工具、标准草案和新架构,这充分说明 Linux 容器领域发展之快。要知道,在一年前,当我报道首届 DockerCon 时,这些新技术和新工具,大部分才刚刚发布,有的甚至还不存在。等再过一年,我们看看是不是还发展得这么快。

我们还没有涉及一个主要的话题:如何在容器中持久保存数据。前文曾经提及,目前普遍的看法是容器应该是无状态的,不保存数据。不坚持这一点,容器管理和编排会遇到一系列亟需解决的问题,例如,外部卷的管理、容器迁移和有状态服务的负载均衡等。下个星期,我们将讨论与持久话数据和容器相关的多个话题,内容来自于 CoreOS Fest 和 Container Camp 。

原文链接: New projects from day two of CoreOS Fest (翻译:柳泉波)

原文发布时间为: 2015-06-19
本文作者:bnuhero 
本文来自云栖社区合作伙伴DockerOne,了解相关信息可以关注DockerOne。
原文标题:CoreOS Fest 系列之第二篇: Systemd、Go、Calico、Sysdig

网友评论

登录后评论
0/500
评论
轩墨
+ 关注
所属团队号: DockOne.io