service-mesh-expert
使用 Istio 和 Linkerd 设计服务网格架构
微服务需要安全、可观测的通信而不引入复杂性。本技能提供关于 Istio 和 Linkerd 部署的专家指导，包括零信任网络和流量管理。
下载技能 ZIP
在 Claude 中上传
前往 设置 → 功能 → 技能 → 上传技能
开启并开始使用
测试它
正在使用“service-mesh-expert”。 请求 mTLS 配置
预期结果:
PeerAuthentication 和 DestinationRule 配置的逐步说明，用于在整个集群范围内强制执行严格的 mTLS，从 permissive 模式迁移路径开始，并提供验证命令以确认加密。
正在使用“service-mesh-expert”。 调试服务连接问题
预期结果:
系统化的故障排除清单，包括 sidecar 注入验证、VirtualService 路由分析、授权策略冲突以及带有预期输出的 istioctl 调试命令。
安全审计
安全Static analysis flagged 4 patterns that are all false positives. Line 22 uses Markdown backticks for documentation reference, not shell execution. Lines 3, 46, and 60 contain no cryptographic code - they reference mTLS conceptually in documentation. This is a markdown-only skill with no executable code, external commands, or security risks.
质量评分
你能构建什么
Kubernetes 平台工程师
为处理高可用性要求的生产微服务平台部署 Istio 服务网格，包含 mTLS 强制执行和流量策略。
DevOps 团队负责人
使用 Istio VirtualService 和 DestinationRule 配置实现带有流量拆分和自动回滚的金丝雀部署。
安全架构师
设计零信任网络架构，在所有命名空间中使用 mTLS 和 AuthorizationPolicy 强制执行服务间身份验证。
试试这些提示
帮我在 Kubernetes 集群上设置 Istio 服务网格。我有 3 个命名空间（dev、staging、prod），需要在服务之间使用基本的 mTLS。安装步骤和初始配置是什么？
我需要将 90% 的流量路由到 version-1，10% 的流量路由到 version-2 的支付服务。创建 Istio VirtualService 和 DestinationRule YAML 配置并附带解释。
为我的订单服务设计熔断器配置以优雅地处理上游故障。包括使用 Istio 的连接池设置、异常检测和重试策略。
规划跨 AWS EKS 和 GCP GKE 的多集群 Istio 网格。包括跨集群服务发现、证书管理以及两个网格之间的流量联合的要求。
最佳实践
- 从 PERMISSIVE mTLS 模式开始，在验证所有服务正常通信后逐步迁移到 STRICT
- 在生产部署之前实施熔断器和重试策略，而不是在故障发生后
- 使用命名空间级别的策略隔离，为每个环境应用不同的安全和流量规则
避免
- 在未先在 permissive 模式下测试的情况下在整个集群范围内启用严格 mTLS - 会导致立即的服务中断
- 假设服务可靠而跳过熔断器配置 - 在负载下会发生级联故障
- 未监控实际 CPU 和内存使用率就过度配置 sidecar 资源 - 不必要地增加成本