Docker 核心知识必知必会

自 2013 年起,随着 Docker 的正式面世,容器技术迅速成为了基础技术领域中的热门。而在近两三年中,随着容器编排领域的混战结束,Kubernetes 已经成为了容器编排领域事实上的标准。 有一些人存在误解,认为 Kubernetes 的出现取代了 Docker。但事实上,Docker 与 Kubernetes 是相辅相成的。Kubernetes 使用 Docker 作为容器运行时,用来启动应用;当 Docker 容器规模变大时,自然是需要有容器编排工具进行管理的。引用最近一次的网络研讨会后的文章内容: In fact, Kubernetes is better with Docker. And Docker is better with Kubernetes. 无论在使用 Docker 或是 Kubernetes 亦或者是使用基于这些技术的其他衍生技术时,都有可能会遇到一些意料之外的情况,当问题发生时,我们总是希望可以快速定位问题,并且从根本上解决问题。 一般情况下,上层的问题比较容易解决,但如果问题发生在运行时/Docker 或容器上时,如果没有系统性的知识,很难从根本上解决问题;当然,有些时候通过搜索引擎可以帮我们找到一些问题的解决办法,但如果不将其彻底搞懂,以后遇到类似问题可能还是没法快速解决。 我自 Docker 0.9 版本时开始学习和使用,自己踩过了很多坑,活跃在社区中,也帮别人解决了很多问题。现在我的新专栏《Docker 核心知识必知必会》正式上线了,共 51 节,从 7 个核心维度来 系统性 的讲解 Docker 容器技术的核心特性及原理,实践与源码相结合;部分内容会深入到 Linux 内核源码,以此来建立起从内核到 Docker 容器技术的知识体系。 我希望借由这个课程,将 Docker 容器技术的本质和思想与我在开发和运维 Docker 过程中对其原理和实践经验的总结讲清楚,并将结合着实践和核心特性的原理,加深对 Docker 容器技术的理解。 因此,我把课程划分成了三大模块: Docker 入门: 这个模块分成了三篇内容,通过第一篇,带你了解 Docker 容器技术生态的发展脉络;第二篇,是为刚入门 Docker 的读者准备的,也是为后续章节进行铺垫;第三篇是很多读者或公司都常会困惑的问题,Docker 与 Linux 内核兼容性如何,要上生产环境该选择哪个版本?我会在这一篇中与你分享,让你不再困惑。

K8S 生态周报| runc v1.0.0-rc9 发布

「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。 runc v1.0.0-rc9 发布 不知不觉,runc v1.0.0-rc9 于近日发布了。早先关注过我文章的朋友们应该看到过我从去年开始每次在 runc 新版本发布时都有专门写一篇文章进行介绍。这次版本的定位主要是修复 CVE-2019-16884 所以我也就不再单独写文章介绍了(另一个原因是现在在假期,还是多抽空陪陪家人) 先对 CVE-2019-16884 做个简单的介绍。这是一个中等级别的漏洞,其主要影响是 runc 源码中的 libcontainer/rootfs_linux.go 在文件挂载至 /proc 时,少做了一些检查,可绕过 AppArmor 的限制,所以可能导致被一些恶意镜像所利用。 主要的修复方式是将原先的 checkMountDestination 函数改写为 checkProcMount,并在其中添加了对源文件类型的判断,只允许 procfs 类型的文件挂载至 /proc 。 此漏洞影响到的范围是 runc 以及一些使用 runc 作为基础组件的容器管理软件。请尽快进行升级。 此版本的地址是:https://github.com/opencontainers/runc/releases/tag/v1.0.0-rc9 Docker v19.03.3-rc1 发布 自从 Docker 修改维护周期后,Docker 对软件的质量要求有了显著提高,每次版本发布前会经历多阶段的测试和回归,确保软件没有什么问题后才会发布正式版。 按现在的进度来看 v19.03.3 应该会在一两周内放出。新版本会将 containerd 升级至最新的 1.2.10 ,并修复了一个在 5.2 版本内核上 overlay2 文件系统挂载时的错误。 关于此版本感兴趣的朋友可以参考 ReleaseNote 上游进展 Kubernetes v1.17 已经进入发布周期,这个版本的发布周期会比较短,现在已经发布了 v1.17.0-alpha 版本,计划是在 12 月 9 日可以最终发布。(想想看,距现在也就两个月的时间,你的集群现在是哪个版本呢?)

K8S 生态周报| containerd v1.3 正式发布

「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。 containerd v1.3.0 正式发布 在上个主版本(v1.2.0)后经过 11 个月,我们终于迎来了 containerd v1.3.0 的发布,当然这个版本也是 containerd 自 CNCF 毕业后的首个主版本。(关于 containerd 毕业的信息可参考我之前的文章) 在三周前 containerd v1.3.0-rc.0 发布时,我也提到过一些,现在我们来整体看一下。 增加了 Windows v2 的 runtime API, 同时移除了 Windows v1 API; 为修复 CVE-2019-16884 更新了 runc 依赖; 可配置的插件目录; 允许插件注册为一个 TCP Server ,通过这种机制其实可以做到很多的事情了; 增加了流式处理的插件,允许在解包的时候处理自定义资源类型(设计上考虑可使用此功能进行加解密相关的逻辑); 支持跨仓库推送镜像; 新增了 devicemapper 的快照支持,然而需要注意的是 Docker 已经将 devicemapper 的存储驱动标记为了过期,推荐大家使用 Overlay2 的存储驱动; 在 CRI 方面 io.containerd.runtime.v1.linux 仍然是默认的运行时,可选配置为新的 io.containerd.runc.v2,新的版本

K8S 生态周报| Kubernetes v1.16 正式发布

「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。 Kubernetes v1.16 正式发布 正如我在上次周报中所说,本周 Kubernetes v1.16 正式发布了。此版本中共包含 31 项功能增强:其中 8 项处于 stable 阶段,8 项处于 beta 阶段,剩下的 15 项处于 alpha 阶段。 如果一直关注本周报系列文章的话,这个版本中比较重要的功能我基本都已经提到过了(这里划个重点)。 CRD 达到 GA ,这是当前社区最为推崇的一种扩展 Kubernetes 的方式,并且自从 1.7 加入后,也被越来越广泛的使用了; 准入控制 webhooks 达到 GA ,准入控制在 Kubernetes 中太过于重要了,自 1.9 该功能加入以来,被广泛用于扩展 Kubernetes 相关功能; 现在 CSI 规范中支持调整卷大小,当前正在迁移至 Beta 阶段; IPv4/IPv6 双栈支持; 为了更好的控制 kube-apiserver 的网络流量,正在尝试给它增加一个代理,详情可点击链接查看; 其余还有一些比较重要的内容: 现在 kubeadm 在 TLS bootstrap 之后,将会删除 bootstrap-kubelet.conf,如果有依赖此文件的小伙伴,请尽快迁移使用 kubelet.conf ,此外也建议先看看 RBAC 相关的内容,了解下切换的意义; beta.

K8S 生态周报| Istio 1.3 正式发布

「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 生态周报| Harbor v1.9 带来众多新特性

「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 生态周报| etcd v3.4.0 带来众多更新

「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 生态周报| cilium 1.6 发布 100% kube-proxy 的替代品

「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 生态周报| 2019-08-12~2019-08-18

「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 生态周报| 2019-08-05~2019-08-11

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