【K8S基础】-k8s的核心概念pod

一、Pod 是什么

1.1 Pod 的定义和概念

在Kubernetes中，Pod是创建或部署的最小/最简单的基本单位。一个Pod代表着集群上正在运行的一个进程，它封装了一个或多个应用容器，并且提供了一些共享资源，如网络和存储，每个Pod都被分配一个独立的IP地址，并且Pod中的每个容器共享网络命名空间，包括IP地址和网络端口。此外，Pod可以指定一组共享存储卷，以便Pod中的所有容器都可以访问共享卷并共享数据。

以下是一个最简单的pod资源文件，它定义了一个名称为nginx的pod，pod中包括一个名称为nginx的容器，容器镜像使用nginx:1.14.2，端口为80。

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx:1.14.2
    ports:
    - containerPort: 80

1.2 Pod 的特点和作用

资源共享与隔离：Pod作为Kubernetes调度的最小单位，它可以包含一个或多个容器，并共享相同的网络和存储资源。Pod中的容器可以共享文件系统、环境变量和进程空间，它们之间可以通过本地主机的localhost进行通信。这种资源的共享和管理使得应用程序的部署更加高效和灵活。

应用程序的部署和管理：Pod提供了一种逻辑上的封装，使得应用程序的部署和管理更加简单和可控。通过定义Pod的规范，我们可以指定应用程序所需的资源、环境变量、存储卷等信息。Kubernetes会根据这些规范来创建、销毁、伸缩和调度Pod，而不会影响到其他Pod。这种灵活的部署和管理方式可以提高应用程序的可靠性和可用性。

弹性伸缩和负载均衡：Pod可以根据应用程序的负载情况进行伸缩，以满足不同的需求。通过水平伸缩Pod，我们可以根据负载的增减自动调整应用程序的实例数量。同时，Pod可以与Service结合使用，通过Service提供稳定的网络访问地址，实现负载均衡和流量管理。

应用程序的可移植性：Pod提供了一种抽象层，隐藏了底层基础设施的细节。这意味着我们可以在不同的环境中运行应用程序，而无需修改代码。无论是在本地开发环境、测试环境还是生产环境，我们都可以使用相同的Pod规范来部署和管理应用程序。这种可移植性使得应用程序的开发、测试和部署更加简单和可靠。

资源管理和调度：Pod可以指定应用程序所需的资源，例如CPU、内存等。Kubernetes可以根据这些资源需求进行调度，将Pod分配到合适的主机上。通过资源管理和调度，我们可以充分利用集群中的资源，提高资源的利用率和效率。

二、Pod 的生命周期管理

2.1 Pod 的创建过程

1. 定义Pod规格：首先，用户或管理员需要定义Pod的规格，包括容器镜像、资源需求、环境变量、存储卷等。这通常通过编写Pod的配置文件（如YAML文件）或使用Kubernetes API进行定义。

2. 提交Pod配置：将Pod的配置文件或通过API提交给Kubernetes控制平面。这可以使用kubectl命令行工具或其他Kubernetes客户端进行操作。

3. 控制器接收到创建请求：Kubernetes控制器（如Deployment、ReplicaSet等）接收到创建Pod的请求，并将其传达给Kubernetes的调度器。

4. 调度器选择节点：调度器根据Pod的调度策略、资源需求、亲和性规则等，选择一个合适的节点来运行Pod。调度器会考虑节点的资源可用性、标签匹配等因素。

5. 节点上创建Pod：一旦调度器选择了节点，Kubernetes会与该节点上的kubelet代理进行通信，请求在该节点上创建Pod。kubelet会根据Pod的规格，拉取容器镜像并创建容器。

6. 容器启动：kubelet在节点上启动Pod中的容器。它会为每个容器设置网络命名空间、IP地址、存储卷等资源，并启动容器进程。

7. 容器状态检查：Kubernetes会定期检查容器的状态，确保容器正常运行。如果容器出现故障或不响应，Kubernetes会自动重启或替换容器。

8. Pod状态更新：一旦Pod中的所有容器都成功启动，Kubernetes会将Pod的状态更新为“运行中”。此时，Pod将可以接收流量和请求。

2.2 Pod 的终止过程

1. 用户请求终止：当用户主动发出终止Pod的请求时，例如使用kubectl命令删除Pod，Kubernetes控制器会接收到该请求。

2. 控制器检测到终止请求：Kubernetes控制器（如Deployment、ReplicaSet等）会检测到终止请求，并将其传达给Kubernetes的调度器。

3. 调度器标记Pod为终止状态：调度器会将Pod标记为终止状态，并停止将新的请求调度到该Pod上。

4. 终止信号发送给Pod中的容器：Kubernetes会向Pod中的每个容器发送终止信号，通常是通过发送SIGTERM信号。

5. 容器执行终止操作：容器接收到终止信号后，可以执行一些清理操作，例如保存状态、关闭连接、释放资源等。容器应该在一定时间内完成清理操作。

6. 超时等待：如果容器在一定时间内无法正常终止（例如，容器无法响应终止信号），Kubernetes会发送SIGKILL信号来强制终止容器。

7. Pod被删除：一旦所有容器都成功终止，Pod将被删除。此时，Pod将不再存在于集群中，并且相关的资源将被释放。

三、Pod 的重启策略

Pods的重启策略用restartPolicy参数表示，有以下三种策略：

Always：当容器失效时，总是由kubelet自动重启容器。

Never：当容器终止运行且退出码不为0的时候，有kubelet自动重启该容器。

OnFailure：无论容器运行关闭状态如何，kubelet都不会重启该容器。

apiVersion: v1
kind: Pod
metadata:
  name: demo-pod
  namespace: default
  labels:
    app: myapp
spec:
  restartPolicy: Always
  containers:
  - name:  tomcat-pod-java
    ports:
    - containerPort: 8080
    image: tomcat
    imagePullPolicy: IfNotPresent

四、Pod 的资源配置

在Kubernetes中，可以使用requests和limits两种类型参数对资源进行预分配和使用限制。

requests：是容器启动时所需要的最小资源，如果无法满足这些资源请求，则容器无法启动。

limits：是容器运行时可以使用的最大资源，如果超过这个限制，则容器会被强制停止。

resources: #资源管理
  requests: 
    cpu: 0.5     
    memory: 1Gi 
  limits:   
    cpu: 1  
    memory: 2Gi

对于CPU资源，其表示方法有两种，浮点数或者是整数+m，1000m代表1个CPU，500m代表0.5个CPU。对于内存资源，其表示方法以Mi/Gi为单位，100Mi代表100MB内存，1Gi为1G内存。如上面的示例就是配置一个最小为0.5C/1G，最大为1C/2G的pod。

五、Pod 的健康检查

5.1 Pod 存活检查（LivenessProbe）

LivenessProbe（存活探针）是Kubernetes中用于检查Pod中的容器是否正常运行的一种机制。其主要作用是确保容器在出现问题时能够自动重启，以保证Pod的可用性。如果检测失败，则认为容器不健康，此时Kubernetes将根据Pod中设置的重启策略（restartPolicy）来判断是否重启容器。如果容器中没有配置LivenessProbe，则默认认为容器的健康检查一直成功。

在Kubernetes中，Pod的LivenessProbe（存活探针）主要有三种类型：

HTTP探针：通过向容器内特定的HTTP端点发送HTTP请求来检查容器的健康状态。如果HTTP响应的状态码在200-400之间，则认为容器健康；否则，认为容器不健康。

livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
    httpHeaders:
    - name: Custom-Header
      value: Awesome
  initialDelaySeconds: 3
  periodSeconds: 3

TCP探针：通过尝试与容器内特定端口建立TCP连接来检查容器的健康状态。如果TCP连接建立成功，则认为容器健康；否则，认为容器不健康。

livenessProbe:
  tcpSocket:
    port: 8080
  initialDelaySeconds: 15
  periodSeconds: 20

Exec探针：通过在容器内执行特定的命令来检查容器的健康状态。如果命令执行成功（返回值为0），则认为容器健康；否则，认为容器不健康。

livenessProbe:
  exec:
    command:
    - cat
    - /tmp/healthy
  initialDelaySeconds: 5
  periodSeconds: 5

这三种探针可以单独使用，也可以结合使用，以满足不同的健康检查需求。

5.2 Pod 就绪检查（ReadinessProbe）

ReadinessProbe是用于检测应用实例是否准备好接收请求的机制。

当Pod启动后，ReadinessProbe会定期检查Pod中的应用实例是否已经准备好接收请求。如果应用实例没有准备好，那么Pod将被标记为未准备好，此时Kubernetes不会将流量转发到该Pod。只有当ReadinessProbe检测到应用实例已经准备好接收请求时，Kubernetes才会将流量转发到该Pod。

ReadinessProbe的配置方式与LivenessProbe类似，可以通过HTTP、TCP或Exec等方式进行检查。唯一区别就是要使用 readinessProbe 字段，而不是 livenessProbe 字段，不同的配置方式适用于不同的应用场景，可以根据具体需求进行选择。