大家好，我是张晋涛。
Kubernetes 正式公布了，蕴含了 40 我的项目加强更新。
本次 LOGO 的次要表白的意思是 尊重合作和凋谢的精力，这种精力将咱们凝聚到一起转变为能扭转世界的力量。
其实我每期的「k8s 生态周报」都有一个叫上游停顿的局部，所以很多值得关注的内容在之前的文章中曾经发过了。
这篇中我会再额定介绍一些之前未涵盖的，和之前介绍过的值得关注的内容。
core CSI Migration 达到 Stable
Kubernetes 对 CSI 的反对是自 v1.9 开始引入的，到 2019 年的 v1.13 时曾经正式 GA。
最近几个版本中，社区正在将本来的 in-tree 插件逐渐废除或删除，并迁徙至应用 CSI 驱动的形式。
迁徙至应用 CSI 的益处在于，能进步可维护性，并缩小因 in-tree 代码导致的破绽或者谬误的产生。
然而迁徙也并不是间接替换，社区思考到用户的迁徙老本，于是提出了一种解决方案：CSI Migration，这个计划是将
in-tree API 转换为等效 CSI API，并将操作委托给 CSI 驱动程序的性能。目前该性能达到 GA，in-tree 的迁徙也有很多停顿。
- deprecate GlusterFS plugin from available in-tree drivers. by humblec · Pull Request #111485 · kubernetes/kubernetes
在这个 PR 中废除了 in-tree 的 GlusterFS 的 plugin，这其实是最早的 dynamic provisioner，自 Kubernetes v1.4 版本开始引入。
在起初 CSI 驱动呈现的时候，社区中也立即呈现了对应的驱动实现 https://github.com/gluster/gl…，只不过该我的项目并没有踊跃的进行保护。
当初还有另一个比拟举荐的代替计划，能够思考应用 https://github.com/kadalu/kad… 此我的项目最新的版本为 v0.8.15。
通过社区之前的探讨，还是决定在 v1.25 版本开始将 in-tree 的 GlusterFS plugin 标记为废除，并在后续的版本中进行移除。
如果有正在应用此插件的小伙伴，我倡议能够尽早的评估 kadalu 的可行性 & 迁徙老本。
- cleanup: Remove storageos volume plugins from k8s codebase by Jiawei0227 · Pull Request #111620 · kubernetes/kubernetes
- cleanup: Remove flocker volume plugins from k8s codebase by Jiawei0227 · Pull Request #111618 · kubernetes/kubernetes
- cleanup: Remove quobyte volume plugins from k8s codebase by Jiawei0227 · Pull Request #111619 · kubernetes/kubernetes
上述的这几个 PR 所做的事件根本相似，是一些清理操作。
将 Kubernetes 我的项目中 StorageOS，Flocker 和 Quobyte 等 in-tree 的卷插件都删除掉了。
其中 StorageOS 和 Quobyte 如果有在应用，倡议往 CSI plugin 进行迁徙，而 Flocker 则是因为不再保护了，所以并没有任何迁徙打算。
cgroup v2 反对达到 GA
在 2019 年 GitChat 对我的访谈中让我聊 2020 年的技术趋势，我过后的次要观点摘录如下：
作为云原生技术的基石，Kubernetes 在 2020 年的热度将会持续上升。而各个公司的集群规模，以及对容器技术的推动都将会继续加大。在经验了初步容器化后，更多的公司将面临的问题是稳定性和性能优化问题。与此同时，service mesh，serverless 等技术也都会逐渐失去广泛利用。从底档次技术的角度来看，cgroups v2 将逐渐遍及，进而取代 cgroups v1，但这个过程可能须要两三年左右。整体而言，稳定性和性能优化将会是将来的主旋律。
现在，3 年工夫曾经过来，Kubernetes v1.25 中对 cgroup v2 的反对曾经达到 GA，和我之前的判断是一样的。
我之前也写了一篇《一篇搞懂容器技术的基石：cgroup》，可能该思考写篇新的 cgroup v2 了（笑
PodSecurity 个性达到 GA
在 #110459 · kubernetes/kubernetes 中正式将 PodSecurity 个性降级到 GA。如果我没有记错，这个
个性应该是从引入到 GA 最快的个性之一了。
PodSecurity 是自 Kubernetes v1.22 引入的 alpha 个性，作为 PodSecurityPolicy 的一个代替。在 v1.23 达到 beta 级别，通过上述 PR，在 v1.25 正式 GA，并且默认启用，能够看到
整个倒退过程还是很快的。
PodSecurity 定义了 3 种级别：
- Enforce：如果 Pod 违反策略，则不会被创立；
- Audit：如果 Pod 违反策略，则在审计日志中会被记录，然而 Pod 仍将失常创立；
- Warn：如果 Pod 违反策略，则会在 console 中打印 warning 信息，Pod 仍将失常创立；
应用起来也很简略，只须要给 namespace 增加 pod-security.kubernetes.io/<mode>=<standard> 标签即可。
只有你的 Kubernetes 集群版本先降级到 v1.22 以上，并且开启 PodSecurity 个性，那么就能够依照 Migrate from PodSecurityPolicy to the Built-In PodSecurity Admission Controller | Kubernetes 进行迁徙了。
然而如果你的集群版本较低，并且还心愿能有一个绝对通用的办法，我倡议你能够看看我之前写的文章。《理清 Kubernetes 中的准入管制（Admission Controller)》
和《云原生策略引擎 Kyverno（上）》
通过应用 Admission controller、OPA/GateKeeper、Kyverno 等来实现对立配置。
初步反对 user namespaces
- Add support for user namespaces phase 1 (KEP 127) by rata · Pull Request #111090 · kubernetes/kubernetes
这个 PR 实现了 KEP127 的第一阶段，KEP127 旨在为 Pod 增加 user namespaces 的反对。
对 user namespaces 不太熟悉的小伙伴，能够看看我之前的系列文章：《搞懂容器技术的基石：namespace（上）》和《搞懂容器技术的基石：namespace（下）》。
在 Kubernetes 中反对应用 user namespaces 的益处在于，能够在与主机有不同 UID/GID 的 Pod 中运行过程，这样在 Pod 内的特权过程
理论是作为主机中的一般过程运行的。这样，假如 Pod 内的特权过程因为安全漏洞被攻破，对主机的影响也能够降到比拟低。
间接相干的破绽，比方 CVE-2019-5736，我也曾在 2019 年的文章《runc 1.0-rc7 公布之际》专门介绍过，
感兴趣的小伙伴能够到该文章中理解详情。
该实现是在 Pod 的 Spec 中增加了布尔类型的 HostUsers 字段，以决定是否启用主机的 user namespaces，默认是 true。
此外，目前可预感的状况是，如果 Kubernetes 集群应用的 Linux 内核版本在 v5.19 以下的话，那么应用该个性可能会导致 Pod 的启动工夫减少。
CronJobTimeZone 达到 Beta 级别
- Promote CronJobTimeZone to beta by soltysh · Pull Request #111435 · kubernetes/kubernetes
CronJob TimeZone 的个性达到了 Beta 阶段。不过依据 Kubernetes 最新的个性策略，该个性依然须要手动开启 CronJobTimeZone feature gate。
留神，CronJob 如果不设置 TimeZone 的话，默认应用的是 kube-controller-manager 过程的 TimeZone。
之前有遇到小伙伴在这个问题上节约了一些工夫。
引入 alpha 个性 ContainerCheckpoint
#104907 · kubernetes/kubernetes 这是一个继续了将近一年的 PR，在这个 PR 中引入了一项新的个性：ContainerCheckpoint。
对 Docker 比拟相熟的小伙伴，可能晓得在 Docker 中存在一个 docker checkpoint 的子命令。
这个子命令实际上是能够帮忙咱们为某个正在运行的容器创立一个状态点的快照，并将其保留到磁盘中。
后续，咱们能够应用此 checkpoint 启动容器，复原其原先的状态，或者将容器迁徙到其余的机器上。
同样的，在 Kubernetes 中提供的这个 ContainerCheckpoint 的新个性是自 v1.25 开始作为 alpha 个性退出的，默认是敞开的。
利用此个性能够通过 kubelet 提供的 API，为 container 创立一个有状态的快照，而后将其挪动到另一个节点上进行调试，或者其余相似的需要。
此处须要留神的是，创立 checkpoint 可能会产生一些安全隐患，比方 checkpoint 实际上是对以后运行中 container 的内存快照，所以如果在
container 的内存中蕴含了某些隐衷数据，那么有可能在迁徙到其余机器上也能够拜访到。
另一方面，创立 checkpoint 会产生一些文件，这些文件是须要占用磁盘的。如果频繁的创立 checkpoint 则可能导致磁盘压力过大。
checkpoint 的存档，默认状况下会放在 /var/lib/kubelet/checkpoints 目录下，并且以 checkpoint-<podFullName>-<containerName>-<timestamp>.tar 进行命名。
这个个性应用起来也很简略，间接给 Kubelet 发送一个申请即可：
POST /checkpoint/{namespace}/{pod}/{container}而后将获取到的归档文件，通过以下命令进行复原：
crictl restore --import=<archive>为 kubectl 引入 kuberc 配置文件
KEP-3104 这个 KEP 旨在为 kubectl 引入一个新的配置文件 kuberc，用来配置一些用户的自定义配置。这在很多的我的项目，或者工具中都有相似的用法。比方 Vim 中能够通过 -u 指定用户本人的配置文件，或者应用默认的 ~/.vimrc 来实现自定义配置。
这样做的益处就在于能够让 kubeconfig 更加的专一，仅仅须要保留和集群、用户凭证相干的信息即可，对于用户的自定义配置则拆散开来。具体而言，这个配置文件看起来就会是这样：
apiVersion: v1alpha1
kind: Preferences
command:
aliases:
- alias: getdbprod
command: get pods -l what=database --namespace us-2-production
overrides:
- command: apply
flags:
- name: server-side
default: "true"
- command: delete
flags:
- name: confirm
default: "true"
- command: "*"
flags:
- name: exec-auth-allowlist
default: /var/kubectl/exec/...看起来也比拟直观，能够用来减少一些 alias 和笼罩一些默认的配置，这样大家不再须要定义很多的 alias，当前应用 kubectl 的时候敲的命令也能少很多。
此个性未实现之前，
在这里顺便举荐另一个我的项目 kubectl-aliases，此我的项目中蕴含了很多 alias，能够让应用 kubectl 的过程更加简略。
但也有一些弊病，就像是每个 Vim 用户都要有本人的 vimrc 配置文件一样，这会养成肯定的习惯。在一些没有本人自定义配置的机器上应用时，会有些不习惯。
同时，这在排查问题时，也可能减少排查的链路（比方 kuberc 中减少了一个谬误的配置之类的）。
举例来说，我在排查 Vim 的问题时候，通常会间接 vim -u /dev/null 这样，以防应用了任何自定义配置造成影响。那么后续如果这个性能齐全实现了，那么大家在
排查问题的时候，须要留神应用 kubectl --kuberc /dev/null 相似这样的形式来防止本地自定义配置造成影响。
为 kubectl 增加 –subresource 的补全
- Add shell completion for new –subresource flag by marckhouzam · Pull Request #109070 · kubernetes/kubernetes
在 Kubernetes v1.24 中，给 kubectl 减少了 subresource 的反对（指 status 和 scale），这样就能够很不便的间接对 subresource 进行操作了，而不须要每次都 -o yaml 之类的间接进行查看，或者通过 curl 之类的调用 API 来实现其余操作。
应用了此个性后，能够有如下成果：
# v1.24+
tao@moelove:~$ kubectl get -n apisix --subresource status deploy apisix-ingress-controller
NAME AGE
apisix-ingress-controller 2d23h
tao@moelove:~$ kubectl get -n apisix --subresource scale deploy apisix-ingress-controller -ojson
{
"apiVersion": "autoscaling/v1",
"kind": "Scale",
"metadata": {
"creationTimestamp": "2022-08-04T18:57:45Z",
"name": "apisix-ingress-controller",
"namespace": "apisix",
"resourceVersion": "1656",
"uid": "7c191a14-ee55-4254-80ba-7c91b4c833bd"
},
"spec": {"replicas": 1},
"status": {
"replicas": 1,
"selector": "app.kubernetes.io/instance=apisix,app.kubernetes.io/name=ingress-controller"
}
}然而在此之前版本应用该参数的话，会间接提醒谬误：
# v1.23
tao@moelove:~$ kubectl-v1.23 get -n apisix --subresource status deploy apisix-ingress-controller
Error: unknown flag: --subresource
See 'kubectl get --help' for usage.此处我提到的这个在 v1.25 中的 PR 实际上是为了给 --subresource 提供一个命令补全的能力（尽管如上文提到的，目前就两种资源），还是比拟不便的。
其余
- #109074 · kubernetes/kubernetes
kubeadm 中为 etcd 的 static Pod 减少了一个 --experimental-initial-corrupt-check 选项，能够用来确认 etcd member 中数据的一致性。这个个性预期在 etcd 的 v3.6 版本中会正式可用。此外，etcd 的 Release 页面也写了，以后不倡议将 etcd 3.5.x 用于生产环境，如果尚未进行降级，能够先持续应用 3.4.x。如果曾经降级了，那么能够自行减少此参数；
- Migrate Ginkgo from v1 to v2 · kubernetes/kubernetes
这个 PR 继续了将近三个月，次要是将 Kubernetes 我的项目中应用的 Ginkgo 从曾经废除的 v1 版本升级到 v2 版本。
其实目前很多我的项目都在踊跃的推动此事，但不同的我的项目对 Ginkgo 的依赖和应用水平不同，在这个 PR 中批改了超过 600 个文件，十分的宏大。
而之前在 Apache APISIX Ingress controller 我的项目中，从 Ginkgo v1 降级到 v2 时，仅仅用了一周工夫，批改文件不算太多。
此外目前 Kubernetes Ingress-NGINX 我的项目也同样在进行此降级，可能工作量也不小。
- Introduce KUBECACHEDIR environment variable to override default discovery cache dir by ardaguclu · kubernetes/kubernetes
这个 PR 说起来是比拟小的一个改变，然而它的影响却很大。
在这个 PR 中引入了一个新的 KUBECACHEDIR 环境变量，来代替默认的 ~/.kube/cache 缓存目录。通过这个 PR 就有可能会导致用户在应用 kubectl 的时候，能够通过这个环境变量来跳过
缓存。进而可能会引起一些性能问题。
- kube-apiserver: default –enable-logs-handler flag to false · kubernetes/kubernetes
kube-apiserver 中的 /logs 因为平安问题，默认状况下会进行敞开，而后通过 --enable-logs-handler 标签进行启用。如果要进行日志采集的话，须要额定留神下。
- #111060 · kubernetes/kubernetes
kube-proxy 的 container image 将要变更为 distroless 的了。
这能够躲避很多安全隐患，晋升集群的安全性。
以上就是 Kubernetes v1.25 中比拟值得关注的内容。在进行集群降级前肯定要留神查看。
好了，咱们下期再见！
欢送订阅我的文章公众号【MoeLove】