嗨!我是Andrew--Linode的开发者。在构建管理型Kubernetes解决方案的过程中,我发现并创造了几个小技巧,用来使Kubernetes的日常工作更容易。我想在这里与你分享这五个技巧,我希望你能像我一样找到它们的帮助。
1.元贝壳诀窍
我第一次看到这个技巧是在今年欧洲KubeCon大会上Olive Power关于CKA准备的演讲中。
kubectl <command> --help | grep kubectl
每条kubectl命令在其帮助输出中都包含一些例子,这是一个快速的方法,可以一次性看到这些例子。这些例子可以给你一些想法,告诉你如何以有用的方式组合参数和标志,而仅仅通过阅读文档可能并不明显。
目前,kubectl运行命令渲染的例子数量最多:18.然而,我最常使用的命令是kubectl get。让我们来看看它的一个例子:
kubectl get pod test-pod -o custom-columns=CONTAINER:.spec.containers[0].name,IMAGE:.spec.containers[0].image
这个命令改变了kubectl get的输出,只给你这个pod部署的容器版本。通过一些轻微的改动,你可以使输出更加有用。注意,它只请求第一个容器(containers[0])的名称和图像。使用kubectl支持的JSONPath语法,你可以列出所有pod中所有容器的所有版本。
kubectl get pod -o custom-columns=CONTAINER:.spec.containers[*].name,IMAGE:.spec.containers[*].image -A
这个小技巧可以让你不用在各个pod资源中寻找一个金丝雀图像或集群中的版本偏差。有了kgi的别名(并且去掉了命名空间选择器-A),你就可以使用查找集群中运行的kube-apiserver的版本。见下文:
$ kgi -n kube-system -l component=component=kube-apiserver
CONTAINER IMAGE
kube-apiserver k8s.gcr.io/kube-apiserver:v1.14.5
kube-apiserver k8s.gcr.io/kube-apiserver:v1.14.5
kube-apiserver k8s.gcr.io/kube-apiserver:v1.14.5
下面的命令将打印出一个所有内置例子的最新列表。挑选一个你以前从未见过的标志,并进行实验吧
for c in $(kubectl --help | egrep "^\s+([a-z-]+)" -o); do echo -e "$(kubectl $c --help | egrep '^\s+kubectl')"; done
2.获取每个命名空间的内存用量
我们中的一些人知道awk比awk { print $1 }多得多。最近,我更深入地学习了这种令人难以置信的强大语言的基本知识,它是从Unix历史上的一些巨头那里传来的。这里有一个非常有用的awk程序的例子,它仍然很短,可以作为一个单行的别名。它计算并打印出每个命名空间中所有pod所使用的MiB内存数量,并使用awk的printf进行干净的输出,即使你的集群包含长的命名空间名称。当你需要对kubectl输出进行汇总时,可以考虑使用awk。
kubectl top pod -A --no-headers=true | awk '{a[$1] += $4} END {for (c in a) printf "%-35s %s\n", c, a[c]}'
3.查看纯文本中的秘密
当你在开发一个依赖秘密的应用程序时,要找到一种方法将kubectl的输出转为base64,这可能是一件麻烦事。也许你已经写了一个shell管道或一个小脚本来解码它们。我见过一些不同的选项,有各种缺点:不支持多行输出,沿途添加或删除换行,或丢失字段名的上下文。有了Ashley Schuett的kubectl秘密解码插件,你可以在kubectl get输出中以可读形式查看秘密,并避免所有这些问题。
项目文档建议使用curl ,从GitHub上抓取二进制文件并将其添加到我们的路径中。由于这涉及到各种敏感数据,我鼓励你从源代码编译它,并首先审查源代码。幸运的是,这个插件由一个格式良好的源文件组成:
git clone git@github.com:ashleyschuett/kubernetes-secret-decode.git
cd kubernetes-secret-decode
GO111MODULE=off go build -o $GOPATH/bin/kubectl-ksd
最后一步构建的二进制文件的名称必须以kubectl-开头,这样才能被识别为一个插件。确保$GOPATH/bin在你的$PATH上,然后你可以像这样使用它:
kubectl ksd get secret -n <namespace-name> <secret-name> -o yaml
4.最近和以前的日志
如果你有一个可以达到几周或几个月的正常运行时间的服务,容器日志可以增长到一定的规模,使典型的kubectl日志命令产生一个可笑的输出量。你可能会觉得你在测试终端机绘制文本的能力的极限,或者对本应是人类可读的东西所产生的网络流量感到惊讶。在这些情况下,有多种方法可以减少输出并获得你想看到的信息。
首先是 --tail=N
标志,开始打印文件中最近的N行。
kubectl logs --tail=10 -f -n kube-system -l component=kube-apiserver
也有 --since=time
它接受时间间隔,如30s、1h或5m,分别指代秒、小时或分钟的数量。
kubectl logs --since=5m -f -n kube-system -l component=kube-apiserver
另一个我已经开始依赖的日志标志是-p。这将打印容器上一次运行的日志;已经退出的容器的日志。这将使我在使用Kubernetes的头几天变得容易得多,因为我试图在它们再次崩溃之前,通过一些快速的鼠标和键盘操作,重新启动pod,并 "捕捉 "它们的日志。
kubectl logs -p -n kube-system -l component=etcd
5.在你等待时节省时间
每当你想用睡眠命令来写一个循环时,通常有一个更好的方法来做。无论你选择什么样的间隔,你都有可能浪费一或几秒钟。如果这是一个自动化的过程,这可能会增加。这就是kubectl wait命令及其相关的apimachinery包的用处。这个命令允许你在集群中满足条件所需的特定时间内暂停你的脚本。你也可以用它来在新版本进入集群的时候在Slack中发布空气喇叭。好好利用它吧。
这里有一些例子:
kubectl wait --for=condition=Available deployment/metrics-server
kubectl wait --for=condition=Initialized pod/csi-linode-controller-0
可用的条件根据资源类型而不同,可以使用kubectl describe在 "条件:"下发现。一个特定的资源可能同时拥有许多不同的条件。
奖励技巧!
有时你看着输出,希望能显示一些额外的网络或其他信息,对吗?为了帮助你,在命令中加入-owide。这几乎适用于所有的资源类型,而且显示的列可以为自定义资源定义(CRD)定制。例子:
kubectl get pods -A -owide
kubectl get services -A -owide
最后但并非最不重要的是,如果你现在还没有注意到,-A是作为标志的别名而添加的 --all-namespaces
.我猜想,自从该功能推出以来,仅此一项就为世界节省了数百万次的击键。另一个伟大的省时方法是添加 alias k=kubectl
到你的shell rc。
这篇文章主要涉及到了kubectl的内置功能。如果想更深入了解,有一本开源的kubectl书,可以在线阅读。该书重点介绍了Kustomize的使用,这是一个内置的工具,允许你组织和编排你的Kubernetes资源。我强烈推荐这本书,特别是如果你一直在寻找Kubernetes项目框架,其脆弱的表面区域最小。对于其他有用的命令集合,请查看Krew,即kubectl插件的官方软件包管理器。
评论 (2)
Great post Andrew, this is actually cool.
#2, getting memory usage based on namespace is a nice hack, on #3, i’d prefer to use rancher to get most of these information.
What do you think, have you tried rancher before?
Thanks : )
I have used Rancher before, in fact Linode has an official Rancher integration which you can read about here: https://www.linode.com/docs/kubernetes/how-to-deploy-kubernetes-on-linode-with-rancher-2-x/
I do like Rancher for managing access to a cluster, the fact that each user gets a ServiceAccount token proxied through the Rancher deployment is very cool.
For viewing secrets, I still use the technique in #3.