krew | 伪架构师

Release 自动更新 Krew Index

Fri, 26 Nov 2021 16:36:44 +0800

前面介绍过创建 Krew 插件的方法，其中生成插件描述文件的部分，可以说是又直接又麻烦，而且每次发布的时候，都要重新生成并刷新 Krew Index，于是我写了个脚本，可以根据既有信息和已经发布的二进制文件生成 YAML 文件。这个脚本的功能，简单说就是写一个 YAML 模板，然后下载二进制文件，计算哈希，生成最终的插件描述文件，把描述文件覆盖旧版本，然后发布 PR 即可。有了脚本之后其实还是挺麻烦的，不过在浏览 Krew 文档时发现有一节 Automating plugin updates ，其中提到了可以使用 Krew Release Bot 来自动地完成这个过程，官方强烈推荐使用这个 Bot 进行更新，理由是该 Bot 生成清单文件后自动提交的 PR，如果其中包含的变更内容只是简单的版本升级，能够被 Krew Index 的 Bot 自动处理，免除人工环节之后，整个更新过程可以在几分钟之内完成，避免了新版本二进制无法及时更新的尴尬。下面就介绍一下这个 Bot 的用法。

这个 Bot 是一个 Github Action 的插件，其工作原理和之前的脚本类似，在前文用 Github Action 自动发布二进制包中，在 Karmada 项目里使用 Github Action 进行了二进制文件的构建和发布，接下来继续使用这个基础，根据新发布的二进制来更新 Krew Index。

要在项目里使用 Krew Release Bot，首先要求项目插件已经成功发布到 Krew Index 中；接下来，需要生成一个文件 .krew.yaml，作为 Bot 的模板，这个模板和 Krew Index 的 YAML 是基本一致的，不过其中的二进制 URL 和 Hash 部分被替换为模板的占位符，例如 {{addURIAndSha "https://github.com/karmada-io/karmada/releases/download/{{ .TagName }}/kubectl-karmada-darwin-arm64.tgz" .TagName }}，甚至连这一步简单操作，Bot 作者也帮你解决了——他做了一个 Krew Release Bot Helper，在输入框输入已发布的 Karmada 插件名称，就可以自动生成 YAML 模板，放到项目里就可以了。

接下来，在 Release Action 里面加入如下语句：

- name: Update new version in krew-index
  uses: rajatjindal/krew-release-bot@v0.0.40

提交代码之后，创建一个新的 Release，会发现 Action 失败了，错误信息大概如下：

原因在于前面使用的 Matrix，我们的 PR 应该在生成并上传所有的二进制文件之后才能发起，所以改成这样：

  update-krew-index:
    needs: release-assests
    name: Update krew-index
    runs-on: ubuntu-18.04
    steps:
    - uses: actions/checkout@master
    - name: Update new version in krew-index
      uses: rajatjindal/krew-release-bot@v0.0.40

这里用了一个新的 job，使用 needs 关键字明确指出，需要等待 release-assests 任务完成。

再次提交，并创建 Tag，创建 Release。Action 运行示意图如下：

这里生成的 URL 所指向的二进制文件是无法访问的，因此还是无法成功，但如果是官方自行发布的话，就可以了，而且如上文所说，这样生成的 PR 会在几分钟之内得到 Approve。

读到这里会产生一个问题，会不会有人冒充发表呢？应该是不会的：Krew index 项目的 PR 机器人会对新 PR 的差异进行判定，如果不是典型的版本更新，会转入人工通道，因此新发的 PR 必须是和上一个版本具备这样的差异关系，而且必须是基于官方的二进制发布，才能够得到自动审批，因此完全可以放心使用。

如何编写一个支持 Krew 的 kubectl 插件

Thu, 02 Apr 2020 10:13:24 +0800

krew 简介

Krew 是一个用来管理 Kubectl 插件的工具，名字大概来自于 OS X 下著名的软件包管理器 Homebrew，使用 Krew 能够方便的查找、安装和使用 Kubectl 插件，例如：

$ kubectl krew search
NAME                            DESCRIPTION                                         INSTALLED
access-matrix                   Show an RBAC access matrix for server resources     no
advise-psp                      Suggests PodSecurityPolicies for cluster.           no
...

$ kubectl krew install tree
Updated the local copy of plugin index.
Installing plugin: tree
...

$  kubectl tree deployment coredns -nkube-system
NAMESPACE    NAME                                READY  REASON  AGE
kube-system  Deployment/coredns                  -              140d
kube-system  └─ReplicaSet/coredns-76d9d9bcc7   -              140d
kube-system    ├─Pod/coredns-76d9d9bcc7-m6d4c  True           4d10h
kube-system    └─Pod/coredns-76d9d9bcc7-zvf9c  True           4d10h

很方便的几个步骤，就可以查询、安装和使用新插件了。

Krew 除了落在客户端的可执行文件之外，和其它软件包管理系统一样，也同样需要有一个索引系统，并根据索引进行软件查询和下载，下载之后的软件保存在本地，供 kubectl 调用。

索引

Krew 的索引保存在一个名为 krew-index 的代码库中。其中的 plugins 目录保存了一组 yaml 文件，就是插件的目录。

YAML 清单

随意打开一个清单文件，可以看到这样的内容：

apiVersion: krew.googlecontainertools.github.com/v1alpha2
kind: Plugin
metadata:
  name: access-matrix
spec:
  version: v0.4.4
  platforms:
  - bin: access-matrix
    uri: https://github.com/corneliusweig/rakkess/releases/download/v0.4.4/access-matrix-amd64-linux.tar.gz
    sha256: 53b1ee5865d11360cea3e59b91cdc6707ee30845567e63657782ee11815f1de4
    files:
      - from: ./LICENSE
        to: .
      - from: ./access-matrix-amd64-linux
        to: access-matrix
    selector:
      matchLabels:
        os: linux
        arch: amd64
  shortDescription: Show an RBAC access matrix for server resources
  homepage: https://github.com/corneliusweig/rakkess
  caveats: |
      Usage:
        kubectl access-matrix
  description: ..

其中 apiVersion 和 kind 是固定内容。platforms 是一个数组，指定不同平台下的不同用法。下一级的 bin 表明了执行命令；uri 和 sha256 分别指的是下载位置以及压缩包的校验码；接下来的 files 是一个拷贝命令——从解压后的文件夹中拷贝文件；最后的 selector 则是针对不同平台的选择标准。

所以要编写一个能够通过 Krew 进行管理的 kubectl 插件，需要以下几个步骤：

编写插件代码
制作清单和调试
上传到 krew-index

下面用一个实际的例子来说明一下这个过程。

编写插件代码

插件代码本身的编写非常简单和随意，可以用你喜欢的任何语言，例如 golang、python 或者 shell。只有一个推荐的命名规则：kubectl-rm，在 kubectl 中调用时就可以使用 kubectl rm 了。例如我要编写一个对输出 JSON 进行过滤的插件，代码如下：

#!/bin/sh

METADATA=${JSON_METADATA-".metadata.resourceVersion, .metadata.selfLink, .metadata.managedFields, .metadata.generation, .metadata.uid, .metadata.creationTimestamp"}
STATUS=${JSON_STATUS-".status"}
ANNOTATION=${JSON_ANNOTATION-".metadata.annotations.\"kubectl.kubernetes.io/last-applied-configuration\", .metadata.annotations.\"deployment.kubernetes.io/revision\""}
SPEC=${JSON_SPEC-".spec.template.metadata.creationTimestamp, .spec.revisionHistoryLimit, .spec.templateGeneration"}

if ! [ -x "$(command -v jq)" ]; then
  echo 'Error: jq is not installed.' >&2
  exit 1
fi

if [ $# -lt 2 ]
  then
    echo "Usage: $0 [workload-type] [object-name] [other parameters for kubectl]"
    echo "Workload types: 'deployment', 'daemonset', 'configmap', 'statefulset', 'secret'"
    echo "Example: $0 deploy coredns -n kube-system"
    exit 1
fi

TYPE=$1
NAME=$2
OTHER=$*

kubectl get ${OTHER} -ojson | jq -S "del(${METADATA}, ${STATUS}, ${ANNOTATION}, ${SPEC})"

想法很简单，获取运行中的对象描述，使用 JQ 对数据进行清理和排序，输出一个相对标准的结果，便于不同环境间的比较和部署的导出。

虽然最后是通过 kubectl std-json 的方式调用，这里的 $0 指的仍然是脚本自身。

制作清单和测试

照猫画虎，按照上面的 YAML 代码，编写自己的清单。

清单要求，需要打一个压缩包便于下载，我们把可执行文件和 LICENSE 文件放置到单独的目录 kubectl-std-json-v0.1.0 中，压缩生成一个 .tar.gz 文件，部分清单如下

    uri: https://github.com/fleeto/kubectl-std-json/releases/download/v0.1.0/kubectl-std-json-v0.1.0.tar.gz
    sha256: e1ad2398eaed5442042da134fb046fa8276042dd4122da4d872a8e91aeb2a339
    bin: kubectl-std-json
    files:
    - from: kubectl-std-json-*/kubectl-std-json
      to: .
    - from: kubectl-std-json-*/LICENSE
      to: .

平台选择方面，我们只支持 OSX 和 Linux，因此只要一个平台元素即可。

压缩包的校验码可以使用 shasum -a 256 命令生成。

上传压缩包之后，可以使用 kubectl krew install --manifest 命令来测试安装。如果一切顺利，在本地就可以使用了。

krew-index

接下来的操作很常规：fork krew-index，把你的清单写入 plugins 目录，提交 PR 即可。