K8S-Pod资源对象

一、概述

Pod 是可以在 Kubernetes 中创建和管理的、最小的可部署的计算单元。

Pod （就像在鲸鱼荚或者豌豆荚中）是一组（一个或多个）容器；这些容器共享存储、网络、以及怎样运行这些容器的声明。 Pod 中的容器总是并置（colocated）的并且一同调度，在共享的上下文中运行。 Pod 所建模的是特定于应用的 "逻辑主机"，其中包含一个或多个应用容器，这些容器相对紧密地耦合在一起。在非云环境中，在相同的物理机或虚拟机上运行的应用类似于在同一逻辑主机上运行的云应用。

除了应用容器，Pod 还可以包含在 Pod 启动期间运行的 Init 容器。你也可以在集群支持临时性容器的情况下，为调试的目的注入临时性容器。

Pod 的共享上下文包括一组 Linux 名字空间、控制组（cgroup）和可能一些其他的隔离方面，即用来隔离容器的技术。在 Pod 的上下文中，每个独立的应用可能会进一步实施隔离。

Pod 类似于共享名字空间并共享文件系统卷的一组容器。

二、POD创建过程

第一步：客户端提交创建Pod的请求，可以通过调用API Server的Rest API接口，也可以通过kubectl命令行工具。如kubectl apply -f filename.yaml(资源清单文件)

第二步： apiserver接收到pod创建请求后，会将yaml中的属性信息(metadata)写入etcd。

第三步： apiserver触发watch机制准备创建pod，信息转发给调度器scheduler，调度器用一组规则过滤掉不符合要求的主机，比如Pod指定了所需要的资源量，那么可用资源比Pod需要的资源量少的主机会被过滤掉。调度器使用调度算法选择node，调度器将node信息给apiserver，apiserver将绑定的node信息写入etcd。

第四步： apiserver又通过watch机制，调用kubelet，指定pod信息，调用Docker API创建并启动pod内的容器。

第五步： worker创建完成之后反馈给自身的kubelet, 再反馈给控制器的apiserver，apiserver又将pod的状态信息写入etcd。

三、Pod资源清单详解

3.1 Pod资源清单介绍

##查看对象中包含哪些字段
$root@k8s-master01 \~\]# kubectl explain pod.spec.containers$

3.1.1 资源清单必须存在的属性

参数名	字段类型	说明
apiversion	String	指的是K8S API的版本，目前基本上是v1，可以用kubectl api-versions命令查询
kind	String	这里指的是yaml文件定义的资源类型和角色，比如：Pod
metadata	Object	元数据对象，固定值就写metadata
metadata.name	String	元数据对象的名称，这里由我们编写，比如命名Pod的名字
metadata.namespace	String	元数据对象的命名空间，由我们自定义
spec	Object	详细定义对象，固定值就是Spec
spec.containers[]	list	这是是spec对象的容器列表定义，是个列表
spec.containers[].name	String	这里定义容器的名称
spec.containers[].image	String	这里定义要用到的镜像名称

3.1.2 主要对象

参数名	字段类型	说明
spec.containers[].name	String	这里定义容器的名称，- name
spec.containers[].image	String	这里定义要用到的镜像名称
spec.containers[].imagePullPolicy	String	定义镜像拉取策略，有Always、Never、IfNotPresent三个值可选(1) Always:意思是每次都尝试重新拉取镜像(2)Never:表示仅使用本地镜像(3)IfNotPresent:如果本地有镜像就使用本地镜像，没有就拉取在线镜像。上面三个值都没设置的话，默认是Always.
spec.containers[].command[]	List	指定容器启动命令，因为是数组可以指定多个，不指定则使用镜像打包时使用的启动命令。
spec.containers[].args[]	List	指定容器启动命令参数，因为是数组可以指定多个
spec.containers[].workingDir	String	指定容器的工作目录
spec.containers[].volumeMounts[]	List	指定容器内部的存储卷配置
spec.containers[].volumeMounts[].name	String	指定可以被容器挂载的存储卷名称
spec.containers[].volumeMounts[].mountPath	String	指定可以被容器挂载的存储卷的路径
spec.containers[].volumeMounts[].readOnly	String	设置存储卷路径的读写模式，ture或者false，默认为读写模式
spec.containers[].ports[]	List	指定容器需要用到的端口列表
spec.containers[].ports[].name	String	指定端口名称
spec.containers[].ports[].containerPort	String	指定容器需要监听的端口号
spec.containers[].ports[].hostPort	String	指定容器所在主机需要监听的端口号，默认跟上面containerPort相同，注意设置了hostPort同一台主机无法启动该容器相同的副本（因为主机的端口号不能相同，这样会冲突）
spec.containers[].ports[].protocol	String	指定端口协议，支持TCP和UDP，默认为TCP
spec.containers[].env[]	List	指定容器运行前需要设置的环境变量列表

3.1.3 额外的参数项

参数名	字段类型	说明
spec.restartPolicy	String	定义Pod的重启策略，可选值为Always、OnFailure，Never；默认值为Always。1.Always: Pod---旦终止运行，则无论容器是如何终止的,kubelet服务都将重启它。2.OnFailure:只有Pod以非零退出码终止时，kubelet才会重启该容器。如果容器正常结束(退出码为0)，则kubelet将不会重启它。3.Never: Pod终止后，kubelet将退出码报告给Master，不会重启该Pod。
spec.nodeSelector	Object	定义Node的Label过滤标签，以key:value格式指定
spec.nodeName	Object	以worker节点的主机名指定pod在哪个worker节点上工作
spect.imagePullSecrets	Object	定义pull镜像时使用secret名称，以name:secretkey格式指定
spec.hostNetwork	Boolean	定义是否使用主机网络模式，默认值为false。设置true标识使用宿主机网络，不使用docker网桥，同时设置了true将无法在同一台宿主机上启动第二个副本

3.2 POD YAML文件示例

bash 复制代码

# yaml格式的pod定义文件完整内容：
apiVersion: v1       #必选，版本号，例如v1
kind: Pod       #必选，Pod
metadata:       #必选，元数据
  name: string       #必选，Pod名称
  namespace: string    #必选，Pod所属的命名空间
  labels:      #自定义标签
    name: string     #自定义标签名字
  annotations:       #自定义注释列表
    - name: string
spec:         #必选，Pod中容器的详细定义
  containers:      #必选，Pod中容器列表
  - name: string     #必选，容器名称
    image: string    #必选，容器的镜像名称
    imagePullPolicy: [Always | Never | IfNotPresent] #获取镜像的策略 Alawys表示下载镜像 IfnotPresent表示优先使用本地镜像，否则下载镜像，Nerver表示仅使用本地镜像
    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     #内存清楚，容器启动的初始可用数量
    livenessProbe:     #对Pod内个容器健康检查的设置，当探测无响应几次后将自动重启该容器，检查方法有exec、httpGet和tcpSocket，对一个容器只需设置其中一种方法即可
      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的重启策略，Always表示一旦不管以何种方式终止运行，kubelet都将重启，OnFailure表示只有Pod以非0退出码退出才重启，Nerver表示不再重启该Pod
    nodeSelector: obeject  #设置NodeSelector表示将该Pod调度到包含这个label的node上，以key：value的格式指定
    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的存储卷，挂载集群与定义的secre对象到容器内部
      scretname: string 
      items:    
      - key: string
        path: string
    configMap:     #类型为configMap的存储卷，挂载预定义的configMap对象到容器内部
      name: string
      items:
      - key: string
        path: string

3.3 标签

3.3.1 什么是标签？

标签其实就一对 key/value ，被关联到对象上，比如Pod,标签的使用我们倾向于能够表示对象的特殊特点，就是一眼就看出了这个Pod是干什么的，标签可以用来划分特定的对象（比如版本，服务类型等），标签可以在创建一个对象的时候直接定义，也可以在后期随时修改，每一个对象可以拥有多个标签，但是，key值必须是唯一的。创建标签之后也可以方便我们对资源进行分组管理。如果对pod打标签之后就可以使用标签来查看、删除指定的pod。（慎重！！！）

在k8s中，大部分资源都可以打标签。

3.3.2 给pod资源打标签

#对已经存在的pod打标签
$root@k8s-master01 \~\]# kubectl label pods pod-first release=v1 #查看标签是否打成功 \[root@k8s-master01 \~\]# kubectl get pods pod-first --show-labels$

3.3.3 查看资源标签

#查看默认名称空间下所有pod资源的标签
$root@k8s-master01 \~\]# kubectl get pods --show-labels #查看默认名称空间下指定pod具有的所有标签 \[root@k8s-master01 \~\]# kubectl get pods pod-first --show-labels #列出默认名称空间下标签key是release的pod，不显示标签 \[root@k8s-master01 \~\]# kubectl get pods -l release #列出默认名称空间下标签key是release、值是v1的pod，不显示标签 \[root@k8s-master01 \~\]# kubectl get pods -l release=v1 #列出默认名称空间下标签key是release的所有pod，并打印对应的标签值 \[root@k8s-master01 \~\]# kubectl get pods -L release #查看所有名称空间下的所有pod的标签 \[root@k8s-master01 \~\]# kubectl get pods --all-namespaces --show-labels$

3.4 资源限制

3.4.1 节点资源不足，导致调度失败

bash 复制代码

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod2
spec:
  containers:
  - name: nginx2
    image: nginx
    imagePullPolicy: IfNotPresent
    resources:
      limits:
        cpu: '8'
        memory: '8Gi'
      requests:
        cpu: '6'

####状态信息
[root@k8s-master ~]# kubectl get pod
NAME         READY   STATUS    RESTARTS   AGE
nginx-pod    1/1     Running   0          47m
nginx-pod2   0/1     Pending   0          4m14s
###排错
[root@k8s-master ~]# kubectl describe pod nginx-pod2 
.....
Events:
  Type     Reason            Age    From               Message
  ----     ------            ----   ----               -------
  Warning  FailedScheduling  4m36s  default-scheduler  0/3 nodes are available: 1 node(s) had untolerated taint {node-role.kubernetes.io/control-plane: }, 2 Insufficient cpu. preemption: 0/3 nodes are available: 1 Preemption is not helpful for scheduling, 2 No preemption victims found for incoming pod.

3.4.2 所在命名空间资源不足

bash 复制代码

##创建命名空间并设置资源限制
[root@k8s-master ~]# vim c2409.txt
apiVersion: v1
kind: Namespace
metadata:
  name: c2409
---
apiVersion: v1
kind: ResourceQuota
metadata:
  name: mem-cpu-quota
  namespace: c2409
spec:
  hard:
    requests.cpu: '2'
    requests.memory: '2Gi'
    limits.cpu: '4'
    limits.memory: '4Gi'
###创建pod
[root@k8s-master ~]# vim nginx.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod2
  namespace: c2409
spec:
  containers:
  - name: nginx2
    image: nginx
    imagePullPolicy: IfNotPresent
    resources:
      limits:
        cpu: '8'
        memory: '8Gi'
      requests:
        cpu: '6'
        memory: '2Gi'


##提交后的报错信息
[root@k8s-master ~]# kubectl apply -f nginx.yaml 
Error from server (Forbidden): error when creating "nginx.yaml": pods "nginx-pod2" is forbidden: exceeded quota: mem-cpu-quota, requested: limits.cpu=8,limits.memory=8Gi,requests.cpu=6, used: limits.cpu=0,limits.memory=0,requests.cpu=0, limited: limits.cpu=4,limits.memory=4Gi,requests.cpu=2

3.5 Pod探针

在K8S集群中，为了测试pod是否正常运行，可以通过kubelet定期对pod进行健康检查，从而保证服务正常运行。

3.5.1 kubelet检查机制

exec：在容器内执行指定命令，当返回码为0表示检测成功。在 Kubernetes 1.20 版本之前，exec 探针会忽略 timeoutSeconds：探针会无限期地持续运行，甚至可能超过所配置的限期，直到返回结果为止。
httpGet：对容器的IP和URL进行HTTP的GET请求，当响应码（状态码）为大于等于200且小于400，表示容器正常运行。
tcpSocket：对容器内的端口或socket进行TCP检查，如果端口成功打开，证明容器正常运行。

3.5.2 探针返回结果

Success：表示通过检测。
Failure：表示未通过检测。
Unknown：表示检测没有正常进行。

3.5.3 探针的类型

livenessProbe（存活探针）：判断容器是否正常运行。如果存活探测失败，那么kubelet就会把老的容器删除，然后根据重启策略对容器做操作。如果容器没有存活探针，默认状态为Success。
readinessProbe（就绪探针）：判断容器的是否就绪。比如：应用在启动时可能需要加载大量的数据或配置文件，或是启动后要依赖等待外部服务。在这种情况下，既不想杀死应用，也不想给它发送请求。这个时候就需要用到这个探针。当就绪探测失败，端点控制器将从与 Pod匹配的所有服务的端点列表中删除该 Pod 的 IP 地址(如果是用nodeport映射端口到外网，这个时候就不能访问网站了，但是容器不会被删除)，初始延迟之前的就绪态的状态值默认为 Failure。如果容器不提供就绪态探针，则默认状态为 Success。
startupProbe（启动探针）：指示容器中的应用是否已经启动。如果提供了启动探针，则所有其他探针都会被禁用 ，直到此探针成功为止。如果启动探测失败，kubelet 将删除容器，而容器依其重启策略进行重启。如果容器没有提供启动探测，则默认状态为 Success。

注意：startupProbe 和 livenessProbe 最大的区别就是startupProbe在探测成功之后就不会继续探测了，而livenessProbe在pod的生命周期中一直在探测！

3.5.4 探针属性

（initialDelaySeconds: 5）：初始化延迟时间，主要是告诉kubelet，容器启动需要的时间，当过了这个时间再进行探测，要不然容器可能还没启动就会删除了。
（periodSeconds: 5）：探测周期间隔时间，主要是指定kubelet对容器进行探针的时间周期，也就是第一次探测结束后，等待多少时间后对容器进行探测。默认值为10秒，最小值为1秒。
（timeoutSeconds: 5）：单次探测超时时间，指定kubelet对容器探测的最大时间，超过这个时间证明容器探测失败。默认为1秒，最小为1秒。
（successThreshold: 5）：探测失败到成功的重试次数，当kubelet对某个容器第一次探测失败后，重新进行探测的次数，比如指定为1，那么就会直接将容器删除。如果使用的探针是livenessProbe，那么只能配置为1，最小值为1次。
（failureThreshold: 5）：探测成功到失败的重试次数，当kubelet对某个容器进行探测过程中，允许失败的次数，当用于readinessProbe探针，默认是3次，最小值为1次。也就是说当3次探测失败后，容器会被删除。当用于startupProbe探针，如果还设置了periodSeconds时间，那么等待容器启动的时间为failureThreshold的时间乘以periodSeconds时间的值，在这段时间内，容器没有启动，那么就会删除容器。

3.5.5 livenessProbe探针案例

3.5.5.1 livenessProbe和kubelet-exec

bash 复制代码

[root@k8s-master01 ~]# cat /root/nginx/nginx_pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: nginx-pods
  labels:
    app: nginx
spec:
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent
    livenessProbe:
      exec:                    #定义探测方式
        command:               #不断查看文件是否存在，文件必须是镜像原本存在的文件
        - cat
        - /usr/share/nginx/html/index.html
      initialDelaySeconds: 5   #指定探针多少秒后启动
      periodSeconds: 5         #指定探针探测周期时间
[root@k8s-master01 ~]# kubectl apply -f nginx-exec.yml   
[root@k8s-master01 ~]# kubectl get pod  
###进入容器，触发探针
[root@k8s-master01 nginx]# kubectl exec -it nginx-pods /bin/bash
root@nginx-pods:/usr/share/nginx/html# mv index.html index1.html
###好处看看后发现重启了1次
[root@k8s-master01 ~]# kubectl get pod 
NAME         READY   STATUS    RESTARTS      AGE
nginx-pods   1/1     Running   1 (59s ago)   4m15s
##再次进入容器，发现文件重建了
[root@k8s-master01 nginx]# kubectl exec -it nginx-pods /bin/bash
root@nginx-pods:/usr/share/nginx/html# ls
50x.html  index.html

3.5.5.2 livenessProbe和kubelet-httpGet

bash 复制代码

[root@k8s-master01 ~]# cat /root/nginx/nginx_pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: nginx-pods
  labels:
    app: nginx
spec:
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent
    livenessProbe:
      httpGet:                  #指定探针探测方式
        path: /index.html       #定义请求的URL
        port: 80                #定义GET的端口
      initialDelaySeconds: 3    #指定探针多少秒后启动
      periodSeconds: 3          #指定探针的探测周期
[root@k8s-master01 ~]# kubectl apply -f nginx-exec.yml   
[root@k8s-master01 ~]# kubectl get pod  
###进入容器，触发探针
[root@k8s-master01 nginx]# kubectl exec -it nginx-pods /bin/bash
root@nginx-pods:/usr/share/nginx/html# mv index.html index1.html
###好处看看后发现重启了1次
[root@k8s-master01 ~]# kubectl get pod 
NAME         READY   STATUS    RESTARTS      AGE
nginx-pods   1/1     Running   1 (59s ago)   4m15s
##再次进入容器，发现文件重建了
[root@k8s-master01 nginx]# kubectl exec -it nginx-pods /bin/bash
root@nginx-pods:/usr/share/nginx/html# ls
50x.html  index.html

3.5.5.3 livenessProbe和kubelet-tcpSocket

bash 复制代码

[root@k8s-master01 ~]# vi nginx-tcp.yml

apiVersion: v1
kind: Pod
metadata:
  name: nginx2-pods
  labels:
    app: nginx
spec:
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent
    livenessProbe:
      tcpSocket:                  #指定探针探测方式
        port: 80                #定义GET的端口
      initialDelaySeconds: 3    #指定探针多少秒后启动
      periodSeconds: 3          #指定探针的探测周期


[root@k8s-master01 ~]# kubectl apply -f nginx-tcp.yml           #创建容器
[root@k8s-master01 ~]# kubectl get pod -A                       #查看pod
####测试#####
[root@k8s-master01 ~]# kubectl exec -it nginx2-pods -- bash  #连接容器

sed -i 's/listen       80;/listen       8080;/' /etc/nginx/conf.d/default.conf       #修改配置文件

server {
    listen       8080;    #把80都改为8080
    listen  [::]:8080;
    
nginx -s reload                          #重新加载配置文件

[root@k8s-master01 ~]# kubectl get pod -A            #查看pod，可以看到RESTARTS，证明容器重启过
[root@k8s-master01 ~]# kubectl exec -it nginx2-pods -- bash  #连接容器
[root@k8s-master01 ~]# head -n 10 /etc/nginx/conf.d/default.conf  #可以看到配置被还原了，证明容器重建了

3.5.6 readinessProbe探针案例

3.5.6.1 readinessProbe和kubelet-exec

bash 复制代码

[root@k8s-master01 ~]# vim nginx-re-exec.yml

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: nginx1
  name: nginx
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 80
        readinessProbe:  #指定探针
          exec:          #指定探针探测方式
            command:
            - cat
            - /usr/share/nginx/html/index.html
          initialDelaySeconds: 5
          periodSeconds: 5
---
apiVersion: v1
kind: Service
metadata:
  labels:
    svc: nginx-svc-nodeport
  name: nginx-svc-nodeport
spec:
  type: NodePort
  ports:
  - port: 8000   ##pod的端口
    targetPort: 80  ##容器内部暴露的端口
    nodePort: 30080 ##对外访问端口
  selector:
    app: nginx

[root@k8s-master01 ~]# kubectl apply -f nginx-re-exec.yml        #创建容器
[root@k8s-master01 ~]# kubectl get pod -A -o wide                #查看容器的创建节点
[root@k8s-master01 ~]# kubectl get svc -o wide                   #查看service
[root@k8s-master01 ~]# kubectl describe svc nginx-svc-nodeport   #查看pod和service绑定
[root@k8s-master01 ~]# curl -I http://192.168.116.132:30080      #访问网站成功
###测试####
[root@k8s-master01 ~]# kubectl get pod -A -o wide     查看容器名字，可以看到原本READY是1/1
[root@k8s-master01 ~]# kubectl exec -it nginx-8595754649-jfz9r -- bash  连接容器
# cd /usr/share/nginx/html/   #修改探针指定探测的文件名字，让探针触发
#ls
#mv index.html index1.html 
#exit
[root@k8s-master01 ~]# kubectl get pod -A -o wide  #可以看到READY变成了0/1，证明探针被触发了，容器没有被删除，也没有重建
[root@k8s-master01 ~]# curl -I http://192.168.116.132:30080 #可以看到网站访问不了
[root@k8s-master01 ~]# kubectl describe svc nginx-svc-nodeport  #可以看到Endpoints没有值，证明探针把service和pod解除绑定了
###恢复
echo nginx-1 > index.html
kubectl cp index.html default/nginx-8595754649-jfz9r:/usr/share/nginx/html/

3.5.6.2 readinessProbe和kubelet-httpGet

bash 复制代码

[root@k8s-master01 ~]# vim nginx-re-httpGet.yml

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: nginx
  name: nginx
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 80
        readinessProbe:             #指定探针
          httpGet:                  #指定探针方式
            path: /index.html       
            port: 80                
          initialDelaySeconds: 5
          periodSeconds: 5
---
apiVersion: v1
kind: Service
metadata:
  labels:
    svc: nginx-svc-nodeport
  name: nginx-svc-nodeport
spec:
  type: NodePort
  ports:
  - port: 80
    targetPort: 80
    nodePort: 30080
  selector:
    app: nginx

[root@k8s-master01 ~]# kubectl apply -f nginx-re-httpGet.yml        #创建容器
[root@k8s-master01 ~]# curl -I http://192.168.116.132:30080      #和上面一样，访问网站成功
[root@k8s-master01 ~]# kubectl get pod -A -o wide     #查看容器名字，可以看到原本READY是1/1
###测试####
[root@k8s-master01 ~]# kubectl exec -it nginx-75f8cfd9d-6x8jz -- bash  #连接容器
#cd /usr/share/nginx/html/   #修改探针指定探测的文件名字，让探针触发
#ls
#mv index.html index1.html 
#exit
[root@k8s-master01 ~]# kubectl get pod -A -o wide  #可以看到READY变成了0/1，证明探针被触发了，容器没有被删除，也没有重建
NAME                                READY   STATUS    RESTARTS      AGE   IP              NODE           NOMINATED NODE   READINESS GATES
nginx-556bcf764d-7qpjh              0/1     Running   0             29m   172.16.79.76    k8s-worker01   <none>           <none>

[root@k8s-master01 ~]# curl -I http://192.168.116.132:30080  #可以看到网站访问不了 （等待5分钟）
[root@k8s-master01 ~]# kubectl describe svc nginx-svc-nodeport  #可以看到Endpoints没有值，证明探针把service和pod解除绑定了
Name:                     nginx-svc-nodeport
Namespace:                default
Labels:                   svc=nginx-svc-nodeport
Annotations:              <none>
Selector:                 app=nginx
Type:                     NodePort
IP Family Policy:         SingleStack
IP Families:              IPv4
IP:                       10.10.166.16
IPs:                      10.10.166.16
Port:                     <unset>  8000/TCP
TargetPort:               80/TCP
NodePort:                 <unset>  30080/TCP
Endpoints:                
Session Affinity:         None
External Traffic Policy:  Cluster
Events:                   <none>

3.5.6.3 readinessProbe和kubelet-tcpSocket

bash 复制代码

[root@k8s-master01 ~]# vim nginx-re-tcpSocket.yml

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: nginx
  name: nginx
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 80
        readinessProbe:                 #指定探针
          tcpSocket:                    #指定探测方式
            port: 80
          initialDelaySeconds: 5
          periodSeconds: 5
---
apiVersion: v1
kind: Service
metadata:
  labels:
    svc: nginx-svc-nodeport
  name: nginx-svc-nodeport
spec:
  type: NodePort
  ports:
  - port: 80
    targetPort: 80
    nodePort: 30080
  selector:
    app: nginx

[root@k8s-master01 ~]# kubectl apply -f nginx-re-tcpSocket.yml        #创建容器
[root@k8s-master01 ~]# curl -I http://192.168.116.132:30080      #和上面一样，访问网站成功

[root@k8s-master01 ~]# kubectl get pod -A                       #查看pod
####测试####
[root@k8s-master01 ~]# kubectl exec -it nginx-6bf8bf8577-9skvn -- bash  #连接容器

#vi /etc/nginx/conf.d/default.conf        #修改配置文件

server {
    listen       8080;    #把80都改为8080
    listen  [::]:8080;
    
#nginx -s reload                          #重新加载配置文件

[root@k8s-master01 ~]# kubectl get pod -A  可以看到READY变成了0/1，证明探针被触发了，容器没有被删除，也没有重建
[root@k8s-master01 ~]# curl -I http://192.168.116.132:30080  可以看到因为探针触发，外网是访问不了容器了

就绪探针不会影响pod和pod之间的访问，新建测试容器测试

$root@k8s-master01 \~\]# kubectl run net-test1 --image=alpine sleep 360000 #创建容器 \[root@k8s-master01 \~\]# kubectl get pod -A -o wide #查看pod的IP \[root@k8s-master01 \~\]# kubectl exec -it net-test1 -- bash #连接容器 #可以看到只要指定改过的pod的端口，pod和pod之间还是可以访问的 #wget http://10.10.1.36:8080 #ls$

3.5 Pod案例

3.5.1 生成YAML文件

##生成Pod模版
$root@k8s-master01 nginx\]# kubectl run pod --image=nginx --dry-run=client -o yaml \> my-pod.yaml \[root@k8s-master01 \~\]# vim /root/nginx/nginx_pod.yaml apiVersion: v1 kind: Pod metadata: name: nginx spec: containers: - name: nginx image: nginx imagePullPolicy: IfNotPresent ports: - containerPort: 80$

3.5.2 创建Pod

$root@k8s-master01 \~\]# kubectl apply -f /root/nginx/nginx_pod.yaml$

五、Pod常用命令

命令	作用
创建pod	kubectl create -f ymal文件
查看pod	kubectl get pod [-n 名称空间] kubectl get pod -o wide
更新pod	kubectl apply -f yaml文件
删除pod	kubectl delete pod pod名称
进入pod中的容器	kubectl exec -it pod名称 -- shell
查看pod中容器日志	kubectl logs pod名称 -c 容器名
查看pod标签	kubectl get pod pod名称 --show-labels
修改pod标签	kubectl label pod pod名称 newkey=newvalue
查看标签为app的pod	kubectl get pod -l app
查看所有名称空间标签为app的pod	kubectl get pod -l app --all-namespaces
查看标签为app，值为myapp的pod	kubectl get pod -l app=myapp kubectl get pod -l app=myapp --all-namespaces
查看详细信息	kubectl describe pod pod名称

六、Pod状态

挂起（Pending）：我们在请求创建pod时，条件不满足，调度没有完成，没有任何一个节点能满足调度条件，已经创建了pod但是没有适合它运行的节点叫做挂起，调度没有完成，处于pending的状态会持续一段时间：包括调度Pod的时间和通过网络下载镜像的时间。
运行中（Running）：Pod已经绑定到了一个节点上，Pod 中所有的容器都已被创建。至少有一个容器正在运行。
成功（Succeeded）：Pod 中的所有容器都被成功终止，并且不会再重启。
失败（Failed）：Pod 中的所有容器都已终止了，并且至少有一个容器是因为失败终止。也就是说，容器以非0状态退出或者被系统终止。
未知（Unknown）：未知状态，所谓pod是什么状态是apiserver和运行在pod节点的kubelet进行通信获取状态信息的，如果节点之上的kubelet本身出故障，那么apiserver就连不上kubelet，得不到信息了，就会看Unknown

6.1 常用的排障命令

##查看 Pod 的配置是否正确
$root@k8s-master01 \~\]# kubectl get pod \ -o yaml ##查看 Pod 的事件 \[root@k8s-master01 \~\]# kubectl describe pod \ ##查看容器日志 \[root@k8s-master01 \~\]# kubectl logs \ \[-c \$
##进入容器查看
$root@k8s-master01 \~\]#kubectl exec -it \ -- /bin/bash$

6.2 常见故障归类

Pod状态一直处于 Pending

复制代码

Pending 说明 Pod 还没有调度到某个 Node 上面。可以通过 kubectl describe pod <pod-name> 命令查看到当前 Pod 的事件，进而判断为什么没有调度。可能的原因包括：
资源不足，集群内所有的 Node 都不满足该 Pod 请求的 CPU、内存、GPU 等资源
HostPort 已被占用，通常推荐使用 Service 对外开放服务端口

Pod状态一直处于 Waiting或者Pod状态一直处于 ContainerCreating

复制代码

首先还是通过 kubectl describe pod <pod-name> 命令查看到当前 Pod 的事件。可能的原因包括：
镜像拉取失败，比如配置了镜像错误、Kubelet 无法访问镜像、私有镜像的密钥配置错误、镜像太大，拉取超时等
CNI 网络错误，一般需要检查 CNI 网络插件的配置，比如无法配置 Pod 、无法分配 IP 地址
容器无法启动，需要检查是否打包了正确的镜像或者是否配置了正确的容器参数

Pod状态处于 ImagePullBackOff

复制代码

这也是我们测试环境常见的，通常是镜像拉取失败。这种情况可以使用 docker pull <image> 来验证镜像是否可以正常拉取。
或者docker images | grep <images>查看镜像是否存在（系统有时会因为资源问题自动删除一部分镜像）

Pod状态处于 CrashLoopBackOff

复制代码

CrashLoopBackOff 状态说明容器曾经启动了，但可能又异常退出了。此时可以先查看一下容器的日志
kubectl logs --previous
这里可以发现一些容器退出的原因，比如：
容器进程退出
健康检查失败退出

Pod状态处于 Error

复制代码

通常处于 Error 状态说明 Pod 启动过程中发生了错误。常见的原因包括
依赖的 ConfigMap、Secret 或者 PV 等不存在
请求的资源超过了管理员设置的限制，比如超过了 LimitRange 等
违反集群的安全策略，比如违反了 PodSecurityPolicy 等
容器无权操作集群内的资源，比如开启 RBAC 后，需要为 ServiceAccount 配置角色绑定

Pod状态一直处于 Terminating或者Pod状态处于 Unknown

复制代码

从 v1.5 开始，Kubernetes 不会因为 Node 失联而删除其上正在运行的 Pod，而是将其标记为 Terminating 或 Unknown 状态。想要删除这些状态的 Pod 有三种方法：
1）从集群中删除该 Node。使用公有云时，kube-controller-manager 会在 VM 删除后自动删除对应的 Node。而在物理机部署的集群中，需要管理员手动删除 Node（如 kubectl delete node <node-name>。
2）Node 恢复正常。Kubelet 会重新跟 kube-apiserver 通信确认这些 Pod 的期待状态，进而再决定删除或者继续运行这些 Pod。
3）用户强制删除。用户可以执行 kubectl delete pods <pod> --grace-period=0 --force 强制删除 Pod。除非明确知道 Pod 的确处于停止状态（比如 Node 所在 VM 或物理机已经关机），否则不建议使用该方法。
特别是 StatefulSet 管理的 Pod，强制删除容易导致脑裂或者数据丢失等问题。

Pod状态处于 Evicted

复制代码

出现这种情况，多见于系统内存或硬盘资源不足，可df-h查看docker存储所在目录的资源使用情况，如果百分比大于85%，就要及时清理下资源，尤其是一些大文件、docker镜像。
清除状态为Evicted的pod：
kubectl get pods | grep Evicted | awk '{print $1}' | xargs kubectl delete pod
删除所有状态异常的pod：
kubectl delete pods $(kubectl get pods | grep -v Running | cut -d ' ' -f 1)
删除集群中没有在使用的docker镜像(慎用)：
docker system prune -a
查看pod对应的服务(镜像)版本：
kubectl --server=127.0.0.1:8888 get rc -o yaml | grep image: |uniq | sort | grep ecs-core
附：
删除某类历史镜像（仅保留当前使用的）
docker images | grep ecs-core | grep -v `docker images | grep ecs-core -m 1 | awk '{print $2}'` | awk '{print $3}' | xargs docker rmi -f