k8s中pod内部容器详解

原创已于 2025-08-02 15:12:44 修改 · 709 阅读

8 ·

CC 4.0 BY-SA版权

文章标签：

#kubernetes #容器 #云原生

于 2025-07-29 00:47:07 首次发布

k8s 专栏收录该内容

2 篇文章

订阅专栏

Pod内的容器分类

pause 基础设施容器

在创建pod时最先创建的容器，创建并维护命名空间，共享网络与存储
在这里插入图片描述

功能与作用

共享网络与存储命名空间：Pause 容器是 Pod 的基础，同一 Pod 内的其他容器会和它共享网络、存储等命名空间，这样容器间就能通过localhost直接通信。
维持 Pod 生命周期：Pause 容器的状态决定了 Pod 的状态。即便业务容器停止运行，只要 Pause 容器还在运行，Pod 就不会终止。
IP 分配：每个 Pod 会被分配唯一的 IP 地址，Pause 容器负责持有这个 IP，为 Pod 内的其他容器提供网络环境。

pause容器是一个很好的获取监控状态和提供运行环境的一个功能性容器

init 初始化容器

执行一些前期启动/初始化的工作（比如数据库增删改查需要先建立数据库连接），pod内的容器启动具有先后顺序，init容器是最先启动的容器，往往是下一个容器启动的必要条件。

这里带有启动顺序的理念与k8s的StatefulSet资源类型比较相似，但是StatefulSet资源没有依赖条件，不过具有顺序。
在这里插入图片描述

功能与作用

预处理任务：Init 容器会在主容器启动之前按顺序执行，用于完成一些初始化工作，比如环境检查、依赖下载等。
保证应用顺序启动：可以把复杂的启动流程拆分成多个步骤，确保在主容器启动前所有先决条件都已满足。能够通过每一步的结果很清楚的知道每一步执行的状态。
安全隔离：Init 容器使用的镜像可以和主容器不同，这样能避免将不必要的工具安装到主容器中，增强安全性。

实验验证

下面的yaml文件定义了一个具有 2 个 Init 容器的简单 Pod。第一个等待 myservice启动，第二个等待 mydb启动。一旦这两个 Init 容器都启动完成，Pod 将启动spec节中的应用容器。

apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
  labels:
    app.kubernetes.io/name: 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"]

如果存在init容器，最直观能够看到效果的就是在启动初期会出现init状态
在这里插入图片描述

sidecar 边车容器（寄生虫）

边车容器其实是init容器的一个特例：特别之处在于init容器一般执行完之后不会继续存在，而边车容器在初始化之后，还会和主容器一起运行（由restartPolicy: Always这个字段来实现运行自由化）
是一种在pod中与主容器相互依存共享资源的容器，作用采集主容器的日志，提供功能性作用

如下图主要有两个功能型的应用：一个是提供web服务的应用，一个是负责拉取日志的应用（日志拉取依赖于web服务）。此 Pod 使用临时 emptyDir 卷作为容器之间的共享存储。

在这里插入图片描述

功能与作用

增强主容器功能：Sidecar 容器和主容器协同工作，为主容器提供额外的功能，像日志收集、监控数据采集等。
解耦关注点：把非核心功能（如日志处理、服务发现）从主容器中分离出来，降低主容器的复杂度。

实验案例

下面是一个包含两个容器的 Deployment 示例，其中一个容器是边车形式：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
  labels:
    app: myapp
spec:
  replicas: 1
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
        - name: myapp
          image: alpine:latest
          command: ['sh', '-c', 'while true; do echo "logging" >> /opt/logs.txt; sleep 1; done']
          volumeMounts:
            - name: data
              mountPath: /opt
      initContainers:
        - name: logshipper
          image: alpine:latest
          restartPolicy: Always
          command: ['sh', '-c', 'tail -F /opt/logs.txt']
          volumeMounts:
            - name: data
              mountPath: /opt
      volumes:
        - name: data
          emptyDir: {}