一、yaml文件详解
Kubernetes支持YAML 和JSON 格局办理资源目标 JSON格局:首要用于api 接口之间消息的传递 YAML格局:用于装备和办理，YAML 是一种简练的非标记性言语，内容格局人性化，较易读
YAML语法格局: ●大小写敏感 ●运用缩进表明层级联系 ●不支持Tab键制表符缩进，只运用空格缩进 ●缩进的空格数目不重要，只要相同层级的元素左侧对齐即可，一般开头缩进两个空格: ●字符后缩进一 个空格，如冒号，逗号，短横杆(-)等 ●”—“表明YAML格局， 一个文件的开始，用于分隔文件间 ●“#”表明注释
#查看api资源版别标签
kubectl api-versions
admissionregistration.k8s.io/vlbeta1
apiextensions.k8s.io/v1beta1
apiregistration.k8s.io/v1
apiregistration.k8s.io/v1beta1
apps/v1
#假如是事务场景一般首选运用apps/v1
apps/v1beta1
#带有beta字样的代表的是测验版别，不必在出产环境中
apps/v1beta2
authentication.k8s.io/v1
authentication.k8s.io/v1beta1
authorization.k8s.io/v1
authorization.k8s.io/vlbeta1
autoscaling/v1
autoscaling/v2beta1
autoscaling/v2beta2
batch/v1
batch/v1beta1
certificates.k8s.io/vlbeta1
coordination.k8s.io/vlbeta1
events.k8s.io/vlbeta1
extensions/v1beta1
networking.k8s.io/v1
policy/v1beta1
rbac.authorization.k8s.io/v1
rbac.authorization.k8s.io/v1beta1
scheduling.k8s.io/v1
scheduling.k8s.io/v1beta1
storage.k8s.io/v1
storage.k8s.io/v1beta1
v1
//写一个yaml文件demo
mkdir /opt/demo
cd demo/
如何写pod资源
cat > pod2.yaml<<-EOF
apiVersion: v1
kind: Pod
#界说资源的类型/人物，deployment 为副本控制器，此处资源类型能够是Deployment、Job、 Ingress、 Service等
metadata:
#界说资源的元数据信息，比方资源的称号、namespace、标签等信息
name: nginxdemo1
#界说资源的称号，在同一个namespace空间中有必要是仅有的
namespace: ky18
#所属命名空间
labels:
#界说资源标签(Pod的标签)
app: nginx
#标签
spec:
#界说deployment资源需求的参数特点，比方是否在容器失利时从头发动容器的特点
containers:
#界说容器特点
- name: nginx
#界说一个容器名，一个- name: 界说一个容器
image: nginx:1.15.4
#界说容器运用的镜像以及版别
ports:
#界说端口号
- name: http
#端口名
containerPort: 80
#界说容器的对外的端口,能够界说多个端口
EOF
kubectl apply -f nginx-demo1.yaml
kubectl get deploy -n kube-public
如何写Deployment资源
cat > deployment01.yaml<<-EOF
apiVersion: apps/v1 #指定api版别标签
kind: Deployment #界说资源的类型/人物，deployment 为副本控制器，此处资源类型能够是Deployment、Job、 Ingress、 Service等
metadata: #界说资源的元数据信息，比方资源的称号、namespace、标签等信息
name: nginx-deployment #界说资源的称号，在同一个namespace空间中有必要是仅有的
namespace: default #所属命名空间
labels: #界说资源标签(Pod的标签)
app: nginx #标签
spec: #界说deployment资源需求的参数特点，比方是否在容器失利时从头发动容器的特点
replicas: 3 #界说资源的副本数量
selector : #界说标签挑选器
matchLabels: #界说匹配标签
app: nginx #匹配上面的标签，需与上面的标签界说的app保持共同，才能让pod和控制器绑定
template: #界说pod事务模板，假如有多个副本，一切副本的特点会依照模板的相关装备进行匹配
metadata: #设置资源称号
labels:
app: nginx #和标签挑选器共同，pod类型不必加
spec:
containers: #界说容器特点
- name: nginx #界说一个容器名，一个- name: 界说一个容器
image: nginx:1.15.4 #界说容器运用的镜像以及版别
ports: #界说端口号
- name: http #端口名
containerPort: 80 #界说容器的对外的端口,能够界说多个端口
args:
#开机战略
- /bin/sh
- -c
- sleep 30; exit 3
resources:
#资源装备
requests:
#预留资源
memory: "64Mi"
#内存
cpu: "250m"
#CPU
limits:
#最大资源
memory: "128Mi"
#内存
cpu: "500m"
#CPU
livenessProbe:
exec:
command:
- cat
- /tmp/healthy
failureThreshold: 1
initialDelaySeconds: 5
periodSeconds: 5
restartPolicy: Never
#重启战略
- name..... #假如要加多个容器
EOF
kubectl apply -f nginx-demo1.yaml
kubectl get deploy -n kube-public
如何写service资源
cat > service01.yaml<<-EOF
apiVersion: v1
kind: Service
metadata :
name: nginx-service
labels:
app: nginx
#service有必要要标签
spec:
#模式
type: NodePort
#指定端口
ports:
#映射端口
- port: 80
#容器映射的端口号
targetPort: 80
#对外映射的端口
nodePort: 31234
#标签挑选器
selector:
#yaml文件中键值对用:表明不能用=
app: nginx
EOF
#创立资源目标
kubectl apply -f nginx-service.yaml
#查看创立的:service
kubectl get svc
#在浏览器输入nodeIP: nodePort 即可拜访
http://192.168.80.11:31234
http://192.168.80.12:31234
----------------------------------------------
详解k8s中的port:
●port
port是k8s集群内部拜访service的端口，即经过clusterIP: port能够从Pod地点的Node. 上拜访到service
●nodePort
nodePort是外部拜访k8s集群中service的端口，经过nodeIP: nodePort 能够从外部拜访到某个service。
●targetPort
targetPort是Pod的端口，从port或nodePort来的流量经过kube-proxy 反向署理负载均衡转发到后端Pod的targetPort上，最终进入容器。
●containerPort
containerPort是Pod内部容器的端口，targetPort 映射到containerPort
--dry-run=client#对现有资源创立yaml文件，这个指令能够假跑，然后配合重定向创立yaml文件，之后改这个文件里的值就行了
#kubectl run --dry-run 打印相应的API 目标而不履行创立
kubectl run nginx-test --image=nginx --port=80 --replicas=3 --dry-run
#查看生成yaml格局
kubectl run nginx-test --image=nginx --port=80 --replicas=3 --dry-run -o yaml
#查看生成json格局
kubectl run nginx-test --image=nginx --port=80 --replicas=3 --dry-run -o json
#运用yaml格局导出生成模板，并进行修正以及删去一些不必要的参数
kubectl run nginx-test --image=nginx --port=80 --replicas=3 --dry-run -o yaml > nginx-test.yaml
#将现有的资源生成模板导出I
kubectl get deployment/nginx-deployment --export -o yaml
#保存到文件中
kubectl get deploy/nginx-deployment --export -o yaml > my-deploy.yaml
#查看字段协助信息，可一层层的查看相关资源目标的协助信息
kubectl explain deployments.spec.template.spec.ontainers
或
kubectl explain pods.spec.containers
#写yaml太累怎么办?
●用run指令生成
kubectl run my-deploy --image=nginx --dry-run -o yaml > my-deploy.yaml
●用get指令导出
kubectl get deploy/nginx-deployment --export -o=yaml > new.yaml
#yaml文件的学习办法:
(1)多看别人(官方)写的，能读懂
(2)能照着现场的文件改着用
(3)遇到不懂的，善用kubectl explain ...指令查折叠
注：当然能够放在一起写
一、Pod根底概念
======Pod根底概念:======
Pod是kubernetes中最小的资源办理组件，Pod也是最小化运转容器化运用的资源目标。一个Pod代表着集群中运转的一个进程。kubernetes
中其他大多数组件都是围绕着Pod来进行支撑和扩展Pod功用的，例如，用于办理Pod运转的StatefulSet和Deployment等控制器目标，用于
露出Pod运用的Service和Ingress目标，为Pod供给存储的PersistentVolume存储资源目标等
======在Kubrenetes集群中Pod有如下两种运用办法:======
●一个Pod中运转一个容器。“每个Pod中一个容器”的模式是最常见的用法;在这种运用办法中，你能够把Pod幻想成是单个容器的封装，kub
erentes办理的是Pod而不是直接办理容器。
●在一个Pod中一起运转多个容器。一个Pod中也能够一起封装几个需求严密耦合相互协作的容器，它们之间同享资源。这些在同一个Pod中
的容器能够相互协作成为一个service单位，比方一个容器同享文件，另一个"sidecar"容器来更新这些文件。Pod将这些容器的存储资源作
为一个实体来办理
一个Pod下的容器有必要运转于同一节点上。现代容器技能主张一个容器只运转一个进程，该进程在容器中PID指令空间中的进程号为1，可直
接接收并处理信号，进程停止时容器生命周期也就完毕了。若想在容器内运转多个进程，需求有一个相似Linux操作系统init进程的管控类
进程，以树状结构完结多进程的生命周期办理。运转于各自容器内的进程无法直接完结网络想信，这是由于容器间的阻隔机制导致，k8s中
的Pod资源抽象正是处理此类问题，Pod目标是一组容器的调集，这些容器同享Network、UTS及IPC指令空间，因而具有相同的域名、主机名
和网络接口，并可经过IPC直接通讯
Pod资源中针对各容器供给网络指令空间等同享机制的是底层根底容器pause，根底容器(也可称为父容器)pause便是为了办理Pod容器间
的共字操作，这个父容器需求能够精确地知道如何去创立同享运转环境的容器，还能办理这些容器的生命周期。为了实现这个父容器的构
想，kubernetes中，用pause容器来作为一个Pod中一切容器的父容器。这个pause容器有两个中心的功用，一是它供给整个Pod的Linux命名
空间的根底。二来启用PID命名空间，它在每个Pod中都作为PID为1进程(init进程) ，并收回僵尸进程
======pause容器使得Pod中的一切容器能够同享两种资源:网络和存储======
●网络:
每个Pod都会被分配一个仅有的IP地址。Pod中的一切容器同享网络空间，包含IP地址和端口。Pod内部的容器能够运用localhost相互通讯
Pod中的容器与外界通讯时，有必要分配同享网络资源(例如运用宿主机的端口映射)
●存储:
能够Pod指定多个同享的Volume。Pod中的一切容器都能够拜访同享的Volume。Volume也能够用来持久化Pod中的存储资源，以防容器重启后文件丢掉
======一般把Pod分为两类:======
●自主式Pod
这种Pod自身是不能自我修正的，当Pod被创立后(不论是由你直接创立还是被其他Controller)，都会被Kuberentes调度到集群的Node上
。直到Pod的进程停止、被删掉、由于短少资源而被驱逐、或许Node毛病之前这个Pod都会一向保持在那个Node上。Pod不会自愈。假如Pod
运转的Node毛病，或许是调度器自身毛病，这个Pod就会被删去。同样的，假如Pod地点Node短少资源或许Pod处于保护状况，Pod也会被驱
逐
●控制器办理的Pod
Kubernetes运用更高档的称为Controller的抽象层，来办理Pod实例。Controller可 以创立和办理多个Pod，供给副本办理、滚动升级和集
群等级的自愈能力。例如，假如一个Node毛病，Controller就能主动将该节点上的Pod调度到其他健康的Node上。虽然能够直接运用Pod,
但是在Kubernetes中一般是运用Controller来办理Pod的
每个Pod都有一个特别的被称为“根容器”的Pause容器。Pause容器对应的镜像属于Kubernetes渠道的一部分，除了Pause容器，每个Pod还包
含一个或许多个严密相关的用户事务容器
======kubernetes中的pause容器首要为每个事务容器供给以下功用:======
●在pod中担任Linux命名空间(如网络指令空间)同享的根底;
●启用PID命名空间，敞开init进程
======Kubernetes规划这样的Pod概念和特别组成结构有什么用意?======
●原因一:在一组容器作为一个单元的情况下，难以对整体的容器简略地进行判别及有效地进行举动。比方，一个容器死亡了，此时是算整
体挂了么?那么引入与事务无关的Pause容器作为Pod的根容器，以它的状况代表着整个容器组的状况，这样就能够处理该问题
●原因二:Pod里的多个事务容器同享Pause容器的IP，同享Pause容器挂载的Volume，这样简化了事务容器之间的通讯问题，也处理了容器
之间的文件同享问题折叠
二、Pod中容器的分类
======Pod容器的分类:======
1、pose根底容器( infrastructure container)
//保护整个Pod网络和存储空间
//node节点中操作
//发动一个容器时，k8s会主动发动一个根底容器
cat /opt/kubernetes/cfg/kubelet
-- pod-infra-container-image=registry.cn-hangzhou.aliyuncs.com/google-containers/pause-amd64:3.0
//每次创立Pod 时分就会创立，运转的每一个容器都有一个pause-amd64 的根底容器主动会运转，关于用户是通明的
docker ps -a
registry.cn-hangzhou.aliyuncs.com/google-containers/pause-amd64:3.0 "/pause"
2、init初始化容器( initcontainers )
//Init容器有必要在运用程序容器发动之前运转完结，而运用程序容器是并行运转的，所以Init容器能够供给了一种简略的阻塞或延迟运用
容器的发动的办法。
Init容器与普通的容器十分像，除了以下两点:
●Init容器总是运转到成功完结停止
●每个Init 容器都有必要鄙人一个Init 容器发动之前成功完结
假如Pod的Init 容器失利，k8s会不断地重启该Pod， 直到Init 容器成功停止。但是，假如Pod
对应的重启战略( restartPolicy)为Never， 它不会从头发动
3、main事务容器( Maincontainer )
//并行发动
官网示例:
https://kubernetes.io/docs/concepts/workloads/pods/init-containers/
apiVersion: v1
kind: Pod
metadata:
name: myapp-pod
labels:
app: myapp
spec:
containers:
- name: myapp-container
image: busybox:1.28
command: ['sh','-c','echo The app is running! && sleep 3600' ]
#容器起动时的默许
initContainers:
- name: init-myservice
image: busybox:1.28
command: ['sh','-c','until nslookup myservice; do echo waiting for myservice; sleep 2; done;']
#解析的service的称号
- name: init -mydb
image: busybox:1.28
command: ['sh', '-c', "until nslookup mydb.$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace).svc.cluster.local; do echo waiting for mydb; sleep 2; done"]
这个比方是界说了一个具有2个Init容器的简略Pod。
第一个等候myservice 发动，第二个等候mydb 发动。一旦这两个Init容器都发动完结，Pod 将发动spec中的运用容器。
//特别阐明:
●在Pod发动过程中，Init容器会按次序在网络和数据卷初始化之后发动。每个容器有必要鄙人一个容器发动之前成功退出
●假如由于运转时或失利退出，将导致容器发动失利，它会依据Pod的restartPolicy指定的战略进行重试。但是，假如Pod的restartPolicy
设置为Always，Init容 器失利时会运用RestartPolicy战略
●在一切的Init容器没有成功之前，Pod将不 会变成Ready状况。Init 容器的端口将不会在Service中进行聚集。正在初始化中的Pod处于Pend
ing状况，但应该会将Initializing状况设置为true
●假如Pod重启，一切Init容器有必要从头履行
●对Init容器spec的修正被约束在容器image字段，修正其他字段都不会收效。更改Init容器的image字段，等价于重启该Pod
●Init容器具有运用容器的一切字段。除了readinessProbe，由于Init容器无法界说不同于完结(completion) 的安排妥当( readiness)之外的其他状况。这会在验证过程中强制履行
●在Pod中的每个app和Init容器的称号有必要仅有;与任何其它容器同享同一个称号，会在验证时抛出错误
//镜像拉取战略( image PullPolicy) :
Pod的中心是运转容器，有必要指定容器引擎，比方Docker， 发动容器时，需求拉取镜像，k8s 的镜像拉取战略能够由用户指定:
1、IfNotPresent:在镜像现已存在的情况下，kubelet将不再去拉取镜像，仅当本地缺失时才从仓库中拉取，默许的镜像拉取战略
2、Always: 每次创立Pod 都会从头拉取一次镜像;
3、Never: Pod不会主动拉取这个镜像，仅运用本地镜像
留意:关于标签为“:latest”的镜像文件，其默许的镜像获取战略即为“Always”;而关于其他标签的镜像，其默许战略则为“IfNotPresent"
官方示例:
https://kubernetes.io/docs/concepts/containers/images
cat <<EOF > pod.yaml
apiVersion: v1
kind: Pod
metadata:
name: foo
namespace: awesomeapps
spec:
containers:
- name: foo
image: janedoe/awesomeapp:v1
imagePullSecrets:
- name: myregistrykey
EOF
cat <<EOF >> ./kustomization.yaml
resources:
- pod.yaml
EOF
//创立测验案例
mkdir / opt/ demo
cd /opt/ demo
vim pod1 . yaml
apiVersion: v1
kind: Pod
metadata :
name: pod-test1
spec:
containers :
- name: nginx
image :
nginx
imagePullPolicy: Always
command:
[ "echo",
"SUCCESS"
kubectl create -f pod1 . yaml
kubectl get pods -o wide
pod-test1
0/1
Cra shLoopBackOf f
4
//重启战略(restartPolicy) :
和containers字段在同一层，当Pod中的容器退出时经过节点上的kubelet 重启容器。适用于Pod中的一切容器。
1、Always: 当容器停止退出后，总是重启容器，不管回来状况码如何，默许战略
2、OnFailure: 当容器反常退出(退出状况码非0)时，重启容器;正常退出则不重启容器
3、NEver: 当容器停止退出，不管回来状况码如何，从不重启容器。
#留意: K8S中不支持重启Pod资源，只要删去重建
深入了解pod
一、资源约束
当界说 Pod 时能够挑选性地为每个容器设定所需求的资源数量。 最常见的可设定资源是 CPU 和内存大小，以及其他类型的资源
当为 Pod 中的容器指定了 request 资源时，调度器就运用该信息来决定将 Pod 调度到哪个节点上。当还为容器指定了 limit 资源时，kubelet 就会保证运转的容器不会运用超出所设的 limit 资源量。kubelet 还会为容器预留所设的 request 资源量， 供该容器运用
假如 Pod 运转地点的节点具有满足的可用资源，容器能够运用超出所设置的 request 资源量。不过，容器不能够运用超出所设置的 limit 资源量
假如给容器设置了内存的 limit 值，但未设置内存的 request 值，Kubernetes 会主动为其设置与内存 limit 相匹配的 request 值。相似的，假如给容器设置了 CPU 的 limit 值但未设置 CPU 的 request 值，则 Kubernetes 主动为其设置 CPU 的 request 值 并使之与 CPU 的 limit 值匹配
官网示例： kubernetes.io/docs/concep…
======Pod 和 容器 的资源恳求和约束：======
spec.containers[].resources.requests.cpu //界说创立容器时预分配的CPU资源
spec.containers[].resources.requests.memory //界说创立容器时预分配的内存资源
spec.containers[].resources.limits.cpu //界说 cpu 的资源上限
spec.containers[].resources.limits.memory //界说内存的资源上限
我再
二、CPU资源单位
CPU 资源的 request 和 limit 以 cpu 为单位。Kubernetes 中的一个 cpu 相当于1个 vCPU（1个超线程）
Kubernetes 也支持带小数 CPU 的恳求。spec.containers[].resources.requests.cpu 为 0.5 的容器能够获得一个 cpu 的一半 CPU 资源（相似于Cgroup对CPU资源的时刻分片）
表达式 0.1 等价于表达式 100m（毫核），表明每 1000 毫秒内容器能够运用的 CPU 时刻总量为 0.1*1000 毫秒
三、内存 资源单位
内存的 request 和 limit 以字节为单位。能够以整数表明，或许以10为底数的指数的单位（E、P、T、G、M、K）来表明， 或许以2为底数的指数的单位（Ei、Pi、Ti、Gi、Mi、Ki）来表明
如：1KB=10^3=1000，1MB=10^6=1000000=1000KB，1GB=10^9=1000000000=1000MB
1KiB=2^10=1024，1MiB=2^20=1048576=1024KiB
PS：在买硬盘的时分，操作系统报的数量要比产品标出或商家声称的小一些，首要原因是标出的是以 MB、GB为单位的，1GB 便是1,000,000,000Byte，而操作系统是以2进制为处理单位的，因而查看硬盘容量时是以MiB、GiB为单位，1GB=2^30=1,073,741,824，相比较而言，1GiB要比1GB多出1,073,741,824-1,000,000,000=73,741,824Byte，所以检测实际成果要比标出的少一些。
======示例1：======
apiVersion: v1
kind: Pod
metadata:
name: frontend
spec:
containers:
- name: app
image: images.my-company.example/app:v4
env:
- name: MYSQL_ROOT_PASSWORD
value: "password"
resources:
requests:
#预留资源
memory: "64Mi"
cpu: "250m"
limits:
#最大资源
memory: "128Mi"
cpu: "500m"
- name: log-aggregator
image: images.my-company.example/log-aggregator:v6
resources:
requests:
memory: "64Mi"
cpu: "250m"
limits:
memory: "128Mi"
cpu: "500m"
此比方中的 Pod 有两个容器。每个容器的 request 值为 0.25 cpu 和 64MiB 内存，每个容器的 limit 值为 0.5 cpu 和 128MiB 内存。那么能够以为该 Pod 的总的资源 request 为 0.5 cpu 和 128 MiB 内存，总的资源 limit 为 1 cpu 和 256MiB 内存
======示例2：======
vim pod2.yaml
apiVersion: v1
kind: Pod
metadata:
name: frontend
spec:
containers:
- name: web
image: nginx
env:
- name: WEB_ROOT_PASSWORD
value: "password"
resources:
requests:
memory: "64Mi"
cpu: "250m"
limits:
memory: "128Mi"
cpu: "500m"
- name: wp
image: wordpress
resources:
requests:
memory: "64Mi"
cpu: "250m"
limits:
memory: "128Mi"
cpu: "500m"
kubectl apply -f pod2.yaml
kubectl describe pod frontend
kubectl get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
frontend 2/2 Running 5 15m 10.244.2.4 node02 <none> <none>
kubectl describe nodes node02 #由于当时虚拟机有2个CPU，所以Pod的CPU Limits总共占用了50%
Namespace Name CPU Requests CPU Limits Memory Requests Memory Limits AGE
--------- ---- ------------ ---------- --------------- ------------- ---
default frontend 500m (25%) 1 (50%) 128Mi (3%) 256Mi (6%) 16m
kube-system kube-flannel-ds-amd64-f4pbp 100m (5%) 100m (5%) 50Mi (1%) 50Mi (1%) 19h
kube-system kube-proxy-pj4wp 0 (0%) 0 (0%) 0 (0%) 0 (0%) 19h
Allocated resources:
(Total limits may be over 100 percent, i.e., overcommitted.)
Resource Requests Limits
-------- -------- ------
cpu 600m (30%) 1100m (55%)
memory 178Mi (4%) 306Mi (7%)
ephemeral-storage 0 (0%) 0 (0%)折叠
四、重启战略
Pod 在遇到毛病之后重启的动作 1.Always：当容器停止退出后，总是重启容器，默许战略 2.OnFailure：当容器反常退出（退出状况码非0）时，重启容器；正常退出则不重启容器 3.Never：当容器停止退出，从不重启容器
注：K8S 中不支持重启 Pod 资源，只要删去重建
======示例======
vim pod3.yaml
apiVersion: v1
kind: Pod
metadata:
name: foo
spec:
containers:
- name: busybox
image: busybox
args:
- /bin/sh
- -c
- sleep 30; exit 3
kubectl apply -f pod3.yaml
======查看Pod状况，等容器发动后30秒后履行exit退出进程进入error状况，就会重启次数加1======
kubectl get pods
NAME READY STATUS RESTARTS AGE
foo 1/1 Running 1 50s
kubectl delete -f pod3.yaml
vim pod3.yaml
apiVersion: v1
kind: Pod
metadata:
name: foo
spec:
containers:
- name: busybox
image: busybox
args:
- /bin/sh
- -c
- sleep 30; exit 3
restartPolicy: Never
#留意：跟container同一个等级
kubectl apply -f pod3.yaml
//容器进入error状况不会进行重启
kubectl get pods -w
五、健康查看（探针 Probe）
探针是由kubelet对容器履行的定时确诊
探针的三种规矩： ●livenessProbe存活探针 ： 判别容器是否正在运转。假如勘探失利，则kubelet会杀死容器，而且容器将依据 restartPolicy 来设置 Pod 状况。假如容器不供给存活探针，则默许状况为Success。以前没用发动探针，配合延迟来判别
●readinessProbe安排妥当探针 ： 判别容器是否准备好接受恳求。假如勘探失利，端点控制器将从与 Pod 匹配的一切 service endpoints 中剔除删去该Pod的IP地址。初始延迟之前的安排妥当状况默许为Failure。假如容器不供给安排妥当探针，则默许状况为Success。
●startupProbe发动探针 （这个1.17版别增加的）：判别容器内的运用程序是否已发动，首要针关于不能确定具体发动时刻的运用。假如装备了 startupProbe 勘探，在则在 startupProbe 状况为 Success 之前，其他一切探针都处于无效状况，直到它成功后其他探针才起作用。 假如 startupProbe 失利，kubelet 将杀死容器，容器将依据 restartPolicy 来重启。假如容器没有装备 startupProbe， 则默许状况为 Success
注：以上规矩能够一起界说。在readinessProbe检测成功之前，Pod的running状况是不会变成ready状况的
发动探针Probe支持三种查看办法：
●exec ： 在容器内履行指定指令。假如指令退出时回来码为0则以为确诊成功
●tcpSocket ： 对指定端口上的容器的IP地址进行TCP查看（三次握手）。假如端口打开，则确诊被以为是成功的
●httpGet ： 对指定的端口和路径上的容器的IP地址履行HTTPGet恳求。假如呼应的状况码大于等于200且小于400，则确诊被以为是成功的，相当于发送了一个ping
每次勘探都将获得以下三种成果之一： ●成功：容器经过了确诊。 ●失利：容器未经过确诊。 ●未知：确诊失利，因而不会采取任何举动
官网示例：
kubernetes.io/docs/tasks/…
======示例1：exec办法======
apiVersion: v1
kind: Pod
metadata:
labels:
test: liveness
name: liveness-exec
spec:
containers:
- name: liveness
image: k8s.gcr.io/busybox
args:
#容器履行时默许履行的指令
- /bin/sh
- -c
- touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 60
livenessProbe:
exec:
command:
- cat
- /tmp/healthy
failureThreshold: 1
initialDelaySeconds: 5
periodSeconds: 5
#initialDelaySeconds：指定 kubelet 在履行第一次勘探前应该等候5秒，即第一次勘探是在容器发动后的第6秒才开始履行。默许是 0 秒，最小值是 0。
#periodSeconds：指定了 kubelet 应该每 5 秒履行一次存活勘探。默许是 10 秒。最小值是 1。
#failureThreshold: 当勘探失利时，Kubernetes 将在抛弃之前重试的次数。 存活勘探情况下的抛弃就意味着从头发动容器。安排妥当勘探情况下的抛弃 Pod 会被打上未安排妥当的标签。默许值是 3。最小值是 1。
#timeoutSeconds：勘探的超时后等候多少秒。默许值是 1 秒。最小值是 1。（在 Kubernetes 1.20 版别之前，exec 探针会疏忽 timeoutSeconds 探针会无限期地 持续运转，乃至可能超过所装备的限期，直到回来成果停止。）
vim exec.yaml
apiVersion: v1
kind: Pod
metadata:
name: liveness-exec
namespace: default
spec:
containers:
- name: liveness-exec-container
image: busybox
imagePullPolicy: IfNotPresent
command: ["/bin/sh","-c","touch /tmp/live ; sleep 30; rm -rf /tmp/live; sleep 3600"]
livenessProbe:
exec:
command: ["test","-e","/tmp/live"]
initialDelaySeconds: 1
periodSeconds: 3
kubectl create -f exec.yaml
kubectl describe pods liveness-exec
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 51s default-scheduler Successfully assigned default/liveness-exec-pod to node02
Normal Pulled 46s kubelet, node02 Container image "busybox" already present on machine
Normal Created 46s kubelet, node02 Created container liveness-exec-container
Normal Started 45s kubelet, node02 Started container liveness-exec-container
Warning Unhealthy 8s (x3 over 14s) kubelet, node02 Liveness probe failed:
Normal Killing 8s kubelet, node02 Container liveness-exec-container failed liveness probe,will be restarted
kubectl get pods -w
NAME READY STATUS RESTARTS AGE
liveness-exec 1/1 Running 1 85s
折叠
能够看到 Pod 中只要一个容器。kubelet 在履行第一次勘探前需求等候 5 秒，kubelet 会每 5 秒履行一次存活勘探。kubelet 在容器内履行指令 cat /tmp/healthy 来进行勘探。假如指令履行成功而且回来值为 0，kubelet 就会以为这个容器是健康存活的。 当到达第 31 秒时，这个指令回来非 0 值，kubelet 会杀死这个容器并从头发动它
======示例2：httpGet办法======
apiVersion: v1
kind: Pod
metadata:
labels:
test: liveness
name: liveness-http
spec:
containers:
- name: liveness
image: k8s.gcr.io/liveness
args:
- /server
livenessProbe:
httpGet:
path: /healthz
port: 8080
httpHeaders:
- name: Custom-Header
value: Awesome
initialDelaySeconds: 3
periodSeconds: 3
在这个装备文件中，能够看到 Pod 也只要一个容器。initialDelaySeconds 字段告知 kubelet 在履行第一次勘探前应该等候 3 秒。periodSeconds 字段指定了 kubelet 每隔 3 秒履行一次存活勘探。kubelet 会向容器内运转的服务（服务会监听 8080 端口）发送一个 HTTP GET 恳求来履行勘探。假如服务器上 /healthz 路径下的处理程序回来成功代码，则 kubelet 以为容器是健康存活的。假如处理程序回来失利代码，则 kubelet 会杀死这个容器而且从头发动它。
任何大于或等于 200 而且小于 400 的回来代码标明成功，其它回来代码都标明失利。
vim httpget.yaml
apiVersion: v1
kind: Pod
metadata:
name: liveness-httpget
namespace: default
spec:
containers:
- name: liveness-httpget-container
image: soscscs/myapp:v1
imagePullPolicy: IfNotPresent
ports:
- name: http
containerPort: 80
livenessProbe:
httpGet:
port: http
path: /index.html
initialDelaySeconds: 1
periodSeconds: 3
timeoutSeconds: 10
kubectl create -f httpget.yaml
kubectl exec -it liveness-httpget -- rm -rf /usr/share/nginx/html/index.html
kubectl get pods
NAME READY STATUS RESTARTS AGE
liveness-httpget 1/1 Running 1 2m44s折叠
======示例3：tcpSocket办法======
apiVersion: v1
kind: Pod
metadata:
name: goproxy
labels:
app: goproxy
spec:
containers:
- name: goproxy
image: k8s.gcr.io/goproxy:0.1
ports:
- containerPort: 8080
readinessProbe:
tcpSocket:
port: 8080
initialDelaySeconds: 5
periodSeconds: 10
livenessProbe:
tcpSocket:
port: 8080
initialDelaySeconds: 15
periodSeconds: 20
这个比方一起运用 readinessProbe 和 livenessProbe 勘探。kubelet 会在容器发动 5 秒后发送第一个 readinessProbe 勘探。这会测验连接 goproxy 容器的 8080 端口。假如勘探成功，kubelet 将继续每隔 10 秒运转一次检测。除了 readinessProbe 勘探，这个装备包含了一个 livenessProbe 勘探。kubelet 会在容器发动 15 秒后进行第一次 livenessProbe 勘探。就像 readinessProbe 勘探一样，会测验连接 goproxy 容器的 8080 端口。假如 livenessProbe 勘探失利，这个容器会被从头发动。
vim tcpsocket.yaml
apiVersion: v1
kind: Pod
metadata:
name: probe-tcp
spec:
containers:
- name: nginx
image: soscscs/myapp:v1
livenessProbe:
initialDelaySeconds: 5
timeoutSeconds: 1
tcpSocket:
port: 8080
periodSeconds: 3
kubectl create -f tcpsocket.yaml
kubectl exec -it probe-tcp -- netstat -natp
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 1/nginx: master pro
kubectl get pods -w
NAME READY STATUS RESTARTS AGE
probe-tcp 1/1 Running 0 4s
probe-tcp 1/1 Running 1 14s
probe-tcp 1/1 Running 2 26s折叠
======示例4：安排妥当检测======
vim readiness-httpget.yaml
apiVersion: v1
kind: Pod
metadata:
name: readiness-httpget
namespace: default
spec:
containers:
- name: readiness-httpget-container
image: soscscs/myapp:v1
imagePullPolicy: IfNotPresent
ports:
- name: http
containerPort: 80
readinessProbe:
httpGet:
port: 80
path: /index1.html
initialDelaySeconds: 1
periodSeconds: 3
livenessProbe:
httpGet:
port: http
path: /index.html
initialDelaySeconds: 1
periodSeconds: 3
timeoutSeconds: 10
kubectl create -f readiness-httpget.yaml
//readiness勘探失利，无法进入READY状况
kubectl get pods
NAME READY STATUS RESTARTS AGE
readiness-httpget 0/1 Running 0 18s
kubectl exec -it readiness-httpget sh
# cd /usr/share/nginx/html/
# ls
50x.html index.html
# echo 123 > index1.html
# exit
kubectl get pods
NAME READY STATUS RESTARTS AGE
readiness-httpget 1/1 Running 0 2m31s
kubectl exec -it readiness-httpget -- rm -rf /usr/share/nginx/html/index.html
kubectl get pods -w
NAME READY STATUS RESTARTS AGE
readiness-httpget 1/1 Running 0 4m10s
readiness-httpget 0/1 Running 1 4m15s折叠
======示例5：安排妥当检测2======
vim readiness-myapp.yaml
apiVersion: v1
kind: Pod
metadata:
name: myapp1
labels:
app: myapp
spec:
containers:
- name: myapp
image: soscscs/myapp:v1
ports:
- name: http
containerPort: 80
readinessProbe:
httpGet:
port: 80
path: /index.html
initialDelaySeconds: 5
periodSeconds: 5
timeoutSeconds: 10
---
apiVersion: v1
kind: Pod
metadata:
name: myapp2
labels:
app: myapp
spec:
containers:
- name: myapp
image: soscscs/myapp:v1
ports:
- name: http
containerPort: 80
readinessProbe:
httpGet:
port: 80
path: /index.html
initialDelaySeconds: 5
periodSeconds: 5
timeoutSeconds: 10
---
apiVersion: v1
kind: Pod
metadata:
name: myapp3
labels:
app: myapp
spec:
containers:
- name: myapp
image: soscscs/myapp:v1
ports:
- name: http
containerPort: 80
readinessProbe:
httpGet:
port: 80
path: /index.html
initialDelaySeconds: 5
periodSeconds: 5
timeoutSeconds: 10
---
apiVersion: v1
kind: Service
metadata:
name: myapp
spec:
selector:
app: myapp
type: ClusterIP
ports:
- name: http
port: 80
targetPort: 80
kubectl create -f readiness-myapp.yaml
kubectl get pods,svc,endpoints -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
pod/myapp1 1/1 Running 0 3m42s 10.244.2.13 node02 <none> <none>
pod/myapp2 1/1 Running 0 3m42s 10.244.1.15 node01 <none> <none>
pod/myapp3 1/1 Running 0 3m42s 10.244.2.14 node02 <none> <none>
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR
......
service/myapp ClusterIP 10.96.138.13 <none> 80/TCP 3m42s app=myapp
NAME ENDPOINTS AGE
......
endpoints/myapp 10.244.1.15:80,10.244.2.13:80,10.244.2.14:80 3m42s
kubectl exec -it pod/myapp1 -- rm -rf /usr/share/nginx/html/index.html
//readiness勘探失利，Pod 无法进入READY状况，且端点控制器将从 endpoints 中剔除删去该 Pod 的 IP 地址
kubectl get pods,svc,endpoints -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
pod/myapp1 0/1 Running 0 5m17s 10.244.2.13 node02 <none> <none>
pod/myapp2 1/1 Running 0 5m17s 10.244.1.15 node01 <none> <none>
pod/myapp3 1/1 Running 0 5m17s 10.244.2.14 node02 <none> <none>
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR
......
service/myapp ClusterIP 10.96.138.13 <none> 80/TCP 5m17s app=myapp
NAME ENDPOINTS AGE
......
endpoints/myapp 10.244.1.15:80,10.244.2.14:80 5m17s折叠
======发动、退出动作======
vim post.yaml
apiVersion: v1
kind: Pod
metadata:
name: lifecycle-demo
spec:
containers:
- name: lifecycle-demo-container
image: soscscs/myapp:v1
lifecycle: #此为要害字段
postStart:
exec:
command: ["/bin/sh", "-c", "echo Hello from the postStart handler >> /var/log/nginx/message"]
preStop:
exec:
command: ["/bin/sh", "-c", "echo Hello from the poststop handler >> /var/log/nginx/message"]
volumeMounts:
- name: message-log
mountPath: /var/log/nginx/
readOnly: false
initContainers:
- name: init-myservice
image: soscscs/myapp:v1
command: ["/bin/sh", "-c", "echo 'Hello initContainers' >> /var/log/nginx/message"]
volumeMounts:
- name: message-log
mountPath: /var/log/nginx/
readOnly: false
volumes:
- name: message-log
hostPath:
path: /data/volumes/nginx/log/
type: DirectoryOrCreate
kubectl create -f post.yaml
kubectl get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
lifecycle-demo 1/1 Running 0 2m8s 10.244.2.28 node02 <none> <none>
kubectl exec -it lifecycle-demo -- cat /var/log/nginx/message
Hello initContainers
Hello from the postStart handler
//在 node02 节点上查看
[root@node02 ~]# cd /data/volumes/nginx/log/
[root@node02 log]# ls
access.log error.log message
[root@node02 log]# cat message
Hello initContainers
Hello from the postStart handler
#由上可知，init Container先履行，然后当一个主容器发动后，Kubernetes 将立即发送 postStart 事情。
//删去 pod 后，再在 node02 节点上查看
kubectl delete pod lifecycle-demo
[root@node02 log]# cat message
Hello initContainers
Hello from the postStart handler
Hello from the poststop handler
#由上可知，当在容器被完结之前， Kubernetes 将发送一个 preStop 事情。
