云原生开发早已不只是“把应用装进容器”。开发者还要面对镜像构建、部署策略、资源限制、健康检查、安全上下文和运行时诊断。围绕 KubeCon + CloudNativeCon North America 2026 所提出的应用开发者旅程，一个关键问题是：哪些基础设施知识应当由开发者掌握，哪些复杂度又应该由平台消化？
开发者旅程不应止于代码提交
一条完整的应用交付链路，通常包含以下环节：
- 编写并在本地运行代码；
- 构建可重复的制品，例如容器镜像；
- 声明应用需要的端口、配置、资源和依赖；
- 部署到开发、测试和生产环境；
- 观察日志、指标、事件与发布状态；
- 在失败时定位问题，并安全地回滚。
如果这些环节分别依赖零散脚本、内部文档和人工审批，开发者就会把大量时间花在“理解组织基础设施”上。反过来，如果平台隐藏所有细节，应用团队又可能无法判断 CPU 限额、探针或扩缩容配置为何影响服务稳定性。
更合理的边界不是让开发者完全绕开 Kubernetes，而是让平台提供一条有默认值、可观察、允许逐步深入的“黄金路径”。日常部署只需要少量输入；出现异常或特殊需求时，开发者仍能看到底层对象和状态。
平台应隐藏机械操作，而不是运行事实
平台最适合接管的是重复且容易出错的工作，例如：
- 生成符合组织规范的镜像和 Kubernetes 清单；
- 自动添加镜像扫描、签名和策略检查；
- 配置日志、指标、追踪与告警接入；
- 创建命名空间、服务账户和最小权限；
- 提供标准化的渐进发布与回滚流程；
- 为常见语言栈维护经过验证的项目模板。
但有些信息不应被完全隐藏。开发者至少需要知道：
- 应用监听哪个端口，怎样判断它已经就绪；
- 正常运行需要多少 CPU 和内存；
- 配置与密钥来自哪里；
- 新版本失败后如何查看事件、日志和发布历史；
- 哪些操作会影响可用性、成本或安全边界。
平台的价值不在于创造另一个不透明控制台，而在于把默认实践固化成产品，同时保留通向 Kubernetes 原生对象的逃生口。
可以这样实践：搭建一条最小可运行路径
下面的示例假设本机已安装 Docker、kind 和 kubectl。它创建一个简单的 Python HTTP 服务，构建镜像，并部署到本地 Kubernetes 集群。示例同时加入了健康检查、资源约束和非 root 运行配置。
创建项目目录：
mkdir -p journey-demo
cd journey-demo
创建 app.py：
from http.server import BaseHTTPRequestHandler, HTTPServer
class Handler(BaseHTTPRequestHandler):
def do_GET(self):
if self.path == "/healthz":
body = b"ok\n"
else:
body = b"hello from the developer journey\n"
self.send_response(200)
self.send_header("Content-Type", "text/plain; charset=utf-8")
self.send_header("Content-Length", str(len(body)))
self.end_headers()
self.wfile.write(body)
if __name__ == "__main__":
HTTPServer(("0.0.0.0", 8080), Handler).serve_forever()
创建 Dockerfile：
FROM python:3.12-slim
WORKDIR /app
COPY app.py /app/app.py
USER 10001:10001
EXPOSE 8080
CMD ["python", "/app/app.py"]
创建 k8s.yaml：
apiVersion: apps/v1
kind: Deployment
metadata:
name: journey-demo
spec:
replicas: 2
selector:
matchLabels:
app: journey-demo
template:
metadata:
labels:
app: journey-demo
spec:
containers:
- name: app
image: journey-demo:0.1
imagePullPolicy: Never
ports:
- name: http
containerPort: 8080
readinessProbe:
httpGet:
path: /healthz
port: http
initialDelaySeconds: 2
periodSeconds: 5
livenessProbe:
httpGet:
path: /healthz
port: http
initialDelaySeconds: 5
periodSeconds: 10
resources:
requests:
cpu: 50m
memory: 32Mi
limits:
cpu: 250m
memory: 128Mi
securityContext:
allowPrivilegeEscalation: false
readOnlyRootFilesystem: true
runAsNonRoot: true
capabilities:
drop:
- ALL
---
apiVersion: v1
kind: Service
metadata:
name: journey-demo
spec:
selector:
app: journey-demo
ports:
- name: http
port: 80
targetPort: http
构建并部署：
docker build -t journey-demo:0.1 .
kind create cluster --name developer-journey
kind load docker-image journey-demo:0.1 --name developer-journey
kubectl apply -f k8s.yaml
kubectl rollout status deployment/journey-demo
kubectl port-forward service/journey-demo 8080:80
另开一个终端验证服务：
curl http://127.0.0.1:8080/
curl http://127.0.0.1:8080/healthz
排查部署问题时，可以使用：
kubectl get pods
kubectl describe deployment journey-demo
kubectl get events --sort-by=.metadata.creationTimestamp
kubectl logs deployment/journey-demo --all-pods=true
如果部署到共享或生产集群，需要把镜像推送到真实仓库，修改 image 字段，并移除 imagePullPolicy: Never。生产环境还应补充镜像摘要固定、网络策略、Pod 中断预算、自动扩缩容和集中式可观测性配置。
把示例收敛成平台契约
上述 YAML 不应该由每个团队长期复制维护。平台团队可以把它转化为模板、内部开发者门户动作，或更高层的应用资源定义。开发者只提交少量业务参数，例如：
name: journey-demo
runtime: python
port: 8080
healthPath: /healthz
size: small
replicas: 2
平台再将这些输入渲染为经过治理的 Deployment、Service、策略和监控配置。这里的重点是保持契约清晰：size: small 对应多少资源、默认探针如何工作、哪些字段允许覆盖，都应该能够查询和版本化。
抽象也有成本。模板过于刚性会阻碍特殊工作负载，模板过于灵活则会重新暴露 Kubernetes 的全部复杂度。因此，平台通常需要三层能力：适合大多数服务的默认路径、经过审批的扩展点，以及可以直接操作底层资源的专家路径。
评估开发者体验时检查什么
设计云原生开发者旅程时，可以从以下问题开始：
- 新开发者能否在一天内把示例服务部署到测试环境？
- 构建、扫描、部署和回滚是否有一致入口？
- 失败信息是否直接告诉开发者下一步该检查什么？
- 平台默认值是否包含资源约束、探针和最小权限？
- 开发者能否看到平台最终创建的 Kubernetes 对象？
- 平台契约是否有版本，并能逐步迁移？
- 团队是否在衡量交付时间、失败率和恢复时间，而不只是平台使用量？
真正有效的开发者平台不会要求应用团队成为 Kubernetes 专家，也不会假装基础设施不存在。它应当把常见路径变短，把安全与可靠性变成默认值，并在问题出现时提供足够清晰的运行事实。