「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。 rkt 项目正式被 CNCF 归档 8 月 16 日，CNCF 宣布技术委员会已经投票通过将 rkt 项目归档。 这个事情，我在几周前的周报大概介绍过，既然现在已经尘埃落定，不如一起来看看 rkt 的前世今生，毕竟它在容器技术的发展中也曾做出了很多贡献。 rkt 最早是由 CoreOS 公司创建的，而 CoreOS 最早应该也算是 Docker 的用户之一。但是随着 Docker 发展的日趋壮大，CoreOS 就想要脱离 Docker，成立自己的标准。 之后 CoreOS 发布了 AppC 规范（这个规范我也曾仔细研究过），而 CoreOS 主打的旗号是开放，毕竟当时 Docker 一枝独秀，所以也就吸引了不少的伙伴参与。当然 rkt 也就借着这股风，得到了不少人的青睐。 这里且不说 rkt 功能或是规范如何，我们单独来看看那场容器市场份额的争夺战是如何打的。 在那时候，同时进行的另外一场战役是容器编排系统的战役。所以 rkt 也算是做了努力，它选择了与 Kubernetes 的合作（大概算是共同阵营的合作吧），所以在 2016 年 Kubernetes 1.3 版本中，宣布了支持 rkt 作为容器运行时的一个可选想。 但 Docker 的发展（指 Docker 项目），却几乎没有受到影响。为什么呢？ Docker 早已凭借自身的稳定性和易用性占领了大批的用户，即使有用户选择 rkt 大多也只是用于尝试（心疼选择 rkt 放入生产环境中的那批）。而且不得不说，Docker 在用户心中几乎是容器的代名词，是一个默认选项。

「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。 Kubernetes 两个重要漏洞修复 最近 Kubernetes 发布了 1.13.9, 1.14.5, 和 1.15.2 版本，旨在修复两个重要漏洞对 Kubernetes 带来的影响， 强烈建议将集群及 kubectl 进行升级 CVE-2019-11247 简单来说其影响就是可以访问单个命名空间中的自定义资源的用户可以访问具有集群范围的自定义资源。当然，这里的修正主要是 针对 CRD 。核心的修正代码如下： var possiblyAcrossAllNamespacesVerbs = sets.NewString("list", "watch") namespacedCRD, namespacedReq := crd.Spec.Scope == apiextensions.NamespaceScoped, len(requestInfo.Namespace) > 0 if !namespacedCRD && namespacedReq { r.delegate.ServeHTTP(w, req) return } if namespacedCRD && !namespacedReq && !possiblyAcrossAllNamespacesVerbs.Has(requestInfo.Verb) { r.delegate.ServeHTTP(w, req) return } 当未通过检查时，delegate 将会触发一个 404 。对此问题感兴趣的朋友可以查看 #80983 。 CVE-2019-11249 则是对于之前暴出来的使用 kubectl cp 可进行恶意目录浏览的漏洞 CVE-2019-1002101 和 CVE-2019-11246 的不完整修复。有兴趣可以参考 #80436 。

「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。 containerd 1.3.0-beta.0 发布 containerd 2014 年从 Docker 孵化出来，最初是作为 Docker 引擎的底层管理器；在 2017 年 3 月被 CNCF 接受后，containerd 几乎成为了行业容器运行引擎的标准，它专注于简单，健壮和可移植性，任何人都可以使用它来构建自己的容器引擎/平台。它是从 CNCF 毕业的第 5 个项目，目前发展势头良好。 本次发布的 1.3.0-beta.0 版本是 containerd 的第 4 个主要版本，主要是为了提升项目的稳定性，以及为了保持项目的活力而持续加入了很多新的特性。 这次的发布和之前版本类似，保持着 containerd 的一贯作风，API 变化很小；并且也保持向后兼容。插件生态和用户的发展也促使了 containerd 变得更易用，可配置和更灵活。 在 Windows 上，此次版本带来了一个新运行时（使用 hcsshim）; 对于客户端而言，本次也带来了很多特性和升级。 这里我只说两点，其余的等正式版出来看情况再进行介绍。 增加了 devicemapper 的快照插件。这个功能本身是个好事儿，如果用过旧版本 Docker 或者系统内核较低的朋友们，应该对 Docker 的 devicemapper 存储驱动不会太陌生的（虽然现在 Docker 的新版本中已经将 devicemapper 的存储驱动废弃掉了）；至于 containerd 中增加的 devicemapper 快照插件，我还没有来得及具体测试，所以这里不说太多了。 客户端支持了跨 repository push 镜像，对此功能感兴趣的朋友可以参考 #2697 的讨论。 更多关于此版本的信息请参考 ReleaseNote

「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。 Docker CE v19.03 正式发布 7 月 22 日，正式发布了 Docker CE v19.03 版本，按照 Docker CE 版本的生命周期，此次的 v19.03 可以说是千呼万唤始出来，原本按语义应该是在 3 月，不过之前的发布计划中开始是设定在了 5 月份，而一转眼现在已经到 7 月底了。 先跳过这次发布时间延期的问题，我们来看看此版本中最值得注意的一些变化。 首先来看看被废弃的部分： 废弃 aufs 存储驱动，在此版本之前 devicemapper 和 overlay 也都已经被废弃; 当 docker daemon 运行时，如果没有指定存储驱动，则会自动选择一个，v19.03 中增加了自动选择时跳过已被废弃的存储驱动的逻辑； 废弃 image manifest v2 schema1 以支持 v2 schema2 ，这里的废弃涉及到的内容很多，尤其是涉及到了 image registry 的部分, 所以后续还有很长的路要走。还记得之前推送过 Docker Hub 今年 6 月份停止 v1 API 进行 Pull 操作的事情吗？早年 2015 年 11 月的时候，它就已经禁止了 v1 API 的 Push 操作。从这点上也能看到 Docker 在功能弃用上其实为用户考虑了很多，并且也给了足够长的时间来让用户进行迁移。 其次，我们看看功能增强的部分：

「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。 Kubernetes v1.16.0-alpha.1 发布 Kubernetes 于近日发布了 v1.16.0-alpha.1 版本，变化是比较大，但这里暂时先不细说了，等到 9 月份正式版本发布前后再慢慢说。当然也稍微聊一些 :) 比如： 官方 etcd 镜像中不再提供 etcd 2 和 3 的兼容工具了，对 etcd 2 的兼容代码也都全部删掉了（对 etcd 2 的支持其实从 1.13 就已经停止了）#80037 ； 1.16 中对以下四种类型资源的 API 有所调整： NetworkPolicy PodSecurityPolicy DaemonSet, Deployment, StatefulSet 和 ReplicaSet Ingress 具体调整细节如下： NetworkPolicy 将使用从 v1.8 版本开始提供的 networking.k8s.io/v1 API; PodSecurityPolicy 将使用从 v1.10 开始提供的 policy/v1beta1 API; DaemonSet, Deployment, StatefulSet 和 ReplicaSet 将使用从 v1.9 版本开始提供的 apps/v1 API; Ingress 迁移到 networking.

「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。 本周为什么发布时间比往常迟呢？因为我在忙结婚呀。 CoreDNS v1.5.2 发布 这是 CoreDNS 在 1.5.x 版本中发布的第二个小版本，关于 1.5.1 版本的说明可参考上上周的文章。 在此版本中，一个重要的变更便是移除掉了 upstream 插件相关的所有文档和说明。比如，Kubernetes 1.14 版本中默认的 CoreDNS 的配置文件的内容如下： .:53 { errors health kubernetes cluster.local in-addr.arpa ip6.arpa { pods insecure upstream fallthrough in-addr.arpa ip6.arpa } prometheus :9153 forward . /etc/resolv.conf cache 30 loop reload loadbalance } 其中 kubernetes 插件中有一行 upstream 的配置，它是定义了用于解析指向外部主机的服务的上游解析器（也称之为外部服务，CNAME）CoreDNS 将针对自身解析该服务。 在此次变更之后， upstream 配置行便可直接移除。 另外 template 插件支持元数据了。比如说可以给它增加一个配置 .Meta "kubernetes/my-namespace"。 关于此版本的更详细说明可阅读 ReleaseNote Envoy v1.

「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。 Kubernetes v1.16 发布周期开始 随着前段时间 Kubernetes v1.15 的发布，v1.16 的发布周期开始了。本次的发布周期一如往常，本月底增强功能冻结，下月底代码冻结，9 月初完善文档，计划在 9 月中发布 v1.16 版本。 其实按这个节奏看得话，大家如果需要维护生产中的 Kubernetes 集群的话，还是尽快测试验证并完成升级，以免所用版本 EOL，带来一些其他的问题。 Knative Serving v0.7.x 发布 本周 Knative Serving 发布了 v0.7.1 版本，Knative 近期的开发还是比较活跃的。 需要注意的是若使用 v0.7.x 版本中新增的 serving.knative.dev/v1beta1 API 的话，则需要 Kubernetes v1.14 版本以上。具体原因请参考 #4533 Non-root 容器：在这个版本中所有发布的容器均以非 root 用户运行，这使得我们可以使用更严格的 PSP。 当然此版本中也包含一些破坏性变更，比如 status 字段废弃。 关于此版本更多的细节请参考 ReleaseNote Debian 10 buster 正式发布 Debian 10 正式发布了，其实按一般的角度来看，Linux 的一个发行版发布不会出现在 K8S 生态周报中的。 但这里有个需要注意的点，对于使用此版本部署 Kubernetes 时，需要注意一下。此版本中使用的 systemd 版本是 241.

「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。 kind (Kubernetes In Docker) v0.4.0 正式发布 kind (Kubernetes In Docker) 是我很喜欢并且一直持续参与贡献的项目，本周发布了 v0.4.0 版本。关于 Kind 的介绍和基础使用，可以参考我之前写的文章 《使用 Kind 搭建你的本地 Kubernetes 集群》 v0.4.0 版本中，默认的 Kubernetes 版本升级到了 v1.15 版本，且 kind.sigs.k8s.io/v1alpha2 版本的 API 已经过期，请更新使用 kind.sigs.k8s.io/v1alpha3 。 目前暂时移除了使用 apt 构建 Node 镜像的选项，之后版本中可能会加回来，直接使用上游构建好的二进制文件进行安装。 在此版本中，我们增加了一个 nodes[].extraPortMappings 的配置，可以直接通过此配置进行端口的转发，以便从宿主机上直接访问到集群上使用 NodePort 方式部署的服务，这样更容易模拟真实的网络环境，否则只能通过其他的转发或者网络代理的方式来进行通信了。 同样的，紧跟着上游的开放，这个版本中也增加了对 IPv6 的支持，可以直接通过 networking.ipFamily 的配置进行使用。 为了能让 kind 更加易用，且满足多数 CI 或者测试使用的场景，在这个版本中，我们尤其对单节点集群的启动时间做了优化，可以更快速的启动集群。 顺便公布一个数据，kind 目前的 star 数是 2.2k 上个版本发布时是 1.8k 并且还在持续增长中 :) 更多的细节和信息请参考 ReleaseNote 欢迎大家使用！

「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。 Kubernetes v1.15.0 正式发布 经过了三个月左右的开发，Kubernetes v1.15.0 正式发布了。 这是 2019 年 Kubernetes 发布的第二个版本，这个版本由 25 个增强功能组成，其中 2 个移动到 stable ，13 个 beta 以及 10 个 alpha ，整体上集中于稳定性改进和扩展的增强。 CRD (Custom Resource Definition) 是 Kubernetes 提供的一种可用于扩展其能力的方式，当前有很多使用 CRD 构建于 Kubernetes 上的平台/系统，可以说之后对 Kubernetes 的扩展，或者说想要基于 Kubernetes 开发，同时又想与上游保持同步的话，CRD 是个最佳的选择。 Kubeadm 在此版本开始有了自己独立的 LOGO ，同时在这个版本中 kubeadm 的功能也得到了很多的完善和补充。这使得 kubeadm 成为更普遍/更好用的搭建集群的工具，同时对集群生命周期的管理也做的更加到位了。这部分的功能我很喜欢也一直在关注，近期我会针对这部分写篇文章出来。感兴趣的朋友们可以关注下 关于此版本更多的介绍，可参考 Kubernetes v1.15 ReleaseNote Istio 1.2.0 正式发布 经过三个 rc 版本之后， Istio 1.2.0 版本正式发布。 在这个版本中，它添加了对 Kubernetes IPv6 的实验性支持。Kind （Kubernetes in Docker） 项目也是本周内刚增加了 IPv6 的支持 :)

「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。 Helm 新下载域名正式上线 https://get.helm.sh/ 正式上线。用户之后下载 Helm 预编译好的二进制文件时，可通过此域名进行下载。 原来 Kubernetes 尚未成为 CNCF 托管项目时，Helm 是作为 Kubernetes 项目的一部分的，所以很自然的使用了 Google 的一个云存储仓库。但随着项目托管至 CNCF 以及后续 Helm 的独立发展，现在使用托管于 Google 的云存储不那么合适了，一方面在于 CNCF 正在接管 K8S 的基础设施，另一方面在于在于这个仓库不只受 Helm 的控制。 考虑到项目的独立性，以及 大陆用户无法正常访问 GCloud 存储的问题 经过维护者们的慎重考虑以及实际测试，终于决定选择 Azure 的 Blob 存储 + CDN 可满足当前所有地区的快速访问（尤其是国内可以直接访问并下载），不再需要花费时间精力解决网络等问题了。 这次的更改仅限于 Helm 客户端的下载位置，类似 Tiller 或者 Chart 等并没有被包含在内。 强烈建议更新有在 CI/自动化任务中使用的 Helm 下载地址，使用 https://get.helm.sh/ 来进行替换。 对此内容感兴趣的朋友可参考 Move Helm Downloads 的讨论 Apple 作为白金终端用户成员加入 CNCF Apple 在 K8S 社区中在这之前也算相对低调，并没有像各类云厂商或其他公司那样疯狂安利或者输出之类的。但是这次突然加入 CNCF 而且作为白金会员，是可具备话语权的。