1. 基本信息
| 项目 | 内容 |
|---|---|
| 名称 | GKE Service Networking |
| 作者/维护者 | Google(google/skills 仓库) |
| 来源链接 | https://github.com/google/skills/tree/main/skills/cloud/gke-service-networking |
| 许可证 | Apache-2.0(数据来源:GitHub API) |
| GitHub Stars | 18,276(数据来源:GitHub API;该数字属整个 google/skills 合集仓库,不代表本技能自身热度) |
| Forks | 1,443(同上,合集整体数据) |
| 最新版本 | 仓库不发布正式 release,持续滚动更新;本技能目录最近一次提交为 2026-07-24(数据来源:GitHub API) |
| 安装方式 | npx skills add google/skills 交互式勾选安装,或手动复制 skills/cloud/gke-service-networking/ 目录到 agent 的 skills 目录 |
2. 功能介绍与亮点
GKE Service Networking 聚焦把运行在 Google Kubernetes Engine 上的应用安全暴露到互联网或内部网络,覆盖六类工作流:
- Gateway API 路由:给出
Gateway与HTTPRoute的完整清单示例,标注为官方推荐的现代路由方式。 - 标准 Ingress:面向简单场景或存量遗留配置的传统
Ingress清单写法。 - Cloud Armor 防护:通过
BackendConfig引入安全策略并关联到 Service,提供 WAF / DDoS 防护。 - Google 托管 SSL 证书:区分传统 Ingress 的
ManagedCertificate与 Gateway API 下 Certificate Manager 的CertificateMap两条配置路径,均为自动签发续期,免去手工证书管理。 - 容器原生负载均衡:说明 Network Endpoint Groups(NEG)如何让负载均衡器直接定位到 Pod 而非节点,并给出
cloud.google.com/neg注解的使用方式。 - Private Service Connect(PSC):不经 VPC 对等互联,把服务安全暴露给另一个 VPC 中的消费方,给出
ServiceAttachment清单示例。
亮点:
- 六个高频场景各配一份可直接套用的 YAML 清单,从路由、Ingress、WAF、证书到内网服务暴露一次性覆盖,正文末尾另附四条最佳实践(优先用 Gateway API、公网端点必开 Cloud Armor、证书交给 Google 托管、负载均衡默认走 NEG)。
- 在 description 里明确划清与同合集
gke-networking的边界(核心集群 IP 规划、Dataplane V2 网络策略、节点 NAT 出网走gke-networking,本技能只管边缘暴露与流量路由),避免用户在两个技能之间选错入口。 - 同时覆盖新旧两代路由方案:Gateway API(官方推荐路线)与传统 Ingress 并列给出,处于迁移过渡期的存量集群也能直接照抄配置。
3. 适用场景
固定分类:DevOps 与基础设施。
适用于负责把 GKE 上的应用对外或对内暴露的团队:需要配置 Gateway/Ingress 路由、给公网端点加 WAF 防护、管理 SSL 证书续期、或跨 VPC 安全暴露内部服务时,可按对应工作流直接套用清单模板。受益人群为 GKE 平台的网络工程师、SRE 与负责服务上线的后端团队。
4. 跨 Agent 兼容性
- Claude Code:原生支持——SKILL.md 遵循标准 Agent Skills 格式,仓库同时提供
npx skills add通用安装与claude plugin marketplace add google/skills插件市场两种途径。 - Codex:原生支持——仓库 README 明确列出
codex plugin marketplace add google/skills安装路径。 - OpenClaw:未验证——未见到针对该 agent 的专门说明。
- Hermes Agent:未验证——未见到针对该 agent 的专门说明。
5. 推荐理由
它把“把 GKE 服务安全暴露出去”这件几乎每个生产应用都躲不开的事,从路由、WAF、证书到跨 VPC 暴露一次性打包成六份可直接套用的清单,且在技能描述里就讲清了和同合集 gke-networking(集群内网 IP 规划)的边界,用户不用先猜“这次该找哪个技能”。四条最佳实践(Gateway API 优先、公网端点必开 Cloud Armor、证书交给 Google 托管、负载均衡走 NEG)把容易被忽略的安全默认项直接摆在配置流程里,而不是留给用户自己想起来。
6. 评分
| 维度 | 分数 | 说明 |
|---|---|---|
| 受欢迎程度 | 7 | 发布方 Google 为一线云厂商,属官方出品,受欢迎程度不低于 7 分的保底档;google/skills 合集仓库 18,276 星不计入单个子技能,本技能自身暂无独立第三方讨论证据 |
| 可用性 | 9 | SKILL.md 单文件即为完整安装单元,六个工作流均配可直接使用的 YAML 示例;技能目录最近一次提交在近 3 个月内;不依赖任何外部 MCP 服务器或付费组件,kubectl/gcloud 命令行工具即可完整使用 |
| 安全性 | 9 | 全部内容开源可审计(Apache-2.0);正文只给出配置指导与 YAML 示例,不含随附可执行脚本;未见外发或权限越界迹象 |
安全检查清单:
| 检查项 | 结果 |
|---|---|
| ① Shell 命令执行范围 | 无独立脚本;正文示例命令限于 kubectl apply 等标准操作,作用范围与技能声明的网络配置功能一致 |
| ② 运行时联网外发 | 无独立外发;清单应用后的流量走用户自己的 GCP 项目与集群 |
| ③ API key/凭据 | 复用用户本机已有的 gcloud/kubectl 认证态,技能本身不额外索取或存储凭据 |
| ④ 可疑指令/注入迹象 | 未发现 |
| ⑤ 作者/组织信誉 | Google 官方仓库,无造假迹象 |
| ⑥ License | Apache-2.0,明确 |
| ⑦ 最近维护时间 | 2026-07-24,近期活跃 |
7. 跟同类 Skills 相比的优势
| 项目 | 定位 | 与本技能的差异 |
|---|---|---|
| Kubernetes_Skill | 面向通用 Kubernetes(非 GKE 专属)manifest 生成与安全默认值诊断 | 覆盖任意 K8s 发行版的通用清单生成,不专门处理 GKE 特有的 Gateway API GKE 扩展、Cloud Armor、PSC 等云厂商专属网络能力;本技能是 GKE 专属且聚焦服务对外暴露这一单一场景 |
| Gke_Golden_Path_Google_Skills | GKE 生产集群的 Day-0 配置基线与就绪检查清单 | 覆盖集群创建阶段的整体决策(节点池、网络模式、监控等一次性设置),本技能是集群建好之后、持续给应用配置暴露路径与证书轮换的日常运维场景 |
| Gke_Workload_Security_Google_Skills | 已运行工作负载的安全配置审计(Workload Identity 等) | 关注的是 Pod/容器运行时本身的权限与身份加固,本技能关注的是服务如何被外部或其他 VPC 访问到,两者分属“运行时安全”与“网络暴露面”两个不同维度 |
8. 用户评价
该技能目前在第三方平台尚无具名用户评价。
9. 其他补充
Gateway API 需 GKE 1.24 及以上版本启用(新建集群默认已开启);技能正文将 Gateway API 列为“推荐”路径,标准 Ingress 定位为兼容简单场景或存量遗留配置的备选方案。
10. 安装使用方式
- 一键安装:
npx skills add google/skills,安装过程中勾选 “GKE Service Networking”。 - 插件市场安装(Claude Code):
claude plugin marketplace add google/skills,再执行claude plugin install <plugin>@google-plugins。 - 手动安装:将仓库
skills/cloud/gke-service-networking/SKILL.md复制到本地 agent 的 skills 目录。 - 使用前需已完成
gcloud container clusters get-credentials认证,本机具备kubectl、gcloud两个命令行工具;使用 Private Service Connect 工作流前需先备妥内部负载均衡器。
11. 注意事项
- 内容聚焦服务的对外/对内暴露与边缘防护,不涉及集群内网 IP 规划、Dataplane V2 网络策略或节点 NAT 出网配置(该部分由同仓库
gke-networking覆盖)。 - Cloud Armor 安全策略需先在 Cloud Armor 中单独创建,技能只给出如何在 GKE 侧引用,不生成策略规则本身。
- Private Service Connect 要求消费方与生产方分处不同 VPC,且需生产方先准备好内部负载均衡器,配置前需确认网络拓扑符合前提条件。