容器技術已經從新興技術演變為現代軟體開發與佈署的基礎設施，它徹底改變了應用程式的打包、分發和執行方式。從最早的 Docker 革命性地將 Linux 容器技術帶入主流，到 Kubernetes 成為容器編排的事實標準，再到 Podman 以其無守護程序架構挑戰傳統容器模式，容器技術的生態系統持續蓬勃發展。本文將從容器技術的底層原理出發，深入剖析 Linux 命名空間與控制群組等核心隔離機制，探討主流容器平台的技術特性與應用場景，並分享容器網路組態、映像檔管理與安全強化的實戰經驗，幫助讀者建立完整的容器技術知識體系。
容器技術底層原理與隔離機制
容器技術的核心價值在於提供輕量級的應用程式隔離和可攜性，而這一切都建立在 Linux 核心的幾個關鍵特性之上。理解這些底層機制對於正確使用容器技術、診斷問題和最佳化效能都至關重要。與傳統虛擬機器不同，容器並不虛擬化硬體，而是透過核心層級的隔離機制在同一個作業系統上建立多個獨立的執行環境。
Linux 命名空間是容器隔離的基礎，它為程序提供了系統資源的獨立視圖。目前 Linux 核心支援多種類型的命名空間，每種命名空間負責隔離特定類型的資源。PID 命名空間隔離程序識別碼，使容器內的程序有自己的程序樹，其中第一個程序的 PID 為 1。NET 命名空間隔離網路堆疊，包括網路介面、路由表和防火牆規則，這讓每個容器可以擁有獨立的 IP 地址和網路組態。MNT 命名空間隔離檔案系統掛載點，允許容器擁有獨立的檔案系統視圖。UTS 命名空間隔離主機名稱和網域名稱。IPC 命名空間隔離程序間通訊資源，如信號量和共享記憶體。USER 命名空間隔離使用者和群組識別碼，這是實現無根容器的關鍵技術。
控制群組是容器資源管理的核心機制，它允許限制、記錄和隔離程序群組使用的實體資源。透過 cgroup，我們可以限制容器使用的 CPU 時間、記憶體用量、磁碟 I/O 頻寬和網路頻寬。cgroup v2 是控制群組的新版本，它採用統一的階層結構，簡化了資源控制的組態和管理。在容器環境中，cgroup 確保單一容器不會獨佔系統資源，影響其他容器或主機系統的正常運作。
聯合檔案系統是容器映像檔技術的基礎，它允許將多個檔案系統層堆疊在一起，形成一個統一的視圖。最常見的聯合檔案系統包括 OverlayFS、AUFS 和 Device Mapper。在容器映像檔中，每一層代表一組檔案變更，這種分層結構讓映像檔可以高效地儲存和傳輸，因為相同的層可以在多個映像檔之間共享。當容器執行時，會在映像檔層之上新增一個可寫層，用於儲存容器執行過程中的檔案變更。
@startuml
!define PLANTUML_FORMAT svg
!theme _none_
skinparam dpi auto
skinparam shadowing false
skinparam linetype ortho
skinparam roundcorner 5
skinparam defaultFontName "Microsoft JhengHei UI"
skinparam defaultFontSize 16
skinparam minClassWidth 100
rectangle "容器隔離技術架構" as isolation {
rectangle "Linux Namespace" as ns {
rectangle "PID Namespace" as pid
rectangle "NET Namespace" as net
rectangle "MNT Namespace" as mnt
rectangle "UTS Namespace" as uts
rectangle "IPC Namespace" as ipc
rectangle "USER Namespace" as user
}
rectangle "Control Groups (cgroup)" as cgroup {
rectangle "CPU 限制" as cpu
rectangle "記憶體限制" as mem
rectangle "I/O 限制" as io
rectangle "網路頻寬" as bw
}
rectangle "聯合檔案系統" as ufs {
rectangle "映像檔層" as image
rectangle "可寫層" as writable
}
}
rectangle "容器執行環境" as runtime
pid --> runtime
net --> runtime
mnt --> runtime
cpu --> runtime
mem --> runtime
image --> runtime
writable --> runtime
@enduml
上圖展示了容器隔離技術的核心架構。Linux Namespace 提供了多種類型的資源隔離，Control Groups 負責資源限制和計量，而聯合檔案系統則提供了高效的映像檔儲存機制。這三種技術共同構成了容器執行環境的基礎。
Docker 技術體系與最佳實踐
Docker 是將容器技術帶入主流的先驅，它透過簡潔的使用者介面和完善的生態系統，讓開發者可以輕鬆地建立、分發和執行容器化應用程式。儘管容器技術本身並非 Docker 的發明，但 Docker 的貢獻在於將複雜的 Linux 容器技術封裝成易於使用的工具鏈，並建立了容器映像檔的標準格式和分發機制。
Docker 架構採用客戶端-伺服器模式，由 Docker 客戶端、Docker 守護程序和容器執行時三個主要元件組成。Docker 客戶端接收使用者命令並傳送給守護程序處理。Docker 守護程序是一個長期執行的背景程序，負責建立和管理容器、映像檔、網路和儲存卷。容器執行時負責實際執行容器，Docker 預設使用 containerd 作為高階執行時，runc 作為低階執行時。這種分層架構讓 Docker 可以靈活地替換底層元件，同時保持上層 API 的穩定性。
Dockerfile 是定義容器映像檔的藍圖，它使用一系列指令描述如何從基礎映像檔建構應用程式映像檔。編寫高效的 Dockerfile 對於減少映像檔大小和建構時間至關重要。多階段建構是一種重要的最佳化技術，它允許在一個 Dockerfile 中使用多個 FROM 指令，將建構環境和執行環境分開。這樣可以在建構階段使用完整的開發工具，而只將編譯產物複製到精簡的執行映像檔中。層快取機制可以顯著加速映像檔建構，將不常變更的指令放在 Dockerfile 前面，將頻繁變更的指令放在後面，可以最大化快取命中率。
Docker Compose 是用於定義和執行多容器應用程式的工具，它使用 YAML 檔案描述服務、網路和儲存卷的組態。對於微服務架構的應用程式，Docker Compose 提供了一種簡潔的方式來管理服務之間的相依關係和通訊。透過一個 docker-compose up 命令，可以同時啟動所有相關服務，大幅簡化了本地開發和測試環境的設定。
import docker
import json
from datetime import datetime
class DockerContainerManager:
"""
Docker 容器管理器
提供容器生命週期管理、映像檔操作和系統監控功能
"""
def __init__(self):
"""
初始化 Docker 客戶端
連接到本地 Docker 守護程序
"""
# 建立 Docker 客戶端連線
# from_env() 會自動讀取環境變數來組態連線
self.client = docker.from_env()
# 取得低階 API 客戶端，用於進階操作
self.api_client = docker.APIClient()
print("Docker 客戶端已連接")
print(f"Docker 版本: {self.client.version()['Version']}")
def list_containers(self, all_containers=False):
"""
列出所有容器
Args:
all_containers: 是否包含已停止的容器
Returns:
容器資訊列表
"""
# 取得容器列表
containers = self.client.containers.list(all=all_containers)
container_info = []
for container in containers:
info = {
'id': container.short_id,
'name': container.name,
'image': container.image.tags[0] if container.image.tags else 'untagged',
'status': container.status,
'created': container.attrs['Created']
}
container_info.append(info)
print(f"\n找到 {len(container_info)} 個容器")
for info in container_info:
print(f" {info['name']} ({info['id']}): {info['status']}")
return container_info
def create_container(self, image_name, container_name, ports=None,
volumes=None, environment=None):
"""
建立並啟動容器
Args:
image_name: 映像檔名稱
container_name: 容器名稱
ports: 連接埠對應字典，例如 {'80/tcp': 8080}
volumes: 儲存卷對應字典
environment: 環境變數字典
Returns:
容器物件
"""
print(f"\n正在建立容器 {container_name}...")
# 確保映像檔存在
try:
self.client.images.get(image_name)
except docker.errors.ImageNotFound:
print(f"映像檔 {image_name} 不存在，正在拉取...")
self.client.images.pull(image_name)
# 建立容器
# detach=True 讓容器在背景執行
container = self.client.containers.run(
image=image_name,
name=container_name,
ports=ports or {},
volumes=volumes or {},
environment=environment or {},
detach=True
)
print(f"容器 {container_name} 已建立並啟動")
print(f"容器 ID: {container.short_id}")
return container
def get_container_stats(self, container_name):
"""
取得容器資源使用統計
Args:
container_name: 容器名稱
Returns:
資源使用統計字典
"""
try:
container = self.client.containers.get(container_name)
# 取得即時統計資料
# stream=False 只取得單次快照
stats = container.stats(stream=False)
# 計算 CPU 使用率
# Docker 統計中的 CPU 使用量是累積值
cpu_delta = stats['cpu_stats']['cpu_usage']['total_usage'] - \
stats['precpu_stats']['cpu_usage']['total_usage']
system_delta = stats['cpu_stats']['system_cpu_usage'] - \
stats['precpu_stats']['system_cpu_usage']
cpu_count = stats['cpu_stats']['online_cpus']
if system_delta > 0:
cpu_percent = (cpu_delta / system_delta) * cpu_count * 100
else:
cpu_percent = 0
# 計算記憶體使用率
mem_usage = stats['memory_stats']['usage']
mem_limit = stats['memory_stats']['limit']
mem_percent = (mem_usage / mem_limit) * 100
# 計算網路 I/O
net_io = stats.get('networks', {})
rx_bytes = sum(net['rx_bytes'] for net in net_io.values())
tx_bytes = sum(net['tx_bytes'] for net in net_io.values())
result = {
'container': container_name,
'cpu_percent': round(cpu_percent, 2),
'memory_usage_mb': round(mem_usage / 1024 / 1024, 2),
'memory_limit_mb': round(mem_limit / 1024 / 1024, 2),
'memory_percent': round(mem_percent, 2),
'network_rx_mb': round(rx_bytes / 1024 / 1024, 2),
'network_tx_mb': round(tx_bytes / 1024 / 1024, 2)
}
print(f"\n容器 {container_name} 資源使用統計:")
print(f" CPU 使用率: {result['cpu_percent']}%")
print(f" 記憶體使用: {result['memory_usage_mb']} MB / "
f"{result['memory_limit_mb']} MB ({result['memory_percent']}%)")
print(f" 網路 RX: {result['network_rx_mb']} MB")
print(f" 網路 TX: {result['network_tx_mb']} MB")
return result
except docker.errors.NotFound:
print(f"容器 {container_name} 不存在")
return None
def execute_command(self, container_name, command):
"""
在容器內執行命令
Args:
container_name: 容器名稱
command: 要執行的命令
Returns:
命令輸出
"""
try:
container = self.client.containers.get(container_name)
# 在容器內執行命令
# demux=True 分離 stdout 和 stderr
exit_code, output = container.exec_run(
command,
demux=True
)
stdout = output[0].decode('utf-8') if output[0] else ''
stderr = output[1].decode('utf-8') if output[1] else ''
print(f"\n在容器 {container_name} 中執行: {command}")
print(f"退出碼: {exit_code}")
if stdout:
print(f"標準輸出:\n{stdout}")
if stderr:
print(f"標準錯誤:\n{stderr}")
return {
'exit_code': exit_code,
'stdout': stdout,
'stderr': stderr
}
except docker.errors.NotFound:
print(f"容器 {container_name} 不存在")
return None
def build_image(self, dockerfile_path, image_tag, build_args=None):
"""
從 Dockerfile 建構映像檔
Args:
dockerfile_path: Dockerfile 所在目錄
image_tag: 映像檔標籤
build_args: 建構參數字典
Returns:
映像檔物件
"""
print(f"\n正在建構映像檔 {image_tag}...")
# 建構映像檔
# decode=True 解碼建構日誌
image, build_logs = self.client.images.build(
path=dockerfile_path,
tag=image_tag,
buildargs=build_args or {},
rm=True, # 建構完成後移除中間容器
forcerm=True # 建構失敗時也移除中間容器
)
# 輸出建構日誌
for log in build_logs:
if 'stream' in log:
print(log['stream'].strip())
print(f"\n映像檔 {image_tag} 建構完成")
print(f"映像檔 ID: {image.short_id}")
return image
def cleanup_unused_resources(self):
"""
清理未使用的 Docker 資源
移除停止的容器、未使用的映像檔和網路
"""
print("\n正在清理未使用的 Docker 資源...")
# 移除停止的容器
pruned_containers = self.client.containers.prune()
print(f"已移除 {len(pruned_containers.get('ContainersDeleted', []))} 個容器")
# 移除未使用的映像檔
pruned_images = self.client.images.prune()
space_reclaimed = pruned_images.get('SpaceReclaimed', 0)
print(f"已回收 {space_reclaimed / 1024 / 1024:.2f} MB 映像檔空間")
# 移除未使用的網路
pruned_networks = self.client.networks.prune()
print(f"已移除 {len(pruned_networks.get('NetworksDeleted', []))} 個網路")
# 移除未使用的儲存卷
pruned_volumes = self.client.volumes.prune()
print(f"已移除 {len(pruned_volumes.get('VolumesDeleted', []))} 個儲存卷")
# 使用範例
if __name__ == "__main__":
# 建立 Docker 管理器
manager = DockerContainerManager()
# 列出所有容器
containers = manager.list_containers(all_containers=True)
# 清理未使用的資源
manager.cleanup_unused_resources()
上述程式碼展示了使用 Python Docker SDK 進行容器管理的完整範例。DockerContainerManager 類別封裝了容器生命週期管理、資源監控和映像檔建構等核心功能。透過這種程式化的方式管理容器，可以輕鬆地整合到自動化工作流程和監控系統中。
Kubernetes 容器編排深度剖析
Kubernetes 是目前最流行的容器編排平台，它提供了強大的功能來管理容器化應用程式的部署、擴展和運維。Kubernetes 的設計哲學是宣告式組態，使用者定義期望的系統狀態，Kubernetes 負責達成和維護該狀態。這種方式讓系統具有自我修復能力，當實際狀態偏離期望狀態時，控制器會自動採取行動進行修正。
Kubernetes 的架構分為控制平面和工作節點兩部分。控制平面包含 API 伺服器、etcd、排程器和控制器管理器等元件。API 伺服器是所有元件通訊的中心，它提供 RESTful API 供客戶端和其他元件存取。etcd 是一個分散式鍵值儲存系統，用於儲存叢集的所有組態資料和狀態。排程器負責決定新建立的 Pod 應該在哪個節點上執行。控制器管理器執行各種控制迴圈，監控叢集狀態並進行必要的調整。工作節點則執行實際的應用程式容器，每個節點包含 kubelet、容器執行時和 kube-proxy。
Pod 是 Kubernetes 中最小的可部署單元，它代表叢集中執行的一組容器。同一個 Pod 中的容器共享網路命名空間和儲存卷，它們可以透過 localhost 相互通訊。這種設計適合緊密耦合的應用程式元件，例如主應用程式和其 sidecar 容器。Deployment 是管理 Pod 副本集的高階抽象，它提供了宣告式更新、滾動升級和回滾等功能。Service 則為一組 Pod 提供穩定的網路端點，實現服務發現和負載均衡。
Kubernetes 的網路模型要求每個 Pod 都有獨立的 IP 地址，且所有 Pod 可以不經過 NAT 直接相互通訊。這種扁平的網路模型簡化了應用程式的網路組態，但需要底層網路外掛的支援。常見的網路外掛包括 Calico、Flannel、Weave 和 Cilium，每種外掛都有不同的特性和效能特點。Calico 使用 BGP 協定進行路由，適合大規模叢集。Cilium 基於 eBPF 技術，提供了強大的網路可觀測性和安全功能。
# Kubernetes Deployment 組態範例
# 此檔案定義了一個完整的微服務部署，包含應用程式、服務和自動擴展
---
# ConfigMap 用於儲存應用程式組態
# 將組態與應用程式分離，便於在不同環境中使用相同的映像檔
apiVersion: v1
kind: ConfigMap
metadata:
name: app-config
namespace: production
labels:
app: web-application
data:
# 應用程式組態項目
DATABASE_HOST: "postgres-service"
DATABASE_PORT: "5432"
CACHE_HOST: "redis-service"
LOG_LEVEL: "info"
---
# Secret 用於儲存敏感資訊
# 資料會以 base64 編碼儲存，建議使用外部 Secret 管理系統
apiVersion: v1
kind: Secret
metadata:
name: app-secrets
namespace: production
type: Opaque
data:
# base64 編碼的敏感資料
DATABASE_PASSWORD: cGFzc3dvcmQxMjM=
API_KEY: YXBpLWtleS1zZWNyZXQ=
---
# Deployment 定義應用程式的部署策略
apiVersion: apps/v1
kind: Deployment
metadata:
name: web-application
namespace: production
labels:
app: web-application
version: v1.0.0
spec:
# 副本數量，指定要維持的 Pod 數量
replicas: 3
# 標籤選擇器，用於識別此 Deployment 管理的 Pod
selector:
matchLabels:
app: web-application
# 更新策略
strategy:
type: RollingUpdate
rollingUpdate:
# 更新過程中可以多出的 Pod 數量
maxSurge: 1
# 更新過程中可以少於的 Pod 數量
maxUnavailable: 0
template:
metadata:
labels:
app: web-application
version: v1.0.0
# 自定義註解，可用於監控和日誌系統
annotations:
prometheus.io/scrape: "true"
prometheus.io/port: "8080"
prometheus.io/path: "/metrics"
spec:
# 服務帳戶，定義 Pod 的身份和許可權
serviceAccountName: web-app-sa
# 安全上下文，定義 Pod 層級的安全設定
securityContext:
runAsNonRoot: true
runAsUser: 1000
fsGroup: 1000
# 初始化容器，在主容器啟動前執行
initContainers:
- name: wait-for-database
image: busybox:1.35
# 等待資料庫服務就緒
command: ['sh', '-c', 'until nc -z postgres-service 5432; do echo waiting for database; sleep 2; done']
containers:
- name: web-app
image: myregistry/web-application:v1.0.0
imagePullPolicy: Always
# 連接埠組態
ports:
- name: http
containerPort: 8080
protocol: TCP
- name: metrics
containerPort: 9090
protocol: TCP
# 資源限制和請求
# requests 用於排程，limits 用於執行時限制
resources:
requests:
cpu: "100m"
memory: "128Mi"
limits:
cpu: "500m"
memory: "512Mi"
# 環境變數，從 ConfigMap 和 Secret 載入
env:
- name: DATABASE_HOST
valueFrom:
configMapKeyRef:
name: app-config
key: DATABASE_HOST
- name: DATABASE_PASSWORD
valueFrom:
secretKeyRef:
name: app-secrets
key: DATABASE_PASSWORD
- name: POD_NAME
valueFrom:
fieldRef:
fieldPath: metadata.name
- name: POD_NAMESPACE
valueFrom:
fieldRef:
fieldPath: metadata.namespace
# 儲存卷掛載
volumeMounts:
- name: app-data
mountPath: /app/data
- name: config-volume
mountPath: /app/config
# 存活探針，用於檢測容器是否正常運作
# 如果探針失敗，容器會被重新啟動
livenessProbe:
httpGet:
path: /health/live
port: http
initialDelaySeconds: 30
periodSeconds: 10
timeoutSeconds: 5
failureThreshold: 3
# 就緒探針，用於檢測容器是否準備好接收流量
# 如果探針失敗，Pod 會從服務端點中移除
readinessProbe:
httpGet:
path: /health/ready
port: http
initialDelaySeconds: 5
periodSeconds: 5
timeoutSeconds: 3
failureThreshold: 3
# 啟動探針，用於慢啟動容器
# 在探針成功前，存活和就緒探針不會執行
startupProbe:
httpGet:
path: /health/startup
port: http
initialDelaySeconds: 10
periodSeconds: 10
failureThreshold: 30
# 容器安全上下文
securityContext:
allowPrivilegeEscalation: false
readOnlyRootFilesystem: true
capabilities:
drop:
- ALL
# 儲存卷定義
volumes:
- name: app-data
persistentVolumeClaim:
claimName: app-data-pvc
- name: config-volume
configMap:
name: app-config
# 親和性規則，控制 Pod 的排程
affinity:
# Pod 反親和性，確保副本分散在不同節點
podAntiAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 100
podAffinityTerm:
labelSelector:
matchLabels:
app: web-application
topologyKey: kubernetes.io/hostname
# 容忍度，允許 Pod 被排程到具有特定污點的節點
tolerations:
- key: "node-role.kubernetes.io/master"
effect: "NoSchedule"
---
# Service 定義，為 Pod 提供穩定的網路端點
apiVersion: v1
kind: Service
metadata:
name: web-application-service
namespace: production
labels:
app: web-application
spec:
type: ClusterIP
selector:
app: web-application
ports:
- name: http
port: 80
targetPort: http
protocol: TCP
- name: metrics
port: 9090
targetPort: metrics
protocol: TCP
---
# HorizontalPodAutoscaler 定義，根據資源使用率自動擴展
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: web-application-hpa
namespace: production
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: web-application
minReplicas: 3
maxReplicas: 10
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 70
- type: Resource
resource:
name: memory
target:
type: Utilization
averageUtilization: 80
behavior:
scaleUp:
stabilizationWindowSeconds: 60
policies:
- type: Percent
value: 100
periodSeconds: 60
scaleDown:
stabilizationWindowSeconds: 300
policies:
- type: Percent
value: 50
periodSeconds: 60
上述 YAML 組態展示了一個生產級別的 Kubernetes 部署，包含 ConfigMap、Secret、Deployment、Service 和 HorizontalPodAutoscaler。組態中包含了資源限制、健康檢查、安全設定和自動擴展策略等最佳實踐。
@startuml
!define PLANTUML_FORMAT svg
!theme _none_
skinparam dpi auto
skinparam shadowing false
skinparam linetype ortho
skinparam roundcorner 5
skinparam defaultFontName "Microsoft JhengHei UI"
skinparam defaultFontSize 16
skinparam minClassWidth 100
rectangle "Kubernetes 叢集架構" as cluster {
rectangle "控制平面" as control {
rectangle "API Server" as api
rectangle "etcd" as etcd
rectangle "Scheduler" as sched
rectangle "Controller Manager" as ctrl
}
rectangle "工作節點" as workers {
rectangle "節點 1" as node1 {
rectangle "kubelet" as kube1
rectangle "Pod A" as poda
rectangle "Pod B" as podb
}
rectangle "節點 2" as node2 {
rectangle "kubelet" as kube2
rectangle "Pod C" as podc
rectangle "Pod D" as podd
}
}
}
api --> etcd
api --> sched
api --> ctrl
api --> kube1
api --> kube2
sched --> kube1
sched --> kube2
@enduml
上圖展示了 Kubernetes 叢集的基本架構。控制平面包含 API Server、etcd、Scheduler 和 Controller Manager，負責整個叢集的管理和協調。工作節點執行 kubelet 和實際的應用程式 Pod，透過 API Server 接收指令並回報狀態。
Podman 無守護程序容器技術
Podman 是 Red Hat 開發的容器管理工具，其最大特點是採用無守護程序架構。與 Docker 不同，Podman 不需要在背景執行一個長期運行的守護程序，每個 Podman 命令都是一個獨立的程序，直接與容器執行時互動。這種架構消除了單點故障的風險，提高了系統的穩定性和安全性。
Podman 的命令列介面與 Docker 高度相容，大多數 Docker 命令可以直接替換為 Podman 命令而無需修改。這種相容性讓 Docker 使用者可以輕鬆地遷移到 Podman，而不需要學習全新的工具。Podman 同時支援 OCI 映像檔格式和 Docker 映像檔格式，可以直接使用來自 Docker Hub 的映像檔。
無根容器是 Podman 的另一個重要特性，它允許普通使用者在沒有 root 權限的情況下執行容器。無根模式利用使用者命名空間技術，將容器內的 root 使用者對應到主機上的普通使用者，大幅降低了容器逃逸攻擊的風險。這對於多租戶環境和需要嚴格安全控制的場景特別有價值。
Podman 原生支援 Pod 的概念，這與 Kubernetes 的 Pod 模型相同。一個 Pod 可以包含多個容器，它們共享網路命名空間和儲存卷。這讓開發者可以在本地環境中測試 Pod 組態，然後直接部署到 Kubernetes 叢集。Podman 甚至可以直接從 Pod 定義生成 Kubernetes YAML 組態，或從 Kubernetes YAML 建立本地 Pod。
Buildah 和 Skopeo 是與 Podman 搭配使用的重要工具。Buildah 專注於建構容器映像檔，它提供了更細粒度的控制，允許逐步建構映像檔而不需要完整的 Dockerfile。Skopeo 則專注於映像檔的複製和檢查，可以在不同的映像檔倉庫之間複製映像檔，而不需要先拉取到本地。這些工具共同構成了一個完整的無守護程序容器工具鏈。
容器網路與 CNI 深度解析
容器網路是容器技術中最複雜的領域之一，它需要解決容器之間、容器與主機之間、以及跨主機容器之間的通訊問題。CNI 是 Cloud Native Computing Foundation 定義的容器網路介面標準，它為容器執行時和網路外掛之間提供了統一的介面。
CNI 外掛負責在容器啟動時組態網路，在容器停止時清理網路資源。一個基本的 CNI 組態包括網路類型、IP 地址管理方式和可選的連鎖外掛。網路類型決定了容器網路的實現方式，常見的類型包括 bridge、macvlan、ipvlan 和 veth pair。IP 地址管理可以使用靜態分配或動態分配，常見的 IPAM 外掛包括 host-local 和 dhcp。
在 Kubernetes 環境中，CNI 外掛不僅負責基本的網路連接，還需要實現網路策略。網路策略是 Kubernetes 的原生資源，用於控制 Pod 之間的網路流量。透過網路策略，可以實現微分段，只允許必要的通訊，拒絕所有其他流量。Calico 和 Cilium 都提供了豐富的網路策略功能，支援基於標籤、命名空間和 CIDR 的規則。
服務網格是容器網路的進階應用，它在應用程式層面提供了流量管理、安全通訊和可觀測性功能。Istio 和 Linkerd 是兩個流行的服務網格實現，它們透過 sidecar 容器攔截應用程式的網路流量，提供透明的功能增強。服務網格可以實現細粒度的流量控制，例如金絲雀部署、A/B 測試和故障注入，而不需要修改應用程式程式碼。
容器安全最佳實踐
容器安全是一個多層次的課題，需要從映像檔安全、執行時安全、網路安全和主機安全等多個維度進行防護。由於容器共享主機核心，一個有漏洞的容器可能危及整個系統，因此容器安全需要特別重視。
映像檔安全是容器安全的起點。使用可信的基礎映像檔、定期更新映像檔、最小化映像檔內容都是基本的安全實踐。映像檔掃描工具可以檢測映像檔中的已知漏洞，Trivy、Clair 和 Snyk 都是常用的掃描工具。映像檔簽章和驗證可以確保映像檔的完整性和來源可信度，Notary 和 Cosign 提供了映像檔簽章的功能。
執行時安全涉及容器執行過程中的安全控制。Linux 核心提供了多種安全機制來限制容器的能力，包括 capabilities、seccomp 和 Linux Security Modules。Capabilities 將傳統的 root 權限拆分為細粒度的能力，容器只需要被授予必要的能力。Seccomp 過濾器可以限制容器可以呼叫的系統呼叫，減少攻擊面。SELinux 和 AppArmor 是兩種 LSM 實現，它們提供了強制存取控制，即使程序以 root 身份執行也受到限制。
網路安全方面，除了前面提到的網路策略，還需要考慮加密通訊和網路隔離。服務網格提供的 mTLS 可以實現服務之間的加密通訊，防止竊聽和中間人攻擊。網路隔離可以透過 VLAN、VXLAN 或其他網路虛擬化技術實現，確保不同租戶或敏感度等級的工作負載在網路層面隔離。
監控和稽核是容器安全的重要組成部分。Falco 是一個雲原生的執行時安全工具，它使用 eBPF 技術監控系統呼叫，檢測異常行為。Kubernetes 的稽核日誌記錄了所有對 API Server 的請求，可以用於事後分析和合規性稽核。建立完善的監控和告警機制，可以及時發現和響應安全事件。
容器技術已經成為現代軟體開發和運維的基礎設施，它帶來的效率提升和靈活性是顯而易見的。然而，正確使用容器技術需要深入理解其底層原理和最佳實踐。從 Linux 命名空間和控制群組等隔離機制，到 Docker、Kubernetes 和 Podman 等容器平台，再到 CNI 網路組態和安全強化，每個領域都有豐富的技術細節需要掌握。隨著容器技術的持續發展，新的挑戰和機會也不斷湧現。邊緣運算、無伺服器架構和 WebAssembly 等新興技術正在擴展容器的應用場景。保持學習和實踐，才能在這個快速變化的領域中保持競爭力。