Pod详细介绍

目录

Pod

1、Pod基础概念

2、集群中Pod的使用方式

        1)一个Pod中运行一个容器

         2)一个Pod中运行多个容器

3、Pod的类型

        1)控制器管理的Pod

        2)自助式Pod

        3)静态Pod

4、Pod中容器的分类

        1)基础容器(Pause容器)

        2)初始化容器(init容器)

        3)应用容器(业务容器)

5、Pod容器镜像的拉取策略

       1)IfNotPresent

        2)Always

        3)Never

        4)创建镜像拉取策略的测试案例

6、Pod容器的重启策略

        1)Always

        2)OnFailure

        3)Never

7、Pod资源限制

1)Pod 和 容器 的资源请求与限制

2)CPU 资源单位

3)内存 资源单位 

8、健康检查(探针)

        1)探针的三种规则

        2)探针检查的三种方式


Pod

1、Pod基础概念

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

总结:Pod是K8S中创建和管理的最小单元

2、集群中Pod的使用方式

        1)一个Pod中运行一个容器

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

         2)一个Pod中运行多个容器

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

总结:

通常一个Pod最好只包含一个应用容器,一个应用容器最好也只运行一个业务进程

同一个Pod里的容器都是运行在同一个node节点上的,并且共享 net mnt uts pid ipc 命名空间

3、Pod的类型

        1)控制器管理的Pod

        由scheduler进行调度的;被控制器管理的;有自愈能力,一旦Pod挂掉了,会被控制器重启拉起;且有副本管理、滚动更新等功能

 创建命令:

        kubectl create deployment/statefulset/daemonset ....

        2)自助式Pod

        由scheduler进行调度的;不被控制器管理的;没有自愈能力,一旦Pod挂掉了,不会被重启拉起;没有副本管理、滚动更新功能

 创建命令:

        kubectl run deployment/statefulset/daemonset ....

        3)静态Pod

        不由scheduler进行调度的,而是由kubelet自行管理;始终与kubelet运行在同一个node节点上,不能直接删除

 静态Pod的yaml配置文件默认放置在/etc/kubernetes/manifests/目录中,当此目录有Pod的yaml配置文件存在或者消失时kubelet会自动创建或删除静态Pod

4、Pod中容器的分类

        1)基础容器(Pause容器)

作用: 

  • 作为linux命名空间(net mnt uts pid ipc)共享的基础
  • 给Pod里的其它容器提供网络、存储资源的共享

特点:是Pod最先启动的容器

        2)初始化容器(init容器)

作用:

  • 可以为应用容器启动前提供运行依赖环境或工具包
  • 还可以阻塞或延迟应用容器的启动

特点:Pod有多个init容器时,是串行启动的,即要在上一个init容器成功的完成启动、运行、退出后才会启动下一个init容器

        3)应用容器(业务容器)

作用:提供应用程序业务

特点:Pod有多个应用容器时,是并行启动的;应用容器要在所有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容器的名称必须唯一;与任何其它容器共享同一个名称,会在验证时抛出错误。

5、Pod容器镜像的拉取策略

       1)IfNotPresent

        在镜像已经存在的情况下,kubelet 将不再去拉取镜像,仅当本地缺失时才从仓库中拉取,默认的镜像拉取策略

        2)Always

        每次创建 Pod 都会重新拉取一次镜像,不管本地是否有镜像

        3)Never

        Pod 不会主动拉取这个镜像,仅使用本地镜像。

注意:对于标签为“:latest”的镜像文件,其默认的镜像获取策略即为“Always”;而对于其他标签的镜像,其默认策略则为“IfNotPresent”。

        4)创建镜像拉取策略的测试案例

mkdir /data/demo
cd /data/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状态

kubectl describe pod pod-test1    #查看详细的Pod描述

6、Pod容器的重启策略

        1)Always

        不管容器是正常退出还是异常退出,总是重启容器,是默认的策略

        2)OnFailure

        只有当容器异常退出时,才会重启容器,正常退出的容器,不会重启

        3)Never

        不管容器是正常退出还是异常退出,都不会重启容器

注意:K8S 中不支持重启 Pod 资源,只有删除重建。

        在用 yaml 方式创建 Deployment 和 StatefulSet 类型时,restartPolicy 只能是 Alwayskubectl run 创建 Pod 可以选择 Always,OnFailure,Never 三种策略

7、Pod资源限制

        当Pod不设置资源限制时,如果Pod遇到bug或中了病毒,不断地吃资源,将会造成节点宕机,导致其他Pod中的业务故障,是十分不安全的,所以对Pod资源做限制是对其他Pod的一种保障。

Pod资源限制有两个参数指定,分别是request和limit;

  • request设置的资源,代表容器运行所需的最小资源量,也就是节点需要预留的最小资源
  • limit设置的资源,代表容器使用的最大资源量,如果Pod容器使用的资源量超过limit设置的资源量,就会报OOM错误。

如果给容器设置了内存的 limit 值,但未设置内存的 request 值,Kubernetes 会自动为其设置与内存 limit 相匹配的 request 值。 类似的,如果给容器设置了 CPU 的 limit 值但未设置 CPU 的 request 值,则 Kubernetes 自动为其设置 CPU 的 request 值 并使之与 CPU 的 limit 值匹配。

1)Pod 和 容器 的资源请求与限制

spec.containers[].resources.requests.cpu		//定义创建容器时预分配的CPU资源
spec.containers[].resources.requests.memory		//定义创建容器时预分配的内存资源
spec.containers[].resources.limits.cpu			//定义 cpu 的资源上限 
spec.containers[].resources.limits.memory		//定义内存的资源上限

2)CPU 资源单位

        CPU 资源的 request 和 limit 以 cpu 为单位。Kubernetes 中的一个 cpu 相当于1个 vCPU(1个超线程)。

        Kubernetes 也支持小数设置 CPU 的请求。spec.containers[].resources.requests.cpu 为 0.5 的容器能够获得一个 cpu 的一半 CPU 资源(类似于Cgroup对CPU资源的时间分片)。表达式 0.1 等价于表达式 100m(毫核),表示每 1000 毫秒内容器可以使用的 CPU 时间总量为 0.1*1000 毫秒。

        Kubernetes 不允许设置精度小于 1m 的 CPU 资源。

3)内存 资源单位 

        内存的 request 和 limit 以字节为单位。可以以整数表示,或者以10为底数的指数的单位(E、P、T、G、M、K)来表示, 或者以2为底数的指数的单位(Ei、Pi、Ti、Gi、Mi、Ki)来表示。

如:1KB=10^3=1000,1MB=10^6=1000000=1000KB,1GB=10^9=1000000000=1000MB
1KiB=2^10=1024,1MiB=2^20=1048576=1024KiB

示例:小明在买硬盘的时候,操作系统报的数量要比产品标出或商家号称的小一些,主要原因是
标出的是以 MB、GB为单位的,1GB 就是1,000,000,000Byte,而操作系统是以2进制为处理单位
的,因此检查硬盘容量时是以MiB、GiB为单位,1GiB=2^30=1,073,741,824,相比较而言,1GiB
要比1GB多出1,073,741,824-1,000,000,000=73,741,824Byte,所以检测实际结果要比标出的少一些。

下面写一个示例:

//创建一个Pod,并对其设置限制
apiVersion: v1
kind: Pod
metadata:
  name: frontend
spec:
  containers:
  - name: app        //该Pod中的第一个容器
    image: images.my-company.example/app:v4
    env:
    - name: MYSQL_ROOT_PASSWORD
      value: "password"
    resources:
      requests:
        memory: "64Mi"        //设置在该节点上需要预留的内存
        cpu: "250m"        //设置在该节点上需要预留的CPU
      limits:
        memory: "128Mi"    //设置能够使用的最大内存资源
        cpu: "500m"    //设置能够使用的最大CPU资源
  - name: log-aggregator    //该Pod中的第二个容器
    image: images.my-company.example/log-aggregator:v6
    resources:
      requests:
        memory: "64Mi"        //设置在该节点上需要预留的内存
        cpu: "250m"        //设置在该节点上需要预留的CPU
      limits:
        memory: "128Mi"    //设置能够使用的最大内存资源
        cpu: "500m"    //设置能够使用的最大CPU资源

以上例子中的 Pod 有两个容器。每个容器的 request 值为 0.25 cpu 和 64MiB 内存,每个容器的 limit 值为 0.5 cpu 和 128MiB 内存。那么可以认为该 Pod 的总的资源 request 为 0.5 cpu 和 128 MiB 内存,总的资源 limit 为 1 cpu 和 256MiB 内存。

8、健康检查(探针)

探针是由kubelet对容器执行的定期诊断

        1)探针的三种规则

        livenessProbe(存活探针):判断容器是否正在运行

        如果探测失败,则kubelet会杀死容器,并且容器将根据 restartPolicy 来设置 Pod 状态。 如果容器不提供存活探针,则默认状态为Success。

        readinessProbe (就绪探针):判断容器是否准备好接受请求

        如果探测失败,端点控制器将从与 Pod 匹配的所有 service endpoints 中剔除删除该Pod的IP地址。 初始延迟之前的就绪状态默认为Failure。如果容器不提供就绪探针,则默认状态为Success。

        startupProbe(启动探针):判断容器内的应用程序是否已启动

        要针对于不能确定具体启动时间的应用。如果配置了 startupProbe 探测,则在 startupProbe 状态为 Success 之前,其他所有探针都处于无效状态,直到它成功后其他探针才起作用。 如果 startupProbe 失败,kubelet 将杀死容器,容器将根据 restartPolicy 来重启。如果容器没有配置 startupProbe, 则默认状态为 Success。启动探针时1.17版本增加的,1.17版本之前没有存活探针。

:以上规则可以同时定义。在readinessProbe检测成功之前,Pod的running状态是不会变成ready状态的。

        2)探针检查的三种方式

  • exec:在容器内执行指定命令,如果命令退出时返回码为0则认为诊断成功。
  • tcpSocket :对指定端口上的容器的IP地址进行TCP检查(三次握手)。如果端口打开,则诊断被认为是成功的。
  • httpGet :对指定的端口和uri路径上的容器的IP地址执行HTTPGet请求。如果响应的状态码大于等于200且小于400,则诊断被认为是成功的

每次探测都将获得以下三种结果之一

  • 成功(Success):表示容器通过了检测。
  • 失败(Failure):表示容器未通过检测。
  • 未知(Unknown):表示检测没有正常进行。

示例1:exec方式

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-exec
spec:
  containers:
  - name: liveness
    image: k8s.gcr.io/busybox
    args:
    - /bin/sh
    - -c
    - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 60
    livenessProbe:        //存活探测
      exec:                //exec方式
        command:
        - cat
        - /tmp/healthy
      failureThreshold: 1
      initialDelaySeconds: 5
      periodSeconds: 5

#initialDelaySeconds:指定 kubelet 在执行第一次探测前应该等待5秒,即第一次探测是在容器启动后的第6秒才开始执行。默认是 0 秒,最小值是 0。
#periodSeconds:指定了 kubelet 应该每 5 秒执行一次存活探测。默认是 10 秒。最小值是 1。
#failureThreshold: 当探测失败时,Kubernetes 将在放弃之前重试的次数。 存活探测情况下的放弃就意味着重新启动容器。就绪探测情况下的放弃 Pod 会被打上未就绪的标签。默认值是 3。最小值是 1。
#timeoutSeconds:探测的超时后等待多少秒。默认值是 1 秒。最小值是 1。(在 Kubernetes 1.20 版本之前,exec 探针会忽略 timeoutSeconds 探针会无限期地 持续运行,甚至可能超过所配置的限期,直到返回结果为止。)

        可以看到 Pod 中只有一个容器。kubelet 在执行第一次探测前需要等待 5 秒,kubelet 会每 5 秒执行一次存活探测。kubelet 在容器内执行命令 cat /tmp/healthy 来进行探测。如果命令执行成功并且返回值为 0,kubelet 就会认为这个容器是健康存活的。 当到达第 31 秒时,这个命令返回非 0 值,kubelet 会杀死这个容器并重新启动它。

示例2:httpGet方式

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-http
spec:
  containers:
  - name: liveness
    image: k8s.gcr.io/liveness
    args:
    - /server
    livenessProbe:    //存活探测
      httpGet:        //httpGet方式
        path: /healthz
        port: 8080
        httpHeaders:
        - name: Custom-Header
          value: Awesome
      initialDelaySeconds: 3
      periodSeconds: 3

        在这个配置文件中,可以看到 Pod 也只有一个容器。initialDelaySeconds 字段告诉 kubelet 在执行第一次探测前应该等待 3 秒。periodSeconds 字段指定了 kubelet 每隔 3 秒执行一次存活探测。kubelet 会向容器内运行的服务(服务会监听 8080 端口)发送一个 HTTP GET 请求来执行探测。如果服务器上 /healthz 路径下的处理程序返回成功代码,则 kubelet 认为容器是健康存活的。如果处理程序返回失败代码,则 kubelet 会杀死这个容器并且重新启动它。返回码2XX或3XX表示成功,其它返回代码都标示失败

示例3:tcpSocket方式

apiVersion: v1
kind: Pod
metadata:
  name: goproxy
  labels:
    app: goproxy
spec:
  containers:
  - name: goproxy
    image: k8s.gcr.io/goproxy:0.1
    ports:
    - containerPort: 8080
    readinessProbe:    //就绪探测
      tcpSocket:        //tcpSocket方法
        port: 8080
      initialDelaySeconds: 5
      periodSeconds: 10
    livenessProbe:
      tcpSocket:
        port: 8080
      initialDelaySeconds: 15
      periodSeconds: 20

       这个例子同时使用 readinessProbe 和 livenessProbe 探测。kubelet 会在容器启动 5 秒后发送第一个 readinessProbe 探测。这会尝试连接 goproxy 容器的 8080 端口。如果探测成功,kubelet 将继续每隔 10 秒运行一次检测。除了 readinessProbe 探测,这个配置包括了一个 livenessProbe 探测。kubelet 会在容器启动 15 秒后进行第一次 livenessProbe 探测。就像 readinessProbe 探测一样,会尝试连接 goproxy 容器的 8080 端口。如果 livenessProbe 探测失败,这个容器会被重新启动。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 1
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值