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

塔式服务器主机建网站什么是网站开发技术

wzjs 2025/9/9 4:25:01

塔式服务器主机建网站,什么是网站开发技术,大数据平台建站,网站绝对路径一、基础概念 1.什么是pod？ 最小部署单元： Pod 是 Kubernetes 中能够被创建、调度和管理的最小可部署计算单元。容器组： 一个 Pod 包含一个或多个紧密耦合的容器（例如：主应用容器日志收集 Sidecar 容器&#xff0…

一、基础概念

1.什么是pod？

最小部署单元： Pod 是 Kubernetes 中能够被创建、调度和管理的最小可部署计算单元。
容器组： 一个 Pod 包含一个或多个紧密耦合的容器（例如：主应用容器 + 日志收集 Sidecar 容器）
逻辑主机： 可将其视为一个“逻辑虚拟机”或“逻辑主机”，承载一组需要协同工作的容器化进程。
共享上下文（Pod 内的容器共享）：

网络命名空间：相同的 IP 地址、端口空间。容器间可通过 localhost 直接通信。

存储卷：可以挂载相同的 Volumes（持久卷、配置映射、密钥等），实现数据共享。

Linux 命名空间：如 UTS（主机名）、IPC（进程间通信）。

资源配额： CPU、内存等资源限制在 Pod 级别定义。

2.Pod 核心特征

# 典型Pod结构示例
apiVersion: v1    #核心api版本
kind: Pod         #资源类型为Pod
metadata:         #元数据部分name: my-pod    #pod名称
spec:             #Pod的期望状态和配置containers:     #Pod包含的容器列表- name: main-container   #容器名称image: nginx:alpine    #镜像和版本ports:                 #容器暴露的端口- containerPort: 80    #容器内部监听80端口（nginx默认端口）- name: sidecar-container   #边车容器 名称image: busybox            #busybox镜像#覆盖容器默认的启动命令，执行一个无限循环：每10秒打印当前日期command: ["/bin/sh", "-c", "while true; do date; sleep 10; done"]

二、Pod 生命周期管理

1.概念

Pod的运行过程中每个时间段会有不同的程序在运行，我们把它叫做Pod的生命周期。

2.生命周期

01 在启动任何容器之前，创建 pause 容器，它初始化Pod的网络环境并为后续加入的容器提供共享名称空间。
02 初始化容器(initContainers)：一个Pod可以定义任意个初始化容器，如上图就定义了两个初始化容器，初始化会按照YAML清单中顺序执行，当最后一个初始化容器执行成功后，才会去启动主容器。
03 启动钩子(postStart)：容器启动后执行的一些操作。
04 容器探测：
启动探测(Startupprobe)：探测容器是否正常运行。
存活探测(Livenessprobe)：探测容器是否处于Running 状态，如果不是根据重启策略进行响应操作。
就绪探测(Readinessprobe)：探测容器是否就绪对外提供服务。
05 停止钩子(preStop)：容器关闭前执行的一些操作

3.启动流程

- 创建Pod
   - 完成Pod调度流程
   - initContainer
   - 容器启动并执行postStart
   - livessProbe
   - 进入Running状态
   - readinessProbe
   - service关联Pod
   - 接收客户端请求

4.Pod 运行五种状态

Pending：已创建并被系统接受，但容器尚未全部启动（调度中、下载镜像中）。
Running： Pod 已绑定到节点，所有容器已创建。至少有一个容器在运行或正在启动/重启。
Succeeded： Pod 中所有容器正常终止（退出码为 0），且不会再重启。适用于一次性任务。
Failed： Pod 中至少有一个容器非正常终止（非零退出码或被系统终止）。通常是因为应用程序出现错误，资源不足导致容器被OOM - Killer（内存耗尽杀手）终止。
Unknown：无法获取 Pod 状态（通常因节点通信故障）。原因可能是节点问题、网络故障或者kubelet出现故障导致无法正常汇报pod状态。

补充：Terminating： Pod 正在被删除（用户删除请求后进入此状态）。

#强制删除pod
[root@master-1 ~]# kubectl delete pod nginx-demo-lb-bc45b7649-rvgxd --force --grace-period=0

三、pod重启策略

1.重启策略类型

Always：容器退出时，始终重启容器(即创建新容器)，跟退出码无关，默认策略。
OnFailure：容器非正常退出（非零退出码）时重启。正常退出（docker stop），异常退出（kill -9）。
Never：容器退出后永不重启。

2.重启策略说明

无论容器的重启策略是什么，当我们手动使用docker移除容器时，K8S均会自动拉起并不会记录重启次数；
当容器非正常退出(即异常退出，可以使用kill -9模拟)时，Always和OnFailure这两种策略会重新拉起POD并会记录重启次数；
当任务正常退出时，只有Always可以重启任务并记录重启次数；

3.案例

[root@master-1 yaml]# cat pods-restartPolicy.yaml 
apiVersion: v1
kind: Pod
metadata:name: image-pull-policy
spec:nodeName: node-1#restartPolicy: Never#restartPolicy: OnFailurerestartPolicy: Alwayscontainers:- name: alpineimage: nginx:latestimagePullPolicy: IfNotPresent[root@master-1 yaml]# kubectl apply -f pods-restartPolicy.yaml

当重启策略是 always时，发现docker stop容器之后，会自动重启，如下如所示：

四、pod镜像下载策略

1.镜像下载类型

Always：每次启动容器都拉取镜像（即使本地有）。
IfNotPresent：仅当本地不存在指定镜像时才拉取（默认策略）。
Never：仅使用本地镜像（需确保镜像已存在）。本地没有镜像也不会拉取镜像。

2.案例

[root@master-1 pod]# cat pods-imagePullPolicy.yaml 
apiVersion: v1
kind: Pod
metadata:name: image-pull-policy
spec:nodeName: node-1containers:- name: alpineimage: alpine:latest#imagePullPolicy: AlwaysimagePullPolicy: Never   #本地没有，也不会拉取，状态显示ErrImageNeverPull#imagePullPolicy: IfNotPresent
[root@master-1 pod]# kubectl apply -f pods-imagePullPolicy.yaml 
pod/image-pull-policy created
[root@master-1 pod]# kubectl get pods
NAME                READY   STATUS              RESTARTS   AGE
image-pull-policy   0/1     ErrImageNeverPull   0          6s

如下图所示：

五、pod探针(Probe)

检查容器里面的服务是否正常运行。

1.常用探针

Liveness Probe (存活探针)：检测容器是否运行。失败则 kubelet 会杀死并重启容器（遵循 restartPolicy）。
Readiness Probe (就绪探针)：检测容器是否准备好接收流量。失败则将该 Pod 从 Service 的 Endpoints 中移除，停止向其发送流量。成功则会将Pod重新添加到svc的ep列表中。
Startup Probe (启动探针)：(v1.16+版本才支持) 保护启动缓慢的容器。在启动期间禁用其他探针，直到此探针成功。成功后，其他探针接管。如果启动探测失败，kubelet将杀死容器，而容器依其重启策略进行重启。

2.探测方式

可参考文档Pod 的生命周期 | Kubernetes

2.1 exec

执行一段命令，根据返回值判断执行结果。返回值为0或非0，有点类似于"echo $?"。

2.2 httpGet

发起HTTP请求，根据返回的状态码来判断服务是否正常。
           200: 返回状态码成功
           301: 永久跳转
           302: 临时跳转
           401: 验证失败
           403: 权限被拒绝
           404: 文件找不到
           413: 文件上传过大
           500: 服务器内部错误
           502: 无效的请求
           504: 后端应用网关响应超时
           ...

2.3 tcpSocket

测试某个TCP端口是否能够连接，类似于telnet，nc等测试工具。

3.案例

3.1 Liveness Probe 存活探针

[root@master-1 pod]# cat pods-livenessProbe-exec.yaml 
apiVersion: v1
kind: Pod
metadata:name: livenessprobe-exec-001
spec:containers:- name: webimage: nginx:1.25.1-alpinecommand: - /bin/sh- -c- touch /tmp/liux-healthy; sleep 10; rm -f /tmp/liux-healthy; sleep 600# 健康状态检查，周期性检查服务是否存活，检查结果失败，将重启容器。livenessProbe:# 使用exec的方式去做健康检查exec:# 自定义检查的命令command:- cat- /tmp/liux-healthy# 检测服务失败次数的累加值，默认值是3次，最小值是1。当检测服务成功后，该值会被重置!failureThreshold: 3# 指定多久之后进行健康状态检查，即此时间段内检测服务失败并不会对failureThreshold进行计数。initialDelaySeconds: 15# 指定探针检测的频率，默认是10s，最小值为1.periodSeconds: 1# 检测服务成功次数的累加值，默认值为1次，最小值1.successThreshold: 1# 一次检测周期超时的秒数，默认值是1秒，最小值为1.timeoutSeconds: 1

使用exec检测，如下图(x3 over 5s)表示第3次检查失败，其中距离第一次检查失败已经经过了"5s"秒，而开始调度成功的时间是"21s"之前，两者时间差详见，得出第一次检测失败的时间是"18s".

3.2 Readiness Probe 就绪探针

确定容器是否已经启动正常(ready)，如果探测成功，这个 Pod 会被标记为就绪状态，kubelet 将继续每隔 10 秒运行一次检测。

[root@master-1 pod]# cat pods-readinessprobe-httpget.yaml 
kind: Pod
apiVersion: v1
metadata:name: readinessprobe-httpget-001labels:apps: myweb
spec:containers:- name: liux-execimage: nginx:latest# 可用性检查，周期性检查服务是否可用,从而判断容器是否就绪.readinessProbe:# 使用httpGet的方式去做健康检查httpGet:# 指定访问的端口号port: 80# 检测指定的访问路径path: /index.html# 检测服务失败次数的累加值，默认值是3次，最小值是1。当检测服务成功后，该值会被重置!failureThreshold: 3# 指定多久之后进行可用性检查，在此之前，Pod始终处于未就绪状态。initialDelaySeconds: 5# 指定探针检测的频率，默认是10s，最小值为1.periodSeconds: 3# 检测服务成功次数的累加值，默认值为1次，最小值1.successThreshold: 1# 一次检测周期超时的秒数，默认值是1秒，最小值为1.timeoutSeconds: 1

3.3 Startup Probe 启动探针

若定义了启动探针，会优先通过该探针检测，若检测成功，再去执行readinessProbe和livenessProbe探针。

[root@master-1 pod]# cat startupProbe-livenessProbe-readinessProbe-httpGet.yaml 
kind: Pod
apiVersion: v1
metadata:name: probe-startup-liveness-readiness-httpgetlabels:school: liux
spec:containers:- name: webimage: nginx:latest# 指定健康检查探针，若未指定默认成功，若定义该探针，检测失败则会重启容器，即重新创建容器。livenessProbe:httpGet:port: 80path: /linux86.htmlfailureThreshold: 3initialDelaySeconds: 10periodSeconds: 10successThreshold: 1timeoutSeconds: 1# 指定可用性就绪探针，若未指定则默认成功，若定义该探针，检测失败则会将Pod标记为未就绪状态，而未就绪的Pod是不会记录到svc的ep列表中。readinessProbe:httpGet:port: 80path: /liux.htmlfailureThreshold: 3initialDelaySeconds: 20periodSeconds: 1successThreshold: 1timeoutSeconds: 1# 指定启动探针，若定义了该探针，会优先通过该探针检测，若检测成功，再去执行readinessProbe和livenessProbe探针。# 若没有定义该探针，则默认为成功。startupProbe:httpGet:port: 80path: /start.htmlfailureThreshold: 3initialDelaySeconds: 40periodSeconds: 1successThreshold: 1timeoutSeconds: 1

总结

Pod 是 Kubernetes 架构的基石，它将容器组合成一个具有共享网络、存储和生命周期的逻辑单元。理解 Pod 的核心概念、生命周期、关键特性（如探针、资源、存储卷）以及其与控制器、网络、存储的关系，是有效设计、部署和管理 Kubernetes 应用的基础。遵循最佳实践（如使用控制器、定义探针、添加标签）能显著提升应用的可靠性、可维护性和可观测性。