【K8S 云原生】Pod资源

koeda（粉丝冲刺一个亿）

已于 2024-01-15 15:28:26 修改

阅读量2k

点赞数 36

分类专栏： Kurbernetes 文章标签：云原生 kubernetes 容器

于 2024-01-03 14:30:21 首次发布

本文链接：https://blog.csdn.net/koeda1/article/details/135361890

版权

Kurbernetes 专栏收录该内容

16 篇文章 0 订阅

订阅专栏

一、pod概述：

1、pod概念

pod是K8S中最小的资源管理组件

pod也是最小化运行容器化的应用的资源管理对象

pod是一个抽象的概念，可以理解为一个或者多个容器化应用的集合

在一个pod中运行一个容器是最常用的方式

在一个pod当中同时运行多个容器，一个pod中可以同时封装几个需要耦合的互相协作的容器

这些多个容器时共享资源，也可以互相协作，组成一个service单位。

不论是运行一个还是多个容器，K8S管理的都是pod而不是容器

一个pod内的容器，必须都运行在同一节点。

基于现代容器技术的要求，就是一个pod运行一个容器，一个容器运行一个进程

这样做的目的：

横向扩展，方便扩缩容
解耦，一个pod内运行多个容器，耦合度太高，一旦一个进程失败，整个pod将全部失败。一个pod运行一个容器，可以实现解耦，可以创建多个副本，实现高可用和负载均衡
管理方面，简单直观

2、pod的分类：

自主式pod：pod不会自我修复，如果pod内容器的进程终止，或者被delete删除、缺少资源被驱逐，这个pod没有办法自愈（只要不是基于控制器创建的都是自主式pod）
控制器管理pod：可以滚动升级，可以自愈（自动重启），可以管理pod的数量，以及扩缩容

二、 pause容器

1、pause容器概念：

pod内的容器共享资源。

共享机制：pause底层基础容器来提供共享资源的机制

pause容器时基础容器，也可以称为父容器。作用就是管理pod内容器的共享操作

pause还可以管理容器的生命周期

K8S提供了pause容器作用：

为pod内的所有容器提供一个命名空间
启动容器的PID命名空间，每个pod中都作为PID为1的进程（init进程），回收僵尸进程
创建pod时，先创建pause容器，然后拉取镜像，生成容器，形成pod（容器不是由pod管理，而是由pause管理容器的进程）

pause相当于pod的基础容器，先有pause再有pod

kubelet 是负责管理整个 Pod 中所有容器的组件，包括pause容器。pause容器在这里充当一个辅助角色，为其他容器提供共享的运行环境。

创建一个nginx pod的过程：先拉取pause容器，在拉取nginx镜像，容器跑起来，pause管理

销毁pod：先销毁nginx，pause回收容器资源，kubelet销毁pause

pause是pod的基础，由pause管理pod内部的容器

总的来说kubelet管理节点上的pod，pause管理pod内的容器

2、创建pod的流程：

第一步：master节点发出指令，pod使用的镜像nginx，pod的副本数

第二步：scheduler来分配执行的node节点

第三步：node节点的kubelet收到master的指令，先拉pause，再拉nginx:1.22，指定副本数

第四步：pause容器先启动，提供命名空间，进程管理pid=1，来为pod内的容器提供共享服务以及容器的进程管理

3、pause容器的作用：

共享网络命名空间： 所有容器都共享同一个网络命名空间，它们可以通过 localhost 相互通信，而无需通过网络进行通信。

共享存储卷： 所有容器可以访问相同的存储卷，这使得它们之间可以共享数据。

维护 Pod 的生命周期： "pause" 容器的存在确保了 Pod 的运行。当 Pod 中的其他容器终止时，"pause" 容器依然存在，从而保持整个 Pod 的存在，直到所有容器都终止。

总体而言，pause容器在 Kubernetes 的 Pod 中扮演了一个关键的角色，为其他容器提供了网络和存储的共享环境，同时通过维护其自身的存在来维护整个 Pod 的生命周期。

pause作用：

网络命名空间共享
只要创建pod就会创建pause，维护pod内部容器的生命周期
pod可以指定多个共享的VOLUME，pod内的容器共享这些VOLUME卷，可以实现数据的持久化，防止pod重新构建之后文件丢失

4、pause总结：

pause容器共享两种资源：网络和存储资源

网络：每个pod都是被分配一个集群内部唯一的IP地址，pod内的容器共享网络，pod在集群内部的IP地址和端口

pod内部的容器可以使用localhost互相通信。pod中的容器与外部通信时，从共享的资源当中进行分配

每个pod都有一个基础容器，pause容器。

pause容器对应的镜像是属于K8S集群的一部分，创建集群的时候就会有pause这个基础镜像

pod里面包含了一个或者多个相关的容器（应用），提供服务的是容器，不是pod

endpoints给pod分配IP地址，网络插件分配网络服务

pod外面再设置一个初始镜像：

pod内部有一组容器，挂了一个，就算整个pod失效了么？引入pause机制，可以代表整个容器组的状态。可以解决对pod内部整体状态的判断
pod内的容器和pod共享ip，共享VOLUME，解决了容器内网络通信的问题，解决了容器内部文件共享的问题

三、pod的生命周期：

1、pod的状态：

1、pending挂起状态：

pod已被创建，但是尚未分配到运行他的node节点

出现原因：

节点上资源不够

需要等待其他pod资源的调度完成

2、Running运行中：

pod已经被分配到了node节点，pod内部的所用容器都已经启动，运行状态正常

3、competed/successded：容器内部的进程运行完毕正常退出，没有发生错误

4、failed：pod中的容器非正常退出。发生了错误，需要通过查看详情或者日志定位问题

5、UNkown：由于某些原因，K8S集群无法获取pod的状态。apiserver出了问题

6、terminating：终止中，pod正在被删除，里面的容器正在终止。终止过程中，涉及资源回收、垃圾清理、终止过程中需要执行的命令

2、pod的生命周期过程：

1、先有pause基础容器才会创建初始化init容器

2、初始化容器运行完毕而且是成功运行完毕后才会创建pod的主业务容器

在容器的生命周期中还伴随着2个容器钩子：

3、容器钩子：

poststart：表示容器运行时执行的第一个命令

prestop：容器结束时执行的最后一个命令

容器生命周期中还有2个探针：

探针：用于检测容器状态是否正常。

livenessProbe：存活探针

readinessProbe：流量探针

启动探针

存活探针和流量探针会伴随整个pod的生命周期

会不停的检测内部主业务容器的情况。只要主业务容器出现问题，整个pod将不再式ready状态。

但是启动探针除外

3、创建一个pod容器过程：

1、基础容器：pause

2、 init容器(初始化容器)：init c

3、业务容器：主服务容器

先启动pause基础容器 > init初始化容器 > pod业务主容器

在pause基础容器和init初始化容器的过程中。pod状态：init 1/3---2/3---3/3

当所有init初始化都启动完毕才会创建业务容器

实验验证：

vim init.yaml
 
apiVersion: v1
kind: Pod
metadata:
  name: nginx-init
spec:
  containers:
  - name: nginx1
    image: nginx:1.22
#定义的业务容器
  initContainers:
  - name: init-centos1
    image: centos:7
    command: ["echo", "hello,world"]
  - name: init-contos2
    image: centos:7
    command: ["echo", "I am ready"]
#这里定义业务容器和两个init初始化容器
#会先创建完pause初始化容器后
#才会先执行init-centos1输出hello，world。
#再执行init-centos2输出I am ready
#最后才会拉起nginx容器

4、init容器的作用：

环境变量，可以在创建的过程中为业务容器定制好相关的代码和工具。

init容器独立于业务容器，他是单独构建的一个镜像，对业务容器不产生任何安全影响

init容器能以不同于pod内应用容器的文件系统视图运行。secrets的权限。应用容器无法访问secrets的权限

总结：

init容器提供了应用容器运行之前的先决条件，提供了一种阻塞或者延迟机制来控制应用容器的启动。只有前置条件满足，才会创建pod内的应用容器

1、在pod的启动过程中，容器是按照初始化容器先启动，每个容器都必须下一个容器启动之前，要成功退出

2、如果有运行失败，会按照容器的重启策略进行指定动作，restartPolicy：Alawys Never Onfailure（非正常退出才会重启）

3、所有的init容器没有成功之前，pod是不会进入ready状态的

init容器与service无关。不能对外提供访问

如果重启pod，所有的init容器一定会重新执行
如果修改init容器的spec（参数），只限制于image，修其他修改字段都不生效（基于deployment创建的pod）
每个容器的名称都要唯一，不能重复

5、pod的重启策略

实验举例：

apiVersion: v1
kind: Pod
metadata:
  name: centos
spec:
  restartPolicy: OnFailure
#k8s中pod的重启策略，基于容器的状态进行pod的重启
#Always：总是重启。只要容器退出，无论容器的状态码是正常还是不正常。默认策略可以不加
#Never：永不重启。只要容器退出，无论容器是否正常都不重启
#OnFailure：只有容器的状态码非0时候才会重启。正常退出不会重启。
#一般情况下都使用默认Always，只有特殊情况下会使用Never
#在deployment的yaml文件当中，重启的策略只能是Always也是默认策略。所以可以不加。
  containers:
  - name: centos
    image: centos:7
    command: ["echo", "I am ready"]

在deployment的yaml文件当中，重启的策略只能是Always也是默认策略。所以可以不加

实验举例：

apiVersion: v1
kind: Pod
metadata:
  name: centos
spec:
  restartPolicy: OnFailure
#k8s中pod的重启策略，基于容器的状态进行pod的重启
#Always：总是重启。只要容器退出，无论容器的状态码是正常还是不正常。默认策略可以不加
#Never：永不重启。只要容器退出，无论容器是否正常都不重启
#OnFailure：只有容器的状态码非0时候才会重启。正常退出不会重启。
#一般情况下都使用默认Always，只有特殊情况下会使用Never
#在deployment的yaml文件当中，重启的策略只能是Always也是默认策略。所以可以不加。
  containers:
  - name: centos
    image: centos:7
    command: ["echo", "I am ready"]

6、总结：

pause容器：底层容器/基础容器

提供pod内容器的网络和共享存储，以及pod内容器退出之后资源回收

init容器：人为设定的，业务容器启动之间的必要条件

pod的生命周期：

pause基础容器
init容器——全部成功退出——业务容器
poststart prestop 容器的钩子

启动时命令和退出时的命令

探针：探测容器的健康状态。伴随pod的整个生命周期（除了容器探针）

总结一句话：

pod就是用来封装管理容器的，业务是容器。服务也是容器。端口也是容器

四、Pod控制器

1、概述

1.1、Pod的控制器是什么？

pod控制器：工作负载均衡。workload。用于管理pod的中间层。确保pod资源符合预期的状态。

预期状态：

1. 副本数
2. 容器的重启策略
3. 镜像拉取策略

pod出现故障时的重启等等

2、Pod控制器的类型

2.1、 replicaSet：指定副本的数量

三个组件：

1. Pod的副本数
2. 标签选择器：判断哪个pod归自己管理
3. 扩缩容

2.2、 Deployment控制器

他是工作在replicaSet之上。管理无状态应用。目前是最好的控制器。支持滚动跟新和回滚。提供声明式配置。

3、 statefulSet：也是控制器的一种，管理有状态的应用。也可也设置副本数，可以扩缩容。 Pod的序号是固定的。重启之后，Pod的名称也不会发生变化。表示有状态的pod

4、 DaemonSet：可以在所有节点部署一个pod。它没有副本数。可以限制部署的节点。也是无状态应用。服务必须是守护进程。例如： ingress、logstash、flannel

5、 job：工作pod控制器。执行完成即可退出。不需要重启，不需要重建。

6、 cronjob：周期性的定时任务控制器。不需要再后台持续运行。

Pod与控制器之间的关系

### 1、 controllers

1、 controllers：管理控制器

pod通过label---selector进行关联。

通过标签和选择标签和控制器关联

strategy字段：

web应用不需要加strategy字段会导致服务中断。

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: nginx1
  name: nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx1
  strategy:
      type: Recreate
#每次有更新，都会把旧的pod全部停止，然后再启动新的实例。服务可能会短暂的终端。无特殊需要可不加
  template:
    metadata:
      labels:
        app: nginx1
    spec:
      containers:
      - image: nginx:1.22
        name: nginx

  strategy:
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%

这是deployment的默认更新策略

rollingUpdate：滚动跟新

maxSurge： 25% 升级过程中，新启动的pod数量不能超过期望pod数的25%

maxUnavailable： 25% 升级过程中，新的pod启动好后，销毁的旧pod数量不能超过期望pod的25%

升级和销毁都不能超过期望pod的25%这样不会导致业务中断

3、无状态应用

2、无状态应用：pod名称是无序的。认为所有pod都是一体的。共享NFS存储。

所有deployment下的pod共享一个存储。

statfulSet：有状态应用。pod的名称是有序的。所有pod都是独立的。存储卷也是独立的。顺序从0开始到n。

delete删除也不会改变pod的序号。扩缩容也是有序扩缩容。同样从0开始

headless service：无头服务，他没有clusterIP。必须要有动态的pvc

statfulSet有状态应用控制器实验举例：

apiVersion: v1
kind: Service
metadata:
  name: nginx-web
  labels:
    app: nginx2

spec:
  ports:
  - port: 80
    targetPort: 80
  clusterIP: ""
  selector:
    app: nginx2
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web
  labels:
    app: nginx2

spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx2
  serviceName: "nginx-web"
  template:
    metadata:
      labels:
        app: nginx2
    spec:
    apiVersion: v1
kind: Service
metadata:
  name: nginx-web
  labels:
    app: nginx2

spec:
  ports:
  - port: 80
    targetPort: 80
  clusterIP: ""
#clusterIP必须为空
  selector:
    app: nginx2
---
apiVersion: apps/v1
#开始创建控制器
kind: StatefulSet
metadata:
  name: web
  labels:
    app: nginx2

spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx2
  serviceName: "nginx-web"
  #定义应用哪个service文件
  template:
    metadata:
      labels:
        app: nginx2
    spec:
      containers:
      - name: nginx
        image: nginx:1.22
        volumeMounts:
#定义挂载卷
        - name: html
          mountPath: /usr/share/nginx/html
  volumeClaimTemplates:
  #定义动态卷
  - metadata:
      name: html
    spec:
      accessModes: ["ReadWriteMany"]
#定义挂载卷权限
      storageClassName: "nfs-client-storageclass"
      resources:
        requests:
          storage: 2Gi

headless service无头服务：是k8s集群中一种特殊的服务类型。

1. 他不分配clusterIP给service。

2. 不会负载均衡到后端的pod。

3. 通过DNS来提供服务的发现和访问。

由于ClusterIP是空的。k8s集群会给每个headless service中的pod创建一个dns记录。

格式： pod-name.headless-service-name.namespace.svc.cluster.local.

通过dns直接解析访问pod的IP地址

#### 为什么要使用headless？

有序、独立个体

deployment的pod是没有名称的。随机字符串。无序的。他需要一个集中的clusterIP来集中统一为pod提供网络。

statefulset是有序的。pod名称是固定的。即便是重建之后pod的表示也不变。pod的名称是唯一的标识符。

系统直接通过pod名称解析IP地址。

只要pod名称不变通过pod名来映射IP地址即可

#### 为什么要使用动态PV？

只要是有状态的副本集群都会涉及到持久化存储。但是每个pod是独立个体。每个pod都有自己专用的存储点。

statefulSet再定义时就规定了每个pod不能使用同一个存储卷。所以才需要动态PV

定义好了每个pod都必须绑定一个存储卷所以使用动态pv

#### statefulset的使用场景

1. 用于不是固定节点的应用。不是固定IP的应用。
2. 更新发布比较频繁的场景
3. 支持自动伸缩。节点资源不够，可以自动扩容的场景。

删除statefulset

不需要clusterIP。没有clusterIP的就是无头服务headless

### 3、 demonSet

4、 demonSet：

确保每个节点上都运行一个pod副本。如果有node加入集群，也会为他薪资一个pod

实验举例：

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: nginx-daemon
  labels:
    app: nginx1
#提高代码的可读性。方便别人读。不同业务可以通过namespace隔离。
#命名时根据业务进行专业命名
spec:
  selector:
    matchLabels:
      app: nginx1
  template:
    metadata:
      labels:
        app: nginx1
    spec:
      containers:
      - name: nginx
        image: nginx:1.22
#部署一个daemonset的控制器。
#daemonset不能指定副本数他会在每个节点上都创建一个pod

kubectl delete daemonsets.apps nginx-daemon
#删除daemonSet控制器

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: nginx-daemon
  labels:
    app: nginx1
#提高代码的可读性。方便别人读。不同业务可以通过namespace隔离。
#命名时根据业务进行专业命名
spec:
  selector:
    matchLabels:
      app: nginx1
  template:
    metadata:
      labels:
        app: nginx1
    spec:
      containers:
      - name: nginx
        image: nginx:1.22
      nodeSelector:
        ingress: "true"
#只在有ingress为true这个标签的节点上部署，没有这个标签的节点不会部署

kubectl delete daemonsets.apps nginx-daemon
#删除daemonSet控制器

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: nginx-daemon
  labels:
    app: nginx1
#提高代码的可读性。方便别人读。不同业务可以通过namespace隔离。
#命名时根据业务进行专业命名
spec:
  selector:
    matchLabels:
      app: nginx1
  template:
    metadata:
      labels:
        app: nginx1
    spec:
      containers:
      - name: nginx
        image: nginx:1.22
      nodeSelector:
        ingress: "true"
#只在有ingress为true这个标签的节点上部署，没有这个标签的节点不会部署

kubectl delete jobs.batch centos
#删除控制器

对于k8s系统来说，既然定义了是job。你只需要执行一次，或者指定册数即可。不能一直允许。

它拥有两个限制：

1. 必须要指定容器容器策略：OnFailure、Never
2. 执行失败的次数也是受限制的。默认是6次。字数可以通过添加 backoffLimit 来自定义失败次数
3. 跟新yaml文件要先删除任务。再更新。不能动态更新。

5、job

job分为两类：

job：普通任务

cronjob：定时任务

job的作用：执行只需要一次性的任务

适用于脚本需要执行、数据库迁移、视频解码等等业务

对K8S系统来说，既然定义了是job，你只需要执行一次，或者指定次数即可，不能一直允许

第一点：必须要指定容器的重启策略（只能是Onfailure、Never）

第二点：执行失败的次数也是受限的。默认是6次

第三点：更新yaml文件要先删除任务，再更新。他不能动态更新

apiVersion: batch/v1
kind: Job
metadata:
  name: centos

spec:
  template:
    spec:
      containers:
      - name: centos
        image: centos:7
        command: ["/bin/bash", "-c", "test -e /etc/passwd"]
      restartPolicy: Never
  backoffLimit: 4
#允许任务失败的次数是4次，4次到了之后，restartPolicy的策略，来进行容器的重启或者不重启

backoffLimit: 4

失败四次之后才会执行Never

6、 cronjob

cronjob：周期性执行任务，定时执行。和linux的crontab含义是一样的。语法一样都是分时日月周

应用场景：定时备份、通知作用、定时检查(结合探针一起布置设定多长时间执行一次)

1. 必须要指定容器容器策略：OnFailure、Never
2. 执行失败的次数也是受限制的。默认是3次。
3. 跟新yaml文件要先删除任务。再更新。不能动态更新。

实验举例：

apiVersion: batch/v1
kind: Job
metadata:
  name: centos
spec:
  template:
    spec:
      containers:
      - name: centos
        image: centos:7
        command: ["/bin/bash", "-c", "test -e /etc/passwd"]
#定义一个任务
#Job类型的参数必须要设置重启策略。只支持“OnFailure、Never”两种策略
      restartPolicy: Never
#指定重启策略
  backoffLimit: 4
#定义重启次数。如果不加默认6次
#允许任务失败的次数是4次。
#当达到4次之后。根据容器的重启策略restartPolicy来进行容器的重启或者是不重启。

kubectl delete cronjobs.batch hello
#删除定时任务