Kubernetes v1.17 版本解读 | 云原生生态周报 Vol. 31
https://www.kubernetes.org.cn/6252.html
作者 |
徐迪、李传云、黄珂、汪萌海、张晓宇、何淋波 、陈有坤、李鹏
审核 | 陈俊
上游重要进展
1. Kubernetes v1.17 版本发布
功能稳定性是第一要务。v1.17 包含 22 个增强功能：14 个增强功能已逐渐稳定，4 个增强功能已进入 beta 版，4 个增强功能已进入 alpha 版本。
Major Theme
- 云提供商标签达到 GA
这个自 1.2 版本就引入的 label，在 1.17 版本终于 GA。之前旧的 label 已经被废弃掉：以下 3 个旧的 label 已经被废弃掉了：
- Volume Snapshot 进入 beta
在 1.12 版本中首次以 v1alpha 版本引入，在 1.13 中升级为 v2alpha（不兼容 v1alpha 版本），目前在 1.17 版本正式进入 beta 版；
- in-tree 存储插件迁移到 CSI 已是 beta
从 1.14 开始迁移 alpha。
特性稳定
- Taint Node by Condition GA
将 kube-scheduler 所关心的 Node 状态从 Conditions（例如：OutOfDiskMemoryPressure）转化到 Taints。Taints 成为 kube-scheduler 判断 Node 状态的唯一来源，同时用户也可以在 Pod 上通过声明 Tolerations 来容忍调度到有这些 Taints 的节点。
- Configurable Pod Process Namespace Sharing
Pod 内所有容器共享 PID Namespace 特性 GA。该特性将方便 Pod 内进程信号传递(如 Sidecar 容器中的日志进程完成日志轮转后，通知业务容器进程使用新的日志)以及 Pod 内僵尸进程回收等。
- ScheduleDaemonSet Pods by kube-scheduler
Damoneset 的 pod 的调度从 daemonset controller 迁移到 kube-scheduler 来做调度，从而支持 PodAffnity、PodAntiAffinit 等能力。
- DynamicMaximum Volume Count
该特性是为了支持调度感知单个 Node 上可以挂载的 Volume 个数的上限，且每个 Node 的上限可由存储插件自己动态设置。一般云厂商提供的云主机对某些存储卷(如块存储)能挂载的数量有限制，该特性支持调度器在选择 Node 时排除那些挂载的存储卷已经超过该 Node 支持的 Maximum Volume Count 的 Node 节点。
- KubernetesCSI Topology Support
通过 CSI 实现的存储插件支持存储拓扑调度感知特性，即可以通过 Pod 被调度到的 Node 对应的拓扑位置信息(如 Node 所属的 Region/Zone/Rack 等等)决定动态创建的云存储的拓扑位置，也可以通过 StorageClass 限制动态创建的存储的拓扑位置，还可以通过 Pod 使用的 PV 的拓扑限制决定 Pod 可被调度的 Node 节点。
- Provide Environment Variables Expansion in SubPathMount
subPath 用在单个 Pod 多个容器或者一个容器中多个 mountPath 在共享同一个 volume 时以建子目录的方式在同一个 Volume 上做目录隔离。而 subPathExpr 字段可以从 Downward API 环境变量构造 subPath 目录名，可更加灵活地动态生成对应的子目录名。
- Defaulting of Custom Resources
Custom Resource 目前缺乏 default 机制，而 default 值对 API 的兼容性影响重大。这个功能通过 OpenAPI v3 的校验机制来为 CRD 添加默认值。
- Move Frequent Kubelet Heartbeats To Lease Api
Lease api 进入 GA 阶段，kubelet 使用 lease api 周期性汇报心跳，相比 NodeStatus，lease 对象更小，可以降低 kube-apiserver 压力。
- Break Apart The Kubernetes Test Tarball
kubernetes-test.tar.gz 之前打包内嵌了各个平台的二进制文件。现在发行的 Kubernetes-test 包将以平台为单位，分拆成多个包。
- Watch Bookmarks GA
kube-apiserver 通过增加 Bookmark 事件通知 watcher 服务器端当前最新 resourceVersion，可以降低 watcher 重启时对 kube-apiserver 造成的压力。
- Behavior-Driven Conformance Testing
一致性测试框架进行修改以支持定义行为测试。行为测试是一组基于经验，代码检查，API 模型为视角的测试定义。而测试本身是具体对行为进行验证。此功能让两者进行分离。
- Finalizer Protection For Service Loadbalancers
增加 finalizer 去做 Load Balancer 类型的 Service 删除保护，确保 Service 这种资源对象在 Load Balancer 被摘除之后才能被删除。
- Avoid Serializing The Same Object Independently ForEvery Watcher
之前多个客户端 watch 同一个对象时，需要对同一个对象序列化多次，引入该特性后，同一个对象只需要序列化一次，在 5000 个节点的测试环境中，可以减少 5% 的 CPU 和 15% 的内存消耗。
重要变化
Add IPv4/IPv6 Dual Stack Support 添加 IPv4/IPv6 双协议栈支持。即允许将 IPv4 和 IPv6 地址分配给 Pods 和服务。预计会在 1.18 版本对 kube-proxy 支持 IPv4/IPv6 双协议栈，代码正在 review 中；
其他重要特性
- Topology Aware Routing of Services (Alpha)： 即让 Service 可以实现就近转发，比如同节点、同 AZ、同 Region 等等；
- RunAsUserName for Windows：增强 windows 容器的安全性，通过 feature gate 开启。1.16 版本 alpha 功能引入，在 1.17 已经变成 beta 版本（默认自动开启）。
2. Knative变更
- 安装后不启动实例
目前第一次启动时总是启动一个，用来检查用户代码是否正常工作，但在某些场景下不想启动任何实例。建议实现一个全局配置，并且可以在 revision 级别覆盖配置，如果不启动实例，则马上把状态设置为 ready，如果有流量过来按冷启动流程启动实例。
- 想在 revision 中添加 dnsPolicy 和 runtimeClassName
还没有足够的理由添加这些属性。
- proposal to delete ingress channel
从 Broker/Trigger 模型中删除 ingress channel。当前 Broker 会创建 2 个 channels: trigger 和 ingress. ingress channel 用于接收 trigger 的响应结果，然后发送给 ingress service. 但是目前看起来是额外的多了一跳，引入了延迟和可靠性的问题，比较好的方式是直接将响应结果发送给 ingress service.
开源项目推荐
1. dive
一个 docker image 分析工具，帮助快速分析各 layer 的内容，有助于减小整个镜像的大小。
2. amazon-vpc-cni-k8s
aws 上基于 ENI 的网络插件。
3. Draino
负责 cordon 和 drain 节点，提供了 dry run 模式。
4. Apache Dubbo-go
dubbo 的 golang 实现。
本周阅读推荐
1.《A visual guide on troubleshooting Kubernetes deployments》
文章主要讲述了如何去定位一个 deployment 无法正常工作的问题。
2.《Kubernetes Audit: Making Log Auditing a Viable Practice Again》
本文提出了一种 Kubernetes 自动化审计日志分析器的愿景，但这一愿景远不止于此。使用机器学习之类的工具甚至可以实时地自动检测日志中潜在的威胁。此外，以用户可理解的方式汇总审核日志中的信息，使审核员可以快速验证已识别的模式，并帮助调查其他隐藏的可疑活动。
3.《How Kubernetes Has Been “Transformational” to Productivity and Culture at uSwitch》
很多人开始尝试把业务迁移到 Kubernetes 上，那么 Kubernetes 到底能带来哪些改变呢？通过 uSwitch 的这个案例研究，可以给你带来不一样的思考。
4.《Building Large Kubernetes Clusters》
随着集群越来越多，集群的搭建和管理是个很头疼的问题。LINE 分享了自研的一套框架 Caravan。
5.《Kubernetes is the future of Computing. What You Should Know About the New Trend》
越来越多的人开始使用 Kubernetes，有人说它是下一代的“操作系统”，“云计算的未来”。快通过这篇文章了解下这个大趋势吧。