截止目前 Kubernetes 1.18,Kubernetes 已经支持标准容器,Sidecar 容器,Init 容器,Ephemeral 容器 4 种类型的 Containers。本文我们详细介绍一下这 4 种容器的特性以及使用场景。
在 Kubernetes 1.18 之前,这两种容器从 Kubernetes 管理的角度来看,并没有什么区别。只不过人为从功能上做了区分。
例如现在 Istio 中 的 Envoy。
通过这种 Sidercar 模式,代理可以拦截进出主容器的流量从而 Istio 可以提取有关流量行为的大量信号作为属性。Istio 可以使用这些属性来执行策略决策,并将其发送到监视系统以提供有关整个网格行为的信息。
Sidecar 代理模型还允许您将 Istio 功能添加到现有部署中,而无需重新构造或重写代码。
适配器容器对输出进行标准化。考虑监视 N 个不同应用程序的任务。可以使用不同的导出监视数据的方式来构建每个应用程序。(例如 JMX,StatsD,特定于应用程序的统计信息),但每个监控系统都希望其收集的监控数据具有一致且统一的数据模型。
通过使用复合容器的适配器模式,您可以通过创建 Pod 来将来自不同系统的异构监视数据转换为一个统一的表示形式,该 Pod 将应用程序容器与知道如何进行转换的适配器分组在一起。同样,由于这些 Pod 共享名称空间和文件系统,因此这两个容器的协调非常简单明了。
Sidecar 容器扩展并增强了 “主” 容器,它们可以使用现有的容器并使它们变得更好。
例如,考虑一个运行 Nginx Web 服务器的容器。添加另一个将文件系统与 Git 存储库同步的容器,在这些容器之间共享文件系统,并且您已经构建了 Git Push-to-deploy。但是您已经以模块化的方式完成了此工作,其中 Git 同步器可以由不同的团队构建,并且可以在许多不同的Web服务器(Apache,Python,Tomcat等)上重复使用。
由于这种模块化,您只需编写和测试 Git 同步器一次,即可在众多应用程序中重复使用它。而且,如果有人编写它,您甚至不需要这样做。
这种场景一般出现在 DevOps 中。比如将收集日志的组件以 Sidecar 的方式部署,实现收集日志的用途,或是部署一个 Sidecar 组件从配置中心监听配置变化,实时更新本地配置。
Sidecar 容器的所有问题都与容器生命周期相关性有关。由于和 Pod 中的常规容器之间没有区别,因此无法控制哪个容器首先启动或最后终止,但是先正确运行 Sidecar 容器通常是应用程序容器正确运行的要求。
从 1.18 版本开始,K8S 内置的 Sidecar 功能将确保 Sidecar 容器在正常业务流程开始之前就启动并运行,即通过更改 Pod 的启动生命周期,在 Init 容器完成后启动 Sidecar 容器,在 Sidecar 容器就绪后启动业务容器,从启动流程上保证顺序性。
通过更改 Pod 规范中的 container.lifecycle.type
将容器标记为 Sidecar 类型:Sidecar
,默认为 Standard
,如下:
apiVersion: v1
kind: Pod
metadata:
name: bookings-v1-b54bc7c9c-v42f6
labels:
app: demoapp
spec:
containers:
- name: bookings
image: banzaicloud/allspark:0.1.1
...
- name: istio-proxy
image: docker.io/istio/proxyv2:1.4.3
lifecycle:
type: Sidecar
...
在 Kubernetes 中,Init 容器是在同一 Pod 中的其他容器之前开始并执行的容器。它旨在为 Pod 上托管的主应用程序执行初始化逻辑。例如,创建必要的用户帐户,执行数据库迁移,创建数据库结构等。
Init 容器与普通的容器非常像,除了如下两点:
因为 Init 容器具有与应用容器分离的单独镜像,其启动相关代码具有如下优势:
正如我们刚刚讨论的那样,Init 容器总是比同一个 Pod 上的其他应用程序容器先启动。结果,调度程序对 Init 容器的资源和限制赋予了更高的优先级。必须仔细考虑这种行为,因为这可能会导致不良后果。例如,如果您有一个初始化容器和一个应用程序容器,并且将初始化容器的资源和限制设置为高于应用程序容器的资源和限制,那么只有在有一个可用节点满足初始化的情况下,才调度整个 Pod 容器要求。换句话说,即使有一个未使用的节点可以在其中运行应用程序容器,但如果初始化容器具有该节点可以处理的更高资源先决条件,则 Pod 也不会部署到该节点。因此,在定义初始化容器的请求和限制时,您应尽可能严格。最佳做法是,除非绝对必要,否则请勿将这些参数设置为高于应用程序容器的值。
下面的例子定义了一个具有 2 个 Init 容器的简单 Pod。第一个等待 myservice 启动,第二个等待 mydb 启动。一旦这两个 Init容器 都启动完成,Pod 将启动 spec 区域中的应用容器。
apiVersion: v1
kind: Pod
metadata:
name: myapp-pod
labels:
app: myapp
spec:
containers:
- name: myapp-container
image: busybox:1.28
command: ['sh', '-c', 'echo The app is running! && sleep 3600']
initContainers:
- name: init-myservice
image: busybox:1.28
command: ['sh', '-c', "until nslookup myservice.$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace).svc.cluster.local; do echo waiting for myservice; sleep 2; done"]
- name: init-mydb
image: busybox:1.28
command: ['sh', '-c', "until nslookup mydb.$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace).svc.cluster.local; do echo waiting for mydb; sleep 2; done"]
这是 Kubernetes 1.6 版本的新语法,尽管老的 annotation 语法仍然可以使用。我们已经把 Init 容器的声明移到 spec 中:
apiVersion: v1
kind: Pod
metadata:
name: myapp-pod
labels:
app: myapp
spec:
containers:
- name: myapp-container
image: busybox
command: ['sh', '-c', 'echo The app is running! && sleep 3600']
initContainers:
- name: init-myservice
image: busybox
command: ['sh', '-c', 'until nslookup myservice; do echo waiting for myservice; sleep 2; done;']
- name: init-mydb
image: busybox
command: ['sh', '-c', 'until nslookup mydb; do echo waiting for mydb; sleep 2; done;']
1.5 版本的语法在 1.6 版本仍然可以使用,但是我们推荐使用 1.6 版本的新语法。在 Kubernetes 1.6 版本中,Init 容器在 API 中新建了一个字段。虽然期望使用 beta 版本的 annotation,但在未来发行版将会被废弃掉。
在所有的 Init 容器没有成功之前,Pod 将不会变成 Ready 状态。Init 容器的端口将不会在 Service 中进行聚集。正在初始化中的 Pod 处于 Pending 状态,但应该会将条件 Initializing 设置为 true。
如果 Pod 重启,所有 Init 容器必须重新执行。
对 Init 容器 spec 的修改,被限制在容器 image 字段中。更改 Init 容器的 image 字段,等价于重启该 Pod。
临时容器与其他容器的不同之处在于,它们缺少对资源或执行的保证,并且永远不会自动重启,因此不适用于构建应用程序。临时容器使用与常规容器相同的 ContainerSpec
段进行描述,但许多字段是不相容且不允许的。
ports
,livenessProbe
,readinessProbe
这样的字段是不允许的。resources
配置是不允许的。临时容器是使用 API 中的一种特殊的 ephemeralcontainers
处理器进行创建的,而不是直接添加到 pod.spec
段,因此无法使用 kubectl edit
来添加一个临时容器。
与常规容器一样,将临时容器添加到 Pod 后,将不能更改或删除临时容器。
我们知道容器的优点是它们通过使用不变方法提供所有必需的依赖项来运行隔离的进程。通过仅将所需的依赖项添加到镜像中,容器可以降低攻击面并提供更快的启动和部署。使用 "distroless" 方法构建容器镜像(基于 Scratch ),通过仅包含已编译的应用程序二进制文件,将容器镜像提升到了一个新的水平。与普通的容器镜像不同,它们不基于任何种类的 Linux 发行版,因此不包含任何其他可通过 kubectl exec
执行以进行故障排除的二进制文件和工具。这就决定了该容器有助于提供安全可靠的运行时环境,但也很难在问题发生时进行调试。
在这种情况下,临时容器发挥作用。它们实现了调试容器附加到主进程的功能,然后你可以用于调试任何类型的问题。调试容器可以基于任何镜像,因此可以根据您的需求进行定制。您可以构建自己的调试镜像,其中包含特殊的调试二进制文件或仅包含 curl,OpenSSL 和 MongoDB客户端之类的工具。但是,您也可以选择Linux发行版(如Ubuntu)或仅运行Busybox镜像,这两个镜像都已经包含了许多有用的工具。
临时容器是alpha功能,因此默认情况下处于禁用状态。您将需要激活以下功能门才能使用它们:
本节中的示例演示了临时容器如何出现在 API 中。通常,您可以使用 kubectl
插件进行故障排查,从而自动化执行这些步骤。
临时容器是使用 Pod 的 ephemeralcontainers
子资源创建的,可以使用 kubectl --raw
命令进行显示。首先描述临时容器被添加为一个 EphemeralContainers
列表:
{
"apiVersion": "v1",
"kind": "EphemeralContainers",
"metadata": {
"name": "example-pod"
},
"ephemeralContainers": [{
"command": [
"sh"
],
"image": "busybox",
"imagePullPolicy": "IfNotPresent",
"name": "debugger",
"stdin": true,
"tty": true,
"terminationMessagePolicy": "File"
}]
}
使用如下命令更新已运行的临时容器 example-pod
:
$ kubectl replace --raw /api/v1/namespaces/default/pods/example-pod/ephemeralcontainers -f ec.json
这将返回临时容器的新列表:
{
"kind":"EphemeralContainers",
"apiVersion":"v1",
"metadata":{
"name":"example-pod",
"namespace":"default",
"selfLink":"/api/v1/namespaces/default/pods/example-pod/ephemeralcontainers",
"uid":"a14a6d9b-62f2-4119-9d8e-e2ed6bc3a47c",
"resourceVersion":"15886",
"creationTimestamp":"2019-08-29T06:41:42Z"
},
"ephemeralContainers":[
{
"name":"debugger",
"image":"busybox",
"command":[
"sh"
],
"resources":{
},
"terminationMessagePolicy":"File",
"imagePullPolicy":"IfNotPresent",
"stdin":true,
"tty":true
}
]
}
可以使用以下命令查看新创建的临时容器的状态:
$ kubectl describe pod example-pod
...
Ephemeral Containers:
debugger:
Container ID: docker://cf81908f149e7e9213d3c3644eda55c72efaff67652a2685c1146f0ce151e80f
Image: busybox
Image ID: docker-pullable://busybox@sha256:9f1003c480699be56815db0f8146ad2e22efea85129b5b5983d0e0fb52d9ab70
Port: <none>
Host Port: <none>
Command:
sh
State: Running
Started: Thu, 29 Aug 2019 06:42:21 +0000
Ready: False
Restart Count: 0
Environment: <none>
Mounts: <none>
...
可以使用以下命令连接到新的临时容器:
$ kubectl attach -it example-pod -c debugger
如果启用了进程命名空间共享,则可以查看该 Pod 所有容器中的进程。例如,运行上述 attach
操作后,在调试器容器中运行 ps
操作:
# 在 "debugger" 临时容器内中运行此 shell 命令
$ ps auxww
运行命令后,输出类似于:
PID USER TIME COMMAND
1 root 0:00 /pause
6 root 0:00 nginx: master process nginx -g daemon off;
11 101 0:00 nginx: worker process
12 101 0:00 nginx: worker process
13 101 0:00 nginx: worker process
14 101 0:00 nginx: worker process
15 101 0:00 nginx: worker process
16 101 0:00 nginx: worker process
17 101 0:00 nginx: worker process
18 101 0:00 nginx: worker process
19 root 0:00 /pause
24 root 0:00 sh
29 root 0:00 ps auxww
本文简单介绍了标准容器,Sidecar 容器,Init 容器,Ephemeral 容器 4 种类型的 Containers。随着 Kubernetes 日益普及,我们需要充分掌握这几种类型容器原理和使用方法,才能更好地服务业务。
此外 Sidecar 容器将会成为未来软件交付的一种新的方式,参照 Dapr 等,不同的团队提供自己的功能容器,然后选择性注入 Sidecar 到主业务容器,实现解耦。