ko 申请成为 CNCF sandbox 项目

ko-build/ko: Build and deploy Go applications on Kubernetes 是一个专注于为 Go 应用程序构建容器镜像的工具。

当初 ko 的出现是为了给 Knative 项目提供一个使用 Go 项目使用的轻量化构建工具，后来社区中为其逐步增加了很多功能。现在 Knative 已经托管到了 CNCF ，ko 很自然的也应该成为社区项目。目前它已经从原先 Google 的组织下移动到了一个独立的 ko-build 组织下。

使用 ko 可以像使用 go build 那样简单，并且无需 Docker 或者其他容器运行时。如果你的项目仅包含 Go 应用的话，选择使用 ko 也是个比较轻量化的选择。

此外，ko 可以用于构建多架构的镜像，以及生成 SBOM 。

接下来我以 apache/apisix-ingress-controller: APISIX Ingress Controller for Kubernetes 这个 Go 项目为例，进行构建：

➜  apisix-ingress-controller git:(master) ✗ KO_DOCKER_REPO=apisix-ingress ko build . -L
2022/11/06 17:13:23 Using base distroless.dev/static:latest@sha256:0c627e7a97a91ed2049c3da50a915b8577a79821561a5704ec89f6c8972deae2 for github.com/apache/apisix-ingress-controller
2022/11/06 17:13:24 Building github.com/apache/apisix-ingress-controller for linux/amd64
2022/11/06 17:13:27 Loading ko.local/apisix-ingress-controller-29a2b9b3f039e9a9971dc48aef895b48:56a132da8c4b1b8b79053b59d6f45f7c64d0ff0a10664a7000c3c87f43a1aac4
2022/11/06 17:13:28 Loaded ko.local/apisix-ingress-controller-29a2b9b3f039e9a9971dc48aef895b48:56a132da8c4b1b8b79053b59d6f45f7c64d0ff0a10664a7000c3c87f43a1aac4
2022/11/06 17:13:28 Adding tag latest
2022/11/06 17:13:28 Added tag latest
ko.local/apisix-ingress-controller-29a2b9b3f039e9a9971dc48aef895b48:56a132da8c4b1b8b79053b59d6f45f7c64d0ff0a10664a7000c3c87f43a1aac4

➜  apisix-ingress-controller git:(master) ✗ docker image ls ko.local/apisix-ingress-controller-29a2b9b3f039e9a9971dc48aef895b48:56a132da8c4b1b8b79053b59d6f45f7c64d0ff0a10664a7000c3c87f43a1aac4 
REPOSITORY                                                            TAG                                                                IMAGE ID       CREATED       SIZE
ko.local/apisix-ingress-controller-29a2b9b3f039e9a9971dc48aef895b48   56a132da8c4b1b8b79053b59d6f45f7c64d0ff0a10664a7000c3c87f43a1aac4   df3478059f07   7 hours ago   62.9MB

通过加 -L 参数可以将镜像加载到本地的 Docker daemon 中。默认使用 distroless 的镜像作为基础镜像，构建出的镜像体积相对也较小。

同时还可以写一份 .ko.yaml 进行更加详细的配置。对此项目感兴趣的小伙伴可以去尝试下，唯一的限制就只是它仅仅是为 Go 项目使用的，并不够通用。

Trivy v0.34.0 发布

Trivy 我介绍过很多次了，这里就不再展开。Trivy 的这个版本主要增加了一些操作系统上的依赖图支持。比如：

对 CentOS/RHEL 等使用 rpm 系统的支持
对 Debian/Ubuntu 等使用 dpkg 系统的支持
对 Alpine 等使用 apk 系统的支持

K8S 生态周报| Kubernetes 修复了转义漏洞，可以放心的查看资源了第1张

198851146-0a913071-a9a1-44f5-9cb1-db26f7bec6de.png

如上所示，不仅可以显示对应存在漏洞的包，还可以查看其相关的依赖，非常方便用于检查系统漏洞。

上游进展

Escape terminal special characters in kubectl by dgl · Pull Request #112553 · kubernetes/kubernetes

这个 PR 中对一些特殊字符进行了转义。这其实是一个比较有意思的内容，我来稍微介绍一下。

你可以在自己的终端中尝试执行如下命令：

kubectl create -f - <<EOF
{
    "apiVersion": "v1",
    "involvedObject": {
        "kind": "Node",
        "name": "node01",
        "uid": "node01"
    },
    "kind": "Event",
    "message": "\u001b[2J\u001b[3J\u001b[1;1H\u001b[m spoofed \u001b[60C\u001b[1;0m. Done",
    "metadata": {
        "name": "spoofEvent",
        "namespace": "default"
    },
    "source": {
        "component": "kubelet",
        "host": "node01"
    },
    "type": "Normal"
}
EOF

这将会创建一条 event 记录，但是一但你执行 kubectl get events 你就会发现一些有趣的事情，屏幕上的记录被清空了。

这是由于 kubectl 在输出内容的时候并不会进行任何转义，比如上述示例中包含了一些特殊字符：

\u001b[2J：清屏
\u001b[60C: 将光标向前移动 60

当然还有一些其他的，我印象中我早年刚开始接触 Linux 不久后还花费了一些时间来学习这些东西，因为这些东西可以配置到终端里面，实现一些比如变换颜色之类的事情。

我翻了下我之前的文章，曾经还有将 bash 做过如下设置：

function git-branch-name {
  git symbolic-ref HEAD 2>/dev/null | cut -d"/" -f 3
  #git rev-parse --abbrev-ref HEAD
}

function git-branch-prompt {
  local branch=`git-branch-name`
  if [ $branch ]; then printf " [%s]" $branch; fi
}

PS1="\u@\h \[\033[0;36m\]\W\[\033[0m\]\[\033[0;32m\]\$(git-branch-prompt)\[\033[0m\] \$ "

对此内容感兴趣的小伙伴可以试试看把上述内容贴到自己的 .bashrc 文件中，然后 source 一下看看。

回到这个 PR 中，之前这个问题还给分配成了 CVE-2021-25743，修复的办法也比较简单，但是比较耗时耗力，就是对一些输出的位置做了转义操作。

不过可能还有一些遗漏的，比如 kubectl logs 之类的，可能也会受到影响，有兴趣的小伙伴可以去验证一下。