企业官网建设流程全解析

一般学校网站的后台用什么做,扁平化网站 psd,建设工程网站有哪些内容,优秀ppt案例欣赏前言 掌握 Pod 基础配置后#xff0c;进阶能力才是保障 K8s 应用稳定运行的关键。想象一下#xff1a;如果容器无节制占用 CPU 和内存#xff0c;会导致其他服务崩溃#xff1b;如果应用卡死但 K8s 不知情#xff0c;会持续转发流量造成故障#xff1b;如果容器启动时依赖…前言掌握 Pod 基础配置后进阶能力才是保障 K8s 应用稳定运行的关键。想象一下如果容器无节制占用 CPU 和内存会导致其他服务崩溃如果应用卡死但 K8s 不知情会持续转发流量造成故障如果容器启动时依赖未就绪或关闭时未保存数据会引发业务异常。这篇文章就用 “大白话 实操案例”带你吃透 Pod 进阶配置——资源限制避免资源争用、健康探针实现自动自愈、生命周期钩子管理启停动作让你的 K8s 应用既稳定又可控。一、Pod 进阶配置1.1 Pod 资源限制集群资源就像公寓的水电每个容器不能无限制使用。K8s 提供资源限制功能给每个容器设定 “最低需求” 和 “最高上限”避免资源浪费或争用。1.1.1 核心概念requests资源请求容器启动的 “最低生活费”是容器运行必需的最小资源。K8s 调度器会根据这个值选择有足够剩余资源的节点部署 Pod。limits资源限制容器运行的 “消费上限”是容器能使用的最大资源。超出这个限制后CPU 会被限制使用降速内存会被强制终止OOM 杀死。简单说requests 决定 “能部署到哪个节点”limits 决定 “最多能用多少资源”。1.1.2 资源单位CPU 单位用 “毫核m” 表示1 核 CPU 1000m。500m 0.5 核 CPU半个核心250m 0.25 核 CPU四分之一核心支持小数比如 0.5 核和 500m 是同一个意思。内存单位推荐用二进制单位Gi、Mi、Ki基于 1024 换算也支持十进制单位GB、MB基于 1000 换算。1Gi 1024Mi1Mi 1024Ki注意1Gi 比 1GB 大约多 73MBK8s 中优先用 Gi/Mi 避免数据丢失。1.2 Pod 资源限制案例下面通过两个实际配置带你看懂资源请求和限制的配置逻辑。示例 1基础资源配置apiVersion:v1kind:Podmetadata:name:frontendspec:containers:-name:app# 主应用容器image:images.my-company.example/app:v4resources:requests:memory:64Mi# 最少需要 64Mi 内存cpu:250m# 最少需要 0.25 核 CPUlimits:memory:128Mi# 最多能用 128Mi 内存cpu:500m# 最多能用 0.5 核 CPU-name:log-aggregator# 日志收集容器image:images.my-company.example/log-aggregator:v6resources:requests:memory:64Micpu:250mlimits:memory:128Micpu:500m通俗分析每个容器的 “最低需求” 都是 0.25 核 CPU 64Mi 内存每个容器的 “消费上限” 都是 0.5 核 CPU 128Mi 内存整个 Pod 的总需求0.5 核 CPU 128Mi 内存两个容器相加整个 Pod 的总上限1 核 CPU 256Mi 内存。案例 1不同容器差异化配置apiVersion:v1kind:Podmetadata:name:frontendspec:containers:-name:web# Nginx web 容器image:nginxresources:requests:memory:64Mi# 需求低cpu:250mlimits:memory:128Micpu:500m-name:db# MySQL 数据库容器image:mysqlresources:requests:memory:512Mi# 数据库需要更多内存需求高cpu:0.5# 0.5 核 CPU等同于 500mlimits:memory:1Gi# 上限 1Gi 内存cpu:1# 上限 1 核 CPU通俗分析Web 容器轻量低需求、低上限DB 容器耗资源高需求、高上限Pod 总需求0.75 核 CPU 576Mi 内存Pod 总上限1.5 核 CPU 1.128Gi 内存1Gi 128Mi。调度与资源分配K8s 调度 Pod 时只会看requests最低需求不会看limits。Pod 调度实例执行命令部署 Podkubectl apply -f pod2.yaml查看 Pod 部署到哪个节点kubectl get pods -o wide查看节点资源使用情况kubectl describe nodes 节点名比如 node02。实际分配情况假设节点有 2 核 CPUPod 总 requests 是 0.75 核就会占用节点 37.5% 的 CPU 资源节点资源不够时K8s 会自动把 Pod 调度到其他有空闲资源的节点。总结未设置 requests 时K8s 会默认让它等于 limits多个容器的 requests 和 limits 会自动相加作为 Pod 的总资源按容器角色差异化配置数据库、缓存等耗资源组件requests 和 limits 设高些轻量组件设低些。1.3 健康检查探针 ProbeK8s 里的 “健康医生”定期检查容器状态发现问题自动处理比如重启容器、移出流量。探针由 kubelet 执行分 3 种类型支持 3 种检查方法。1.3.1 探针类型重点探针类型作用失败处理方式livenessProbe存活探针检测容器是否 “活着”正常运行杀死容器按重启策略重启readinessProbe就绪探针检测容器是否 “准备好”能接收请求从 Service 中移除 Pod不转发流量startupProbe启动探针检测应用是否 “启动完成”适用于慢启动启动前屏蔽其他探针失败则重启容器小贴士启动探针是 K8s 1.17 版本后新增的比如 Java 应用启动慢就用它避免其他探针误判。1.3.2 检查方法探针通过 3 种方式检查容器状态按需选择exec在容器内执行命令返回码为 0 表示成功比如检查文件是否存在httpGet向容器的指定端口和路径发 HTTP 请求状态码 200-399 表示成功tcpSocket尝试连接容器的指定端口能建立 TCP 连接表示成功。每次探测结果只有 3 种成功、失败、未知通信问题不处理。二、Kubernetes 探针Probe实践光懂理论不够下面通过实操案例带你玩转 3 种探针看完就能上手。2.1 存活探针Liveness Probe实践存活探针的核心容器 “死了” 就重启保障应用持续运行。2.1.1 Exec 方式执行命令检测示例 1核心配置apiVersion:v1kind:Podmetadata:name:liveness-execspec:containers:-name:liveness-containerimage:busybox# 容器启动后创建 /tmp/live 文件 → 10 秒后删除 → 休眠 3600 秒command:[/bin/sh,-c,touch /tmp/live; sleep 10; rm -rf /tmp/live; sleep 3600]livenessProbe:exec:command:[test,-e,/tmp/live]# 检查 /tmp/live 文件是否存在initialDelaySeconds:1# 容器启动 1 秒后开始探测periodSeconds:3# 每 3 秒探测一次执行命令与结果创建 Podkubectl create -f exec.yaml实时查看状态kubectl get pods -w结果前 10 秒文件存在探针成功10 秒后文件删除探针失败K8s 重启容器RESTARTS 次数增加。2.1.2 HTTP Get 方式发送 HTTP 请求检测案例 2实操配置apiVersion:v1kind:Podmetadata:name:liveness-httpgetspec:containers:-name:nginx-containerimage:soscscs/myapp:v1ports:-containerPort:80# Nginx 监听 80 端口livenessProbe:httpGet:port:80# 探测 80 端口path:/index.html# 探测路径 /index.htmlinitialDelaySeconds:1periodSeconds:3timeoutSeconds:10# 超时时间 10 秒执行命令与结果创建 Podkubectl create -f httpget.yaml模拟异常删除 index.html 文件 →kubectl exec -it liveness-httpget -- rm -rf /usr/share/nginx/html/index.html查看状态kubectl get pods发现 RESTARTS 增加探针失败重启容器。2.1.3 TCP Socket 方式TCP 连接检测案例 3实操配置apiVersion:v1kind:Podmetadata:name:probe-tcpspec:containers:-name:nginx-containerimage:soscscs/myapp:v1livenessProbe:tcpSocket:port:8080# 故意配错端口Nginx 实际监听 80initialDelaySeconds:5# 启动 5 秒后探测periodSeconds:10# 每 10 秒探测一次failureThreshold:2# 失败 2 次后重启执行命令与结果创建 Podkubectl create -f tcpsocket.yaml查看容器监听端口kubectl exec -it probe-tcp -- netstat -natp发现只监听 80 端口实时查看状态kubectl get pods -w25 秒后5 秒延迟 10 秒×2 次失败容器重启RESTARTS 增加修复把端口改成 80重新应用配置 →kubectl apply -f tcpsocket.yamlPod 不再重启。2.2 就绪探针Readiness Probe实践就绪探针的核心容器 “没准备好” 就不接收流量避免用户访问异常。案例 4就绪探针与存活探针协同apiVersion:v1kind:Podmetadata:name:readiness-httpgetspec:containers:-name:app-containerimage:soscscs/myapp:v1ports:-containerPort:80readinessProbe:# 就绪探针检测 /index1.htmlhttpGet:port:80path:/index1.htmlinitialDelaySeconds:1periodSeconds:3livenessProbe:# 存活探针检测 /index.htmlhttpGet:port:80path:/index.htmlinitialDelaySeconds:1periodSeconds:3执行命令与结果创建 Podkubectl create -f readiness-httpget.yaml初始状态kubectl get podsREADY 为 0/1/index1.html 不存在未就绪模拟就绪创建 /index1.html →kubectl exec -it readiness-httpget -- echo 123 /usr/share/nginx/html/index1.html查看状态READY 变为 1/1就绪可接收流量模拟崩溃删除 /index.html →kubectl exec -it readiness-httpget -- rm -rf /usr/share/nginx/html/index.html查看状态存活探针失败容器重启READY 变回 0/1。案例 5就绪探针与 Service Endpoint 联动核心逻辑Service 只会把流量转发给 “就绪” 的 Pod未就绪的 Pod 会被移出 Endpoint服务端点。实操配置含 3 个 Pod 和 1 个 Service# readiness-myapp.yamlapiVersion:v1kind:Podmetadata:name:myapp1labels:{app:myapp}spec:containers:-name:myappimage:soscscs/myapp:v1ports:[{containerPort:80}]readinessProbe:httpGet:{port:80,path:/index.html}initialDelaySeconds:5periodSeconds:5---apiVersion:v1kind:Podmetadata:name:myapp2labels:{app:myapp}spec:# 配置和 myapp1 一致省略...---apiVersion:v1kind:Podmetadata:name:myapp3labels:{app:myapp}spec:# 配置和 myapp1 一致省略...---apiVersion:v1kind:Servicemetadata:{name:myapp}spec:selector:{app:myapp}type:ClusterIPports:[{port:80,targetPort:80}]执行命令与结果创建资源kubectl create -f readiness-myapp.yaml初始状态kubectl get pods,svc,endpoints -o wide3 个 Pod 都就绪Endpoint 包含 3 个 Pod 的 IP模拟故障删除 myapp1 的 index.html →kubectl exec -it myapp1 -- rm -rf /usr/share/nginx/html/index.html查看状态myapp1 的 READY 变为 0/1Endpoint 中移除 myapp1 的 IP不再接收流量修复后myapp1 重新就绪Endpoint 自动添加其 IP。三、容器生命周期钩子管理实践生命周期钩子就像容器的 “自定义动作”在启动后、关闭前执行指定操作比如初始化配置、保存数据。3.1 案例 6初始化容器与生命周期钩子核心配置apiVersion:v1kind:Podmetadata:name:lifecycle-demospec:# 初始化容器主容器启动前执行initContainers:-name:init-containerimage:soscscs/myapp:v1command:[/bin/sh,-c,echo 初始化完成 /var/log/message]volumeMounts:-name:log-volumemountPath:/var/log# 挂载存储卷共享日志# 主容器containers:-name:main-containerimage:soscscs/myapp:v1lifecycle:postStart:# 主容器启动后执行exec:command:[/bin/sh,-c,echo 主容器启动 /var/log/message]preStop:# 主容器关闭前执行exec:command:[/bin/sh,-c,echo 主容器关闭 /var/log/message]volumeMounts:-name:log-volumemountPath:/var/log# 存储卷共享日志文件volumes:-name:log-volumehostPath:path:/data/logtype:DirectoryOrCreate# 不存在则创建目录执行命令与结果创建 Podkubectl create -f post.yaml查看日志验证执行顺序kubectl exec -it lifecycle-demo -- cat /var/log/message输出初始化完成 主容器启动删除 Pod触发 preStopkubectl delete pod lifecycle-demo查看节点上的日志存储卷挂载到节点# 登录节点执行cat/data/log/message输出初始化完成 主容器启动 主容器关闭核心逻辑总结初始化容器initContainers主容器启动前执行完成前置准备如初始化配置、等待依赖postStart主容器启动后立即执行可能和应用并行用于启动后的自定义操作preStop主容器关闭前执行同步操作阻塞删除用于优雅关闭如保存数据、断开连接。四、Pod 与容器的状态说明遇到问题时Pod 和容器的状态是 “故障排查指南针”下面用通俗的语言解释每种状态4.1 Pod 状态PendingPod 已被 K8s 认可但容器还没启动比如正在调度节点、拉取镜像RunningPod 已调度到节点至少一个容器在运行或启动中Succeeded所有容器正常终止且不会重启比如一次性任务执行完成Failed所有容器都终止了且至少一个容器异常终止退出码非 0 或被强制杀死Unknown无法获取状态通常是 K8s 与节点通信失败。4.2 容器状态Waiting容器正在启动中如拉取镜像、执行初始化命令Running容器正常运行Terminated容器已终止正常或异常可通过退出码判断。小贴士用kubectl get pods看 Pod 状态用kubectl describe pod 名称看详细事件快速定位问题。总结这篇文章围绕 Pod 进阶配置的核心能力展开关键要点可总结为 3 点资源限制用 requests 保障容器 “最低需求”用 limits 防止 “资源滥用”按容器角色差异化配置避免争用探针实践存活探针保运行就绪探针保可用启动探针适配慢启动应用3 种检查方法按需选择生命周期与状态初始化容器做前置准备postStart/preStop 实现自定义动作状态信息帮你快速排查故障。掌握这些能力就能让你的 K8s 应用从 “能运行” 变成 “稳定运行、自动自愈、易于维护”