K8S学习--Kubeadm-6--Pod生命周期和探针
一：Pod的状态和探针：https://kubernetes.io/zh/docs/concepts/workloads/pods/pod-lifecycle/ #Pod的状态和探针第一阶段：Pending（挂起）:#正在创建Pod但是Pod中的容器还没有全部被创建完成，处于此状态的Pod应该检查Pod依赖的存储是否有权限挂载、镜像是否可以下载、调度是否正常等。Failed#Pod中...
K8S学习–Kubeadm 安装 kubernetes-1-组件简介
K8S学习–Kubeadm 安装 kubernetes-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中的容器已经可以提供访问服务
1.2：Pod调度过程：
k8s 实战案例 2.1.3：kube-scheduler：需要安装好二进制文件才知道如何调度
1.3：Pod探针：
1.3.1：探针简介：
探针 是由 kubelet 对容器执行的定期诊断，以保证Pod的状态始终处于运行状态，要执行诊断，kubelet 调用由容
器实现的Handler，有三种类型的处理程序：
基于命令式的访问探测方式，类似redis mysql rebbitmq等这些服务 需要基于命令在内部命令式访问
ExecAction
#在容器内执行指定命令，如果命令退出时返回码为0则认为诊断成功。
TCPSocketAction
#对指定端口上的容器的IP地址进行TCP检查，如果端口打开，则诊断被认为是成功的。类似HAproxy 探测端口
HTTPGetAction（推荐）
#对指定的端口和路径上的容器的IP地址执行HTTPGet请求，如果响应的状态码大于等于200且小于 400，则诊断被认
为是成功的。 301 302 都是成功的
每次探测都将获得以下三种结果之一：
成功：容器通过了诊断。
失败：容器未通过诊断。
未知：诊断失败，因此不会采取任何行动。
1.3.2：配置探针：
基于探针实现对Pod的状态检测
1.3.2.1：探针类型：
livenessProbe
#存活探针，检测容器容器是否正在运行，如果存活探测失败，则kubelet会杀死容器，并且容器将受到其重启策略的
影响，如果容器不提供存活探针，则默认状态为 Success，livenessProbe用户控制是否重启pod。
readinessProbe
#就绪探针，如果就绪探测失败，端点控制器将从与Pod匹配的所有Service的端点中删除该Pod的IP地址，初始延迟之
前的就绪状态默认为Failure，如果容器不提供就绪探针，则默认状态为 Success，readinessProbe用于控制pod
是否添加至service。
1.3.2.2：探针配置：
探针有很多配置字段，可以使用这些字段精确的控制存活和就绪检测的行为：
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 之间。
1.3.2.3：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 的返回码标示成功，其它返回码都标示失败。
1.3.2.4：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
1.3.2.5：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值
1.3.2.6：livenessProbe和readinessProbe的对比：
配置参数一样
livenessProbe #连续探测失败会重启、重建pod，readinessProbe不会执行重启或者重建Pod操作
livenessProbe #连续检测指定次数失败后会将容器置于(Crash Loop BackOff)切不可用，readinessProbe不会readinessProbe
#连续探测失败会从service的endpointd中删除该Pod，livenessProbe不具备此功能，但是会将容器挂起livenessProbe
livenessProbe用户控制是否重启pod，readinessProbe用于控制pod是否添加至service建议： 两个探针都配置
1.4：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步
K8S/Kubernetes社区为您提供最前沿的新闻资讯和知识内容
更多推荐
0
0- 0
已为社区贡献12条内容
所有评论(0)