尧图网页设计 
开发工具云原生【免费下载链接】krew Find and install kubectl plugins项目地址https://gitcode.com/gh_mirrors/kr/krew点击查看免费下载本指南围绕 Krew 的「自定义插件索引」展开讲解如何在满足 Krew 约定git 仓库 根目录plugins/ 合法清单的前提下自建并托管一套专属的 kubectl 插件索引覆盖索引的添加、列出、移除、按INDEX_NAME/PLUGIN_NAME安装插件以及私有仓库鉴权分发。读完本文你将掌握自定义索引的完整生命周期操作并理解 Krew 底层通过 git clone、plugins/目录扫描与清单校验完成索引加载的实现机制。自定义插件索引是什么Krew 自带一个名为default的插件索引它指向社区维护的krew-index仓库对应常量DefaultIndexURI定义在 constants.go负责通过社区评审实现插件的集中化发现。索引的实质是一组插件清单plugin manifests的集合——每个清单是一份描述插件下载与安装过程的 YAML 文档你完全可以不再依赖社区索引托管属于自己的索引甚至可以移除或替换default索引。从源码结构看Krew 把「索引」抽象为磁盘上的一个 git 克隆目录paths.IndexPath(name)索引名与目录名一一对应见 indexoperations/index.go因此自建索引的形态天然就是「一个 git 仓库 约定的目录结构」。为什么需要自建索引官方并不推荐无理由地自建索引托管自定义索引仅适合确实有特殊需求的场景例如插件未被krew-index接受社区索引有评审门槛插件可能因定位、质量或合规原因无法收录完全掌控插件分发生命周期希望自主决定发布节奏、版本策略与分发渠道而不受社区索引评审流程约束在组织内运行私有插件索引例如在开发机批量安装内部工具链时不希望在公网暴露插件。这些场景的共性在于默认的社区索引无法满足发布控制或私密性要求而自定义索引提供了完整替代路径。托管自定义索引的硬性要求原文档明确了自定义索引必须满足的四项要求它们是 Krew 能够识别并加载该索引的前提必须是 git 仓库Krew 对索引的添加、更新都基于 git 操作完成后续章节会给出源码证据客户端必须对该仓库有读权限若仓库非公开用户仍可在客户端通过 SSH 密钥或其他已安装的 git remote helpers 完成认证仓库根目录下必须存在plugins/目录且其中至少包含一个插件清单清单文件必须直接位于该目录内不得放在子目录中清单必须是合法 YAML且通过 Krew 清单校验可选用仓库自带的validate-krew-manifest工具做静态分析。推荐的最小仓库布局原文档给出了如下示例布局这是自定义索引仓库的标准形态. └── plugins/ ├── plugin-a.yaml ├── plugin-b.yaml └── plugin-c.yaml仓库根目录下只有plugins/一个关键目录每个插件对应一个plugin-name.yaml清单文件。这一布局与 Krew 的扫描逻辑严格对应索引扫描器只读取索引目录下扩展名为.yaml的普通文件filepath.Ext(file.Name()) constants.ManifestExtension见 scanner.go因此清单文件既不能放在子目录也不应使用.yml等其他扩展名。插件清单manifest的写法要点plugins/中的每个清单都必须符合 Krew 的清单结构。参照 plugin-manifest.md 中的示例一个典型的清单形如apiVersion: krew.googlecontainertools.github.com/v1alpha2 kind: Plugin metadata: # name 必须与文件名一致例如文件名 plugin-a.yaml 对应插件名 plugin-a name: restart spec: # version 必须是合法 semver 字符串且要求带 v 前缀 version: v0.0.1 # homepage 通常指向插件源码仓库 homepage: https://example.com/kubectl-restart # shortDescription 用一两句话说明插件用途 shortDescription: Restarts a pod with the given name description: | Restarts a pod with the given name. The existing pod will be deleted and created again, not a true restart. platforms: - selector: matchExpressions: - key: os operator: In values: - darwin - linux # uri 指向 .zip 或 .tar.gz 格式的插件归档 uri: https://example.com/kubectl-restart/archive/v0.0.3.zip # sha256 是上述归档文件的 sha256 校验和 sha256: d7079b79bf4e10e55ded435a2e862efe310e019b6c306a8ff04191238ef4b2b4 # files 指定从归档中提取哪些文件到安装目录 files: - from: kubectl-restart-*/restart.sh to: ./restart.sh - from: LICENSE to: . # bin 指向安装目录下可执行文件路径相对安装目录根 bin: ./restart.sh这些字段与 types.go 中定义的PluginSpec、Platform结构体一一对应Platform的URI/Sha256描述下载来源与完整性校验Selector用 Kubernetes 标签选择器按os/arch匹配目标平台Files定义归档提取操作Bin指定插件可执行文件在安装目录中的相对路径。关于清单字段的默认行为与边界可从校验实现validate.go反推出一组可复制、可自检的规则apiVersion必须为krew.googlecontainertools.github.com/v1alpha2kind必须为Plugin插件名必须匹配^[\w-]$且不能是 Windows 保留名如CON、PRN、COM1等spec.namemetadata.name必须与清单文件名一致shortDescription不能为空且不得包含换行platforms至少一个version必须存在且可被 semver 解析每个 platform 的uri、sha256不能为空sha256必须匹配^[a-f0-9]{64}$即 64 位小写十六进制bin不能为空files要么不写、要么非空且其中每项的from/to都必须设置selector不能为空键仅支持os与arch。用 validate-krew-manifest 做静态校验Krew 仓库自带独立的清单校验工具validate-krew-manifest源码见 main.go。该工具不仅做结构校验还会模拟完整安装过程适合在提交清单到索引仓库之前作为 CI 环节使用# 校验单个清单文件结构 平台匹配 validate-krew-manifest -manifest plugins/plugin-a.yaml # 跳过实际安装步骤仅做结构校验 validate-krew-manifest -manifest plugins/plugin-a.yaml -skip-install其校验流程依次为见 main.go调用indexscanner.ReadPluginFromFile读取并解析清单同时确认文件扩展名为.yaml并从文件名推断插件名执行validation.ValidatePlugin结构校验逐一检查每个spec.platforms[i].selector是否至少匹配一个 Krew 支持的os, arch组合支持的组合见代码中allPlatforms()覆盖 windows/linux/darwin 的 386、amd64、arm64 等见 main.go检查是否存在多个 platform 的选择器重叠同一os,arch被多个 platform 匹配是非法配置除非指定-skip-install否则对每个 platform 调用kubectl krew install --manifest ...在临时KREW_ROOT下实际演练安装并校验归档中是否包含 LICENSE或 COPYING 等同类许可文件。因此该工具能提前暴露「选择器不匹配任何平台」「platform 重叠」「sha256 错误」「归档缺少许可文件」等静态分析难以发现的问题是自定义索引质量保障的关键一环。源码视角Krew 如何加载与更新自定义索引理解索引的加载机制有助于排查「添加了索引却搜不到插件」之类的问题。整个过程分三层1. 添加/克隆indexoperations gitutilkubectl krew index add最终调用indexoperations.AddIndex其逻辑是若目标目录不存在则调用gitutil.EnsureCloned(uri, dir)执行git clone -v uri dir见 index.go 与 git.go。这也印证了「自定义索引必须是 git 仓库」这一硬性要求——Krew 从不通过 HTTP 下载索引目录只认 git 克隆。2. 更新gitutil执行kubectl krew update时索引目录会通过EnsureUpdated被刷新先git fetch -v再git reset --hard {upstream}将工作区强制对齐远端最后git clean -xfd清理未跟踪文件见 git.go。这意味着索引仓库本地工作区会被强制重置任何未经提交的改动包括临时创建的文件都会被清除客户端侧不应把索引克隆当作可写工作区使用。3. 扫描indexscanner插件加载由LoadPluginListFromFS完成它只读取索引目录下直接位于根层的.yaml文件逐个解析为index.Plugin并对每个插件执行validation.ValidatePlugin单个清单解析失败不会导致整个索引加载失败而是记录错误后跳过该插件继续加载其余清单见 scanner.go。这与原文档「清单应直接放在plugins/目录而非子目录」的要求是直接对应的。4. 列出索引kubectl krew index list的实现index.go遍历索引基目录下的每个子目录并对每个目录读取git config --get remote.origin.url得到远端 URL最终以「INDEX / URL」表格输出。客户端操作添加、列出与移除自定义索引配套的用户侧操作文档见 using-custom-indexes.md核心命令如下。添加索引kubectl krew index add foo https://github.com/foo/custom-index.gitadd接受两个参数索引名与 git remote URI。URI 可以是任意 git remote 形式例如 SSH 形式gitgithub.com:foo/custom-index.git。索引名需匹配^[A-Za-z0-9_-]$见 indexoperations/index.go非法名字会被拒绝返回invalid index name见 index.go。值得注意index add成功后Krew 会打印一条安全警告——新索引中的插件未经 Krew 维护者安全审计安装需自担风险见 index.go。这是自定义索引与社区索引在信任模型上的核心差异使用前应评估索引来源的可信度。列出已配置的索引kubectl krew index list输出示例表格格式INDEX与URL两列INDEX URL default https://github.com/kubernetes-sigs/krew-index.git foo https://github.com/foo/custom-index.git该命令别名ls。移除索引kubectl krew index remove fooremove别名rm有两个值得注意的行为见 index.go存在已安装插件的索引默认无法移除命令会先查询该索引下已安装的插件通过安装收据 receipt 的status.source.name关联收据类型见 types.go若仍有插件安装自该索引会报错提示若确实需要强制移除可加--force标志但这可能导致已安装插件进入不受支持的状态官方注释明确「不推荐」kubectl krew index remove foo --force从自定义索引安装与使用插件添加索引后所有插件管理命令install、upgrade等都适用于自定义索引。关键约定在于索引前缀不带前缀时Krew 默认把插件归属到default索引魔法字符串DefaultIndexName default见 constants.go带前缀时必须使用INDEX_NAME/PLUGIN_NAME格式。例如从自定义索引foo安装名为bar的插件kubectl krew install foo/bar其余常用操作列出所有索引的全部插件含自定义索引kubectl krew search卸载插件无需指定索引按插件名即可kubectl krew uninstall PLUGIN_NAME查看自定义索引中插件的信息kubectl krew info foo/bar注意若两个索引中存在同名插件同一时间只能安装其中一个。替换 default 索引默认情况下不带INDEX_NAME前缀的命令都指向default索引前缀的作用是区分不同索引中的同名插件。Krew 出厂即绑定krew-index作为default索引但你可以将其移除从而彻底切换索引来源kubectl krew index remove default移除后你可以用任意索引名重新添加并命名为defaultkubectl krew index add default https://your-org/index-repo.git此后该索引中的插件在命令中无需INDEX_NAME前缀行为与内置默认索引一致。这是组织内部「接管默认插件源」的标准做法。私有索引与受保护归档的分发原文档提到非公开索引的客户端可通过 SSH 密钥或 git remote helpers 认证——这解决的是索引仓库本身git 仓库的访问但插件归档文件清单uri指向的二进制包若托管在需要认证的私有注册表还需要额外的凭据机制。Krew 支持从用户的.netrc文件读取凭据详见 serving-plugins-privately.mdkubectl krew install --enable-netrc foo/bar其中--enable-netrc启用.netrc凭据读取Windows 上为_netrc归档 URL 的主机部分必须在.netrc中有对应条目machine private registry host login username password password.netrc默认位置Linux/macOS 为~/.netrcWindows 为%HOME%\_netrc可用--netrc-file覆盖。对于私有 GitHub 仓库常见的落地方式是用细粒度 PAT只读contents与metadata权限写入.netrc的github.com与raw.githubusercontent.com条目并通过raw.githubusercontent.com直链归档——因为 GitHub Release 产物不支持该鉴权方式。实践建议与注意事项综合原文档与源码实现托管自定义索引时应遵守以下最佳实践先本地校验再推送把validate-krew-manifest纳入索引仓库的 CI确保每个清单通过结构校验与平台匹配检查避免坏清单拖累整仓索引的可用性保持目录严格扁平清单必须位于plugins/根层、扩展名必须是.yaml、文件名必须与插件名一致——三者任一违反都会导致插件无法被发现理解信任边界自定义索引插件未经 Krew 维护者审计index add后终端会明确警告请仅添加可信来源的索引不要手工改动本地索引克隆krew update会fetch reset --hard clean强制重置索引目录本地改动会被抹掉移除索引前检查已安装插件默认的移除保护会阻止你误删仍被引用的索引--force慎用同名插件互斥不同索引出现同名插件时同一时间只能安装其一可用INDEX_NAME/PLUGIN_NAME精确指定目标来源。通过本文的布局约定、清单校验与客户端命令你已经可以完全脱离社区索引搭建并运营属于自己的 kubectl 插件分发体系。赞分享开发工具云原生【免费下载链接】krew Find and install kubectl plugins项目地址https://gitcode.com/gh_mirrors/kr/krew点击查看免费下载相关推荐Vue Flow 自定义连接线Custom Connection Line实战指南从插槽用法到源码级原理Vue Flow 自定义连接线Custom Connection Line实战指南从插槽用法到源码级原理 在 Vue Flow 中连接线Connect前端UI组件pipx高级用法从源码、Git仓库到自定义版本管理pipx高级用法从源码、Git仓库到自定义版本管理 本文详细介绍了pipx的高级用法包括从Git仓库安装Python应用的方法、指定版本和分支的安装技巧、从CLI开发工具包管理器Read the Docs 自定义域名Custom Domains完整指南从 DNS 配置到源码级原理Read the Docs 自定义域名Custom Domains完整指南从 DNS 配置到源码级原理 自定义域名允许你将文档托管在完全由自己掌控的域名后端文档上一篇Butterfly项目中的Edge线组件详解下一篇CTF Wiki 競賽內容總覽六大題型分類與全國大學生信息安全競賽考點解讀创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Krew 自定义插件索引（Custom Plugin Indexes）托管指南：从仓库布局到源码级原理
开发工具云原生【免费下载链接】krew Find and install kubectl plugins项目地址https://gitcode.com/gh_mirrors/kr/krew点击查看免费下载本指南围绕 Krew 的「自定义插件索引」展开讲解如何在满足 Krew 约定git 仓库 根目录plugins/ 合法清单的前提下自建并托管一套专属的 kubectl 插件索引覆盖索引的添加、列出、移除、按INDEX_NAME/PLUGIN_NAME安装插件以及私有仓库鉴权分发。读完本文你将掌握自定义索引的完整生命周期操作并理解 Krew 底层通过 git clone、plugins/目录扫描与清单校验完成索引加载的实现机制。自定义插件索引是什么Krew 自带一个名为default的插件索引它指向社区维护的krew-index仓库对应常量DefaultIndexURI定义在 constants.go负责通过社区评审实现插件的集中化发现。索引的实质是一组插件清单plugin manifests的集合——每个清单是一份描述插件下载与安装过程的 YAML 文档你完全可以不再依赖社区索引托管属于自己的索引甚至可以移除或替换default索引。从源码结构看Krew 把「索引」抽象为磁盘上的一个 git 克隆目录paths.IndexPath(name)索引名与目录名一一对应见 indexoperations/index.go因此自建索引的形态天然就是「一个 git 仓库 约定的目录结构」。为什么需要自建索引官方并不推荐无理由地自建索引托管自定义索引仅适合确实有特殊需求的场景例如插件未被krew-index接受社区索引有评审门槛插件可能因定位、质量或合规原因无法收录完全掌控插件分发生命周期希望自主决定发布节奏、版本策略与分发渠道而不受社区索引评审流程约束在组织内运行私有插件索引例如在开发机批量安装内部工具链时不希望在公网暴露插件。这些场景的共性在于默认的社区索引无法满足发布控制或私密性要求而自定义索引提供了完整替代路径。托管自定义索引的硬性要求原文档明确了自定义索引必须满足的四项要求它们是 Krew 能够识别并加载该索引的前提必须是 git 仓库Krew 对索引的添加、更新都基于 git 操作完成后续章节会给出源码证据客户端必须对该仓库有读权限若仓库非公开用户仍可在客户端通过 SSH 密钥或其他已安装的 git remote helpers 完成认证仓库根目录下必须存在plugins/目录且其中至少包含一个插件清单清单文件必须直接位于该目录内不得放在子目录中清单必须是合法 YAML且通过 Krew 清单校验可选用仓库自带的validate-krew-manifest工具做静态分析。推荐的最小仓库布局原文档给出了如下示例布局这是自定义索引仓库的标准形态. └── plugins/ ├── plugin-a.yaml ├── plugin-b.yaml └── plugin-c.yaml仓库根目录下只有plugins/一个关键目录每个插件对应一个plugin-name.yaml清单文件。这一布局与 Krew 的扫描逻辑严格对应索引扫描器只读取索引目录下扩展名为.yaml的普通文件filepath.Ext(file.Name()) constants.ManifestExtension见 scanner.go因此清单文件既不能放在子目录也不应使用.yml等其他扩展名。插件清单manifest的写法要点plugins/中的每个清单都必须符合 Krew 的清单结构。参照 plugin-manifest.md 中的示例一个典型的清单形如apiVersion: krew.googlecontainertools.github.com/v1alpha2 kind: Plugin metadata: # name 必须与文件名一致例如文件名 plugin-a.yaml 对应插件名 plugin-a name: restart spec: # version 必须是合法 semver 字符串且要求带 v 前缀 version: v0.0.1 # homepage 通常指向插件源码仓库 homepage: https://example.com/kubectl-restart # shortDescription 用一两句话说明插件用途 shortDescription: Restarts a pod with the given name description: | Restarts a pod with the given name. The existing pod will be deleted and created again, not a true restart. platforms: - selector: matchExpressions: - key: os operator: In values: - darwin - linux # uri 指向 .zip 或 .tar.gz 格式的插件归档 uri: https://example.com/kubectl-restart/archive/v0.0.3.zip # sha256 是上述归档文件的 sha256 校验和 sha256: d7079b79bf4e10e55ded435a2e862efe310e019b6c306a8ff04191238ef4b2b4 # files 指定从归档中提取哪些文件到安装目录 files: - from: kubectl-restart-*/restart.sh to: ./restart.sh - from: LICENSE to: . # bin 指向安装目录下可执行文件路径相对安装目录根 bin: ./restart.sh这些字段与 types.go 中定义的PluginSpec、Platform结构体一一对应Platform的URI/Sha256描述下载来源与完整性校验Selector用 Kubernetes 标签选择器按os/arch匹配目标平台Files定义归档提取操作Bin指定插件可执行文件在安装目录中的相对路径。关于清单字段的默认行为与边界可从校验实现validate.go反推出一组可复制、可自检的规则apiVersion必须为krew.googlecontainertools.github.com/v1alpha2kind必须为Plugin插件名必须匹配^[\w-]$且不能是 Windows 保留名如CON、PRN、COM1等spec.namemetadata.name必须与清单文件名一致shortDescription不能为空且不得包含换行platforms至少一个version必须存在且可被 semver 解析每个 platform 的uri、sha256不能为空sha256必须匹配^[a-f0-9]{64}$即 64 位小写十六进制bin不能为空files要么不写、要么非空且其中每项的from/to都必须设置selector不能为空键仅支持os与arch。用 validate-krew-manifest 做静态校验Krew 仓库自带独立的清单校验工具validate-krew-manifest源码见 main.go。该工具不仅做结构校验还会模拟完整安装过程适合在提交清单到索引仓库之前作为 CI 环节使用# 校验单个清单文件结构 平台匹配 validate-krew-manifest -manifest plugins/plugin-a.yaml # 跳过实际安装步骤仅做结构校验 validate-krew-manifest -manifest plugins/plugin-a.yaml -skip-install其校验流程依次为见 main.go调用indexscanner.ReadPluginFromFile读取并解析清单同时确认文件扩展名为.yaml并从文件名推断插件名执行validation.ValidatePlugin结构校验逐一检查每个spec.platforms[i].selector是否至少匹配一个 Krew 支持的os, arch组合支持的组合见代码中allPlatforms()覆盖 windows/linux/darwin 的 386、amd64、arm64 等见 main.go检查是否存在多个 platform 的选择器重叠同一os,arch被多个 platform 匹配是非法配置除非指定-skip-install否则对每个 platform 调用kubectl krew install --manifest ...在临时KREW_ROOT下实际演练安装并校验归档中是否包含 LICENSE或 COPYING 等同类许可文件。因此该工具能提前暴露「选择器不匹配任何平台」「platform 重叠」「sha256 错误」「归档缺少许可文件」等静态分析难以发现的问题是自定义索引质量保障的关键一环。源码视角Krew 如何加载与更新自定义索引理解索引的加载机制有助于排查「添加了索引却搜不到插件」之类的问题。整个过程分三层1. 添加/克隆indexoperations gitutilkubectl krew index add最终调用indexoperations.AddIndex其逻辑是若目标目录不存在则调用gitutil.EnsureCloned(uri, dir)执行git clone -v uri dir见 index.go 与 git.go。这也印证了「自定义索引必须是 git 仓库」这一硬性要求——Krew 从不通过 HTTP 下载索引目录只认 git 克隆。2. 更新gitutil执行kubectl krew update时索引目录会通过EnsureUpdated被刷新先git fetch -v再git reset --hard {upstream}将工作区强制对齐远端最后git clean -xfd清理未跟踪文件见 git.go。这意味着索引仓库本地工作区会被强制重置任何未经提交的改动包括临时创建的文件都会被清除客户端侧不应把索引克隆当作可写工作区使用。3. 扫描indexscanner插件加载由LoadPluginListFromFS完成它只读取索引目录下直接位于根层的.yaml文件逐个解析为index.Plugin并对每个插件执行validation.ValidatePlugin单个清单解析失败不会导致整个索引加载失败而是记录错误后跳过该插件继续加载其余清单见 scanner.go。这与原文档「清单应直接放在plugins/目录而非子目录」的要求是直接对应的。4. 列出索引kubectl krew index list的实现index.go遍历索引基目录下的每个子目录并对每个目录读取git config --get remote.origin.url得到远端 URL最终以「INDEX / URL」表格输出。客户端操作添加、列出与移除自定义索引配套的用户侧操作文档见 using-custom-indexes.md核心命令如下。添加索引kubectl krew index add foo https://github.com/foo/custom-index.gitadd接受两个参数索引名与 git remote URI。URI 可以是任意 git remote 形式例如 SSH 形式gitgithub.com:foo/custom-index.git。索引名需匹配^[A-Za-z0-9_-]$见 indexoperations/index.go非法名字会被拒绝返回invalid index name见 index.go。值得注意index add成功后Krew 会打印一条安全警告——新索引中的插件未经 Krew 维护者安全审计安装需自担风险见 index.go。这是自定义索引与社区索引在信任模型上的核心差异使用前应评估索引来源的可信度。列出已配置的索引kubectl krew index list输出示例表格格式INDEX与URL两列INDEX URL default https://github.com/kubernetes-sigs/krew-index.git foo https://github.com/foo/custom-index.git该命令别名ls。移除索引kubectl krew index remove fooremove别名rm有两个值得注意的行为见 index.go存在已安装插件的索引默认无法移除命令会先查询该索引下已安装的插件通过安装收据 receipt 的status.source.name关联收据类型见 types.go若仍有插件安装自该索引会报错提示若确实需要强制移除可加--force标志但这可能导致已安装插件进入不受支持的状态官方注释明确「不推荐」kubectl krew index remove foo --force从自定义索引安装与使用插件添加索引后所有插件管理命令install、upgrade等都适用于自定义索引。关键约定在于索引前缀不带前缀时Krew 默认把插件归属到default索引魔法字符串DefaultIndexName default见 constants.go带前缀时必须使用INDEX_NAME/PLUGIN_NAME格式。例如从自定义索引foo安装名为bar的插件kubectl krew install foo/bar其余常用操作列出所有索引的全部插件含自定义索引kubectl krew search卸载插件无需指定索引按插件名即可kubectl krew uninstall PLUGIN_NAME查看自定义索引中插件的信息kubectl krew info foo/bar注意若两个索引中存在同名插件同一时间只能安装其中一个。替换 default 索引默认情况下不带INDEX_NAME前缀的命令都指向default索引前缀的作用是区分不同索引中的同名插件。Krew 出厂即绑定krew-index作为default索引但你可以将其移除从而彻底切换索引来源kubectl krew index remove default移除后你可以用任意索引名重新添加并命名为defaultkubectl krew index add default https://your-org/index-repo.git此后该索引中的插件在命令中无需INDEX_NAME前缀行为与内置默认索引一致。这是组织内部「接管默认插件源」的标准做法。私有索引与受保护归档的分发原文档提到非公开索引的客户端可通过 SSH 密钥或 git remote helpers 认证——这解决的是索引仓库本身git 仓库的访问但插件归档文件清单uri指向的二进制包若托管在需要认证的私有注册表还需要额外的凭据机制。Krew 支持从用户的.netrc文件读取凭据详见 serving-plugins-privately.mdkubectl krew install --enable-netrc foo/bar其中--enable-netrc启用.netrc凭据读取Windows 上为_netrc归档 URL 的主机部分必须在.netrc中有对应条目machine private registry host login username password password.netrc默认位置Linux/macOS 为~/.netrcWindows 为%HOME%\_netrc可用--netrc-file覆盖。对于私有 GitHub 仓库常见的落地方式是用细粒度 PAT只读contents与metadata权限写入.netrc的github.com与raw.githubusercontent.com条目并通过raw.githubusercontent.com直链归档——因为 GitHub Release 产物不支持该鉴权方式。实践建议与注意事项综合原文档与源码实现托管自定义索引时应遵守以下最佳实践先本地校验再推送把validate-krew-manifest纳入索引仓库的 CI确保每个清单通过结构校验与平台匹配检查避免坏清单拖累整仓索引的可用性保持目录严格扁平清单必须位于plugins/根层、扩展名必须是.yaml、文件名必须与插件名一致——三者任一违反都会导致插件无法被发现理解信任边界自定义索引插件未经 Krew 维护者审计index add后终端会明确警告请仅添加可信来源的索引不要手工改动本地索引克隆krew update会fetch reset --hard clean强制重置索引目录本地改动会被抹掉移除索引前检查已安装插件默认的移除保护会阻止你误删仍被引用的索引--force慎用同名插件互斥不同索引出现同名插件时同一时间只能安装其一可用INDEX_NAME/PLUGIN_NAME精确指定目标来源。通过本文的布局约定、清单校验与客户端命令你已经可以完全脱离社区索引搭建并运营属于自己的 kubectl 插件分发体系。赞分享开发工具云原生【免费下载链接】krew Find and install kubectl plugins项目地址https://gitcode.com/gh_mirrors/kr/krew点击查看免费下载相关推荐Vue Flow 自定义连接线Custom Connection Line实战指南从插槽用法到源码级原理Vue Flow 自定义连接线Custom Connection Line实战指南从插槽用法到源码级原理 在 Vue Flow 中连接线Connect前端UI组件pipx高级用法从源码、Git仓库到自定义版本管理pipx高级用法从源码、Git仓库到自定义版本管理 本文详细介绍了pipx的高级用法包括从Git仓库安装Python应用的方法、指定版本和分支的安装技巧、从CLI开发工具包管理器Read the Docs 自定义域名Custom Domains完整指南从 DNS 配置到源码级原理Read the Docs 自定义域名Custom Domains完整指南从 DNS 配置到源码级原理 自定义域名允许你将文档托管在完全由自己掌控的域名后端文档上一篇Butterfly项目中的Edge线组件详解下一篇CTF Wiki 競賽內容總覽六大題型分類與全國大學生信息安全競賽考點解讀创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考