早上起来你有两个选择:
盖上被子做你未完成的梦||掀开被子完成未完成的梦

K8S学习–Kubeadm-6–Pod生命周期和探针

K8S学习–Kubeadm-1-组件简介

K8S学习–Kubeadm-2-安装部署

K8S学习–Kubeadm-3-Dashboard部署和升级

K8S学习–Kubeadm-4-测试运行Nginx+Tomcat

K8S学习–Kubeadm-5-资源管理核心概念

一:Pod的状态和探针:

https://kubernetes.io/zh/docs/concepts/workloads/pods/pod-lifecycle/ #Pod的状态和探针

在这里插入图片描述

第一阶段:
Pending(挂起):
#正在创建Pod但是Pod中的容器还没有全部被创建完成,处于此状态的Pod应该检查Pod依赖的存储是否有权限挂载、镜像是否可以下载、调度是否正常等。
Failed
#Pod中有容器启动失败而导致pod工作异常。
Unknown
#由于某种原因无法获得pod的当前状态,通常是由于与pod所在的node节点通信错误。
Succeeded
#Pod中的所有容器都被成功终止即pod里所有的containers均已terminated。

第二阶段:
Unschedulable:
#Pod不能被调度,kube-scheduler没有匹配到合适的node节点 筛选主机的限制
PodScheduled
#pod正处于调度中,在kube-scheduler刚开始调度的时候,还没有将pod分配到指定的pid,在筛选出合适的节点后就会更新etcd数据,将pod分配到指定的pod
Initialized
#所有pod中的初始化容器已经完成了
ImagePullBackOff:
#Pod所在的node节点下载镜像失败 网络问题 权限问题 镜像服务器地址写错或者镜像名称写错
Running
#Pod内部的容器已经被创建并且启动。
Ready
#表示pod中的容器已经可以提供访问服务

在这里插入图片描述

Pod调度过程:

k8s 实战案例 2.1.3:kube-scheduler:需要安装好二进制文件才知道如何调度

Pod探针:

https://kubernetes.io/zh/docs/concepts/workloads/pods/pod-lifecycle/#%E5%AE%B9%E5%99%A8%E6%8E%A2%E9%92%88

探针简介:

探针 是由 kubelet 对容器执行的定期诊断,以保证Pod的状态始终处于运行状态,要执行诊断,kubelet 调用由容器实现的Handler,有三种类型的处理程序:
基于命令式的访问探测方式,类似redis mysql rebbitmq等这些服务 需要基于命令在内部命令式访问

ExecAction
#在容器内执行指定命令,如果命令退出时返回码为0则认为诊断成功。

TCPSocketAction
#对指定端口上的容器的IP地址进行TCP检查,如果端口打开,则诊断被认为是成功的。类似HAproxy 探测端口

HTTPGetAction(推荐)
#对指定的端口和路径上的容器的IP地址执行HTTPGet请求,如果响应的状态码大于等于200且小于 400,则诊断被认
为是成功的。 301 302 都是成功的 

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

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

配置探针:

基于探针实现对Pod的状态检测

探针类型:

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

探针配置:

https://kubernetes.io/zh/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/

探针有很多配置字段,可以使用这些字段精确的控制存活和就绪检测的行为:

initialDelaySeconds: 120
#初始化延迟时间,告诉kubelet在执行第一次探测前应该等待多少秒,默认是0秒,最小值是0

periodSeconds: 60
#探测周期间隔时间,指定了kubelet应该每多少秒秒执行一次存活探测,默认是 10 秒。最小值是 1

timeoutSeconds: 5
#单次探测超时时间,探测的超时后等待多少秒,默认值是1秒,最小值是1。

successThreshold: 1
#从失败转为成功的重试次数,探测器在失败后,被视为成功的最小连续成功数,默认值是1,存活探测的这个值必须是1,最小值是 1。连续探测成功多少次,才把pod标记为成功

failureThreshold: 3
#从成功转为失败的重试次数,当Pod启动了并且探测到失败,Kubernetes的重试次数,存活探测情况下的放弃就意味着重新启动容器,就绪探测情况下的放弃Pod 会被打上未就绪的标签,默认值是3,最小值是1。

HTTP 探测器可以在 httpGet 上配置额外的字段:

host:
#连接使用的主机名,默认是Pod的 IP,也可以在HTTP头中设置 “Host” 来代替。

scheme: http
#用于设置连接主机的方式(HTTP 还是 HTTPS),默认是 HTTP。

path: /monitor/index.html
#访问 HTTP 服务的路径。

httpHeaders:
#请求中自定义的 HTTP 头,HTTP 头字段允许重复。

port: 80
#访问容器的端口号或者端口名,如果数字必须在 1 ~ 65535 之间。

HTTP探针示例:

root@master-1:/opt/k8s-data/yaml/linux39# vim nginx.yml
#apiVersion: extensions/v1beta1
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 1
  selector:
    matchLabels: #rs or deployment
      app: ng-deploy-80
    #matchExpressions:
    # - {key: app, operator: In, values: [ng-deploy-80,ng-rs-81]}
  template:
    metadata:
      labels:
        app: ng-deploy-80
    spec:
      containers:
      - name: ng-deploy-80
        image: nginx:1.17.5
        ports:
        - containerPort: 80
        #readinessProbe:  #探测异常则下线 通过service的时候没有被转发到后端pod
        livenessProbe:    #探测异常则重启 ,不关心在service后面有没有后端的pod 只是到service这一层面。不会摘除pod
          httpGet: 
            #path: /monitor/monitor.html #对nginx这个页面进行探测 如果存在则正常 不存在则会404 从而重启 当重启到3次之后则下线
            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: 40012
      protocol: TCP
    type: NodePort
    selector:
      app: ng-deploy-80

生产中这2个探测结合使用,固定URL 不能发生变化 2个探测的URL保持一致 结合使用

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

任何大于或等于 200 并且小于 400 的返回码标示成功,其它返回码都标示失败。

TCP探针示例:

第三种类型的存活探测是使用 TCP 套接字。通过配置,kubelet 会尝试在指定端口和容器建立套接字链接。如果能建立链接,这个容器就被看作是健康的,如果不能则这个容器就被看作是有问题的。

kubelet 会在容器启动 5 秒后发送第一个就绪探测。这会尝试连接 goproxy 容器的 8080 端口。如果探测成功,这个 Pod 会被标记为就绪状态,kubelet 将继续每隔 10 秒运行一次检测。

除了就绪探测,这个配置包括了一个存活探测。kubelet 会在容器启动 15 秒后进行第一次存活探测。就像就绪探测一样,会尝试连接 goproxy 容器的 8080 端口。如果存活探测失败,这个容器会被重新启动。

# cat nginx-tcp.yaml
#apiVersion: extensions/v1beta1
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 1
  selector:
    matchLabels: #rs or deployment
      app: ng-deploy-80
    #matchExpressions:
    # - {key: app, operator: In, values: [ng-deploy-80,ng-rs-81]}
  template:
    metadata:
      labels:
        app: ng-deploy-80
    spec:
      containers:
      - name: ng-deploy-80
        image: nginx:1.17.5
        ports:
        - containerPort: 80
        livenessProbe:
        #readinessProbe:
          tcpSocket:
            port: 80
            #port: 8080
          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: 40012
    protocol: TCP
  type: NodePort
  selector:
    app: ng-deploy-80
ExecAction探针:

可以基于指定的命令对Pod进行特定的状态检查。

# docker pull redis #下载redis镜像

# cat redis.yaml
#apiVersion: extensions/v1beta1
apiVersion: apps/v1
kind: Deployment
metadata:
  name: redis-deployment
spec:
  replicas: 1
  selector:
    matchLabels: #rs or deployment
      app: redis-deploy-6379
      #matchExpressions:
      # - {key: app, operator: In, values: [redis-deploy-6379,ng-rs-81]}
    template:
      metadata:
        labels:
          app: redis-deploy-6379
      spec:
        containers:
        - name: redis-deploy-6379
          image: redis
          ports:
          - containerPort: 6379
          livenessProbe:
          #readinessProbe:
            exec:
              command: #执行命令
              #- /apps/redis/bin/redis-cli
              - /usr/local/bin/redis-cli  #执行的客户端命令
              - quit     #退出来   执行命令能进去也能退出来说明是正常的
            initialDelaySeconds: 5 #初始化延迟时间
            periodSeconds: 3
            timeoutSeconds: 5
            successThreshold: 1  #这个探测次数值必须为1 
            failureThreshold: 3
---
apiVersion: v1
kind: Service
metadata:
  name: redis-deploy-6379
spec:
  ports:
  - name: http
    port: 6379
    targetPort: 6379 #pod端口 必须是对应的服务端口redis是6379
    nodePort: 40016
    protocol: TCP
  type: NodePort
  selector:
    app: redis-deploy-6379

如果端口检测连续超过指定的三次都没有通过,则Pod状态会出现CrashLoopBackOff 的STATUS值

livenessProbe和readinessProbe的对比

配置参数一样
livenessProbe #连续探测失败会重启、重建pod,readinessProbe不会执行重启或者重建Pod操作
livenessProbe #连续检测指定次数失败后会将容器置于(Crash Loop BackOff)切不可用,readinessProbe不会

readinessProbe
连续探测失败会从service的endpointd中删除该Pod,livenessProbe不具备此功能,但是会将容器挂起livenessProbe
livenessProbe用户控制是否重启pod,readinessProbe用于控制pod是否添加至service

建议: 两个探针都配置

Pod重启策略:

k8s在Pod出现异常的时候会自动将Pod重启以恢复Pod中的服务。

restartPolicy: #注意缩进问题 6空格
Always:当容器异常时,k8s自动重启该容器,ReplicationController/Replicaset/Deployment。
OnFailure:当容器失败时(容器停止运行且退出码不为0),k8s自动重启该容器。
Never:不论容器运行状态如何都不会重启该容器,Job或CronJob。

示例:

          containers: #和pod平级 
          - name: magedu-tomcat-app1-container
            image: harbor.magedu.local/magedu/tomcat-app1:v1
            #command: ["/apps/tomcat/bin/run_tomcat.sh"]
            #imagePullPolicy: IfNotPresent
            imagePullPolicy: Always
            ports:
            - containerPort: 8080
              protocol: TCP
              name: http
            env:
            - name: "password"
              value: "123456"
            - name: "age"
              value: "18"
            resources:
              limits:
                cpu: 1
                memory: "512Mi"
              requests:
                cpu: 500m
                memory: "512Mi"
          restartPolicy: Always   #增加策略

HPA控制器简介及实现

https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#HPA参考

HPA全称Horizontal Pod Autoscaler控制器工作流程

手动调整pod数量:

root@master-1:~# kubectl get pod #当前pod数量
NAME                                 READY   STATUS    RESTARTS   AGE
net-test1-5fcc69db59-j78d7           1/1     Running   0          8h
net-test1-5fcc69db59-jz944           1/1     Running   1          5d3h
net-test1-5fcc69db59-wzlmg           1/1     Running   2          5d3h
nginx-deployment-8c449b55f-sdksb     1/1     Running   0          8h
tomcat-deployment-7cd955f48c-lthk2   1/1     Running   1          3d21h

#查看命令使用帮助
root@master-1:~# kubectl --help |grep scale #文本没有更新 这里deployment也可以
  scale          Set a new size for a Deployment, ReplicaSet or Replication Controller
  autoscale      Auto-scale a Deployment, ReplicaSet, or ReplicationController

#执行扩容/缩容
root@master-1:~# kubectl scale deployment/tomcat-deployment --replicas=3 -n default
deployment.apps/tomcat-deployment scaled

#验证手动扩容结果  增加了2个pod
root@master-1:~# kubectl get pod
NAME                                 READY   STATUS              RESTARTS   AGE
net-test1-5fcc69db59-j78d7           1/1     Running             0          8h
net-test1-5fcc69db59-jz944           1/1     Running             1          5d3h
net-test1-5fcc69db59-wzlmg           1/1     Running             2          5d3h
nginx-deployment-8c449b55f-sdksb     1/1     Running             0          8h
tomcat-deployment-7cd955f48c-b8k6j   1/1     Running             0          7s
tomcat-deployment-7cd955f48c-lthk2   1/1     Running             1          3d21h
tomcat-deployment-7cd955f48c-v5dch   0/1     ContainerCreating   0          8s
root@master-1:~# kubectl get pod
NAME                                 READY   STATUS    RESTARTS   AGE
net-test1-5fcc69db59-j78d7           1/1     Running   0          8h
net-test1-5fcc69db59-jz944           1/1     Running   1          5d3h
net-test1-5fcc69db59-wzlmg           1/1     Running   2          5d3h
nginx-deployment-8c449b55f-sdksb     1/1     Running   0          8h
tomcat-deployment-7cd955f48c-b8k6j   1/1     Running   0          11s
tomcat-deployment-7cd955f48c-lthk2   1/1     Running   1          3d21h
tomcat-deployment-7cd955f48c-v5dch   1/1     Running   0          12s

在这里插入图片描述

HPA自动伸缩pod数量:

Horizontal Pod Autoscaling,简称HPA,是Kubernetes中实现POD水平自动伸缩的功能。为什么要水平而不叫垂直, 那是因为自动扩展主要分为两种:

水平扩展(scale out),针对于实例数目的增减
垂直扩展(scal up),即单个实例可以使用的资源的增减, 比如增加cpu和增大内存
而HPA属于前者。它可以根据CPU使用率或应用自定义metrics自动扩展Pod数量(支持 replication controller、deployment 和 replica set)
架构介绍

获取metrics的两种方式:
Heapster: heapster提供metrics服务, 但是在v1(autoscaling/v1)版本中仅支持以CPU作为扩展度量指标, 而其他比如:内存, 网络流量, qps等目前处于beta阶段(autoscaling/v2beta1)
Cousom: 同样处于beta阶段(autoscaling/v2beta1), 但是涉及到自定义的REST API的开发, 复杂度会大一些, 并且当需要从自定义的监控中获取数据时,只能设置绝对值,无法设置使用率
kubectl autoscale 自动控制在k8s集群中运行的pod数量(水平自动伸缩),需要提前设置pod范围及触发条件。

k8s从1.1版本开始增加了名称为HPA(Horizontal Pod Autoscaler)的控制器,用于实现基于pod中资源
(CPU/Memory)利用率进行对pod的自动扩缩容功能的实现,早期的版本只能基于Heapster组件实现对CPU利用率
做为触发条件,但是在k8s 1.11版本开始使用Metrices Server完成数据采集,然后将采集到的数据通过
API(Aggregated API,汇总API),例如metrics.k8s.io、custom.metrics.k8s.io、external.metrics.k8s.io,然后
再把数据提供给HPA控制器进行查询,以实现基于某个资源利用率对pod进行扩缩容的目的。

控制管理器默认每隔15s(可以通过–horizontal-pod-autoscaler-sync-period修改)查询metrics的资源使用情况
支持以下三种metrics指标类型:
->预定义metrics(比如Pod的CPU)以利用率的方式计算
->自定义的Pod metrics,以原始值(raw value)的方式计算
->自定义的object metrics
支持两种metrics查询方式:
->Heapster
->自定义的REST API
支持多metrics

在这里插入图片描述
工作流程:

1.创建HPA资源,设定目标CPU使用率限额,以及最大、最小实例数, 一定要设置Pod的资源限制参数: request, 负责HPA不会工作。
2.控制管理器每隔30s(可以通过–horizontal-pod-autoscaler-sync-period修改)查询metrics的资源使用情况
3.然后与创建时设定的值和指标做对比(平均值之和/限额),求出目标调整的实例个数
4.目标调整的实例数不能超过1中设定的最大、最小实例数,如果没有超过,则扩容;超过,则扩容至最大的实例个数
重复2-4步

更多咨询,关注微信公众号

赞(0)
开源学习 相互进步www.likai.tech » K8S学习–Kubeadm-6–Pod生命周期和探针
分享到: 更多 (0)

评论 抢沙发