当前位置：首页 > wzjs >正文

网站开发项目总结报告wordpress 无效的文章类型

wzjs 2025/9/5 10:54:31

网站开发项目总结报告,wordpress 无效的文章类型,广州公司注册网址,asp.net网站设计分工初始化容器初始化容器是在pod的主容器启动之前要运行的容器，主要是做一些主容器的前置工作，它具有两大特征： 1. 初始化容器必须运行完成直至结束，若某初始化容器运行失败，那么kubernetes需要重启它直到成功完成 2. 初…

初始化容器

初始化容器是在pod的主容器启动之前要运行的容器，主要是做一些主容器的前置工作，它具有两大特征：
1. 初始化容器必须运行完成直至结束，若某初始化容器运行失败，那么kubernetes需要重启它直到成功完成
2. 初始化容器必须按照定义的顺序执行，当且仅当前一个成功之后，后面的一个才能运行
初始化容器有很多的应用场景，下面列出的是最常见的几个：

提供主容器镜像中不具备的工具程序或自定义代码
初始化容器要先于应用容器串行启动并运行完成，因此可用于延后应用容器的启动直至其依赖的条
件得到满足

案例

假设要以主容器来运行nginx，但是要求在运行nginx之前先要能够连接上mysql和redis所在服务器
为了简化测试，事先规定好mysql (192.168.109.201) 和redis (192.168.109.202) 服务器的地址
创建pod-initcontainer.yaml，内容如下：

[root@k8s-master01 dev]# vim pod-init.yml

#master

#接下来新开一个shell，为当前服务器新增两个ip，观察pod的变化
[root@k8s-master01 dev]# ifconfig ens160:1 192.168.109.201 netmask 255.255.255.0 up
[root@k8s-master01 dev]# ifconfig ens160:2 192.168.109.202 netmask 255.255.255.0 up

#node01
[root@master ~]# ifconfig ens33:1 192.168.109.201 netmask 255.255.255.0 up
[root@master ~]# ifconfig ens33:2 192.168.109.202 netmask 255.255.255.0 up

#node02
[root@master ~]# ifconfig ens33:1 192.168.109.201 netmask 255.255.255.0 up
[root@master ~]# ifconfig ens33:2 192.168.109.202 netmask 255.255.255.0 up

#查看pod的环境

[root@k8s-master01 dev]# kubectl get pod -n dev
NAME READY STATUS RESTARTS AGE
pod-initcontainer 1/1 Running 0 11m

#查看pod状态

[root@k8s-master01 dev]# kubectl describe pod pod-init -n dev

钩子函数

钩子函数能够感知自身生命周期中的事件，并在相应的时刻到来时运行用户指定的程序代码。
kubernetes在主容器的启动之后和停止之前提供了两个钩子函数：
post start：容器创建之后执行，如果失败了会重启容器。
pre stop ：容器终止之前执行，执行完成之后容器将成功终止，在其完成之前会阻塞删除容器的操作。

钩子处理器支持使用下面三种方式定义动作：

1.Exec命令：在容器内执行一次命令

2.TCPSocket：在当前容器尝试访问指定的socket

3.HTTPGet：在当前容器中向某url发起http请求

下面以exec方式为例，演示下钩子函数的使用，创建pod-hook-exec.yaml文件，内容如下：

#创建pod

[root@k8s-master01 ~]# kubectl create -f pod-hook-exec.yaml

#查看pod

[root@k8s-master01 ~]# kubectl get pods pod-hook-exec -n dev -o wide

#访问ip地址

[root@k8s-master01 ~]# curl 10.244.58.212

容器探测

容器探测用于检测容器中的应用实例是否正常工作，是保障业务可用性的一种传统机制。如果经过探测，实例的状态不符合预期，那么kubernetes就会把该问题实例" 摘除 "，不承担业务流量。

两种探针

kubernetes提供了两种探针来实现容器探测，分别是：

1.liveness probes：存活性探针，用于检测应用实例当前是否处于正常运行状态，如果不是，k8s会重启容器。（livenessProbe 决定是否重启容器，readinessProbe 决定是否将请求转发给容器。）

2.readiness probes：就绪性探针，用于检测应用实例当前是否可以接收请求，如果不能，k8s不会转发流量。

三种探测方式

上面两种探针目前均支持三种探测方式：

1.Exec命令：在容器内执行一次命令，如果命令执行的退出码为0，则认为程序正常，否则不正常。

2.TCPSocket：将会尝试访问一个用户容器的端口，如果能够建立这条连接，则认为程序正常，否则不正常。

3.HTTPGet：调用容器内Web应用的URL，如果返回的状态码在200和399之间，则认为程序正常，否则不正常。

Exec实例

创建pod-liveness-exec.yaml

[root@k8s-master01 dev]# vim pod-liveness-exec.yaml

# 创建Pod

[root@master ~]# kubectl create -f pod-liveness-exec.yaml

# 查看Pod详情

[root@k8s-master01 dev]# kubectl get pod -n dev

# 查看Pod详情，显示探测失败（没有hello.txt文件和目录tmp）

[root@k8s-master01 dev]# kubectl describe pods pod-liveness-exec -n dev

#进入容器里面

[root@k8s-master01 dev]# kubectl exec -it pod-liveness-exec -n dev -- /bin/bash

#创建文件和目录。
root@pod-liveness-exec:/# echo test123 > /tmp/hello.txt

TCPSocket实例

创建pod-liveness-tcpsocket.yaml

[root@k8s-master01 dev]# vim pod-liveness-tcpsocket.yaml

# 创建Pod
[root@master ~]# kubectl create -f pod-liveness-tcpsocket.yaml
# 查看Pod详情
[root@master ~]# kubectl describe pods pod-liveness-tcpsocket -n dev

观察上面的信息，发现尝试访问8080端口,但是失败了，稍等一会之后，再观察pod信息，就可以看到RESTARTS不再是0，而是一直增长。

[root@master ~]# kubectl get pods pod-liveness-tcpsocket -n dev

当然接下来，可以修改成一个可以访问的端口，比如80，再试，结果就正常了......

[root@k8s-master01 dev]# kubectl delete -f pod-liveness-tcpsocket.yaml
pod "pod-liveness-tcpsocket" deleted

[root@k8s-master01 dev]# kubectl create -f pod-liveness-tcpsocket.yaml
pod/pod-liveness-tcpsocket created

[root@k8s-master01 dev]# kubectl get pod -n dev
NAME READY STATUS RESTARTS AGE
pod-hook-exec 1/1 Running 1 (3h48m ago) 23h
pod-liveness-tcpsocket 1/1 Running 0 12s

[root@k8s-master01 dev]# kubectl describe pods pod-liveness-tcpsocket -n dev

HTTPGet实例

创建pod-liveness-httpget.yaml

[root@k8s-master01 dev]# vim pod-liveness-httpget.yaml

# 创建Pod
[root@master ~]# kubectl create -f pod-liveness-httpget.yaml
pod/pod-liveness-httpget created

# 查看Pod详情
[root@master ~]# kubectl describe pod pod-liveness-httpget -n dev

#观察上面信息，尝试访问路径，但是未找到,出现404错误。

# 当然接下来，可以修改成一个可以访问的路径path，比如/

[root@k8s-master01 dev]# vim pod-liveness-httpget.yaml

#删除原先的pod

[root@k8s-master01 dev]# kubectl delete -f pod-liveness-httpget.yaml

#重新创建新的pod

[root@k8s-master01 dev]# kubectl create -f pod-liveness-httpget.yaml

#再试查看，结果就正常了
[root@k8s-master01 dev]# kubectl describe pod pod-liveness-httpget -n dev

重启策略

在上一节中，一旦容器探测出现了问题，kubernetes就会对容器所在的Pod进行重启，其实这是由
pod的重启策略决定的，pod的重启策略有 3 种，分别如下：
        Always ：容器失效时，自动重启该容器，这也是默认值。
        OnFailure ：容器终止运行且退出码不为0时重启
        Never ：不论状态为何，都不重启该容器
重启策略适用于pod对象中的所有容器，首次需要重启的容器，将在其需要时立即进行重启，随后再次需要重启的操作将由kubelet延迟一段时间后进行，且反复的重启操作的延迟时长以此为10s、20s、40s、80s、160s和300s，300s是最大延迟时长。

创建pod-restartpolicy.yaml：

[root@k8s-master01 dev]# vim pod-restartpolicy.yaml

# 创建Pod
[root@master ~]# kubectl create -f pod-restartpolicy.yaml

# 查看Pod详情，发现nginx容器失败
[root@master ~]# kubectl describe pods pod-restartpolicy -n dev