K8S-特殊容器

Init初始化容器

Init容器与普通容器区别

Init容器在Pod内先于应用容器启动，并按照定义顺序执行。普通容器并行启动，而Init容器必须成功完成才能启动后续容器。Init容器通常用于准备环境（如下载配置、等待依赖服务），不提供长期服务。

Init容器的优势

• 隔离性：初始化逻辑与应用逻辑分离，避免污染主容器镜像。
• 顺序控制：确保前置条件（如数据库就绪）满足后再启动应用。
• 资源复用：多个Pod可共享相同的初始化步骤，减少主镜像体积。

Init容器应用场景

• 配置文件生成或下载（如从ConfigMap或远程存储加载）。
• 依赖服务等待（如数据库迁移完成）。
• 安全校验（如密钥注入或权限检查）。

Init容器使用案例

apiVersion: v1
kind: Pod
metadata:
  name: init-demo
spec:
  initContainers:
  - name: init-config
    image: busybox
    command: ['sh', '-c', 'echo "Config initialized" > /tmp/config']
  containers:
  - name: app
    image: nginx
    volumeMounts:
    - name: config-volume
      mountPath: /etc/nginx
  volumes:
  - name: config-volume
    emptyDir: {}

Init初始化容器说明

• 若Init容器失败，Pod会根据restartPolicy重试（通常为Always或OnFailure）。
• 资源请求/限制需单独定义，不共享应用容器的配置。

---

临时容器（Ephemeral Containers）

概述

临时容器是动态注入到运行中Pod的容器，用于调试或诊断，不参与Pod的原生生命周期管理。

用途

• 调试：排查运行中容器的网络、文件系统问题。
• 诊断工具注入 ：临时添加工具链（如curl、tcpdump）而不修改原有镜像。

开启特性支持临时容器

Kubernetes 1.16+需启用EphemeralContainers特性门控。在kube-apiserver配置中添加：

--feature-gates=EphemeralContainers=true  

使用临时容器

通过kubectl debug命令添加临时容器：

kubectl debug -it <pod-name> --image=busybox --target=<target-container>

示例YAML手动注入：

ephemeralContainers:
- name: debugger
  image: busybox
  command: ["sh"]
  tty: true

注意：

• 临时容器修改需通过API直接提交，不可通过kubectl edit。
• 资源限制与普通容器相同，但生命周期独立。

Init 初始化容器概述

Init Container 用于在 Pod 主容器启动前执行初始化任务，支持多个容器按顺序执行。所有 Init Container 成功完成后，主容器才会启动。Init Container 与主容器共享数据卷和网络命名空间，产生的数据可被主容器使用。

Init Container 独立于主容器的生命周期，不同于 PreStart 钩子函数。每个 Pod 包含一个 pause-amd64 镜像（infra 容器），用于共享网络命名空间。若该镜像未拉取，可能导致 Pod 启动失败。

Init 容器与普通容器的区别

• Init 容器必须运行到成功为止。
• 每个 Init 容器必须在下一个 Init 容器启动前完成。
• 若 Init 容器失败且 Pod 的 restartPolicy 不为 Never，Kubernetes 会不断重启 Pod。

Init 容器的优势

• 可包含实用工具，避免将这些工具打包到主容器镜像中。
• 支持定制化安装逻辑（如使用 sed、awk 等工具）。
• 分离应用程序镜像的构建和部署职责。
• 具有独立的文件系统视图，可访问主容器无法访问的 Secret。
• 提供阻塞主容器启动的机制，确保依赖条件满足。

Init 容器的应用场景

• 服务依赖检查：例如等待数据库服务就绪后再启动 Web 服务。
• 初始化配置：为主容器准备集群配置信息。
• 注册与配置：将 Pod 注册到中央数据库或配置中心。

---

Init 容器使用案例

以下示例定义了一个包含两个 Init 容器的 Pod，分别检查 myservice 和 mysql 服务是否可用：

apiVersion: v1
kind: Pod
metadata:
  name: init-demo
  labels:
    demo: init-demo
spec:
  containers:
  - name: init-demo
    image: busybox
    command: ['sh', '-c', 'echo The app is running! && sleep 3600']
  initContainers:
  - name: init-demo1
    image: busybox
    command: ['sh', '-c', 'until nslookup myservice; do echo waiting for myservice;sleep 2; done;']
  - name: init-demo2
    image: busybox
    command: ['sh', '-c', 'until nslookup mysql; do echo waiting for mysql; sleep 2;done;']
---
apiVersion: v1
kind: Service
metadata:
  name: myservice
spec:
  ports:
  - port: 5566
    targetPort: 6655
    protocol: TCP
---
apiVersion: v1
kind: Service
metadata:
  name: mysql
spec:
  ports:
  - port: 8899
    targetPort: 9988
    protocol: TCP

验证步骤

1. 创建 Pod 后，状态为 Init:0/2，表示 Init 容器未完成。
2. 创建 myservice 和 mysql 服务后，Init 容器成功，主容器启动。
3. 通过 kubectl logs 查看主容器日志。

---

Init 容器注意事项

• Init 容器按顺序执行，必须全部成功退出后主容器才会启动。
• 若 Init 容器失败且 restartPolicy 为 Always，Pod 会重启。
• Pod 未就绪时状态为 Pending，并标记 Initializing 为 true。
• 修改 Init 容器仅允许更改 image 字段，其他修改需重启 Pod。
• Init 容器不支持 readinessProbe，仅依赖完成状态。
• 容器名称在 Pod 内必须唯一。

---

临时容器（Ephemeral Containers）

临时容器用于调试场景，不具备资源保障且不会自动重启。与常规容器不同，临时容器不支持以下配置：

• 端口配置（如 ports、livenessProbe）。
• 资源分配（如 resources）。

临时容器通过 ephemeralcontainers API 创建，无法通过 kubectl edit 直接添加。

用途

• 故障排查：当主容器崩溃或镜像不包含调试工具时（如 Distroless 镜像），临时容器提供交互式调试环境。
• 进程查看：启用进程命名空间共享后，可查看其他容器中的进程。

Distroless 镜像

Distroless 镜像是极简化的容器镜像，不包含 Shell 或调试工具，以减少攻击面和漏洞暴露。临时容器弥补了此类镜像的调试短板。

---

总结

• Init 容器：确保依赖条件和初始化任务完成后再启动主容器。
• 临时容器：提供轻量级调试能力，适用于生产环境故障排查。

Init Container 概述

Init Container 是 Kubernetes 中用于执行初始化任务的容器，可以包含一个或多个。多个 Init Container 会按照定义的顺序依次执行，所有 Init Container 成功完成后，主容器才会启动。Pod 内的所有容器共享数据卷和网络命名空间，因此 Init Container 生成的数据可供主容器使用。

Init Container 与钩子函数的区别

Init Container 和钩子函数（如 PreStart）在功能上看似相似，但处于不同的阶段：

• Init Container：在 Pod 启动流程中独立运行，完成后再启动主容器。
• 钩子函数：在主容器的生命周期内触发（如启动前或停止前），属于主容器的一部分。

典型使用场景

• 等待依赖服务就绪（如数据库或 API）。
• 从远程存储下载配置文件或密钥。
• 修改文件系统权限或初始化数据目录。

示例配置片段

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  initContainers:
  - name: init-service
    image: busybox
    command: ['sh', '-c', 'until nslookup myservice; do echo waiting; sleep 2; done']
  containers:
  - name: main-container
    image: nginx

注意事项

• 若任何 Init Container 失败，Pod 会按 RestartPolicy 重启（默认 Always 会重启）。
• Init Container 的资源限制需单独声明，不共享主容器的配额。
• 调试时可查看 Pod 事件或使用 kubectl logs -c <init-container-name> 检查日志。

Pod生命周期示意图解析

Kubernetes Pod的生命周期包含多个阶段和组件，以下是关键元素及其时间线（以秒为单位）的示意图解析：

核心阶段与组件

• Init Containers（初始化容器）：在Pod启动时运行，按顺序执行，必须全部成功完成后才会启动主容器。示例中编号3、4、6、8可能对应不同初始化任务。
• Main Container（主容器）：编号2、5、7、11、12、13、14、15代表主容器的启动与运行过程。
• Readiness Probe（就绪探针）：检查容器是否准备好接收流量，未通过时Pod不会加入Service的负载均衡。
• Liveness Probe（存活探针）：检测容器是否健康，失败时会重启容器。

Hook与探针时间线

• Post-start Hook：容器启动后立即执行的操作（如配置加载），可能在编号2之后触发。
• Pre-stop Hook：容器终止前执行的清理操作（如优雅关闭连接），通常在终止信号发出后运行。
• 探针周期：Readiness和Liveness探针会周期性运行（如间隔10秒），图中未明确标注周期但贯穿运行阶段。

典型时间线示例

0s-3s: Init Container 1 (编号3)
3s-4s: Init Container 2 (编号4)
6s-8s: Init Container 3 (编号6、8)
8s-9s: Main Container启动 (编号2)
9s-12s: Post-start Hook完成
12s+: 周期性探针检查（Readiness/Liveness）
终止时: Pre-stop Hook (编号15)

生命周期管理建议

配置探针优化可用性

• Liveness Probe应设置合理的initialDelaySeconds，避免过早判定失败。
• Readiness Probe的failureThreshold需根据应用启动时间调整。

Hook的使用场景

• Post-start Hook适合资源初始化，但需注意超时设置（默认无超时）。
• Pre-stop Hook结合terminationGracePeriodSeconds实现优雅停止。

Init容器设计原则

• 每个Init容器应聚焦单一任务（如下载配置、等待依赖服务）。
• 资源限制需单独配置，避免影响主容器调度。

通过合理配置这些组件，可以确保Pod从启动到终止的完整生命周期稳定可控。

Pod 生命周期组件关系

PostStart、PreStop、Liveness 和 Readiness 属于主容器的生命周期钩子，这些钩子直接与主容器的运行状态相关联。Init Container 虽然属于 Pod 的一部分，但其执行独立于主容器，通常用于完成主容器启动前的预处理任务。

Infra 容器的作用

每个 Pod 在底层会默认运行一个 pause-amd64 镜像（或其他架构版本的 pause 镜像），该容器作为 Pod 的基础设施容器（Infra Container），主要职责是维护 Pod 级别的共享资源：

• 提供共享的网络命名空间，确保 Pod 内所有容器使用相同的网络栈（IP、端口范围等）。
• 充当 Pod 内其他容器的父进程，管理僵尸进程回收。

常见问题与解决方案

Infra 镜像拉取失败会导致 Pod 启动异常，解决方法包括：

• 手动预拉取镜像到节点：docker pull k8s.gcr.io/pause-amd64:版本号（或根据集群实际使用的镜像仓库调整路径）。
• 配置集群的镜像拉取策略，确保节点能访问镜像仓库。
• 检查节点网络或镜像仓库认证配置，排除拉取障碍。

组件层级示意图

Pod 生命周期
├── Infra 容器（pause-amd64）
├── Init Containers（独立执行）
└── 主容器
    ├── PostStart（启动后钩子）
    ├── PreStop（终止前钩子）
    ├── Liveness Probe（存活探测）
    └── Readiness Probe（就绪探测）

Init容器与普通容器的核心区别

运行机制差异

Init容器必须顺序执行且成功退出后才会启动下一个Init容器或主容器。普通容器默认并行启动，无强制顺序依赖。

生命周期控制

Init容器失败时会触发Pod重启（restartPolicy≠Never时），而普通容器失败则根据Pod的重启策略独立处理。

Init容器的核心优势

安全隔离

通过Linux Namespace实现文件系统隔离，使得Init容器可访问敏感数据（如Secret），而主容器无法直接获取。

工具解耦

允许使用sed/awk/python等工具完成初始化操作，避免将这些工具打包进主容器镜像，减小镜像体积并提升安全性。

职责分离

构建阶段与运行时环境分离，例如通过Init容器动态生成配置文件，主容器只需关注业务逻辑。

典型应用场景实现方案

服务依赖检查

通过Init容器循环检测数据库服务可达性，使用以下命令模板实现：

until nc -z db-service 3306; do echo "waiting for db"; sleep 2; done

动态配置生成

在Init容器中通过API获取集群节点信息并生成配置文件：

kubectl get nodes -o json > /etc/cluster/nodes.json

注册中心交互

Init容器完成服务注册后再启动主服务：

curl -X POST registry-service/register --data 'pod_ip=${POD_IP}'

关键设计约束

资源限制

需单独为Init容器设置resources字段，其资源配额不计入主容器配额，但总和受Pod上限约束。

探针配置

Init容器不支持readiness/liveness探针，其成功标准仅为exitCode=0。

调试建议

查看Init容器日志使用命令：

kubectl logs <pod-name> -c <init-container-name>

2、Init容器使用案例

[root@k8s-master01 ~]# cat init-test.yaml
apiVersion: v1
kind: Pod
metadata:
  name: init-demo
  labels:
    demo: init-demo
spec:
  containers:
  - name: init-demo
    image: busybox
    command: ['sh', '-c', 'echo The app is running! && sleep 3600']
  initContainers:
  - name: init-demo1
    image: busybox
    command: ['sh', '-c', 'until nslookup myservice; do echo waiting for myservice;sleep 2; done;']
  - name: init-demo2
    image: busybox
    command: ['sh', '-c', 'until nslookup mysql; do echo waiting for mysql; sleep 2;done;']
---
apiVersion: v1
kind: Service
metadata:
  name: myservice
spec:
  ports:
  - port: 5566
    targetPort: 6655
    protocol: TCP
---
apiVersion: v1
kind: Service
metadata:
  name: mysql
spec:
  ports:
  - port: 8899
    targetPort: 9988
    protocol: TCP
##验证
[root@k8s-master01 ~]# kubectl  get pods
NAME                                      READY   STATUS      RESTARTS   AGE
init-demo                                 0/1     Init:0/2    0          6s

[root@k8s-master01 ~]# kubectl get pods
NAME                                      READY   STATUS      RESTARTS   AGE
init-demo                                 1/1     Running     0          4m24s

[root@k8s-master01 ~]# kubectl get service
NAME         TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)        AGE
kubernetes   ClusterIP   10.10.0.1        <none>        443/TCP        13m
myservice    ClusterIP   10.10.202.229   <none>        5566/TCP        40s
mysql        ClusterIP   10.10.222.227   <none>        8899/TCP        39s

[root@k8s-master01 ~]# kubectl  logs init-demo

Init容器核心特性说明

启动顺序与依赖关系

Init容器在Pod启动时严格按照顺序执行，仅当网络和数据卷初始化完成后才会启动。前一个Init容器必须成功退出（exit code 0）才会触发下一个容器的启动。若任意Init容器因运行时错误或非零退出码失败，整个Pod将根据restartPolicy决定是否重试。

状态控制与Pod生命周期

Pod的Ready状态与Init容器强关联。所有Init容器未全部成功前，Pod状态保持为Pending且标记Initializing: true。Init容器的端口不会被Service聚合。若Pod发生重启（如手动删除重建或镜像更新），所有Init容器需重新执行。

字段修改限制与唯一性约束

仅允许修改Init容器的image字段，其他字段变更无效。修改image会触发Pod重启。Init容器不支持配置readinessProbe，因其状态仅由完成（completion）决定。Pod内所有容器（包括应用容器和Init容器）的名称必须唯一，重复名称会导致验证错误。

重启策略交互

当Pod的restartPolicy设置为Always时，Init容器失败会遵循该策略进行重试。但需注意：Init容器的重试行为独立于应用容器的重启逻辑。

临时容器 Ephemeral Containers 概述

临时容器是一种特殊类型的容器，与常规容器相比，它们在资源分配和执行保证方面存在显著差异。临时容器不具备自动重启功能，因此不适合用于构建应用程序。它们的配置方式与常规容器类似，但某些字段被限制使用。

临时容器通过 Kubernetes API 中的 ephemeralcontainers 处理器创建，而非直接修改 pod.spec。这意味着无法通过 kubectl edit 命令直接添加临时容器。一旦临时容器被添加到 Pod 中，就无法修改或删除。

临时容器的限制

临时容器的配置受到以下限制：

• 端口配置 ：ports、livenessProbe、readinessProbe 等字段不允许使用。
• 资源分配 ：由于 Pod 资源分配不可变，resources 配置字段被禁用。

临时容器的用途

临时容器主要用于故障排查和调试场景：

• 交互式故障排查：当容器崩溃或容器镜像中缺少调试工具时，临时容器提供了一种有效的调试手段。
• Distroless 镜像支持：Distroless 镜像以轻量化和安全性著称，但通常不包含 Shell 或其他调试工具，临时容器可以弥补这一缺陷。
• 进程名字空间共享：启用进程名字空间共享可以查看其他容器中的进程，便于调试和分析。

Distroless 镜像简介

Distroless 镜像是一种轻量化的容器镜像，专注于减少攻击面和资源占用。它移除了不必要的工具和组件，仅包含应用程序运行所需的最小依赖项。

Distroless 镜像的特点

• 轻量化：移除默认工具和组件，显著减小存储空间和资源占用。
• 易于部署：支持多种平台，包括云端、本地和容器环境。
• 高效能：使用原生 Kubernetes API 进行管理，优化资源利用率。
• 安全性：提供自动更新、补丁和安全策略，增强系统安全性。

Distroless 镜像的适用场景

Distroless 镜像适合需要高安全性和轻量化部署的用户。它特别适用于那些不希望安装大量默认工具但仍需 Kubernetes 容器编排功能的场景。

临时容器 Ephemeral Containers 概述

临时容器是一种特殊类型的容器，与常规容器相比，它们在资源分配和执行保证方面存在显著差异。临时容器不具备自动重启功能，因此不适合用于构建应用程序。它们的配置方式与常规容器类似，但某些字段被限制使用。

临时容器通过 Kubernetes API 中的 ephemeralcontainers 处理器创建，而非直接修改 pod.spec。这意味着无法通过 kubectl edit 命令直接添加临时容器。一旦临时容器被添加到 Pod 中，就无法修改或删除。

临时容器的限制

临时容器的配置受到以下限制：

• 端口配置 ：ports、livenessProbe、readinessProbe 等字段不允许使用。
• 资源分配 ：由于 Pod 资源分配不可变，resources 配置字段被禁用。

临时容器的用途

临时容器主要用于故障排查和调试场景：

• 交互式故障排查：当容器崩溃或容器镜像中缺少调试工具时，临时容器提供了一种有效的调试手段。
• Distroless 镜像支持：Distroless 镜像以轻量化和安全性著称，但通常不包含 Shell 或其他调试工具，临时容器可以弥补这一缺陷。
• 进程名字空间共享：启用进程名字空间共享可以查看其他容器中的进程，便于调试和分析。

Distroless 镜像简介

Distroless 镜像是一种轻量化的容器镜像，专注于减少攻击面和资源占用。它移除了不必要的工具和组件，仅包含应用程序运行所需的最小依赖项。

Distroless 镜像的特点

• 轻量化：移除默认工具和组件，显著减小存储空间和资源占用。
• 易于部署：支持多种平台，包括云端、本地和容器环境。
• 高效能：使用原生 Kubernetes API 进行管理，优化资源利用率。
• 安全性：提供自动更新、补丁和安全策略，增强系统安全性。

Distroless 镜像的适用场景

Distroless 镜像适合需要高安全性和轻量化部署的用户。它特别适用于那些不希望安装大量默认工具但仍需 Kubernetes 容器编排功能的场景。

1.2、开启特性支持临时容器

#1. master 节点配置 APIServer 组件
[root@k8s-master01 ~]# cat /etc/kubernetes/manifests/kube-apiserver.yaml
- --feature-gates=EphemeralContainers=true
...

#2. master 节点配置 controller-manager
[root@k8s-master01 ~]# vim /etc/kubernetes/manifests/kube-controller-manager.yaml
spec:
  containers:
  - command:
    - --feature-gates=EphemeralContainers=true            # 增加
...

#3. master 节点配置 kube-scheduler
[root@k8s-master01 ~]# vim /etc/kubernetes/manifests/kube-scheduler.yaml
spec:
  containers:
  - command:
    - --feature-gates=EphemeralContainers=true            # 增加
# 重启服务 
[root@k8s-master01 ~]# systemctl restart kubelet.service

#4. 所有 node 节点配置 kubelet 参数
#添加 --feature-gates=EphemeralContainers=true
[root@k8s-worker01 kubernetes]# cat /var/lib/kubelet/kubeadm-flags.env
KUBELET_KUBEADM_ARGS="--network-plugin=cni --pod-infra-container-image=registry.aliyuncs.com/google_containers/pause:3.6 --feature-gates=EphemeralContainers=true"
# 重启 node kubelet 服务
[root@k8s-worker01 kubernetes]# systemctl daemon-reload
[root@k8s-worker01 kubernetes]# systemctl restart kubelet

2、使用临时容器 创建一个部署tomcat的pod

[root@k8s-master01 ~]# cat pod-tomcat.yaml
apiVersion: v1
kind: Pod
metadata:
  name: tomcat-test
  namespace: default
  labels:
    app:  tomcat
spec:
  containers:
  - name:  tomcat-java
    ports:
    - containerPort: 8080
    image: xianchao/tomcat-8.5-jre8:v1
    imagePullPolicy: IfNotPresent
##提交
[root@k8s-master01 ~]# kubectl apply -f pod-tomcat.yaml
##查看
[root@k8s-master01 ~]# kubectl get pod pod-tomcat.yaml

创建临时容器

[root@k8s-master01 ~]# kubectl debug -it tomcat-test--image=busybox:1.28 --target=tomcat-java
Defaulting debug container name to debugger-6m2s8.
If you don't see a command prompt, try pressing enter.
/ #ps -ef | grep tomcat

查看tomcat-test这个pod是否已经有临时容器

root@k8s-master01 \~# kubectl describe pods tomcat-test

运维的核心职责

运维（Operations and Maintenance，简称 Ops）的核心目标是保障系统稳定性、安全性和高效性，具体职责包括：

• 系统监控：实时跟踪服务器、网络、应用等资源状态，及时发现异常。
• 故障处理：快速响应并解决系统故障，减少停机时间。
• 自动化运维：通过脚本或工具（如 Ansible、SaltStack）实现重复任务自动化。
• 安全管理：定期更新补丁、配置防火墙、防御网络攻击。
• 性能优化：分析系统瓶颈，调整配置以提升效率。

常见运维工具与技术

• 监控工具：Prometheus、Zabbix、Grafana（可视化监控数据）。
• 日志管理：ELK Stack（Elasticsearch、Logstash、Kibana）集中分析日志。
• 容器化：Docker 和 Kubernetes 实现应用快速部署与扩展。
• 版本控制：Git 管理配置文件和脚本，确保变更可追溯。

自动化运维实践

自动化是提升效率的关键，典型场景包括：

• 使用 Shell/Python 脚本批量部署服务。
• 通过 CI/CD 管道（如 Jenkins、GitLab CI）实现持续集成与交付。
• 基础设施即代码（IaC）工具（Terraform、AWS CloudFormation）管理云资源。

安全与备份策略

• 定期备份：使用 rsync 或 BorgBackup 实现数据冗余。
• 访问控制：基于 RBAC（基于角色的访问控制）限制权限。
• 灾难恢复：制定应急预案，测试备份恢复流程。

性能调优方法

• 数据库优化 ：索引优化、查询缓存（如 MySQL 的 query_cache_size）。
• 网络调优 ：调整 TCP 参数（如 net.ipv4.tcp_tw_reuse）。
• 资源限制：使用 cgroups 或 systemd 限制进程资源占用。

云计算与运维

云平台（AWS、Azure、阿里云）提供托管服务降低运维复杂度：

• 利用云监控服务（如 CloudWatch）替代自建监控系统。
• 通过 Auto Scaling 自动调整实例数量应对流量波动。

运维发展趋势

• AIOps：结合人工智能分析日志和预测故障。
• DevOps 融合：开发与运维协作，加速交付周期。
• Serverless：聚焦业务逻辑，无需管理底层基础设施。

运维需持续学习新技术，平衡自动化与人工干预，确保系统高可用。