首先

这是Kubernetes Advent Calendar 2019 第7天的文章。

我想回顾一下Kubernetes在过去一年中的发布情况，总结一下。

2019年版本的年表（部分摘要）

著名的信息 (zhu de xī)

• マイナーバージョンについては最新のバージョンの他、直近3バージョンについてパッチリリースが入ります。

2019年12月現在では1.17がUpstreamの開発バージョン、1.14-1.16がパッチリリースの対象です。

Kubernetesの基本的なアップデートサイクルは、3ヶ月に1回のマイナーバージョンリリースなので、このまま行くと12月の半ばには1.17がリリースされる見込みです。
Kubernetesのバージョンリリース管理については「SIG-release」によって管理されています。

2019年发生的重大升级/新闻事件

鑑於追蹤所有發布和更新實在太多資訊且無限制，所以我們主要會選擇報導和提及那些被部分文章所著墨或較大範圍的重要資訊。

“在1.14.0版本中的重大更新”

Windows节点的生产支持

• Windows Server 2019向けにWindowsコンテナ及びワーカーノードのサポートが追加された

Azure-CNI、OVN-Kubernetes及びFlannelでのネットワーキングのサポートも

可能な限りPod、Service、メトリクスやクオータなどをLinuxコンテナの挙動に寄せた

经过长时间的本地存储，Persistent Local Volume现已全面推出（GA）。

• ノードにローカルにアタッチされたストレージをPVリソースとして利用可能になった

多くのユースケースでは分散型(または外部)のストレージを使うのが望ましいが、パフォーマンス要件などを理由にこちらを使う選択肢もありえる

Kubectl进行了重大更新

• kubectlのドキュメントサイトがスタンドアロンで出来た (Ref: https://kubectl.docs.kubernetes.io/)

Kustomizeが統合された
kubectl pluginの機構がStableになった

1. 在1.15.0版本中的重大更新

为了增强Kubernetes的可扩展性，对API的核心周围进行更新。

Kubernetesの拡張にはCRD(Custom Resource Definition)を使うが、Golangを使ってCRDを扱うにあたって、開発者たちがCRDを意識しなくても良いようにOpenAPIベースの構造化スキーマを用いることで、CRDのAPI周りの通信における安定性や信頼性が向上した

关于这方面的详细信息，可以在@Ladicle的Kubernetes 1.15: SIG-API Machinery的更改内容中找到。

改善Cluster Lifecycle方面的问题。

kubeadmを使った高可用性クラスターの構築がより簡単になった
ノード間で使われる証明書のローテーションが自動化された

CSI持续改善的努力

Kubenretesの従来のストレージ機構として使われていたin-tree volumeをより拡張性の高いCSI(Container Storage Interface)に移行するための様々な改善が行われた

1. 在1.16.0版本中的重大更新。

API的破坏性改变

• Deploymentなどで従来使われていたextentions/v1beta1、apps/v1beta1、apps/v1beta2が全てデフォルトで利用できなくなった

apps/v1への速やかな移行が推奨されている

自定义资源已经正式发布

• Kubernetesを拡張して独自のリソースを定義し利用できるようにするCRDがこのバージョンからGAになった

• Windows周りでの改善

WindowsコンテナにおけるWorkload Identityの改善
kubeadmを使ったクラスターセットアップの改善
CSIの提供を開始

Volume的扩展性得到了改善。

CSIのVolume specが改善され、リサイズが簡単にできるようになった

Paraphrase: 這個Endpoint Slice與Alpha相連。

• 従来、Kubernetesリソースの管理は種別ごとに全く同じAPIエンドポイントによって提供されていた。大量のNodeやPodを抱えるようなユースケースの場合、リクエスト方になりエンドポイントのパフォーマンスが劣化する

Endpoint Sliceを使うことで、適切にリソースとエンドポイントの範囲を定義して、大量のリソースが存在していてもAPIで取得できるオブジェクトのデータが肥大化しなくなり、リクエスト量も分散できる

2019年发现的与Kubernetes相关的安全漏洞

CVE-2019-11249, CVE-2019-1002101可以在下文中找到。

kubectl cp中的漏洞

kubectl cp 命令是用于在Kubernetes容器和本地环境之间相互复制文件的命令。
这个漏洞相对比较难以处理，如果在cp命令内部使用的容器内tar命令被恶意的二进制文件篡改，那么就有可能在本地执行恶意代码或展开输出。

如果基础图像是来自第三方，并被恶意篡改，将会再现。

2. CVE-2019-11247 可编写成: “编号 CVE-2019-11247。”

Kubernetes API服务器中存在的授权漏洞

在命名空间范围内完成的Kubernetes资源操作，却可以访问集群范围的自定义资源。

如果给定了可以访问命名空间内所有资源的设置，在这种条件下，实际上可以对集群中的所有自定义资源进行操作，这是一个有些棘手的漏洞。

3. CVE-2019-11253

3. 具体描述：CVE-2019-11253

Kubernetes的API服务器中的YAML解析器的弱点

给Kubernetes的API服务器输入符合特定条件的清单文件（YAML或JSON有效负载），将导致其成为无法响应的Kubernetes主控组件。

如果是在1.14.0及以后的版本中新创建的集群，RBAC的默认设置已经发生了变化，只有经过身份验证的用户才能访问，从而限制了脆弱性的范围。

重要的是，即使从1.13升级到1.14，”RBAC的设置不会因为前向兼容而变化”这一点很关键。
换句话说，仅仅升级到1.14版本是不够的，还需要升级到已修复漏洞的版本。

总结感想

整理发布信息的结果，让我们对Z Lab的成员印象深刻。在此，我们要感谢为我们整理发布内容的Z团队成员（@uesyn，@shmurata，@tkusumi，@shmurata，@Ladicle，@inajob，@superbrothers，@watawuwu，@kkohtaka，@ysakashita，@hiyosi，@yuanying敬称略）。

参考的文章：
https://qiita.com/shmurata/items/a796e02740b0eb7df65a
https://qiita.com/uesyn/items/3def2beb32387e58af01
https://qiita.com/uesyn/items/0246346d8958318fa1d4

请注意:基于机器翻译的回答可能不准确、不完整或不符合中文表达习惯。