Docker on HRunning

SRE面试题汇总 | Docker

Sat, 06 Dec 2025 09:56:07 +0800

容器技术的基础原理

容器技术的基础原理是基于 Linux 内核的 Namespace、Cgroups、Rootfs、Capabilities 和 Seccomp 等机制。

它主要解决了应用运行环境不一致的问题：将应用、依赖和配置打包为可复用的镜像，再以隔离的进程方式运行。

容器镜像通常利用 Linux 的 Union FS 能力，将基础系统、运行库、应用文件和配置等内容以分层方式组织起来。容器启动时，运行时会把镜像层和可写层组合成容器的 Rootfs。

如何减小 Dockerfile 生成的镜像体积？

使用更小的基础镜像
将构建环境与运行环境分离，使用多阶段构建：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


# 第一阶段：编译
FROM golang:1.22-alpine AS builder
WORKDIR /app
COPY . .
RUN CGO_ENABLED=0 go build -trimpath -ldflags="-s -w" -o /out/app .

# 第二阶段：运行
FROM alpine:3.19
COPY --from=builder /out/app /usr/local/bin/app
CMD ["/usr/local/bin/app"]

及时清理构建缓存和临时文件，并让 apt、yum、apk 的缓存不要进入最终镜像层。例如 Debian/Ubuntu 可以使用 --no-install-recommends。
合并关联的 RUN 指令，避免清理操作发生在下一层，导致缓存仍然保留在镜像历史中。
最终运行阶段只复制必要的二进制文件、配置和证书，不要复制整个源码目录。
使用 .dockerignore 排除 .git、测试数据、日志、构建产物和本地依赖等无关文件。
根据程序依赖选择基础镜像。Alpine 不一定适合所有程序，使用 C/C++ 或 CGO 时要注意 musl/glibc 兼容性；使用 scratch 或 distroless 时还要补充 CA 证书、时区等运行时文件。

容器网络模式

网络模式	特点	典型场景
`bridge`	默认模式，容器拥有独立的 Network Namespace 和 IP，通过网桥通信；外部通常通过端口映射访问	普通 Web 服务、微服务，最常用
`host`	容器直接使用宿主机网络栈，没有独立的网络 Namespace，不经过常规 NAT	对网络性能或端口可见性要求较高的场景
`none`	只保留 loopback，不配置外部网络，需要应用自行配置网络	强隔离或自定义网络实验
`container:<name\|id>`	与另一个容器共享 Network Namespace，共享 IP、端口和 `localhost`	Sidecar、多容器协作

container 模式下，两个容器访问对方通常使用 localhost 和共享端口，而不是把它们当成拥有两个独立 IP 的容器。

Docker、镜像和 container 的区别

Docker / Docker Engine：容器平台和容器引擎，负责镜像构建、容器创建与管理、网络、Volume 等能力。
镜像（Image）：只读的分层模板，包含应用程序及其依赖、文件系统和默认配置，本身不是正在运行的进程。
容器（Container）：镜像启动后的运行实例，本质上是一组被 Namespace 和 Cgroups 隔离、限制和管理的进程。
containerd：负责镜像传输与存储、容器生命周期等核心工作的容器运行时；Docker Engine 内部也会使用 containerd。

为什么 Kubernetes 从 Docker Engine 转向 containerd？

Kubernetes 真正需要的是符合 CRI（Container Runtime Interface）的容器运行时，而 Docker Engine 是一个包含镜像构建、网络、Volume、Swarm 等能力的完整平台，并没有直接面向 kubelet 的原生 CRI 接口。

架构层面的原因

使用 Docker Engine 时，kubelet 启动容器通常需要经过 dockershim 转换层：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


kubelet
 │ 调用 CRI
 ▼
dockershim（Kubernetes 维护的 CRI 转换层）
 │ 调用 Docker Engine API
 ▼
Docker Engine
 │ 调用 containerd API
 ▼
containerd
 │ 调用 OCI Runtime
 ▼
runc（以 runc 为例）
 └─> 创建 Linux 容器（Namespace、Cgroups、Rootfs 等）

Docker Engine 的很多平台能力对 kubelet 并不是必需的。
dockershim 负责把 Kubernetes 的 CRI 调用转换为 Docker Engine API 调用，增加了维护成本和中间环节。
真正创建 Linux 容器的通常仍是 containerd 加 OCI Runtime，例如 runc。

当 kubelet 直接通过 CRI 使用 containerd 时，调用链可以简化为：

1
2
3
4
5
6
7
8


kubelet
 │ 调用 CRI
 ▼
containerd（CRI 插件）
 │ 调用 OCI Runtime
 ▼
runc（以 runc 为例）
 └─> 创建 Linux 容器（Namespace、Cgroups、Rootfs 等）

减少维护成本

Kubernetes 1.24 移除了内置的 dockershim，不再在 Kubernetes 项目中维护 Docker Engine 的适配层。这里的含义不是 Kubernetes 强制所有集群使用 containerd，containerd、CRI-O 等符合 CRI 的运行时都可以使用；containerd 只是常见选择之一。

性能与稳定性

直接使用 CRI 运行时可以减少适配层和组件数量，降低维护复杂度，并可能减少额外的调用开销。但实际性能和稳定性还取决于运行时版本、CNI、存储驱动、镜像配置和工作负载，不能简单认为“少一层调用”就一定带来显著性能提升。

Containerd命令行管理工具

Thu, 27 Nov 2025 10:51:50 +0800

Containerd 命令行管理工具

Kubernetes 从 Docker 转向 containerd 的原因

架构层面的原因

kubelet 启动一个容器的流程:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


kubelet
 │
 │ (调用 CRI 接口)
 ▼
dockershim (K8s 维护的 CRI 转换层)
 │
 │ (调用 Docker Engine API)
 ▼
Docker Engine
 │
 │ (调用 containerd API)
 ▼
containerd
 │
 │ (调用 OCI 接口)
 ▼
runc (OCI runtime)
 │
 └─> 真正创建 Linux 容器 (namespace, cgroups, rootfs...)

Docker Engine 是一个完整平台（构建镜像、管理网络、Volume、Swarm 等），这些对 K8s 来说都是多余的。
dockershim 只是为了把 CRI（K8s 语言）翻译成 Docker API（Docker 语言）。
实际执行容器的，依然是 containerd + runc。

当 kubelet 直接使用 containerd 时，调用链简化为：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


 kubelet
 │
 │ (调用 CRI 接口)
 ▼
containerd (内置 CRI 插件)
 │
 │ (调用 OCI 接口)
 ▼
runc (OCI runtime)
 │
 └─> 真正创建 Linux 容器 (namespace, cgroups, rootfs...)

减少维护成本

kubernetes 从 1.24 开始，默认使用 containerd 作为容器运行时。不再去维护中间dockershim

性能提升

少一层调用，性能和稳定性更好。

ctr – Containerd自带的命令行管理工具

1
2


# 列出所有命名空间
sudo ctr namespaces list

1
2


# 镜像相关命令
sudo ctr -n=k8s.io images -h

ctr 上传、拉取镜像时不支持登陆认证，只能通过–user携带用户密码操作

1
2
3


sudo ctr -n=k8s.io images pull \
 --user <username>:<password> \
 myregistry.example.com/myrepo/nginx:latest

nerdctl (最接近docker CLI)

基本和docker CLI命令一致，只是在命令前添加了nerdctl前缀

安装nerdctl

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38


#!/bin/bash
set -e

VERSION=${VERSION:-2.2.0}

# 自动识别架构
ARCH=$(uname -m)
if [[ "$ARCH" == "x86_64" ]]; then
 ARCH="amd64"
elif [[ "$ARCH" == "aarch64" ]]; then
 ARCH="arm64"
else
 echo "Unsupported architecture: $ARCH"
 exit 1
fi

DOWNLOAD_URL="https://github.com/containerd/nerdctl/releases/download/v${VERSION}/nerdctl-${VERSION}-linux-${ARCH}.tar.gz"

echo "Downloading nerdctl v$VERSION for $ARCH"
wget "$DOWNLOAD_URL" -O nerdctl.tgz

echo "Extracting..."
tar -xzf nerdctl.tgz

# 解压后会得到 nerdctl、containerd、runc 等二进制
# 一般 nerdctl 位于当前目录的 nerdctl
TARGET_DIR="/usr/local/bin"

echo "Moving binaries to $TARGET_DIR (require sudo)"
sudo mv nerdctl "${TARGET_DIR}/"


echo "Cleaning up…"
rm -f nerdctl.tgz

echo "🎉 nerdctl installation completed!"
echo "Version check:"
sudo ${TARGET_DIR}/nerdctl --version

To list local Kubernetes containers:

1

nerdctl --namespace k8s.io ps -a

容器网络影响宿主机入网问题排查

Wed, 26 Nov 2025 10:38:20 +0800

容器网络影响宿主机入网问题排查

问题描述

发现172.27.0.0/16，172.26.0.0/16 网段的服务无法访问宿主机的服务

问题排查

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


docker network ls
NETWORK ID NAME DRIVER SCOPE
8eacdcbf22d7 7b-full_default bridge local
f22af6f77037 bridge bridge local
4a56201be716 host host local
6e36d25cdbb0 llama2-13b-lora_default bridge local
fb2839792d18 llama3-8b_lora_default bridge local
d1f916892b02 none null local
2c9c2578ecce tgi_default bridge local
446845acbad5 v2-9b_default bridge local
d1301d605f3c v2-27b-it_default bridge local
c3d523d51ee4 v3-8b_default bridge local
1d3cf7bd9665 v4-9b_default bridge local
59aecf59ca81 v31-8b_default bridge local
42cca879c18f webui-docker_default bridge local

发现1d3cf7bd9665、1d3cf7bd9665占用了172.27.0.0/16，172.26.0.0/16 网段，导致路由冲突。Linux 内核的路由机制会优先选择最匹配的路由，它会覆盖默认路由，流量会被错误的流向docker。

解决方法

修改docker 配置，不使用冲突网段

1
2
3
4
5
6
7
8
9


{
 "bip": "192.168.100.1/24",
 "default-address-pools": [
 {
 "base": "192.168.200.0/20",
 "size": 24
 }
 ]
}

创建容器时使用特定网络

docker network create –subnet=xx.xx.xx.xx/24 my_custom_network

如果必须保留冲突网段，修改宿主机路由，让外部网络优先

1
2


ip route del 172.27.0.0/16
ip route add 172.27.0.0/16 via <外部网关> metric 100