Kubernetes v1.23 今天正式发布，这是 2021 年发布的第三个版本，也是今年最后一个正式发布的版本。

此版本中主要包括 47 项增强更新，其中 11 项达到 stable, 17 项达到 beta 还有 19 项达到 alpha 。当然，也有 1 项被标记为废弃。相比于 v1.22 从数量上来说是少了一点（v1.22 有 53 项增强更新），但这并不影响这是一个很棒的版本！

在 Kubernetes 的发布周期变更为每4个月一个版本后，很明显的感觉就是不用在升级上面花费太多时间了，毕竟 Kubernetes 的升级操作是个体力活，大家觉得呢？

我们一起来看看这个版本中有哪些值得关注的变更吧！

新增 kubectl alpha events 命令

在之前的《K8S 生态周报| Helm 新版本发布增强对 OCI 的支持》文章的上游进展中我曾为大家介绍了该功能。它是按照 KEP #1440 实施的。

"

增加此命令主要是由于在不修改 kubectl get 的前提下，查看 event 有一些限制，所以直接增加 kubectl events 命令可以更方便的去获取到需要的信息，尤其是 event 是在 Kubernetes 中经常需要查看的一个信息。kubectl get events 比较典型的一些问题, 比如排序（虽然可以通过加参数解决）， watch，以及无法按照时间线方式去查看 events 等。 "

我们来看看这个命令具体如何使用。

我们先来创建两个 Pod，分别叫 redis 和 redis2 。

(MoeLove) ➜ kubectl run redis --image="ghcr.io/tao12345666333/redis:alpine" 
pod/redis created
(MoeLove) ➜ kubectl run redis2 --image="ghcr.io/tao12345666333/redis:alpine"
pod/redis2 created
(MoeLove) ➜ kubectl  get pods
NAME     READY   STATUS    RESTARTS   AGE
redis    1/1     Running   0          12m
redis2   1/1     Running   0          2m23s

执行 kubectl alpha events 可以看到当前 namespace 下的所有 events 。如果增加 --for 条件可以用来筛选只展示特定资源相关的 events 。同时默认情况下就是按时间排序的

(MoeLove) ➜ kubectl  alpha events
LAST SEEN   TYPE     REASON      OBJECT       MESSAGE
12m         Normal   Scheduled   Pod/redis    Successfully assigned default/redis to kind-control-plane
12m         Normal   Pulling     Pod/redis    Pulling image "ghcr.io/tao12345666333/redis:alpine"
12m         Normal   Pulled      Pod/redis    Successfully pulled image "ghcr.io/tao12345666333/redis:alpine" in 4.028873745s
12m         Normal   Created     Pod/redis    Created container redis
12m         Normal   Started     Pod/redis    Started container redis
3m5s        Normal   Scheduled   Pod/redis2   Successfully assigned default/redis2 to kind-control-plane
3m5s        Normal   Pulled      Pod/redis2   Container image "ghcr.io/tao12345666333/redis:alpine" already present on machine
3m4s        Normal   Created     Pod/redis2   Created container redis2
3m4s        Normal   Started     Pod/redis2   Started container redis2
(MoeLove) ➜ kubectl  alpha events --for pod/redis2
LAST SEEN   TYPE     REASON      OBJECT       MESSAGE
3m23s       Normal   Scheduled   Pod/redis2   Successfully assigned default/redis2 to kind-control-plane
3m23s       Normal   Pulled      Pod/redis2   Container image "ghcr.io/tao12345666333/redis:alpine" already present on machine
3m22s       Normal   Created     Pod/redis2   Created container redis2
3m22s       Normal   Started     Pod/redis2   Started container redis2

IPv4/IPv6 双栈支持达到 GA

在配置双栈网络的 Kubernetes 时，需要同时指定 --node-cidr-mask-size-ipv4 和 --node-cidr-mask-size-ipv6 以便于设置每个 Node 上的子网大小。在此之前我们都是直接使用 --node-cidr-mask-size 进行设置即可。

如果我们仍然使用单栈 Kubernetes 集群的话，正常来说不需要做什么调整，当然我们也可以使用上面提到的选项，来单独设置集群的 IPv4/IPv6 子网。

PodSecurity Admission 达到 Beta

PodSecurity Admission 是之前的 PSP 的代替，关于 Kubernetes Admission 可以参考我之前的文章《理清 Kubernetes 中 Admission 机制》，这里就不展开了。

IngressClass 支持 namespace 级别的参数

IngressClass.Spec.Parameters.Namespace 字段当前达到 GA ，这样我们就可以为 IngressClass 设置参数为 namespace 级别了。比如：

apiVersion: networking.k8s.io/v1
 kind: IngressClass
 metadata:
   name: external-lb
 spec:
   controller: example.com/ingress-controller
   parameters:
     apiGroup: k8s.example.com
     kind: IngressParameters
     name: external-lb
     namespace: external-configuration
     scope: Namespace

Probe 中增加 gRPC 协议的支持

通过 KEP #2727 ，在此版本中为 Pod.Spec.Container.{Liveness,Readiness,Startup} 的 Probe 添加了 gRPC 协议的支持。例如：

readinessProbe:
  grpc:
    port: 9090
    service: moelove-service
  initialDelaySeconds: 5
  periodSeconds: 10

可通过 GRPCContainerProbe feature gate 开启此特性。具体细节可参考 #106463

新增 OpenAPI V3

这个特性是 Alpha 级别，可通过 OpenApiv3 feature gate 进行开启。

增加此特性主要是由于 CRD 目前可通过 OpenApi V3 进行定义，但是 api-server 目前还不支持。当从 OpenApi V3 转换为 V2 时，部分信息将会丢失。

更多详细信息可参考 KEP #2896

CRD Validation 表达式语言

这是一项 Alpha 级别的特性，默认是不开启的。可通过增加 CustomResourceValidationExpressions feature gate 来进行开启。单独介绍此 Alpha 级别的特性是因为目前基于 Custom Resource Definitions (CRDs) 的方式对 Kubernetes 进行扩展已经成为主流，但是在 CRD 中目前能添加的校验规则有限，更多的场景都需要通过额外的 Admission 来完成。

此功能使用一种叫做 Common Expression Language (CEL) 的语言进行规则定义，通过 x-kubernetes-validation-rules 字段进行规则的添加。

例如，某个 CRDs 的内容如下，其中定义了 minReplicas 小于 replicas 并且 replicas 小于 maxReplicas 。

...
openAPIV3Schema:
  type: object
  properties:
    spec:
      type: object
      x-kubernetes-validation-rules:
        - rule: "self.minReplicas <= self.replicas"
          message: "replicas should be greater than or equal to minReplicas."
        - rule: "self.replicas <= self.maxReplicas"
          message: "replicas should be smaller than or equal to maxReplicas."
      properties:
        ...
        minReplicas:
          type: integer
        replicas:
          type: integer
        maxReplicas:
          type: integer
      required:
        - minReplicas
        - replicas
        - maxReplicas

那么，当有如下的自定义资源创建时，Kubernetes 将会拒绝其请求。

apiVersion: "stable.example.com/v1"
kind: CustomDeployment
metadata:
  name: my-new-deploy-object
spec:
  minReplicas: 0
  replicas: 20
  maxReplicas: 10

并且返回如下错误：

The CustomDeployment "my-new-deploy-object" is invalid:
* spec: Invalid value: map[string]interface {}{"maxReplicas":10, "minReplicas":0, "replicas":20}: replicas should be smaller than or equal to maxReplicas.

这样相比原来我们通过 Admission 的方式来进行校验就会方便的多。关于 Kubernetes Admission 可以参考我之前的文章《理清 Kubernetes 中 Admission 机制》。