晴耕小筑

在团队中使用增强版OpenShift CLI

2021-08-11T00:00:00+08:00

增强版OpenShift CLI可以帮助我们高效而安全的管理大量的OpenShift集群。它是一个位于GitHub上的开源项目。

作为增强版OpenShift CLI系列文章的第四篇，本文将向大家介绍如何把保存在本地secret store里的集群访问信息分享给团队中的其他成员。

通过把存有集群访问信息的本地secret store分享到远程，我们可以很方便的在整个团队范围内实现统一的集群管理。任何时候，当你有新的集群访问信息通过增强版oc加入到secret store，同样的访问信息将会被自动同步到其他团队成员的本地secret store里。这样，大家在不关心集群访问信息具体内容的情况下，只通过集群的别名就可以实现对同一集群的访问了。

分享你的Secret Store

如果你打算把保存在本地secret store里的集群访问信息分享给其他人，首先需要为secret store添加git remote信息，并将本地的secret store通过git push推送到远程：

$ gopass git remote add origin git@github.example.com:william/team-clusters.git
$ gopass git push origin master

当连接远程的git服务器时（比如GitHub），尽管我们可以使用HTTPS协议，但还是建议大家使用SSH进行连接。利用SSH key，我们在每次访问远程git库时，可以无需提供用户名和access token。有关如何以SSH方式连接GitHub，请参考GitHub的相关文档。

为团队成员做准备

为了让团队成员能够成功解密保存在远程secret store里的经过加密的集群访问信息，我们还需要做一点准备工作。首先，要求团队成员在各自的机器上安装好必要的工具和软件，包括：gpg，git，gopass，oc等。然后，要求大家用如下命令生成各自的密钥对：

$ gpg --full-generate-key

选择RSA and RSA作为密钥类型，keysize为2048，密钥永不过期，然后输入团队成员的用户名，邮箱地址，以及密钥对应的密码（passphrase）。

等密钥对生成完毕以后，要求大家把其中的公钥导出并发送给你。在团队成员所在的机器上执行如下命令，可以找到公钥的ID：

$ gpg --list-keys --keyid-format LONG
/root/.gnupg/pubring.gpg
------------------------
pub   2048R/93E7B0300BB9C91B 2021-03-17
uid                          Nicole <nicole@example.com>
sub   2048R/3AE8C980579D103C 2021-03-17

从输出结果中选取与当前团队成员的用户名及邮箱地址相匹配的公钥，复制相应的密钥ID，即pub所在的那一行，本例中为93E7B0300BB9C91B。然后用如下命令，把公钥导出到一个文件里：

$ gpg --armor --export 93E7B0300BB9C91B > nicole_pub.gpg

当我们接收到团队成员的公钥以后，通过如下命令将公钥导入到本地：

$ gpg --import nicole_pub.gpg

并将该团队成员作为recipient，加入到本地的secret store里：

$ gopass recipients add 93E7B0300BB9C91B

然后用我们自己的私钥对团队成员的公钥进行签名，并选择对其永久信任：

$ gpg --edit-key 93E7B0300BB9C91B
lsign
trust
save

最后，重新加一次recipient，以触发gopass对保存在本地secret store里的数据重新进行加密：

$ gopass recipients rm 93E7B0300BB9C91B
$ gopass recipients add 93E7B0300BB9C91B

上述所有步骤都会被自动同步到远程的secret store里。

克隆远程的Secret Store

现在，我们可以通知团队成员，让大家把远程的secret store克隆到本地了。同时，请确保这些团队成员已经以collaborator的身份被添加到了远程git库里。然后在每位团队成员所在的机器上执行如下命令，将远程secret store克隆到本地：

$ gopass --yes setup --remote git@github.example.com:william/team-clusters.git --alias team-clusters --name Nicole --email "nicole@example.com"

其中，参数--name和--email的取值和团队成员在生成各自密钥对时所使用的取值保持一致。这样，其他人就可以和我们一样，利用oc login命令及别名，对同一组集群进行访问了。

下图演示了整个准备工作的端到端流程：

小结

本文中，我们学习了如何把保存在本地secret store里的集群访问信息分享给团队中的其他成员。

如果你想了解更多有关增强版OpenShift CLI的信息，请阅读它的在线文档。如果你喜欢这个项目，欢迎给它加星。同时，也非常欢迎针对该项目的任何形式的贡献，比如bug报告以及代码提交。

增强版OpenShift CLI的更多功能

2021-08-02T00:00:00+08:00

增强版OpenShift CLI可以帮助我们高效而安全的管理大量的OpenShift集群。它是一个位于GitHub上的开源项目。

作为增强版OpenShift CLI系列文章的第三篇，本文将和大家分享有关这一工具所提供的更多有意思的功能。

层级化管理集群

在一个实际项目里，同时管理多个集群是一件很常见的事。使用增强版oc，通过指定别名可以实现在多个集群之间的快速切换，这样做即安全又高效。不过，随着集群数量的增加，管理成本还是会逐步上升。针对这种情况，一种更为有效的方法，是将这些集群以层级化的方式进行管理。

增强版oc底层依赖于gopass，而gopass天生就具备层级化管理加密数据的能力。这是因为，gopass在存储加密数据时，把一组加密数据以一个独立文件的形式保存在secret store里，而彼此相关的一组文件可以根据需要存放在同一目录下面。例如，假设有三个集群，我们可以采用path/to/your/context这样的格式来为集群定义别名。

$ oc login -s https://api.foo.example.com -c dev-env/cluster-foo
$ oc login -s https://api.bar.example.com -c dev-env/cluster-bar
$ oc login -s https://api.baz.example.com -c dev-env/cluster-baz

这样，集群的访问信息就会以层级化的方式保存在secret store里，相应的目录结构与我们定义别名时的格式保持一致。这一点可以通过执行gopass ls命令清楚直观的展现出来：

$ gopass ls
gopass
└── dev-env
    ├── cluster-foo
    ├── cluster-bar
    └── cluster-baz

当我们在这些集群之间切换时，只要给出path/to/your/context别名即可：

$ oc login -c dev-env/cluster-foo
$ oc login -c dev-env/cluster-bar
$ oc login -c dev-env/cluster-baz

在多个集群中选择

以层级化方式对集群进行管理允许我们能够非常高效的管理大量集群，我们可以把集群按照不同的用途进行分类。不过，由于别名里包含了层级结构，输入完整的别名就会变得有点冗长。

增强版oc允许我们在输入集群的别名时只输入名字的一部分。例如，如果我们把所有开发用的集群环境都放到dev-env类别下，相应的集群别名均以dev-env打头。那么，当我们指定别名的时候，只要输入完整名字的几个首字母，比如：de，dev，dev-，dev-env，就会有多个满足输入条件的集群返回回来。这些集群会以有序列表的形式依次排列，要想选中其中一个集群登录，只要输入集群前面的数字即可：

$ oc login -c dev
1) dev-env/cluster-bar
2) dev-env/cluster-baz
3) dev-env/cluster-foo
#? 1
Read context 'dev-env/cluster-bar' from secret store...
Context loaded successfully.
Login successful.

You have access to 59 projects, the list has been suppressed. You can list all projects with 'oc projects'

Using project "default".

模糊查找

增强版oc允许我们在输入集群的别名时只输入名字的一部分，从而进一步提高了在多个集群间切换的效率。不仅如此，如果我们安装了fzf，一个通用的支持模糊查找与过滤的命令行工具，就可以在指定别名时利用typeahead实现模糊查找的功能了。增强版oc与fzf做了无缝集成，不需要额外配置，它会自动监测fzf存在与否，并开启相应的模糊查找功能。有关fzf的安装，请参考其文档。

定制Shell提示

我们还可以安装kube-ps1。这是一个脚本程序，允许把当前集群的上下文信息，包括当前所在的namespace，在命令行的Shell提示里显示出来。当我们需要同时管理多个集群，并在这些集群之间来回切换的时候，这一功能就会非常有用。通过查看命令行的Shell提示信息，我们可以快速获知当前操作的是哪个集群，从而避免了误操作。

增强版oc和kube-ps1做了无缝集成，不需要额外配置，它会自动监测kube-ps1存在与否，并对kube-ps1控制的Shell提示进行定制，将完整的集群上下文名称替换为相应的集群别名，通常而言，后者要比前者更短更易于记忆。有关kube-ps1的安装，请参考其文档。

小结

本文中，我们学习了有关增强版oc的更多有趣的功能，比如：以层级化方式对集群进行管理；通过只输入别名的一部分，实现多个集群间的快速切换；以及通过对Shell提示的定制，显示当前操作的集群。在下一篇文章里，我将向大家介绍增强版oc的另一个重要的功能：如何将集群访问信息分享给团队中的其他成员。

增强版OpenShift CLI快速入门

2021-07-25T00:00:00+08:00

增强版OpenShift CLI可以帮助我们高效而安全的管理大量的OpenShift集群。它是一个位于GitHub上的开源项目。

作为增强版OpenShift CLI系列文章的第二篇，本文将向大家介绍如何安装增强版oc，并为大家演示它的一些基本用法。

安装增强版OpenShift CLI

为了让增强版OpenShift CLI能够正常工作，我们在安装增强版OpenShift CLI之前，首先需要确保其所依赖的软件已经安装就绪，这其中包括：

gpg：用于数据加密和解密
git：用于存储和共享加密数据
gopass：用于加密数据的管理，运行于gpg和git之上
oc：RedHat官方提供的OpenShift CLI

根据你所使用的操作系统，从下列命令中选择正确的命令，安装git与gpg：

# MacOS
$ brew install gnupg2 git
# RHEL & CentOS
$ brew install gnupg2 git
# Ubuntu & Debian
$ apt-get install gnupg2 git

关于gopass的安装，推荐到gopass在GitHub上的releases页面下载并安装最新的版本。根据你所使用的操作系统，选择相应的压缩包，将之下载到本地并解压，然后从中找出gopass的可执行文件，放入$PATH能访问的路径下。

关于oc的安装，请参考OpenShift的官方文档。

当增强版OpenShift CLI的所有依赖软件安装完毕以后，请从GitHub上下载增强版oc的Shell脚本：

$ curl -OL https://raw.githubusercontent.com/morningspace/oc/master/oc.sh

如果你用的是Bash，请在用户主目录下找到Shell初始化文件.bashrc，并将下列代码加入其中。如果你用的是其他Shell，比如Zsh，则相应的Shell初始化文件会有所不同。

[[ -f /path/to/oc.sh ]] && source /path/to/oc.sh

随后，我们打开一个新的终端窗口，并运行oc命令，以验证安装是否成功。如果一切正常，我们会看到，在oc命令输出的正常帮助信息前面，会有几行提示信息，代表这是一个增强版的OpenShift CLI。

设置环境

gopass是依赖于gpg对数据进行加密和解密的。在我们开始使用增强版oc之前，我们必须先创建一组密钥对：

$ gpg --full-generate-key

选择RSA and RSA作为密钥类型，keysize为2048，密钥永不过期，然后输入你的用户名，邮箱地址，以及密钥对应的密码（passphrase）。

此外，我们还应该把下列代码加入位于用户主目录下的Shell初始化文件内：

export GPG_TTY=$(tty)

然后运行gopass命令初始化secret store：

$ gopass init

根据提示，选择之前生成的密钥对中的私钥，用它对存储于secret store中的数据进行加密，随后输入你的邮箱地址用于git的配置。

首次登录集群

第一次登录某个集群时，我们将使用oc login命令：

$ oc login
Server [https://localhost:8443]: https://api.cluster-foo.example.com:6443
Username [kubeadmin]:
Password:
Context alias [api-cluster-foo-example-com-6443]: cluster-foo
Login successful.

You have access to 59 projects, the list has been suppressed. You can list all projects with 'oc projects'

Using project "default".
Save context 'cluster-foo' into secret store...
Context saved successfully.

根据提示，输入集群的服务器地址，登录用户名，以及密码。这些都是原有oc命令所支持的功能。在这之后，增强版oc会提示我们为即将访问的集群指定一个便于记忆的别名。这个别名相当于一个”助记符“，不仅对应于所访问的集群，还包括所使用的登录账号等信息。稍后我们会看到，增强版oc是如何利用这个别名，实现在多个集群之间的快速切换的。

当然，就像原有oc命令所支持的那样，我们也可以把上述输入的信息作为命令行参数，直接放在oc login命令的后面。不过，为了避免登录信息通过命令行执行历史暴露出来，还是建议大家不要这样做。

通过别名登录集群

当集群的登录会话超时以后，我们就需要用oc login命令再次进行登录。不过和原有oc命令不同，这一次我们无需再重新输入全部登录信息了，只要通过-c参数告诉oc命令我们要访问的集群别名即可：

$ oc login -c cluster-foo
Read context 'cluster-foo' from secret store...
Context loaded successfully.
Login successful.

You have access to 59 projects, the list has been suppressed. You can list all projects with 'oc projects'

Using project "default".

这是因为，之前我们所提供的有关该集群的全部访问信息，连同对应的别名，都已经被保存在gopass的secret store里了。因此，只要我们提供别名信息，增强版oc就会根据别名找到对应的集群访问信息，并自动登录集群。

小结

本文中，我们学习了增强版OpenShift CLI的安装，及其基本使用方法。在下一篇文章里，我将和大家分享有关这一工具所提供的更多有意思的功能。

如何高效安全的管理OpenShift集群

2021-07-18T00:00:00+08:00

增强版OpenShift CLI可以帮助我们高效而安全的管理大量的OpenShift集群。它是一个位于GitHub上的开源项目。

问题的提出

大家有没有遇到过这样的情况：手里有多个OpenShift集群同时在工作，并且访问每个集群都需要使用各自的登录账号和密码。基于安全的考虑，每次登录一个集群以后，登录会话会在一段时间之后失效。于是，为了继续操作这些集群，我们需要重新进行登录。

不仅如此，如果这些集群属于池化资源，那么典型情况下，它们的创建和释放都是按需来的，相应的集群访问信息，包括访问地址和登录密码，都可能是随机生成的，因而非常难于记忆。为此，我们不得不把集群的访问信息记录在某个地方，比如一个文本文件里，而这种记录信息的方法是不安全的。

并且，由于类似这样的集群资源，其生命周期往往都不会很长，所以相应的访问信息也很容易过时，手工维护这些信息费力又不讨好。

增强版OpenShift CLI

针对上面提到的问题，我在这里向大家推荐的一个解决方法，是使用增强版的OpenShift CLI。

如果你接触过OpenShift集群，那么对OpenShift CLI（即oc命令）一定不会陌生。它是一个命令行工具，可以用来管理OpenShift集群，非常类似于管理标准Kubernetes集群的命令行工具kubectl。

增强版OpenShift CLI（或增强版oc）并非是对原有oc命令的替换。它实际上是一个运行在原有oc命令之上的shell脚本。通过使用增强版oc，我们可以高效而安全的管理大量的OpenShift集群。

增强版oc除了支持原有oc的全部命令以外，还提供了以下几个有趣的功能：

只有在第一次登录集群时需要提供完整的登录信息，后续只要提供代表该集群的别名即可完成再次登录。
可以把数量巨大的集群以层级化方式进行管理，并在这些集群之间实现快速切换，输入集群别名时允许只输入部分名字，支持模糊查询，并和shell prompt做了很好的集成。
支持把集群的上下文信息分享给其他人，实现多人团队协作过程中的共享集群管理。

增强版OpenShift CLI之所以能提供上述这些神奇的功能，都是因为它底层使用了gopass，一款用go开发的密码管理软件。它把集群的访问信息存入了由gopass维护的secret store，并将这些信息和一个易于记忆的别名关联起来。此外，增强版oc对原有oc进行了封装，修改了oc命令的输入参数，使得用户可以在使用oc命令登录集群时指定集群的别名作为输入参数。

不仅如此，由于gopass天生具备的一些特征，增强版oc还能做很多别的事，比如：

gopass是以层级化的文件夹及文件结构对secret进行管理的：这使我们能够同样以层级化的方式对集群访问信息进行管理，从而能够支持数量非常多的集群。
gopass在查询secret时支持非精确匹配：这使我们能够在通过别名对集群访问信息进行查询时同样也支持非精确查询及模糊查询。
gopass是以git库的形式来维护secret store的：这使得我们能够把本地的secret store分享到远程，从而让团队中的其他人也能访问到这些信息。这对于一个需要团队协作的大规模项目而言是非常有价值的。

小结

本文中，我们讨论了一种高效而安全的管理OpenShift集群的方案。这一方案是基于密码管理工具gopass，以及一个封装了oc命令的shell脚本来实现的。并且，由于gopass天生具备的一些特征，它为我们带来了很多有趣的功能，比如：对集群访问信息进行层级化管理，支持集群别名的非精确查询及模糊查询，允许把本地的集群访问信息分享给远程。

在下一篇文章里，我将和大家分享如何安装增强版oc，并为大家演示它的一些用法。

集成KubeAssert与KUTTL

2021-07-10T00:00:00+08:00

KubeAssert是一个kubectl插件，用于在命令行声明针对Kubernetes资源的断言（assertion）。KubeAssert是一个位于GitHub上的开源项目。

作为KubeAssert系列文章的第四篇，本文将向大家介绍，如何把KubeAssert和KUTTL集成在一起，让针对Kubernetes集群的自动化测试如虎添翼。

关于KUTTL

KUbernetes Test TooL (KUTTL)是一个Kubernetes的自动化测试工具，它利用YAML语法，提供了以声明式手段对Kubernetes进行测试的方法。KUTTL能在测试准备阶段动态注入即将要被测试的operator，并允许以YAML文件的形式对测试用例进行描述。测试过程中出现的断言，通常也是一系列YAML文件，用来验证Kubernetes资源的状态字段是否满足预期条件。此外，KUTTL也可以被用来实现Kubernetes集群的自动化部署。获取有关KUTTL的更多信息，可以访问它的网站。

结合KubeAssert与KUTTL

在KUTTL里，测试的断言是用YAML语言来定义的。我们可以用YAML语法来描述某个Kubernetes对象是否匹配指定的对象名称，或者相应的状态字段。如果我们为对象指定了预期的名称，KUTTL就会在集群中查找匹配该条件的Kubernetes对象。例如，假设我们定义的断言如下所示：

apiVersion: v1
kind: Pod
metadata:
 name: my-pod
status:
 phase: Successful

那么KUTTL就会在运行测试用例的namespace里寻找名为my-pod的pod资源，并等待其字段status.phase的值变成Successful。

然而，KUTTL的断言表达能力非常有限。例如，默认情况下，KUTTL是无法用这种YAML格式的断言来验证pod的重启次数小于某个期望数值的，它也无法验证没有pod处于terminating状态这样的情况。这就是KubeAssert的用武之地了！

幸运的是，从v0.9.0开始，KUTTLE允许用户在声明断言时指定命令行命令或脚本文件。这就给了我们把KubeAssert和KUTTL集成在一起的机会，从而允许我们能写出更加灵活而强大的断言来。

用KubeAssert编写KUTTL断言

接下来，让我们以KUTTL官网上的“Writing Your First Test”为例，看一下我们是如何把它改造成用KubeAssert来编写断言的。

创建测试用例

首先，我们来创建一个tests/e2e目录，作为存放所有测试用例的根目录，并在该目录下创建example-test子目录，代表对应的测试用例：

mkdir -p tests/e2e/example-test

接下来，在tests/e2e/example-test/目录下创建测试步骤00-install.yaml，用于创建一个名为example-deployment的deployment：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: example-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80

然后，创建测试断言tests/e2e/example-test/00-assert.yaml：

apiVersion: kuttl.dev/v1beta1
kind: TestAssert
commands:
- command: kubectl assert exist-enhanced deployment example-deployment -n $NAMESPACE --field-selector status.readyReplicas=3

此处，我们使用了TestAssert，并通过command定义调用了KubeAssert。判断如果example-deployment的status.readyReplicas字段取值为3，则认为测试步骤执行完毕。请注意，我们在这里使用了环境变量$NAMESPACE。这是KUTTL提供的，用来指明当前测试所在的namespace。

编写第二个测试步骤

在第二个测试步骤里，我们把deployment的replica数从3增加到了4。这是在tests/e2e/example-test/01-scale.yaml中定义的：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: example-deployment
spec:
  replicas: 4

为此，我们在tests/e2e/example-test/01-assert.yaml中利用KubeAssert定义了相应的断言：

apiVersion: kuttl.dev/v1beta1
kind: TestAssert
commands:
- command: kubectl assert exist-enhanced deployment example-deployment -n $NAMESPACE --field-selector status.readyReplicas=4

此处，我们所声明的断言几乎和前一个测试步骤里定义的一摸一样。唯一的区别是，我们把status.readyReplicas的期望值改成了4。

执行该测试用例并验证测试是否通过：

kubectl kuttl test - start-kind=true ./tests/e2e/

有关这一示例的更多信息，请访问位于KUTTL网站上的原文。

小结

如你所见，把KubeAssert与KUTTL集成在一起非常的容易。本文中，我们只演示了KubeAssert的几个非常基本的断言功能。根据实际需要，我们还可以在编写KUTTL的测试用例时定义更加复杂的KubeAssert断言。

如果你想了解更多有关KubeAssert的信息，请阅读它的在线文档。如果你喜欢这个项目，欢迎给它加星。同时，也非常欢迎针对该项目的任何形式的贡献，比如bug报告以及代码提交。

为KubeAssert定制断言

2021-07-03T00:00:00+08:00

KubeAssert是一个kubectl插件，用于在命令行声明针对Kubernetes资源的断言（assertion）。KubeAssert是一个位于GitHub上的开源项目。

作为KubeAssert系列文章的第三篇，本文将向大家介绍，当现有断言无法满足需求的时候，如何通过编写自己的断言来扩展KubeAssert的能力。

自己动手写断言

虽然KubeAssert默认提供的断言可以支持Kubernetes集群日常操作的很多场景，但是，也有可能这些断言并不能满足你的特定需求。KubeAssert支持定制断言，它允许你自己动手编写断言，然后让KubeAssert加载并运行。

作为一个例子，本文我们将编写一个自定义断言，用来验证kubeconfig里是否包含指定的集群。其中，集群的名称是在该断言被执行的时候通过命令行参数传入的。

创建Shell脚本文件

首先，让我们创建一个shell脚本文件，取名为custom-assertions.sh，并将它放到$HOME/.kubeassert目录下。这里是KubeAssert加载所有断言的地方。每当KubeAssert启动时，它会寻找该目录下的所有.sh文件，并作为断言加载到内存。

一个脚本文件可以包含多个断言，每个断言都是通过shell函数来实现的。本例中，我们只有一个断言，对应函数名是cluster，目前函数体还是空的：

#!/bin/bash
function cluster {
 :
}

为了测试断言，我们可以调用kubectl assert命令，并指定函数名cluster，作为该断言的名字：

kubectl assert cluster
ASSERT PASS

正常情况下，我们会看到命令能够正确返回，只是返回结果是空的。接下来，让我们为函数加入具体的实现逻辑。

实现断言的逻辑

为了实现一个断言，通常我们需要做下面这几件事情：

验证输入参数：在本例中，就是由用户通过命令行输入的集群名。如果验证失败，比如用户没有指定集群名，可以调用函数logger::error输出错误信息，然后以非零值立即返回并退出断言。
打印断言信息：通过调用函数logger::assert，我们可以在命令行打印出一条断言信息，以便告诉用户这个断言即将要做的事情。
执行断言逻辑：作为断言的主体部分，此处通常会调用一系列kubectl命令或Kubernetes API，例如：调用kubectl config命令，从kubeconfig中查询集群信息。
验证断言结果：通过对kubectl或Kubernetes API的返回结果进行解析，判断断言成功与否。如果断言失败，则调用函数logger::fail输出一条断言失败的信息。如果成功，则不需要做任何事情，或者也可以根据需要调用logger::info函数打印一些日志信息。

将下列逻辑加入cluster函数：

#!/bin/bash
function cluster {
  # Validate input arguments
  [[ -z $1 ]] && logger::error "You must specify a cluster name." && exit 1
  # Print assertion message
  logger::assert "Cluster with name $1 should be included in kubeconfig."
  # Run some kubectl commands
  kubectl config get-clusters
  # Validate results
  if cat $HOME/.kubeassert/result.txt | grep -q ^$1$; then
    # Print normal logs
    logger::info "Found $1 in kubeconfig."
  else
    # Print failure message
    logger::fail "$1 not found."
  fi
}

可能你已经注意到了，函数中对于断言结果的验证，是通过解析一个位置处于$HOME/.kubeassert/目录下的名为result.txt的文件实现的。KubeAssert把调用kubectl的返回结果都存入了该文件。

现在，让我们试一下执行该断言时不指定集群名的情况：

kubectl assert cluster
ERROR You must specify a cluster name.

结果报错，并提示调用断言时必须指定集群名。再试一下指定一个kubeconfig中不存在的集群名：

kubectl assert cluster kind
ASSERT Cluster with name kind should be included in kubeconfig.
ASSERT FAIL kind not found.

结果显示断言失败，并给出了原因。指定一个kubeconfig中存在的集群名：

kubectl assert cluster kind-foo
ASSERT Cluster with name kind-foo should be included in kubeconfig.
INFO Found kind-foo in kubeconfig.
ASSERT PASS

这次结果显示断言成功了。

如果断言执行过程中遇到了问题，需要进行排查，我们也可以在执行断言时加上-v参数，以打开详细日志输出的开关。这样，我们就可以看到断言中涉及了哪些kubectl调用，以及它们各自的返回结果是什么。

kubectl assert cluster kind-foo -v
ASSERT Cluster with name kind-foo should be included in kubeconfig.
INFO kubectl config get-clusters
NAME
kind-foo
kind-bar
INFO Found kind-foo in kubeconfig.
ASSERT PASS

为断言添加注释

到目前为止，我们已经实现了断言的全部逻辑。不过，还有一件事情我们需要做。当执行kubectl assert并带着-h/--help参数或者不带任何参数时，为了能够让我们的断言出现在已安装断言的列表里，我们还需要为断言添加一个特别的注释。

此外，当我们执行kubectl assert <assertion>命令并带着-h/--help参数时，为了能够打印输出针对该断言的帮助信息，我们还需要提前准备好相应的帮助信息。这些信息也是通过断言注释添加的。

为断言添加的注释必须以##开头，并以##结尾，两者之间包含了若干个字段，每个字段的名字都是以@打头的。下面是一个注释模版，包含了每个字段的详细解释：

##
# @Name: <Input your single-line assertion name here>
# @Description: <Input your single-line assertion description here>
# @Usage: <Input your single-line assertion usage information here>
# @Options:
# <Input help information for all your options started from here>
# <It supports multiple lines>
# @Examples:
# <Input detailed information for all examples started from here>
# <It supports multiple lines>
##

对于Options字段，KubeAssert提供了几个预定义变量可供我们使用。如果我们的断言支持某些KubeAssert预定义的通用Option，那么在定义Options字段时，我们就可以引用这些预定义变量作为占位符。在输出实际的帮助信息时，KubeAssert会把这些占位符替换成真正的内容。

${GLOBAL_OPTIONS}：该变量代表了适用于所有断言的全局Option，比如：用于输出帮助信息的-h/--help。
${SELECT_OPTIONS}：该变量代表了用于对资源进行过滤的Option，比如：用于标签过滤的-l/--selector，以及用于指定namespace的-n/--namespace。
${OP_VAL_OPTIONS}：该变量代表了比较运算符，例如：-eq，-lt，-gt，-ge，-le。

通过使用这些变量，我们可以确保所有断言的帮助信息里涉及这些Option的描述都是一致的。

下面是针对cluster断言的注释内容：

##
# @Name: cluster
# @Description: Assert specified cluster included in kubeconfig
# @Usage: kubectl assert cluster (NAME) [options]
# @Options:
# ${GLOBAL_OPTIONS}
# @Examples:
# # To assert a cluster is included in kubeconfig
# kubectl assert cluster kind-foo
##
function cluster {
 ...
}

为了验证，我们可以执行如下命令，看一下我们的断言是否已经出现在已安装断言的列表中了：

kubectl assert --help

如果一切正常，我们会在返回结果中找到cluster。执行如下命令，打印输出断言的帮助信息：

kubectl assert cluster --help

我们会看到如下输出结果，这正是我们在注释里定义的内容：

Assert cluster with specified name included in kubeconfig file
Usage: kubectl assert cluster (NAME) [options]
Options:
  -h, --help: Print the help information.
  -v, --verbose: Enable the verbose log.
  -V, --version: Print the version information.

小结

断言cluster的最终版本如下：

#!/bin/bash
##
# @Name: cluster
# @Description: Assert specified cluster included in kubeconfig
# @Usage: kubectl assert cluster (NAME) [options]
# @Options:
#   ${GLOBAL_OPTIONS}
# @Examples:
#   # To assert a cluster is included in kubeconfig
#   kubectl assert cluster kind-foo
##
function cluster {
  # Validate input arguments
  [[ -z $1 ]] && logger::error "You must specify a cluster name." && exit 1
  # Print assertion message
  logger::assert "Cluster with name $1 should be included in kubeconfig."
  # Run some kubectl commands
  kubectl config get-clusters
  # Validate results
  if cat $HOME/.kubeassert/result.txt | grep -q ^$1$; then
    # Print normal logs
    logger::info "Found $1 in kubeconfig."
  else
    # Print failure message
    logger::fail "$1 not found."
  fi
}

如你所见，为KubeAssert定制断言是非常容易的。在下一篇文章里，我将和大家分享，如何把KubeAssert和KUTTL集成在一起，让针对Kubernetes集群的自动化测试如虎添翼。

高效使用KubeAssert

2021-06-26T00:00:00+08:00

KubeAssert是一个kubectl插件，用于在命令行声明针对Kubernetes资源的断言（assertion）。KubeAssert是一个位于GitHub上的开源项目。

作为KubeAssert系列文章的第二篇，本文将和大家分享一些有关KubeAssert使用的技巧。

使用多个Label及Field Selector

当使用像exist或not-exist这样的断言，对Kubernetes资源进行验证时，我们可以利用label selector或field selector对返回的查询结果进行过滤。例如，为了验证foo namespace下存在标签app值为echo的pod，且处于Running状态，我们可以采用下面的断言，并同时指定label selector和field selector：

kubectl assert exist pods \
  -l app=echo --field-selector status.phase=Running -n foo

我们还可以在同一个断言里根据需要同时指定多个label及field selector。例如，为了验证位于指定namespace下的处于Running状态的pod同时满足多个标签及其取值，我们可以这样声明断言：

kubectl assert exist pods -l app=echo -l component=proxy \
  --field-selector metadata.namespace==foo \
  --field-selector status.phase=Running \
  --all-namespaces

或者，我们也可以用一个-l或--field-selector参数后跟一个逗号分隔的列表，达到同样的效果。例如，下面的断言和之前的断言效果一样，但看起来更加紧凑：

kubectl assert exist pods -l app=echo,component=proxy \
  --field-selector metadata.namespace==foo,status.phase=Running \
  --all-namespaces

使用增强的Field Selector

当使用exist或not-exist断言对Kubernetes资源进行验证时，尽管我们可以通过指定field selector对查询结果进行过滤，但是这种field selector的功能是非常受限的。这是因为exist和not-exist在底层都是利用kubectl get来实现针对资源的查询的，并且它们都是直接用的由kubectl提供的原生--field-selector参数。但是根据Kubernetes官方文档，这种通过字段进行过滤的操作是在服务器端完成的，而且Kubernetes在服务器端根据资源类型的不同，只支持非常有限的字段查询能力。举个例子，当对pod声明断言时，我们可以使用field selector针对status下的某些字段进行过滤查询。但是同样的过滤条件对于deployment却不适用：

kubectl assert exist deployments -l app=echo --field-selector status.replicas=1
ASSERT deployments matching label criteria 'app=echo' and field criteria 'status.replicas=1' should exist.
Error from server (BadRequest): Unable to find "extensions/v1beta1, Resource=deployments" that match label selector "app=echo", field selector "status.replicas=1": "status.replicas" is not a known field selector: only "metadata.name", "metadata.namespace"
ASSERT FAIL Error getting resource(s).

由于这个原因，KubeAssert提供了两个额外的断言，exist-enhanced和not-exist-enhanced，它们提供了和exist以及not-exist同样的功能，但是对field selector做了增强。因此，我们可以将上述针对deployment的断言改写如下：

kubectl assert exist-enhanced deployments -l app=echo --field-selector status.replicas=1
ASSERT deployments matching label criteria 'app=echo' and field criteria 'status.replicas=1' should exist.
INFO   Found 1 resource(s).
NAME   NAMESPACE   COL0
echo   default     1
ASSERT PASS

原生的field selector支持=，==，以及!=操作符，其中=和==含义相同。而经过增强的field selector除了支持这些操作符以外，甚至还支持正则表达式匹配符=~。这使得我们在定义field selector时变得更加灵活和强大。下面是几个例子：

验证foo namespace下的service account是否包含指定的secret：

kubectl assert exist-enhanced serviceaccounts --field-selector 'secrets[*].name=~my-secret' -n foo

验证某个custom resource的status下面，至少有一个condition，其type的取值为Deployed：

kubectl assert exist-enhanced MyResources --field-selector 'status.conditions[*].type=~Deployed'

验证某个custom resource的所有实例名都是以foo，bar，或baz打头的：

kubectl assert exist-enhanced MyResource --field-selector metadata.name=~'foo.*|bar.*|baz.*'

验证Pod的状态

尽管原则上我们可以利用exist，not-exist，exist-enhanced，以及not-exist-enhanced对pod的状态进行验证，但是要在一条命令里用这些断言完成针对pod的某些验证是非常复杂的。

为了方便起见，KubeAssert为我们提供了几个专门针对pod的断言，它们都是以pod-打头的。用它们对pod的状态进行验证，可以变得更加高效：

pod-ready用于验证pod的就绪状态；
pod-restarts用于验证pod的重启次数；
pod-not-terminating用于验证pod是否处于terminating状态；

这里有几个例子。

验证某个namespace下或所有namespace下的所有pod都处于就绪状态：

kubectl assert pod-ready pods -n foo
kubectl assert pod-ready pods --all-namespaces

验证某个namespace下或所有namespace下都不存在任何处于terminating状态的pod：

kubectl assert pod-not-terminating -n foo
kubectl assert pod-not-terminating --all-namespaces

验证某个namespace下或所有namespace下的pod，其重启次数都小于指定数值：

kubectl assert pod-restarts -lt 10 -n foo
kubectl assert pod-restarts -lt 10 --all-namespaces

检查处于Terminating状态的对象

虽然pod-not-terminating可以被用来检查pod是否处于terminating状态，但并非只有pod才有可能遇到这种情况。如果想检查除pod以外的其他Kubernetes资源是否也存在这种情况，可以使用exist-enhanced，not-exist-enhanced，或者编写自己的断言。

例如，假如要判断某个custom resource在任何namespace下都不存在处于terminating状态的对象，我们可以检查它是否有元数据deletionTimestamp，且status.phase字段为Running。当一个资源被删除时，Kubernetes会自动为其加上deletionTimestamp元数据。如果一个资源被删除，但同时还保持运行状态，那它就很可能是一个陷入terminating状态的对象：

kubectl assert not-exist-enhanced MyResources --field-selector metadata.deletionTimestamp!='<none>',status.phase==Running --all-namespaces

再来看一个例子，为了判断集群里没有处于terminating状态的namespace，我们可以检查namespace是否同时具备deletionTimestamp元数据和finalizer。如果满足这一条件，就说明该namespace很有可能陷入了terminating状态，因为只要namespace有finalizer存在，Kubernetes就不会主动把它删除。

kubectl assert not-exist-enhanced namespace --field-selector metadata.deletionTimestamp!='<none>',spec.finalizers[*]!='<none>'

小结

如你所见，利用各种不同的断言以及相应的参数组合，我们可以非常灵活的对Kubernetes资源进行检验。在下一篇文章里，我将和大家分享，当现有断言无法满足需求的时候，如何通过编写自己的断言来扩展KubeAssert的能力。

KubeAssert快速入门

2021-06-19T00:00:00+08:00

KubeAssert是一个kubectl插件，用于在命令行声明针对Kubernetes资源的断言（assertion）。KubeAssert是一个位于GitHub上的开源项目。

作为KubeAssert系列文章的第一篇，本文将告诉你什么是KubeAssert，如何安装并运行KubeAssert。

什么是KubeAssert

KubeAssert是一个kubectl插件，它提供了一组断言（assertion），可以用于在命令行对Kubernetes资源进行判断。利用KubeAssert，可以帮助我们检查和分析Kubernetes集群的状态，集群中资源的部署情况。例如，我们可以通过KubeAssert来判断：

某个资源是否存在于当前集群中；
某个资源的状态是否满足指定条件；
某个资源的实例数是否小于或等于指定数值；

使用KubeAssert声明针对Kubernetes资源的断言和我们在代码里用xUnit编写单元测试中的断言非常类似。将这样的一组断言放到一个脚本文件里，可以作为针对Kubernetes集群的自动化测试的一部分，和CI/CD pipeline进行集成。

安装KubeAssert

由于KubeAssert本质上是由脚本实现的，所以它可以作为一个独立的命令在命令行执行。但同时，它也可以被安装成一个kubectl插件，这样我们就可以像执行普通的kubectl <command>命令那样执行KubeAssert了。

KubeAssert目前已被提交至krew。作为Kubernetes社区官方的kubectl插件管理工具，krew提供了krew-index，用于在社区范围内集中发布与分享kubectl插件。因此，安装KubeAssert最简单的方式就是使用krew：

krew install assert

如果没有安装krew，也没关系。我们可以从GitHub库将其下载到本地，并将文件设置为可执行：

curl -L https://raw.githubusercontent.com/morningspace/kubeassert/master/kubectl-assert.sh -o kubectl-assert
chmod +x kubectl-assert

把脚本文件放到任何PATH环境变量能够找到的地方，比如：

mv ./kubectl-assert /usr/local/bin

然后，我们就可以像执行普通的kubectl命令那样调用KubeAssert了：

kubectl assert

执行上述命令，将会返回KubeAssert的帮助信息，以及一个KubeAssert当前支持的断言清单。如果在执行kubectl assert命令时指定了断言的名字以及--help参数，就会得到更多有关雨如何使用相应断言的详细信息。例如：

kubectl assert exist --help

使用KubeAssert

以下给出的是目前为止KubeAssert默认提供的所有断言：

Assertion	Description
exist	Assert resource should exist.
not-exist	Assert resource should not exist.
exist-enhanced	Assert resource should exist using enhanced field selector.
not-exist-enhanced	Assert resource should not exist using enhanced field selector.
num	Assert the number of resource should match specified criteria.
pod-ready	Assert pod should be ready.
pod-not-terminating	Assert pod should not keep terminating.
pod-restarts	Assert pod restarts should match specified criteria.
apiservice-available	Assert API service should be available.

这里给出了一些例子，演示了如何利用这些断言来帮助我们对Kubernetes集群中的资源进行检查。

检查foo namespace下是否存在任何满足标签app取值为echo的pod：

kubectl assert exist pods -l app=echo -n foo

检查是否所有namespace下的pod都处于就绪（ready）状态：

kubectl assert pod-ready --all-namespaces

检查pod的重启次数小于指定数值：

kubectl assert restarts pods -n foo -lt 10

小结

如你所见，KubeAssert的使用非常简单。在下一篇文章里，我将和大家分享更多有关KubeAssert使用的技巧。

编写自己的Kube Macro

2021-06-12T00:00:00+08:00

KubeMacro是一个kubectl插件，它用于把一组针对于kubectl命令或Kubernetes API的调用封装成一个命令，以便于在命令行多次执行。KubeMacro是一个位于GitHub上的开源项目。

作为KubeMacro系列的第三篇文章，本文将向大家介绍如何编写一个kube macro。

自己动手写Macro

KubeMacro本质上是一个kube macro的执行器。默认情况下，它并不绑定任何预定义的macro。我们可以通过访问 KubeMacro Hub 网站浏览并安装由他人开发的kube macro。

如果现有的macro无法满足需求，你也可以编写属于你自己的macro。本文里，我将带着大家一步一步编写出一个macro，用于打印一组pod及其所包含的容器。此外，也非常欢迎大家把自己开发的macro提交到KubeMacro Hub，这样其他人也可以从中获益。

创建Shell脚本文件

首先，让我们创建一个shell脚本文件，取名为get-pod-containers.sh，并将它放到$HOME/.kubemacro目录下。这里是KubeMacro加载所有macro的地方。每当KubeMacro启动时，它会寻找该目录下的所有.sh文件，并作为macro加载到内存。

在这个脚本文件里，我们是通过一个shell函数来实现macro的逻辑的。在我们的例子里，这个函数的名字是get-pod-containers，目前函数体还是空的：

#!/bin/bash
function get-pod-containers {
 :
}

为了测试这个macro，我们可以调用kubectl macro命令，并指定函数名get-pod-containers作为该macro的名字：

kubectl macro get-pod-containers

正常情况下，我们会看到命令能够正确返回，只是返回结果是空的。接下来，让我们为函数加入具体的实现逻辑。

实现Macro的逻辑

将下列逻辑加入get-pod-containers函数：

#!/bin/bash
function get-pod-containers {
  local args=()
  local ns=''
  # Parse the arguments input from command line
  while [[ $# -gt 0 ]]; do
    case "$1" in
    -n|--namespace|-n=*|--namespace=*)
      ns=$2
      args+=("$1 $2")
      shift
      shift ;;
    -A|--all-namespaces)
      ns="all namespaces"
      args+=("$1")
      shift ;;
    *)
      args+=("$1")
      shift ;;
    esac
  done
  # Run kubectl get and define custom columns to include pod container names
  local custom_columns="NAME:.metadata.name,CONTAINERS:.spec.containers[*].name"
  if [[ $ns == "all namespaces" ]]; then
    custom_columns="NAMESPACE:.metadata.namespace,$custom_columns"
  fi
  kubectl get pods ${args[@]} -o custom-columns=$custom_columns
}

大体而言，上述函数做了两件事情：

解析从命令行传入的输入参数。
执行kubectl get命令，并定制了输出列，通过指定JSONPath，把从pod定义中解析得到的容器名显示输出。

现在，让我们再次执行该macro。这一次我们会看到，命令会把所有位于当前namespace下的pod及其容器都返回回来：

kubectl macro get-pod-containers

为Macro添加注释

到目前为止，我们已经实现了macro的全部逻辑。是不是很简单啊？不过，还有一件事情我们需要做。当执行kubectl macro并带着-h/--help参数或者不带任何参数时，为了能够让我们的macro出现在已安装macro的列表里，我们还需要为macro添加一个特别的注释。

此外，当我们执行kubectl macro <macro>命令并带着-h/--help参数时，为了能够打印输出针对该macro的帮助信息，我们还需要提前准备好相应的帮助信息。这些信息也是通过macro注释添加的。

不仅如此，如果你希望通过KubeMacro Hub把自己的macro分享给其他人，为macro定义更为详细的描述说明与使用方法同样也必须通过这个macro注释来实现。

为macro添加的注释必须以##开头，并以##结尾，两者之间包含了若干个字段，每个字段的名字都是以@打头的。下面是一个注释模版，包含了每个字段的详细解释：

##
# @Name: <Input your single-line macro name here>
# @Description: <Input your single-line macro description here>
# <Input detailed description for your macro started from here>
# <It supports multiple lines and markdown syntax>
# @Author: <Input single-line author name here, support markdown syntax>
# @Usage: <Input your single-line macro usage information here>
# @Options:
#   <Input help information for all your options started from here>
#   <It supports multiple lines>
# @Examples:
#   <Input detailed information for all examples started from here>
#   <It supports multiple lines>
# @Dependencies: <Input single-line comma-separated dependencies of your macro here>
##

下面是针对get-pod-containers的注释内容：

##
# @Name: get-pod-containers
# @Description: List the pods with their containers.
#
# This is a sample macro to demonstrate how to write a macro by your own.
# It can be used to list pods and their containers. For example, to list
# all pods and their containers in `kube-system` namespace:
# ```shell
# kubectl macro get-pod-containers -n kube-system
# NAME                                         CONTAINERS
# coredns-6955765f44-gtx2q                     coredns
# coredns-6955765f44-tz96m                     coredns
# etcd-kind-control-plane                      etcd
# kindnet-4pzm7                                kindnet-cni
# kube-apiserver-kind-control-plane            kube-apiserver
# kube-controller-manager-kind-control-plane   kube-controller-manager
# kube-proxy-b6wn8                             kube-proxy
# kube-scheduler-kind-control-plane            kube-scheduler
# ```
#
# @Author: [morningspace](https://github.com/morningspace/)
# @Usage: kubectl macro get-pod-containers [options]
# @Options:
#   -A, --all-namespaces=false: If present, list the requested object(s) across all namespaces. Namespace in current
#   context is ignored even if specified with --namespace.
#   -h, --help: Print the help information.
#   -n, --namespace='': If present, the namespace scope for this CLI request.
#   -l, --selector='': Selector (label query) to filter on, not including uninitialized ones.
#       --version: Print the version information.
#   -w, --watch=false: After listing/getting the requested object, watch for changes. Uninitialized objects are excluded
#   if no object name is provided.
#       --watch-only=false: Watch for changes to the requested object(s), without listing/getting first.
# @Examples:
#   # To list all pods with their containers in a namespace.
#   kubectl macro get-pod-containers -n foo
#   # To list all pods with their containers in all namespaces.
#   kubectl macro get-pod-containers -A
# @Dependencies: kubectl
##
function cluster {
  ...
}

为了验证，我们可以执行如下命令，看一下我们的macro是否已经出现在已安装macro的列表中了：

kubectl macro --help

如果一切正常，我们会在返回结果中找到get-pod-containers。执行如下命令，打印输出macro的帮助信息：

kubectl macro get-pod-containers --help

我们会看到如下输出结果，这正是我们在注释里定义的内容：

get-pod-containers: List the pods with their containers.
Usage: kubectl macro get-pod-containers [options]
Options:
  -A, --all-namespaces=false: If present, list the requested object(s) across all namespaces. Namespace in current
  context is ignored even if specified with --namespace.
  -h, --help: Print the help information.
  -n, --namespace='': If present, the namespace scope for this CLI request.
  -l, --selector='': Selector (label query) to filter on, not including uninitialized ones.
      --version: Print the version information.
  -w, --watch=false: After listing/getting the requested object, watch for changes. Uninitialized objects are excluded
  if no object name is provided.
      --watch-only=false: Watch for changes to the requested object(s), without listing/getting first.
Examples:
  # To list all pods with their containers in a namespace.
  kubectl macro get-pod-containers -n foo
  # To list all pods with their containers in all namespaces.
  kubectl macro get-pod-containers -A

关于Macro的依赖

也许你已经注意到了，在前面的macro注释里有一个@Dependencies字段。一个macro可能会包含多个依赖。比如，有的macro需要用jq命令来解析JSON数据，有的macro则依赖于其他macro来共同完成一项任务。为了成功执行一个macro，需要确保其所依赖的部分已经事先安装好了。

当编写一个macro的时候，我们可以根据需要为macro定义它的依赖。每当KubeMacro执行一个macro时，它首先会检查该macro是否存在任何依赖。如果有的话，KubeMacro会检查这些依赖是否已存在。如果不存在，则会报错。

小结

get-pod-containers的最终版本可以从这里找到。至此，我们可以看到，编写一个kube macro是非常容易的。如果你发现现有macro都不能满足你的需求时，那就自己动手写一个吧。你还可以以pull request的形式把macro提交到KubeMacro Hub的GitHub库。一旦被成功合并，其他人也能从中获益。

如果你想了解更多有关KubeMacro的信息，请阅读它的在线文档。如果你喜欢这个项目，欢迎给它加星。同时，也非常欢迎针对该项目的任何形式的贡献，比如bug报告以及代码提交。

KubeMacro Hub：寻找你的Kube Macro

2021-06-05T00:00:00+08:00

KubeMacro是一个kubectl插件，它用于把一组针对于kubectl命令或Kubernetes API的调用封装成一个命令，以便于在命令行多次执行。KubeMacro是一个位于GitHub上的开源项目。

作为KubeMacro系列的第二篇文章，本文首先将会向大家介绍KubeMacro Hub，一个用于发布和分享kube macro的网站，然后介绍几个通过该网站发布的，非常有意思的macro，以及它们的使用方法。

什么是KubeMacro Hub

KubeMacro Hub就像是一个kube macro的“集散地”，它为人们在社区范围内发布和分享kube macro提供了一个集中的场所。你可以在这里浏览由别人开发的macro，也可以把你自己开发的macro通过KubeMacro Hub分享给别人，以便让大家都能够从中获益。

如果你想把自己的macro贡献给社区，只需要向KubeMacro Hub的GitHub库提交一个pull request。一旦代码被合并，大约几秒钟之后，你的macro就可以出现在KubeMacro Hub的网站上了。在这一系列的后续文章里，我将向大家详细介绍如何编写一个kube macro。

浏览KubeMacro Hub

既然你已经了解了KubeMacro Hub的作用，接下来让我们一起看一下如何浏览KubeMacro Hub网站及其所提供的那些kube macro。

首先让我们打开 KubeMacro Hub 网站，我们可以看到在网站页面的左侧有一个macro的列表，点击其中任意一个macro，会在网页右侧打开该macro的对应详情页面。此外，网页左上方还有一个搜索框，我们可以在里面输入关键词，然后在下方的搜索结果里寻找想要的macro。点击对应的搜索结果，同样会打开macro的详情页面。在macro详情页面的顶部，我们会看到该macro的名称和一个简短的描述。

除此以外，下方还有几个标签页：

标签页	说明
`Description`	提供了有关该macro的详细说明，比如：用途，用法等。
`Usage & Options`	提供了该macro的调用格式，以及所支持的命令行参数。
`Examples`	列举了该macro的一些使用范例，可以供我们在实际使用时参考。
`Dependencies`	列举了该macro在执行过程中需要的所有依赖。为了保证macro的正常执行，这些依赖必须事先安装好。
`Code`	给出了该macro的源代码，我们可以通过阅读代码来了解该macro的工作原理。同时，这个标签页上还有如何安装该macro的说明文字。

如你所见，浏览KubeMacro Hub上的kube macro非常简单，只需在列表里选择你想要的macro，然后阅读详情页面的使用说明，比如了解它的用途，用法，支持的参数，以及参考示例等。最后，下载该macro，或者直接复制粘贴源代码到本地，就大功告成了。

接下来，我将向大家介绍几个KubeMacro Hub上发布的，非常意思的macro，并演示它们的使用方法。

Macro: delete-pod-by-svc

该macro可以用来删除所有和某个Kubernetes service相关联的pod。当我们遇到某些service由于其背后的pod出现故障而无法正常工作的时候，就可以使用这个macro。通过删除这些pod，它能强制触发pod的重启。

众所周知，Kubernetes service的实际功能是由pod来实现的。要找到与service相关联的pod，我们需要查看service的定义，找到spec.selector字段。让我们以下面这个service为例：

kubectl get svc prometheus-adapter -n openshift-monitoring -o yaml

从service定义的spec.selector字段中获知，与该service相关联的pod应该具备prometheus-adapter标签：

apiVersion: v1
kind: Service
metadata:
  name: prometheus-adapter
  namespace: openshift-monitoring
spec:
  clusterIP: 172.30.179.161
  ports:
  - name: https
    port: 443
    protocol: TCP
    targetPort: 6443
  selector:
    name: prometheus-adapter
  sessionAffinity: None
  type: ClusterIP

我们可以列出所有满足这一条件的pod，然后决定是否要删除这些pod：

kubectl get pod -l name=prometheus-adapter  -n openshift-monitoring
NAME                                  READY   STATUS    RESTARTS   AGE
prometheus-adapter-6856976f54-42jzh   0/1     Pending   0          3d
prometheus-adapter-6856976f54-d428c   0/1     Pending   0          3d

每当我们遇到需要重启pod的时候，手工完成上述步骤会非常的繁琐。这个macro的作用就是为了把这一过程完全自动化，我们只需要告诉它service的名字就行了。此外，删除pod的时候，我们还可以指定额外的参数对删除行为进行控制，比如：指定--force参数实现强制删除，指定--dry-run参数实现“dry run”模式下的删除，以便在我们真正决定删除之前做一些检查。

下面是几个实际使用该macro的例子，供大家参考：

# To delete pods associated with a service.
kubectl macro delete-pod-by-svc echo -n foo
# To force delete pods associated with a service.
kubectl macro delete-pod-by-svc echo --force
# To delete pods associated with a service in dry run mode.
kubectl macro delete-pod-by-svc echo --dry-run=client

Macro: get-by-owner-ref

该macro通过遍历Kubernetes资源的metadata.ownerReferences字段，可以用来列举某个namespace下的一个或多个资源及其祖先。

我们知道，在Kubernetes里一些资源和另一些资源存在着从属关系。比如，一组pod可能从属于某个ReplicaSet。ReplicaSet就是pod的owner，而pod则被称为ReplicaSet的dependent。每个dependent对象，都有一个字段，名字叫做metadata.ownerReferences，它指向了对应的owner对象。

利用该macro，当我们手里有一个或多个资源时，可以通过它来揭示这些资源及其祖先资源的从属关系。其输出结果是以树状形式呈现的。例如，要列举名为echo-5ffc7f444f-pj5xj的pod及其祖先，可以执行如下命令：

kubectl macro get-by-owner-ref pod echo-5ffc7f444f-pj5xj -n foo
pod/echo-5ffc7f444f-pj5xj
└──ReplicaSet/echo-5ffc7f444f
   └──Deployment/echoCopy to clipboardErrorCopied

由于该macro背后是通过对kubectl get的调用来实现的，所以我们还可以指定某些kubectl get所支持的参数，从而实现对返回结果的定制。例如，为了展示所有具备指定标签的pod及其从属关系，可以使用-l参数：

kubectl macro get-by-owner-ref pod -l 'app=echo'

上述命令可以打印出所有标签app为echo的pod及其祖先。

我们甚至还可以列举某个namespace下的所有pod资源及其祖先，例如：

kubectl macro get-by-owner-ref pods -n foo

上述命令可以打印出foo namespace下的所有pod及其祖先。

小结

通过本文，我们了解了如何访问KubeMacro Hub网站，浏览并安装相应的kube macro。同时，我们还学习了几个KubeMacro Hub上发布的，非常有意思的macro。欢迎大家访问 KubeMacro Hub 网站，看看上面是否有你所感兴趣的macro。如果没有任何一个macro能满足你的需求，也没关系，你可以选择开发自己的macro，然后提交给KubeMacro Hub在GitHub上的代码库。在下一篇文章里，我将向大家介绍如何编写自己的kube macro。