“「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」[1]。 ”
大家好，我是张晋涛。
本周 KubeCon CloudNativeCon North America 2022 已经结束，看 timeline 有了一种几乎所有人都去参加的错觉， 大概也是受近几年各类因素的影响，很多人也都没有线下聚会之类的。
在这次大会上，有很多有意思的内容，简单的概括一下：
- 当前的 Kubernetes 生态中有太多的工具，在做相同或者类似的事情，所以很多人都会面临"选择困难症"，在工具选择上需要考虑很多方面，比如技术匹配度，学习成本，灵活性，可扩展性，社区以及文档等方面。
- 供应链安全愈发的受到重视 ，很多的公司 & 工具都在积极的添加此类支持。但国内在此方面并不那么重视。我之前写了一本小册 《Kubernetes 安全原理与实践》，其中覆盖了在生产中使用 Kubernetes 需要关注的各方面及其原理等内容，从反馈上看大家对此方面的关注度并不高，当然也有可能是很多公司还处于调研/测试的阶段，尚未真正迈入生产，否则的话，安全还是一个很重要的部分。
- 混沌工程和模糊测试等在工程实践中得到了更多关注和实践，尤其是构建金融级服务时候，产生了更大的价值。
- eBPF, 安全，可观测性等持续让企业从中得到收益，越来越多的公司也选择了相关的技术栈，来丰富自己现有的产品和工具。
- 多集群，多租户，GitOps, 调度，Service Mesh 等仍然在探索中，并且越复杂的环境，其中衍生出来的问题就越多，尤其是需要与其他的一些工具/平台进行集成。
此外就是一些开源项目的发展和技术等内容了，有兴趣的小伙伴可以再去看看。
Sigstore 正式 GA
在本周的 SigstoreCon 上，Sigstore 社区宣布 Sigstore 正式 GA。
在去年 11 月份，我曾写过一篇文章：《云原生时代下的容器镜像安全（上） | MoeLove》其中就有介绍过 Sigstore 以及利用它来提升镜像安全，有兴趣的小伙伴可以回顾下文章。
Sigstore 的出现就是为了应对日益增长的供应链攻击的问题，并且 Sigstore 一经出现，就成为了历史上采用最快的开源技术之一， 迄今为止，已使用 Sigstore 记录了超过 400 万个签名，并且世界上最大的两个开源社区 Kubernetes 和 Python 已使用 Sigstore 进行其生产 release 的签名。最近，npm 宣布他们正在积极整合 Sigstore，因此所有 npm 包都可以可靠地链接到它们的源代码和构建指令。这将极大的提高 Sigstore 的采用率。
此外，无论你在用什么 CI/CD 工具，还是在使用一些云上工具类似 GitHub Action 等都可以很轻松的与 Sigstore 进行集成，以下是一个简单的示例：
代码语言：javascript复制...
jobs:
build:
steps:
# ... build steps here
- uses: sigstore/cosign-installer@main
- name: Write signing key to disk (only needed for `cosign sign --key`)
run: echo "${{ secrets.SIGNING_SECRET }}" > cosign.key
- name: Sign container image
run: |
cosign sign --key cosign.key
ghcr.io/your-org/your-repo:some-tag
env:
COSIGN_PASSWORD: ""
然后在部署之前进行验证：
代码语言：javascript复制$ cosign verify --key cosign.pub ghcr.io/your-org/your-repo:some-tag
Verification for ghcr.io/your-org/your-repo:some-tag --
The following checks were performed on each of these signatures:
- The cosign claims were validated
- The signatures were verified against the specified public key
- Any certificates were verified against the Fulcio roots.
[{"critical":{"identity":{"docker-reference":"ghcr.io/your-org/your-repo"},"image":{"docker-manifest-digest":"sha256:..."},"type":"cosign container image signature"},"optional":{}}]
更多详细信息请参考 Sigstore Announces General Availability at SigstoreCon - Open Source Security Foundation
Kyverno 1.8 正式发布
我之前已经写过一些 Kyverno 相关文章了，感兴趣的小伙伴可以回顾下 《云原生策略引擎 Kyverno （上） | MoeLove》
本次发布的 v1.8 包含了很多值得关注的特性，一起来看看：
YAML Manifest 的验证
Kyverno 之前已经与 Sigstore 进行了集成，可以进行镜像的签名校验（常规功能），本次 1.8 中集成了 Sigstore 的 k8s-manifest-sigstore 工具，通过 这次的集成，Kyverno 还可以验证 Kubernetes YAML manifest 上的签名，以便确保它们没有被篡改。
一旦用户使用私钥对 YAML manifest 进行了签名，就可以使用类似下方示例中的策略文件对其进行校验了。
代码语言：javascript复制apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: verify-manifest-integrity
spec:
validationFailureAction: audit
background: true
rules:
- name: verify-deployment-allow-replicas
match:
any:
- resources:
kinds:
- Deployment
validate:
manifests:
attestors:
- count: 1
entries:
- keys:
publicKeys: |-
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEStoX3dPCFYFD2uPgTjZOf1I5UFTa
1tIu7uoGoyTxJqqEq7K2aqU vy aK76uQ5mcllc TymVtcLk10kcKvb3FQ==
-----END PUBLIC KEY-----
ignoreFields:
- objects:
- kind: Deployment
fields:
- spec.replicas
这里需要注意的是，在 Kubernetes 中对 YAML manifest 签名时，需要考虑哪些内容是需要变更的，比如 spec.replicas 就可能经常发生变更，所以此处需要忽略它。否则当出现变更时候，就会被此策略拒绝。当然也还可以根据实际情况去忽略其他的字段。
与 Pod Security 的集成
作为 Pod Security Policy (PSP) 的替代品，Pod Security Admission（PSA）在 Kuberenetes v1.23 中默认启用，并在 1.25 中达到 stable 状态，PSA 带来了 Pod Security Standards | Kubernetes 。
Kyverno 从 1.8 开始增加了 podSecurity 的验证规则，它使用了和 PSA 相同的库，所以是完全兼容的。以下是一个简单的示例：
代码语言：javascript复制apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: podsecurity-restricted
spec:
background: true
validationFailureAction: audit
rules:
- name: restricted
match:
any:
- resources:
kinds:
- Pod
validate:
podSecurity:
level: restricted
version: latest
它为整个集群实现了 PSA 的 restricted 策略。
上游进展
- Normalize HTTP lifecycle handlers with HTTP probers by jasimmons · Pull Request #86139 · kubernetes/kubernetes
我们可以为 Pod 增加 postStart 和 preStop 的 Hook，并且其分别可以设置为 Exec 或 HTTP 模式。这个 PR 主要是在修改 HTTP 模式下的行为。
具体来说，HTTP 模式下的代码与 readiness/liveness 下使用的并不一样，而且也不支持一些常见的功能，比如：
- 设置自定义 HTTP header
- 使用 HTTPS 连接
但经过此 PR ,终于将它们的行为进行了统一，但这毕竟是一个比较大的调整，如果你不希望应用此变更， 可以通过 -feature-gates=ConsistentHTTPGetHandlers=false 进行全局禁用，避免这个功能影响到你的环境。
其他
- #952 Cilium 正在申请从 CNCF 毕业。
在几年前，部署 Kubernetes 集群选择 CNI 时，Flannel 和 Calico 还是最流行的选项。不过现在 Cilium 也已经成为了一个备选。这有几个方面的原因：
- eBPF 的持续火热，让 cilium 大放异彩；。
- Flannel 不支持 Network Policy 等特性，无法满足企业在安全性方面的需求；
- 越来越多的公司开始将 Linux 内核升级到 5.x 以上了，不像之前总是在用 3.10.x ，所以可以尝试使用 eBPF 等技术了；
- cilium 已经成为了很多厂商的首选，比如 GKE。我之前还写过一篇 K8S 生态周报| Google 选择 Cilium 作为 GKE 下一代数据面 | MoeLove
参考资料
[1]k8s生态: https://zhuanlan.zhihu.com/container
