kubernetes部署.net应用的核心是确保pod启动即就绪、连通稳定、扩缩可靠、可观测强；关键卡点在于多阶段镜像构建、健康探针精准配置、数据库迁移隔离执行、配置安全挂载及监听地址显式设为0.0.0.0。

直接上结论：Kubernetes 部署 .NET Core（现统一称 .NET）应用，核心不是“能不能跑”，而是“怎么让 Pod 启动时就准备好、连得上、扩得稳、查得清”。关键卡点往往不在 YAML 写不写得对，而在镜像构建方式、数据库迁移时机、健康检查路径是否真实可访问。

用多阶段 Dockerfile 构建轻量、可复现的镜像

官方 mcr.microsoft.com/dotnet/sdk:8.0 和 mcr.microsoft.com/dotnet/aspnet:8.0 是当前生产首选。硬套旧版（如 3.1 或 5.0）会导致基础镜像停止维护、安全漏洞无法修复，且与 K8s 1.25+ 的 CRI 兼容性变差。

常见错误现象：本地 dotnet run 正常，但容器内报 Could not load file or assembly —— 很可能是 SDK 镜像构建后没 clean 依赖，或 final 阶段漏拷了 runtimeconfig.json。

• 必须使用多阶段：build → publish → final，避免把 SDK、nuget 缓存、调试符号打进运行镜像
• EXPOSE 不影响 K8s 端口映射，但建议保留并设为 80（ASP.NET Core 默认监听端口），便于本地调试和 probe 配置对齐
• 发布命令务必加 --no-restore（因 restore 已在 build 阶段完成），否则 final 阶段会因无网络或权限失败
• 镜像 tag 推荐用 Git commit SHA 或语义化版本（如 v1.2.3），禁用 latest —— K8s 拉取策略默认 IfNotPresent，用 latest 容易导致误复用旧镜像

Deployment 中必须配置 readinessProbe 和 livenessProbe

K8s 不会等你的 Program.cs 里 await host.RunAsync() 执行完才认为服务就绪。没配探针，滚动更新时流量可能打到尚未完成 EF Core 迁移、DB 连接未建立的 Pod 上，直接 500。

典型错误配置：httpGet.path: "/health" 但应用没暴露该 endpoint；或 initialDelaySeconds: 5 太小，EF Core Database.Migrate() 耗时超 10 秒就触发重启循环。

Kubernetes Skills

针对 Kubernetes 仪表板和 Web UI 的浏览器自动化。适用于与 Kubernetes Dashboard、Grafana、ArgoCD UI 或其他 Web 界面交互。需要设置 MCP_BROWSER_ENABLED=true。

下载

• ASP.NET Core 6+ 建议用内置 HealthCheckService，注册 services.AddHealthChecks().AddDbContextCheck<appdbcontext>()</appdbcontext>
• readinessProbe 应检查 DB 连通性 + 关键外部依赖（如 Redis、Message Broker），失败则从 Service Endpoints 中摘除
• livenessProbe 可只检查进程存活（如 httpGet.path: "/healthz" 返回 200 即可），避免因临时 DB 故障反复 kill Pod
• 所有 probe 的 timeoutSeconds 必须 > 应用冷启动耗时（含迁移、缓存预热），实测 .NET 8 + EF Core 8 在中等数据量下首次 Migrate() 常需 8–15 秒

EF Core 数据库迁移不能靠应用启动时自动执行

直接在 Program.cs 里调用 context.Database.Migrate() 看似简单，但在 K8s 多副本场景下会引发竞态：多个 Pod 并发执行 migration，可能破坏表结构或唯一约束。

更糟的是，如果 migration 失败，Pod 会不断重启 —— 而 K8s 默认 restartPolicy: Always，根本不会给你留日志排查时间。

• 正确做法：用 Job 资源单独执行迁移，成功后再启动主应用 Deployment
• Job 必须设置 backoffLimit: 1 和 activeDeadlineSeconds: 300，防止无限重试拖垮集群
• Job 镜像可复用主应用镜像，通过 entrypoint 覆盖为 ["dotnet", "MyApp.dll", "migrate"]，并在 Main 中识别该参数分支执行 Database.Migrate()
• Job 必须显式依赖数据库 Service 就绪（可用 initContainer + nc -z db-svc 5432 做前置探测）

ConfigMap 和 Secret 注入必须用 volume 挂载而非环境变量

环境变量注入看似方便，但有两大硬伤：一是 Secret 以明文形式出现在 ps aux 和 K8s event 日志中（即使 base64 也不安全）；二是超长连接字符串（含特殊字符如 @、/）容易被 shell 解析错误，导致 Invalid URI: The hostname could not be parsed.

尤其当连接字符串来自 Azure Key Vault 或 HashiCorp Vault 同步的 Secret 时，体积和复杂度更高。

• 推荐方式：将 Secret 挂载为文件（如 /app/config/connectionstring.txt），应用启动时读取该路径
• 挂载后注意文件权限：.NET 容器默认用户是 root，但 K8s 1.20+ 默认启用 runAsNonRoot: true，需在 SecurityContext 中指定 runAsUser: 1001 并确保挂载文件对该 UID 可读
• ConfigMap 用于非敏感配置（如日志级别、Feature Flag），同样建议挂载为文件，避免环境变量名大小写混淆（Windows 开发 vs Linux 运行）
• 不要在 Dockerfile 中 COPY 配置文件进镜像 —— 违反“镜像一次构建、多环境部署”原则

最易被忽略的一点：.NET 应用在容器里默认不监听 0.0.0.0:80，而是 localhost:80。若没在 Program.cs 显式调用 webApplicationBuilder.WebHost.UseUrls("http://0.0.0.0:80") 或通过 ASPNETCORE_URLS=http://0.0.0.0:80 环境变量覆盖，K8s Service 流量根本进不来 Pod。