k8s之pod

一、Pod基础概念

1.1 在Kubrenetes集群中Pod有如下两种使用方式

1.2 pod的种类

二、容器的分类

（1）基础容器（pause）

（2）初始化容器（initcontainers）

（3）应用容器（Maincontainer）

三、init初始化

四、k8s 镜像拉取策略

1、IfNotPresent

2、Always

3、Never

五、pod容器重启策略（restartPolicy）

1、Always

2、OnFailure

3、Never

一、Pod基础概念

总结：pod是k8s最小的创建和运行单元

一个pod包含一个或几个容器

一个跟容器/父容器/基础容器---->pause容器---->一个或者多个应用容器/业务容器

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

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

1.1 在Kubrenetes集群中Pod有如下两种使用方式

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

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

1.2 pod的种类

自主式Pod

总结：不被控制器管理的pod，没有自愈能力，一旦pod挂掉，不会被重新拉起。而且副本数量也不会因为达不到期望值而创建新的pod

这种Pod本身是不能自我修复的，当Pod被创建后（不论是由你直接创建还是被其他Controller），都会被Kuberentes调度到集群的Node上。直到Pod的进程终止、被删掉、因为缺少资源而被驱逐、或者Node故障之前这个Pod都会一直保持在那个Node上。Pod不会自愈。如果Pod运行的Node故障，或者是调度器本身故障，这个Pod就会被删除。同样的，如果Pod所在Node缺少资源或者Pod处于维护状态，Pod也会被驱逐。

控制器管理的Pod

总结：被控制器管理的pod，有自愈能力，一旦pod挂掉，会被重新拉起。而且副本数量会因为达不到期望值而创建新的pod。

Kubernetes使用更高级的称为Controller的抽象层，来管理Pod实例。Controller可以创建和管理多个Pod，提供副本管理、滚动升级和集群级别的自愈能力。例如，如果一个Node故障，Controller就能自动将该节点上的Pod调度到其他健康的Node上。虽然可以直接使用Pod，但是在Kubernetes中通常是使用Controller来管理Pod的。

自主式pod不存在etcd当中，所以坏了或者删除就不会再创建pod了

控制器可以根据etcd的信息，会根据预选和优选的策略，再重新创建一个pod。

二、容器的分类

（1）基础容器（pause）

pause容器使得Pod中的所有容器可以共享两种资源：网络和存储。

给pod中的所有应用容器提供网络(共享IP)和存储(共享存储)资源共享：作为PID=1的进程(init进程)

（2）初始化容器（initcontainers）

初始化容器（init容器）：阻塞或者延迟应用容器的启动，可以为应用容器事先提供好运行环境和工具。

多个init容器是串行启动的，每个init容器都必须在下一个init容器启动前完成启动和退出。

（3）应用容器（Maincontainer）

应用容器（main 容器）：在所有init容器成功后启动和退出后应用容器才会启动，并行启动的，提供应用程序的业务。

三、init初始化

特别说明！！！！！：
●在Pod启动过程中，Init容器会按顺序在网络和数据卷初始化之后启动。每个容器必须在下一个容器启动之前成功退出。
●如果由于运行时或失败退出，将导致容器启动失败，它会根据Pod的restartPolicy指定的策略进行重试。然而，如果Pod的restartPolicy设置为Always，Init容器失败时会使用RestartPolicy策略。
●在所有的Init容器没有成功之前，Pod将不会变成Ready状态。Init容器的端口将不会在Service中进行聚集。正在初始化中的Pod处于Pending状态，但应该会将Initializing状态设置为true。
●如果Pod重启，所有Init容器必须重新执行。
●对Init容器spec的修改被限制在容器image字段，修改其他字段都不会生效。更改Init容器的image字段，等价于重启该Pod。
●Init容器具有应用容器的所有字段。除了readinessProbe，因为Init容器无法定义不同于完成（completion）的就绪（readiness）之外的其他状态。这会在验证过程中强制执行。
●在Pod中的每个app和Init容器的名称必须唯一；与任何其它容器共享同一个名称，会在验证时抛出错误。

init初始化：当有一个或多个init时，必须先创建init成功之后，才会运行下一个，如果创建不成功，就不会运行下一个，会阻塞。

创建pod：myapp-pod

这段代码是一个 Kubernetes Pod 的配置文件，用于定义一个运行容器化应用程序的 Pod，并包含了两个 initContainer。让我逐步解释它：

- `apiVersion: v1` 和 `kind: Pod` 表示这是一个 Kubernetes Pod 配置。

- `metadata` 部分定义了 Pod 的元数据，包括名称和标签。这个 Pod 的名称是 "myapp-pod"，并且它有一个标签 "app: myapp"，标签用于标识和分类 Pod。

- `spec` 部分是 Pod 的规范，它定义了 Pod 包含的容器和 initContainer。

  - `containers` 部分定义了一个主要的容器，名称为 "myapp-container"，使用了 "busybox:1.28" 镜像，并运行一个命令：`sh -c 'echo The app is running! && sleep 3600'`。
这个命令会在容器内打印一条消息 "The app is running!"，然后让容器休眠 3600 秒（1小时）。

  - `initContainers` 部分定义了两个 initContainer，它们在主容器运行之前执行。这些 initContainer 的目的是在主应用程序容器开始运行之前，执行一些初始化任务，通常用于等待依赖项准备就绪。

    - 第一个 initContainer 名为 "init-myservice"，它使用了 "busybox:1.28" 镜像，运行的命令是 `sh -c 'until nslookup myservice; do echo waiting for myservice; sleep 2; done;'`。
这个 initContainer 的目的是等待名为 "myservice" 的 DNS 条目可用，它会不断执行 DNS 查询，直到 "myservice" 的 DNS 条目就绪，期间会每隔 2 秒打印一条消息 "waiting for myservice"。

    - 第二个 initContainer 名为 "init-mydb"，与 "init-myservice" 类似，它使用了 "busybox:1.28" 镜像，运行的命令是 `sh -c 'until nslookup mydb; do echo waiting for mydb; sleep 2; done;'`。
它的目的是等待名为 "mydb" 的 DNS 条目可用，也会不断执行 DNS 查询，直到 "mydb" 的 DNS 条目就绪，期间会每隔 2 秒打印一条消息 "waiting for mydb"。

这种设置通常用于确保在主应用程序容器开始运行之前，需要的依赖项（如其他服务或数据库）已经准备就绪。一旦这些 initContainer 完成了它们的任务，主应用程序容器才会开始运行。
这有助于应用程序的稳定性和可靠性，因为它们不会在依赖项未准备好的情况下启动。

这段代码是一个 Kubernetes Service（服务）的配置文件，用于定义一个服务对象。以下是对该配置文件的逐行解释：

- `apiVersion: v1`: 这是 Kubernetes API 的版本，表明这个配置文件适用于 Kubernetes API 版本 1。

- `kind: Service`: 这指定了配置文件中定义的 Kubernetes 资源类型，即 Service。

- `metadata`: 在这个部分中，您可以定义有关服务的元数据，包括服务的名称。
   - `name: myservice`: 这里指定了服务的名称为 "myservice"。服务名称是在集群内唯一标识服务的重要属性。

- `spec`: 这个部分定义了服务的规范，包括服务的端口配置和选择器。
   - `ports`: 这里定义了服务监听的端口，可以有多个端口。在这个例子中，只定义了一个端口。
     - `port: 80`: 表示服务在端口 80 上监听传入的请求。
     - `protocol: TCP`: 指定服务使用 TCP 协议来处理请求。
     - `targetPort: 80`: 这是服务将请求路由到的 Pod 的端口。在这种情况下，服务将请求路由到具有标签 `app: myapp` 的 Pod 上的端口 80。

   - `selector`: 这是一个用于选择要关联到服务的 Pod 的标签选择器。
     - `app: myapp`: 这里定义了一个标签选择器，它要求服务将流量路由到带有标签 `app: myapp` 的 Pod。这意味着该服务将关联到那些具有标签 `app: myapp` 的 Pod，而不是其他 Pod。

总结：这个配置文件定义了一个名为 "myservice" 的 Kubernetes 服务，监听端口 80，并将传入的请求路由到带有标签 `app: myapp` 的 Pod 上的端口 80。这有助于服务发现和负载均衡，使应用程序能够通过服务名 "myservice" 访问相关的 Pod。

这段代码是一个 Kubernetes Service（服务）的配置文件，用于定义另一个服务对象。以下是对该配置文件的逐行解释：

- `apiVersion: v1`: 这是 Kubernetes API 的版本，表明这个配置文件适用于 Kubernetes API 版本 1。

- `kind: Service`: 这指定了配置文件中定义的 Kubernetes 资源类型，即 Service。

- `metadata`: 在这个部分中，您可以定义有关服务的元数据，包括服务的名称。
   - `name: mydb`: 这里指定了服务的名称为 "mydb"。服务名称是在集群内唯一标识服务的重要属性。

- `spec`: 这个部分定义了服务的规范，包括服务的端口配置和选择器。
   - `ports`: 这里定义了服务监听的端口，可以有多个端口。在这个例子中，只定义了一个端口。
     - `port: 80`: 表示服务在端口 80 上监听传入的请求。
     - `protocol: TCP`: 指定服务使用 TCP 协议来处理请求。
     - `targetPort: 80`: 这是服务将请求路由到的 Pod 的端口。在这种情况下，服务将请求路由到具有标签 `app: myapp` 的 Pod 上的端口 80。

   - `selector`: 这是一个用于选择要关联到服务的 Pod 的标签选择器。
     - `app: myapp`: 这里定义了一个标签选择器，它要求服务将流量路由到带有标签 `app: myapp` 的 Pod。这意味着该服务将关联到那些具有标签 `app: myapp` 的 Pod，而不是其他 Pod。

总结：这个配置文件定义了一个名为 "mydb" 的 Kubernetes 服务，监听端口 80，并将传入的请求路由到带有标签 `app: myapp` 的 Pod 上的端口 80。与前一个服务配置类似，这有助于服务发现和负载均衡，使应用程序能够通过服务名 "mydb" 访问相关的 Pod。这个服务可能是应用程序中与数据库相关的服务。