k8s的探针,资源清单运作原理

Posted 2021-05-20 爱上口袋的天空

1.资源控制器

1. 什么是控制器？
   Kubernetes中内建了很多controller (控制器) ,这些相当于一个状态机,用来控制Pod的具体状态和行为。
   Pod 的分类如下：
       1）自主式 Pod：Pod 退出了，此类型的 Pod 不会被创建
       2）控制器管理的 Pod：在控制器的生命周期里，始终要维持 Pod 的副本数目
2. 常用控制器
   1）ReplicationController（副本控制器旧版本，目前基本不用了）
   2）ReplicaSet（新的副本控制器，我们现在都用这个）
   3）Deployment （是新一代用于Pod和ReplicaSet管理的对象）
   4）DaemonSet （DaemonSet 确保全部（或者某些）节点上运行一个 Pod 的副本，删除 DaemonSet 将会删除它创建的所有 Pod）
   5）StatefulSet （是用来管理有状态应用的工作负载 API 对象）
   6）Job/Cronjob （定时任务）
3. 自主式Pod(单独定义一个pod,这个没有没有副本控制器管理，也没有对应deployment)

   # 自主式的pod: 单独定义一个pod,这个没有没有副本控制器管理，也没有对应deployment
   #init-pod.yaml
   apiVersion: v1
   kind: Pod
   metadata:
     name: init-pod
     labels:
       app: myapp
   spec:
     containers:
     - name: myapp
       image: myapp:v1
     initContainers:
     - name: init-mydb
       image: myapp:v1

    

4. RC&RS
   ReplicationController (RC)用来确保容器应用的副本数始终保持在用户定义的副本数,即如果有容器 异常退出,会自动创建新的Pod来替代;而如果异常多出来的容器也会自动回收.
   在新版本的Kubernetes中建议使用Replicaset来取代ReplicationController. ReplicaSet跟 ReplicationController没有本质的不同,只是名字不一样,并且ReplicaSet支持集合式的selector。使用yaml脚本单独创建如下：

   apiVersion: extensions/v1beta1
   kind: ReplicaSet
   metadata:
     name: frontend
   spec:
     replicas: 3
     selector:
       matchLabels:
         tier: frontend
     template:
       metadata:
         labels:
           tier: frontend
       spec:
         containers:
           - name: Java-nginx
             image: myapp:v1
             env:
               - name: GET_HOSTS_FROM
                 value: dns
             ports:
               - containerPort: 80

   注意：使用上面的yaml脚本创建RS之后，会存在3个pod,一个RS,但是没有deployment,那么没有deployment就没有办法做滚动更新，但是副本的数量是可以控制的。

5. Deployment
   Deployment为Pod和ReplicaSet提供了一个声明式定义(declarative)方法,用来替代以前的 ReplicationController来方便的管理应用。
   典型的应用场景包括如下;
        1）定义Deployment来创建Pod和ReplicaSet
        2）滚动升级和回滚应用
        3）扩容和缩容
        4）暂停和继续Deploymen
   案例部署一个简单的Nginx应用：
   首选我们创建一个my-deployment.yaml文件：
   
   内容如下：

   apiVersion: extensions/v1beta1
   kind: Deployment
   metadata:
     name:  nginx-deployment
   spec:
     replicas: 3
     template:
       metadata:
         labels:
           app: nginx
       spec:
         containers:
           - name: nginx
             image: hub.harbor.com/library/myapp:v1
             env:
               - name: GET_HOSTS_FROM
                 value: dns
             ports:
               - containerPort: 80

   执行脚本：kubectl create -f my-deployment.yaml
   
   下面我们来看看deployment的滚动更新，由上面的脚本可知我们现在运行的容器对应的镜像版本是hub.harbor.com/library/myapp:v1，
   那么我们如何使用命令切换为hub.harbor.com/library/myapp:v2版本呢？
   命令：kubectl set image deployment 指定的deployment名称 容器名称=指定的image版本
   kubectl set image deployment nginx-deployment nginx=hub.harbor.com/library/myapp:v2
   

6. 将上面的v2版本回滚到历史版本
   命令：kubectl rollout undo deployment deployment名称
   
7. Deployment更新策略
   Deployment可以保证在升级时只有一定数量的Pod是down的。默认的,它会确保至少有比期望的 Pod数量少一个是up状态(最多一个不可用)。
   Deployment同时也可以确保只创建出超过期望数量的一定数量的Pod,默认的,它会确保最多比期望 的Pod数量多一个的Pod是up的(最多1个surge )
8. DaemonSet
   创建一个my-daemonset.yaml文件：
   
   内容如下：

   apiVersion: apps/v1
   kind: DaemonSet
   metadata:
     name:  my-deamon
     namespace: default
     labels:
       app: daemonset
   spec:
     selector:
       matchLabels:
         app: my-daemonset
     template:
       metadata:
         labels:
           app: my-daemonset
       spec:
         containers:
           - name: daemon-app
             image: hub.harbor.com/library/myapp:v1

   执行脚本：kubectl create -f my-daemonset.yaml
   

2.pod简介

Pod是kubernetes中你可以创建和部署的最⼩也是最简的单位。 ⼀个Pod代表着集群中运⾏的⼀个 进程。 Pod中封装着应⽤的容器（有的情况下是好⼏个容器） ， 存储、 独⽴的⽹络IP， 管理容器如何 运⾏的策略选项。 Pod代 表着部署的⼀个单位： kubernetes中应⽤的⼀个实例， 可能由⼀个或者多个 容器组合在⼀起共享资源。 在Kubrenetes集群中Pod有如下两种使⽤⽅式：

1. ⼀个Pod中运⾏⼀个容器。 “每个Pod中⼀个容器”的模式是最常⻅的⽤法； 在这种使⽤⽅式 中， 你可以把Pod想象成是单个容器的封装， kuberentes管理的是Pod⽽不是直接管理容 器。
2. 在⼀个Pod中同时运⾏多个容器。 ⼀个Pod中也可以同时封装⼏个需要紧密耦合互相协作的容 器， 它们之间共享资源。 这些在同⼀个Pod中的容器可以互相协作成为⼀个service单位—— ⼀个容器共享⽂件， 另⼀个“sidecar”容器来更新这些⽂件。 Pod将这些容器的存储资源作为 ⼀个实体来管理

每个Pod都是应⽤的⼀个实例。 如果你想平⾏扩展应⽤的话（运⾏多个实例） ， 你应该运⾏多个 Pod， 每个Pod都是⼀个应⽤实例。 在Kubernetes中， 这通常被称为replication。

服务如何部署：

• 建议一个pod中部署一个容器（通常情况下都是这样的）
• 有一些业务上紧密耦合的服务，可以部署在一个容器，通信效率比较高。

3.Pod Phase

Pod 的 status 属性是一个 PodStatus 对象，拥有一个 phase 字段。它简单描述了 Pod 在其生 命周期的阶段。

1. Pending
   Pod 已被 Kubernetes 接受，但尚未创建一个或多个容器镜像。这包括被调度之 前的时间以及通过网络下载镜像所花费的时间，执行需要一段时间。
2. Running
   Pod 已经被绑定到了一个节点，所有容器已被创建。至少一个容器正在运行，或 者正在启动或重新启动。
3. Succeeded
   所有容器成功终止，也不会重启。
4. Failed
   所有容器终止，至少有一个容器以失败方式终止。也就是说，这个容器要么已非 0 状态退出，要么被系统终止。
5. Unknown
   由于一些原因，Pod 的状态无法获取，通常是与 Pod 通信时出错导致的。

4.pod的重启策略

Pod 的重启策略有 3 种，默认值为 Always。

1. Always
   容器失效时，kubelet 自动重启该容器；
2. OnFailure
   容器终止运行且退出码不为0时重启；
3. Never
   不论状态为何， kubelet 都不重启该容器。

失败的容器由 kubelet 以五分钟为上限的指数退避延迟（10秒，20秒，40秒…）重新启动，并在成功执行 十分钟后重置

5.pod生命周期详解

说明：

1. 初始化容器阶段初始化pod中每一个容器,他们是串行执行的，执行完成后就退出了
2. 启动主容器main container
3. 在main container刚刚启动之后可以执行post start命令
4. 在整个main container执行的过程中可以做两类探测：liveness probe(存活 探测)和readiness probe(就绪探测)
5. 在main container结束前可以执行pre stop命令

配置启动后钩子(post start)和终止前钩子(pre stop)

• post start：容器创建之后立即执行，如果失败了就会按照重启策略重启容器
• pre stop：容器终止前立即执行，执行完成之后容器将成功终止

可以使用以下命令查看post start和pre stop的设置格式：

1. kubectl explain pod.spec.containers.lifecycle.preStop
2. kubectl explain pod.spec.containers.lifecycle.postStar

pod init：

1. init容器
   Pod能够持有多个容器，应用运行在容器里面，但是它也可能有一个或多个先于应用容器启动的 Init容器。
   Init容器与普通的容器非常像，除了如下两点：
       1）Init容器总是运行到成功完成为止
       2）每个Init容器都必须在下一个Init容器启动之前成功完成
   如果Pod的Init容器失败，Kubernetes会不断地重启该Pod，直到Init容器成功为止。然而，如果 Pod对应的restartPolicy为Never，它不会重新启动
2. init作用
   因为Init容器具有与应用程序容器分离的单独镜像，所以它们的启动相关代码具有如下优势：
   1）它们可以包含并运行实用工具，但是出于安全考虑，是不建议在应用程序容器镜像中包含 这些实用工具的
   2）它们可以包含使用工具和定制化代码来安装，但是不能出现在应用程序镜像中。例如，创 建镜像没必要FROM另一个镜像，只需要在安装过程中使用类似sed、awk、python或dig这 样的工具
   3）应用程序镜像可以分离出创建和部署的角色，而没有必要联合它们构建一个单独的镜像。
   4）Init容器使用LinuxNamespace，所以相对应用程序容器来说具有不同的文件系统视图。 因此，它们能够具有访问Secret的权限，而应用程序容器则不能。
   5）它们必须在应用程序容器启动之前运行完成，而应用程序容器是并行运行的，所以Init容 器能够提供了一种简单的阻塞或延迟应用容器的启动的方法，直到满足了一组先决条件。
3. 特殊说明
   1）在Pod启动过程中，Init容器会按顺序在网络和数据卷初始化之后启动。每个容器必须在 下一个容器启动之前成功退出(网络和数据卷初始化是在pause)
   2）如果由于运行时或失败退出，将导致容器启动失败，它会根据Pod的restartPolicy指定的 策略进行重试。然而，如果Pod的restartPolicy设置为Always，Init容器失败时会使用 RestartPolicy策略
   3）在所有的Init容器没有成功之前，Pod将不会变成Ready状态。Init容器的端口将不会在 Service中进行聚集。正在初始化中的Pod处于Pending状态，但应该会将Initializing状态设置 为true
   4）如果Pod重启，所有Init容器必须重新执行
   5）对Init容器spec的修改被限制在容器image字段，修改其他字段都不会生效。更改Init容器 的image字段，等价于重启该Pod
   6）Init容器具有应用容器的所有字段。除了readinessProbe（就绪检测），因为Init容器无 法定义不同于完成（completion）的就绪（readiness）之外的其他状态。这会在验证过程中 强制执行
   7）在Pod中的每个app和Init容器的名称必须唯一；与任何其它容器共享同一个名称，会在 验证时抛出错误
4. 案例：
   1）首先我们创建一个init-pod.yaml内容如下：
       

   apiVersion: v1
   kind: Pod
   metadata:
     name:  init-pod
     labels:
       app: myapp
   spec:
     containers:
     - name: myapp
       image: hub.harbor.com/library/busybox:v1
       command: ['sh', '-c', 'echo -n "running at " && date +%T && sleep 600']
     initContainers: #这里有一个初始化容器
     - name: init-mydb
       image: hub.harbor.com/library/busybox:v1
       #下面的命令表示会一直反复的查询init-db容器服务，如果查询不到那么该init-pod就会一直启动不成功
       command: ['sh', '-c', 'until nslookup init-db; do echo waiting for init-db;date +%T; sleep 2;echo; done;']

   
   2）在创建一个init-db.yaml文件，内容如下：
        

   kind: Service
   apiVersion: v1
   metadata:
     name: init-db
   spec:
     ports: 
       - protocol: TCP
         port: 80
         targetPort: 3366    

   
   3）通过命令对两个脚本进行执行
         3.1）先执行init-pod.yaml
               命令：kubectl create -f init-pod.yaml
               #查看pod状态 init没成功
               kubectl get pod
               
               #查看log
               kubectl logs init-pod -c init-mydb
              
             可以发现一只在查找init-db容器服务。
         3.2）下面我们执行init-db.yaml文件
             命令：kubectl create -f init-db.yaml
             #查看
             kubectl get svc
             
            再次通过kubectl get pod查看init-pod服务容器（等的时间可能会长点）
           

6.容器探针

探针是由kubelet对容器执行的定期诊断。要执行诊断，kubelet调用由容器实现的Handler。有三 种类型的处理程序：

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

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

• 成功：容器通过了诊断。
• 失败：容器未通过诊断。
• 未知：诊断失败，因此不会采取任何行动

探测方式：

• livenessProbe：指示容器是否正在运行。如果存活探测失败，则kubelet会杀死容器， 并且容器将受到其重启策略的影响。如果容器不提供存活探针，则默认状态为Success（会随 着容器的生命周期一直存在）
• readinessProbe：指示容器是否准备好服务请求。如果就绪探测失败，端点控制器将从 与Pod匹配的所有Service的端点中删除该Pod的IP地址。初始延迟之前的就绪状态默认为 Failure。如果容器不提供就绪探针，则默认状态为Success

6.1）案例之检测探针之就绪检测

           在/opt目录下创建readiness-probe.yaml文件并且内容如下：
          

#这个是我们的版本信息
apiVersion: v1 
#这个表示资源类型我们创建的是Pod
kind: Pod
metadata: #这个里面定义的是deployment中我们创建的对象信息
  #对象名称
  name: readiness-httpget-pod
  #元数据名称空间
  namespace: default
spec: #这个是对Pod的详细定义
  # 定义Pod下面的容器
  containers:
  #定义容器的名称
  - name: readiness-httpget-container   
    image: hub.harbor.com/library/myapp:v1
    #定义镜像的拉取策略
    imagePullPolicy: IfNotPresent
    #下面定义就绪检查策略
    readinessProbe:
      #使用httpGet的方式
      httpGet:
        port: 80
        path: /index1.html
      #初始化时间为1秒  
      initialDelaySeconds: 1
      #每隔3秒重试检测一遍
      periodSeconds: 3  

 使用命令执行：kubectl create -f  readiness-probe.yaml

查看pod状态：

由上面我们可以发现一个问题，这个pod的状态是Running但是pod里面的容器却还没有Ready,还没有启动起来。下面我们通过命令查看这个pod的详细信息。

命令：kubectl describe pod readiness-httpget-pod

那么我们就需要看一下上面我们定义的httpget请求的index1.html是否存在了

下面我们通过命令进入容器内部：kubectl exec -it readiness-httpget-pod -- /bin/sh

那么我们在里面创建一个index1.html

退出容器我们再次查看pod状态，发现已经成功了，说明readiness一直在检测容器，我们刚一修改后它就检测到了

6.2）案例之检测探针之存活检测

       在/opt目录下创建liveness-exec.yaml文件并且内容如下:
      
      

#这个是我们的版本信息
apiVersion: v1 
#这个表示资源类型我们创建的是Pod
kind: Pod
metadata: #这个里面定义的是deployment中我们创建的对象信息
  #对象名称
  name:  liveness-exec-pod
  #元数据名称空间
  namespace: default
spec: #这个是对Pod的详细定义
  # 定义Pod下面的容器
  containers:
  #定义容器的名称
  - name: liveness-exec-container   
    image: hub.harbor.com/library/busybox:v1
    #定义镜像的拉取策略
    imagePullPolicy: IfNotPresent
    #下面的命令表示启动容器的时候会创建/tmp/live目录，并且睡眠60秒后会删除这个文件
    command:  ["/bin/sh","-c","touch /tmp/live;sleep 60;rm -rf /tmp/live;sleep 3600"]
    #下面定义就绪检查策略
    livenessProbe:
      #使用httpGet的方式
      exec:
        #表示容器会一直检测/tmp/live文件是否存在，不存在则会重新创建容器
        command: ["test","-e","/tmp/live"]
      #初始化时间为1秒  
      initialDelaySeconds: 1
      #每隔3秒重试检测一遍
      periodSeconds: 3  

执行文件：
 
过一会会发现重启次数会不断增加，这就是存活检测：

当然我们也可以使用http方式进行存活检测：

#这个是我们的版本信息
apiVersion: v1 
#这个表示资源类型我们创建的是Pod
kind: Pod
metadata:
  #对象名称
  name: liveness-httpget-pod
  #元数据名称空间
  namespace: default
spec: #这个是对Pod的详细定义
  # 定义Pod下面的容器
  containers:
  #定义容器的名称
  - name: liveness-httpget-container   
    image: hub.harbor.com/library/myapp:v1
    #定义镜像的拉取策略
    imagePullPolicy: IfNotPresent
    ports: #定义容器的名称和端口
    - name: http
      containerPort: 80 
    #下面定义就绪检查策略
    livenessProbe:
      #使用httpGet的方式
      httpGet:
        port: 80
        path: /index.html
      #初始化时间为1秒  
      initialDelaySeconds: 1
      #每隔3秒重试检测一遍
      periodSeconds: 3  
      #超时时间10s
      timeoutSeconds: 10

我们可以执行上面的文件，然后进入容器内部，删除index.html,看看容器是否就无法正常运行了 

6.3）案例检测探针之livenessProbe-Tcp方式存活检测

    配置文件可以类似下面：

apiVersion: v1
kind: Pod
metadata:
  name: probe-tcp
spec:
  containers:
  - name: myapp
    image: hub.harbor.com/library/myapp:v1
    #下面定义就绪检查策略
    livenessProbe:
      #使用tcpSocket的方式
      tcpSocket: #下面就一直监听80端口，80端口不通就会一直重启容器
        port: 80
      #初始化时间为1秒  
      initialDelaySeconds: 1
      #每隔3秒重试检测一遍
      periodSeconds: 3  
      #超时时间10s
      timeoutSeconds: 10

6.4）也可以同时定义存活检测和就绪检测

#这个是我们的版本信息
apiVersion: v1 
#这个表示资源类型我们创建的是Pod
kind: Pod
metadata:
  #对象名称
  name: liveness-httpget-pod
  #元数据名称空间
  namespace: default
spec: #这个是对Pod的详细定义
  # 定义Pod下面的容器
  containers:
  #定义容器的名称
  - name: liveness-httpget-container   
    image: hub.harbor.com/library/myapp:v1
    #定义镜像的拉取策略
    imagePullPolicy: IfNotPresent
    ports: #定义容器的名称和端口
    - name: http
      containerPort: 80 
    #下面定义就绪检查策略
    readinessProbe:
      #使用httpGet的方式
      httpGet:
        port: 80
        path: /index1.html
      #初始化时间为1秒  
      initialDelaySeconds: 1
      #每隔3秒重试检测一遍
      periodSeconds: 3  
      #超时时间10s
      timeoutSeconds: 10
    #下面定义就绪检查策略
    livenessProbe:
      #使用httpGet的方式
      httpGet:
        port: 80
        path: /index.html
      #初始化时间为1秒  
      initialDelaySeconds: 1
      #每隔3秒重试检测一遍
      periodSeconds: 3  
      #超时时间10s
      timeoutSeconds: 10  

6.5）启动及退出动作

apiVersion: v1
kind: Pod
metadata:
  name: lifecycle-demo
spec:
  containers:
  - name: lifecycle-container
    image: hub.harbor.com/library/busybox:v1
    #下面定义容器启动前和退出前的操作
    lifecycle:
      postStart: #启动前执行下面的命令
        exec:
          command: ["/bin/sh","-c","echo Hello from the postStart handler > /usr/share/message"]
      preStop: #容器停止前执行下面的命令
        exec:
          command: ["/bin/sh","-c","echo Hello container stop"]