最近最为热门的技术莫过于 ChatGPT 等 AI 方面的技术和应用了。它是这样介绍自己的：

"

ChatGPT 是一个有趣和有用的聊天机器人，它可以帮助人们获取信息、娱乐自己、提高自己的创造力和思维能力。它也是一个不断学习和进步的聊天机器人，它会根据用户的反馈和数据来优化自己的模型和策略。它使用了目前最先进的自然语言处理模型，由 OpenAI 开发，使用了深度学习和大规模数据的方法，能够理解和生成各种自然语言文本。该模型的核心是一个 Transformer 网络，它由 1750 亿个参数组成，可以从大量的无标注文本中学习语言的规律和知识。 "

我也用它做了些尝试，用来写邮件，效果很不错，增加了很多夸夸语，很生动。

本周作为 OpenAI 的唯一公有云服务商的 Microsoft 在 Azure OpenAI Service 上推出了 ChatGPT API，我在第一时间进行了尝试，发现效果还挺好的。

另外就是我并没有花时间去解决 OpenAI Plus 付费的问题，因此用 Azure OpenAI Service 也省心了很多。在推上也发了相关信息

K8S 生态周报| Kubernetes 基于 CEL 的控制系统再添新特性第1张

最近一家做多云管理的公司 Firefly 也创建了一个名叫 AIaC(Artificial Intelligence Infrastructure-as-Code Generator) 的项目，利用 AI 工具来生成一些基础设施即代码的配置。地址在：https://github.com/gofireflyio/aiac 目前已经收到了将近 2K star 。

代码很简单，使用起来也很简单，和在网页版问的区别在于 1. 可以选择模型 2. 生成的内容如果是你需要的，可以直接保存成文件。

示例如下：

$ aiac get dockerfile for nodejs with comments

FROM node:latest

# Create app directory
WORKDIR /usr/src/app

# Install app dependencies
# A wildcard is used to ensure both package.json AND package-lock.json are copied
# where available (npm@5+)
COPY package*.json ./

RUN npm install
# If you are building your code for production
# RUN npm ci --only=production

# Bundle app source
COPY . .

EXPOSE 8080
CMD [ "node", "index.js" ]

可以用来帮 DevOps 工程师们减轻些工作压力和负担。

下周 k8s.gcr.io 将重定向到 registry.k8s.io

我在 K8S 生态周报| Kubernetes 旧的 registry 将被冻结 | MoeLove 和 K8S 生态周报| KSM 即将废弃对 VerticalPodAutoscaler 的支持 | MoeLove 这两篇都有介绍过 registry.k8s.io 的相关信息。

Kubernetes 自 v1.25 起将默认的镜像仓库从 k8s.gcr.io 切换到了 registry.k8s.io ，用于提高 Kubernetes registry 的安全性、可靠性和可扩展性，Kubernetes registry 是在 Kubernetes 集群中分发和运行容器镜像的关键组件。

k8s.gcr.io 本质上是由 Google 提供的镜像服务，Kubernetes 社区的所有基础设施的消费都来自于 Google 的赞助，每年的花费是巨大的。

贴张图感受一下：

K8S 生态周报| Kubernetes 基于 CEL 的控制系统再添新特性第2张

k8s-cost.png

目前也有其他公司对 Kubernetes 社区进行了赞助，比如，Amazon 也宣布了会对 Kubernetes 进行捐赠。当前社区也正在努力吸引其他的供应商来参与项目，以便于给用户提供更高可用的镜像服务，且可以通过 CDN 提升速度。

Kubernetes 社区希望通过本次切换提供一个中立的服务，通过使用各个云厂商提供的镜像服务做为后端服务，实现了镜像仓库的高可用，并且可以在各个厂商之间进行分流，节省开支等。

迁移的挑战包括确保向后兼容性、最小化中断、协调多个利益相关者以及与用户和开发者沟通变更和如何采用它们，这个过程已经持续了很久，下周的重定向算是达成了一个新的里程碑。

同时，这次迁移后也会从 Google Container Registry 切换为 Artifact Registry，这个除了可以存储容器镜像外，还可以存储其他比如 Maven 和 npm 等 artifacts ，会更加灵活，也可以支持后续社区的其他存储需求。

另外这里还有一个潜在的好处，比如说 AWS 的用户，可以通过这个服务获取到更快的响应，而且还节省了流量费。

你可以通过如下命令来查看当前集群中是否还有旧的 gcr.io 的镜像，比如在我的一个 Kubernetes v1.23 的集群执行：

(MoeLove) ➜ kubectl get pods --all-namespaces -o jsonpath="{.items[*].spec.containers[*].image}" |tr -s '[[:space:]]' '\n' |sort |uniq -c 
      4 gcr.io/datadoghq/agent:7.34.0
      1 gcr.io/datadoghq/cluster-agent:1.18.0
      2 k8s.gcr.io/coredns/coredns:v1.8.6
      1 k8s.gcr.io/etcd:3.5.1-0
      1 k8s.gcr.io/kube-apiserver:v1.23.0
      1 k8s.gcr.io/kube-controller-manager:v1.23.0
      1 k8s.gcr.io/kube-proxy:v1.23.0
      1 k8s.gcr.io/kube-scheduler:v1.23.0
      1 k8s.gcr.io/kube-state-metrics/kube-state-metrics:v1.9.8
      1 quay.io/cilium/cilium:v1.11.3@sha256:cb6aac121e348abd61a692c435a90a6e2ad3f25baa9915346be7b333de8a767f
      1 quay.io/cilium/operator-generic:v1.11.3@sha256:5b81db7a32cb7e2d00bb3cf332277ec2b3be239d9e94a8d979915f4e6648c787

当然，社区中为了方便迁移也提供了一个 kubectl 的插件，你可以通过如下命令进行安装。

(MoeLove) ➜ kubectl krew install community-images

最后，社区最近也写了一篇指南供参考：k8s.gcr.io Redirect to registry.k8s.io - What You Need to Know | Kubernetes

上游进展

KEP-3488: Implement secondary authz for ValidatingAdmissionPolicy by jpbetz · Pull Request #116054 · kubernetes/kubernetes
KEP-3488: Implement Enforcement Actions and Audit Annotations by jpbetz · Pull Request #115973 · kubernetes/kubernetes

Kubernetes v1.26 增加了一项很重要的特性，那就是允许使用 CEL 进行 Admission Control，具体内容可以参考我之前写的文章：Kubernetes v1.26 新特性一览 | MoeLove

其中引入了一个新的资源 ValidatingAdmissionPolicy ，使用起来如下:

apiVersion: admissionregistration.k8s.io/v1alpha1
 kind: ValidatingAdmissionPolicy
 metadata:
   name: "demo-policy.moelove.info"
 Spec:
   failurePolicy: Fail
   matchConstraints:
     resourceRules:
     - apiGroups:   ["apps"]
       apiVersions: ["v1"]
       operations:  ["CREATE", "UPDATE"]
       resources:   ["deployments"]
   validations:
     - expression: "object.spec.replicas <= 2"

但是在当时也只是实现了 KEP-3488 的一部分。

在这个 PR 中是在实现 Authz 的部分，这允许用 CEL 表达式编写复杂的 admission control 规则，放置在声明式资源中，而不是构建和部署 webhook。

虽然 admission webhook 一直是我们灵活的与第三方工具集成的基石，但是对于新用户来说，它们有很多复杂性，新的 CEL 系统有望接管仅需要对默认规则进行小修改的简单独立案例。

以前，表达式上下文会公开有关当前请求和目标资源的信息，现在通过这个 PR 可以在授权层中动态检查 RBAC 权限。一些有用的地方可能是使用 RBAC 进行每个字段的更新权限，允许 RBAC 检查特定对象而不使用 resourceNames 系统，或基于请求者身份限制对程序敏感字段（例如 finalizers ）的访问而无需生成复杂的 RBAC 策略。

例如：

authorizer.group('').resource('pods').namespace('default').check('create').allowed()
authorizer.path('/healthz').check('GET').allowed()
authorizer.requestResource.check('my-custom-verb').allowed()

本周还加入了#115973，该功能允许在失败时作为主要操作发出审计日志事件，或者如果需要更多数据，可以编写一个或多个CEL表达式，以提供详细的值，这些值将发送到审计子系统。

这既可以在开发新策略时提供强大的调试选项，也可以进行运行时分析。其他 CEL admission 特性包括成本检查，以防止您使用所有这些新功能意外拒绝服务自己的 kube-apiserver，以及改进的类型检查。

总的来说，基于 CEL 的 admission 处理有了很多新的功能，希望进一步将 webhook 推入到一个有限的用例空间中（防止滥用）。

其他

Vault Release v1.13.0 · hashicorp/vault
kubevirt Release v0.59.0 · kubevirt/kubevirt 有超多的变更，如果升级需要注意
Kyma Release 2.12.0-rc2 · kyma-project/kyma 常规更新
containerd Release containerd 1.7.0 · containerd/containerd 我在上一篇 K8S 生态周报| Kubernetes In-place Pod 垂直伸缩的功能已合并 | MoeLove 中已经介绍过了，感兴趣的小伙伴可以翻翻看。

以上就是本周的全部内容了，我们下周再见！