VMware 2020 年 Kubernetes 战略

2019 年 12 月 30 日,VMware 正式结束了对 Pivotal Software 的收购,正式从虚拟机领域进军容器领域,转型成云原生服务提供商。和此前被收购的 Heptio 和 Bitnami 一样,未来 Pivotal 的业务会被融入 VMware Tanzu 平台。

Kubernetes 和云原生是 VMware 2020 年的一个重要布局。在内部,VMware 发起了一个名为 Project Pacific 的项目,旨在将 Kubernetes 控制平台添加到 vSphere 中。这会使 vSphere 管理员能够管理容器化的应用程序,并将 Kubernetes 概念嵌入到 vSphere 中,用 Kubernetes 协调基于 VM 的应用程序。

对此,VMware 高级总监 Jared Rosoff 表示:

我们内部有这样一个观点,就是 Kubernetes 远不止是一个容器平台,它可以成为面向所有工作负载的平台,帮助管理员轻松部署和管理跨越多个技术堆栈的现代应用程序。

而作为押宝 Kubernetes 的进一步举措,有媒体报道称 VMware 正打算使用新兴的 MinIO 对象存储来通过 Kubernetes 微服务配置存储。MinIO 在容器化应用程序中被广泛使用,目前它的实例已有 2.888 亿个 Docker pull,而且全球有 27% 的 MinIO 是使用 Kubernetes 管理的。

KubeCon 成大型招聘现场

随着 Kubernetes 大获成功, KubeCon 近年来也开始在全球范围内引起人们的普遍兴趣,尤其是更传统的软件开发人员以及数百家希望应用这种技术的大型公司,

据福布斯近日报道,在月前结束的 KubeCon 北美专场上,参会的企业工程师大多携带“招聘”任务,他们把 KubeCon 直接变成了大型招聘现场:

  • 自动驾驶创业公司 Cruise 正在招募数百名精通各种技术的工程师,从机器人技术到云原生应用;
  • Discover 有 300 多个开放技术职位,包括 Java 开发人员;
  • 红十字会正在通过其 #Code4Good 倡议寻求志愿者;
  • Home Depot 在会议上设有一个展位,配备了正在学习 Kubernetes 的工程师;
  • Reddit 有 500 个空缺职位,急聘工程师和社区建设人员……

MUFG 的工程总监 Timothy Miller 向媒体表示:我们没有带来招聘人员,我们是直接招聘的,我们的 CTO 也在这里。这家世界最大的银行之一到场是为了招聘 30 位云原生开发人员,以抓住金融业的转型浪潮。

Capital One 进入全面上云时代

近日,美国银行 Capital One 宣布将于 2020 年陆续关闭剩余的 3 座数据中心,将机房内的工作负载、系统等全面迁移上公有云,这标志着它向云端过渡已进入最后阶段。

Capital One 是世界上最大的金融服务公司之一,早在多年前它就制定了自管 Kubernetes 实例的战略,以确保基于微服务的应用程序具有一定的安全级别。

自 2014 年起,这家金融服务公司一直在其 Kubernetes 强化实例上构建云原生应用程序。当时 Capital One 仍面临兼顾私有云和公有云环境的困境,经过短暂尝试,它决定彻底放弃私有云,利用 Kuebernetes 强大的编排能力使用多种公有云,率先进入多云时代。

发展至今,Capital One 的 Kubernetes 平台不仅能满足常规业务应用的开发维护,也开始具备一定 AI 部署能力。而它选择全面上公有云的原因,并不是为了节省成本,而是希望通过云原生充分利用云计算模型的优势。

谷歌发布云原生安全模型

近日,谷歌发布 BeyondProd 白皮书,为云原生安全提供了一个模型。

据介绍,BeyondCorp 是一个“零信任”安全框架,它将访问控制从外围转移到单个设备和用户,允许员工在任何位置安全地工作,而不需要传统的虚拟专用网络。所谓“零信任”,即“服务之间不存在固有的相互信任,工作负载之间应该始终保持隔离”。

使用容器的第一个大差异是由于调度。你不能依靠 IP 地址或主机名来保证安全性,你需要服务身份。——Maya Kaczorowski

在“零信任”网络中,保护边缘的网络仍然至关重要。但是,要将其发展为完全“零信任”网络还需要大量附加条款。

为了填补这一空白,谷歌白皮书设定了一些基本原则,如在受信任的机器上运行已知来源的代码、创建阻塞点来确保跨服务的一致策略实施、确保授权的数据访问。更重要的是:

这些原则可以确保容器和微服务的安全部署和彼此通信,同时还减轻了应用程序开发人员实现安全性的负担,让他们可以专注于编写应用程序。

通过这个模型,企业能规避应用开发过程中的各种安全隐患,从而有效地从 DevOps 过渡到 DevSecOps。在白皮书中,谷歌提供了一些列开源软件和工清单,包括 Envoy、Traffic Director、Kubernetes 准入控制器等。

本周 K8s 开源项目推荐

kubectl-tree
github.com/ahmetb/kubectl-tree
一个 kubectl 插件,用于通过 ownerReferences 上的对象探索 Kubernetes 对象之间的所有权关系。

sugarkube
github.com/sugarkube/sugarkube
一个可以创建临时 Kubernetes 集群的工具。仅需几个命令,你就可以启动和配置 Kubernetes 集群,将所有应用程序安装到其中,并创建所需的基础架构。

isopod
github.com/cruise-automation/isopod
这是用于 Kubernetes 配置的表达性 DSL 框架。由于没有 YAML 构件,Isopod 会将 Kubernetes 对象呈现为 Protocol Buffer,因此它们由 Kubernetes API 直接进行类型化和直接使用。

kubeform
github.com/kubeform/kubeform
它可以为 Terraform 资源和模块提供自动生成的 Kubernetes CRD,以便用户以 Kubernetes 原生方式管理任何云基础架构。

hubble
github.com/cilium/hubble
这是一个用于云原生工作负载的完全分布式的网络和安全性可观察性平台。

nodalingresser
github.com/jacobstr/nodalingresser
这个工具能使 GKE worker nodes 更易于在公共互联网上访问,而不会因使用 ILB 来使你的应用程序每月花费 20 美元。

博客推荐:限速服务 lyft/ratelimit 详解

Service Mesh 由 Data Panel、Control Panel 两部分组成,虽然目前的 Service Mesh 已经进入了以 Istio、Conduit 为代表的第二代 Control Panel。但是以 Istio 为例,它也没有自己去实现 Data Panel,而是仍然基于 Envoy 做了 Control Panel 来达成目标,可见 Envoy 在 Service Mesh 中地位的重要性。

Envoy 是一款由 Lyft 开源的 L7 代理和通信总线,目前也是 CNCF 旗下的开源项目,代码托管在 GitHub 上,由 C++ 语言实现,拥有强大的定制化能力——通过其提供的 Filter 机制,Envoy 基本可以对请求转发过程中超过 50% 的流程做定制化。

本文主要分析 Envoy ratelimit filter 机制和 lyft/ratelimit 提供的 gRPC 服务。详见《微服务之服务治理:Envoy 全局 gRPC 限速服务 lyft/ratelimit 详解》。