Vue 3 的工程化通常集中在 Vite 构建、组件拆分和包体积优化，但当应用需要部署到 Kubernetes 集群时，工程化的范围会被自然拉宽。CNCF 提供的不是某一种框架能力，而是一套面向容器和动态基础设施的标准：镜像、编排、服务发现、配置管理、可观测性。把 Vue 3 项目接入这套体系，核心不是改写前端代码，而是调整交付链路和运行配置，让静态资源产物具备与后端服务同等的治理能力。
先分清 Vue 3 工程化与 CNCF 的对接点
Vue 3 应用本身运行在浏览器端，但浏览器拿到的是构建后的静态文件。CNCF 体系中的 Kubernetes 负责调度容器，容器内通常运行 Web 服务器。因此前端的运行态不是 Vue 实例，而是承载这些静态资源的服务器。工程化对接首先要承认这一点，很多部署混乱正是因为没有把静态服务器当作一等公民来管理。
云原生对前端的要求可以从交付和运行两个角度拆开。交付阶段关注镜像可重复构建、配置与代码分离、制品可追溯；运行阶段关注进程无状态、探针可执行、日志和指标可采集。Vue 3 代码层面对这些没有直接约束，但 Vite 的构建配置、环境变量机制和 Nginx 部署方式会直接影响这些能力能否落地。
如果只用本地 npm run build 再手动上传，容器镜像就缺少版本化上下文。工程化的价值在于把 Vue 3 的构建流水线映射为 CNCF 工具链中的步骤，比如用 Tekton 或 Argo Workflows 跑构建，用 Kaniko 或 Buildpacks 生成镜像，再推送到 Harbor。这样前端发布不再依赖个人电脑，也才能在同一套流水线里执行安全扫描和制品签名。
用多阶段镜像解决构建与运行分离
Vue 3 项目的依赖体积往往远大于最终产物。多阶段 Dockerfile 可以避免把 node_modules 带进运行镜像。第一阶段使用 Node 安装依赖并执行构建，第二阶段只保留 Nginx 和 dist 目录，这样做既减小镜像体积，也降低攻击面。下面是一种常见写法。
FROM node:20-alpine AS build WORKDIR /app COPY package.json pnpm-lock.yaml ./ RUN corepack enable && pnpm install --frozen-lockfile COPY . . ARG VITE_API_BASE ENV VITE_API_BASE=$VITE_API_BASE RUN pnpm build FROM nginx:1.27-alpine COPY --from=build /app/dist /usr/share/nginx/html COPY nginx.conf /etc/nginx/conf.d/default.conf EXPOSE 80 CMD ["nginx", "-g", "daemon off;"]
该镜像启动后 Nginx 监听 80 端口，能直接服务静态文件。但 Vue Router 使用 history 模式时，刷新 /users 这类路径会向 Nginx 请求对应文件，找不到就返回 404。需要在 Nginx 配置里加 try_files 回退到 index.html，同时保留静态资源缓存规则，避免每次都回源。
server {
listen 80;
server_name _;
root /usr/share/nginx/html;
index index.html;
location / {
try_files $uri $uri/ /index.html;
}
location /assets/ {
expires 7d;
add_header Cache-Control "public, immutable";
}
location = /healthz {
return 200 'ok';
add_header Content-Type text/plain;
}
}环境变量注入是另一个关键。Vue 3 使用 import.meta.env.VITE_API_BASE 在编译期读取变量，如果希望在运行时切换接口地址，必须在构建时通过 ARG 传入。可以执行 docker build --build-arg VITE_API_BASE=https://api.ipipp.com .。如果部署多套环境，CNCF 体系中的 CI 系统应从配置中心读取值后再执行构建。这不是运行期配置，但可借助 Argo CD 的参数化构建实现不同集群不同值。
用 Kubernetes 资源对象管理 Vue 3 应用
容器镜像准备好以后，Kubernetes 中的 Deployment 可以声明副本数、滚动更新和资源限制。前端 Pod 通常资源消耗较低，但仍要设置 requests 和 limits，避免突发流量下被 OOM 杀掉。这里给出最小部署示例。
apiVersion: apps/v1
kind: Deployment
metadata:
name: vue-app
spec:
replicas: 3
selector:
matchLabels:
app: vue-app
template:
metadata:
labels:
app: vue-app
spec:
containers:
- name: vue-app
image: registry.ipipp.com/vue-app:1.4.2
ports:
- containerPort: 80
readinessProbe:
httpGet:
path: /healthz
port: 80
initialDelaySeconds: 5
periodSeconds: 10
livenessProbe:
httpGet:
path: /healthz
port: 80
initialDelaySeconds: 15
periodSeconds: 20
resources:
requests:
cpu: 10m
memory: 32Mi
limits:
cpu: 100m
memory: 64MireadinessProbe 对前端应用仍然重要。Nginx 默认没有独立健康路径，可以在配置文件中增加 location = /healthz。这样当 Pod 启动完成但 Nginx 尚未就绪时，Service 不会把流量转发过来。livenessProbe 可以复用同一路径，但需要注意不要因为短暂高负载重启容器。策略上 readiness 失败摘流量，liveness 失败才重启，两者阈值要分开设置。
Service 和 Ingress 用于暴露和路由。对于 CNCF 体系，Ingress Controller 可选择 Nginx Ingress、Traefik 或 Contour。前端应用通常作为入口，需要在 Ingress 中处理 TLS 终止和路径转发。此外，ConfigMap 可以挂载 Nginx 配置，避免修改镜像。比如把 default.conf 内容放 ConfigMap 中，Deployment 通过 volume 挂到 /etc/nginx/conf.d/default.conf，这样更新路由规则不用重新打镜像，变更风险和发布周期都会下降。
用 OpenTelemetry 与 Prometheus 补齐观测能力
前端可观测性容易被忽略。CNCF 的 OpenTelemetry 提供 JavaScript SDK，可以在 Vue 3 入口初始化，自动采集页面加载、路由切换和接口请求的 trace。接入后，请求会带上 traceparent 头，后端如果也使用 OTel，就能把浏览器到服务端的调用链串起来。下面是一个轻量接入示例。
import { WebTracerProvider } from '@opentelemetry/sdk-trace-web';
import { OTLPTraceExporter } from '@opentelemetry/exporter-trace-otlp-http';
import { BatchSpanProcessor } from '@opentelemetry/sdk-trace-base';
import { registerInstrumentations } from '@opentelemetry/instrumentation';
import { FetchInstrumentation } from '@opentelemetry/instrumentation-fetch';
const provider = new WebTracerProvider();
provider.addSpanProcessor(
new BatchSpanProcessor(
new OTLPTraceExporter({
url: 'https://otel.ipipp.com/v1/traces'
})
)
);
provider.register();
registerInstrumentations({
instrumentations: [new FetchInstrumentation()]
});指标方面前端更关注性能数据，如 LCP、CLS、FID。可以在 Web Vitals 基础上把指标暴露给 Prometheus pushgateway，或者通过 OTel Metrics 导出到 OTLP 端点。后端基础设施的指标如 CPU、内存、请求量则来自 Nginx Ingress Controller 和 cAdvisor，Grafana 统一展示。这样运维人员能看到前端发布后首屏时间变化，也能看到后端响应是否同步劣化。
日志方面 Vue 3 应用本身不会产生大量服务端日志，但 Nginx 访问日志可以输出为 JSON，由 Fluent Bit 采集到 Loki。结合 traceId，可以把一次前端请求对应的 Nginx 日志、后端服务日志关联起来。这种能力对排查跨端问题很有价值，也是 CNCF 生态给前端带来的实际工程收益。完成这些接入后，Vue 3 工程化就不再局限于本地开发体验，而真正成为云原生交付体系中的一环。