一个用于在没有 Docker Daemon 的环境里构建 OCI/Docker Container Image 的工具，历史上主要用于 Kubernetes / CI/CD 场景。
**Kaniko 项目目前已经 Archived，不再开发和维护。
1. Kaniko解决什么问题
传统 Docker 构建大致是：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
| Dockerfile
│
▼
docker build
│
▼
Docker Daemon
│
├── FROM image
├── RUN ...
├── COPY ...
└── ...
│
▼
Docker Image
|
构建 Image 通常需要 Docker Daemon
在 Kubernetes 中，如果你直接Pod里运行Docker Daemon，会涉及：
- privileged container
/var/run/docker.sock- Docker-in-Docker
- 容器逃逸风险
- CI 环境复杂化
Kaniko的核心思路就是：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
| Dockerfile
│
▼
┌─────────────────────┐
│ Kaniko Pod │
│ │
│ userspace executor │
│ │
│ FROM image │
│ ↓ │
│ 解包 rootfs │
│ ↓ │
│ RUN / COPY / ENV │
│ ↓ │
│ snapshot filesystem│
│ ↓ │
│ 生成 layer │
└─────────────────────┘
│
▼
Container Registry
|
不需要Docker Daemon。
官方 README 对它的定义也是：在 container/Kubernetes 中从 Dockerfile 构建镜像，并在userspace中执行 Dockerfile 指令。
2. Kaniko核心设计
它不是“运行 Docker”，而是自己实现了一套 Dockerfile → Image 的构建逻辑。
例如：
1
2
3
4
| FROM alpine
RUN apk add curl
COPY app /app
CMD ["/app"]
|
1
2
3
4
5
6
7
8
9
| Base Image
+
Layer 1: apk add curl
+
Layer 2: COPY app （增量层）
+
Image metadata
↓
Final Image
|
机制：每执行一个Dockerfile command，就在 userspace中snapshot filesystem，然后把发生变化的文件作为layer加到image上。
3.典型Kubernetes用法
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
| apiVersion: batch/v1
kind: Job
metadata:
name: kaniko-build
spec:
template:
spec:
containers:
- name: kaniko
image: gcr.io/kaniko-project/executor:latest
args:
- "--dockerfile=/workspace/Dockerfile"
- "--context=dir:///workspace"
- "--destination=myregistry.example.com/myapp:v1"
volumeMounts:
- name: workspace
mountPath: /workspace
restartPolicy: Never
volumes:
- name: workspace
emptyDir: {}
|
实际 CI 中通常是：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
| Git
│
▼
CI Runner
│
▼
Kubernetes Pod
│
▼
Kaniko Executor
│
├── checkout source
├── read Dockerfile
├── build image
└── push
│
▼
Container Registry
|
3.1Build Context
Kaniko 支持多种 context 来源
| Context |
示例 |
| 本地目录 |
dir:///workspace |
| tar.gz |
tar:///context.tar.gz |
| stdin |
tar://stdin |
| GCS |
gs://bucket/context.tar.gz |
| S3 |
s3://bucket/context.tar.gz |
| Azure Blob |
Azure URL |
| Git |
git://github.com/... |
4. Kaniko核心组件
1
2
3
4
5
6
7
8
9
| Kaniko
│
┌───────────┼───────────┐
▼ ▼ ▼
Dockerfile Filesystem Registry
Executor Snapshotter Client
│ │ │
▼ ▼ ▼
指令执行 Layer生成 Push
|
Executor
1
2
3
4
| /kaniko/executor \
--dockerfile=Dockerfile \
--context=dir:///workspace \
--destination=registry.example.com/app:v1
|
5.Kaniko vs Docker Build
| 类型 |
Docker Build |
Kaniko |
| Docker Daemon |
通常需要 |
不需要 |
| Kubernetes |
可以 |
很适合 |
| privileged |
传统方式常见 |
目标是不需要 |
| Dockerfile |
支持 |
支持 |
| Image Layer |
支持 |
支持 |
| Registry Push |
支持 |
支持 |
| CI/CD |
支持 |
曾经很常用 |
| Windows Container |
支持场景更广 |
不支持 |
| 项目状态 |
活跃 |
Archived |
6. Kaniko vs BuildKit
今天如果你设计新的 Container Build 基础设施，我会重点比较：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
| Docker BuildKit
│
├── buildx
├── Docker
└── standalone BuildKit
Kaniko
│
└── archived
Buildah
│
└── daemonless build
Podman
│
└── daemonless containers/build
img
│
└── daemonless Docker image builder
|
Kaniko 命令它背后的三个思想：
1
2
3
4
5
6
7
8
9
10
11
12
| Container Build
│
┌────────────┼────────────┐
▼ ▼ ▼
Execution Snapshot Distribution
│ │ │
▼ ▼ ▼
RUN/COPY filesystem Registry
diff
│
▼
Layer
|