1. POD状态

新建
调度资源
将事件和node绑定,写入etcd
node节点上的kubelet和kube-proxy进行pod创建,网络规则维护
kubelet调用runc(docker/containerd)创建pod
pod回收

第一阶段

	Pending
	# 正在创建pod但是pod中的容器还没有全部被创建完成.主要是外部资源分配出现问题.(检查pod的存储挂载,镜像下载,调度是否正常)
	Failed
	# Pod中的容器启动失败导致pod工作异常
	Unknow
	# 由于某种原因无法获得pod当前状态,通常是node节点通讯错误.
	Succeeded
	# Pod中所有容器都被成功终止,即pod里所有的containers均已terminated.这个状态存在的时间非常短

第二阶段

	Unschedulable:
	# Pod不能被调度,kube-scheduler没有匹配到合适的node节点
	PodScheduled
	# pod正处于调度中,在kube-scheduler刚开始调度的时候,还没有将pod分配到指定的node,在筛选出合适的节点后将会更新etcd数据,将pod分配到指定的node
	Initalized
	# 所有pod中的初始化容器已经完成
	ImagePullBackOff
	# pod所在节点下载镜像失败
	Running
	# pod内部容器已经被创建并启动
	Ready
	# 表示Pod中容器已经可以提供访问服务

其他状态

	Error: pod 启动过程中发生错误
	NodeLost: pod 所在节点失联
	Unknow: pod 所在节点失联或者其他未知异常
	Waiting: pod 等待启动
	Pending: pod 等待被调度,基本是外部资源获取有问题.
	Terminating: Pod 等待被销毁,是否有其他服务占用.
	CrashLoopBackOff: Pod启动失败,但kubelet正在将它重启
	InvalidImageNmae: node节点无法解析镜像名称导致镜像无法下载
	ImageInspectError: 无法校验镜像,镜像不完整导致
	ErrorImageNeverPull: 策略禁止拉取镜像,镜像中心权限是私有等
	ImagePullBackOff: 镜像拉取失败,尝试重新拉取
	RegistryUnavailable: 镜像服务器不可用,网络原因或harbor宕机
	ErrorIImagePull: 镜像拉取出错,超时或下载被强制终止
	CreateContainerConfigErrror: 不能创建kubelet使用的容器配置
	CreateContainerError: 创建容器失败
	PreStartContainer: 执行preStart hook报错,Pod hook是由Kubernetes管理的kubelet发起的,当容器中的进程启动前或者容器中的进程终止之前运行,比如容器创建完成后里面的服务启动之前可以检查一下依赖的其他服务是否启动,或者容器退出之前可以把容器中的服务先通过命令停止爱
	PostStartHookError: 执行 posstStart hook报错
	RunContainerError: pod运行失败,容器中没有初始化pid为1的守护进程等.
	ContainersNotInitialized: pod没有初始化完毕
	ContainersNotReady: pod没有准备完毕
	ContainerCreating: pod正在创建中
	PodInitializing: pod正在初始化中
	DockerDaemonNotReady: node节点docker服务没有启动
	NetworkPluginNotReady: 网络插件还没有启动

2.探针

探针是有kubelet对容器执行的定时诊断,以保证Pod的状态始终处于运行状态,要执行诊断,kubelet调用由容器实现的handler(处理程序),有三种处理程序:

ExecAction
# 在容器内执行指定命令,如果命令退出时返回码为0则认为诊断成功
TCPSocketAction
# 对指定端口上的容器IP地址进行TCP检查,如果端口打开,则诊断被判断认为是成功的.
HTTPGetAction
# 对指定的端口和路径上的容器的IP地址执行HTTPGet请求,如果响应的状态大于等于200切小于400,则诊断被认为是成功的.

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

成功: 容器通过了诊断
失败: 容器未能通过诊断
未知: 诊断失败,因此不会采取任何行动.

2.1 探针类型

livenessProbe
# 存活探针,检查容器是否正常运行,如果存活探针失败,则kubelet杀死容器,并且容器将收到器重启策略影响.如果容器不提供存活探针,则默认状态为success,livenessProbe用于控制是否重启pod
readinessProbe
# 就绪探针,如果就绪探测失败,端点控制器将从与pod匹配的所有Service的端点中删除该pod的ip地址,初始延迟之前的就绪状态默认为Failure(失败)如果容器不提供就绪探针,则默认状态为success,readinessProbe用于控制pod是否添加至service.

2.2 探针配置

initialDelaySeconds: 120
# 初始化延迟时间.默认是0秒,最小0秒
periodSeconds: 60
# 探测周期间隔时间,指定了kubelet应该每多少秒执行一次存活探测,默认10秒,最小1秒,类似于haproxy的inter
timeoutSeconds: 5
# 单次探测超时时间,探测的超时后等待多少秒,默认1秒,最小1秒
successThreshold: 1
# 从失败转为成功的重试次数,探测器失败后,被视为成功的最小连续成功数,默认是1,存活探测的这个值必须是1,最小值是1.类似于haproxy的rise
failurThreshold: 3
# 从成功转为失败的重试次数,当pod启动了并且探测失败,kubernetes的重试次数,存活探测情况下的放弃就意味着重新启动容器,就绪探测情况下放弃pod,会被打伤未就绪的标签,默认值是3,最小值是1.类似于haproxy的fall

http探测器可以在HTTPGetAction上配置的字段

host: 连接使用的主机名,默认是Pod的ip,也可以使用HTTP头中设置"Host"代替
scheme: 连接主机方式(http/https),默认http
path: 访问http服务的路径
httpHeaders: 请求中定义的HTTP头
port: 访问容器的端口号或者端口名

2.2.1 Http探针

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 1
  selector:
    matchLabels: #rs or deployment
      app: ng-deploy-80
  template:
    metadata:
      labels:
        app: ng-deploy-80
    spec:
      containers:
      - name: ng-deploy-80
        image: nginx:1.17.5 
        ports:
        - containerPort: 80
        readinessProbe:
          httpGet:
            path: /index.html
            port: 80
          initialDelaySeconds: 5
          periodSeconds: 3
          timeoutSeconds: 5
          successThreshold: 1
          failureThreshold: 3

        livenessProbe:
          httpGet:
            path: /index.html
            port: 80
          initialDelaySeconds: 5
          periodSeconds: 3
          timeoutSeconds: 5
          successThreshold: 1
          failureThreshold: 3
---
apiVersion: v1
kind: Service
metadata:
  name: ng-deploy-80 
spec:
  ports:
  - name: http
    port: 81
    targetPort: 80
    nodePort: 30020
    protocol: TCP
  type: NodePort
  selector:
    app: ng-deploy-80

存活探针:
如果将index.html删除,探针就会监控到访问失败,并重启容器.此时被删除的index.html由于镜像本身就有,探针检查又会恢复正常.在重建没有完成时,通过service继续访问该pod会有403的报错.

root@haproxy-1:~# curl 192.168.31.113:30020
<html>
<head><title>403 Forbidden</title></head>
<body>
<center><h1>403 Forbidden</h1></center>
<hr><center>nginx/1.17.5</center>
</body>
</html>

就绪探针:
如果将index.html删除,探针就会监控到访问失败,并从service的ep中删除,但容器不会被重建,如果是单个pod的话那么服务就不能被访问.

root@haproxy-1:~# curl 192.168.31.113:30020
curl: (7) Failed to connect to 192.168.31.113 port 30020: Connection refused
root@k8s-master-01:~/yml# kubectl get ep
NAME           ENDPOINTS                                                     AGE
kubernetes     192.168.31.101:6443,192.168.31.102:6443,192.168.31.103:6443   102d
ng-deploy-80                                                  23m

所以一般会把这2个都配置上.

2.2.2 Tcp探针

使用tcpSocket进行检测

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 1
  selector:
    matchLabels: #rs or deployment
      app: ng-deploy-80
  template:
    metadata:
      labels:
        app: ng-deploy-80
    spec:
      containers:
      - name: ng-deploy-80
        image: nginx:1.17.5 
        ports:
        - containerPort: 80
        livenessProbe:
          tcpSocket:
            port: 80
          initialDelaySeconds: 5
          periodSeconds: 3
          timeoutSeconds: 5
          successThreshold: 1
          failureThreshold: 3
        readinessProbe:
          tcpSocket:
            port: 80
          initialDelaySeconds: 5
          periodSeconds: 3
          timeoutSeconds: 5
          successThreshold: 1
          failureThreshold: 3
---
apiVersion: v1
kind: Service
metadata:
  name: ng-deploy-80 
spec:
  ports:
  - name: http
    port: 81
    targetPort: 80
    nodePort: 30020
    protocol: TCP
  type: NodePort
  selector:
    app: ng-deploy-80

2.2.3 ExecAction 探针

某些情况下通过端口判断并不是很准确,同时服务又没法使用httpget的方式获取服务状态.这时就采用execaction方式,通过一条或多条命令的执行结果进行判断服务是否正常.

kind: Deployment
metadata:
  name: redis-deployment
spec:
  replicas: 1
  selector:
    matchLabels: #rs or deployment
      app: redis-deploy-6379
  template:
    metadata:
      labels:
        app: redis-deploy-6379
    spec:
      containers:
      - name: redis-deploy-6379
        image: redis
        ports:
        - containerPort: 6379
        livenessProbe:
          exec:
            command:
            - /usr/local/bin/redis-cli 
            - quit
          initialDelaySeconds: 5
          periodSeconds: 3
          timeoutSeconds: 5
          successThreshold: 1
          failureThreshold: 3
      
        readinessProbe:
          exec:
            command:
            - /usr/local/bin/redis-cli
            - quit
          initialDelaySeconds: 5
          periodSeconds: 3
          timeoutSeconds: 5
          successThreshold: 1
          failureThreshold: 3
---
apiVersion: v1
kind: Service
metadata:
  name: redis-deploy-6379 
spec:
  ports:
  - name: http
    port: 6379
    targetPort: 6379
    nodePort: 30021
    protocol: TCP
  type: NodePort
  selector:
    app: redis-deploy-6379

K8s复习笔记4-探针