findscripter 服务网格架构（Istio/Linkerd）
何时使用
当需要在 Kubernetes 上端到端规划与落地服务网格时使用——重点是架构层面的决策与编排，而不是写某一条配置。典型场景：
- 微服务间通信的整体方案设计：网格选型（Istio vs Linkerd）、Sidecar/Ambient 模式、注入范围。
- 零信任网络：以 mTLS 为基础的服务身份与授权（PeerAuthentication / AuthorizationPolicy）。
- 多集群 / 多云网格联邦与跨集群服务发现。
- 渐进式交付（金丝雀、蓝绿、流量切分）的网格侧编排。
- 接入可观测性（指标、分布式追踪、日志）并沉淀运维手册（runbook）。
- 排查网格连通性、mTLS 握手、Sidecar 注入等问题。
不该用的边界：
- 任务与服务网格无关，或属于其他领域/工具范畴。
- 只是要写某一条 Istio 资源（VirtualService / DestinationRule / Gateway）——改用更聚焦的
istio-traffic-management。 - 问题在应用层业务逻辑、而非网络/网格层。
- 缺少必需输入（集群访问、网格版本、流量/合规需求、成功标准）时，先停下来澄清，不要臆造。
步骤
- 评估现状与需求：盘点集群拓扑、服务清单、现有 Ingress/网络、合规与延迟预算；明确目标（零信任？多集群？灰度？）。
- 设计网格拓扑与流量策略：定网格产品与部署模式、命名空间隔离边界、入口/出口网关、DestinationRule 负载均衡策略。
- 落地安全策略：先
PERMISSIVE模式灰度，再逐步收紧到STRICTmTLS；按命名空间编写 AuthorizationPolicy 做最小授权。 - 接入可观测性：指标（Prometheus）、分布式追踪、访问日志三者齐备，建立网格开销（延迟、资源）基线。
- 配置流量管理：路由、超时、重试、熔断（在需要前就配好），按需做流量切分支撑金丝雀。
- 测试故障转移与韧性：注入故障、断网演练，验证熔断/重试/降级行为。
- 沉淀运维手册：把回滚、扩缩、证书轮换、常见故障排查写成 runbook。
指令
- 先澄清目标、约束与必需输入，再动手；产出给出可执行步骤与验证命令。
- 渐进收紧安全：mTLS 从 permissive 起步，确认全链路再切 strict，避免一刀切打断存量流量。
- 以命名空间做策略隔离单元，授权遵循最小权限。
- 熔断器要前置：在故障发生前就配置好，而非事后补救。
- 持续监控网格开销：Sidecar 的延迟与资源占用要纳入基线，Sidecar 资源请求/限制要按实际调优。
- 用 DestinationRule 统一负载均衡策略，保证一致性。
- 多集群联邦先打通信任域与根 CA，再做跨集群服务发现。
- 输出的 YAML 必须可被
istioctl analyze/linkerd check验证通过。
示例
严格 mTLS（命名空间级，先 permissive 后 strict）：
apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
name: default
namespace: payments
spec:
mtls:
mode: STRICT # 灰度期先用 PERMISSIVE
最小授权（只允许 frontend 调用 payments）：
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
name: payments-allow-frontend
namespace: payments
spec:
selector:
matchLabels: { app: payments }
action: ALLOW
rules:
- from:
- source:
principals: ["cluster.local/ns/web/sa/frontend"]
验证命令：
istioctl analyze -n payments # Istio：静态校验配置
istioctl proxy-config secret <pod> # 确认 mTLS 证书已下发
linkerd check # Linkerd：健康与配置自检
linkerd viz stat deploy -n payments # 网格侧实时指标
提示：流量切分做金丝雀时，先用 DestinationRule 定义 subset，再由 VirtualService 按权重切流；具体 YAML 编写下钻到
istio-traffic-management。
注意事项
- 仅在任务明确落入上述范围时使用本技能；产出不能替代环境相关的验证、测试或专家评审。
- 若缺少必需输入、权限、安全边界或成功标准，停下来询问澄清。
- Sidecar 注入会引入额外延迟与资源开销，性能敏感链路需评估 Ambient 模式或排除注入。
- mTLS 切
STRICT前务必确认网格外调用方（如旧服务、探针、外部 LB）已纳管或显式放行，否则会断流。 - 多集群联邦的信任域、证书与网络连通是前置硬条件，配置复杂、回滚成本高，务必先在非生产环境演练。
互见
- related：
istio-traffic-management—— 网格内具体流量/安全 YAML 的聚焦写法（本技能管架构，它管单条配置）。 - related：
kubernetes-architect—— 网格所在的 K8s 平台与集群架构。 - related：
microservices-patterns—— 网格承载的微服务通信与拆分模式。 - related：
distributed-tracing—— 网格可观测性中的链路追踪落地。 - related：
k8s-security-policies—— 与网格授权互补的集群安全策略。 - combines_with：
gitops-argocd-flux—— 用 GitOps 编排渐进式交付与网格配置发布。 - combines_with：
observability-strategy-designer—— 设计网格的指标/日志/追踪整体策略。 - combines_with：
helm-chart-scaffolding—— 以 Helm 打包网格组件与策略清单。
采编自 sickn33/antigravity-awesome-skills（MIT）。