一个公司做网站需要注意什么襄阳建设网站

一个公司做网站需要注意什么,襄阳建设网站,本科自考是什么意思啊,百度给做网站吗文章目录概述一、探针种类、方法与使用场景1. 探针种类#xff08;Probe Types#xff09;2. 探针检测方法#xff08;Handler Types#xff09;3. 探针关键参数二、探针使用案例1. livenessProbe#xff08;存活探针#xff09;2. readinessProbe#xff08;就绪探针Probe Types2. 探针检测方法Handler Types3. 探针关键参数二、探针使用案例1. livenessProbe存活探针2. readinessProbe就绪探针3. startupProbe启动探针三、探针接口设计最佳实践1. 探针目标与接口职责对照表2. 每种探针对应接口的设计最佳实践Liveness Probe 接口/live 或 /health/liveReadiness Probe 接口/ready 或 /health/readyStartup Probe 接口/startup 或 /started反面案例 vs 正确做法概述Kubernetes简称 k8s中的探针Probes是用于检测容器健康状态的重要机制它帮助 Kubernetes 决定何时将 Pod 加入服务流量、何时重启容器以及何时从服务中剔除不可用的实例。一、探针种类、方法与使用场景1. 探针种类Probe TypesKubernetes 提供了三种类型的探针(1) livenessProbe存活探针作用判断容器是否仍在运行。行为如果探针失败kubelet 会杀死容器并根据重启策略restartPolicy决定是否重启。典型场景应用陷入死锁、内存泄漏、无限循环等无法自行恢复的状态。(2) readinessProbe就绪探针作用判断容器是否准备好接收流量。行为如果探针失败Pod 的 IP 地址会从所有 Service 的 Endpoints中移除即不再接收新请求。典型场景应用启动较慢如加载大模型、连接数据库、依赖外部服务未就绪等、应用短暂不可用时避免影响流量。(3) startupProbe启动探针v1.16 引入作用判断容器是否已成功启动。行为在 startupProbe 成功之前liveness 和 readiness 探针不会执行。典型场景启动时间很长的应用如 Java 应用、大型 ML 模型加载避免因启动慢被误杀。⚠️ 注意三种探针可以同时配置但 startupProbe 优先级最高在其成功前其他探针不生效。2. 探针检测方法Handler Types每种探针都支持以下三种检测方式方法说明exec在容器内执行一个命令退出码为 0 表示成功。httpGet向容器发送 HTTP GET 请求响应状态码在 200–399 之间表示成功。tcpSocket尝试与容器指定端口建立 TCP 连接能连通即成功。3. 探针关键参数initialDelaySeconds:5# 容器启动后等待多少秒才开始探测periodSeconds:10# 探测间隔秒timeoutSeconds:5# 探测超时时间successThreshold:1# 连续成功多少次才算通过liveness 必须为1failureThreshold:3# 连续失败多少次才算失败对于 livenessProbesuccessThreshold 必须为 1。对于 readinessProbe可设为1用于容忍短暂失败。二、探针使用案例1. livenessProbe存活探针livenessProbe:httpGet:path:/liveport:8080initialDelaySeconds:15# 容器启动后等待多少秒才开始探测periodSeconds:20# 探测间隔秒timeoutSeconds:5# 单次探测超时时间failureThreshold:3# 连续失败多少次才判定为“不存活”successThreshold:1# 成功阈值liveness 必须为 1参数详解参数默认值说明initialDelaySeconds0容器启动后延迟多久开始第一次探测。对慢启动应用至关重要但更推荐用 startupProbe 来兜底。periodSeconds10每隔多少秒执行一次探测。建议 10~30 秒太频繁影响性能太稀疏恢复慢。timeoutSeconds1单次探测允许的最大耗时超时即视为失败。建议 2~5 秒。failureThreshold3连续失败多少次才触发容器重启。总容忍时间为(timeoutSeconds periodSeconds) × (failureThreshold - 1) timeoutSeconds简化估算≈ periodSeconds × failureThresholdsuccessThreshold1livenessProbe 必须为 1即一次成功就算恢复不能设为 1。⚠️ 注意liveness 接口必须轻量、只读、无外部依赖避免在 liveness 中检查数据库、Redis、下游服务合理设置failureThreshold太小网络抖动导致误杀太大故障恢复慢。配合日志和监控 只关心“我还能不能活”不关心“我能不能干活”。 失败 重启所以必须谨慎设计失败条件。 它是最后的安全网不是日常健康检查。2. readinessProbe就绪探针readinessProbe:httpGet:path:/readyport:8080initialDelaySeconds:5# 容器启动后延迟多少秒开始探测periodSeconds:10# 探测间隔秒timeoutSeconds:3# 单次探测超时时间failureThreshold:3# 连续失败多少次才判定为“未就绪”successThreshold:1# 连续成功多少次才算“就绪”可 1参数详解参数默认值说明initialDelaySeconds0启动后等待多久开始探测。对慢启动应用很重要但更推荐配合 startupProbe。periodSeconds10每隔多少秒探测一次。建议 5~15 秒。timeoutSeconds1单次探测最大耗时超时即失败。建议 2~5 秒。failureThreshold3连续失败多少次才将 Pod 标记为 NotReady。successThreshold1可设为 1如 2用于防止因短暂抖动导致频繁切换 Ready 状态。场景 数据库暂时不可用 → Pod 不接收流量时间事件T0sPod 启动T5s/ready 探测 → DB 连接失败 → 503 ❌第1次失败T15s第二次失败 ❌T25s第三次失败 ❌ → 达到 failureThreshold3T25sPod 状态为 Running but NotReadyT30sService Endpoints 不包含该 Pod → 零流量打入 ✅T60sDB 恢复T65s/ready 首次成功 ✅第1次T75s第二次成功 ✅ → Pod 变为 ReadyT76s流量自动恢复 ✅⚠️ 注意检查所有关键外部依赖DB、Redis、Config Server、认证服务等。使用短连接或连接池 ping避免长期占用连接。设置合理的 successThreshold如 2防止因网络抖动频繁进出 Ready 状态。配合 preStop hook 实现优雅下线lifecycle:preStop:exec:command:[/bin/sh,-c,sleep 10]# 先 sleep同时让 readiness 失败监控 NotReady Pod 数量通过 Prometheus 报警。 “能跑 ≠ 能干” —— Running 不等于 Ready。 流量开关由 readiness 控制不是由容器是否启动决定。 它是服务网格、滚动更新、弹性伸缩的基石。3. startupProbe启动探针startupProbe:httpGet:path:/startupport:8080initialDelaySeconds:0# 容器启动后多久开始第一次探测秒periodSeconds:5# 探测间隔秒timeoutSeconds:2# 单次探测超时时间秒failureThreshold:10# 允许连续失败的最大次数参数详解参数默认值说明initialDelaySeconds0容器启动后等待多少秒才开始第一次探测。对于启动极慢的应用可设为 5~10 秒。periodSeconds10每隔多少秒探测一次。建议设为 3~10 秒。timeoutSeconds1单次探测允许的最大耗时超时即视为失败。failureThreshold3最关键参数表示最多允许连续失败多少次。总容忍时间为(initialDelaySeconds) (periodSeconds × failureThreshold)只要在这 60 秒内有一次探测成功startupProbe 就算通过之后 livenessProbe 和 readinessProbe才会开始工作。如果 startupProbe 在其最大容忍时间即 initialDelaySeconds periodSeconds × failureThreshold后仍然探测失败Kubernetes 会认为容器“启动失败”并按照 Pod 的重启策略restartPolicy进行处理——通常是杀死容器并重新创建重启⚠️ 注意startup 接口必须轻量只检查“是否初始化完成”不要连数据库。合理设置容忍时间留足余量宁可多给不要少给所有启动时间 30 秒的应用都应配置 startupProbe。不要在 startupProbe 中做 readiness 的事如检查 DB那是 readinessProbe 的职责。监控 startupProbe 失败事件可通过 Prometheus 抓取kube_pod_container_status_waiting_reason{reason“CrashLoopBackOff”} 或事件日志。 startupProbe 成功前liveness 和 readiness 不生效。 startup 接口只关心“我启好了没”不关心“我能干活吗”。 宁可多给几秒也不要让 Pod 死在黎明前。三、探针接口设计最佳实践下面从 三种探针的特性出发系统性地阐述 健康检查接口的最佳实践设计方法。1. 探针目标与接口职责对照表探针类型核心目标健康检查接口应验证的内容不应包含的内容startupProbe判断容器是否已完成启动应用主进程已启动、初始化逻辑如加载模型、配置完成外部依赖DB、缓存连通性readinessProbe判断是否可以接收流量所有外部依赖就绪DB、Redis、API 网关等应用内部状态如内存泄漏、死锁livenessProbe判断是否需要重启容器应用是否处于可恢复的运行状态无死锁、未崩溃外部依赖失败不应因 DB 挂了重启2. 每种探针对应接口的设计最佳实践Liveness Probe 接口/live 或 /health/live✅ 应该做仅检查应用自身是否处于可运行状态主线程未阻塞、内存未 OOM、无死锁最好是一个纯内存操作不涉及 I/O。即使外部依赖如 DB宕机只要应用本身还能运行比如有重试队列就应返回成功。Liveness 只对不可恢复错误返回失败如死锁。❌ 不应该做连接数据库、调用外部 API。因外部服务不可用而返回失败这会导致不必要的重启。示例最简形式# 检查内部状态标志如后台线程是否存活ifnotbackground_worker.is_alive():returnjsonify({error:worker dead}),500⚠️ 极简即可甚至可以直接返回 200因为如果进程挂了根本不会响应。Readiness Probe 接口/ready 或 /health/ready✅ 应该做验证所有关键外部依赖是否可用数据库连接池是否能获取连接、Redis 是否可 ping、下游微服务是否可达谨慎使用返回 200 仅当所有依赖就绪可安全接收流量。Readiness 对暂时不可用返回失败如 DB 连接池满。/ready 返回 200 但 body 是 {“ok”: false}K8s 仍认为就绪只看状态码❌ 不应该做检查非关键依赖如日志服务、监控上报。执行写操作或修改状态。因单点依赖失败导致整个应用不可用可考虑降级逻辑。示例最简形式app.route(/ready)defreadiness_check():try:# 检查数据库db.session.execute(text(SELECT 1))# 检查 Redisredis_client.ping()returnjsonify({status:ready}),200exceptExceptionase:app.logger.warning(fReadiness check failed:{e})returnjsonify({error:dependencies not ready}),503⚠️ 注意避免在 readiness 中做“全链路健康检查”否则容易引发级联故障。Startup Probe 接口/startup 或 /started✅ 应该做检查应用主进程是否已完全初始化例如模型加载完毕、配置解析完成。返回成功仅当内部初始化逻辑完成。轻量、快速、无外部依赖。❌ 不应该做连接数据库、调用外部服务。执行耗时操作如全表扫描。示例最简形式app.route(/startup)defstartup_check():ifapp.config.get(INIT_DONE):returnjsonify({status:started}),200else:returnjsonify({error:still initializing}),503 提示可在init或 before_first_request 中设置 INIT_DONE True。反面案例 vs 正确做法场景错误做法正确做法数据库挂了liveness 返回 500 → 容器被反复重启liveness 仍返回 200readiness 返回 503 → 流量切断但容器保留应用启动慢30s无 startupProbeliveness 在 10s 超时杀死容器配置 startupProbe允许最多 60s 启动缓存不可用readiness 检查缓存失败 → 整个服务不可用若缓存非关键readiness 忽略或实现降级逻辑