开发者看KubeCon消失的Kubernetes

Posted 2021-04-16 K8S技术社区

全球含金量容器认证CKA培训北京站文末招生啦！

KubeCon+CloudNativeCon北美峰会已进入第二天，CNCF Meetup Partner K8S技术社区联合Kubernetes认证服务提供商EasyStack技术代表团继续为大家送上现场技术解析：

走进KubeCon+CloudNativeCon 2018西雅图峰会，最大的变化是，技术 session很少有纯 Kubernetes 自身代码和原理解析等话题，印证了 Kubernetes 本身已经稳定并广泛应用，社区、用户、厂商的关注点更多转向了 Kubernetes 平台周围的庞大开源生态。也许峰会名称以后可以简化，只叫CloudNativeCon了。聚焦关键技术session，为大家带来以下技术信息和总结，欢迎拍砖！

 

etcd 加入 CNCF，分布式系统基石从幕后走向台前

如果 Kubernetes 是用来支撑分布式系统的分布式系统，那作为 Kubernetes 集群元数据存储池的分布式键值数据库etcd，便是分布式系统的基石。再往细看，我们知道etcd 的强大核心主要由如下4个特性来驱动：

1、raft 分布式一致性算法

相对于 paxos 等其它分布式一致算法，raft语义更简洁易懂和实现更简单，逐渐被越来越多的分布式系统采用。etcd 在创立之初就推出了一套基于 Go 语言的 raft 实现etcd/raft，形成了 raft 标准库，一方面是 etcd 自身的核心库，一方面也被很多其它的分布式软件采用，如 TiKV、Dgraph、Cockroach DB、Hyperledger等。raft 保证了 etcd 集群的多节点数据强一致性和容错性。

2、MVCC（Multi-Verison Concurrency Control，多版本并发控制）

MVCC 是数据库系统常用的一种并发控制机制，解决读写阻塞问题和进行事务控制，核心思想是，当写入数据时，不更新旧数据，而是新创建一个新版本的对象来存储新数据；同时读操作不会阻塞写操作，因为可以读取旧版本的数据，等写入成功的下次读取，会切换到新版本上。MVCC 机制让 etcd 的多版本修改历史和 watch 机制得以实现。

3、bbolt(BoltDB)单机键值数据库

etcd 从v3版本开始使用 BoltDB 来持久化存储多版本 key，作为单节点的数据存储 db。

4、gRPC 接口API

etcd最开始使用 JOSN+HTTP对外提供 REST 接口，为了提升服务性能，后续切换到默认用gRPC+http/2提供接口。这是 etcd 集群高性能的保证因素之一。

 

强大的核心和广泛的应用，让 etcd 的运维实践变得有迹可循。有过etcd 生产环境运维经验的同事都会体验到，etcd 集群的稳定和高性能，是整个 Kubernetes 集群稳定高效的基础，我们可以充分利用已有的最佳使用实践应用到自己的环境中，比如使用 etcd-operator 来进行集群生命周期管理；合理分配系统 IO 和网络带宽保证集群性能、合理利用Prometheus 进行集群监控状态监控、定期备份数据等等。

随着云原生应用和 Kubernetes的兴起，etcd  也逐步进入更多企业的视野，凭借稳定可靠高性能，几乎所有云平台厂商都有基于 etcd 的产品或在内部系统中使用etcd。随着加入 CNCF 基金会，可以预料的是，不仅仅是支撑 Kubernetes 等底层分布式系统，etcd 也将会出现在更多、更贴近上层应用的更广泛使用场景中。

 

CRD 和 Custom Controller 无处不在，可扩展性极致展现

    

CRD(Custom Resource Definition)是 Kubernetes 可扩展性的最典型特性，允许用户在 Kubernetes 已有 API 和资源的基础上，不改动 Kubernetes 一行代码，把新的 API 和自定义资源以 Kubernetes-Style 的方式加入到集群中，用户可使用同一套 API 入口、同一套命令行工具 kubectl 来管理系统内置资源和自定义资源（CR）。类似于 Kubernetes 内置的 controller manager 用来管理 Pod/Service等资源，自定义控制器(custom controller) 是用来维护自定义资源创建删除逻辑、数据结构存储和解析等等完整生命周期。Operator 框架正是这这两种特性的结合，让开发者可以把特定应用的领域知识和运维经验，转换为 Kubernetes 里的一类新的自定义资源 API 和新的扩展能力。

 这种非常方便把不同的应用领域知识，通过扩展转换为 Kubernetes 语义和资源的能力，既不对原有功能带来任何侵入，又能极大扩展 Kubernetes 的应用领域，是其能成为分布式系统事实标准的主要原因之一。当前社区在对 CRD 的完善上，主要集中在以下几点：

1、支持 CR Versioning版本管理，也就是类似内置的Deployment 等等资源有不同版本，为了区别资源的成熟程度，也加入了对自定义资源的版本支持。

2、支持 CR Conversion可进化，也就是支持自定义资源向更高版本进化。可进化能力是应用领域知识和运维经验能持续回馈到 Kubernetes 生态不可缺少的能力。

3、支持 quota 以及更完善的资源格式校验等。

在已有代码库和工具集上，sample-controller(https://github.com/kubernetes/sample-controller)可作为创建 custom controller 的模板；更进一步，kubebuilder(https://github.com/kubernetes-sigs/kubebuilder)可自动生成创建一套 CRD 的代码框架；operator-sdk(https://github.com/operator-framework/operator-sdk)提供自动创建 Operator 的代码框架。

 

在应用领域方面，有众多软件系统和管理工具利用 CRD+Custom Controller 机制来扩展 Kubernetes，可参考的有：

1、众多分布式应用特别是有状态应用，正在通过 Operator 框架集成到 Kubernetes 生态，如 Rook、etcd、mysql、Redis 等等。因为有状态应用的最佳使用和运维管理，需要经验的积累，正是 Operator 让这些经验得以大规模复制。

2、Cluster API，是使用 Kubernetes-Style API 来创建、配置和管理 Kubernetes 集群的项目，目的就是通过自定义资源 cluster，然后通过对 cluster 的声明式 API 调用，就能创建和管理集群。目前国内外主流公有云厂商，以及 OpenStack，都在实现对 Cluster API 的支持。

3、各不同厂商根据产品需要，创建 CRD 满足各种需求：如使用 CRD 来管理 External LoadBalancer等等任何类型的集群外资源。

 

Envoy突破重围，加速进入生产实践

 

Envoy 在本次KubeCon 可谓出尽风头。keynotes 开篇主持人便祝贺 Envoy 成为 CNCF 基金会继 Kubernetes 和 Prometheus 后，第三个正式毕业的项目，引来8000人会场一片掌声。其后的 keynotes 环节除了 Envoy Update外，Google，AWS，Cisco，vmWare等公司又分别在各自的 keynote 中提及 Envoy，成为全场被提及最多次的 CNCF 项目。

Envoy 是以 sidecar 形式运行的高性能代理程序，实现动态服务发现、负载均衡和并发管理等功能，它与一般智能代理区别在于它是以“网格”配置部署。Lyft作为 Envoy 的发起者，它们的生产系统深度依赖 Envoy。

在Lyft的生产系统中每项服务都通过 Envoy 代理程序去负载均衡和统计管理等。Envoy 的数据平面由 Front Envoy和后端大量Envoy网格组成，而 Envoy Manager 作为整个生产系统的控制平面，它记录了当前系统的状态和期望的配置，会不断协调整个网格系统。 Front Envoy在整个系统边缘运行（来自外部的所有请求都会发送到Front Envoy），它将起到负载均衡并决定转发路径的作用；整个系统的后台运行大量的服务实例，并且每个服务实例运行时都伴生一个 Envoy（会记录服务的运行状态），最终形成一个网格，并在网格间彼此共享路由信息。

Envoy 还会记录对每个服务的请求数据，为了增加可观察性，网络团队提供了不同的可视化，服务所有者可以观察到系统的状态，并追踪服务的运行状态和流量情况来配置例如并发限制这样的参数。可观察性对 Envoy 来说是设计理念的完整体现，Envoy 认为网络对于应用应该是透明的，当网络和应用程序出现问题时，应该很容易确定问题的根源。

• 
  

作为CNCF中国区Meetup Partner和国内云原生技术布道组织，K8S技术社区将持续带来北美峰会现场播报，进群秒得现场一手资讯和看点！

添加小助手，参与KubeCon直播互动（投票、话题讨论、峰会点评、社区投稿等）还可获赠CKA认证培训85折优惠券哦！