Kubernetes之“暂停”容器

最新推荐文章于 2024-08-25 21:33:35 发布

dssky_2008

最新推荐文章于 2024-08-25 21:33:35 发布

阅读量1.8k

点赞数

分类专栏： kubernetes docker 文章标签： kubernetes docker pods

docker 同时被 2 个专栏收录

24 篇文章 0 订阅

订阅专栏

kubernetes

16 篇文章 0 订阅

订阅专栏

【编者的话】希望这篇文章可以帮助大家更好的了解Kubernetes的核心内容-“暂停”容器。感受“暂停”容器如神一般的存在。

当你检查Kubernetes集群的节点时（即在节点上执行命令docker ps 命令），你可能会注意到一些被称为“暂停（/pause）”的容器。

$ docker ps
CONTAINER ID IMAGE COMMAND ...
...
3b45e983c859 gcr.io/google_containers/pause-amd64:3.0 “/pause” ...
...
dbfc35b00062 gcr.io/google_containers/pause-amd64:3.0 “/pause” ...
...
c4e998ec4d5d gcr.io/google_containers/pause-amd64:3.0 “/pause” ...
...
508102acf1e7 gcr.io/google_containers/pause-amd64:3.0 “/pause” ...

这些“暂停”容器是什么，为什么这么多暂停的？这到底是啥情况？

说明一下，它不是一个pod(暂停的)，而是一个容器(暂停的)。

为了回答这些问题，我们需要退一步看看Kubernetes中的pods是如何实现的，特别是在Docker/containerd运行时。如果你对pods还不了解，可以先阅读我以前发表的关于Kubernetes pods 的文章。

Docker支持容器的特性，非常适合部署单个软件单元。但是，当你想要一起运行多个软件时，这种模式会变得有点麻烦。比如：当开发人员创建使用supervisord作为入口点的Docker镜像来启动和管理多个进程时，你经常会看到这一点。对于生产系统，许多人发现，将这些应用程序部署在部分隔离并部分共享环境的容器组中更为有用。

Kubernetes为这种使用场景提供了一个称为pod的干净的抽象。它在隐藏Docker标志的复杂性的同时会保留容器，共享卷等。与此同时，它也隐藏了容器运行时的差异。例如，rkt原生支持pod，所以Kubernetes的工作要少一些，但是不管怎样，作为Kubernetes用户的你都不用担心(pod会帮你搞定这些)。

原则上，任何人都可以配置Docker来控制容器组之间的共享级别– 你只需创建一个父容器，在知道正确的标志配置的情况下来设置并创建共享相同环境的新容器，然后管理这些容器的生命周期。然而管理所有这些片段的生命周期可能会变得相当复杂。

在Kubernetes中，“暂停”容器将被用作你的pod中所有容器的“父容器”。“暂停”容器有两个核心职责。首先，在pod中它作为Linux命名空间共享的基础。其次，启用PID（进程ID）命名空间共享，它为每个pod提供PID 1，并收集僵尸进程。

共享命名空间

在Linux中，当你运行新进程时，该进程从父进程继承其命名空间。在新命名空间中运行进程的方法是通过“取消共享”命名空间（与父进程），从而创建一个新的命名空间。以下是使用该unshare 工具在新的PID，UTS，IPC和装载命名空间中运行shell 的示例。

sudo unshare --pid --uts --ipc --mount -f chroot rootfs / bin / sh

一旦进程运行，你可以将其他进程添加到进程的命名空间中以形成一个pod。可以使用setns 系统调用将新进程添加到现有命名空间。

pod中的容器在其中共享命名空间。Docker可让你自动执行此过程，因此，让我们来看一下如何使用“暂停”容器和共享命名空间从头开始创建pod的示例。首先，我们将需要使用Docker启动“暂停”容器，以便我们可以将容器添加到pod中。

docker run -d --name pause gcr.io/google_containers/pause-amd64:3.0

然后我们可以运行我们的pod的容器。首先我们将运行nginx。这将在端口2368上设置nginx到其localhost的代理请求。

$ cat <<EOF >> nginx.conf
> error_log stderr;
> events { worker_connections  1024; }
> http {
>     access_log /dev/stdout combined;
>     server {
>         listen 80 default_server;
>         server_name example.com www.example.com;
>         location / {
>             proxy_pass http://127.0.0.1:2368;
>         }
>     }
> }
> EOF
$ docker run -d --name nginx -v `pwd`/nginx.conf:/etc/nginx/nginx.conf -p 8080:80 --net=container:pause --ipc=container:pause --pid=container:pause nginx

然后，我们将为作为我们的应用服务器的ghost博客应用程序创建另一个容器。

$ docker run -d --name ghost --net = container：pause --ipc = container：pause --pid = container：pause ghost

在这两种情况下，我们将“暂停”容器指定为我们要加入其命名空间的容器。这将有效地创建我们的pod。如果你访问，http://localhost:8080/你应该能够看到ghost通过nginx代理运行，因为网络命名空间在pause，nginx和ghost容器之间共享。

如果你认为这一切都很复杂，你是对的; 它确实很复杂（感觉像句废话）。而且我们甚至还没有了解如何监控和管理这些容器的生命周期。不过，值得庆幸的事，通过pod，Kubernetes会为你很好地管理所有这些。

收割僵尸

在Linux中，PID命名空间中的所有进程会形成一个树结构，每个进程都会有一个父进程。只有在树的根部的进程没有父进程。这个进程就是“init”进程，即PID 1。

进程可以使用fork 和exec syscalls 启动其他进程。当启动了其他进程，新进程的父进程就是调用fork syscall 的进程。fork 用于启动正在运行的进程的另一个副本，而exec 则用于启动不同的进程。每个进程在OS进程表中都有一个条目。这将记录有关进程的状态和退出代码。当子进程运行完成，它的进程表条目仍然将保留直到父进程使用wait syscall 检索其退出代码将其退出。这被称为“收割”僵尸进程。

当心僵尸

僵尸进程是已停止运行但进程表条目仍然存在的进程，因为父进程尚未通过wait syscall进行检索。从技术层面来说，终止的每个进程都算是一个僵尸进程，尽管只是在很短的时间内发生的，但只要不终止他们就可以存活更久。

当父进程wait 在子进程完成后不调用syscall 时，会发生较长的生存僵尸进程。这样的情况有很多，比如：当父进程写得不好并且简单地省略wait call时，或者当父进程在子进程之前死机，并且新的父进程没有调用wait 去检索子进程时。当进程的父进程在子进程之前死机时，OS将子进程分配给“init”进程即PID 1。init进程“收养”子进程并成为其父进程。这意味着现在当子进程退出新的父进程（init）时，必须调用wait 来获取其退出代码否则其进程表项将保持永远，并且它也将成为一个僵尸进程。

在容器中，一个进程必须是每个PID命名空间的init进程。使用Docker，每个容器通常都有自己的PID命名空间，ENTRYPOINT进程是init进程。然而，正如我在上一篇关于Kubernetes pods的文章中所指出的，某个容器可以在另一个容器的命名空间中运行。在这种情况下，这个容器必须承担init进程的角色，而其他容器则作为init进程的子进程添加到命名空间中。

在Kubernetes pods的文章中，我在一个容器中运行nginx，并将ghost添加到了nginx容器的PID命名空间。

$ docker run -d --name nginx -v `pwd`/nginx.conf:/etc/nginx/nginx.conf -p 8080:80 nginx
$ docker run -d --name ghost --net=container:nginx --ipc=container:nginx --pid=container:nginx ghost

在这种情况下，nginx将承担PID 1的作用，并将ghost添加为nginx的子进程。虽然这样貌似不错，但从技术上来看，nginx现在需要负责任何ghost进程的子进程。例如，如果ghost分身或者使用子进程运行exec，并在子进程完成之前崩溃，那么这些子进程将被nginx收养。但是，nginx并不是设计用来作为一个init进程运行并收割僵尸进程的。这意味着将会有很多的这种僵尸进程，并且在整个容器的生命周期，他们都将持续存活。

在Kubernetes pods中，容器的运行方式与上述方式大致相同，但是每个pod都有一个特殊的“暂停”容器。这个“暂停”容器运行一个非常简单的进程，它不执行任何功能，基本上是永远睡觉的（见pause()下面的调用）。因为它比较简单，在这里写下完整的源代码，如下：

/*
Copyright 2016 The Kubernetes Authors.
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
    http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
*/

#include <signal.h>
#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <sys/wait.h>
#include <unistd.h>

static void sigdown(int signo) {
  psignal(signo, "Shutting down, got signal");
  exit(0);
}

static void sigreap(int signo) {
  while (waitpid(-1, NULL, WNOHANG) > 0);
}

int main() {
  if (getpid() != 1)
    /* Not an error because pause sees use outside of infra containers. */
    fprintf(stderr, "Warning: pause should be the first process\n");

  if (sigaction(SIGINT, &(struct sigaction){.sa_handler = sigdown}, NULL) < 0)
    return 1;
  if (sigaction(SIGTERM, &(struct sigaction){.sa_handler = sigdown}, NULL) < 0)
    return 2;
  if (sigaction(SIGCHLD, &(struct sigaction){.sa_handler = sigreap,
                                             .sa_flags = SA_NOCLDSTOP},
                NULL) < 0)
    return 3;

  for (;;)
    pause();
  fprintf(stderr, "Error: infinite loop terminated\n");
  return 42;
}

正如你所看到的，它当然不会只知道睡觉。它执行另一个重要的功能–即它扮演PID 1的角色，并在子进程被父进程孤立的时候通过调用wait 来收割这些僵尸子进程（参见sigreap）。这样我们就不用担心我们的Kubernetes pods的PID命名空间里会堆慢僵尸了。

PID命名空间共享的一些不能说的秘密

值得注意的是，PID命名空间共享已经有了很多的前后关系。如果你启用了PID命名空间共享，那么只能通过暂停容器来收割僵尸，并且目前这一功能仅在Kubernetes 1.7+以上的版本中可用。如果使用Docker 1.13.1+运行Kubernetes 1.7，这一功能默认是开启的，除非使用kubelet标志（–docker-disable-shared-pid=true）禁用。这在Kubernetes 1.8 中正好相反的，现在默认情况下是禁用的，除非由kubelet标志（–docker-disable-shared-pid=false）启用。感兴趣的话，可以看看在GitHub issue中对增加支持PID命名空间共享的有关讨论。

如果没有启用PID命名空间共享，则Kubernetes pod中的每个容器都将具有自己的PID 1，并且每个容器将需要收集僵尸进程本身。很多时候，这不是一个问题，因为应用程序不会产生其他进程，但僵尸进程使用内存是一个经常被忽视的问题。因此，由于PID命名空间共享使你能够在同一个pod中的容器之间发送信号，我衷心的希望PID命名空间共享可以成为Kubernetes中的默认选项。