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

「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。 Kubernetes v1.19 正式发布 本周 Kubernetes v1.19 正式发布,这是今年发布的第二个版本,也是耗时最长的一个版本。 在此版本中有 34 个增强功能,其中 10 个GA,15 个 beta 以及 9 个 alpha。并且从 v1.19 开始,Kubernetes 每个版本的支持周期延长至 1 年。(感谢[ Long Term Support (LTS) working group ](https://github.com/kubernetes/community/tree/master/wg-lts#readme “LTS WG”)) 关于此版本中重要的变更,可参考我每期周报中 “上游进展” 的部分。或者直接参考 官方博客中 v1.19 的介绍文章 。 这里我来单独介绍一个更具体且实用的特性。 API 弃用规则 Kubernetes 是一个庞大的系统,当讨论它的 API 时,我们不得不提到常用的 4 个术语,即:group(组), version(版本), kind(类型)和 resource(资源)。 一个 API group 是一组相关功能的集合,group + version 是确保 API 可随着时间推移,进行版本升级或功能更新的基础。 这里我来介绍下 自 Kubernetes v1.

K8S 生态周报| Google 选择 Cilium 作为 GKE 下一代数据面

「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。 Google 选择 Cilium 作为 GKE 网络的数据面 Google 声明将选择 Cilium 作为 GKE 网络的数据面 V2 以便增加其容器安全性和可观测性。 Kubernetes 最强的能力之一便是其开发者优先的网络模型,可以提供简单易用的功能,比如: L3/L4 service 和 L7 ingress 以便将流量引入 Kubernetes 集群,以及多租户的网络隔离等。 但随着越来越多的企业使用 Kubernetes , 用例范围越来越广,围绕多云,安全性,可观察性和可扩展性等方面均提出了新的要求。此外,诸如 service mesh 和 serverless 等技术,均需要来自底层 Kubernetes 的更多自定义。这些新要求最终汇聚到一起得出来的结论便是: 需要一个更具可编程性的数据平面,该平面可执行 Kubernetes 感知的数据包操作,并且还不会损失性能。 Cilium 的出现恰恰满足了这些需求,它基于 eBPF 技术的实现,使 Linux 内核具备了 Kubernetes 的意识。它可以很好的满足现在新的对容器负载的可伸缩性,可观察性以及安全等方面相关的要求。此外, Cilium 所提供的功能也远超了传统 CNI 提供的功能,不仅有传统的 Network Policy, service 和 LB ,还有 Flow & Policy logging 以及内置运维和安全侧的 metrics 等。

K8S 生态周报| Helm v2 进入维护期倒计时

「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。 Helm v2 将正式废弃 本周,Helm v2 系列发布了 v2.16.10 版本, 这是 Helm v2 的最后一个 bugfix 版本,此后不会再为 Helm v2 提供错误修复。并且在三个月后,将停止为 Helm v2 提供安全补丁。届时, Helm v2 也就完全废弃,不会再去维护了。 如果有在使用 Helm v2 的小伙伴,请尽快升级至 Helm v3, 社区也提供了 Helm 2to3 的工具,可以帮助迁移。 另外,还有个别厂商绑定 Helm v2 提供应用安装/部署服务的,也建议尽快迁移了。 我统计了下,我发布的文章中,有 25 篇与 Helm 相关。包括 Helm v3 的尝试,Helm v2 的废弃计划,从 Helm v2 迁移到 v3 等内容,感兴趣的小伙伴可以看看历史文章。 DockerHub 修改了定价和 TOS DockerHub 本周对其服务收费以及 TOS(Terms of Service)。我们重点来看看本次的修改对我们会有哪些影响吧。 这里重点来看看对免费用户/(未登录)匿名用户的影响。 流量限制

K8S 生态周报| runc v1.0-rc92 发布

「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。 微软开源了 Open Service Mesh 微软近期开源了一个新的名为 Open Service Mesh 的项目并准备捐赠给 CNCF 。 OSM 主打轻量&可扩展,支持 Service Mesh Interface (SMI) 规范 附带开箱即用的可观察性功能。截至目前,已经发布了v0.2.0 版本。 主要特性如下: 支持 Service Mesh Interface (SMI) 的规范,主要包括 Traffic Access Control, Traffic Specs 和 Traffic Split 。剩下的 Traffic Metrics 正在开发中; 服务间的通信加密使用 mTLS ; 定义和执行服务间的访问控制策略; 通过 Prometheus 和 Grafana 完成其观察性; 可与外部证书管理服务进行集成; Envoy sidecar 自动注入; 关于 Open Service Mesh 更详细的内容,请参考我上一篇文章 初试 Open Service Mesh(OSM)

初试 Open Service Mesh(OSM)

微软近期开源了一个新的名为 Open Service Mesh 的项目并准备捐赠给 CNCF 。 基本介绍 Open Service Mesh (OSM) is a lightweight, extensible, Cloud Native service mesh that allows users to uniformly manage, secure, and get out-of-the-box observability features for highly dynamic microservice environments. Open Service Mesh(OSM)是一个轻量级,可扩展的云原生服务网格,它使用户能够统一管理,保护和获得针对高度动态微服务环境的开箱即用的可观察性功能。 OSM 在 Kubernetes 上运行基于 Envoy 的控制平面,可以使用 SMI API 进行配置。它通过以 sidecar 的形式注入 Envoy 代理来工作。 控制面负责持续配置代理,以配置策略和路由规则等都保持最新。代理主要负责执行访问控制的规则,路由控制,采集 metrics 等。(这和目前我们常见到的 Service Mesh 方案基本都一样的) 显著特性 基于 Service Mesh Interface (SMI) 的实现,主要包括 Traffic Access Control, Traffic Specs 和 Traffic Split 。剩下的 Traffic Metrics 正在开发中; 服务间的通信加密使用 mTLS ; 定义和执行服务间的访问控制策略; 通过 Prometheus 和 Grafana 完成其观察性; 可与外部证书管理服务进行集成; Envoy sidecar 自动注入; 上手体验 只做介绍未免太过无趣,而且说实话,这么多 service mesh 实现,不亲自上手试试看,感觉不出来太多差异的。

K8S 生态周报| Istio 已修复导致 Pod 崩溃的 bug

「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。 Istio 1.6.7 发布 Istio 1.6.7 是为了解决在 1.6.6 中引入的一个 bug。 该 bug 可能会导致 在使用 Istio 1.6.6 时,某些 Pod 进入 CrashLoopBackOff 状态,无法正常提供服务。 修复后的核心代码如下,这里主要是增加另一个返回值 expectpod 。 通过此方法获取 Pod 时,Pod 有两种情况可能为空: 该 endpoint 未关联 Pod,这时 expectpod 为 false; 该 endpoint 已关联 Pod,但未找到 Pod,这时 expectpod 为 true 而这种情况发生的最主要原因可能是由于最终一致性,或者乱序事件等。 建议如果打算升级 Istio 的读者,直接跳过 1.6.6 版本,以免影响到服务。 func getPod(c *Controller, ip string, ep *metav1.ObjectMeta, targetRef *v1.ObjectReference, host host.Name) (rpod *v1.Pod, expectPod bool) { pod := c.

K8S 生态周报| NGINX Ingress Controller又添新特性

「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。 Conftest 正式加入 Open Policy Agent 项目 conftest 是一个非常实用的 CLI 工具,可以用于测试/验证配置文件是否符合预期。例如,可以通过如下内容来定义规则: package main deny[msg] { input.kind = "Deployment" not input.spec.template.spec.securityContext.runAsNonRoot = true msg = "Containers must not run as root" } deny[msg] { input.kind = "Deployment" not input.spec.selector.matchLabels.app msg = "Containers must provide app label for pod selectors" } 使用此规则去检查一个未符合预期规则的 Deployment 的配置文件: (MoeLove) ➜ conftest test deployment.yaml FAIL - deployment.yaml - Containers must not run as root FAIL - deployment.

K8S 生态周报| Traefik v2.3.0-rc2 发布

「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。 Traefik v2.3.0-rc2 发布 关于 Traefik 的系列介绍可以参考之前周报的内容:Traefik v2.2.0-rc1 发布。本周它又发布了 v2.3.0-rc2 版本,我们一起来看看有哪些值得关注的内容吧! #6696 为 Traefik 在 terminating 时,添加自定义的 HTTP 状态码; 具体而言,可通过以下几种方式进行添加: 配置文件(YAML) ping: terminatingStatusCode: 204 命令行参数 --ping.terminatingStatusCode=204 环境变量 TRAEFIK_PING_TERMINATINGSTATUSCODE=204 现在默认的状态码是 503 增加此配置的好处在于,当 Traefik 处于 terminating 状态时,可通过设置自定义的状态码来实现优雅终止。 #6875 使用 parser 从文件中取动态配置; 值得注意的是: 如果从之前版本升级至 v2.3 那一定需要注意的是如果动态配置中存在未知的其他字段,则返回错误。 #7041 Traefik 提供了 Plugins 特性的支持。可以通过此机制,让 Traefik Pilot 连接到 Traefik ,以此来将其 SaaS 能力暴露给用户。同时 Traefik Pilot 可以监控连接到它的任意 Traefik 实例,并支持发出报警。

K8S 生态周报| Helm v3.3.0-rc.1 发布

「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。 Helm v3.3.0-rc.1 发布 这是 Helm v3.3.0 的预发布版本,在此次版本中,重点在修复 helm lint 相关的错误,以及提升整体的稳定性和其他一般性 bug 的修复。我主要介绍几个值得注意的内容: #8277 将 warning 信息从写入 stdout 修改为写入 stderr ,这样可大大方便将 helm 用于 pipeline 中。比如 helm template 与 kubectl 组合使用; #8220 修复了当 chart 数量很多时,helm chart list 可能报错的问题; #8158 修复了 --repository-cache 不能被 repo add 和 repo update 识别的问题, 现在可以通过 repository-cache 自行指定 cache 目录; #7875 增加了 --insecure-skip-tls-verify 参数,用于在 pull/install 等阶段,跳过证书校验; #8011 增加了 lint 规则,以便于检查资源名称是否符合 K8S 的要求。 以上便是我认为此版本中值得关注的内容,更多关于此版本的详细信息,请参考其 ReleaseNote

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

「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。 runc v1.0.0-rc91 发布 如果不出意外的话,这将会是 runc v1.0 正式发布前的倒数第二个 rc 版。 本次有很多值得关注的变更。 首先是期待已久的 hooks 的变更,这是少数与规范有关的变更,当然它也是一直没有发布 v1.0 的原因之一。现有的使用 hook 的用户不受影响,比如说 NVIDIA Docker 用户,但是 runc 提供了其他的 hook ,比如 createRuntime 等。 其次是对 cgroup v2 的支持(我已经多次介绍过); 修复了一个小的安全漏洞 很早之前 runc 中默认将所有的设备都设置成了允许,这意味着需要用户自己去设置要去拒绝哪个设备访问。在 runc 的众多用户,均已经很早就修复了此问题。所以此问题在 runc 中被忽略掉了,直到现在才修复。 更多关于此版本的信息,请参考其 ReleaseNote Envoy v1.14.3 发布 此次 v1.14.3 版本的主题是安全修复。本次修复了如下安全漏洞: CVE-2020-12603 CVE-2020-12604 CVE-2020-12605 CVE-2020-8663 CVE-2020-8663 这些安全漏洞基本都是通过发送特定数据包,引起服务端大量消耗资源。 同时,此次的这些安全修复,也都影响到了 Istio ,所以 Istio 在本周也发布了 v1.