标签容器下的文章

Kubernetes 网络运维

Julia Evans 发布于 2018-09-12
另请参阅: 系统运维,网络, 容器, Kubernetes
评论

最近我一直在研究 Kubernetes 网络。我注意到一件事情就是，虽然关于如何设置 Kubernetes 网络的文章很多，也写得很不错，但是却没有看到关于如何去运维 Kubernetes 网络的文章、以及如何完全确保它不会给你造成生产事故。

在本文中，我将尽力让你相信三件事情（我觉得这些都很合理 :)）：

避免生产系统网络中断非常重要
运维联网软件是很难的
有关你的网络基础设施的重要变化值得深思熟虑，以及这种变化对可靠性的影响。虽然非常“牛x”的谷歌人常说“这是我们在谷歌正在用的”（谷歌工程师在 Kubernetes 上正做着很重大的工作！但是我认为重要的仍然是研究架构，并确保它对你的组织有意义）。

我肯定不是 Kubernetes 网络方面的专家，但是我在配置 Kubernetes 网络时遇到了一些问题，并且比以前更加了解 Kubernetes 网络了。

运维联网软件是很难的

在这里，我并不讨论有关运维物理网络的话题（对于它我不懂），而是讨论关于如何让像 DNS 服务、负载均衡以及代理这样的软件正常工作方面的内容。

我在一个负责很多网络基础设施的团队工作过一年时间，并且因此学到了一些运维网络基础设施的知识！（显然我还有很多的知识需要继续学习）在我们开始之前有三个整体看法：

联网软件经常重度依赖 Linux 内核。因此除了正确配置软件之外，你还需要确保许多不同的系统控制（sysctl）配置正确，而一个错误配置的系统控制就很容易让你处于“一切都很好”和“到处都出问题”的差别中。
联网需求会随时间而发生变化（比如，你的 DNS 查询或许比上一年多了五倍！或者你的 DNS 服务器突然开始返回 TCP 协议的 DNS 响应而不是 UDP 的，它们是完全不同的内核负载！）。这意味着之前正常工作的软件突然开始出现问题。
修复一个生产网络的问题，你必须有足够的经验。（例如，看这篇由 Sophie Haskins 写的关于 kube-dns 问题调试的文章）我在网络调试方面比以前进步多了，但那也是我花费了大量时间研究 Linux 网络知识之后的事了。

我距离成为一名网络运维专家还差得很远，但是我认为以下几点很重要：

对生产网络的基础设施做重要的更改是很难得的（因为它会产生巨大的混乱）
当你对网络基础设施做重大更改时，真的应该仔细考虑如果新网络基础设施失败该如何处理
是否有很多人都能理解你的网络配置

切换到 Kubernetes 显然是个非常大的更改！因此，我们来讨论一下可能会导致错误的地方！

Kubernetes 网络组件

在本文中我们将要讨论的 Kubernetes 网络组件有：

覆盖网络 overlay network 的后端（像 flannel/calico/weave 网络/romana）
kube-dns
kube-proxy
入站控制器 / 负载均衡器
kubelet

如果你打算配置 HTTP 服务，或许这些你都会用到。这些组件中的大部分我都不会用到，但是我尽可能去理解它们，因此，本文将涉及它们有关的内容。

最简化的方式：为所有容器使用宿主机网络

让我们从你能做到的最简单的东西开始。这并不能让你在 Kubernetes 中运行 HTTP 服务。我认为它是非常安全的，因为在这里面可以让你动的东西很少。

如果你为所有容器使用宿主机网络，我认为需要你去做的全部事情仅有：

配置 kubelet，以便于容器内部正确配置 DNS
没了，就这些！

如果你为每个 pod 直接使用宿主机网络，那就不需要 kube-dns 或者 kube-proxy 了。你都不需要一个作为基础的覆盖网络。

这种配置方式中，你的 pod 们都可以连接到外部网络（同样的方式，你的宿主机上的任何进程都可以与外部网络对话），但外部网络不能连接到你的 pod 们。

这并不是最重要的（我认为大多数人想在 Kubernetes 中运行 HTTP 服务并与这些服务进行真实的通讯），但我认为有趣的是，从某种程度上来说，网络的复杂性并不是绝对需要的，并且有时候你不用这么复杂的网络就可以实现你的需要。如果可以的话，尽可能地避免让网络过于复杂。

运维一个覆盖网络

我们将要讨论的第一个网络组件是有关覆盖网络的。Kubernetes 假设每个 pod 都有一个 IP 地址，这样你就可以与那个 pod 中的服务进行通讯了。我在说到“覆盖网络”这个词时，指的就是这个意思（“让你通过它的 IP 地址指向到 pod 的系统）。

所有其它的 Kubernetes 网络的东西都依赖正确工作的覆盖网络。更多关于它的内容，你可以读这里的 kubernetes 网络模型。

Kelsey Hightower 在 kubernetes 艰难之路中描述的方式看起来似乎很好，但是，事实上它的作法在超过 50 个节点的 AWS 上是行不通的，因此，我不打算讨论它了。

有许多覆盖网络后端（calico、flannel、weaveworks、romana）并且规划非常混乱。就我的观点来看，我认为一个覆盖网络有 2 个职责：

确保你的 pod 能够发送网络请求到外部的集群
保持一个到子网络的稳定的节点映射，并且保持集群中每个节点都可以使用那个映射得以更新。当添加和删除节点时，能够做出正确的反应。

Okay! 因此！你的覆盖网络可能会出现的问题是什么呢？

覆盖网络负责设置 iptables 规则（最基本的是 iptables -A -t nat POSTROUTING -s $SUBNET -j MASQUERADE），以确保那个容器能够向 Kubernetes 之外发出网络请求。如果在这个规则上有错误，你的容器就不能连接到外部网络。这并不很难（它只是几条 iptables 规则而已），但是它非常重要。我发起了一个拉取请求，因为我想确保它有很好的弹性。
添加或者删除节点时可能会有错误。我们使用 flannel hostgw 后端，我们开始使用它的时候，节点删除功能尚未开始工作。
你的覆盖网络或许依赖一个分布式数据库（etcd）。如果那个数据库发生什么问题，这将导致覆盖网络发生问题。例如，https://github.com/coreos/flannel/issues/610 上说，如果在你的 flannel etcd 集群上丢失了数据，最后的结果将是在容器中网络连接会丢失。（现在这个问题已经被修复了）
你升级 Docker 以及其它东西导致的崩溃
还有更多的其它的可能性！

我在这里主要讨论的是过去发生在 Flannel 中的问题，但是我并不是要承诺不去使用 Flannel —— 事实上我很喜欢 Flannel，因为我觉得它很简单（比如，类似 vxlan 在后端这一块的部分只有 500 行代码），对我来说，通过代码来找出问题的根源成为了可能。并且很显然，它在不断地改进。他们在审查拉取请求方面做的很好。

到目前为止，我运维覆盖网络的方法是：

学习它的工作原理的详细内容以及如何去调试它（比如，Flannel 用于创建路由的 hostgw 网络后端，因此，你只需要使用 sudo ip route list 命令去查看它是否正确即可）
如果需要的话，维护一个内部构建版本，这样打补丁比较容易
有问题时，向上游贡献补丁

我认为去遍历所有已合并的拉取请求以及过去已修复的 bug 清单真的是非常有帮助的 —— 这需要花费一些时间，但这是得到一个其它人遇到的各种问题的清单的好方法。

对其他人来说，他们的覆盖网络可能工作的很好，但是我并不能从中得到任何经验，并且我也曾听说过其他人报告类似的问题。如果你有一个类似配置的覆盖网络：a) 在 AWS 上并且 b) 在多于 50-100 节点上运行，我想知道你运维这样的一个网络有多大的把握。

运维 kube-proxy 和 kube-dns？

现在，我有一些关于运维覆盖网络的想法，我们来讨论一下。

这个标题的最后面有一个问号，那是因为我并没有真的去运维过。在这里我还有更多的问题要问答。

这里的 Kubernetes 服务是如何工作的！一个服务是一群 pod 们，它们中的每个都有自己的 IP 地址（像 10.1.0.3、10.2.3.5、10.3.5.6 这样）

每个 Kubernetes 服务有一个 IP 地址（像 10.23.1.2 这样）
kube-dns 去解析 Kubernetes 服务 DNS 名字为 IP 地址（因此，my-svc.my-namespace.svc.cluster.local 可能映射到 10.23.1.2 上）
kube-proxy 配置 iptables 规则是为了在它们之间随机进行均衡负载。Kube-proxy 也有一个用户空间的轮询负载均衡器，但是在我的印象中，他们并不推荐使用它。

因此，当你发出一个请求到 my-svc.my-namespace.svc.cluster.local 时，它将解析为 10.23.1.2，然后，在你本地主机上的 iptables 规则（由 kube-proxy 生成）将随机重定向到 10.1.0.3 或者 10.2.3.5 或者 10.3.5.6 中的一个上。

在这个过程中我能想像出的可能出问题的地方：

kube-dns 配置错误
kube-proxy 挂了，以致于你的 iptables 规则没有得以更新
维护大量的 iptables 规则相关的一些问题

我们来讨论一下 iptables 规则，因为创建大量的 iptables 规则是我以前从没有听过的事情！

kube-proxy 像如下这样为每个目标主机创建一个 iptables 规则：这些规则来自这里）

-A KUBE-SVC-LI77LBOOMGYET5US -m comment --comment "default/showreadiness:showreadiness" -m statistic --mode random --probability 0.20000000019 -j KUBE-SEP-E4QKA7SLJRFZZ2DD[b][c]  
-A KUBE-SVC-LI77LBOOMGYET5US -m comment --comment "default/showreadiness:showreadiness" -m statistic --mode random --probability 0.25000000000 -j KUBE-SEP-LZ7EGMG4DRXMY26H  
-A KUBE-SVC-LI77LBOOMGYET5US -m comment --comment "default/showreadiness:showreadiness" -m statistic --mode random --probability 0.33332999982 -j KUBE-SEP-RKIFTWKKG3OHTTMI  
-A KUBE-SVC-LI77LBOOMGYET5US -m comment --comment "default/showreadiness:showreadiness" -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-CGDKBCNM24SZWCMS 
-A KUBE-SVC-LI77LBOOMGYET5US -m comment --comment "default/showreadiness:showreadiness" -j KUBE-SEP-RI4SRNQQXWSTGE2Y

因此，kube-proxy 创建了许多 iptables 规则。它们都是什么意思？它对我的网络有什么样的影响？这里有一个来自华为的非常好的演讲，它叫做支持 50,000 个服务的可伸缩 Kubernetes，它说如果在你的 Kubernetes 集群中有 5,000 服务，增加一个新规则，将需要 11 分钟。如果这种事情发生在真实的集群中，我认为这将是一件非常糟糕的事情。

在我的集群中肯定不会有 5,000 个服务，但是 5,000 并不是那么大的一个数字。为解决这个问题，他们给出的解决方案是 kube-proxy 用 IPVS 来替换这个 iptables 后端，IPVS 是存在于 Linux 内核中的一个负载均衡器。

看起来，像 kube-proxy 正趋向于使用各种基于 Linux 内核的负载均衡器。我认为这只是一定程度上是这样，因为他们支持 UDP 负载均衡，而其它类型的负载均衡器（像 HAProxy）并不支持 UDP 负载均衡。

但是，我觉得使用 HAProxy 更舒服！它能够用于去替换 kube-proxy！我用谷歌搜索了一下，然后发现了这个 thread on kubernetes-sig-network，它说：

kube-proxy 是很难用的，我们在生产系统中使用它近一年了，它在大部分的时间都表现的很好，但是，随着我们集群中的服务越来越多，我们发现它的排错和维护工作越来越难。在我们的团队中没有 iptables 方面的专家，我们只有 HAProxy & LVS 方面的专家，由于我们已经使用它们好几年了，因此我们决定使用一个中心化的 HAProxy 去替换分布式的代理。我觉得这可能会对在 Kubernetes 中使用 HAProxy 的其他人有用，因此，我们更新了这个项目，并将它开源：https://github.com/AdoHe/kube2haproxy。如果你发现它有用，你可以去看一看、试一试。

因此，那是一个有趣的选择！我在这里确实没有答案，但是，有一些想法：

负载均衡器是很复杂的
DNS 也很复杂
如果你有运维某种类型的负载均衡器（比如 HAProxy）的经验，与其使用一个全新的负载均衡器（比如 kube-proxy），还不如做一些额外的工作去使用你熟悉的那个来替换，或许更有意义。
我一直在考虑，我们希望在什么地方能够完全使用 kube-proxy 或者 kube-dns —— 我认为，最好是只在 Envoy 上投入，并且在负载均衡&服务发现上完全依赖 Envoy 来做。因此，你只需要将 Envoy 运维好就可以了。

正如你所看到的，我在关于如何运维 Kubernetes 中的内部代理方面的思路还是很混乱的，并且我也没有使用它们的太多经验。总体上来说，kube-proxy 和 kube-dns 还是很好的，也能够很好地工作，但是我仍然认为应该去考虑使用它们可能产生的一些问题（例如，”你不能有超出 5000 的 Kubernetes 服务“）。

入口

如果你正在运行着一个 Kubernetes 集群，那么到目前为止，很有可能的是，你事实上需要 HTTP 请求去进入到你的集群中。这篇博客已经太长了，并且关于入口我知道的也不多，因此，我们将不讨论关于入口的内容。

有用的链接

几个有用的链接，总结如下：

Kubernetes 网络模型
GKE 网络是如何工作的：https://www.youtube.com/watch?v=y2bhV81MfKQ
上述的有关 kube-proxy 上性能的讨论：https://www.youtube.com/watch?v=4-pawkiazEg

我认为网络运维很重要

我对 Kubernetes 的所有这些联网软件的感觉是，它们都仍然是非常新的，并且我并不能确定我们（作为一个社区）真的知道如何去把它们运维好。这让我作为一个操作者感到很焦虑，因为我真的想让我的网络运行的很好！:) 而且我觉得作为一个组织，运行你自己的 Kubernetes 集群需要相当大的投入，以确保你理解所有的代码片段，这样当它们出现问题时你可以去修复它们。这不是一件坏事，它只是一个事而已。

我现在的计划是，继续不断地学习关于它们都是如何工作的，以尽可能多地减少对我动过的那些部分的担忧。

一如继往，我希望这篇文章对你有帮助，并且如果我在这篇文章中有任何的错误，我非常喜欢你告诉我。

via: https://jvns.ca/blog/2017/10/10/operating-a-kubernetes-network/

作者：Julia Evans 译者：qhwdw 校对：wxy

本文由 LCTT 原创编译，Linux中国荣誉推出

Buildah 入门

Chris Collins 发布于 2018-07-14
另请参阅: 容器与云,容器, Docker, Buildah
评论

Buildah 提供一种灵活、可脚本编程的方式，来使用你熟悉的工具创建精简、高效的容器镜像。

Buildah 是一个命令行工具，可以方便、快捷的构建与开放容器标准 Open Container Initiative （OCI）兼容的容器镜像，这意味着其构建的镜像与 Docker 和 Kubernetes 兼容。该工具可作为 Docker 守护进程 docker build 命令（即使用传统的 Dockerfile 构建镜像）的一种简单 drop-in 替换，而且更加灵活，允许构建镜像时使用你擅长的工具。Buildah 可以轻松与脚本集成并生成流水线 pipeline ，最好之处在于构建镜像不再需要运行容器守护进程（LCTT 译注：这里主要是指 Docker 守护进程）。

docker build 的简单替换

目前你可能使用 Dockerfile 和 docker build 命令构建镜像，那么你可以马上使用 Buildah 进行替代。Buildah 的 build-using-dockerfile （或 bud）子命令与 docker build 基本等价，因此可以轻松的与已有脚本结合或构建流水线。

类似我的上一篇关于 Buildah 的文章，我也将以使用源码安装 “GNU Hello” 为例进行说明，对应的 Dockerfile 文件如下：

FROM fedora:28
LABEL maintainer Chris Collins <[email protected]>

RUN dnf install -y tar gzip gcc make \
        && dnf clean all

ADD http://ftpmirror.gnu.org/hello/hello-2.10.tar.gz /tmp/hello-2.10.tar.gz

RUN tar xvzf /tmp/hello-2.10.tar.gz -C /opt

WORKDIR /opt/hello-2.10

RUN ./configure
RUN make
RUN make install
RUN hello -v
ENTRYPOINT "/usr/local/bin/hello"

使用 Buildah 从 Dockerfile 构建镜像也很简单，使用 buildah bud -t hello . 替换 docker build -t hello . 即可：

[chris@krang] $ sudo buildah bud -t hello .
STEP 1: FROM fedora:28
Getting image source signatures
Copying blob sha256:e06fd16225608e5b92ebe226185edb7422c3f581755deadf1312c6b14041fe73
 81.48 MiB / 81.48 MiB [====================================================] 8s
Copying config sha256:30190780b56e33521971b0213810005a69051d720b73154c6e473c1a07ebd609
 2.29 KiB / 2.29 KiB [======================================================] 0s
Writing manifest to image destination
Storing signatures
STEP 2: LABEL maintainer Chris Collins <[email protected]>
STEP 3: RUN dnf install -y tar gzip gcc make    && dnf clean all

<考虑篇幅，略去后续输出>

镜像构建完毕后，可以使用 buildah images 命令查看这个新镜像：

[chris@krang] $ sudo buildah images
IMAGE ID        IMAGE NAME                              CREATED AT              SIZE
30190780b56e    docker.io/library/fedora:28             Mar 7, 2018 16:53       247 MB
6d54bef73e63    docker.io/library/hello:latest    May 3, 2018 15:24     391.8 MB

新镜像的标签为 hello:latest，我们可以将其推送至远程镜像仓库，可以使用 CRI-O 或其它 Kubernetes CRI 兼容的运行时来运行该镜像，也可以推送到远程仓库。如果你要测试对 Docker build 命令的替代性，你可以将镜像拷贝至 docker 守护进程的本地镜像存储中，这样 Docker 也可以使用该镜像。使用 buildah push 可以很容易的完成推送操作：

[chris@krang] $ sudo buildah push hello:latest docker-daemon:hello:latest
Getting image source signatures
Copying blob sha256:72fcdba8cff9f105a61370d930d7f184702eeea634ac986da0105d8422a17028
 247.02 MiB / 247.02 MiB [==================================================] 2s
Copying blob sha256:e567905cf805891b514af250400cc75db3cb47d61219750e0db047c5308bd916
 144.75 MiB / 144.75 MiB [==================================================] 1s
Copying config sha256:6d54bef73e638f2e2dd8b7bf1c4dfa26e7ed1188f1113ee787893e23151ff3ff
 1.59 KiB / 1.59 KiB [======================================================] 0s
Writing manifest to image destination
Storing signatures

[chris@krang] $ sudo docker images | head -n2
REPOSITORY              TAG             IMAGE ID        CREATED                 SIZE
docker.io/hello      latest       6d54bef73e63  2 minutes ago   398 MB

[chris@krang] $ sudo docker run -t hello:latest
Hello, world!

若干差异

与 Docker build 不同，Buildah 不会自动的将 Dockerfile 中的每条指令产生的变更提到新的分层 layer 中，只是简单的每次从头到尾执行构建。类似于自动化 automation 和流水线构建 build pipeline ，这种无缓存构建 non-cached 方式的好处是可以提高构建速度，在指令较多时尤为明显。从自动部署 automated deployment 或持续交付 continuous delivery 的视角来看，使用这种方式可以快速的将新变更落实到生产环境中。

但从实际角度出发，缓存机制的缺乏对镜像开发不利，毕竟缓存层可以避免一遍遍的执行构建，从而显著的节省时间。自动分层只在 build-using-dockerfile 命令中生效。但我们在下面会看到，Buildah 原生命令允许我们选择将变更提交到硬盘的时间，提高了开发的灵活性。

Buildah 原生命令

Buildah 真正有趣之处在于它的原生命令，你可以在容器构建过程中使用这些命令进行交互。相比与使用 build-using-dockerfile/bud 命令执行每次构建，Buildah 提供命令让你可以与构建过程中的临时容器进行交互。（Docker 也使用临时或中间 intermediate 容器，但你无法在镜像构建过程中与其交互。）

还是使用 “GNU Hello” 为例，考虑使用如下 Buildah 命令构建的镜像：

#!/usr/bin/env bash

set -o errexit

# Create a container
container=$(buildah from fedora:28)

# Labels are part of the "buildah config" command
buildah config --label maintainer="Chris Collins <[email protected]>" $container

# Grab the source code outside of the container
curl -sSL http://ftpmirror.gnu.org/hello/hello-2.10.tar.gz -o hello-2.10.tar.gz

buildah copy $container hello-2.10.tar.gz /tmp/hello-2.10.tar.gz

buildah run $container dnf install -y tar gzip gcc make
buildah run $container dnf clean all
buildah run $container tar xvzf /tmp/hello-2.10.tar.gz -C /opt

# Workingdir is also a "buildah config" command
buildah config --workingdir /opt/hello-2.10 $container

buildah run $container ./configure
buildah run $container make
buildah run $container make install
buildah run $container hello -v

# Entrypoint, too, is a “buildah config” command
buildah config --entrypoint /usr/local/bin/hello $container

# Finally saves the running container to an image
buildah commit --format docker $container hello:latest

我们可以一眼看出这是一个 Bash 脚本而不是 Dockerfile。基于 Buildah 的原生命令，可以轻易的使用任何脚本语言或你擅长的自动化工具编写脚本。形式可以是 makefile、Python 脚本或其它你擅长的类型。

这个脚本做了哪些工作呢？首先，Buildah 命令 container=$(buildah from fedora:28) 基于 fedora:28 镜像创建了一个正在运行的容器，将容器名（buildah from 命令的返回值）保存到变量中，便于后续使用。后续所有命令都是有 $container 变量指明需要操作的容器。这些命令的功能大多可以从名称看出：buildah copy 将文件拷贝至容器，buildah run 会在容器中执行命令。可以很容易的将上述命令与 Dockerfile 中的指令对应起来。

最后一条命令 buildah commit 将容器提交到硬盘上的镜像中。当不使用 Dockerfile 而是使用 Buildah 命令构建镜像时，你可以使用 commit 命令决定何时保存变更。在上例中，所有的变更是一起提交的；但也可以增加中间提交，让你可以选择作为起点的缓存点 cache point 。（例如，执行完 dnf install 命令后将变更缓存到硬盘是特别有意义的，一方面因为该操作耗时较长，另一方面每次执行的结果也确实相同。）

挂载点，安装目录以及 chroot

另一个可以大大增加构建镜像灵活性的 Buildah 命令是 buildah mount，可以将容器的根目录挂载到你主机的一个挂载点上。例如：

[chris@krang] $ container=$(sudo buildah from fedora:28)
[chris@krang] $ mountpoint=$(sudo buildah mount ${container})
[chris@krang] $ echo $mountpoint
/var/lib/containers/storage/overlay2/463eda71ec74713d8cebbe41ee07da5f6df41c636f65139a7bd17b24a0e845e3/merged
[chris@krang] $ cat ${mountpoint}/etc/redhat-release
Fedora release 28 (Twenty Eight)
[chris@krang] $ ls ${mountpoint}
bin   dev  home  lib64          media  opt   root  sbin  sys  usr
boot  etc  lib   lost+found  mnt        proc  run   srv   tmp  var

这太棒了，你可以通过与挂载点交互对容器镜像进行修改。这允许你使用主机上的工具进行构建和安装软件，不用将这些构建工具打包到容器镜像本身中。例如，在我们上面的 Bash 脚本中，我们需要安装 tar、Gzip、GCC 和 make，在容器内编译 “GNU Hello”。如果使用挂载点，我仍使用同样的工具进行构建，但下载的压缩包和 tar、Gzip 等 RPM 包都在主机而不是容器和生成的镜像内：

#!/usr/bin/env bash

set -o errexit

# Create a container
container=$(buildah from fedora:28)
mountpoint=$(buildah mount $container)

buildah config --label maintainer="Chris Collins <[email protected]>" $container

curl -sSL http://ftpmirror.gnu.org/hello/hello-2.10.tar.gz \
     -o /tmp/hello-2.10.tar.gz
tar xvzf src/hello-2.10.tar.gz -C ${mountpoint}/opt

pushd ${mountpoint}/opt/hello-2.10
./configure
make
make install DESTDIR=${mountpoint}
popd

chroot $mountpoint bash -c "/usr/local/bin/hello -v"

buildah config --entrypoint "/usr/local/bin/hello" $container
buildah commit --format docker $container hello
buildah unmount $container

在上述脚本中，需要提到如下几点：

curl 命令将压缩包下载到主机中，而不是镜像中；
（主机中的） tar 命令将压缩包中的源代码解压到容器的 /opt 目录；
configure，make 和 make install 命令都在主机的挂载点目录中执行，而不是在容器内；
这里的 chroot 命令用于将挂载点本身当作根路径并测试 "hello" 是否正常工作；类似于前面例子中用到的 buildah run 命令。

这个脚本更加短小，使用大多数 Linux 爱好者都很熟悉的工具，最后生成的镜像也更小（没有 tar 包，没有额外的软件包等）。你甚至可以使用主机系统上的包管理器为容器安装软件。例如，（出于某种原因）你希望安装 GNU Hello 的同时在容器中安装 NGINX：

[chris@krang] $ mountpoint=$(sudo buildah mount ${container})
[chris@krang] $ sudo dnf install nginx --installroot $mountpoint
[chris@krang] $ sudo chroot $mountpoint nginx -v
nginx version: nginx/1.12.1

在上面的例子中，DNF 使用 --installroot 参数将 NGINX 安装到容器中，可以通过 chroot 进行校验。

快来试试吧！

Buildah 是一种轻量级、灵活的容器镜像构建方法，不需要在主机上运行完整的 Docker 守护进程。除了提供基于 Dockerfile 构建容器的开箱即用支持，Buildah 还可以很容易的与脚本或你喜欢的构建工具相结合，特别是可以使用主机上已有的工具构建容器镜像。Buildah 生成的容器体积更小，更便于网络传输，占用更小的存储空间，而且潜在的受攻击面更小。快来试试吧！

阅读相关的故事，[使用 Buildah 创建小体积的容器]

via: https://opensource.com/article/18/6/getting-started-buildah

作者：Chris Collins 选题：lujun9972 译者：pinewall 校对：wxy

本文由 LCTT 原创编译，Linux中国荣誉推出

Mesos 和 Kubernetes：不是竞争者

Swapnil Bhartiya 发布于 2018-07-13
另请参阅: 观点,容器, Mesos, Kubernetes
评论

人们经常用 x 相对于 y 这样的术语来考虑问题，但是它并不是一个技术对另一个技术的问题。Ben Hindman 在这里解释了 Mesos 是如何对另外一种技术进行补充的。

Mesos 的起源可以追溯到 2009 年，当时，Ben Hindman 还是加州大学伯克利分校研究并行编程的博士生。他们在 128 核的芯片上做大规模的并行计算，以尝试去解决多个问题，比如怎么让软件和库在这些芯片上运行更高效。他与同学们讨论能否借鉴并行处理和多线程的思想，并将它们应用到集群管理上。

Hindman 说 “最初，我们专注于大数据” 。那时，大数据非常热门，而 Hadoop 就是其中的一个热门技术。“我们发现，人们在集群上运行像 Hadoop 这样的程序与运行多线程应用及并行应用很相似。”Hindman 说。

但是，它们的效率并不高，因此，他们开始去思考，如何通过集群管理和资源管理让它们运行的更好。“我们查看了那个时期很多的各种技术” Hindman 回忆道。

然后，Hindman 和他的同事们决定去采用一种全新的方法。“我们决定对资源管理创建一个低级的抽象，然后在此之上运行调度服务和做其它的事情。” Hindman 说，“基本上，这就是 Mesos 的本质 —— 将资源管理部分从调度部分中分离出来。”

他成功了，并且 Mesos 从那时开始强大了起来。

将项目呈献给 Apache

这个项目发起于 2009 年。在 2010 年时，团队决定将这个项目捐献给 Apache 软件基金会（ASF）。它在 Apache 孵化，并于 2013 年成为顶级项目（TLP）。

为什么 Mesos 社区选择 Apache 软件基金会有很多的原因，比如，Apache 许可证，以及基金会已经拥有了一个充满活力的其它此类项目的社区。

与影响力也有关系。许多在 Mesos 上工作的人也参与了 Apache，并且许多人也致力于像 Hadoop 这样的项目。同时，来自 Mesos 社区的许多人也致力于其它大数据项目，比如 Spark。这种交叉工作使得这三个项目 —— Hadoop、Mesos，以及 Spark —— 成为 ASF 的项目。

与商业也有关系。许多公司对 Mesos 很感兴趣，并且开发者希望它能由一个中立的机构来维护它，而不是让它成为一个私有项目。

谁在用 Mesos？

更好的问题应该是，谁不在用 Mesos？从 Apple 到 Netflix 每个都在用 Mesos。但是，Mesos 也面临任何技术在早期所面对的挑战。“最初，我要说服人们，这是一个很有趣的新技术。它叫做‘容器’，因为它不需要使用虚拟机” Hindman 说。

从那以后，这个行业发生了许多变化，现在，只要与别人聊到基础设施，必然是从”容器“开始的 —— 感谢 Docker 所做出的工作。今天再也不需要做说服工作了，而在 Mesos 出现的早期，前面提到的像 Apple、Netflix，以及 PayPal 这样的公司。他们已经知道了容器替代虚拟机给他们带来的技术优势。“这些公司在容器成为一种现象之前，已经明白了容器的价值所在”， Hindman 说。

可以在这些公司中看到，他们有大量的容器而不是虚拟机。他们所做的全部工作只是去管理和运行这些容器，并且他们欣然接受了 Mesos。在 Mesos 早期就使用它的公司有 Apple、Netflix、PayPal、Yelp、OpenTable 和 Groupon。

“大多数组织使用 Mesos 来运行各种服务” Hindman 说，“但也有些公司用它做一些非常有趣的事情，比如，数据处理、数据流、分析任务和应用程序。“

这些公司采用 Mesos 的其中一个原因是，资源管理层之间有一个明晰的界线。当公司运营容器的时候，Mesos 为他们提供了很好的灵活性。

“我们尝试使用 Mesos 去做的一件事情是去创建一个层，以让使用者享受到我们的层带来的好处，当然也可以在它之上创建任何他们想要的东西，” Hindman 说。 “我认为这对一些像 Netflix 和 Apple 这样的大公司非常有用。”

但是，并不是每个公司都是技术型的公司；不是每个公司都有或者应该有这种专长。为帮助这样的组织，Hindman 联合创建了 Mesosphere 去围绕 Mesos 提供服务和解决方案。“我们最终决定，为这样的组织去构建 DC/OS，它不需要技术专长或者不想把时间花费在像构建这样的事情上。”

Mesos vs. Kubernetes?

人们经常用 x 相对于 y 这样的术语来考虑问题，但是它并不是一个技术对另一个技术的问题。大多数的技术在一些领域总是重叠的，并且它们可以是互补的。“我不喜欢将所有的这些东西都看做是竞争者。我认为它们中的一些与另一个在工作中是互补的，” Hindman 说。

“事实上，名字 Mesos 表示它处于 ‘中间’；它是一种中间的操作系统”， Hindman 说，“我们有一个容器调度器的概念，它能够运行在像 Mesos 这样的东西之上。当 Kubernetes 刚出现的时候，我们实际上在 Mesos 的生态系统中接受了它，并将它看做是在 Mesos 上的 DC/OS 中运行容器的另一种方式。”

Mesos 也复活了一个名为 Marathon（一个用于 Mesos 和 DC/OS 的容器编排器）的项目，它成为了 Mesos 生态系统中最重要的成员。但是，Marathon 确实无法与 Kubernetes 相比较。“Kubernetes 比 Marathon 做的更多，因此，你不能将它们简单地相互交换，” Hindman 说，“与此同时，我们在 Mesos 中做了许多 Kubernetes 中没有的东西。因此，这些技术之间是互补的。”

不要将这些技术视为相互之间是敌对的关系，它们应该被看做是对行业有益的技术。它们不是技术上的重复；它们是多样化的。据 Hindman 说，“对于开源领域的终端用户来说，这可能会让他们很困惑，因为他们很难去知道哪个技术适用于哪种任务，但这是这个被称之为开源的本质所在。“

这只是意味着有更多的选择，并且每个都是赢家。

via: https://www.linux.com/blog/2018/6/mesos-and-kubernetes-its-not-competition

作者：Swapnil Bhartiya 选题：lujun9972 译者：qhwdw 校对：wxy

本文由 LCTT 原创编译，Linux中国荣誉推出

容器基础知识：你需要知道的术语

Swapnil Bhartiya 发布于 2018-07-02
另请参阅: 容器与云,容器, Docker
评论

在前一篇文章中，我们谈到了容器 container 是什么以及它是如何培育创新并助力企业快速发展的。在以后的文章中，我们将讨论如何使用容器。然而，在深入探讨这个话题之前，我们需要了解关于容器的一些术语和命令。掌握了这些术语，才不至于产生混淆。

让我们来探讨 Docker 容器世界中使用的一些基本术语吧。

容器 Container ：到底什么是容器呢？它是一个 Docker 镜像 image 的运行实例。它包含一个 Docker 镜像、执行环境和说明。它与系统完全隔离，所以可以在系统上运行多个容器，并且完全无视对方的存在。你可以从同一镜像中复制出多个容器，并在需求较高时扩展服务，在需求低时对这些容器进行缩减。

Docker 镜像 Image ：这与你下载的 Linux 发行版的镜像别无二致。它是一个安装包，包含了用于创建、部署和执行容器的一系列依赖关系和信息。你可以在几秒钟内创建任意数量的完全相同的容器。镜像是分层叠加的。一旦镜像被创建出来，是不能更改的。如果你想对容器进行更改，则只需创建一个新的镜像并从该镜像部署新的容器即可。

仓库 Repository （repo）：Linux 的用户对于仓库这个术语一定不陌生吧。它是一个软件库，存储了可下载并安装在系统中的软件包。在 Docker 容器中，唯一的区别是它管理的是通过标签分类的 Docker 镜像。你可以找到同一个应用程序的不同版本或不同变体，他们都有适当的标记。

镜像管理服务 Registry ：可以将其想象成 GitHub。这是一个在线服务，管理并提供了对 Docker 镜像仓库的访问，例如默认的公共镜像仓库——DockerHub。供应商可以将他们的镜像库上传到 DockerHub 上，以便他们的客户下载和使用官方镜像。一些公司为他们的镜像提供自己的服务。镜像管理服务不必由第三方机构来运行和管理。组织机构可以使用预置的服务来管理内部范围的镜像库访问。

标签 Tag ：当你创建 Docker 镜像时，可以给它添加一个合适的标签，以便轻松识别不同的变体或版本。这与你在任何软件包中看到的并无区别。Docker 镜像在添加到镜像仓库时被标记。

现在你已经掌握了基本知识，下一个阶段是理解实际使用 Docker 容器时用到的术语。

Dockerfile ：这是一个文本文件，包含为了为构建 Docker 镜像需手动执行的命令。Docker 使用这些指令自动构建镜像。

构建 Build ：这是从 Dockerfile 创建成镜像的过程。

推送 Push ：一旦镜像创建完成，“push” 是将镜像发布到仓库的过程。该术语也是我们下一篇文章要学习的命令之一。

拉取 Pull ：用户可以通过 “pull” 过程从仓库检索该镜像。

编组 Compose ：复杂的应用程序会包含多个容器。docker-compose 是一个用于运行多容器应用程序的命令行工具。它允许你用单条命令运行一个多容器的应用程序，简化了多容器带来的问题。

总结

容器术语的范围很广泛，这里是经常遇到的一些基本术语。下一次当你看到这些术语时，你会确切地知道它们的含义。在下一篇文章中，我们将开始使用 Docker 容器。

via: https://www.linux.com/blog/intro-to-linux/2017/12/container-basics-terms-you-need-know

作者：Swapnil Bhartiya 译者：jessie-pang 校对：wxy

本文由 LCTT 原创编译，Linux中国荣誉推出

8 个基本的 Docker 容器管理命令

Shrikant Lavhate 发布于 2018-06-22
另请参阅: 容器与云,容器, Docker
评论

利用这 8 个命令可以学习 Docker 容器的基本管理方式。这是一个为 Docker 初学者准备的，带有示范命令输出的指南。

Docker 容器管理命令

在这篇文章中，我们将带你学习 8 个基本的 Docker 容器命令，它们操控着 Docker 容器的基本活动，例如运行 run 、列举 list 、停止 stop 、查看历史纪录 logs 、删除 delete 等等。如果你对 Docker 的概念很陌生，推荐你看看我们的介绍指南，来了解 Docker 的基本内容以及如何在 Linux 上安装 Docker。现在让我们赶快进入要了解的命令：

如何运行 Docker 容器？

众所周知，Docker 容器只是一个运行于宿主操作系统 host OS 上的应用进程，所以你需要一个镜像来运行它。Docker 镜像以进程的方式运行时就叫做 Docker 容器。你可以加载本地 Docker 镜像，也可以从 Docker Hub 上下载。Docker Hub 是一个提供公有和私有镜像来进行拉取 pull 操作的集中仓库。官方的 Docker Hub 位于 hub.docker.com。当你指示 Docker 引擎运行容器时，它会首先搜索本地镜像，如果没有找到，它会从 Docker Hub 上拉取相应的镜像。

让我们运行一个 Apache web 服务器的 Docker 镜像，比如 httpd 进程。你需要运行 docker container run 命令。旧的命令为 docker run，但后来 Docker 添加了子命令部分，所以新版本支持下列命令：

root@kerneltalks # docker container run -d -p 80:80 httpd
Unable to find image 'httpd:latest' locally
latest: Pulling from library/httpd
3d77ce4481b1: Pull complete
73674f4d9403: Pull complete
d266646f40bd: Pull complete
ce7b0dda0c9f: Pull complete
01729050d692: Pull complete
014246127c67: Pull complete
7cd2e04cf570: Pull complete
Digest: sha256:f4610c3a1a7da35072870625733fd0384515f7e912c6223d4a48c6eb749a8617
Status: Downloaded newer image for httpd:latest
c46f2e9e4690f5c28ee7ad508559ceee0160ac3e2b1688a61561ce9f7d99d682

Docker 的 run 命令将镜像名作为强制参数，另外还有很多可选参数。常用的参数有：

-d：从当前 shell 脱离容器
-p X:Y：绑定容器的端口 Y 到宿主机的端口 X
--name：命名你的容器。如果未指定，它将被赋予随机生成的名字
-e：当启动容器时传递环境编辑及其值

通过以上输出你可以看到，我们将 httpd 作为镜像名来运行容器。接着，本地镜像没有找到，Docker 引擎从 Docker Hub 拉取了它。注意，它下载了镜像 httpd:latest，其中 : 后面跟着版本号。如果你需要运行特定版本的容器，你可以在镜像名后面注明版本名。如果不提供版本名，Docker 引擎会自动拉取最新的版本。

输出的最后一行显示了你新运行的 httpd 容器的唯一 ID。

如何列出所有运行中的 Docker 容器？

现在，你的容器已经运行起来了，你可能想要确认这一点，或者你想要列出你的机器上运行的所有容器。你可以使用 docker container ls 命令。在旧的 Docker 版本中，对应的命令为 docker ps。

root@kerneltalks # docker container ls
CONTAINER ID        IMAGE               COMMAND              CREATED             STATUS              PORTS                NAMES
c46f2e9e4690        httpd               "httpd-foreground"   11 minutes ago      Up 11 minutes       0.0.0.0:80->80/tcp   cranky_cori

列出的结果是按列显示的。每一列的值分别为：

Container ID ：一开始的几个字符对应你的容器的唯一 ID
Image ：你运行容器的镜像名
Command ：容器启动后运行的命令
Created ：创建时间
Status ：容器当前状态
Ports ：与宿主端口相连接的端口信息
Names ：容器名（如果你没有命名你的容器，那么会随机创建）

如何查看 Docker 容器的历史纪录？

在第一步我们使用了 -d 参数来将容器，在它一开始运行的时候，就从当前的 shell 中脱离出来。在这种情况下，我们不知道容器里面发生了什么。所以为了查看容器的历史纪录，Docker 提供了 logs 命令。它采用容器名称或 ID 作为参数。

root@kerneltalks # docker container logs cranky_cori
AH00558: httpd: Could not reliably determine the server's fully qualified domain name, using 172.17.0.2. Set the 'ServerName' directive globally to suppress this message
AH00558: httpd: Could not reliably determine the server's fully qualified domain name, using 172.17.0.2. Set the 'ServerName' directive globally to suppress this message
[Thu May 31 18:35:07.301158 2018] [mpm_event:notice] [pid 1:tid 139734285989760] AH00489: Apache/2.4.33 (Unix) configured -- resuming normal operations
[Thu May 31 18:35:07.305153 2018] [core:notice] [pid 1:tid 139734285989760] AH00094: Command line: 'httpd -D FOREGROUND'

这里我使用了容器名称作为参数。你可以看到在我们的 httpd 容器中与 Apache 相关的历史纪录。

如何确定 Docker 容器的进程？

容器是一个使用宿主资源来运行的进程。这样，你可以在宿主系统的进程表中定位容器的进程。让我们在宿主系统上确定容器进程。

Docker 使用著名的 top 命令作为子命令的名称，来查看容器产生的进程。它采用容器的名称或 ID 作为参数。在旧版本的 Docker 中，只可运行 docker top 命令。在新版本中，docker top 和 docker container top 命令都可以生效。

root@kerneltalks # docker container top  cranky_cori
UID                 PID                 PPID                C                   STIME               TTY                 TIME                CMD
root                15702               15690               0                   18:35               ?                   00:00:00            httpd -DFOREGROUND
bin                 15729               15702               0                   18:35               ?                   00:00:00            httpd -DFOREGROUND
bin                 15730               15702               0                   18:35               ?                   00:00:00            httpd -DFOREGROUND
bin                 15731               15702               0                   18:35               ?                   00:00:00            httpd -DFOREGROUND

root@kerneltalks # ps -ef |grep -i 15702
root     15702 15690  0 18:35 ?        00:00:00 httpd -DFOREGROUND
bin      15729 15702  0 18:35 ?        00:00:00 httpd -DFOREGROUND
bin      15730 15702  0 18:35 ?        00:00:00 httpd -DFOREGROUND
bin      15731 15702  0 18:35 ?        00:00:00 httpd -DFOREGROUND
root     15993 15957  0 18:59 pts/0    00:00:00 grep --color=auto -i 15702

在第一个输出中，列出了容器产生的进程的列表。它包含了所有细节，包括用户号 uid 、进程号 pid ，父进程号 ppid 、开始时间、命令，等等。这里所有的进程号你都可以在宿主的进程表里搜索到。这就是我们在第二个命令里做得。这证明了容器确实是宿主系统中的进程。

如何停止 Docker 容器？

只需要 stop 命令！同样，它采用容器名称或 ID 作为参数。

root@kerneltalks # docker container stop cranky_cori
cranky_cori

如何列出停止的或不活动的 Docker 容器？

现在我们停止了我们的容器，这时如果我们使用 ls 命令，它将不会出现在列表中。

root@kerneltalks # docker container ls
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES

所以，在这种情况下，如果想要查看停止的或不活动的容器，你需要在 ls 命令里同时使用 -a 参数。

root@kerneltalks # docker container ls -a
CONTAINER ID        IMAGE               COMMAND              CREATED             STATUS                     PORTS               NAMES
c46f2e9e4690        httpd               "httpd-foreground"   33 minutes ago      Exited (0) 2 minutes ago                       cranky_cori

有了 -a 参数，现在我们可以查看已停止的容器。注意这些容器的状态被标注为已退出 exited 。既然容器只是一个进程，那么用“退出”比“停止”更合适！

如何（重新）启动 Docker 容器？

现在，我们来启动这个已停止的容器。这和运行一个容器有所区别。当你运行一个容器时，你将启动一个全新的容器。当你启动一个容器时，你将开始一个已经停止并保存了当时运行状态的容器。它将以停止时的状态重新开始运行。

root@kerneltalks #  docker container start c46f2e9e4690
c46f2e9e4690

root@kerneltalks # docker container ls -a
CONTAINER ID        IMAGE               COMMAND              CREATED             STATUS              PORTS                NAMES
c46f2e9e4690        httpd               "httpd-foreground"   35 minutes ago      Up 8 seconds        0.0.0.0:80->80/tcp   cranky_cori

如何移除 Docker 容器？

我们使用 rm 命令来移除容器。你不可以移除运行中的容器。移除之前需要先停止容器。你可以使用 -f 参数搭配 rm 命令来强制移除容器，但并不推荐这么做。

root@kerneltalks # docker container rm cranky_cori
cranky_cori
root@kerneltalks # docker container ls -a
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES

你看，一旦移除了容器，即使再使用 ls -a 命令也查看不到容器了。

via: https://kerneltalks.com/virtualization/8-basic-docker-container-management-commands/

作者：Shrikant Lavhate 选题：lujun9972 译者：lonaparte 校对：wxy

本文由 LCTT 原创编译，Linux中国荣誉推出

底层 Linux 容器运行时之发展史

Daniel Walsh 发布于 2018-06-15
另请参阅: 容器与云,容器, Docker
评论

“容器运行时”是一个被过度使用的名词。

在 Red Hat，我们乐意这么说，“容器即 Linux，Linux 即容器”。下面解释一下这种说法。传统的容器是操作系统中的进程，通常具有如下 3 个特性：

资源限制

当你在系统中运行多个容器时，你肯定不希望某个容器独占系统资源，所以我们需要使用资源约束来控制 CPU、内存和网络带宽等资源。Linux 内核提供了 cgroup 特性，可以通过配置控制容器进程的资源使用。

安全性配置

一般而言，你不希望你的容器可以攻击其它容器或甚至攻击宿主机系统。我们使用了 Linux 内核的若干特性建立安全隔离，相关特性包括 SELinux、seccomp 和 capabilities。

（LCTT 译注：从 2.2 版本内核开始，Linux 将特权从超级用户中分离，产生了一系列可以单独启用或关闭的 capabilities）

虚拟隔离

容器外的任何进程对于容器而言都应该不可见。容器应该使用独立的网络。不同的容器对应的进程应该都可以绑定 80 端口。每个容器的内核映像 image 、根文件系统 rootfs （rootfs）都应该相互独立。在 Linux 中，我们使用内核的名字空间 namespace 特性提供虚拟隔离 virtual separation 。

那么，具有安全性配置并且在 cgroup 和名字空间下运行的进程都可以称为容器。查看一下 Red Hat Enterprise Linux 7 操作系统中的 PID 1 的进程 systemd，你会发现 systemd 运行在一个 cgroup 下。

# tail -1 /proc/1/cgroup
1:name=systemd:/

ps 命令让我们看到 systemd 进程具有 SELinux 标签：

# ps -eZ | grep systemd
system_u:system_r:init_t:s0             1 ?     00:00:48 systemd

以及 capabilities：

# grep Cap /proc/1/status
...
CapEff: 0000001fffffffff
CapBnd: 0000001fffffffff
CapBnd:    0000003fffffffff

最后，查看 /proc/1/ns 子目录，你会发现 systemd 运行所在的名字空间。

ls -l /proc/1/ns
lrwxrwxrwx. 1 root root 0 Jan 11 11:46 mnt -> mnt:[4026531840]
lrwxrwxrwx. 1 root root 0 Jan 11 11:46 net -> net:[4026532009]
lrwxrwxrwx. 1 root root 0 Jan 11 11:46 pid -> pid:[4026531836]
...

如果 PID 1 进程（实际上每个系统进程）具有资源约束、安全性配置和名字空间，那么我可以说系统上的每一个进程都运行在容器中。

容器运行时工具也不过是修改了资源约束、安全性配置和名字空间，然后 Linux 内核运行起进程。容器启动后，容器运行时可以在容器内监控 PID 1 进程，也可以监控容器的标准输入/输出，从而进行容器进程的生命周期管理。

容器运行时

你可能自言自语道，“哦，systemd 看起来很像一个容器运行时”。经过若干次关于“为何容器运行时不使用 systemd-nspawn 工具来启动容器”的邮件讨论后，我认为值得讨论一下容器运行时及其发展史。

Docker 通常被称为容器运行时，但“ 容器运行时 container runtime ”是一个被过度使用的词语。当用户提到“容器运行时”，他们其实提到的是为开发人员提供便利的上层 high-level 工具，包括 Docker，CRI-O 和 RKT。这些工具都是基于 API 的，涉及操作包括从容器仓库拉取容器镜像、配置存储和启动容器等。启动容器通常涉及一个特殊工具，用于配置内核如何运行容器，这类工具也被称为“容器运行时”，下文中我将称其为“底层容器运行时”以作区分。像 Docker、CRI-O 这样的守护进程及形如 Podman、Buildah 的命令行工具，似乎更应该被称为“容器管理器”。

早期版本的 Docker 使用 lxc 工具集启动容器，该工具出现在 systemd-nspawn 之前。Red Hat 最初试图将 libvirt （libvirt-lxc）集成到 Docker 中替代 lxc 工具，因为 RHEL 并不支持 lxc。libvirt-lxc 也没有使用 systemd-nspawn，在那时 systemd 团队仅将 systemd-nspawn 视为测试工具，不适用于生产环境。

与此同时，包括我的 Red Hat 团队部分成员在内的上游 upstream Docker 开发者，认为应该采用 golang 原生的方式启动容器，而不是调用外部应用。他们的工作促成了 libcontainer 这个 golang 原生库，用于启动容器。Red Hat 工程师更看好该库的发展前景，放弃了 libvirt-lxc。

后来成立开放容器组织 Open Container Initiative （OCI）的部分原因就是人们希望用其它方式启动容器。传统的基于名字空间隔离的容器已经家喻户晓，但人们也有虚拟机级别隔离 virtual machine-level isolation 的需求。Intel 和 Hyper.sh 正致力于开发基于 KVM 隔离的容器，Microsoft 致力于开发基于 Windows 的容器。OCI 希望有一份定义容器的标准规范，因而产生了 OCI 运行时规范 Runtime Specification 。

OCI 运行时规范定义了一个 JSON 文件格式，用于描述要运行的二进制，如何容器化以及容器根文件系统的位置。一些工具用于生成符合标准规范的 JSON 文件，另外的工具用于解析 JSON 文件并在该根文件系统（rootfs）上运行容器。Docker 的部分代码被抽取出来构成了 libcontainer 项目，该项目被贡献给 OCI。上游 Docker 工程师及我们自己的工程师创建了一个新的前端工具，用于解析符合 OCI 运行时规范的 JSON 文件，然后与 libcontainer 交互以便启动容器。这个前端工具就是 runc，也被贡献给 OCI。虽然 runc 可以解析 OCI JSON 文件，但用户需要自行生成这些文件。此后，runc 也成为了最流行的底层容器运行时，基本所有的容器管理工具都支持 runc，包括 CRI-O、Docker、Buildah、Podman 和 Cloud Foundry Garden 等。此后，其它工具的实现也参照 OCI 运行时规范，以便可以运行 OCI 兼容的容器。

Clear Containers 和 Hyper.sh 的 runV 工具都是参照 OCI 运行时规范运行基于 KVM 的容器，二者将其各自工作合并到一个名为 Kata 的新项目中。在去年，Oracle 创建了一个示例版本的 OCI 运行时工具，名为 RailCar，使用 Rust 语言编写。但该 GitHub 项目已经两个月没有更新了，故无法判断是否仍在开发。几年前，Vincent Batts 试图创建一个名为 nspawn-oci 的工具，用于解析 OCI 运行时规范文件并启动 systemd-nspawn；但似乎没有引起大家的注意，而且也不是原生的实现。

如果有开发者希望实现一个原生的 systemd-nspawn --oci OCI-SPEC.json 并让 systemd 团队认可和提供支持，那么CRI-O、Docker 和 Podman 等容器管理工具将可以像使用 runc 和 Clear Container/runV （Kata）那样使用这个新的底层运行时。（目前我的团队没有人参与这方面的工作。）

总结如下，在 3-4 年前，上游开发者打算编写一个底层的 golang 工具用于启动容器，最终这个工具就是 runc。那时开发者有一个使用 C 编写的 lxc 工具，在 runc 开发后，他们很快转向 runc。我很确信，当决定构建 libcontainer 时，他们对 systemd-nspawn 或其它非原生（即不使用 golang）的运行 namespaces 隔离的容器的方式都不感兴趣。

via: https://opensource.com/article/18/1/history-low-level-container-runtimes

作者：Daniel Walsh 译者：pinewall 校对：wxy

本文由 LCTT 原创编译，Linux中国荣誉推出