云原生工程师的角色常被误解为"会kubectl、会看Pod日志"。真正的岗位内核是:构建内部开发者平台、定义服务黄金路径、用SLO量化可靠性、治理多集群与成本、主导故障演练与应急。下面按岗位真实工作流拆解,每环给可运行代码。
业务团队不该直接写Deployment。云原生工程师要提供平台层抽象——一个App CRD,开发者填最少字段,平台自动生成Deployment/Service/HPA/PDB/NetworkPolicy。
# App CRD(简化)
apiVersion: platform.example.com/v1
kind: App
metadata: {name: order-api}
spec:
image: registry.example.com/order-api:v1.2.0
replicas: 3
port: 8080
resources: {cpu: 200m, memory: 256Mi}
expose: {type: ClusterIP}// controller:Reconcile时补齐所有子资源
func (r *AppReconciler) Reconcile(ctx context.Context, req ctrl.Request) (ctrl.Result, error) {
var app platformv1.App
if err := r.Get(ctx, req.NamespacedName, &app); err != nil { return ctrl.Result{}, client.IgnoreNotFound(err) }
dep := buildDeployment(&app) // 自动生成,含探针/资源/安全上下文
if err := r.CreateOrUpdate(ctx, dep); err != nil { return ctrl.Result{}, err }
for _, obj := range []client.Object{buildService(&app), buildHPA(&app), buildPDB(&app), buildNetPol(&app)} {
if err := r.CreateOrUpdate(ctx, obj); err != nil { return ctrl.Result{}, err }
}
// 状态回写:就绪副本数、当前版本
app.Status.ReadyReplicas = dep.Status.ReadyReplicas
return ctrl.Result{}, r.Status().Update(ctx, &app)
}工程约束:平台层必须默认安全(非root、只读根、默认NetworkPolicy拒绝),开发者想放开需显式申请;CRD要带status和conditions,业务能自助排查。
"服务稳定"不是形容词,要用SLI/SLO量化。99.9%的可用性意味着每月43分钟预算,超支就冻结发布。
# slo.yaml —— 用Sloth/Prometheus规则生成
version: "prometheus/v1"
service: "order-api"
slos:
- name: "availability"
objective: 99.9
description: "非5xx请求占比"
sli:
events:
error_query: sum(rate(http_requests_total{job="order-api",code=~"5.."}[5m]))
total_query: sum(rate(http_requests_total{job="order-api"}[5m]))
alerting:
page_alert: {labels: {severity: page}}
ticket_alert: {labels: {severity: ticket}}# burn_rate.py —— 多窗口燃烧率告警,比阈值告警更早发现
def burn_rate(error_ratio, window_hours, slo=0.999):
allowed = 1 - slo
return (error_ratio / allowed) * (30*24 / window_hours)
# 1h燃烧率>14.4 或 5m燃烧率>14.4 立即page;6h>6 开ticket工程约束:SLO必须基于用户可感知的SLI(成功率、延迟P99),不是CPU使用率;燃烧率告警配多窗口(1h+5m)降噪;错误预算耗尽自动触发发布冻结。
多集群下最怕"这个集群改了、那个没改"。用GitOps + 策略引擎统一约束。
# Kyverno策略:禁止latest、强制资源限制、强制标签
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata: {name: platform-guardrails}
spec:
validationFailureAction: Enforce
rules:
- name: disallow-latest
match: {any: [{resources: {kinds: [Pod]}}]}
validate:
message: "禁止使用latest标签"
pattern:
spec: {containers: [{image: "!*:latest"}]}
- name: require-resources
match: {any: [{resources: {kinds: [Deployment]}}]}
validate:
message: "必须设置requests/limits"
pattern:
spec: {template: {spec: {containers: [{resources: {requests: {cpu: "?*"}, limits: {memory: "?*"}}}]}}}工程约束:策略先Audit观察两周再切Enforce;集群基线用Fleet/ArgoCD ApplicationSet批量下发,新集群加入即继承全部策略。
云原生工程师要管账单。用OpenCost/Kubecost按namespace、label分摊成本,识别闲置资源。
# 按团队统计CPU请求成本(单价按实际云厂商)
sum by (team) (
kube_pod_container_resource_requests{resource="cpu"}
* on(namespace) group_left(team) namespace_labels{label_team!=""}
) * 0.03# rightsizing.py —— 基于7天P95用量给requests建议
def suggest(p95_cpu, current_req):
if p95_cpu < current_req * 0.4:
return {"action": "downsize", "suggest": round(p95_cpu * 1.3, 3)}
if p95_cpu > current_req * 0.9:
return {"action": "upsize", "suggest": round(p95_cpu * 1.3, 3)}
return {"action": "keep"}工程约束:成本必须打到团队label上,否则没人认领;downsize建议要结合HPA和业务峰值,不能只看均值。
可靠性不是配出来的,是演练出来的。用Chaos Mesh定期注入故障,验证PDB、探针、熔断是否生效。
# chaos-mesh:随机杀Pod,验证PDB与自愈
apiVersion: chaos-mesh.org/v1alpha1
kind: PodChaos
metadata: {name: kill-order-api}
spec:
action: pod-kill
mode: one
selector: {namespaces: [prod], labelSelectors: {app: order-api}}
scheduler: {cron: "@every 6h"}
duration: "30s"# 应急手册自动化:一键采集现场
kubectl get pods -n prod -o wide > incident/pods.txt
kubectl logs -n prod -l app=order-api --tail=500 --since=10m > incident/logs.txt
kubectl top pods -n prod >> incident/pods.txt工程约束:演练从非生产→预发→生产低峰逐步推进;每次演练有假设、有观测指标、有结论;应急手册要可执行、可回滚,不能只有"检查一下"。
总结:云原生工程师的专业度不在"会运维集群",而在平台抽象藏复杂度、SLO量化可靠性、策略即代码治多集群、成本按团队分摊、故障演练常态化、应急可执行这六件事。能给别人讲清楚"为什么业务不该直接写Deployment""错误预算耗尽为什么冻结发布",你就站稳了这个岗位。觉得有用点赞收藏,需要完整工程目录留言。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。