kubernetes资源--Pod解析

已于 2023-08-24 22:24:25 修改
阅读量335 收藏
点赞数
文章标签： kubernetes 容器 centos linux
于 2023-08-01 01:53:50 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/weixin_73882207/article/details/132024782
版权

一、Pod结构

在Kubernetes中，每个Pod中都可以包含一个或者多个容器，这些容器可以分为两类：

  • 用户程序所在的容器，数量可多可少

  • Pause容器，这是每个Pod都会有的一个根容器，它的作用有两个：

    • 可以以它为依据，评估整个Pod的健康状态

    • 可以在根容器上设置Ip地址，其它容器都此Ip（Pod IP），以实现Pod内部的网路通信

这里是Pod内部的通讯，Pod的之间的通讯采用虚拟二层网络技术来实现，当前环境用的是Flannel

8a3e79436bc542ae95f61bdac5a39147.png 

 

 

二、Pod定义

为了解清楚Pod这种资源，就要先了解它的资源属性

下面是Pod的资源清单：

apiVersion: v1     #必选，版本号，例如v1
kind: Pod       　 #必选，资源类型，例如 Pod
metadata:       　 #必选，元数据
  name: string     #必选，Pod名称
  namespace: string  #Pod所属的命名空间,默认为"default"
  labels:       　　  #自定义标签列表
    - name: string      　          
spec:  #必选，Pod中容器的详细定义
  containers:  #必选，Pod中容器列表
  - name: string   #必选，容器名称
    image: string  #必选，容器的镜像名称
    imagePullPolicy: [ Always|Never|IfNotPresent ]  #获取镜像的策略 
    command: [string]   #容器的启动命令列表，如不指定，使用打包时使用的启动命令
    args: [string]      #容器的启动命令参数列表
    workingDir: string  #容器的工作目录
    volumeMounts:       #挂载到容器内部的存储卷配置
    - name: string      #引用pod定义的共享存储卷的名称，需用volumes[]部分定义的的卷名
      mountPath: string #存储卷在容器内mount的绝对路径，应少于512字符
      readOnly: boolean #是否为只读模式
    ports: #需要暴露的端口库号列表
    - name: string        #端口的名称
      containerPort: int  #容器需要监听的端口号
      hostPort: int       #容器所在主机需要监听的端口号，默认与Container相同
      protocol: string    #端口协议，支持TCP和UDP，默认TCP
    env:   #容器运行前需设置的环境变量列表
    - name: string  #环境变量名称
      value: string #环境变量的值
    resources: #资源限制和请求的设置
      limits:  #资源限制的设置
        cpu: string     #Cpu的限制，单位为core数，将用于docker run --cpu-shares参数
        memory: string  #内存限制，单位可以为Mib/Gib，将用于docker run --memory参数
      requests: #资源请求的设置
        cpu: string    #Cpu请求，容器启动的初始可用数量
        memory: string #内存请求,容器启动的初始可用数量
    lifecycle: #生命周期钩子
        postStart: #容器启动后立即执行此钩子,如果执行失败,会根据重启策略进行重启
        preStop: #容器终止前执行此钩子,无论结果如何,容器都会终止
    livenessProbe:  #对Pod内各容器健康检查的设置，当探测无响应几次后将自动重启该容器
      exec:       　 #对Pod容器内检查方式设置为exec方式
        command: [string]  #exec方式需要制定的命令或脚本
      httpGet:       #对Pod内个容器健康检查方法设置为HttpGet，需要制定Path、port
        path: string
        port: number
        host: string
        scheme: string
        HttpHeaders:
        - name: string
          value: string
      tcpSocket:     #对Pod内个容器健康检查方式设置为tcpSocket方式
         port: number
       initialDelaySeconds: 0       #容器启动完成后首次探测的时间，单位为秒
       timeoutSeconds: 0    　　    #对容器健康检查探测等待响应的超时时间，单位秒，默认1秒
       periodSeconds: 0     　　    #对容器监控检查的定期探测时间设置，单位秒，默认10秒一次
       successThreshold: 0
       failureThreshold: 0
       securityContext:
         privileged: false
  restartPolicy: [Always | Never | OnFailure]  #Pod的重启策略
  nodeName: <string> #设置NodeName表示将该Pod调度到指定到名称的node节点上
  nodeSelector: obeject #设置NodeSelector表示将该Pod调度到包含这个label的node上
  imagePullSecrets: #Pull镜像时使用的secret名称，以key：secretkey格式指定
  - name: string
  hostNetwork: false   #是否使用主机网络模式，默认为false，如果设置为true，表示使用宿主机网络
  volumes:   #在该pod上定义共享存储卷列表
  - name: string    #共享存储卷名称 （volumes类型有很多种）
    emptyDir: {}       #类型为emtyDir的存储卷，与Pod同生命周期的一个临时目录。为空值
    hostPath: string   #类型为hostPath的存储卷，表示挂载Pod所在宿主机的目录
      path: string      　　        #Pod所在宿主机的目录，将被用于同期中mount的目录
    secret:       　　　#类型为secret的存储卷，挂载集群与定义的secret对象到容器内部
      scretname: string  
      items:     
      - key: string
        path: string
    configMap:         #类型为configMap的存储卷，挂载预定义的configMap对象到容器内部
      name: string
      items:
      - key: string
        path: string
#   可通过一个命令来查看每种资源的可配置项
#   kubectl explain 资源类型         查看某种资源可以配置的一级属性
#   kubectl explain 资源类型.属性     查看属性的子属性
[root@master ~]# kubectl explain pod
KIND:     Pod
VERSION:  v1
FIELDS:
   apiVersion   <string>
   kind <string>
   metadata     <Object>
   spec <Object>
   status       <Object>



#   查看Pod的子属性之一 metadata
[root@master ~]# kubectl explain pod.metadata
KIND:     Pod
VERSION:  v1
RESOURCE: metadata <Object>
FIELDS:
   annotations  <map[string]string>
   clusterName  <string>
   creationTimestamp    <string>
   deletionGracePeriodSeconds   <integer>
   deletionTimestamp    <string>
   finalizers   <[]string>
   generateName <string>
   generation   <integer>
   labels       <map[string]string>
   managedFields        <[]Object>
   name <string>
   namespace    <string>
   ownerReferences      <[]Object>
   resourceVersion      <string>
   selfLink     <string>
   uid  <string>

在kubernetes中基本所有资源的一级属性都是一样的，主要包含5部分：

  • apiVersion <string> 版本，由kubernetes内部定义，版本号必须可以用 kubectl api-versions 查询到

  • kind <string> 类型，由kubernetes内部定义，版本号必须可以用 kubectl api-resources 查询到

  • metadata <Object> 元数据，主要是资源标识和说明，常用的有name、namespace、labels等

  • spec <Object> 描述，这是配置中最重要的一部分，里面是对各种资源配置的详细描述

  • status <Object> 状态信息，里面的内容不需要定义，由kubernetes自动生成

在上面的属性中，spec是接下来研究的重点，继续看下它的常见子属性:

  • containers <[]Object> 容器列表，用于定义容器的详细信息

  • nodeName <String> 根据nodeName的值将pod调度到指定的Node节点上

  • nodeSelector <map[]> 根据NodeSelector中定义的信息选择将该Pod调度到包含这些label的Node 上

  • hostNetwork <boolean> 是否使用主机网络模式，默认为false，如果设置为true，表示使用宿主机网络

  • volumes <[]Object> 存储卷，用于定义Pod上面挂在的存储信息

  • restartPolicy <string> 重启策略，表示Pod在遇到故障的时候的处理策略

 

三、Pod配置

本节主要来研究pod.spec.containers属性，这也是pod配置中最为关键的一项配置。

[root@master ~]# kubectl explain pod.spec.containers
KIND:     Pod
VERSION:  v1
RESOURCE: containers <[]Object>   # 数组，代表可以有多个容器
FIELDS:
   name  <string>     # 容器名称
   image <string>     # 容器需要的镜像地址
   imagePullPolicy  <string> # 镜像拉取策略 
   command  <[]string> # 容器的启动命令列表，如不指定，使用打包时使用的启动命令
   args     <[]string> # 容器的启动命令需要的参数列表
   env      <[]Object> # 容器环境变量的配置
   ports    <[]Object>     # 容器需要暴露的端口号列表
   resources <Object>      # 资源限制和资源请求的设置

1.基本配置

创建pod-base.yaml文件，内容如下：

apiVersion: v1
kind: Pod
metadata:
  name: pod-base
  namespace: dev
  labels:
    user: heima
spec:
  containers:
  - name: nginx
    image: nginx:1.17.1
  - name: busybox
    image: busybox:1.30

上面定义了一个比较简单Pod的配置，里面有两个容器：

  • nginx：用1.17.1版本的nginx镜像创建，（nginx是一个轻量级web容器）

  • busybox：用1.30版本的busybox镜像创建，（busybox是一个小巧的linux命令集合）

 

# 创建Pod
kubectl apply -f pod-base.yaml

0b7d3d2fbe4649ee92085f9af125e8fc.png

 

# 查看Pod状况
# READY 1/2 : 表示当前Pod中有2个容器，其中1个准备就绪，1个未就绪
# RESTARTS  : 重启次数，因为有1个容器故障了，Pod一直在重启试图恢复它
kubectl get pod -n dev

5bf42ba508004b199adec8b86fb7c176.png

 

# 可以通过describe查看内部的详情
# 此时已经运行起来了一个基本的Pod，虽然它暂时有问题
kubectl describe pod pod-base -n dev

108afb4b09ed44fe93c7a60334805b8c.png

 

2.镜像拉取

创建pod-imagepullpolicy.yaml文件，内容如下：

apiVersion: v1
kind: Pod
metadata:
  name: pod-imagepullpolicy
  namespace: dev
spec:
  containers:
  - name: nginx
    image: nginx:1.17.2
    imagePullPolicy: Never # 用于设置镜像拉取策略
  - name: busybox
    image: busybox:1.30

imagePullPolicy，用于设置镜像拉取策略，kubernetes支持配置三种拉取策略：

  • Always：总是从远程仓库拉取镜像（一直远程下载）

  • IfNotPresent：本地有则使用本地镜像，本地没有则从远程仓库拉取镜像（本地有就本地 本地没远程下载）

  • Never：只使用本地镜像，从不去远程仓库拉取，本地没有就报错 （一直使用本地）

默认值说明：

如果镜像tag为具体版本号， 默认策略是：IfNotPresent

如果镜像tag为：latest（最终版本） ，默认策略是always

 

# 创建Pod
kubectl create -f pod-imagepullpolicy.yaml

4799d452073640078ac449cb532658c4.png

 

# 查看Pod
kubectl get pods -n dev

09d91007ce3946ce8bc53b4f8aef11be.png

 可以看到pod里面的两个容器都没准备好

 

# 查看Pod详情
# 此时明显可以看到nginx镜像有一步Pulling image "nginx:1.17.2"的过程
kubectl describe pod pod-imagepullpolicy -n dev

e96600940a724ca4a373c8e6e00e08be.png

 因为镜像拉取策略的原因，再加上本机本身就不存在1.17.2版本的nginx，所以容器启动失败

 

3.启动命令

前面的案例中，一直有一个问题没有解决，就是的busybox容器一直没有成功运行，那么到底是什么原因导致这个容器的故障呢？

原来busybox并不是一个程序，而是类似于一个工具类的集合，kubernetes集群启动管理后，它会自动关闭。解决方法就是让其一直在运行，这就用到了command配置。

创建pod-command.yaml文件，内容如下：

apiVersion: v1
kind: Pod
metadata:
  name: pod-command
  namespace: dev
spec:
  containers:
  - name: nginx
    image: nginx:1.17.1
  - name: busybox
    image: busybox:1.30
    command: ["/bin/sh","-c","touch /tmp/hello.txt;while true;do /bin/echo $(date +%T) >> /tmp/hello.txt; sleep 3; done;"]

command，用于在pod中的容器初始化完毕之后运行一个命令。

稍微解释下上面命令的意思：

"/bin/sh","-c", 使用sh执行命令

touch /tmp/hello.txt; 创建一个/tmp/hello.txt 文件

while true;do /bin/echo $(date +%T) >> /tmp/hello.txt; sleep 3; done; 每隔3秒向文件中写入当前时间

 

# 创建Pod
kubectl create  -f pod-command.yaml

40934c558bac4b1da368c5ba9e4a0171.png

 

# 查看Pod状态
# 此时发现两个pod都正常运行了
kubectl get pods pod-command -n dev

32c7fa766bab44ba88b397246cf54fc1.png

 

# 进入pod中的busybox容器，查看文件内容
# 补充一个命令: kubectl exec  pod名称 -n 命名空间 -it -c 容器名称 /bin/sh  在容器内部执行命令
# 使用这个命令就可以进入某个容器的内部，然后进行相关操作了
kubectl exec pod-command -n dev -it -c busybox /bin/sh

db03fc1512364c13a90fa9255cc8f52e.png

 特别说明：
    通过上面发现command已经可以完成启动命令和传递参数的功能，为什么这里还要提供一个args选项，用于传递参数呢?这其实跟docker有点关系，kubernetes中的command、args两项其实是实现覆盖Dockerfile中ENTRYPOINT的功能。
 1 如果command和args均没有写，那么用Dockerfile的配置。
 2 如果command写了，但args没有写，那么Dockerfile默认的配置会被忽略，执行输入的command
 3 如果command没写，但args写了，那么Dockerfile中配置的ENTRYPOINT的命令会被执行，使用当前args的参数
 4 如果command和args都写了，那么Dockerfile的配置被忽略，执行command并追加上args参数

 

4. 环境变量

创建pod-env.yaml文件，内容如下：

apiVersion: v1
kind: Pod
metadata:
  name: pod-env
  namespace: dev
spec:
  containers:
  - name: busybox
    image: busybox:1.30
    command: ["/bin/sh","-c","while true;do /bin/echo $(date +%T);sleep 60; done;"]
    env: # 设置环境变量列表
    - name: "username"
      value: "admin"
    - name: "password"
      value: "123456"

env，环境变量，用于在pod中的容器设置环境变量

 

# 创建Pod
kubectl create -f pod-env.yaml

1a37e73ad56f4ee4af8a3109cb6c6089.png

 

# 进入容器，输出环境变量
kubectl exec pod-env -n dev -c busybox -it /bin/sh

04415853cdbe4d71ade9c27a8029e78e.png

 

5.端口设置

容器的端口设置，也就是containers的ports选项。

首先看下ports支持的子选项：

[root@master ~]# kubectl explain pod.spec.containers.ports
KIND:     Pod
VERSION:  v1
RESOURCE: ports <[]Object>
FIELDS:
   name         <string>  # 端口名称，如果指定，必须保证name在pod中是唯一的		
   containerPort<integer> # 容器要监听的端口(0<x<65536)
   hostPort     <integer> # 容器要在主机上公开的端口，如果设置，主机上只能运行容器的一个副本(一般省略) 
   hostIP       <string>  # 要将外部端口绑定到的主机IP(一般省略)
   protocol     <string>  # 端口协议。必须是UDP、TCP或SCTP。默认为“TCP”。

 

编写一个测试案例，创建pod-ports.yaml

apiVersion: v1
kind: Pod
metadata:
  name: pod-ports
  namespace: dev
spec:
  containers:
  - name: nginx
    image: nginx:1.17.1
    ports: # 设置容器暴露的端口列表
    - name: nginx-port
      containerPort: 80
      protocol: TCP

 

# 创建Pod
kubectl create -f pod-ports.yaml

91b8c695776a42c280881d5ecfe8d01b.png

 

 

# 查看pod
# 在下面可以明显看到配置信息
kubectl describe pods pod-ports -n dev

76bac8a7ec9c4444bfc847dde580c6c6.png

访问容器中的程序需要使用的是Podip:containerPort

 

6.资源配额

容器中的程序要运行，肯定是要占用一定资源的，比如cpu和内存等，如果不对某个容器的资源做限制，那么它就可能吃掉大量资源，导致其它容器无法运行。针对这种情况，kubernetes提供了对内存和cpu的资源进行配额的机制，这种机制主要通过resources选项实现，他有两个子选项：

  • limits：用于限制运行时容器的最大占用资源，当容器占用资源超过limits时会被终止，并进行重启

  • requests ：用于设置容器需要的最小资源，如果环境资源不够，容器将无法启动

可以通过上面两个选项设置资源的上下限。

 

编写一个测试案例，创建pod-resources.yaml

apiVersion: v1
kind: Pod
metadata:
  name: pod-resources
  namespace: dev
spec:
  containers:
  - name: nginx
    image: nginx:1.17.1
    resources: # 资源配额
      limits:  # 限制资源（上限）
        cpu: "2" # CPU限制，单位是core数
        memory: "10Gi" # 内存限制
      requests: # 请求资源（下限）
        cpu: "1"  # CPU限制，单位是core数
        memory: "10Mi"  # 内存限制

在这对cpu和memory的单位做一个说明：

  • cpu：core数，可以为整数或小数

  • memory： 内存大小，可以使用Gi、Mi、G、M等形式

 

# 运行Pod
kubectl create  -f pod-resources.yaml

679cfeb117164c6d82899d9a02372550.png

 

# 查看发现pod运行正常
kubectl get pod pod-resources -n dev

0144ff20cd264d7489af53de70a93301.png

 

# 接下来，删除Pod
kubectl delete  -f pod-resources.yaml

2cac1614d7d14baf84d7456fe2429ae6.png

 

# 编辑pod，修改resources.requests.memory的值为10Gi
vim pod-resources.yaml

a83fc49c10a345b1ba079b4ce039e6e1.png

 

# 再次启动pod
kubectl create  -f pod-resources.yaml

# 查看Pod状态，发现Pod启动失败
kubectl get pod pod-resources -n dev

ccda2b867e72475c8c73e47633b159bc.png

 

# 查看pod详情会发现，如下提示
kubectl describe pod pod-resources -n dev

20a010669f2b41b6aeb0bf75d68bf383.png

没有一个节点满足条件

 

四、Pod生命周期

我们一般将pod对象从创建至终的这段时间范围称为pod的生命周期，它主要包含下面的过程：

  • pod创建过程

  • 运行初始化容器（init container）过程

  • 运行主容器（main container）

    • 容器启动后钩子（post start）、容器终止前钩子（pre stop）

    • 容器的存活性探测（liveness probe）、就绪性探测（readiness probe）

  • pod终止过程

90dab574389a444a9536112c33648927.png 

在整个生命周期中，Pod会出现5种状态（相位），分别如下：

  • 挂起（Pending）：apiserver已经创建了pod资源对象，但它尚未被调度完成或者仍处于下载镜像的过程中

  • 运行中（Running）：pod已经被调度至某节点，并且所有容器都已经被kubelet创建完成

  • 成功（Succeeded）：pod中的所有容器都已经成功终止并且不会被重启

  • 失败（Failed）：所有容器都已经终止，但至少有一个容器终止失败，即容器返回了非0值的退出状态

  • 未知（Unknown）：apiserver无法正常获取到pod对象的状态信息，通常由网络通信失败所导致

 

1.创建和终止

1）pod的创建过程

  1. 用户通过kubectl或其他api客户端提交需要创建的pod信息给apiServer

  2. apiServer开始生成pod对象的信息，并将信息存入etcd，然后返回确认信息至客户端

  3. apiServer开始反映etcd中的pod对象的变化，其它组件使用watch机制来跟踪检查apiServer上的变动

  4. scheduler发现有新的pod对象要创建，开始为Pod分配主机并将结果信息更新至apiServer

  5. node节点上的kubelet发现有pod调度过来，尝试调用docker启动容器，并将结果回送至apiServer

  6. apiServer将接收到的pod状态信息存入etcd中

86b2ef3d00d54b92b6de6ad450eb99ea.png

 

2）pod的终止过程

  1. 用户向apiServer发送删除pod对象的命令

  2. apiServcer中的pod对象信息会随着时间的推移而更新，在宽限期内（默认30s），pod被视为dead

  3. 将pod标记为terminating状态

  4. kubelet在监控到pod对象转为terminating状态的同时启动pod关闭过程

  5. 端点控制器监控到pod对象的关闭行为时将其从所有匹配到此端点的service资源的端点列表中移除

  6. 如果当前pod对象定义了preStop钩子处理器，则在其标记为terminating后即会以同步的方式启动执行

  7. pod对象中的容器进程收到停止信号

  8. 宽限期结束后，若pod中还存在仍在运行的进程，那么pod对象会收到立即终止的信号

  9. kubelet请求apiServer将此pod资源的宽限期设置为0从而完成删除操作，此时pod对于用户已不可见

 

2.初始化容器

初始化容器是在pod的主容器启动之前要运行的容器，主要是做一些主容器的前置工作，它具有两大特征：

  1. 初始化容器必须运行完成直至结束，若某初始化容器运行失败，那么kubernetes需要重启它直到成功完成

  2. 初始化容器必须按照定义的顺序执行，当且仅当前一个成功之后，后面的一个才能运行

初始化容器有很多的应用场景，下面列出的是最常见的几个：

  • 提供主容器镜像中不具备的工具程序或自定义代码

  • 初始化容器要先于应用容器串行启动并运行完成，因此可用于延后应用容器的启动直至其依赖的条件得到满足

接下来做一个案例，模拟下面这个需求：

假设要以主容器来运行nginx，但是要求在运行nginx之前先要能够连接上mysql和redis所在服务器

为了简化测试，事先规定好mysql(192.168.109.201)和redis(192.168.109.202)服务器的地址

 

创建pod-initcontainer.yaml，内容如下：

apiVersion: v1
kind: Pod
metadata:
  name: pod-initcontainer
  namespace: dev
spec:
  containers:
  - name: main-container
    image: nginx:1.17.1
    ports: 
    - name: nginx-port
      containerPort: 80
  initContainers:
  - name: test-mysql
    image: busybox:1.30
    command: ['sh', '-c', 'until ping 192.168.109.201 -c 1 ; do echo waiting for mysql...; sleep 2; done;']
  - name: test-redis
    image: busybox:1.30
    command: ['sh', '-c', 'until ping 192.168.109.202 -c 1 ; do echo waiting for reids...; sleep 2; done;']

 

# 创建pod
kubectl create -f pod-initcontainer.yaml

6a53ee48179a489f8c0995e624484af6.png

 

# 查看pod状态
# 发现pod卡在启动第一个初始化容器过程中，后面的容器不会运行
kubectl get pod  pod-initcontainer -n dev

42125521528a4f8c9e32343622e59056.png

 

# 接下来新开一个shell，为当前服务器新增两个ip，观察pod的变化
ifconfig ens33:1 192.168.109.201 netmask 255.255.255.0 up
ifconfig ens33:2 192.168.109.202 netmask 255.255.255.0 up

06a6e94f62064ae2bec018985d909e60.png

 

# 动态查看pod
kubectl get pods pod-initcontainer -n dev -w

5a5fc52df78f42e0b4cf290c4bc436ca.png

 可以看到容器逐渐初始化完成，状态变成running

 

3.钩子函数

钩子函数能够感知自身生命周期中的事件，并在相应的时刻到来时运行用户指定的程序代码。

kubernetes在主容器的启动之后和停止之前提供了两个钩子函数：

  • post start：容器创建之后执行，如果失败了会重启容器

  • pre stop ：容器终止之前执行，执行完成之后容器将成功终止，在其完成之前会阻塞删除容器的操作

 

钩子处理器支持使用下面三种方式定义动作：

  • Exec命令：在容器内执行一次命令

……
  lifecycle:
    postStart: 
      exec:
        command:
        - cat
        - /tmp/healthy
……

 

  • TCPSocket：在当前容器尝试访问指定的socket

……      
  lifecycle:
    postStart:
      tcpSocket:
        port: 8080
……

 

  • HTTPGet：在当前容器中向某url发起http请求

……
  lifecycle:
    postStart:
      httpGet:
        path: / #URI地址
        port: 80 #端口号
        host: 192.168.5.3 #主机地址
        scheme: HTTP #支持的协议，http或者https
……

 

接下来，以exec方式为例，演示下钩子函数的使用，创建pod-hook-exec.yaml文件，内容如下：

apiVersion: v1
kind: Pod
metadata:
  name: pod-hook-exec
  namespace: dev
spec:
  containers:
  - name: main-container
    image: nginx:1.17.1
    ports:
    - name: nginx-port
      containerPort: 80
    lifecycle:
      postStart: 
        exec: # 在容器启动的时候执行一个命令，修改掉nginx的默认首页内容
          command: ["/bin/sh", "-c", "echo postStart... > /usr/share/nginx/html/index.html"]
      preStop:
        exec: # 在容器停止之前停止nginx服务
          command: ["/usr/sbin/nginx","-s","quit"]

 

# 创建pod
kubectl create -f pod-hook-exec.yaml

966d887fece8429f809836406332026c.png

 

# 查看pod
kubectl get pods  pod-hook-exec -n dev -o wide

1631141ef65146d2bcd81dbdcc6a22f2.png

 

# 访问pod
curl 10.244.1.27:80

fc6ae82f73b149148fc7bc6384365589.png

 

4.容器探测

容器探测用于检测容器中的应用实例是否正常工作，是保障业务可用性的一种传统机制。如果经过探测，实例的状态不符合预期，那么kubernetes就会把该问题实例" 摘除 "，不承担业务流量。kubernetes提供了两种探针来实现容器探测，分别是：

  • liveness probes：存活性探针，用于检测应用实例当前是否处于正常运行状态，如果不是，k8s会重启容器

  • readiness probes：就绪性探针，用于检测应用实例当前是否可以接收请求，如果不能，k8s不会转发流量

livenessProbe 决定是否重启容器，readinessProbe 决定是否将请求转发给容器。

 上面两种探针目前均支持三种探测方式：

  • Exec命令：在容器内执行一次命令，如果命令执行的退出码为0，则认为程序正常，否则不正常

……
  livenessProbe:
    exec:
      command:
      - cat
      - /tmp/healthy
……

  • TCPSocket：将会尝试访问一个用户容器的端口，如果能够建立这条连接，则认为程序正常，否则不正常

……      
  livenessProbe:
    tcpSocket:
      port: 8080
……

  • HTTPGet：调用容器内Web应用的URL，如果返回的状态码在200和399之间，则认为程序正常，否则不正常

……
  livenessProbe:
    httpGet:
      path: / #URI地址
      port: 80 #端口号
      host: 127.0.0.1 #主机地址
      scheme: HTTP #支持的协议，http或者https
……

 

下面以liveness probes为例，做几个演示：

方式一：Exec

创建pod-liveness-exec.yaml

apiVersion: v1
kind: Pod
metadata:
  name: pod-liveness-exec
  namespace: dev
spec:
  containers:
  - name: nginx
    image: nginx:1.17.1
    ports: 
    - name: nginx-port
      containerPort: 80
    livenessProbe:
      exec:
        command: ["/bin/cat","/tmp/hello.txt"] # 执行一个查看文件的命令

 

# 创建Pod
kubectl create -f pod-liveness-exec.yaml

731d9521630b442e84e27ff625c28caa.png

 

# 查看Pod详情
kubectl describe pods pod-liveness-exec -n dev

7103e6cec503406680fdecf9a790f1b2.png观察上面的信息就会发现nginx容器启动之后就进行了健康检查。
检查失败之后，容器被kill掉，然后尝试进行重启（这是重启策略的作用，后面讲解）

 

# 稍等一会之后，再观察pod信息，就可以看到RESTARTS不是0，而是一直增长
kubectl get pods pod-liveness-exec -n dev

d598472c703442a788890af7a9ac055e.png

 

# 删除pod，修改yaml文件
kubectl delete -f pod-liveness-exec.yaml

1383076626b04426adba6069b326d570.png

vim pod-liveness-exec.yaml

e9ffe94798b748688d399f751e38e48e.png 执行命令修改为查看/tmp目录

 

# 重新创建Pod
kubectl create -f pod-liveness-exec.yaml
# 再观察pod信息
kubectl get pods pod-liveness-exec -n dev

48dde652c7a549b88a9903cac6036096.png

 已经没有再重启了

 

方式二：TCPSocket

创建pod-liveness-tcpsocket.yaml

apiVersion: v1
kind: Pod
metadata:
  name: pod-liveness-tcpsocket
  namespace: dev
spec:
  containers:
  - name: nginx
    image: nginx:1.17.1
    ports: 
    - name: nginx-port
      containerPort: 80
    livenessProbe:
      tcpSocket:
        port: 8080 # 尝试访问8080端口

 

# 创建Pod
kubectl create -f pod-liveness-tcpsocket.yaml

83fa7eebaacd4243ba54ce9f6fe85e2d.png

# 查看Pod详情
kubectl describe pods pod-liveness-tcpsocket -n dev

e6fd6a650b0f461fabf8bf3c708515f4.png

观察上面的信息，发现尝试访问8080端口,但是失败了

 

# 再稍等一会之后，再观察pod信息，就可以看到RESTARTS不再是0，而是一直增长
kubectl get pods pod-liveness-tcpsocket  -n dev

37088e96ba954bfdb38f3fa29778caba.png

 

# 删除Pod，修改yaml文件
kubectl delete -f pod-liveness-tcpsocket.yaml

318064a5c7e241cb9e61ee193aafa829.png

vim pod-liveness-tcpsocket.yaml

 7a58ed5693064791ba319f82287c9fc6.png

 端口修改为80

 

# 重新创建Pod
kubectl create -f pod-liveness-tcpsocket.yaml
# 再观察pod信息
kubectl get pods pod-liveness-tcpsocket  -n dev

ddb527fb51ca4ceb8a02f3a974647787.png

 已经没有重启了

 

方式三：HTTPGet

创建pod-liveness-httpget.yaml

apiVersion: v1
kind: Pod
metadata:
  name: pod-liveness-httpget
  namespace: dev
spec:
  containers:
  - name: nginx
    image: nginx:1.17.1
    ports:
    - name: nginx-port
      containerPort: 80
    livenessProbe:
      httpGet:  # 其实就是访问http://host:port/path
        scheme: HTTP #支持的协议，http或者https
        port: 80 #端口号
        path: /hello #URI地址

 

# 创建Pod
kubectl create -f pod-liveness-httpget.yaml

f2825ec9680240749064db037b70656e.png

 

# 查看Pod详情
kubectl describe pod pod-liveness-httpget -n dev

56e5443bfb854bf5bd42911a78c7feb1.png

 观察上面信息，尝试访问路径，但是未找到,出现404错误

 

# 稍等一会之后，再观察pod信息，就可以看到RESTARTS不再是0，而是一直增长
kubectl get pod pod-liveness-httpget -n dev

7bfb348497c34a7a9c0e98e384ce0dcf.png

 

# 删除Pod，修改yaml文件
kubectl delete -f pod-liveness-httpget.yaml

5e96bf0233cb45008e575e0230ada856.png

vim pod-liveness-httpget.yaml

76f1803cf566432a9fbc32405562f816.png

访问的路径改为根目录

 

# 重新创建Pod
kubectl create -f pod-liveness-httpget.yaml
# 查看Pod
kubectl get pods pod-liveness-httpget -n dev

b8d39ab067f741aaae59469abf0580e7.png

 已经没有再重启了

 

至此，已经使用liveness Probe演示了三种探测方式，但是查看livenessProbe的子属性，会发现除了这三种方式，还有一些其他的配置，在这里一并解释下：

[root@master ~]# kubectl explain pod.spec.containers.livenessProbe
FIELDS:
   exec <Object>  
   tcpSocket    <Object>
   httpGet      <Object>
   initialDelaySeconds  <integer>  # 容器启动后等待多少秒执行第一次探测
   timeoutSeconds       <integer>  # 探测超时时间。默认1秒，最小1秒
   periodSeconds        <integer>  # 执行探测的频率。默认是10秒，最小1秒
   failureThreshold     <integer>  # 连续探测失败多少次才被认定为失败。默认是3。最小值是1
   successThreshold     <integer>  # 连续探测成功多少次才被认定为成功。默认是1

 

5.重启策略

在上一节中，一旦容器探测出现了问题，kubernetes就会对容器所在的Pod进行重启，其实这是由pod的重启策略决定的，pod的重启策略有 3 种，分别如下：

  • Always ：容器失效时，自动重启该容器，这也是默认值。

  • OnFailure ： 容器终止运行且退出码不为0时重启

  • Never ： 不论状态为何，都不重启该容器

重启策略适用于pod对象中的所有容器，首次需要重启的容器，将在其需要时立即进行重启，随后再次需要重启的操作将由kubelet延迟一段时间后进行，且反复的重启操作的延迟时长以此为10s、20s、40s、80s、160s和300s，300s是最大延迟时长。

 

创建pod-restartpolicy.yaml：

apiVersion: v1
kind: Pod
metadata:
  name: pod-restartpolicy
  namespace: dev
spec:
  containers:
  - name: nginx
    image: nginx:1.17.1
    ports:
    - name: nginx-port
      containerPort: 80
    livenessProbe:
      httpGet:
        scheme: HTTP
        port: 80
        path: /hello
  restartPolicy: Always # 设置重启策略为Always

 

# 创建Pod
kubectl create -f pod-restartpolicy.yaml

b2f74f93eb6e4c61b90eb5ac61a21451.png

 

# 动态查看Pod详情，发现nginx容器重启
kubectl  get pods pod-restartpolicy  -n dev -o wide

9c231a45c36c4dacb93476095d723fc9.png

 

# 删除Pod
kubectl delete -f pod-restartpolicy.yaml

6f318c6757014602b97d1205ac8f2648.png

# 修改yaml文件
vim pod-restartpolicy.yaml

015fce5fc33646dba61a2b35bfeb26cc.png

 重启策略改为never

 

# 重新创建Pod
kubectl create -f pod-restartpolicy.yaml

715516e47ba34e2da0176e93f0a84e89.png

 

# 查看Pod状态
kubectl  get pods pod-restartpolicy  -n dev

5fb88de571b342059a5391dd4fe758aa.png  此时容器状态为完成

 

# 查看Pod详情
kubectl  describe pods pod-restartpolicy  -n dev

 

a56e9af515664bd98fff83ab520c58a1.png

探针发现问题，停止容器

 

 

五、Pod调度

在默认情况下，一个Pod在哪个Node节点上运行，是由Scheduler组件采用相应的算法计算出来的，这个过程是不受人工控制的。但是在实际使用中，这并不满足的需求，因为很多情况下，我们想控制某些Pod到达某些节点上，那么应该怎么做呢？这就要求了解kubernetes对Pod的调度规则，kubernetes提供了四大类调度方式：

  • 自动调度：运行在哪个节点上完全由Scheduler经过一系列的算法计算得出

  • 定向调度：NodeName、NodeSelector

  • 亲和性调度：NodeAffinity、PodAffinity、PodAntiAffinity

  • 污点（容忍）调度：Taints、Toleration

 

1.定向调度

定向调度，指的是利用在pod上声明nodeName或者nodeSelector，以此将Pod调度到期望的node节点上。注意，这里的调度是强制的，这就意味着即使要调度的目标Node不存在，也会向上面进行调度，只不过pod运行失败而已。

 

NodeName：

NodeName用于强制约束将Pod调度到指定的Name的Node节点上。这种方式，其实是直接跳过Scheduler的调度逻辑，直接将Pod调度到指定名称的节点。

接下来实验，创建一个pod-nodename.yaml文件

apiVersion: v1
kind: Pod
metadata:
  name: pod-nodename
  namespace: dev
spec:
  containers:
  - name: nginx
    image: nginx:1.17.1
  nodeName: node1 # 指定调度到node1节点上

 

#创建Pod
kubectl create -f pod-nodename.yaml

dfba321a971d4e7aa2278e0b7612108d.png

#查看Pod调度到NODE属性，确实是调度到了node1节点上
kubectl get pods pod-nodename -n dev -o wide

0730e307d6bb4fc7b8b7172ffd9326ce.png

 

# 接下来，删除pod，修改nodeName的值为node3（并没有node3节点）
kubectl delete -f pod-nodename.yaml

cad5fb894995456383de990d7e67b8f6.png

vim pod-nodename.yaml

d790648be73b45dca47af633aa18c5d5.png

 

# 重新创建pod
kubectl create -f pod-nodename.yaml

713dfb2dd1c04103a36f648aebed3479.png

#再次查看，发现已经向Node3节点调度，但是由于不存在node3节点，所以pod无法正常运行
kubectl get pods pod-nodename -n dev -o wide

88f2477e71dd4c22a13cb021c9eee814.png

 可以看到pod确实调度到node3节点，但是无法正常运行

 

NodeSelector：

NodeSelector用于将pod调度到添加了指定标签的node节点上。它是通过kubernetes的label-selector机制实现的，也就是说，在pod创建之前，会由scheduler使用MatchNodeSelector调度策略进行label匹配，找出目标node，然后将pod调度到目标节点，该匹配规则是强制约束。

接下来实验：

# 首先分别为node节点添加标签
kubectl label nodes node1 nodeenv=pro
kubectl label nodes node2 nodeenv=test

2d2d1ba3776c49c59805cf0c7b39ffd6.png

 

 创建一个pod-nodeselector.yaml文件，并使用它创建Pod

apiVersion: v1
kind: Pod
metadata:
  name: pod-nodeselector
  namespace: dev
spec:
  containers:
  - name: nginx
    image: nginx:1.17.1
  nodeSelector: 
    nodeenv: pro # 指定调度到具有nodeenv=pro标签的节点上

 

#创建Pod
kubectl create -f pod-nodeselector.yaml

53ecbb532e7e431482ef8aa173e44e48.png

 

#查看Pod调度到NODE属性，确实是调度到了node1节点上
kubectl get pods pod-nodeselector -n dev -o wide

732461e5d90344e19673f273068547bf.png

 

# 接下来，删除pod，修改nodeSelector的值为nodeenv: pro1（不存在打有此标签的节点）
kubectl delete -f pod-nodeselector.yaml

947561b44f8a481ba842eeb11afc1a1b.png

vim pod-nodeselector.yaml

9bd91bef57544f64b9fb5a8724127b9f.png

 

# 重新创建pro
kubectl create -f pod-nodeselector.yaml

092c3391adf94072a76ad1860a045379.png

 

#再次查看，发现pod无法正常运行,Node的值为none
kubectl get pods -n dev -o wide

b52370fe3dd04694a11caf91025853c2.png

 

# 查看详情,发现node selector匹配失败的提示
kubectl describe pods pod-nodeselector -n dev

f81fd5d776214c93a18217fd43c5f670.png

 

2.亲和性调度

上一节，介绍了两种定向调度的方式，使用起来非常方便，但是也有一定的问题，那就是如果没有满足条件的Node，那么Pod将不会被运行，即使在集群中还有可用Node列表也不行，这就限制了它的使用场景。

基于上面的问题，kubernetes还提供了一种亲和性调度（Affinity）。它在NodeSelector的基础之上的进行了扩展，可以通过配置的形式，实现优先选择满足条件的Node进行调度，如果没有，也可以调度到不满足条件的节点上，使调度更加灵活。

Affinity主要分为三类：

  • nodeAffinity(node亲和性）: 以node为目标，解决pod可以调度到哪些node的问题

  • podAffinity(pod亲和性) : 以pod为目标，解决pod可以和哪些已存在的pod部署在同一个拓扑域中的问题

  • podAntiAffinity(pod反亲和性) : 以pod为目标，解决pod不能和哪些已存在pod部署在同一个拓扑域中的问题

 关于亲和性(反亲和性)使用场景的说明：

亲和性：如果两个应用频繁交互，那就有必要利用亲和性让两个应用的尽可能的靠近，这样可以减少因网络通信而带来的性能损耗。

反亲和性：当应用的采用多副本部署时，有必要采用反亲和性让各个应用实例打散分布在各个node上，这样可以提高服务的高可用性。

 

NodeAffinity：

先来看一下NodeAffinity的可配置项

pod.spec.affinity.nodeAffinity
  requiredDuringSchedulingIgnoredDuringExecution  Node节点必须满足指定的所有规则才可以，相当于硬限制
    nodeSelectorTerms  节点选择列表
      matchFields   按节点字段列出的节点选择器要求列表
      matchExpressions   按节点标签列出的节点选择器要求列表(推荐)
        key    键
        values 值
        operat or 关系符 支持Exists, DoesNotExist, In, NotIn, Gt, Lt


  preferredDuringSchedulingIgnoredDuringExecution 优先调度到满足指定的规则的Node，相当于软限制 (倾向)
    preference   一个节点选择器项，与相应的权重相关联
      matchFields   按节点字段列出的节点选择器要求列表
      matchExpressions   按节点标签列出的节点选择器要求列表(推荐)
        key    键
        values 值
        operator 关系符 支持In, NotIn, Exists, DoesNotExist, Gt, Lt
	weight 倾向权重，在范围1-100。

 关系符的使用说明:

- matchExpressions:
  - key: nodeenv              # 匹配存在标签的key为nodeenv的节点
    operator: Exists
  - key: nodeenv              # 匹配标签的key为nodeenv,且value是"xxx"或"yyy"的节点
    operator: In
    values: ["xxx","yyy"]
  - key: nodeenv              # 匹配标签的key为nodeenv,且value大于"xxx"的节点
    operator: Gt
    values: "xxx"

 

首先演示一下requiredDuringSchedulingIgnoredDuringExecution,

创建pod-nodeaffinity-required.yaml

apiVersion: v1
kind: Pod
metadata:
  name: pod-nodeaffinity-required
  namespace: dev
spec:
  containers:
  - name: nginx
    image: nginx:1.17.1
  affinity:  #亲和性设置
    nodeAffinity: #设置node亲和性
      requiredDuringSchedulingIgnoredDuringExecution: # 硬限制
        nodeSelectorTerms:
        - matchExpressions: # 匹配env的值在["xxx","yyy"]中的标签，实际当前没有这样标签的node
          - key: nodeenv
            operator: In
            values: ["xxx","yyy"]

 

# 创建pod
kubectl create -f pod-nodeaffinity-required.yaml

feebfec0b4b34e94a74d44448e68a47c.png

 

# 查看pod状态 （运行失败）
kubectl get pods pod-nodeaffinity-required -n dev

0733e8f13bcf49dfb5d56998fd515506.png

 

# 查看Pod的详情
# 发现调度失败，提示node选择失败
kubectl describe pod pod-nodeaffinity-required -n dev

465a9ec5a1f14841963c79c171405f04.png

 

# 接下来，删除pod
kubectl delete -f pod-nodeaffinity-required.yaml

7c8679eda6eb4890b81b8f8350e99341.png

# 修改文件，将values: ["xxx","yyy"]------> ["pro","yyy"]
vim pod-nodeaffinity-required.yaml

6e68afc610544ce49e5b29770de90dd4.png

 

# 再次创建pod
kubectl create -f pod-nodeaffinity-required.yaml

0290eee0fc43445eae09abafbe228655.png

 

# 此时查看，发现调度成功，已经将pod调度到了node1上
kubectl get pods pod-nodeaffinity-required -n dev -o wide

90c4c63741ec449a8f37364d1824869e.png

 

接下来再演示一下preferredDuringSchedulingIgnoredDuringExecution，

创建pod-nodeaffinity-preferred.yaml

apiVersion: v1
kind: Pod
metadata:
  name: pod-nodeaffinity-preferred
  namespace: dev
spec:
  containers:
  - name: nginx
    image: nginx:1.17.1
  affinity:  #亲和性设置
    nodeAffinity: #设置node亲和性
      preferredDuringSchedulingIgnoredDuringExecution: # 软限制
      - weight: 1
        preference:
          matchExpressions: # 匹配env的值在["xxx","yyy"]中的标签(当前环境没有)
          - key: nodeenv
            operator: In
            values: ["xxx","yyy"]

 

# 创建pod
kubectl create -f pod-nodeaffinity-preferred.yaml

4841fb4925a74982bf3320af5273aeb1.png

 

# 查看pod状态 （运行成功）
kubectl get pods pod-nodeaffinity-preferred -n dev -o wide

55e9cacb58d24790b280868a1bb6e564.png

NodeAffinity规则设置的注意事项：
    1 如果同时定义了nodeSelector和nodeAffinity，那么必须两个条件都得到满足，Pod才能运行在指定的Node上
    2 如果nodeAffinity指定了多个nodeSelectorTerms，那么只需要其中一个能够匹配成功即可
    3 如果一个nodeSelectorTerms中有多个matchExpressions ，则一个节点必须满足所有的才能匹配成功
    4 如果一个pod所在的Node在Pod运行期间其标签发生了改变，不再符合该Pod的节点亲和性需求，则系统将忽略此变化

 

PodAffinit：

PodAffinity主要实现以运行的Pod为参照，实现让新创建的Pod跟参照pod在一个区域的功能。

首先来看一下PodAffinity的可配置项：

pod.spec.affinity.podAffinity
  requiredDuringSchedulingIgnoredDuringExecution  硬限制
    namespaces       指定参照pod的namespace
    topologyKey      指定调度作用域
    labelSelector    标签选择器
      matchExpressions  按节点标签列出的节点选择器要求列表(推荐)
        key    键
        values 值
        operator 关系符 支持In, NotIn, Exists, DoesNotExist.
      matchLabels    指多个matchExpressions映射的内容

  preferredDuringSchedulingIgnoredDuringExecution 软限制
    podAffinityTerm  选项
      namespaces      
      topologyKey
      labelSelector
        matchExpressions  
          key    键
          values 值
          operator
        matchLabels 
    weight 倾向权重，在范围1-100

 topologyKey用于指定调度时作用域,例如:
    如果指定为kubernetes.io/hostname，那就是以Node节点为区分范围
    如果指定为beta.kubernetes.io/os,则以Node节点的操作系统类型来区分

 

接下来演示requiredDuringSchedulingIgnoredDuringExecution,

首先创建一个参照Pod，pod-podaffinity-target.yaml：

apiVersion: v1
kind: Pod
metadata:
  name: pod-podaffinity-target
  namespace: dev
  labels:
    podenv: pro #设置标签
spec:
  containers:
  - name: nginx
    image: nginx:1.17.1
  nodeName: node1 # 将目标pod名确指定到node1上

 

# 启动目标pod
kubectl create -f pod-podaffinity-target.yaml

39a35dbea0294cfb953144333b402c29.png

 

# 查看pod状况
kubectl get pods  pod-podaffinity-target -n dev -o wide --show-labels

dd65d8ebac6e43fc84721da3772afc6f.png

 

创建pod-podaffinity-required.yaml，内容如下：

apiVersion: v1
kind: Pod
metadata:
  name: pod-podaffinity-required
  namespace: dev
spec:
  containers:
  - name: nginx
    image: nginx:1.17.1
  affinity:  #亲和性设置
    podAffinity: #设置pod亲和性
      requiredDuringSchedulingIgnoredDuringExecution: # 硬限制
      - labelSelector:
          matchExpressions: # 匹配env的值在["xxx","yyy"]中的标签
          - key: podenv
            operator: In
            values: ["xxx","yyy"]
        topologyKey: kubernetes.io/hostname

上面配置表达的意思是：新Pod必须要与拥有标签nodeenv=xxx或者nodeenv=yyy的pod在同一Node上，显然现在没有这样pod，接下来，运行测试一下。

 

# 启动pod
kubectl create -f pod-podaffinity-required.yaml

d571e4e08343413ba4fc86675a36f1f7.png

 

# 查看pod状态，发现未运行
kubectl get pods pod-podaffinity-required -n dev -o wide --show-labels

6f611546c4f04ef08fedd965390bdbb0.png

 

# 查看详细信息
kubectl describe pods pod-podaffinity-required  -n dev

2e811984990541b58f6a76726ec2c37b.png

 

# 接下来修改  values: ["xxx","yyy"]----->values:["pro","yyy"]
# 意思是：新Pod必须要与拥有标签nodeenv=xxx或者nodeenv=yyy的pod在同一Node上
vim pod-podaffinity-required.yaml

e19801de3aa64877b9db2e5bb10543f2.png

 

 

# 删除pod，然后重新创建pod，查看效果
kubectl delete -f  pod-podaffinity-required.yaml
kubectl create -f pod-podaffinity-required.yaml

6ccf491f592742039d47900cd2380f83.png

cd5ff4fe549647b09e003aeebdfbbc04.png

 

# 发现此时Pod运行正常
kubectl get pods pod-podaffinity-required -n dev -o wide --show-labels

ffbacaddfcfa402a96806af76131ae99.png

关于PodAffinity的 preferredDuringSchedulingIgnoredDuringExecution，这里不再演示。

 

PodAntiAffinity：

PodAntiAffinity主要实现以运行的Pod为参照，让新创建的Pod跟参照pod不在一个区域中的功能。

它的配置方式和选项跟PodAffinty是一样的，这里不再做详细解释，直接做一个测试案例。

 

 继续使用上个案例中目标pod

kubectl get pods -n dev -o wide --show-labels

0d91bc80d7b140e3890c7546f0ef1abf.png

 

创建pod-podantiaffinity-required.yaml，内容如下：

apiVersion: v1
kind: Pod
metadata:
  name: pod-podantiaffinity-required
  namespace: dev
spec:
  containers:
  - name: nginx
    image: nginx:1.17.1
  affinity:  #亲和性设置
    podAntiAffinity: #设置pod亲和性
      requiredDuringSchedulingIgnoredDuringExecution: # 硬限制
      - labelSelector:
          matchExpressions: # 匹配podenv的值在["pro"]中的标签
          - key: podenv
            operator: In
            values: ["pro"]
        topologyKey: kubernetes.io/hostname

上面配置表达的意思是：新Pod必须要与拥有标签nodeenv=pro的pod不在同一Node上，运行测试一下。

 

# 创建pod
kubectl create -f pod-podantiaffinity-required.yaml

dd62ae9774af42fd91a7e6ee475d1ad2.png

 

# 查看pod
# 发现调度到了node2上
kubectl get pods -n dev -o wide

902e427f6773406e95f0570df2d4f5b5.png

 

3. 污点和容忍

污点（Taints）

前面的调度方式都是站在Pod的角度上，通过在Pod上添加属性，来确定Pod是否要调度到指定的Node上，其实我们也可以站在Node的角度上，通过在Node上添加污点属性，来决定是否允许Pod调度过来。

Node被设置上污点之后就和Pod之间存在了一种相斥的关系，进而拒绝Pod调度进来，甚至可以将已经存在的Pod驱逐出去。

污点的格式为：key=value:effect, key和value是污点的标签，effect描述污点的作用，支持如下三个选项：

  • PreferNoSchedule：kubernetes将尽量避免把Pod调度到具有该污点的Node上，除非没有其他节点可调度

  • NoSchedule：kubernetes将不会把Pod调度到具有该污点的Node上，但不会影响当前Node上已存在的Pod

  • NoExecute：kubernetes将不会把Pod调度到具有该污点的Node上，同时也会将Node上已存在的Pod驱离

85e9ea9625b648e185a115815be10959.png

 

使用kubectl设置和去除污点的命令示例如下：

# 设置污点
kubectl taint nodes node1 key=value:effect

# 去除污点
kubectl taint nodes node1 key:effect-

# 去除所有污点
kubectl taint nodes node1 key-

 

接下来，演示下污点的效果：

1. 准备节点node1（为了演示效果更加明显，暂时停止node2节点）
2. 为node1节点设置一个污点: `tag=heima:PreferNoSchedule`；然后创建pod1( pod1 可以 )
3. 修改为node1节点设置一个污点: `tag=heima:NoSchedule`；然后创建pod2( pod1 正常 pod2 失败 )
4. 修改为node1节点设置一个污点: `tag=heima:NoExecute`；然后创建pod3 ( 3个pod都失败 )

 

# 为node1设置污点(PreferNoSchedule)
kubectl taint nodes node1 tag=heima:PreferNoSchedule

f4e39e962c4b4799af7204680b279644.png

 

# 创建pod1
kubectl run taint1 --image=nginx:1.17.1 -n dev
kubectl get pods -n dev -o wide

d0ec84c2f2aa4a70bee9b3f3046a9761.png

 

# 为node1设置污点(取消PreferNoSchedule，设置NoSchedule)
kubectl taint nodes node1 tag:PreferNoSchedule-
kubectl taint nodes node1 tag=heima:NoSchedule

cef1886244c94c718476d0483dd78b70.png

 

# 创建pod2
kubectl run taint2 --image=nginx:1.17.1 -n dev
kubectl get pods taint2 -n dev -o wide

a993984cff4b4d65be06532149d74ac0.png

56fce5e8dfa14c13a4717f9778143932.png

 

# 为node1设置污点(取消NoSchedule，设置NoExecute)
kubectl taint nodes node1 tag:NoSchedule-
kubectl taint nodes node1 tag=heima:NoExecute

a7c07e2ade914d0ab4b3591ef629c116.png

 

# 创建pod3
kubectl run taint3 --image=nginx:1.17.1 -n dev
kubectl get pods -n dev -o wide

9d239b0e3e5e408191bc49de7ed56c5e.png

小提示：
    使用kubeadm搭建的集群，默认就会给master节点添加一个污点标记,所以pod就不会调度到master节点上.

 

容忍（Toleration）

上面介绍了污点的作用，我们可以在node上添加污点用于拒绝pod调度上来，但是如果就是想将一个pod调度到一个有污点的node上去，这时候应该怎么做呢？这就要使用到容忍。

b10cc26c7600440f9833231ea244e23c.png 

 污点就是拒绝，容忍就是忽略，Node通过污点拒绝pod调度上去，Pod通过容忍忽略拒绝

 

下面通过一个案例看下效果：

  1. 上一小节，已经在node1节点上打上了NoExecute的污点，此时pod是调度不上去的

  2. 本小节，可以通过给pod添加容忍，然后将其调度上去

创建pod-toleration.yaml,内容如下

apiVersion: v1
kind: Pod
metadata:
  name: pod-toleration
  namespace: dev
spec:
  containers:
  - name: nginx
    image: nginx:1.17.1
  tolerations:      # 添加容忍
  - key: "tag"        # 要容忍的污点的key
    operator: "Equal" # 操作符
    value: "heima"    # 容忍的污点的value
    effect: "NoExecute"   # 添加容忍的规则，这里必须和标记的污点规则相同

 6ccd452e743b49c8b69e0a63aad15917.png

 但是先不添加容忍

 

# 创建pod
kubectl create -f pod-toleration.yaml

7591c1a15cf549f5b444673841709cb9.png

 

# 添加容忍之前的pod状态
kubectl get pods -n dev

ae7602e75cb04b6695926260f74d9ccf.png

 

# 删除pod，修改yaml文件添加容忍
kubectl delete -f pod-toleration.yaml
vim pod-toleration.yaml

31a5523abb574376a0bfe2587e29b62d.png

309b362500aa4a4498de854ec92a051d.png

 

# 重新创建pod，查看添加容忍之后的pod状态
kubectl create -f pod-toleration.yaml
kubectl get pods -n dev -o wide

7990746f25c24d44a3d1f40f0a9e410b.png

 

最后再看一下容忍的详细配置:

[root@k8s-master01 ~]# kubectl explain pod.spec.tolerations
......
FIELDS:
   key       # 对应着要容忍的污点的键，空意味着匹配所有的键
   value     # 对应着要容忍的污点的值
   operator  # key-value的运算符，支持Equal和Exists（默认）
   effect    # 对应污点的effect，空意味着匹配所有影响
   tolerationSeconds   # 容忍时间, 当effect为NoExecute时生效，表示pod在Node上的停留时间

 

 

 

 

 

 

 

 

 

 

 

 

 

03.Pod资源详解
weixin_45898396的博客
11-12 971
Pod是Kubernetes最核心的、最基础的资源。本篇干货满满，建议先收藏！
【云原生】Kubernetes----POD控制器
hy199707的博客
06-01 951
在Kubernetes（K8s）的庞大生态系统中，Pod控制器是一个核心组件，它负责管理和控制Pod的生命周期。Pod是Kubernetes中最小的可部署计算单元，而Pod控制器则确保Pod按照预期的状态运行，无论面临何种挑战。本文将深入探讨Pod控制器的概念、种类以及它们是如何工作的
pod资源
renren_100的博客
05-24 233
~]# kubectl version 版本1.23.6
Kubernetes Pod Resource和Qos
小楼一夜听春雨，深巷明朝卖杏花
04-13 486
Resource 容器资源配合管理 下面介绍一下 Resource，即：容器的一个资源配置管理。 目前内部支持类型有三种：CPU、内存，以及临时存储。当用户觉得这三种不够，有自己的一些资源，比如说 GPU，或者其他资源，也可以自己来定义，但配置时，指定的数量必须为整数。目前资源配置主要分成 request 和 limit 两种类型，一个是需要的数量，一个是资源的界限。CPU、内存以及临时存储都是在 container 下的 Resource 字段里进行一个声明。 举个例子，wordpress 容器
Kubernetes-Pod-Resources.json
u014692704的博客
03-03 497
{ “__inputs”: [ { “name”: “DS_PROMETHEUS”, “label”: “prometheus”, “description”: “”, “type”: “datasource”, “pluginId”: “prometheus”, “pluginName”: “Prometheus” } ], “__requires”: [ { “type”: “grafana”...
二、Kubernetes中pod的管理及优化
最新发布
luohailin_的博客
09-14 1501
Pod是可以创建和管理Kubernetes计算的最小可部署单元一个Pod代表着集群中运行的一个进程，每个pod都有一个唯一的ip。一个pod类似一个豌豆荚，包含一个或多个容器（通常是docker）多个容器间共享IPC、Network和UTC namespace。
kubernetes-server-linux-amd64.tar.gz
08-28
9. **安装DNS和Dashboard**：Kubernetes DNS提供内部域名解析，Dashboard则提供了Web界面用于集群管理。 10. **安全配置**：确保所有组件都使用安全的配置，如启用TLS通信，限制API访问，以及使用RBAC（Role-Based ...
kubernetes-server-linux-amd64.tar
01-17
3. **kube-scheduler**：负责决定新创建的无状态Pod（Kubernetes的基本调度单元）应被调度到哪个Node上运行，基于资源利用率、亲和性规则等多种因素进行决策。 4. **kubelet**：运行在每个Node上，是Kubernetes与...
Kubernetes--API Server
GaoChuang_的博客
11-06 1431
一、Kubernetes API Server功能 Kubernetes API Server的核心功能是提供Kubernetes各类资源对象(如Pod、RC、Server等)的增、删、改、查及watch等HTTP REST接口，成为集群内各个功能模块之间数据交互和通信中心枢纽，是整个系统的数据总线和数据中心。除此之外，它还是集群管理的API入口，是资源配额控制的入口，提供了完备的集群安全机制。 二、Kubernetes API Server核心原理 通过curl 命令访问 API...
Kubernetes --k8s集群部署、Pod管理、资源编写
ly660402的博客
02-22 1053
开始部署k8s集群 清理内存 用此命令扩容 部署多个节点 生命周期 ...
K8s（一）Pod资源——Pod介绍、创建Pod、Pod简单资源配额
qq_72569959的博客
01-14 1830
本文主要介绍了k8s的pod资源，pod资源的创建，pod的简单操作，并介绍了pod的labels和resource字段
pod管理，资源清单
weixin_44791884的博客
04-23 381
pod管理： pod命令集网站： 创建pod应用，例如nginx: 查看信息，此时nginx被分配到节点server4上： 交互式运行busyboxplus(没有指定镜像位置的话，则从harbor仓库下载)，restart=never表示运行一次结束，访问刚才的nginx可以发现，访问成功： 删除pod应用： 测试： 创建两个pod应用，默认情况下主控节点server2不参...
k8s的pod资源管理
qq_43699928的博客
09-19 764
1，陈述式对象配置： 编写develop-ns.yaml，在此之前可以查看kubectl get ns root@node01 ~]# kubectl get ns NAME STATUS AGE default Active 23h kube-node-lease Active 23h kube-public Active...
kubernetes（三）--Pod资源清单及pod控制器
xiaochenwj1995的博客
06-02 759
一、pod的存活性及就绪性探测 1、使用exec command方式探测 [root@master kube_manifest]# vim liveness-exec.yml apiVersion: v1 kind: Pod metadata: name: liveness-exec-pod namespace: default spec: containers: - name: liveness-exec-container image: busybox:latest
Pod资源管理（pod容器分类，k8s添加harbor私库，上传下载私库）
weixin_47151717的博客
10-14 598
Pod资源管理了解podPod容器分类:镜像拉取策略（image PullPolicy）创建pods资源k8s和Harbor服务过程node节点配置连接私有仓库在node节点下载tomcat基于本地镜像创建tomcat上传镜像到harbor创建资源从harbor中下载镜像 了解pod 特点： 最小部署单元 一组容器的集合 一个Pod中的容器共享网络命名空间 Pod是短暂的 Pod容器分类: infrastructure container 基础容器:维护整个Pod网络空间 node节点操
3、Pod资源管理
ljh451321的博客
09-30 1016
Pod的资源管理
云原生工程师-4.kubernetes核心资源-Pod
qq_16688317的博客
03-12 249
云原生工程师-4.kubernetes核心资源-Pod [个人博客](http://47.109.97.22/)
kubernetes五大资源之Pod
阿澈不吃蒜的博客
05-22 163
Pod可以认为是容器的封装，一个Pod中可以存在一个或多个容器。#查看指定kube-system名称空间中的Pod。
Kubernetes----Pod配置资源配额
redrose2100的博客
03-09 1308
一、环境变量配置 Pod中的环境变量配置即env参数 修改pod_base.yaml文件如下，增加env参数 apiVersion: v1 kind: Pod metadata: name: pod-base namespace: dev labels: user: redrose2100 spec: containers: - name: nginx image: nginx:latest imagePullPolicy: IfNotPresent - na
评论 1
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值