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。这个服务可能是应用程序中与数据库相关的服务。
四、k8s 镜像拉取策略
Pod 的核心是运行容器，必须指定容器引擎，比如 Docker，启动容器时，需要拉取镜像，k8s 的镜像拉取策略可以由用户指定：
1、IfNotPresent
在镜像已经存在的情况下，kubelet 将不再去拉取镜像，仅当本地缺失时才从仓库中拉取，默认的镜像拉取策略。
优先使用本地已存在的仓库，如果本地没有，则从仓库镜像拉取。
2、Always
每次创建 Pod 都会重新拉取一次镜像。
总是从仓库拉取镜像，无论本地是否已存在镜像。
3、Never
Pod 不会主动拉取这个镜像，仅使用本地镜像。
总是不从仓库拉取镜像，仅使用本地镜像。
注意：对于标签为“:latest”的镜像文件，其默认的镜像获取策略即为“Always”；而对于其他标签的镜像，其默认策略则为“IfNotPresent”。
以编辑模式查看指定的pod的配置
创建Pod资源时，因为设置镜像的版本资源为:lastest，默认的镜像拉取策略为Always
重新创建一个Pod资源，修改镜像版本为latest，然后再设置镜像策略为IfNotPresent，会按设置的顺序进行。
五、pod容器重启策略（restartPolicy）
当 Pod 中的容器退出时通过节点上的 kubelet 重启容器。适用于 Pod 中的所有容器。
1、Always
当容器终止退出后，总是重启容器，默认策略
容器退出总是重启容器，不管返回状态码如何，默认的Pod容器重启策略
2、OnFailure
当容器异常退出（退出状态码非0）时，重启容器；正常退出则不重启容器
仅在容器异常退出时，返回码为非0时，会重启容器。
3、Never
当容器终止退出，从不重启容器。
容器退出时从不重启容器，不管返回状态码如何
#注意：K8S 中不支持重启 Pod 资源，只有删除重建
创建的Pod资源，默认的重启策略都为：Always
重新创建Pod资源，并且添加默认的重启策略为：Never
