1、StatefulSets
StatefulSet 是用来管理有状态应用的工作负载 API 对象。
StatefulSet 用来管理某 Pod 集合的部署和扩缩， 并为这些 Pod 提供持久存储和持久标识符。
和 Deployment 类似， StatefulSet 管理基于相同容器规约的一组 Pod。但和 Deployment 不同的是， StatefulSet 为它们的每个 Pod 维护了一个有粘性的 ID。这些 Pod 是基于相同的规约来创建的， 但是不能相互替换：无论怎么调度，每个 Pod 都有一个永久不变的 ID。
如果希望使用存储卷为工作负载提供持久存储，可以使用 StatefulSet 作为解决方案的一部分。 尽管 StatefulSet 中的单个 Pod 仍可能出现故障， 但持久的 Pod 标识符使得将现有卷与替换已失败 Pod 的新 Pod 相匹配变得更加容易。
1）使用场景
稳定的、唯一的网络标识符。
稳定的、持久的存储。
有序的、优雅的部署和缩放。
有序的、自动的滚动更新。
2）使用限制
给定 Pod 的存储必须由 PersistentVolume 驱动 基于所请求的 storage class 来提供，或者由管理员预先提供。
删除或者收缩 StatefulSet 并不会删除它关联的存储卷。 这样做是为了保证数据安全，它通常比自动清除 StatefulSet 所有相关的资源更有价值。
StatefulSet 当前需要无头服务 来负责 Pod 的网络标识。你需要负责创建此服务。
Statefulset按照顺序对pod进行启停、伸缩和回收，回收从后向前，创建从前向后(前面的pod不会 *** 作)。当删除 StatefulSets 时，StatefulSet 不提供任何终止 Pod 的保证。 为了实现 StatefulSet 中的 Pod 可以有序地且体面地终止，可以在删除之前将 StatefulSet 缩放为 0。
在默认 Pod 管理策略(OrderedReady) 时使用 滚动更新，可能进入需要人工干预 才能修复的损坏状态。
---
#apiVersion: extensions/v1beta1
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: myserver-myapp
namespace: myserver
spec:
replicas: 3
serviceName: "myserver-myapp-service"
selector:
matchLabels:
app: myserver-myapp-frontend
template:
metadata:
labels:
app: myserver-myapp-frontend
spec:
containers:
- name: myserver-myapp-frontend
image: nginx:1.20.2-alpine
ports:
- containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
name: myserver-myapp-service
namespace: myserver
spec:
clusterIP: None
ports:
- name: http
port: 80
selector:
app: myserver-myapp-frontend
测试
kubectl get pod -n myserver -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
myserver-myapp-0 1/1 Running 0 5s 10.200.169.157 192.168.74.148
myserver-myapp-1 1/1 Running 0 4s 10.200.100.81 192.168.74.149
myserver-myapp-2 1/1 Running 0 2s 10.200.135.156 192.168.74.147
/ # ping myserver-myapp-0.myserver-myapp-service.myserver.svc.kubedocker.local
PING myserver-myapp-0.myserver-myapp-service.myserver.svc.kubedocker.local (10.200.169.157): 56 data bytes
64 bytes from 10.200.169.157: seq=0 ttl=62 time=0.644 ms
64 bytes from 10.200.169.157: seq=1 ttl=62 time=0.263 ms
64 bytes from 10.200.169.157: seq=2 ttl=62 time=0.336 ms
^C
--- myserver-myapp-0.myserver-myapp-service.myserver.svc.kubedocker.local ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0.263/0.414/0.644 ms
/ # ping myserver-myapp-service
PING myserver-myapp-service (10.200.135.156): 56 data bytes
64 bytes from 10.200.135.156: seq=0 ttl=64 time=0.040 ms
64 bytes from 10.200.135.156: seq=1 ttl=64 time=0.050 ms
64 bytes from 10.200.135.156: seq=2 ttl=64 time=0.046 ms
^C
--- myserver-myapp-service ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0.040/0.045/0.050 ms
/ # ping myserver-myapp-service
PING myserver-myapp-service (10.200.135.156): 56 data bytes
64 bytes from 10.200.135.156: seq=0 ttl=64 time=0.032 ms
64 bytes from 10.200.135.156: seq=1 ttl=64 time=0.050 ms
^C
--- myserver-myapp-service ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 0.032/0.041/0.050 ms
/ # ping myserver-myapp-service
PING myserver-myapp-service (10.200.100.81): 56 data bytes
64 bytes from 10.200.100.81: seq=0 ttl=62 time=0.709 ms
64 bytes from 10.200.100.81: seq=1 ttl=62 time=0.320 ms
^C
--- myserver-myapp-service ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 0.320/0.514/0.709 ms
/ # ping myserver-myapp-service
PING myserver-myapp-service (10.200.169.157): 56 data bytes
64 bytes from 10.200.169.157: seq=0 ttl=62 time=0.281 ms
64 bytes from 10.200.169.157: seq=1 ttl=62 time=0.388 ms
^C
--- myserver-myapp-service ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 0.281/0.334/0.388 ms
2、DaemonSet
DaemonSet 确保全部（或者某些）节点上运行一个 Pod 的副本。 当有节点加入集群时， 也会为他们新增一个 Pod 。 当有节点从集群移除时，这些 Pod 也会被回收。删除 DaemonSet 将会删除它创建的所有 Pod。
使用场景：
在每个节点上运行集群守护进程
在每个节点上运行日志收集守护进程
在每个节点上运行监控守护进程
#基于DaemonSet部署prometheus
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: node-exporter
namespace: monitoring
labels:
k8s-app: node-exporter
spec:
selector:
matchLabels:
k8s-app: node-exporter
template:
metadata:
labels:
k8s-app: node-exporter
spec:
tolerations:
- effect: NoSchedule
key: node-role.kubernetes.io/master
containers:
- image: prom/node-exporter:v1.3.1
imagePullPolicy: IfNotPresent
name: prometheus-node-exporter
ports:
- containerPort: 9100
hostPort: 9100
protocol: TCP
name: metrics
volumeMounts:
- mountPath: /host/proc
name: proc
- mountPath: /host/sys
name: sys
- mountPath: /host
name: rootfs
args:
- --path.procfs=/host/proc
- --path.sysfs=/host/sys
- --path.rootfs=/host
volumes:
- name: proc
hostPath:
path: /proc
- name: sys
hostPath:
path: /sys
- name: rootfs
hostPath:
path: /
hostNetwork: true
hostPID: true
---
apiVersion: v1
kind: Service
metadata:
annotations:
prometheus.io/scrape: "true"
labels:
k8s-app: node-exporter
name: node-exporter
namespace: monitoring
spec:
type: NodePort
ports:
- name: http
port: 9100
nodePort: 39100
protocol: TCP
selector:
k8s-app: node-exporter
检查创建状态
kubectl get pod -n monitoring -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
node-exporter-79rrb 1/1 Running 0 29s 192.168.74.149 192.168.74.149
node-exporter-8mbm5 1/1 Running 0 29s 192.168.74.148 192.168.74.148
node-exporter-bnx4h 1/1 Running 0 29s 192.168.74.147 192.168.74.147
node-exporter-ctqlt 1/1 Running 0 29s 192.168.74.145 192.168.74.145
node-exporter-cz665 1/1 Running 0 29s 192.168.74.146 192.168.74.146
node-exporter-wwsl4 1/1 Running 0 29s 192.168.74.144 192.168.74.144
3、pod常见状态
Unschedulable： #Pod不能被调度， kube-scheduler没有匹配到合适的node节点
PodScheduled：#pod正处于调度中，在kube-scheduler刚开始调度的时候，还没有将pod分配到指定的node，在筛选出合适的节点后就会更新etcd数据，将pod分配到指定的node
Pending： #正在创建Pod但是Pod中的容器还没有全部被创建完成，处于此状态的Pod应该检查Pod依赖的存储是否有权限挂载等。
Failed：#Pod中有容器启动失败而导致pod工作异常。
Unknown：#由于某种原因无法获得pod的当前状态，通常是由于与pod所在的node节点通信错误"lnitialized：#所有pod中的初始化容器已经完成了
lmagePullBackOff：#!Pod所在的node节点下载镜像失败，镜像找到了但下不了，与InvalidlmageName区别
Running：#Pod内部的容器已经被创建并且启动，也包括探针检测通过了。
Ready：#表示pod中的容器已经可以提供访问服务
Error： #pod启动过程中发生错误NodeLost： #Pod所在节点失联
Waiting： #Pod 等待启动
Terminating： # Pod正在被销毁
CrashLoopBackOff： #kubelet正在重启pod
InvalidlmageName： #node节点无法解析镜像名称导致的镜像无法下载(404)，找不到镜像
lmageInspectError：#无法校验镜像，镜像不完整导致
ErrlmageNeverPull：#策略禁止拉取镜像，镜像中心权限是私有等
RegistryUnavailable：#镜像服务器不可用，网络原因或harbor宕机
ErrlmagePull：#镜像拉取出错，超时或下载被强制终止
CreateContainerConfigError：#不能创建kubelet使用的容器配置
CreateContainerError：#创建容器失败
RunContainerError： #pod运行失败，容器中没有初始化PID为1的守护进程等ContainersNotInitialized：#pod没有初始化完毕
ContainersNotReady：#pod没有准备完毕
ContainerCreating：#pod正在创建中
PodInitializing：#pod正在初始化中
DockerDaemonNotReady： #node节点decker服务没有启动
NetworkPluginNotReady：#网络插件没有启动
3、Pause容器，又叫lnfra容器，是pod的基础容器，镜像体积只有几百KB左右，配置在kubelet(/etc/systemd/system/kubelet.service)中，主要的功能是一个pod中多个容器的网络通信。
lnfra容器被创建后会初始化Network Namespace，之后其它容器就可以加入到Infra容器中共享Infra 容器的网络了，因此如果一个Pod 中的两个容器A和B，那么关系如下:
1)A容器和B容器能够直接使用localhost通信;
2)A容器和B容器可以看到网卡、IP与端口监听信息。Pod只有一个IP地址，也就是该Pod的Network Namespace对应的IP地址(由Infra容器初始化并创建).
3)k8s环境中的每个Pod有一个独立的IP地址(前提是地址足够用)，并且此IP被当前Pod中所有容器在内部共享使用。
4)pod删除后Infra容器随机被删除,其IP被回收。
Pause容器共享的Namespace:
1)NET Namespace: Pod中的多个容器共享同一个网络命名空间，即使用相同的IP和端口信息。
2)IPC Namespace: Pod中的多个容器可以使用System VIPC或POSIX消息队列进行通信。
3)UTS Namespace: pod中的多个容器共享一个主机名。MNT Namespace、PID Namespace、User Namespace未共享。
4、init容器
容器是一种特殊容器，在 Pod 内的应用容器启动之前运行。Init 容器可以包括一些应用镜像中不存在的实用工具和安装脚本。可以在 Pod 的规约中与用来描述应用容器的 containers 数组平行的位置指定 Init 容器。
每个 Pod 中可以包含多个容器， 应用运行在这些容器里面，同时 Pod 也可以有一个或多个先于应用容器启动的 Init 容器。
Init 容器与普通的容器非常像，除了如下两点：
1）它们总是运行到完成。
3）每个都必须在下一个启动之前成功完成。
如果 Pod 的 Init 容器失败，kubelet 会不断地重启该 Init 容器直到该容器成功为止。 然而，如果 Pod 对应的 restartPolicy 值为 “Never”，并且 Pod 的 Init 容器失败， 则 Kubernetes 会将整个 Pod 状态设置为失败。
1）init容器的作用：
Init 容器可以包含一些安装过程中应用容器中不存在的实用工具或个性化代码。 例如，没有必要仅为了在安装过程中使用类似 sed、awk、python 或 dig 这样的工具而去 FROM 一个镜像来生成一个新的镜像。
Init 容器可以安全地运行这些工具，避免这些工具导致应用镜像的安全性降低。
应用镜像的创建者和部署者可以各自独立工作，而没有必要联合构建一个单独的应用镜像。
Init 容器能以不同于 Pod 内应用容器的文件系统视图运行。因此，Init 容器可以访问 应用容器不能访问的 Secret 的权限。
由于 Init 容器必须在应用容器启动之前运行完成，因此 Init 容器 提供了一种机制来阻塞或延迟应用容器的启动，直到满足了一组先决条件。 一旦前置条件满足，Pod 内的所有的应用容器会并行启动。
利用init容器初始化web页面
kind: Deployment
#apiVersion: extensions/v1beta1
apiVersion: apps/v1
metadata:
labels:
app: myserver-myapp
name: myserver-myapp-deployment-name
namespace: myserver
spec:
replicas: 1
selector:
matchLabels:
app: myserver-myapp-frontend
template:
metadata:
labels:
app: myserver-myapp-frontend
spec:
containers:
- name: myserver-myapp-container
image: nginx:1.16.0
#imagePullPolicy: Always
volumeMounts:
- mountPath: "/usr/share/nginx/html/myserver"
name: myserver-data
initContainers:
- name: init-web-data
image: centos:7.9.2009
command: ['/bin/bash','-c',"for i in `seq 1 10`;do echo ''$i web page at $(date +%Y%m%d%H%M%S) '' >> /data/nginx/html/myserver/index.html;sleep 1;done"]
volumeMounts:
- mountPath: "/data/nginx/html/myserver"
name: myserver-data
- name: change-data-owner
image: busybox:1.28
command: ['/bin/sh','-c',"/bin/chmod 644 /data/nginx/html/myserver/* -R"]
volumeMounts:
- mountPath: "/data/nginx/html/myserver"
name: myserver-data
volumes:
- name: myserver-data
hostPath:
path: /tmp/data/html
---
kind: Service
apiVersion: v1
metadata:
labels:
app: myserver-myapp-service
name: myserver-myapp-service-name
namespace: myserver
spec:
type: NodePort
ports:
- name: http
port: 80
targetPort: 80
nodePort: 30080
selector:
app: myserver-myapp-frontend
检查状态
kubectl get pod -n myserver -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
myserver-myapp-deployment-name-767f4878c-n57ls 1/1 Running 0 2m39s 10.200.100.82 192.168.74.149
5、探针
probe 是由 kubelet 对容器执行的定期诊断。 要执行诊断，kubelet 既可以在容器内执行代码，也可以发出一个网络请求。
1)探针机制
使用探针来检查容器有四种不同的方法。 每个探针都必须准确定义为这四种机制中的一种，探测结果分为Success，Failure，Unknown(诊断失败)：
exec
在容器内执行指定命令。如果命令退出时返回码为 0 则认为诊断成功。
grpc
使用 gRPC 执行一个远程过程调用。 目标应该实现 gRPC健康检查。 如果响应的状态是 "SERVING"，则认为诊断成功。 gRPC 探针是一个 alpha 特性，只有在你启用了 "GRPCContainerProbe" 特性门控时才能使用。
httpGet
对容器的 IP 地址上指定端口和路径执行 HTTP GET 请求。如果响应的状态码大于等于 200 且小于 400，则诊断被认为是成功的。
tcpSocket
对容器的 IP 地址上的指定端口执行 TCP 检查。如果端口打开，则诊断被认为是成功的。 如果远程系统（容器）在打开连接后立即将其关闭，这算作是健康的。
2）探测类型
针对运行中的容器，kubelet 可以选择是否执行以下三种探针，以及如何针对探测结果作出反应：
livenessProbe
指示容器是否正在运行。如果存活态探测失败，则 kubelet 会杀死容器， 并且容器将根据其重启策略决定未来。如果容器不提供存活探针， 则默认状态为 Success。
readinessProbe
指示容器是否准备好为请求提供服务。如果就绪态探测失败， 端点控制器将从与 Pod 匹配的所有服务的端点列表中删除该 Pod 的 IP 地址。 初始延迟之前的就绪态的状态值默认为 Failure。 如果容器不提供就绪态探针，则默认状态为 Success。
startupProbe
指示容器中的应用是否已经启动。如果提供了启动探针，则所有其他探针都会被 禁用，直到此探针成功为止。如果启动探测失败，kubelet 将杀死容器，而容器依其 重启策略进行重启。 如果容器没有提供启动探测，则默认状态为 Success。
3）参数配置
通用参数：
initialDelaySeconds：容器启动后要等待多少秒后才启动存活和就绪探测器， 默认是 0 秒，最小值是 0。
periodSeconds：执行探测的时间间隔（单位是秒）。默认是 10 秒。最小值是 1。
timeoutSeconds：探测的超时后等待多少秒。默认值是 1 秒。最小值是 1。
successThreshold：探测器在失败后，被视为成功的最小连续成功数。默认值是 1。 存活和启动探测的这个值必须是 1。最小值是 1。
failureThreshold：当探测失败时，Kubernetes 的重试次数。 对存活探测而言，放弃就意味着重新启动容器。 对就绪探测而言，放弃意味着 Pod 会被打上未就绪的标签。默认值是 3。最小值是 1。
http参数：
host：连接使用的主机名，默认是 Pod 的 IP。也可以在 HTTP 头中设置 “Host” 来代替。
scheme ：用于设置连接主机的方式（HTTP 还是 HTTPS）。默认是 "HTTP"。
path：访问 HTTP 服务的路径。默认值为 "/"。
httpHeaders：请求中自定义的 HTTP 头。HTTP 头字段允许重复。
port：访问容器的端口号或者端口名。如果数字必须在 1～65535 之间。
基于http的探针检测
apiVersion: apps/v1
kind: Deployment
metadata:
name: myserver-myapp-frontend-deployment
namespace: myserver
spec:
replicas: 1
selector:
matchLabels: #rs or deployment
app: myserver-myapp-frontend-label
#matchExpressions:
# - {key: app, operator: In, values: [myserver-myapp-frontend,ng-rs-81]}
template:
metadata:
labels:
app: myserver-myapp-frontend-label
spec:
containers:
- name: myserver-myapp-frontend-label
image: nginx:1.20.2
ports:
- containerPort: 80
#readinessProbe:
livenessProbe:
httpGet:
#path: /monitor/monitor.html
path: /index.html
port: 80
initialDelaySeconds: 5
periodSeconds: 3
timeoutSeconds: 3
successThreshold: 1
failureThreshold: 3
readinessProbe:
httpGet:
#path: /monitor/monitor.html
path: /index.html
port: 80
initialDelaySeconds: 5
periodSeconds: 3
timeoutSeconds: 3
successThreshold: 1
failureThreshold: 3
---
apiVersion: v1
kind: Service
metadata:
name: myserver-myapp-frontend-service
namespace: myserver
spec:
ports:
- name: http
port: 80
targetPort: 80
nodePort: 40018
protocol: TCP
type: NodePort
selector:
app: myserver-myapp-frontend-label
[root@kube-master-1 case3-Probe]#
检测
kubectl get pod -n myserver -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
myserver-myapp-frontend-deployment-84888c75cd-srz86 1/1 Running 0 2m15s 10.200.169.158 192.168.74.148
kubectl logs --tail 20 myserver-myapp-frontend-deployment-84888c75cd-srz86 -n myserver
192.168.74.148 - - [08/May/2022:08:02:02 +0000] "GET /index.html HTTP/1.1" 200 612 "-" "kube-probe/1.23" "-"
192.168.74.148 - - [08/May/2022:08:02:02 +0000] "GET /index.html HTTP/1.1" 200 612 "-" "kube-probe/1.23" "-"
192.168.74.148 - - [08/May/2022:08:02:05 +0000] "GET /index.html HTTP/1.1" 200 612 "-" "kube-probe/1.23" "-"
192.168.74.148 - - [08/May/2022:08:02:05 +0000] "GET /index.html HTTP/1.1" 200 612 "-" "kube-probe/1.23" "-"
192.168.74.148 - - [08/May/2022:08:02:08 +0000] "GET /index.html HTTP/1.1" 200 612 "-" "kube-probe/1.23" "-"
192.168.74.148 - - [08/May/2022:08:02:08 +0000] "GET /index.html HTTP/1.1" 200 612 "-" "kube-probe/1.23" "-"
192.168.74.148 - - [08/May/2022:08:02:11 +0000] "GET /index.html HTTP/1.1" 200 612 "-" "kube-probe/1.23" "-"
192.168.74.148 - - [08/May/2022:08:02:11 +0000] "GET /index.html HTTP/1.1" 200 612 "-" "kube-probe/1.23" "-"
192.168.74.148 - - [08/May/2022:08:02:14 +0000] "GET /index.html HTTP/1.1" 200 612 "-" "kube-probe/1.23" "-"
192.168.74.148 - - [08/May/2022:08:02:14 +0000] "GET /index.html HTTP/1.1" 200 612 "-" "kube-probe/1.23" "-"
192.168.74.148 - - [08/May/2022:08:02:17 +0000] "GET /index.html HTTP/1.1" 200 612 "-" "kube-probe/1.23" "-"
192.168.74.148 - - [08/May/2022:08:02:17 +0000] "GET /index.html HTTP/1.1" 200 612 "-" "kube-probe/1.23" "-"
192.168.74.148 - - [08/May/2022:08:02:20 +0000] "GET /index.html HTTP/1.1" 200 612 "-" "kube-probe/1.23" "-"
192.168.74.148 - - [08/May/2022:08:02:20 +0000] "GET /index.html HTTP/1.1" 200 612 "-" "kube-probe/1.23" "-"
192.168.74.148 - - [08/May/2022:08:02:23 +0000] "GET /index.html HTTP/1.1" 200 612 "-" "kube-probe/1.23" "-"
192.168.74.148 - - [08/May/2022:08:02:23 +0000] "GET /index.html HTTP/1.1" 200 612 "-" "kube-probe/1.23" "-"
192.168.74.148 - - [08/May/2022:08:02:26 +0000] "GET /index.html HTTP/1.1" 200 612 "-" "kube-probe/1.23" "-"
192.168.74.148 - - [08/May/2022:08:02:26 +0000] "GET /index.html HTTP/1.1" 200 612 "-" "kube-probe/1.23" "-"
192.168.74.148 - - [08/May/2022:08:02:29 +0000] "GET /index.html HTTP/1.1" 200 612 "-" "kube-probe/1.23" "-"
192.168.74.148 - - [08/May/2022:08:02:29 +0000] "GET /index.html HTTP/1.1" 200 612 "-" "kube-probe/1.23" "-"
基于TCP的探针检测
apiVersion: apps/v1
kind: Deployment
metadata:
name: myserver-myapp-frontend-deployment
namespace: myserver
spec:
replicas: 1
selector:
matchLabels: #rs or deployment
app: myserver-myapp-frontend-label
#matchExpressions:
# - {key: app, operator: In, values: [myserver-myapp-frontend,ng-rs-81]}
template:
metadata:
labels:
app: myserver-myapp-frontend-label
spec:
containers:
- name: myserver-myapp-frontend-label
image: nginx:1.20.2
ports:
- containerPort: 80
livenessProbe:
#readinessProbe:
tcpSocket:
#port: 80
port: 80
initialDelaySeconds: 5
periodSeconds: 3
timeoutSeconds: 5
successThreshold: 1
failureThreshold: 3
---
apiVersion: v1
kind: Service
metadata:
name: myserver-myapp-frontend-service
namespace: myserver
spec:
ports:
- name: http
port: 81
targetPort: 80
nodePort: 40012
protocol: TCP
type: NodePort
selector:
app: myserver-myapp-frontend
基于命令的探针检测
apiVersion: apps/v1
kind: Deployment
metadata:
name: myserver-myapp-redis-deployment
namespace: myserver
spec:
replicas: 1
selector:
matchLabels: #rs or deployment
app: myserver-myapp-redis-label
#matchExpressions:
# - {key: app, operator: In, values: [myserver-myapp-redis,ng-rs-81]}
template:
metadata:
labels:
app: myserver-myapp-redis-label
spec:
containers:
- name: myserver-myapp-redis-container
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
failureThreshold: 3
---
apiVersion: v1
kind: Service
metadata:
name: myserver-myapp-redis-service
namespace: myserver
spec:
ports:
- name: http
port: 6379
targetPort: 6379
nodePort: 40016
protocol: TCP
type: NodePort
selector:
app: myserver-myapp-redis-label
探针类型样例
apiVersion: apps/v1
kind: Deployment
metadata:
name: myserver-myapp-frontend-deployment
namespace: myserver
spec:
replicas: 1
selector:
matchLabels: #rs or deployment
app: myserver-myapp-frontend-label
#matchExpressions:
# - {key: app, operator: In, values: [myserver-myapp-frontend,ng-rs-81]}
template:
metadata:
labels:
app: myserver-myapp-frontend-label
spec:
terminationGracePeriodSeconds: 60
containers:
- name: myserver-myapp-frontend-label
image: nginx:1.20.2
ports:
- containerPort: 80
startupProbe:
httpGet:
#path: /monitor/index.html
path: /index.html
port: 80
initialDelaySeconds: 5 #首次检测延迟5s
failureThreshold: 3 #从成功转为失败的次数
periodSeconds: 3 #探测间隔周期
readinessProbe:
httpGet:
#path: /monitor/monitor.html
path: /index.html
port: 80
initialDelaySeconds: 5
periodSeconds: 3
timeoutSeconds: 5
successThreshold: 1
failureThreshold: 3
livenessProbe:
httpGet:
#path: /monitor/monitor.html
path: /index.html
port: 80
initialDelaySeconds: 5
periodSeconds: 3
timeoutSeconds: 5
successThreshold: 1
failureThreshold: 3
---
apiVersion: v1
kind: Service
metadata:
name: myserver-myapp-frontend-service
namespace: myserver
spec:
ports:
- name: http
port: 81
targetPort: 80
nodePort: 40012
protocol: TCP
type: NodePort
selector:
app: myserver-myapp-frontend-label
检测
kubectl describe pod myserver-myapp-frontend-deployment-855c89f977-q25nt -n myserver
Name: myserver-myapp-frontend-deployment-855c89f977-q25nt
Namespace: myserver
Priority: 0
Node: 192.168.74.149/192.168.74.149
Start Time: Sun, 08 May 2022 16:21:03 +0800
Labels: app=myserver-myapp-frontend-label
pod-template-hash=855c89f977
Annotations:
Status: Running
IP: 10.200.100.84
IPs:
IP: 10.200.100.84
Controlled By: ReplicaSet/myserver-myapp-frontend-deployment-855c89f977
Containers:
myserver-myapp-frontend-label:
Container ID: docker://4fd890b1628def272f990d5c2b3d4392a24f097141a45e858ee85de26f27acae
Image: nginx:1.20.2
Image ID: docker-pullable://nginx@sha256:03f3cb0afb7bd5c76e01bfec0ce08803c495348dccce37bcb82c347b4853c00b
Port: 80/TCP
Host Port: 0/TCP
State: Running
Started: Sun, 08 May 2022 16:21:23 +0800
Ready: True
Restart Count: 0
Liveness: http-get http://:80/index.html delay=5s timeout=5s period=3s #success=1 #failure=3
Readiness: http-get http://:80/index.html delay=5s timeout=5s period=3s #success=1 #failure=3
Startup: http-get http://:80/index.html delay=5s timeout=1s period=3s #success=1 #failure=3
Environment:
Mounts:
/var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-kfkf2 (ro)
Conditions:
Type Status
Initialized True
Ready True
ContainersReady True
PodScheduled True
Volumes:
kube-api-access-kfkf2:
Type: Projected (a volume that contains injected data from multiple sources)
TokenExpirationSeconds: 3607
ConfigMapName: kube-root-ca.crt
ConfigMapOptional:
DownwardAPI: true
QoS Class: BestEffort
Node-Selectors:
Tolerations: node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 2m32s default-scheduler Successfully assigned myserver/myserver-myapp-frontend-deployment-855c89f977-q25nt to 192.168.74.149
Normal Pulling 2m31s kubelet Pulling image "nginx:1.20.2"
Normal Pulled 2m12s kubelet Successfully pulled image "nginx:1.20.2" in 19.286392842s
Normal Created 2m12s kubelet Created container myserver-myapp-frontend-label
Normal Started 2m12s kubelet Started container myserver-myapp-frontend-label
4）重启策略
Pod一旦配置探针，在检测失败时候，会基于restartPolicy对Pod进行下一步 *** 作，restartPolicy(容器重启策略)：
Always:当容器异常时， k8s自动重启该容器，默认策略
ReplicationController/Replicaset/Deployment,默认为Always.OnFailure:当容器失败时(容器停止运行且退出码不为O),k8s自动重启该容器。
Never:不论容器运行状态如何都不会重启该容器,Job或CronJob。
容器启动过程中类型:
startupProbe：#启动探针，判断容器内的应用程序是否已启动完成，如果配置了启动探测，则会先禁用所有其它的探测，直到startupProbe检测成功为止，如果startupProbe探测失败，则kubelet将杀死容器，容器将按照重启策略进行下一步 *** 作，如果容器没有提供启动探测，则默认状态为成功
livenessProbe(检测失败后重启pod): #存活探针，检测容器容器是否正在运行，如果存活探测失败，则kubelet会杀死容器，并且容器将受到其重启策略的影响。如果容器不提供存活探针，则默认状态为Success，livenessProbe用于控制是否重启pod。
readinessProbe(检测失败后从service中摘除)：#就绪探针，如果就绪探测失败，端点控制器将从与Pod匹配的所有Service的端点中删除该Pod的IP地址，初始延迟之前的就绪状态默认为Failure(失败)，如果容器不提供就绪探针，则默认状态为Success,readinessProbe用于控制pod是否添加至service。
6、pod终止
由于 Pod 所代表的是在集群中节点上运行的进程，当不再需要这些进程时允许其体面地 终止是很重要的。一般不应武断地使用 KILL 信号终止它们，导致这些进程没有机会 完成清理 *** 作。
设计的目标是令你能够请求删除进程，并且知道进程何时被终止，同时也能够确保删除 *** 作终将完成。当你请求删除某个 Pod 时，集群会记录并跟踪 Pod 的体面终止周期， 而不是直接强制地杀死 Pod。在存在强制关闭设施的前提下， kubelet 会尝试体面地终止 Pod。
通常情况下，容器运行时会发送一个 TERM 信号到每个容器中的主进程。 很多容器运行时都能够注意到容器镜像中 STOPSIGNAL 的值，并发送该信号而不是 TERM。 一旦超出了体面终止限期，容器运行时会向所有剩余进程发送 KILL 信号，之后 Pod 就会被从 API 服务器 上移除。如果 kubelet 或者容器运行时的管理服务在等待进程终止期间被重启， 集群会从头开始重试，赋予 Pod 完整的体面终止限期。
1)pod终止流程
①你使用 kubectl 工具手动删除某个特定的 Pod，而该 Pod 的体面终止限期是默认值（30 秒）。
②API 服务器中的 Pod 对象被更新，记录涵盖体面终止限期在内 Pod 的最终死期，超出所计算时间点则认为 Pod 已死（dead）。 如果你使用 kubectl describe 来查验你正在删除的 Pod，该 Pod 会显示为 "Terminating" （正在终止）。 在 Pod 运行所在的节点上：kubelet 一旦看到 Pod 被标记为正在终止（已经设置了体面终止限期），kubelet 即开始本地的 Pod 关闭过程。
如果 Pod 中的容器之一定义了 preStop 回调， kubelet 开始在容器内运行该回调逻辑。如果超出体面终止限期时，preStop 回调逻辑 仍在运行，kubelet 会请求给予该 Pod 的宽限期一次性增加 2 秒钟。
kubelet 接下来触发容器运行时发送 TERM 信号给每个容器中的进程 1。
③与此同时，kubelet 启动体面关闭逻辑，控制面会将 Pod 从对应的端点列表（以及端点切片列表， 如果启用了的话）中移除，过滤条件是 Pod 被对应的 服务以某 选择算符选定。 ReplicaSets和其他工作负载资源 不再将关闭进程中的 Pod 视为合法的、能够提供服务的副本。关闭动作很慢的 Pod 也无法继续处理请求数据，因为负载均衡器（例如服务代理）已经在终止宽限期开始的时候 将其从端点列表中移除。超出终止宽限期限时，kubelet 会触发强制关闭过程。容器运行时会向 Pod 中所有容器内 仍在运行的进程发送 SIGKILL 信号。 kubelet 也会清理隐藏的 pause 容器，如果容器运行时使用了这种容器的话。
⑤kubelet 触发强制从 API 服务器上删除 Pod 对象的逻辑，并将体面终止限期设置为 0 （这意味着马上删除）。
⑥API 服务器删除 Pod 的 API 对象，从任何客户端都无法再看到该对象。
2)容器回调：
PostStart
这个回调在容器被创建之后立即被执行。 但是，不能保证回调会在容器入口点（ENTRYPOINT）之前执行。 没有参数传递给处理程序。
PreStop
在容器因 API 请求或者管理事件（诸如存活态探针、启动探针失败、资源抢占、资源竞争等） 而被终止之前，此回调会被调用。 如果容器已经处于已终止或者已完成状态，则对 preStop 回调的调用将失败。 在用来停止容器的 TERM 信号被发出之前，回调必须执行结束。 Pod 的终止宽限周期在 PreStop 回调被执行之前即开始计数，所以无论 回调函数的执行结果如何，容器最终都会在 Pod的终止宽限期内被终止。 没有参数会被传递给处理程序。
postStart与preStop实例
apiVersion: apps/v1
kind: Deployment
metadata:
name: myserver-myapp1-lifecycle
labels:
app: myserver-myapp1-lifecycle
namespace: myserver
spec:
replicas: 1
selector:
matchLabels:
app: myserver-myapp1-lifecycle-label
template:
metadata:
labels:
app: myserver-myapp1-lifecycle-label
spec:
terminationGracePeriodSeconds: 60
containers:
- name: myserver-myapp1-lifecycle-label
image: tomcat:7.0.94-alpine
lifecycle:
postStart:
exec:
#command: 把自己注册到注册在中心
command: ["/bin/sh", "-c", "echo 'Hello from the postStart handler' >> /usr/local/tomcat/webapps/ROOT/index.html"]
#httpGet:
# #path: /monitor/monitor.html
# host: www.magedu.com
# port: 80
# scheme: HTTP
# path: index.html
preStop:
exec:
#command: 把自己从注册中心移除
command: ["/usr/local/tomcat/bin/catalina.sh","stop"]
ports:
- name: http
containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
name: myserver-myapp1-lifecycle-service
namespace: myserver
spec:
ports:
- name: http
port: 80
targetPort: 8080
nodePort: 30012
protocol: TCP
type: NodePort
selector:
app: myserver-myapp1-lifecycle-label
kubectl get pod -n myserver -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
myserver-myapp1-lifecycle-6f7b4f659-s9gw4 1/1 Running 0 4m12s 10.200.169.160 192.168.74.148
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）