pod的生命周期
1.initC
1.1 Pod生命周期initC的各个方面
定义
initC,即初始化容器(Init Containers),是Kubernetes Pod中在主容器(Main Containers)启动之前运行的容器。它们主要用于设置Pod中的环境,比如下载配置文件、准备数据卷等。
作用
环境准备:initC可以为主容器提供必要的环境配置,如下载配置文件、设置环境变量等。
依赖检查:确保Pod运行所需的服务或资源已经就绪,例如检查数据库或外部服务是否可达。
数据初始化:初始化数据卷或配置数据,供主容器使用。
使用场景
配置文件下载:在启动主容器之前,下载最新的配置文件。
数据库连接检查:确保Pod能够成功连接到必要的数据库或其他服务。
数据预加载:为主容器预先加载必要的数据或执行数据初始化脚本。
1.2. Pod生命周期initC与其他相关概念的关系和区别
与主容器的关系
顺序执行:initC在主容器之前运行,且必须按顺序成功执行完毕后,主容器才会启动。
生命周期:initC的生命周期独立于主容器,一旦完成其初始化任务,便会退出。而主容器则会在Pod的生命周期内持续运行,直到被显式终止。
与探针(Probes)的区别
功能不同:探针主要用于监测容器的运行状态,如存活状态和就绪状态;而initC则用于在容器启动前进行初始化工作。
执行时机:探针在容器运行期间周期性执行;而initC仅在容器启动前执行一次。
1.3. 实际案例或示例
示例场景:假设有一个Web应用Pod,它依赖于外部数据库和Redis服务。在启动Web应用容器之前,需要确保这些服务都已就绪,并且需要从远程配置服务器下载最新的配置文件。
YAML配置文件示例:
apiVersion: v1
kind: Pod
metadata:
name: myapp-pod
spec:
containers:
- name: myapp-container
image: myapp:latest
ports:
- containerPort: 80
initContainers:
- name: init-config
image: busybox
command: ['sh', '-c', 'wget -O /config/config.yaml http://config-server/myapp-config.yaml']
volumeMounts:
- name: config-volume
mountPath: /config
- name: init-db
image: busybox
command: ['sh', '-c', 'until nslookup mydatabase; do echo waiting for mydatabase; sleep 2; done;']
- name: init-redis
image: busybox
command: ['sh', '-c', 'until nslookup myredis; do echo waiting for myredis; sleep 2; done;']
volumes:
- name: config-volume
emptyDir: {}
解释:
init-config:这个initC负责从远程配置服务器下载配置文件,并将其保存到Pod的数据卷中。
init-db 和 init-redis:这两个initC分别检查数据库和Redis服务的DNS解析是否成功,以确保这些服务已经就绪。
一旦所有initC都成功执行完毕,myapp-container 主容器才会启动。
1.4 总结
Pod生命周期中的initC是Kubernetes提供的一个强大特性,它允许开发者在主容器启动之前执行必要的初始化工作。通过合理配置initC,可以确保Pod在启动时就处于一个健康、可用的状态,从而提高应用的稳定性和可靠性。对于初学者和有一定经验的开发者来说,理解和掌握initC的使用对于高效利用Kubernetes平台至关重要。
vim 02.pod-initC.yaml
apiVersion: v1
kind: Pod
metadata:
name: initc-1
labels:
app: initc
spec:
containers:
- name: myapp-container
image: wangyanglinux/tools:busybox
command: ['sh', '-c', 'echo The app is running! && sleep 3600']
initContainers:
- name: init-myservice
image: wangyanglinux/tools:busybox
command: ['sh', '-c', 'until nslookup myservice; do echo waiting for myservice; sleep 2; done;']
- name: init-mydb
image: wangyanglinux/tools:busybox
command: ['sh', '-c', 'until nslookup mydb; do echo waiting for mydb; sleep 2; done;']
[root@master 4]# kubectl create -f 02.pod-initC.yaml
# 查看pod状态
[root@master 4]# kubectl get po
NAME READY STATUS RESTARTS AGE
initc-1 0/1 Init:0/2 0 14m
# 查看pod initc-1 里面 init-myservice 日志
[root@master 4]# kubectl logs initc-1 -c init-myservice
Server: 10.0.0.10
Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local
nslookup: can't resolve 'myservice'
waiting for myservice
Server: 10.0.0.10
Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local
[root@master 4]# kubectl logs initc-1 -c init-mydb
Error from server (BadRequest): container "init-mydb" in pod "initc-1" is waiting to start: PodInitializing
# 创建 myservice服务 端口为80:80
[root@master 4]# kubectl create svc clusterip myservice --tcp=80:80
service/myservice created
# 查看service信息
[root@master 4]# kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.0.0.1 <none> 443/TCP 17h
myservice ClusterIP 10.0.184.109 <none> 80/TCP 3m20s
# 查看pod状态
[root@master 4]# kubectl get po
NAME READY STATUS RESTARTS AGE
initc-1 0/1 Init:1/2 0 21m
# 再查看pod initc-1 里面 init-myservice 日志
[root@master 4]# kubectl logs initc-1 -c init-myservice
Name: myservice
Address 1: 10.0.184.109 myservice.default.svc.cluster.local
# 再查看pod initc-1 里面 init-mydb 日志
[root@master 4]# kubectl logs initc-1 -c init-mydb
waiting for mydb
nslookup: can't resolve 'mydb'
Server: 10.0.0.10
Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local
# 创建 mydb服务 端口为80:80
[root@master 4]# kubectl create svc clusterip mydb --tcp=80:80
service/mydb created
[root@master 4]# kubectl get po
NAME READY STATUS RESTARTS AGE
initc-1 1/1 Running 0 37m
# 再查看pod initc-1 里面 init-mydb 日志
[root@master 4]# kubectl logs initc-1 -c init-mydb
Name: mydb
Address 1: 10.6.57.222 mydb.default.svc.cluster.local
2.探针
Pod生命周期探针的详细科普介绍
定义
Pod生命周期探针(Probes)是Kubernetes中对容器执行的定期诊断机制,由kubelet(Node节点上的组件)执行。这些探针用于监测容器的运行状态,确保Pod的健康和可用性。探针通过调用容器实现的Handler(处理程序)来执行诊断,常见的Handler类型包括执行命令(ExecAction)、TCP端口检查(TCPSocketAction)和HTTP GET请求(HTTPGetAction)。
功能
选项说明:
initialDelaySeconds:容器启动后延迟多少秒开始执行第一次探测,默认为0秒。
periodSeconds:探测的时间间隔,即每隔多少秒执行一次,默认为10秒(最小值1秒)。
timeoutSeconds:探测超时时间,默认为1秒(最小值1秒)。
successThreshold:处于失败状态时,需要探测成功多少次才算成功,默认为1。
failureThreshold:处于成功状态时,需要探测失败多少次才算失败,默认为3。
Kubernetes(k8s)中的探针是一种健康检查机制,用于监测Pod内容器的运行状况。主要包括以下三种类型的探针:
2.1 存活探针(Liveness Probe)
作用:检测容器内主进程或服务是否仍然运行正常且响应健康检查。主要用于确保容器中的进程在出现问题时能够被重启,以恢复服务的可用性。
探测方式:
- HTTP GET请求(HTTPGetAction):通过向容器内的指定端口和路径发送HTTP GET请求,并检查响应的状态码来确定容器是否健康。如果响应状态码在200-399之间,则认为探测成功。
- TCP Socket检查(TCPSocketAction):尝试与容器内的指定端口建立TCP连接。如果连接成功,则认为容器健康。
- 执行命令(ExecAction):在容器内执行指定的命令,并检查命令的退出状态码。如果退出状态码为0,则认为探测成功。
影响:当存活探针检测失败时,kubelet将认为该容器内的主进程已经不再健康或者已停止提供预期的服务,此时会根据Pod的重启策略来决定是否应该重新启动这个容器。
# 基于 Exec 方式
apiVersion: v1
kind: Pod
metadata:
name: liveness-exec-pod
namespace: default
spec:
containers:
- name: liveness-exec-container
image: wangyanglinux/tools:busybox
imagePullPolicy: IfNotPresent
command: ["/bin/sh","-c","touch /tmp/live ; sleep 60; rm -rf /tmp/live;
sleep
3600"]
livenessProbe:
exec:
command: ["test","-e","/tmp/live"]
initialDelaySeconds: 1
periodSeconds: 3
# 基于 HTTP Get 方式
apiVersion: v1
kind: Pod
metadata:
name: liveness-httpget-pod
namespace: default
spec:
containers:
- name: liveness-httpget-container
image: wangyanglinux/myapp:v1.0
imagePullPolicy: IfNotPresent
ports:
- name: http
containerPort: 80
livenessProbe:
httpGet:
port: 80
path: /index.html
initialDelaySeconds: 1
periodSeconds: 3
timeoutSeconds: 3
# 基于 TCP Check 方式
apiVersion: v1
kind: Pod
metadata:
name: liveness-tcp-pod
spec:
containers:
- name: liveness-tcp-container
image: wangyanglinux/myapp:v1.0
livenessProbe:
initialDelaySeconds: 5
timeoutSeconds: 1
tcpSocket:
port: 80
2.2 就绪探针(Readiness Probe)
作用:检测容器是否已经准备好对外提供服务。主要用于控制容器是否应该接收服务请求。
探测方式:与存活探针相同,也支持HTTP GET请求、TCP Socket检查和执行命令三种方式。
影响:如果就绪探针检查失败,则表示容器可能还在启动过程中、正在重启服务、或者由于某种原因暂时无法正常响应请求。在这种情况下,kubelet会将容器从Service的后端池中移除,确保不会向其发送任何用户请求,从而避免了因应用未准备完毕而引起的错误响应和用户体验下降。
创建pod 创建svc
vim 01_pod-demo.yaml
apiVersion: v1
kind: Pod
metadata:
name: pod-1
namespace: default
labels:
app: myapp
spec:
containers:
- name: myapp-1
image: wangyanglinux/myapp:v1.0
[root@master 6]# kubectl create -f 01_pod-demo.yaml
pod/pod-1 created
[root@master wp]# kubectl get pod
NAME READY STATUS RESTARTS AGE
pod-1 1/1 Running 0 82s
[root@master 6]# kubectl get pod --show-labels
NAME READY STATUS RESTARTS AGE LABELS
pod-1 1/1 Running 0 2m10s app=myapp
vi 02.pod-demo.yaml
apiVersion: v1
kind: Pod
metadata:
name: pod-2
namespace: default
labels:
app: myapp
version: v1
spec:
containers:
- name: myapp-1
image: wangyanglinux/myapp:v1.0
[root@master 6]# kubectl get pod --show-labels
NAME READY STATUS RESTARTS AGE LABELS
pod-1 1/1 Running 0 4m28s app=myapp
pod-2 1/1 Running 0 36s app=myapp,version=v1
# app是匹配到labels名字为app的pod --tcp代表tcp负载均衡 80:80代表集群访问端口:真实服务器端口
[root@master 6]# kubectl create svc clusterip myapp --tcp=80:80
service/myapp created
# CLUSTER-IP:10.10.120.159 负载均衡的vip
[root@master 6]# kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.0.0.1 <none> 443/TCP 35h
myapp ClusterIP 10.10.120.159 <none> 80/TCP 2m33s
[root@master 6]# kubectl get po --show-labels
NAME READY STATUS RESTARTS AGE LABELS
pod-1 1/1 Running 0 16m app=myapp
pod-2 1/1 Running 0 12m app=myapp,version=v1
pod-3 1/1 Running 0 2m18s app=myapp,version=v1
pod-4 1/1 Running 0 2m2s app=test,version=v1
labels:
app: myapp
version: v1
若使用app=其他名称与svc不匹配 则不会实现负载均衡
# 基于 HTTP Get 方式
apiVersion: v1
kind: Pod #Pod类型
metadata:
name: readiness-httpget-pod #pod名称
namespace: default #命名空间
labels:
app: myapp #标签
env: test
spec:
containers:
- name: readiness-httpget-container #容器名称
image: wangyanglinux/myapp:v1.0 #镜像
imagePullPolicy: IfNotPresent #镜像若存在则不下载
readinessProbe: #就绪探测
httpGet: #探测方式httpget
port: 80 #探测端口80
path: /index1.html #探测文件为index1.html
initialDelaySeconds: 1 # 表示在容器启动后等待 1 秒后开始执行首次探测
periodSeconds: 3 #表示每隔 3 秒进行一次探测
# 基于 EXEC 方式(linux命令)
apiVersion: v1
kind: Pod #Pod类型
metadata:
name: readiness-exec-pod #pod名称
namespace: default #命名空间
spec:
containers:
- name: readiness-exec-container #容器名称
image: wangyanglinux/tools:busybox #镜像
imagePullPolicy: IfNotPresent #镜像若存在则不下载
command: ["/bin/sh","-c","touch /tmp/live ; sleep 60; rm -rf /tmp/live; sleep3600"] #创建文件live 60秒后 删除live
readinessProbe: #就绪探针
exec:
command: ["test","-e","/tmp/live"] # 检测live文件是否存在
initialDelaySeconds: 1 # 表示在容器启动后等待 1 秒后开始执行首次探测
periodSeconds: 3 #表示每隔 3 秒进行一次探测
# 基于 TCP Check 方式
apiVersion: v1
kind: Pod
metadata:
name: readiness-tcp-pod
spec:
containers:
- name: readiness-exec-container
image: wangyanglinux/myapp:v1.0
readinessProbe:
initialDelaySeconds: 5
timeoutSeconds: 1
tcpSocket: #tcp检测
port: 80 #tcp检测端口为80
2.3 启动探针(Startup Probe)(自1.16版本引入)
作用:检测容器内的应用是否已经成功启动并完成初始化任务。主要用于在容器启动初期,延缓其他探针(存活探针和就绪探针)的生效,避免因为容器启动时间较长或初始化过程中的不稳定状态导致的不必要重启或流量涌入。
探测方式:
启动探测的探测方式与存活探测和就绪探测相同,也支持HTTP GET请求、TCP Socket检查和执行命令三种方式。
影响:
在容器启动期间,如果配置了启动探测,则Kubernetes将仅执行启动探测,而不执行存活探测和就绪探测。只有当启动探测成功时,才会开始执行存活探测和就绪探测。
探测周期与参数
通过这些探针的配置和使用,Kubernetes能够实现对容器健康状态的精细监控和管理,确保服务的稳定性和可用性。
应用场景
确保应用健康:通过存活探针和就绪探针,可以实时监测应用的运行状态,确保应用在出现问题时能够被及时发现和处理。
提高服务可用性:就绪探针确保只有健康的Pod才会被加入到服务的负载均衡中,从而提高服务的整体可用性。
支持慢启动应用:启动探针为慢启动应用提供了额外的保护,防止它们在启动过程中被错误地认为是失败或被重启。
优缺点
优点:
实时性:探针能够实时地监测容器的运行状态,确保Pod的健康和可用性。
灵活性:提供了多种类型的探针(存活探针、就绪探针、启动探针)和探测机制(执行命令ExexAction、TCP端口检查TCPSocketAction、HTTP GET请求HTTPGetAction),可以根据不同的应用场景进行灵活配置。
自动化:探针的执行和响应都是自动化的,无需人工干预,提高了运维效率。
缺点:
配置复杂性:正确配置探针需要一定的知识和经验,错误的配置可能导致不必要的容器重启或服务中断。
性能开销:虽然探针的开销相对较小,但在高并发场景下,频繁的探针调用仍可能对系统性能产生一定影响。
apiVersion: v1
kind: Pod
metadata:
name: startupprobe-1
namespace: default
spec:
containers:
- name: myapp-container
image: wangyanglinux/myapp:v1.0
imagePullPolicy: IfNotPresent
ports:
- name: http
containerPort: 80
readinessProbe:
httpGet:
port: 80
path: /index2.html
initialDelaySeconds: 1
periodSeconds: 3
startupProbe:
httpGet:
path: /index1.html
port: 80
failureThreshold: 30
periodSeconds: 10
综上所述,Pod生命周期探针是Kubernetes中保障Pod健康和可用性的重要机制。通过合理配置和使用探针,可以有效地提高应用的稳定性和服务的可用性。
3钩子
在Kubernetes(K8s)中,钩子(Hooks)是一种在容器生命周期的不同阶段执行特定操作的机制。这些钩子允许用户在容器启动后(PostStart)和容器终止前(PreStop)执行自定义的脚本或命令,以完成初始化任务、清理操作或发送信号等。以下是关于K8s钩子的详细解释:
3.1 K8s钩子的类型
K8s中的钩子主要分为两种类型:
PostStart:在容器创建后立即执行。这个钩子可以用来执行一些初始化任务,如设置环境变量、加载配置文件、启动服务等。如果PostStart钩子执行失败,容器可能会被重启,具体取决于容器的重启策略。
PreStop:在容器终止之前执行。这个钩子可以用来执行一些清理操作,如保存数据、关闭数据库连接、注销服务等。PreStop钩子是同步阻塞的,即它会等待钩子中的命令执行完成后再继续删除容器的操作。如果PreStop钩子执行时间过长,超过了Pod的终止宽限期(terminationGracePeriodSeconds),容器将被强制删除。
3.2K8s钩子的实现方式
K8s钩子可以通过在Pod的YAML配置文件中使用lifecycle字段来定义。lifecycle字段下可以包含postStart和preStop两个子字段,分别用于定义PostStart和PreStop钩子。
钩子的实现方式主要有以下几种:
Exec命令:在容器内执行一次命令。这是最常用的实现方式,因为它简单且灵活。
HTTP请求:向容器内的某个URL发起HTTP请求。这种方式较少使用,因为需要容器内部有能够处理HTTP请求的服务。
TCPSocket:尝试访问容器内的指定socket。这种方式通常用于检查某个服务是否已经启动并监听在指定的端口上。
3.3K8s钩子的示例
以下是一个使用Exec命令实现PostStart和PreStop钩子的Pod YAML配置文件示例:
# exec模式
apiVersion: v1
kind: Pod
metadata:
name: lifecycle-exec-pod
spec:
containers:
- name: lifecycle-exec-container
image: wangyanglinux/myapp:v1
lifecycle:
postStart:
exec:
command: ["/bin/sh", "-c", "echo postStart > /usr/share/message"]
preStop:
exec:
command: ["/bin/sh", "-c", "echo preStop > /usr/share/message"]
# 容器内写一个死循环查看
while true;
do
cat /usr/share/message
done;
#再开一个终端
kubectl delete pod --all
# HTTP GET 模式
docker run -it --rm -p 1234:80 wangyanglinux/myapp:v1.0
apiVersion: v1
kind: Pod
metadata:
name: lifecycle-httpget-pod
labels:
name: lifecycle-httpget-pod
spec:
containers:
- name: lifecycle-httpget-container
image: wangyanglinux/myapp:v1.0
ports:
- containerPort: 80
lifecycle:
postStart:
httpGet:
host: 10.0.17.100
path: index.html
port: 1234
preStop:
在这个示例中,当容器启动时,会执行echo "Container started!"命令;当容器即将终止时,会执行echo "Container stopping…"命令。
四、注意事项
容器级别的钩子:K8s中的钩子是容器级别的,每个容器都可以拥有自己的钩子。
触发时机:PostStart钩子在容器创建后立即执行,与容器的ENTRYPOINT是异步的;PreStop钩子在容器终止前执行,并且是同步阻塞的。
失败处理:如果PostStart或PreStop钩子执行失败,容器的行为将取决于容器的重启策略和终止宽限期。
使用场景:钩子在容器生命周期管理中非常有用,特别是在需要执行初始化任务或清理操作的场景中。
综上所述,K8s钩子是一种强大的机制,它允许用户在容器生命周期的不同阶段执行自定义的操作。通过合理使用钩子,可以简化容器的管理和维护工作。
vim pod_all.yaml
apiVersion: v1
kind: Pod
metadata:
name: lifecycle-pod
labels:
app: lifecycle-pod
spec:
containers:
- name: busybox-container
image: wangyanglinux/tools:busybox
command: ["/bin/sh","-c","touch /tmp/live ; sleep 600; rm -rf /tmp/live; sleep 3600"]
livenessProbe:
exec:
command: ["test","-e","/tmp/live"]
initialDelaySeconds: 1
periodSeconds: 3
lifecycle:
postStart:
httpGet:
host: 10.0.17.100
path: index.html
port: 1234
preStop: # 关闭前钩子
httpGet: # 使用HTTP GET方式 访问 10.0.17.100:80/hostname.html
host: 10.0.17.100
path: hostname.html
port: 1234
- name: myapp-container
image: wangyanglinux/myapp:v1.0
livenessProbe: #存活检测
httpGet: #检测 端口80的index.html
port: 80
path: /index.html
initialDelaySeconds: 1 # 延迟1秒
periodSeconds: 3 # 间隔3秒
timeoutSeconds: 3 #超时时间3秒
readinessProbe: # 就绪探测
httpGet: #检测 端口80的index1.html
port: 80
path: /index1.html
initialDelaySeconds: 1 # 延迟1秒
periodSeconds: 3 # 间隔3秒
initContainers:
- name: init-myservice
image: wangyanglinux/tools:busybox
command: ['sh', '-c', 'until nslookup myservice; do echo waiting for myservice; sleep 2; done;'] #检测service myservice
- name: init-mydb
image: wangyanglinux/tools:busybox
command: ['sh', '-c', 'until nslookup mydb; do echo waiting for mydb; sleep 2; done;'] #检测service mydb
拍错思路
[root@master 6]# kubectl get pod
NAME READY STATUS RESTARTS AGE
lifecycle-pod 0/2 Init:0/2 0 5m44s
# 没初始化 查看详情
[root@master 6]# kubectl describe pod lifecycle-pod
Normal Created 5m51s kubelet Created container init-myservice
Normal Started 5m51s kubelet Started container init-myservice
# 查看myservice
[root@master 6]# kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.0.0.1 <none> 443/TCP 40h
# 没有 myservice 创建myservice
[root@master 6]# kubectl create svc clusterip myservice --tcp=80:80
service/myservice created
# 查看pod
[root@master 6]# kubectl get pod
NAME READY STATUS RESTARTS AGE
lifecycle-pod 0/2 Init:1/2 0 8m55s
# 没初始化 查看详情
[root@master 6]# kubectl describe pod lifecycle-pod
Normal Created 49s kubelet Created container init-mydb
Normal Started 49s kubelet Started container init-mydb
[root@master 6]# kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.0.0.1 <none> 443/TCP 40h
myservice ClusterIP 10.0.42.186 <none> 80/TCP 105s
# 没有 mydb 创建mydb
[root@master 6]# kubectl create svc clusterip mydb --tcp=80:80
service/mydb created
# 查看service
[root@master 6]# kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.0.0.1 <none> 443/TCP 40h
mydb ClusterIP 10.14.189.127 <none> 80/TCP 37s
myservice ClusterIP 10.0.42.186 <none> 80/TCP 3m39s
# 查看pod 状态为PodInitializing 进入初始化
[root@master 6]# kubectl get pod
NAME READY STATUS RESTARTS AGE
lifecycle-pod 0/2 PodInitializing 0 12m
# 查看pod 状态为CrashLoopBackOff
[root@master 6]# kubectl get pod
NAME READY STATUS RESTARTS AGE
lifecycle-pod 0/2 CrashLoopBackOff 1 (24s ago) 13m
# 查看pod详细信息
[root@master 6]# kubectl describe pod lifecycle-pod
Warning Unhealthy 6s (x64 over 2m36s) kubelet Readiness probe failed: HTTP probe failed with statuscode: 404
# 就绪探针探测失败
# myapp-container
#readinessProbe:
# httpGet:
# port: 80
# path: /index1.html
# initialDelaySeconds: 1
# periodSeconds: 3
# 没有这个index1.html 所以http get 404
# 进入容器添加 index1.html
[root@master 6]# kubectl exec -it lifecycle-pod -c myapp-container -- bash
lifecycle-pod:/# ls /usr/local/nginx/html/
50x.html hostname.html index.html
# 添加 index1.html
lifecycle-pod:/# echo "index1 created" >> /usr/local/nginx/html/index1.html
#查看pod 妈的还有问题
[root@master 6]# kubectl get pod
NAME READY STATUS RESTARTS AGE
lifecycle-pod 1/2 CrashLoopBackOff 6 (2m17s ago) 23m
# 查看pod详细信息
[root@master 6]# kubectl describe pod lifecycle-pod
Warning BackOff 2m55s (x57 over 15m) kubelet Back-off restarting failed container busybox-container in pod lifecycle-pod_default(aa0887f3-e2c2-4c4f-b54b-e21139a5c451)
#lifecycle:
# postStart:
# httpGet:
# host: 10.0.17.100
# path: index.html
# port: 1234
# preStop:
# httpGet:
# host: 10.0.17.100
# path: hostname.html
# port: 1234
#运行一个
[root@master 6]# docker run --name test -p 1234:80 -d wangyanglinux/myapp:v1.0
[root@master 6]# kubectl get pod
NAME READY STATUS RESTARTS AGE
lifecycle-pod 2/2 Running 9 (5m36s ago) 38m
#正常了