【云原生--Kubernetes】Pod容器与镜像拉取策略

原创

已于 2022-08-05 03:28:43 修改 · 2.5k 阅读

1 ·

CC 4.0 BY-SA版权

文章标签：

#kubernetes #云原生 #docker

于 2022-08-02 20:46:22 首次发布

本文介绍了Kubernetes Pod中的不同容器类型，包括基础容器、初始化容器和应用容器，强调了初始化容器在应用启动前的作用。同时，详细讨论了镜像拉取策略，如Always、IfNotPresent和Never，并通过实例展示了如何配置和使用这些策略。最后，提到了私有仓库部署，特别是使用Harbor的情况。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

前言：pod作为k8s最小资源单位，对于pod的管理也将尤为重要，本文将详细介绍pod

一. Pod容器的分类

1.1 基础容器（infrastructure container）

维护整个 Pod 网络和存储空间
node 节点中操作
启动一个容器时，k8s会自动启动一个基础容器

1.2 初始化容器（initcontainer）

Init 容器必须在应用程序容器启动之前运行完成，而应用程序容器是并行运行的，所以 Init 容器能够提供了一种简单的阻塞或延迟应用容器的启动的方法。Init 容器与普通的容器非常像，除了以下两点：

init 容器总是运行到成功完成为止
每个 Init 容器都必须在下一个 Init 容器启动之前成功完成启动和退出
如果 Pod 的 init 容器失败，k8s 会不断地重启该 Pod，直到 Init 容器成功为止。然而，如果 Pod 对应的重启策略（restartPolicy）为 Never，它不会重新启动。

init 的容器作用
因为 init 容器具有与应用容器分离的单独镜像，其启动相关代码具有如下优势：

Init 容器可以包含一些安装过程中应用容器中不存在的实用工具或个性化代码。例如，没有必要仅为了在安装过程中使用类似 sed、 awk、python 或 dig 这样的工具而去 FROM 一个镜像来生成一个新的镜像。
Init 容器可以安全地运行这些工具，避免这些工具导致应用镜像的安全性降低。
应用镜像的创建者和部署者可以各自独立工作，而没有必要联合构建一个单独的应用镜像。
Init 容器能以不同于 Pod 内应用容器的文件系统视图运行。因此，Init 容器可具有访问 Secrets的权限，而应用容器不能够访问。
由于 Init 容器必须在应用容器启动之前运行完成，因此 Init容器提供了一种机制来阻塞或延迟应用容器的启动，直到满足了一组先决条件。一旦前置条件满足，Pod 内的所有的应用容器会并行启动。

1.3 应用容器（main container）

应用容器会在 init 容器完成并退出后并行启动。

1.4 操作示例

参考官网：init容器说明
下面的例子定义了一个具有 2 个 Init 容器的简单 Pod。第一个等待 myservice 启动，第二个等待 mydb 启动。一旦这两个 Init容器都启动完成，Pod 将启动 spec 节中的应用容器。

编写yaml

apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
  labels:
    app: 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;do echo waiting for myservice; sleep2; done;']
  - name: init-mydb
    image: busybox:1.28
    command: ['sh','-c',