是否可以扩展kubectl create命令？有哪些替代实现方案？

首先明确原生插件机制的硬限制：kubectl官方插件规则不允许插件覆盖内置命令，也不允许给已存在的内置命令追加子命令，类似kubectl-create-foo这种试图挂载到create子命令下的插件会被系统直接忽略，没有稳定hack手段能绕过原生插件加载的这个校验逻辑。

目前可行的落地方案主要有三类，可以根据实际使用场景选择：

• 方案1：使用独立顶级插件命令绕开限制
  不要尝试把插件挂到create的子层级，按照插件命名规则给插件起独立的顶级命令名，比如命名为kubectl-cfoo、kubectl-createfoo，插件就能被正常识别加载。用户调用时执行kubectl cfoo或者kubectl createfoo即可触发自定义创建逻辑，功能上完全可以覆盖需要的扩展能力，只需要在插件帮助信息里说明这是create命令的扩展能力，用户几乎没有学习成本。这个方案是成本最低、兼容性最好的无侵入方案，也是社区最常用的自定义创建类插件实现方式。
• 方案2：封装kubectl wrapper层实现透明扩展
  写一个轻量的外层封装脚本（可以用Shell、Go、Python任意语言实现），命名为kubectl，放到系统PATH里优先级高于原生kubectl的路径下（比如/usr/local/bin，原生kubectl通常安装在/usr/bin路径）。脚本逻辑非常简单：先判断传入的参数，当参数匹配自定义的create xxx子命令时，直接执行写好的扩展逻辑；如果参数不匹配自定义规则，就把所有入参原封不动透传给原生kubectl二进制执行。
  一个极简的Shell版wrapper示例如下：

  #!/bin/bash
  # 匹配自定义create foo子命令
  if [[ "$1" == "create" && "$2" == "foo" ]]; then
    # 此处填入自定义创建逻辑
    echo "执行自定义kubectl create foo流程"
    exit 0
  fi
  # 其余所有请求透传给原生kubectl
  exec /usr/bin/kubectl "$@"
  

  这个方案对终端用户完全透明，使用体验和原生内置的kubectl create foo没有任何区别，维护成本也很低，只要透传逻辑写对，后续kubectl版本升级也不需要调整代码，唯一需要注意的是避免和其他kubectl封装工具的PATH优先级冲突。
• 方案3：源码编译定制版kubectl
  如果是企业内部使用、有专门的工具链维护能力，可以直接fork kubectl上游源码，在create命令的子命令注册逻辑中直接添加自定义的命令实现，编译出定制版的kubectl二进制分发给内部用户使用。这个方案的体验和原生命令完全一致，但是维护成本最高，每次上游发布新版本都需要同步合并代码、处理可能的命令注册逻辑冲突，不建议个人或者小团队使用。

注意：不要尝试通过修改插件管理器、篡改kubectl二进制打补丁等方式绕过插件命名限制，这类非官方hack方案会随kubectl版本升级随时失效，稳定性没有任何保障。

内容的提问来源于stack exchange，提问作者ciis0