K8S 生态周报| 2019-07-08~2019-07-14

「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 生态周报| 2019-07-01~2019-07-07

「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 生态周报| 2019-06-24~2019-06-30

「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 生态周报| 2019-06-17~2019-06-23

「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 生态周报| 2019-06-10~2019-06-16

「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 而且作为白金会员,是可具备话语权的。

K8S 生态周报| 2019-06-03~2019-06-09

「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。 Kubernetes CVE-2019-11245 漏洞 这是一个评分为 4.9 的漏洞,算是一个中等漏洞。 受此漏洞影响的版本为 v1.13.6 和 v1.14.2 ,所以本周也加紧发布了 v1.13.7 和 v1.14.3 版本,以避免受此漏洞影响。 如果有使用 v1.13.6 和 v1.14.2 版本的小伙伴,请尽快进行 升级 以免受到影响。 上面说了最直接的解决办法,接下来对此漏洞大致做下介绍: 这个漏洞影响了 v1.13.6 和 v1.14.2 版本的 kubelet,具体表现为, 1) 如果 Pod 中的容器,开始时是以某个非 root 用户启动的,但是当它重启后,则会以 root (uid 0) 的身份启动。2) 或者是 Node 节点上已经存在了启动容器所需的镜像。 第 2 个情况比较常见,不再具体介绍。我们来看下第 1 种情况。举个栗子: 通常情况下,如果我们使用 Docker 官方的 Redis 镜像进行部署的时候,默认情况下将会以 redis 用户启动;而如果受此漏洞影响,当容器重启后,则当前的用户可能会变成 root (uid 0) 。使用 root 用户启动服务可能带来的危害,这里也不再多进行展开了。 也存在例外,比如已经显式的通过 runAsUser 指定了运行用户,则不会受到此漏洞影响。

Docker 镜像构建三部曲

我最近在 GitChat 写了一些 Docker 构建镜像相关的文章,这个系列写了三篇,通过这三篇将 Docker 构建镜像相关的事情基本就讲明白了,感兴趣的朋友扫描二维码或者点击链接即可。 高效构建 Docker 镜像的最佳实践 Docker 可谓是开启了容器化技术的新时代,现在无论大中小公司基本上都对容器化技术有不同程度的尝试,或是已经进行了大量容器化的改造。伴随着 Kubernetes 和 Cloud Native 等技术和理念的普及,也大大增加了业务容器化需求。 而这一切的推进,不可避免的技术之一便是构建容器镜像。 在本场 Chat 中,会讲到如下内容: Docker 镜像是什么 Docker 镜像常规管理操作 如何构建 Docker 镜像 逐步分解构建 Docker 镜像的最佳实践 如何提升构建效率 适合人群: 对高效构建 Docker 镜像有兴趣的技术人员 地址:https://gitbook.cn/gitchat/activity/5cd527e864de19331ba79278 进阶:Dockerfile 高阶使用指南及镜像优化 在上次的 Chat 高效构建 Docker 镜像的最佳实践 中,我们重点深入内部介绍了 Docker 镜像是什么;以及构建 Docker 镜像的最佳实践等。 即将发布的 Docker 19.03 版本中 Dockerfile 及构建系统有了很多变化。 在本场 Chat 中,会讲到如下内容: Dockerfile 高阶使用及新特性解读 Docker 19.03 构建系统解读 Docker 镜像安全实践 发现并优化镜像大小 地址:https://gitbook.

K8S 生态周报| 2019-05-27~2019-06-02

「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。 Kubernetes v1.15.0-beta.1 发布 随着 KubeCon EU 的结束,Kubernetes 的开发工作继续回归正常,本周相继发布了 v1.12.9 和 v1.15.0-beta.1。 随着 v1.15 的正式版临近,维护期的 Kubernetes 版本也将变成 1.12~1.15,请尽快升级。 这个版本的变化,等正式版发布时候再进行介绍好了,有兴趣可以先看 ReleaseNote Docker v19.03.0-beta5 发布 按照正常规律 Docker 19.03 正式版也将在近期进行发布,而最近的所有测试版本中,其实变化比较大的东西主要在 构建系统 上;构建系统的升级可以使构建速度更快,同时也增加了更多的安全特性。 这次的 beta5 也是常规修复,有兴趣可以先看 ReleaseNote Docker CVE-2018-15664 安全漏洞 在 5 月 29 日我看到了 CVE 的信息,这个漏洞会影响 Docker 的全部版本,漏洞攻击的主要途径是 docker cp 相关的操作。 但是不必太过紧张,因为这个漏洞的攻击范围其实不算太大;最主要可能被攻击的对象其实是公有云。对于普通用户而言,如果受此攻击,那前提是攻击者已经具备了机器的权限和 Docker 的操作权限(一般用户只要自行控制权限便可避免攻击的发生)。 漏洞发现者 Aleksa Sarai 开始提了一个 PR (他的实现方式是在 docker cp 操作的同时暂停容器),不过现在已经被一个新的 PR 给取代了,毕竟暂停容器意味着停止服务,这是难以接受的。 类似 Podman 之类的其实也存在相同的问题,不过现在也已经被修复了。

K8S 生态周报| 2019-05-20~2019-05-26

「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。 KubeCon EU 举办 2019 年第一个 KubeCon + CloudNativeCon 于 5 月 20 ~ 23 日在巴塞罗那成功举办,这次大会吸引了七千多名参会者远超去年的参会人数。 这也从另一个侧面反映了 Kubernetes 和云原生在大大的普及 在大会上宣布了不少值得关注的信息, 我在此大致列一下我认为值得关注的信息(虽然有些内容之前已经关注到了): OpenTracing, OpenCensus 合并为 OpenTelemetry; 微软推出 Service Mesh Interface(SMI)规范; NGINX Ingress Controller 发布 1.5.0 版本; Google 宣布 GKE 将会支持 Windows Server Container; Helm 3 的发展历程;(推荐阅读我之前写的 初试 Helm 3) 当然,大会上公布的信息还有很多,还有一些 CNCF 的计划等,这里暂且不提,感兴趣的朋友可以自行搜索或者参加下个月在上海举办的 KubeCon + CloudNativeCon 微软推出 Service Mesh Interface (SMI) Service Mesh 也是一个趋势,但现在并没有一个统一的规范,各个厂商的实现也都各有不同。微软本次提出的 SMI 主要是为 Kubernetes 服务网格提供通用接口,以便能让 Service Mesh 有更加通用的规范 (就像当初 CNI/CRI 那样子)

云原生应用开发新体验:Kui

云原生(Cloud Native)应用是伴随着 Kubernetes 应用范围的扩大,基于云模型而提出的一种概念。 本文来介绍一个云原生应用开发的工具 Kui, 这是一款由 IBM 开源的工具,使用 Electron 提供 GUI 能力。 Kui Shell offers a new development experience for building cloud-native applications. By combining the power of familiar CLIs with visualizations in high-impact areas, Kui enables you to manipulate complex JSON and YAML data models, integrate disparate tooling, and provides quick access to aggregate views of operational data. 正如以上介绍中提到的,Kui 提供了一种新的开发体验(原先大多数时候我们是通过 kubectl 与 Kubernetes 中的资源进行交互),Kui 结合了原有 CLI 的强大功能,并提供一种可视化的方式,方便我们对 Kubernetes 中 YAML 或者 JSON 格式数据的处理。