POD的基础概念

目录

一、什么是pod

二、pod中的容器

三、pod中的镜像拉取策略与重启策略

1.拉取策略（Image Pull Policy）

2.重启策略（Restart Policy）

四、实验案例

1.拉取策略

2.重启策略

---

一、什么是pod

        Pod是kubernetes中最小的资源管理组件，Pod也是最小化运行容器化应用的资源对象。一个Pod代表着集群中运行的一个进程。kubernetes中其他大多数组件都是围绕着Pod来进行支撑和扩展Pod功能的，例如，用于管理Pod运行的StatefulSet和Deployment等控制器对象，用于暴露Pod应用的Service和Ingress对象，为Pod提供存储的PersistentVolume存储资源对象等。

pod有两种使用方式：

一个Pod中运行一个容器。“每个Pod中一个容器”的模式是最常见的用法；在这种使用方式中，你可以把Pod想象成是单个容器的封装，kuberentes管理的是Pod而不是直接管理容器。

在一个Pod中同时运行多个容器。一个Pod中也可以同时封装几个需要紧密耦合互相协作的容器，它们之间共享资源。这些在同一个Pod中的容器可以互相协作成为一个service单位，比如一个容器共享文件，另一个“sidecar”容器来更新这些文件。Pod将这些容器的存储资源作为一个实体来管理。

一个Pod下的容器必须运行于同一节点上。现代容器技术建议一个容器只运行一个进程，该进程在容器中PID命令空间中的进程号为1，可直接接收并处理信号，进程终止时容器生命周期也就结束了。若想在容器内运行多个进程，需要有一个类似Linux操作系统init进程的管控类进程，以树状结构完成多进程的生命周期管理。运行于各自容器内的进程无法直接完成网络通信，这是由于容器间的隔离机制导致，k8s中的Pod资源抽象正是解决此类问题，Pod对象是一组容器的集合，这些容器共享Network、UTS及IPC命令空间，因此具有相同的域名、主机名和网络接口，并可通过IPC直接通信。

pause容器使得Pod中的所有容器可以共享两种资源：网络和存储。
网络：
每个Pod都会被分配一个唯一的IP地址。Pod中的所有容器共享网络空间，包括IP地址和端口。Pod内部的容器可以使用localhost互相通信。Pod中的容器与外界通信时，必须分配共享网络资源（例如使用宿主机的端口映射）。

存储：
Pod可以指定多个共享的Volume。Pod中的所有容器都可以访问共享的Volume。Volume也可以用来持久化Pod中的存储资源，以防容器重启后文件丢失。

二、pod中的容器

1、基础容器（infrastructure container）
//维护整个 Pod 网络和存储空间
//node 节点中操作
//启动一个Pod时，k8s会自动启动一个基础容器
cat /opt/kubernetes/cfg/kubelet
......
--pod-infra-container-image=registry.cn-hangzhou.aliyuncs.com/google-containers/pause-amd64:3.0"

//每次创建 Pod 时候就会创建，运行的每一个Pod都有一个 pause-amd64 的基础容器自动会运行，对于用户是透明的
docker ps -a
registry.cn-hangzhou.aliyuncs.com/google-containers/pause-amd64:3.0   "/pause"

2、初始化容器（initcontainers）

初始化容器（initContainers）是Kubernetes中的一种特殊类型的容器。它们用于在主应用容器启动之前运行，并且仅在完成其任务后才会退出。

初始化容器常用于执行一些预处理任务，例如：

1. 数据初始化：可以使用初始化容器在应用程序启动之前准备数据，如从外部存储加载配置文件、密钥、证书等。

2. 依赖项安装：如果应用程序有一些依赖项需要在启动之前安装，可以使用初始化容器来执行软件包安装、下载依赖项等操作。

3. 数据库迁移：如果应用程序需要进行数据库迁移或者初始化，可以使用初始化容器来执行相关的数据库操作。

4. 启动脚本：可以使用初始化容器来运行启动脚本，进行一些环境配置、权限设置等操作。

在Kubernetes中，一个Pod可以包含一个或多个初始化容器。这些容器会按照定义的顺序逐个执行，并且只有当前一个初始化容器成功完成后，下一个初始化容器才会启动。如果任何一个初始化容器失败，Kubernetes将会重启Pod，直到所有的初始化容器都成功完成。

通过使用初始化容器，可以确保应用程序的运行环境和依赖项在主应用容器启动之前得到满足。这种方式可以提高应用程序的稳定性和可靠性，同时也能够简化应用程序的部署和维护工作。

3、应用容器（Maincontainer）

应用容器（Maincontainer）通常指的是包含应用程序及其所有依赖项的独立运行环境。在容器化技术中，容器被用来封装应用程序、运行时环境和系统工具，以便应用程序能够在任何环境中保持一致性并独立运行。

在一个典型的容器化应用中，通常会有一个主要的应用容器（Maincontainer），它包含了整个应用程序的代码、库文件、配置文件等。主应用容器负责启动应用程序，并与其他容器或系统资源进行交互，比如访问数据库、调用其他服务等。

主应用容器通常会运行一个特定的进程或服务，并且可以通过容器编排工具（如Docker Compose、Kubernetes等）管理多个容器之间的依赖关系和通信。在容器化的架构中，主应用容器往往是整个应用系统的核心，负责处理业务逻辑并提供服务。

通过将应用程序及其依赖项打包到容器中，主应用容器可以实现快速部署、扩展和迁移，同时也提高了应用程序的可移植性和可靠性。容器技术的流行使得开发人员能够更加灵活地构建和管理应用程序，同时也简化了运维工作，提升了应用程序的效率和可维护性。

三、pod中的镜像拉取策略与重启策略

1.拉取策略（Image Pull Policy）

在 Kubernetes 中，镜像拉取策略（Image Pull Policy）用于指定 Pod 如何获取其容器镜像。镜像拉取策略通常在 Pod 的容器配置中指定，有以下几种常见的策略：

1. Always：始终拉取最新版本的镜像。无论本地是否已存在该镜像，Kubernetes 都会尝试从容器镜像仓库中拉取最新的镜像。这可以确保每次启动 Pod 时都使用最新的镜像，但也可能增加镜像拉取时间和网络开销。

2. IfNotPresent：仅当本地不存在镜像时才拉取。如果本地已经存在相同的镜像，则不会再次拉取，直接使用本地镜像。这可以减少镜像拉取时间和网络流量，适合在本地有缓存镜像的情况下使用。

3. Never：永远不拉取镜像。即使容器镜像不存在本地，也不会尝试从容器镜像仓库中拉取镜像。这种策略适合于必须使用本地镜像且离线部署的场景。

4. Default：根据容器镜像的标签来决定是否拉取镜像。如果容器镜像的标签发生变化，Kubernetes 会尝试拉取新版本的镜像；如果标签没有变化，则不会拉取新镜像。这是 Kubernetes 默认的镜像拉取策略。

镜像拉取策略可以在 Pod 的容器配置文件中通过 imagePullPolicy 字段进行设置。根据实际需求和应用场景，选择合适的镜像拉取策略可以提高容器的性能、可靠性和安全性。

2.重启策略（Restart Policy）

在 Kubernetes 中，重启策略（Restart Policy）用于指定当容器退出时如何处理 Pod。重启策略通常在 Pod 的配置中指定，有以下几种常见的策略：

1. Always：始终重启容器。无论容器是正常退出还是异常退出，Kubernetes 都会自动重启容器。这是默认的重启策略。

2. OnFailure：仅在容器异常退出时才重启容器。如果容器以非零状态退出（例如由于错误或异常），Kubernetes 会自动重启容器。如果容器正常退出（状态码为零），则不会重启容器。

3. Never：永远不重启容器。无论容器是正常退出还是异常退出，Kubernetes 都不会自动重启容器。这意味着 Pod 中的容器一旦退出，将不再自动恢复。

重启策略可以在 Pod 的配置文件中通过 restartPolicy 字段进行设置。根据应用的特性和需求，选择合适的重启策略可以确保容器的可用性、稳定性和可靠性。需要根据实际情况权衡容器的重启与资源消耗之间的平衡。

四、实验案例

1.拉取策略

kubectl apply -f - <<EOF
apiVersion: v1
kind: Pod
metadata:
  name: private-image-test-1
spec:
  containers:
    - name: uses-private-image
      image: $PRIVATE_IMAGE_NAME
      imagePullPolicy: Always
      command: [ "echo", "SUCCESS" ]
EOF

//master01 上操作
kubectl edit deployment/nginx-deployment
......
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: nginx
    spec:
      containers:
      - image: nginx:1.15.4
        imagePullPolicy: IfNotPresent                            #镜像拉取策略为 IfNotPresent
        name: nginx
        ports:
        - containerPort: 80
          protocol: TCP
        resources: {}
        terminationMessagePath: /dev/termination-log
        terminationMessagePolicy: File
      dnsPolicy: ClusterFirst
      restartPolicy: Always                                        #Pod的重启策略为 Always，默认值
      schedulerName: default-scheduler
      securityContext: {}
      terminationGracePeriodSeconds: 30
......

//创建测试案例
mkdir /opt/demo
cd /opt/demo

vim pod1.yaml
apiVersion: v1
kind: Pod
metadata:
  name: pod-test1
spec:
  containers:
    - name: nginx
      image: nginx
      imagePullPolicy: Always
      command: [ "echo", "SUCCESS" ]

kubectl create -f pod1.yaml

kubectl get pods -o wide
pod-test1                         0/1     CrashLoopBackOff   4          3m33s
//此时 Pod 的状态异常，原因是 echo 执行完进程终止，容器生命周期也就结束了

kubectl describe pod pod-test1
......
Events:
  Type     Reason     Age                 From                    Message
  ----     ------     ----                ----                    -------
  Normal   Scheduled  2m10s               default-scheduler       Successfully assigned default/pod-test1 to 192.168.80.11
  Normal   Pulled     46s (x4 over 119s)  kubelet, 192.168.80.11  Successfully pulled image "nginx"
  Normal   Created    46s (x4 over 119s)  kubelet, 192.168.80.11  Created container
  Normal   Started    46s (x4 over 119s)  kubelet, 192.168.80.11  Started container
  Warning  BackOff    19s (x7 over 107s)  kubelet, 192.168.80.11  Back-off restarting failed container
  Normal   Pulling    5s (x5 over 2m8s)   kubelet, 192.168.80.11  pulling image "nginx"
//可以发现 Pod 中的容器在生命周期结束后，由于 Pod 的重启策略为 Always，容器再次重启了，并且又重新开始拉取镜像

//修改 pod1.yaml 文件
cd /opt/demo
vim pod1.yaml
apiVersion: v1
kind: Pod
metadata:
  name: pod-test1
spec:
  containers:
    - name: nginx
      image: nginx:1.14                            #修改 nginx 镜像版本
      imagePullPolicy: Always
      #command: [ "echo", "SUCCESS" ]            #删除

//删除原有的资源
kubectl delete -f pod1.yaml 

//更新资源
kubectl apply -f pod1.yaml 

//查看 Pod 状态
kubectl get pods -o wide
NAME                              READY   STATUS    RESTARTS   AGE   IP            NODE            NOMINATED NODE
pod-test1                         1/1     Running   0          33s   172.17.36.4   192.168.80.11   <none>

//在任意 node 节点上使用 curl 查看头部信息
curl -I http://172.17.36.4
HTTP/1.1 200 OK
Server: nginx/1.14.2
......
 

2.重启策略

vim pod3.yaml
apiVersion: v1
kind: Pod
metadata:
  name: foo
spec:
  containers:
  - name: busybox
    image: busybox
    args:
    - /bin/sh
    - -c
    - sleep 30; exit 3

kubectl apply -f pod3.yaml

//查看Pod状态，等容器启动后30秒后执行exit退出进程进入error状态，就会重启次数加1
kubectl get pods
NAME                              READY   STATUS             RESTARTS   AGE
foo                               1/1     Running            1          50s

kubectl delete -f pod3.yaml

vim pod3.yaml
apiVersion: v1
kind: Pod
metadata:
  name: foo
spec:
  containers:
  - name: busybox
    image: busybox
    args:
    - /bin/sh
    - -c
    - sleep 30; exit 3
  restartPolicy: Never
#注意：跟container同一个级别

kubectl apply -f pod3.yaml

//容器进入error状态不会进行重启
kubectl get pods -w