K8s 1.36 新特性深度解析：服务网格与零信任集成（生产级配置）

前言：K8s 1.36 被称为“云原生安全网络里程碑”版本，核心突破集中在「服务网格原生化」和「零信任落地」两大板块——彻底解决了过去服务网格“资源占用高、配置复杂”、零信任“部署繁琐、易踩坑”的痛点，让中小企业也能轻松落地生产级安全架构。

本文全程不堆理论、不玩概念，只讲开发者能直接复用的实操步骤、可复制的YAML配置、生产环境避坑清单，适配CSDN阅读习惯，同时兼顾公众号格式，看完就能上手部署，无需额外查资料。

一、先搞懂：K8s 1.36 为什么要“集成服务网格+零信任”？

过去做服务网格（如Istio）+ 零信任，开发者要踩3个致命坑：

• Sidecar代理冗余：每个Pod都要注入Sidecar，内存占用增加200M+，集群规模大了直接拖垮性能[superscript:1]；

• 配置割裂：服务网格路由、零信任策略、网关规则分开配置，还要手动联动，容易出错；

• 门槛太高：需要同时掌握Istio、Ingress、安全策略等多种工具，中小企业没精力维护。

K8s 1.36 的核心解决思路：把服务网格、零信任能力“下沉到K8s原生层”，不用额外部署复杂组件，用原生API就能实现“高性能网格+零信任安全”，部署成本降低60%，运维效率提升一倍。

二、核心前提：K8s 1.36 环境准备（生产级适配）

先搞定基础环境，避免后续部署踩坑，以下步骤可直接复制执行，适配CentOS 8/9、Ubuntu 22.04（生产主流系统）：

1. 环境兼容性检查（必做）

# 1. 检查内核版本（要求≥5.4，推荐5.10+，否则不支持nftables/eBPF）
uname -r
# 2. 检查容器运行时（推荐containerd 1.7+，避免兼容问题）
containerd --version
# 3. 关闭冲突服务（nftables与firewalld不兼容，必须关闭）
systemctl stop firewalld && systemctl disable firewalld
# 4. 关闭SELINUX（生产环境常用配置，避免权限拦截）
setenforce 0
sed -i 's/^SELINUX=enforcing$/SELINUX=disabled/' /etc/selinux/config
# 5. 关闭swap（K8s强制要求，否则会导致调度异常）
swapoff -a
sed -i '/swap/s/^/#/' /etc/fstab

2. 升级/安装K8s 1.36（无宕机升级）

# 1. 升级kubeadm、kubelet、kubectl（以CentOS为例）
yum install -y kubeadm-1.36.0 kubelet-1.36.0 kubectl-1.36.0
# 2. 标记升级计划（不立即执行，先检查兼容性）
kubeadm upgrade plan v1.36.0
# 3. 执行升级（控制平面节点，无宕机）
kubeadm upgrade apply v1.36.0
# 4. 重启kubelet（所有节点）
systemctl daemon-reload && systemctl restart kubelet
# 5. 验证升级结果（出现Ready即成功）
kubectl get nodes
# 输出示例：STATUS为Ready，VERSION为v1.36.0

3. 核心组件安装（服务网格+零信任依赖）

# 1. 安装Gateway API CRD（K8s 1.36内置，直接启用）
kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.1.0/standard-install.yaml
# 2. 安装Istio 1.22+（兼容K8s 1.36，支持Ambient零Sidecar模式）
istioctl install --set profile=ambient --skip-confirmation
# 3. 安装监控工具（可选，用于验证服务网格/零信任效果）
kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.22/samples/addons/prometheus.yaml
kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.22/samples/addons/grafana.yaml

三、实操落地：服务网格+零信任 生产级部署（4步搞定）

重点讲解K8s 1.36 新增的「Gateway API GA」「Ambient零Sidecar网格」「原生零信任策略」三大核心功能，每一步都有可复制的YAML和命令，全程实操无理论。

1. 第一步：部署Gateway API（替代Ingress，服务网格入口）

K8s 1.36 中Gateway API 正式GA，彻底替代老旧的Ingress-Nginx，原生支持服务网格路由、多租户隔离，配置更简洁，性能提升40%[superscript:8]。

生产级配置（直接复制YAML，修改域名和证书即可）：

# 1. 创建生产级Gateway（南北流量入口，绑定SSL证书）
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: prod-gateway
  namespace: istio-system
spec:
  gatewayClassName: istio  # 对接Istio服务网格，必写
  listeners:
  - name: http
    port: 80
    protocol: HTTP
    allowedRoutes:
      namespaces:
        from: All  # 允许所有命名空间路由（生产可限制为指定命名空间）
    # HTTP自动跳转HTTPS（生产必配，提升安全性）
    tls:
      mode: RedirectToHTTPS
  - name: https
    port: 443
    protocol: HTTPS
    tls:
      mode: Terminate
      certificateRefs:
      - name: prod-tls-cert  # 提前创建的SSL证书Secret（替换为你的证书名）
        kind: Secret
    allowedRoutes:
      namespaces:
        from: Selector
        selector:
          matchLabels:
            env: production  # 仅允许生产环境路由

# 2. 应用Gateway配置
kubectl apply -f prod-gateway.yaml
# 3. 验证Gateway状态（READY=True即成功）
kubectl get gateways -n istio-system
# 4. 创建HTTPRoute（服务路由，替代Istio VirtualService）
kubectl apply -f - << EOF
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: order-service-route
  namespace: microservices  # 替换为你的业务命名空间
spec:
  parentRefs:
  - name: prod-gateway
    namespace: istio-system
  hostnames: ["order.xxx.com"]  # 替换为你的业务域名
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /api/v1/order
    backendRefs:
    - name: order-service
      port: 8080
EOF
# 5. 验证路由（出现200即成功）
curl -I https://order.xxx.com/api/v1/order

避坑提示：必须指定「gatewayClassName: istio」，否则Gateway无法对接服务网格，流量会直接穿透，无法实现路由管控和零信任验证[superscript:8]。

2. 第二步：部署Ambient零Sidecar网格（资源占用降70%）

这是K8s 1.36 + Istio 1.22 的核心优化：无需为每个Pod注入Sidecar，用ztunnel（轻量代理）替代，资源占用降低70%，延迟降低30%，老业务无需改造即可接入[superscript:1]。

# 1. 为业务命名空间开启Ambient模式（替代Sidecar注入）
kubectl label namespace microservices istio.io/dataplane-mode=ambient
# 2. 部署测试业务Pod（验证零Sidecar效果）
kubectl apply -f - << EOF
apiVersion: apps/v1
kind: Deployment
metadata:
  name: order-service
  namespace: microservices
spec:
  replicas: 3
  selector:
    matchLabels:
      app: order-service
  template:
    metadata:
      labels:
        app: order-service
    spec:
      containers:
      - name: order-service
        image: nginx:alpine  # 替换为你的业务镜像
        ports:
        - containerPort: 8080
EOF
# 3. 验证零Sidecar（无istio-proxy容器即成功）
kubectl get pods -n microservices
# 输出示例：只有order-service容器，无istio-proxy

关键优势：ztunnel 统一管理服务间通信，自动实现mTLS加密、流量管控，不用再手动配置Sidecar注入规则，运维成本直接减半。

3. 第三步：配置原生零信任策略（拒绝所有，精准放行）

K8s 1.36 联合Istio，将零信任能力下沉到原生API，实现“默认拒绝所有流量，按需精准放行”，彻底解决内部横向攻击问题[superscript:1]。

生产级零信任配置（直接复制，修改服务名称即可）：

# 1. 全局开启mTLS（所有服务间通信强制加密，生产必开）
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: istio-system
spec:
  mtls:
    mode: STRICT  # 严格模式：拒绝非mTLS请求
  selector: {}  # 作用于所有命名空间

# 2. 默认拒绝所有流量（零信任核心：先拒绝，再放行）
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: deny-all
  namespace: microservices
spec:
  selector:
    matchLabels:
      app: order-service  # 目标服务（替换为你的服务标签）
  action: DENY
  rules:
  - from:
    - any: true  # 拒绝所有来源

# 3. 精准放行（仅允许payment-service调用指定接口）
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: allow-payment-to-order
  namespace: microservices
spec:
  selector:
    matchLabels:
      app: order-service
  action: ALLOW
  rules:
  - from:
    - source:
        principals: ["cluster.local/ns/microservices/sa/payment-service-sa"]  # 服务身份（替换为你的ServiceAccount）
    to:
    - operation:
        methods: ["POST", "GET"]  # 允许的HTTP方法
        paths: ["/api/v1/order", "/api/v1/order/list"]  # 允许的接口路径

# 应用零信任策略
kubectl apply -f zero-trust-policy.yaml
# 验证策略效果（未授权访问会返回403）
# 1. 未授权Pod访问（预期返回403）
kubectl run -it --rm test-pod --image=busybox -n microservices -- wget -qO- order-service:8080/api/v1/order
# 2. 授权Pod访问（预期返回200）
kubectl run -it --rm payment-test --image=busybox -n microservices --serviceaccount=payment-service-sa -- wget -qO- order-service:8080/api/v1/order

4. 第四步：验证与监控（生产级必做）

# 1. 验证mTLS加密（出现TLS=true即成功）
istioctl pc peers $(kubectl get pods -n microservices -l app=order-service -o jsonpath='{.items[0].metadata.name}') -n microservices
# 2. 查看零信任策略执行日志（确认拒绝/放行记录）
kubectl logs -n istio-system -l app=ztunnel | grep "authorization"
# 3. 查看服务网格监控（Grafana看板，默认端口3000）
kubectl port-forward -n istio-system svc/grafana 3000:3000
# 访问http://localhost:3000，查看服务流量、mTLS覆盖率、授权规则执行情况

四、生产级避坑清单（K8s 1.36 专属，踩过的坑全总结）

• 避坑1：CentOS 7 内核低于5.4，无法启用nftables，导致kube-proxy启动失败 → 解决方案：升级内核到5.10+，或切换为eBPF模式（Cilium）[superscript:7]。

• 避坑2：Gateway API 未指定gatewayClassName: istio，导致路由不生效 → 解决方案：修改Gateway YAML，添加gatewayClassName字段，重启Gateway。

• 避坑3：Ambient模式下，ztunnel 缺少NET_ADMIN权限，导致无法转发流量 → 解决方案：给Istio的ServiceAccount添加NET_ADMIN权限，重启ztunnel。

• 避坑4：零信任策略顺序错误（先放行后拒绝），导致策略失效 → 解决方案：先部署deny-all策略，再部署allow策略，顺序不能颠倒。

• 避坑5：升级K8s 1.36后，cgroup v2 兼容性问题，导致Pod OOM → 解决方案：升级JDK/应用依赖到支持cgroup v2的版本，或临时切回cgroup v1[superscript:6]。

• 避坑6：Istio 版本低于1.22，无法兼容K8s 1.36 Ambient模式 → 解决方案：升级Istio到1.22+，安装时指定profile=ambient。

五、总结：K8s 1.36 服务网格+零信任 落地价值

对开发者/企业来说，K8s 1.36 不是“小版本迭代”，而是“安全网络现代化”的分水岭：

1. 成本降低：零Sidecar网格减少70%资源占用，不用采购高端服务器；

2. 效率提升：Gateway API 统一入口，零信任策略一键部署，运维效率提升一倍；

3. 安全可控：默认拒绝所有流量，mTLS强制加密，彻底解决内部横向攻击，符合等保合规要求[superscript:1]；

4. 易上手：原生API配置，不用再学习多种工具，中小企业也能轻松落地生产级安全架构。

下一步：按本文步骤部署，2小时内即可完成服务网格+零信任落地，后续可结合Prometheus+Grafana实现监控告警，进一步提升集群安全性和可观测性。

结尾互动

你在K8s 1.36 部署服务网格时，遇到过哪些坑？Ambient零Sidecar模式是否解决了你的资源占用难题？评论区留言交流。