「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。 Istio 1.3.0 正式发布 上周 k8s 生态周报中，我推送了关于 Istio 1.3.0-rc2 发布的消息后，有小伙伴专门私聊我，说想问问 Istio 1.3 到底有什么新特性；以及为何上次没有对 Istio 1.3 的新特性进行介绍。 这里我来做下说明，首先关于为何上次没有对 Istio 1.3 新特性进行介绍。有两个主要原因：1. 上周时，正式版尚未发布；2. 对 1.3 这个版本而言没有太多新特性，此版本主要在于改善用户体验。 对 Istio 而言，今年是个很重要的节点，而且自从 3 月份发布 1.1 版本以来， Istio 的更新频率基本稳定在了 3 个月发布一个版本。1.1 版本专注于企业就绪，在此版本中一方面是提升系统的稳定性，另一方面则是解决企业落地时，可能遇到的一些问题，所以 1.1 中有大量的新特性。而 1.2 版本其实也类似，虽然花费了很多精力在保证质量上，但其中也有不少功能从 Beta 到了 Stable 阶段。 其次是关于 1.3 版本到底有哪些新特性： 出站流量自动确定协议：之前版本中，Istio 要求 Service 需要按照指定的规则进行命名才可以自动确认其协议，而在此版本中则可以自动确认其是 HTTP 或 HTTP/2 流量，如果无法自动确认，则认为其是纯 TCP 流量，如果是通过 Helm 安装的话，可以使用 --set pilot.enableProtocolSniffing=false 关闭此功能； Pod spec 中不再需要定义 containerPort，默认情况下会捕获所有端口，当然你也可以通过 traffic.

「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。 Docker CE 19.03.2 发布 Docker CE 19.03.2 已于近日发布，事实上此版本内更新的内容本该在 19.03.1 中发布的，不过 19.03.1 主要是为了修正 CVE-2019-14271 如果你正在使用 19.03.0 那我建议你进行升级。 为了保证尽可能快的修复问题，所以专程发布了 19.03.1 版本，而把原先预期的功能转移至 19.03.2 中进行发布。这其实也是 Docker 做的比较好的一个事情，Docker 的版本发布很有原则。 我们来看看 19.03.2 中带来了哪些变化： 修正了Docker CLI 对 HTTP Proxy 环境变量的支持； 修正了一个为容器使用 XFS 磁盘配额可能产生的 panic； 其他变化，感兴趣的朋友可以参看其 ReleaseNote containerd 1.3.0-rc.0 发布 1.3 将会是 containerd 的下一个主版本；而自 containerd 1.2 发布以来已经过去了近 9 个月。我们来大致看看 1.3 中有哪些值得期待的功能。 增加了 Windows v2 的 runtime API， 同时移除了 Windows v1 API； 新增了 devicemapper 的快照支持，然而需要注意的是 Docker 已经将 devicemapper 的存储驱动标记为了过期，推荐大家使用 Overlay2 的存储驱动； 允许插件注册为一个 TCP Server ，通过这种机制其实可以做到很多的事情了； 可配置的插件目录； 在 CRI 方面 io.

「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。 Helm 3 beta2 发布 Helm 3 从 Alpha 之后，就一直进入了持续改进阶段。终于现在 beta2 发布了，按现在社区的开发进度来看，今年发布正式版的希望还是很大的。 感兴趣还是建议可以先尝试下，以免之后升级时带来不适。 CoreDNS v1.6.3 发布 federation 将在 1.7.0 中被完全废弃； 新增两个插件 clouddns 和 sign，其中 clouddns 顾名思义是为云环境设计的，现在它支持 GCP （Google Cloud Platform）Cloud DNS 提供的 zone 数据，实际上它是通过 Google Cloud 的 API 来获取这些信息的，如果你没有在使用 GCP Cloud DNS 的话，目前这个插件应该是用不到的；sign 插件则是根据 RFC 6781 对 Zone 使用 NSEC 签名，但需要注意的是签名是有时效的，如果到了过期时间，则 Zone 信息会变成 Bad 状态（RFC 4035），所以如果你想要使用这个插件，请明确知道自己需要做什么以及为何使用它； file 插件修复了一些内存泄漏的问题； 除了上述提到的内容外，想稍微再提一下在 v1.6.2 中新增的 azure 插件，它其实和 clouddns 做的事情类似，只不过是从 Azure 获取记录罢了。另外从 v1.

「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。 Kind(Kubernetes In Docker) v0.5.1 正式发布 Kind(Kubernetes In Docker) 已经广泛的应用于 Kubernetes 上游及相关项目的 CI 环境中，作为个人本地的测试环境也很方便，推荐大家尝试。 本次发布，将默认的 Kubernetes 版本更新为 v1.15.3 ；支持了 UDP 和 SCTP 协议的端口转发；对构建 Node 镜像进行了优化，使它更快；同时也对 arm32 增加了有限的支持。 对 kind load-image 进行了改进，从原先的只是判断镜像名称和 tag 到现在增加了对哈希值的校验；修正了在使用 Proxy 时，部分服务可能受代理影响导致的问题（对国内用户友好）。 更多关于此版本的内容，请参考 ReleaseNote，欢迎使用和反馈。 Kubernetes 受 Go 的 net/http 安全漏洞影响 Kubernetes 近期紧急发布了 v1.15.3, v1.14.6, v1.13.10 版本，距离上个集体更新发布仅过了两周而已，上次的说明请参考两周前的 k8s 生态周报，不过本次的漏洞的根本原因不在 Kubernetes 的功能逻辑上，还是在于其使用的 Go 语言的 net/http 库的安全漏洞 CVE-2019-9512 和 CVE-2019-9514 。 关于此次漏洞的信息，可参考 golang/go#33606，另外 Go 最近陆续发布了几个版本，建议大家也最好升到 v1.

「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.