From V

以下内容转载自 https://www.v2ex.com/t/968514#r_13557021

k8s 这个东西真的内容太多了，没有啥系统性的资料，里面各种知识点真的没法说，太多了，最好的就是看官方文档，并且结合工作当中的实践慢慢积累，才能由浅入深，只是看文档想掌握深点，个人感觉很困难。

如果你不是专做这行，只是把它当作你应用部署的底层平台的话可以给你个简单的流程做参考：
1 、云服务商买一套，或者自己搭建个 k8s 环境
2 、运行起来一套简单的前后端分离服务，这里主要练习的是多个镜像启动多个不同的 workload ，然后怎么能互相访问对接，这个环节能掌握清楚 workload service ingress 都是干嘛的，该怎么用，怎么关联
3 、你会发现当你测试环境发生重启，或者 pod 重建后，数据库数据都没了，这会你就应该研究数据持久化了，pv pvc 的概念就出来了
5 、然后你又创建了个前端服务，想修改个前端页面的配置文件参数，比如网页的 title ，其他都一模一样，但是每个服务一个镜像，太麻烦了，容器里直接修改，重建就没了，配置文件放 pv pvc ，太小题大做，这会 configmap 出现了。连接数据库的配置文件，密钥明文，太 low 了，secret 出现了
6 、前端页面镜像有 bug ，必须要重打镜像了，cicd 出现了，你是选择 docker build 还是 jenkins ，新的知识又增加了
7 、更新 workload 的镜像，问题又来了，服务会不会受损，多副本就不会受损吗？如何优雅终止，健康检查，无损更新？
8 、服务高峰期怎么应对，手动扩副本数太傻，hpa 来了

如果你想深点，做些 k8s 运维或者技术支持的，那么除了上面的必须熟悉，下面的东西必知必会
1 、清楚 k8s 的工作逻辑，master 的三大件是干嘛的，kubelet ，kube-proxy ，coredns 都是干嘛的，比如执行个创建或查询一个 workload ，系统组件之间怎么通讯的，创建一个 pod 后，容器网络和外界是怎么打通的，k8s 资源调度和分配逻辑是什么
2 、自己搭建一套 k8s 集群，多 master 的最好，master 和 worker 节点分开（一定是自己搭建，不要购买云服务商现成的容器服务，自己搭建过程你会收获不少东西）
3 、熟练使用 kubectl 命令进行各种查询分析
4 、清楚 rbac 的功能和使用

剩下的太多太多了，说不完了，
等你发现 k8s 了解差不多了，发现总得有个监控吧，prometheus 出现了
流量治理，服务分析也得有吧，istio 来了
日志得持久化保存下吧，els 来了
学了那么多了，得给老板展示下漂亮帅气的监控吧，得研究 grafana 了。
服务都上 k8s 了，集群越来越重要，万一哪天 etcd 崩了怎么办，备份总得有吧，etcd 原理和备份恢复得研究下吧。
想自建镜像仓库了？ harbor 研究下。
这个云平台太贵了，业务想换个云平台，集群要迁移，velero 走起
想给 pod 限速了，想给集群加审计了。。。。

References

• https://www.v2ex.com/t/968514#r_13557021

demo ingress

这个实例中，实现将 访问 https://image.frytea.com/Avatar.jpg 请求302到 https://image.frytea.com/i/Avatar.jpg

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app
  namespace: imagehost
  annotations:
    cert-manager.io/cluster-issuer: "dnspod-cluster-issuer"
    nginx.ingress.kubernetes.io/configuration-snippet: |
      location = /Avatar.jpg {
        return 301 https://image.frytea.com/i/Avatar.jpg$is_args$args;
      }
spec:
  ingressClassName: nginx
  tls:
  - hosts:
      - image.frytea.com
      - imagehost-cdn.frytea.com
      - cdn-imagehost.frytea.com
    secretName: image-frytea-com-tls
  rules:
  - host: image.frytea.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: app
            port:
              name: web

直接配置会提示报错：

➜  imagehost git:(main) ✗ kubectl apply -f ingress.yaml  
Error from server (BadRequest): error when applying patch:  
{"metadata":{"annotations":{"kubectl.kubernetes.io/last-applied-configuration":"{\"apiVersion\":\"networking.k8s.io/v1\",\"kind\":\"Ingress\",\"metadata\":{\"annotati  
ons\":{\"cert-manager.io/cluster-issuer\":\"dnspod-cluster-issuer\",\"nginx.ingress.kubernetes.io/configuration-snippet\":\"location = /Avatar.jpg {\\n  return 301 ht  
tps://image.frytea.com/i/Avatar.jpg$is_args$args;\\n}\\n\"},\"name\":\"app\",\"namespace\":\"imagehost\"},\"spec\":{\"ingressClassName\":\"nginx\",\"rules\":[{\"host\  
":\"image.frytea.com\",\"http\":{\"paths\":[{\"backend\":{\"service\":{\"name\":\"app\",\"port\":{\"name\":\"web\"}}},\"path\":\"/\",\"pathType\":\"Prefix\"}]}},{\"ho  
st\":\"imagehost-cdn.frytea.com\",\"http\":{\"paths\":[{\"backend\":{\"service\":{\"name\":\"app\",\"port\":{\"name\":\"web\"}}},\"path\":\"/\",\"pathType\":\"Prefix\  
"}]}},{\"host\":\"cdn-imagehost.frytea.com\",\"http\":{\"paths\":[{\"backend\":{\"service\":{\"name\":\"app\",\"port\":{\"name\":\"web\"}}},\"path\":\"/\",\"pathType\  
":\"Prefix\"}]}}],\"tls\":[{\"hosts\":[\"image.frytea.com\",\"imagehost-cdn.frytea.com\",\"cdn-imagehost.frytea.com\"],\"secretName\":\"image-frytea-com-tls\"}]}}\n",  
"nginx.ingress.kubernetes.io/configuration-snippet":"location = /Avatar.jpg {\n  return 301 https://image.frytea.com/i/Avatar.jpg$is_args$args;\n}\n","nginx.ingress.k  
ubernetes.io/rewrite-rule":null}}}  
to:  
Resource: "networking.k8s.io/v1, Resource=ingresses", GroupVersionKind: "networking.k8s.io/v1, Kind=Ingress"  
Name: "app", Namespace: "imagehost"  
for: "ingress.yaml": error when patching "ingress.yaml": admission webhook "validate.nginx.ingress.kubernetes.io" denied the request: annotation group ConfigurationSn  
ippet contains risky annotation based on ingress configuration

这个错误来自于 Nginx Ingress Controller 自带的一个叫做 “Admission Webhook” 的安全校验机制。它的作用是在你创建或更新 Ingress 资源时进行检查，防止应用不安全或可能导致问题的配置。 很多 Nginx Ingress Controller 的默认安装配置或者管理员策略会禁用或限制 configuration-snippet 和 server-snippet 这类强大的注解

开启 Snippet 注释

使用 helm 部署的 nginx-ingress ，首先修改 Values.yaml 中的内容，启动

controller:
  allowSnippetAnnotations: true

将配置应用到集群：

helm upgrade --install ingress-nginx ingress-nginx  \
    --repo https://kubernetes.github.io/ingress-nginx  \
    --namespace ingress-nginx --create-namespace -f vaules.yaml

之后调整 ConfigMap

kubectl -n ingress-nginx edit cm ingress-nginx-controller

增加两行：

...
apiVersion: v1
data:
  allow-snippet-annotations: "true"
  annotations-risk-level: Critical
  use-forwarded-headers: "true"
kind: ConfigMap
...

其中 ：

• annotations-risk-level: Critical: 设置 Webhook 接受的最高风险门槛，确保 Snippets（作为 Critical 风险注解）在被评估时不会因为风险等级过高而被直接拒绝，从而让 allow-snippet-annotations 的设置能够生效
• use-forwarded-headers: "true": 告诉 Nginx Ingress Controller 信任并使用由其上游代理（通常是你的云服务商提供的负载均衡器，如 AWS ELB/ALB/NLB, GCP Load Balancer, Azure Load Balancer 等）设置的 X-Forwarded-* 或 Forwarded HTTP 头部信息，来确定原始客户端的真实信息

再重启所有 nginx controller

kubectl rollout restart -n ingress-nginx daemonset ingress-nginx-controller

之后在尝试 apply 上面的 demo 就可以成功了。

References

• Admission Controller Error with allowSnippetAnnotations: true #12648
• Gemini 2.5 Pro

下面介绍更新 Deployment 以重新拉取相同标签镜像的方法，不要只会杀 pod 触发了，个人最喜欢方法二。

当镜像名称和标签都没有变化，但需要重新拉取镜像时（比如镜像内容已更新但标签保持不变），可以采用以下方法：

方法一：修改 Pod 模板以触发重新部署

为 Deployment 的 Pod 模板添加或更新一个注释（annotation）来触发滚动更新：

kubectl patch deployment [deployment-name] -p \
  "{\"spec\":{\"template\":{\"metadata\":{\"annotations\":{\"kubectl.kubernetes.io/restartedAt\":\"$(date +%s)\"}}}}}"

这会添加或更新一个时间戳注释，使 Kubernetes 认为 Pod 模板已更改，从而触发重新部署。

方法二：强制重启 Deployment

kubectl rollout restart deployment/[deployment-name]

这是 Kubernetes 1.15 及更高版本提供的便捷命令，效果与方法一类似。

方法三：修改 imagePullPolicy

确保容器的 imagePullPolicy 设置为 Always，这样每次 Pod 重启都会重新拉取镜像：

kubectl patch deployment [deployment-name] -p '{"spec":{"template":{"spec":{"containers":[{"name":"[container-name]","imagePullPolicy":"Always"}]}}}}'

设置后，可以使用方法一或方法二触发重新部署。

方法四：删除 Pod（不推荐）

手动删除 Pod，让 Deployment 控制器创建新的 Pod：

kubectl delete pod -l app=[your-app-label]

注意： 此方法不推荐用于生产环境，因为它可能导致服务中断。

最佳实践建议

1. 始终使用唯一标签：最好的做法是为每个新版本的镜像使用唯一标签，如使用 Git commit SHA 或时间戳。

2. 设置 Always 拉取策略：在 Deployment 中设置：

   spec:
     template:
       spec:
         containers:
         - name: your-container
           image: your-image:tag
           imagePullPolicy: Always

3. 对于生产环境：推荐使用前两种方法（添加注释或使用 rollout restart），它们符合 Kubernetes 的声明式设计理念，并且会进行受控的滚动更新。

使用 kubectl rollout restart deployment/[deployment-name] 是最简单且符合 Kubernetes 最佳实践的方式。