IBM 不满谷歌移交 Istio 商标

近日,谷歌正式宣布创建 Open Usage Commons(OUC),并将开源服务网格 Istio 项目商标的所有权移交至 OUC,由其负责商标中立且独立的管理。(详情请点击

在谷歌发布声明后,作为对 Istio 做出过重大贡献的企业,IBM 却立即发文表示不满:

这不符合社区开放治理的项目期望。一个项目成功的基础是开放、中立的治理过程,而 OUC 与谷歌之间的紧密关系,可能会导致 Kubernetes 相关社区之间的摩擦。

IBM 在文章中称:在 Istio 项目启动时,谷歌就与我们达成了协议,会在项目成熟时将 Istio 捐赠给 CNCF。我们认为只有在 CNCF 这种公平公开的组织下进行项目管理, Istio 才能保持项目的中立。因此我们建议谷歌重新考虑当初的约定,把 Istio 捐赠给 CNCF。

2020 K8s 漏洞及解决方案

开源漏洞是企业和开发者都密切关注的问题。作为容器编排的行业事实标准,Kubernetes 正被越来越多企业用于管理容器工作负载,除了直接使用 Amazon EKS 等巨头托管式服务,自主管理集群如今也成了一种流行的选择,这使时刻关注 Kubernetes 漏洞成了开发者的必修课。

下面是 2020 年以来最新发现的 Kubernetes 安全漏洞,以及漏洞的解决方案:

CVE-2020–10749

containernetworking plugins 是美国 Linux 基金会的一款 CNI(容器网络接口)网络插件工具集。上述漏洞存在于 0.8.6 之前的所有版本中,攻击者可通过发送恶意 IPv6 路由器通告利用该漏洞实施中间人攻击。

解决方案:避免不受信任的非特权容器运行 CAP_NET_RAW,目前厂商已发布升级补丁以修复漏洞:github.com/containernetworking/plugins/pull/484/commits/219eb9e0464761c47383d239aba206da695e1a43

CVE-2020–2121

Jenkins Google Kubernetes Engine 插件 0.8.0 及更早版本未配置其 YAML 解析器来防止实例化任意类型,这导致用户能够向 Google Kubernetes Engine 插件的构建步骤提供 YAML 输入文件的用户执行远程代码执行漏洞。

解决方案:谷歌已发布修复程序:www.jenkins.io/security/advisory/2020-02-12/#SECURITY-1731

CVE-2020–8552

Google Kubernetes API server 中存在资源管理错误漏洞,攻击者可借助 API 请求利用该漏洞造成拒绝服务。

解决方案:可升级到 v1.18.0-alpha.3 版本避免该漏洞,v1.17.3、v1.16.7 和 v1.15.10 的 API server 已完成漏洞修复。

CVE-2020–7010

1.1.0 版本之前的 Kubernetes Elastic Cloud(ECK)使用弱随机数生成器生成密码,如果攻击者能够确定当前 Elastic Stack 集群的部署时间,则他们也许能强制执行 ECK 生成的 Elasticsearch 凭证。

解决方案:升级到最新版本。

CVE-2020–8551

Google Kubelet v1.15.0-v1.15.9、v1.16.0-v1.16.6、v1.17.0-v1.17.2 中存在资源管理错误漏洞,攻击者可利用该漏洞造成拒绝服务。

解决方案:v1.18.0-alpha.4 已更新修复程序,除了使用最新版本,开发者还应遵循最佳实践:除特殊情况外,始终确保禁用匿名身份验证;始终确保仅可从受信任的子网访问 API 服务器,并且确保它不被公开在网上。

K8s 部署应用易忽略的 5 件事

大多数人将应用程序成功部署到 Kubernetes 上后就放松了警惕,以至于忽略了一些“陷阱”。为了帮助大家并避免踩坑,下面罗列了这些“陷阱”,希望大家可以更好地使用 Kubernetes。

配置 Pod 请求和限制

应用开发首先要配置一个可以运行 Pod 的干净环境。Kubernetes 在处理 Pod 调度和故障状态方面非常出色。但是有件事我们需要注意,如果 Kubernetes 调度程序无法确定 Pod 运行需要多少资源,就无法正常放置 Pod,这就要提到资源请求和限制。这里着重要指出一点,更高的资源限制意味着更难的 Pod 调度,因为这样需要有足够可用资源的目标节点。想象一下在高资源限制(例如 4GB 内存)的情况下运行轻量级 Web 服务器进程。此时,我们需要水平扩展,并且每个新容器都需要在至少 4GB 可用内存的节点上进行调度。如果没有这样的节点,我们还需要引入一个新节点来处理该 Pod。因此,资源请求和限制的难点就在于在二者之间获得一个平衡,以确保快速、平稳地扩展。

配置 Liveness 和 Readiness 探针

这是 Kubernetes 社区中经常讨论的一个话题。掌握 Liveness 和 Readiness 探针非常重要,因为它们提供了一种运行容错软件并最大程度减少停机时间的机制。但如果配置错误,它们可能会给应用程序带来严重的性能下降。

设置 Pod 默认网络策略

Kubernetes 是一种类似“扁平”的网络拓扑,在默认情况下,所有 Pod 都可以直接相互通信。大多时候,这种通信不仅没必要,还会导致潜在的安全隐患。举个例子,单个被攻击的应用程序会为攻击者提供极高的访问权限,攻击者可能会借此攻击该网络上所有可访问的 Pod。安全领域中的最小访问策略,就是为此情况而设置的。我们最好使用网络策略,明确指定容器与容器之间的通信。

内核调优

Kubernetes 是一个非常灵活的平台,可以让我们以自己喜欢的方式运行工作负载。许多高性能的应用程序对资源的需求非常苛刻,对此,Kubernetes 允许运行特权容器,可以修改仅适用于特定运行 Pod 的内核参数。这种方法并不复杂,如果应用程序难以在高负载下保持运行,那可能需要尝试调整其中的一些参数。

循环测试

最后,尽管 Kubernetes 是一种优秀的“开箱即用”解决方案,但是我们仍然需要小心谨慎以确保应用程序的平稳运行。在将应用程序在 Kubernetes 上运行的整个过程中,尽量“循环”进行负载测试,就是在运行应用程序时,进行负载测试,观察指标和扩展行为,再基于该数据调整配置,循环进行负载测试。

Istio 4 个常用命令

Istio 是云原生领域的重要项目,它将路由、可观察性和安全性三大要素合而为一。这里罗列了 4 个常用的 Istio 命令。

kubectl get pods -n istio-system

该命令用于检查 Pod 是否为 Running 状态。Istio 通常将控制平面组件安装在 istio-system 命名空间中,但在 Istio 1.6 及更高版本中,变成了 istiod 组件。以下是示例:

kubectl logs -n istio-system -l app=istiod

该命令用于从 Istiod 中获取日志,提供控制平面中发生事件的快照。下面是检查 istiod 日志的示例:

istioctl analyze

istioctl analyze 是一种诊断工具,可以检测 Istio 配置的潜在问题。它可以针对运行的群集或一组本地配置文件运行,还可以将两者结合起来使用,从而在更改应用之前发现问题。

istioctl proxy-status

proxy-status 命令用于网格概览。如果输出列表中缺少某个代理则意味着它当前未连接到 Polit 实例,所以它无法接收到任何配置。此外,如果它被标记为 stale,则意味着存在网络问题或者需要扩展 Pilot。