containers:
  - name: order
    image: shop/order:v1.2
    # ① 启动探针：给慢启动一个保护期，通过前另两个探针不生效
    startupProbe:
      httpGet: { path: /healthz, port: 8080 }
      failureThreshold: 30      # 最多等 30 次 × 5s = 150 秒启动
      periodSeconds: 5
    # ② 就绪探针：没就绪就不接流量（从 Service Endpoints 摘除）
    readinessProbe:
      httpGet: { path: /readyz, port: 8080 }
      periodSeconds: 5
      failureThreshold: 3       # 连续 3 次失败才摘除
    # ③ 存活探针：卡死了重启我。注意——只探自己，别探数据库！
    livenessProbe:
      httpGet: { path: /healthz, port: 8080 }
      periodSeconds: 10
      failureThreshold: 3

resources:
  requests:            # 调度按这个预留，也是被驱逐时的"护身符"
    cpu: "250m"
    memory: "256Mi"
  limits:              # 上限：CPU 超了限流，内存超了 OOMKill
    cpu: "500m"
    memory: "512Mi"

spec:
  terminationGracePeriodSeconds: 30
  initContainers:
    - name: wait-db                    # 主容器起之前，先等数据库通
      image: busybox:1.36
      command: ['sh','-c','until nc -z mysql 3306; do sleep 2; done']
  containers:
    - name: order
      image: shop/order:v1.2
      lifecycle:
        preStop:
          exec:
            # 先睡几秒，等 Endpoints 摘除传播到所有节点，再让应用退出
            command: ['sh','-c','sleep 5']

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata: { name: order }
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: order
  minReplicas: 2
  maxReplicas: 20
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 60   # 目标：平均 CPU 用到 requests 的 60%

spec:
  # 同一应用的副本尽量分到不同节点（软反亲和）
  affinity:
    podAntiAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
        - weight: 100
          podAffinityTerm:
            labelSelector: { matchLabels: { app: order } }
            topologyKey: kubernetes.io/hostname
  # 按可用区均匀铺，最多差 1 个
  topologySpreadConstraints:
    - maxSkew: 1
      topologyKey: topology.kubernetes.io/zone
      whenUnsatisfiable: DoNotSchedule
      labelSelector: { matchLabels: { app: order } }
  # 容忍 GPU 节点的污点（否则上不去）
  tolerations:
    - key: "nvidia.com/gpu"
      operator: "Exists"
      effect: "NoSchedule"

apiVersion: v1
kind: ResourceQuota
metadata: { name: team-a-quota, namespace: team-a }
spec:
  hard:
    requests.cpu: "20"        # 这个 ns 所有 Pod 的 requests 总和上限
    requests.memory: 40Gi
    limits.cpu: "40"
    pods: "50"
---
apiVersion: v1
kind: LimitRange
metadata: { name: team-a-defaults, namespace: team-a }
spec:
  limits:
    - type: Container
      default: { cpu: "500m", memory: 512Mi }        # 没写 limits 时的默认
      defaultRequest: { cpu: "100m", memory: 128Mi }  # 没写 requests 时的默认

apiVersion: v1
kind: ServiceAccount
metadata: { name: reader-sa, namespace: team-a }
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role                    # 只在 team-a 这个 ns 内有效
metadata: { name: pod-reader, namespace: team-a }
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "list", "watch"]   # 只读，不给 delete/create
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding             # 把 pod-reader 角色绑给 reader-sa
metadata: { name: bind-reader, namespace: team-a }
subjects:
  - kind: ServiceAccount
    name: reader-sa
roleRef: { kind: Role, name: pod-reader, apiGroup: rbac.authorization.k8s.io }

# Pod spec 里指定用哪个 SA（不指定就是 ns 的 default SA）
spec:
  serviceAccountName: reader-sa
  automountServiceAccountToken: false   # 不需要访问 API 的 Pod，干脆别挂 token
---
# 排查权限神器：我（或某个 SA）到底能不能做某件事？
# kubectl auth can-i delete pods --as=system:serviceaccount:team-a:reader-sa

# ① 本 ns 默认拒绝所有入站（一旦有这条，未被放行的入站全断）
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata: { name: default-deny-ingress, namespace: shop }
spec:
  podSelector: {}          # 选中本 ns 所有 Pod
  policyTypes: ["Ingress"]
---
# ② 只放行：带 app=frontend 的 Pod → 访问 app=backend 的 8080
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata: { name: allow-frontend-to-backend, namespace: shop }
spec:
  podSelector: { matchLabels: { app: backend } }
  policyTypes: ["Ingress"]
  ingress:
    - from:
        - podSelector: { matchLabels: { app: frontend } }
      ports:
        - { protocol: TCP, port: 8080 }

# 用 prod 的值安装或升级（--install：没装过就装，装过就升级）
helm upgrade --install order ./order-chart -f values-prod.yaml

# 只改个别值
helm upgrade order ./order-chart --set image.tag=v1.3 --set replicaCount=5

# 上线前先渲染成纯 YAML 看看它到底会生成什么（读别人 chart 的利器）
helm template order ./order-chart -f values-prod.yaml

# 看历史、一键回滚到上一个版本
helm history order
helm rollback order 3

helm list                 # 当前集群装了哪些 Release
helm uninstall order      # 卸载

# overlays/prod/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
  - ../../base            # 引入基础 manifests
replicas:
  - name: order
    count: 5              # base 里是 2，prod 覆盖成 5
images:
  - name: shop/order
    newTag: v1.3          # 覆盖镜像 tag
patches:
  - path: prod-resources.yaml   # 用补丁改 resources 等更复杂的字段

kubectl apply -k overlays/prod       # 直接应用 prod overlay
kubectl kustomize overlays/prod      # 只渲染出最终 YAML 看看（不 apply）

git checkout -b bump-order-v1.3          # ① 开分支
# ② 改配置库里的 values / manifests（比如把 image tag 改成 v1.3）
git commit -am "order: v1.2 -> v1.3"
git push origin bump-order-v1.3          # ③ 推分支
# ④ 开 Pull Request，CI 自动校验（lint / diff / 策略检查）
# ⑤ 同事 review 通过 → 合并到 main
# ⑥ Argo CD 检测到 Git 变了 → 自动同步进集群 → 在 Argo UI 看健康状态
# 出问题？git revert 那个 commit，Argo 自动把集群同步回旧版本

# 往正在跑的 Pod 注入一个带工具的临时容器（不用改镜像）
kubectl debug -it order-xxx --image=busybox --target=order

# 把文件从容器里捞出来
kubectl cp shop/order-xxx:/app/logs/err.log ./err.log

# 用 kubectl 生成 YAML 模板（不真的创建），改改再 apply
kubectl create deploy demo --image=nginx --dry-run=client -o yaml > demo.yaml

# 查某个字段怎么写
kubectl explain deployment.spec.strategy

func Reconcile(req) {
  cr := get(req)                 // 读期望状态（我的 CRD 对象）
  if cr.deleting {               // 处理删除：先跑 finalizer 清理外部资源
    cleanupExternal(); removeFinalizer(cr); return
  }
  want := cr.spec.replicas       // 期望
  have := countPods(cr)          // 实际（从 Lister 缓存读）
  if have < want { create(want - have) }   // 缺就补
  if have > want { delete(have - want) }    // 多就删
  cr.status.ready = have; update(cr.status) // 把实际写回 status
  // 返回后，任何新变更会再次触发 Reconcile —— 这就是调谐循环
}