Kuma和Consul
Kuma
Kuma架构 — Cloud Atlas beta 文档 (cloud-atlas.readthedocs.io)
架构
2020年11月17日Kuma1.0 GA正式发布，这是一个可以再生产环境使用和部署的版本，可以运行在多个集群、云（包括Kubenetes和虚拟机上）；为应用程序创建先进的分别是服务网格
Kuma是CNCF孵化项目，开源与供应商无关
在Envoy作为数据控制台基础上，Kuma可以感知任何L4、L7流量，可以对流量进行监控、路由和增强任何服务或数据库之间的连接安全性。它可以再Kubernetes中通过CRDs或RestfulAPI使用，可以跨其他环境（如VM虚拟机和物理机）使用
Kong公司将自己定位成
Cloud Connectivity Company，也就是提供企业级服务网格，和Istio竞争企业市场。从 kuma官方网站 来看，Kuma作为 通用Envoy服务网格 ，其特点是易于使用，官方宣传简化部署屏蔽了service mesh的复杂性。(待验证)
不论是Cilium网络还是kuma，都是从不同方向殊途同归（Cilium从底层网络向上，kuma从上层7L应用代理向下）最终都采用了笑死的开源软件堆栈，加上自己的优化和开发，打包成全面的Service Mesh解决方案
概览
kuma是一个平台无关（platform agnostic）开源服务网格控制平面（control plane for service mesh）和微服务管理（microservice management）支持Kubernetes，VM以及裸金属环境。
作为单体架构(monolithic architectures)向微服务(microservices)转变的一部分，Kuma帮助实现了分布式部署的服务网格(service mesh):
- 通用和Kubernetes-native : 与平台无关(Platform-agnostic)，可以在任何地方运行和操作
- 单机和多可用区：支持多云、多地域、多kubernetes急群，具备原生DNS服务发现和Ingress能力。
- 多网格：通过一个控制平面支持多个单独的网格，降低支持整个技术组织的运营成本。
- 基于属性的策略：允许使用任意标签选择器(any arbitrary tag selector)作为源和目标应用细粒度的服务和流量策略
- 基于Envoy：由Envoy sidecar代理提供支持，不会暴露Envoy本身的复杂性
- 水平可扩展
- 企业可用：支持需要正常运行时间和稳定性的关键企业用例。
将Envoy负载均衡、反向代理绑定为数据平面，kuma可以检测任何l4/L7流量，以保护、观察、路由和增强任何服务或数据库之间的连接。Kuma可以通过CRD在Kubernetes中本地使用，也可以通过其他环境的RestfulApi使用
通过Kuma概览可以看到
Consul
Consul是HashiCorp，Consul由Go语言开发，部署起来非常容易，只需要极少的可执行程序和配置文件，具有绿色、轻量级等特点。Consul是分布式的、高可用的、可横向扩展的英语实现分布式系统的服务发现与配置。
特点
- 服务发现（Service Discovery）：
Consul提供了通过DNS或者HTTP接口的方式来注册服务和发现服务。一些外部的服务通过Consul很容易的找到它所依赖的服务。 - 健康检查（Health Checking）：Consul的Client可以提供任意数量的健康检查，既可以与给定的服务相关联(“webserver是否返回200 OK”)，也可以与本地节点相关联(“内存利用率是否低于90%”)。操作员可以使用这些信息来监视集群的健康状况，服务发现组件可以使用这些信息将流量从不健康的主机路由出去。
- Key/Value存储：应用程序可以根据自己的需要使用Consul提供的Key/Value存储。 Consul提供了简单易用的HTTP接口，结合其他工具可以实现动态配置、功能标记、领袖选举等等功能。
- 安全服务通信：Consul可以为服务生成和分发TLS证书，以建立相互的TLS连接。意图可用于定义允许哪些服务通信。服务分割可以很容易地进行管理，其目的是可以实时更改的，而不是使用复杂的网络拓扑和静态防火墙规则。
- 多数据中心：Consul支持开箱即用的多数据中心. 这意味着用户不需要担心需要建立额外的抽象层让业务扩展到多个区域。
让我们把这幅图分解描述。首先，我们可以看到有两个数据中心，分别标记为“1”和“2”。Consul拥有对多个数据中心的一流支持，这是比较常见的情况。
在每个数据中心中，我们都有客户机和服务器。预计将有三到五台服务器。这在故障情况下的可用性和性能之间取得了平衡，因为随着添加更多的机器，一致性会逐渐变慢。但是，客户端的数量没有限制，可以很容易地扩展到数千或数万。
Consul 实现多个数据中心都依赖于gossip protocol协议。这样做有几个目的:首先，不需要使用服务器的地址来配置客户端;服务发现是自动完成的。其次，健康检查故障的工作不是放在服务器上，而是分布式的。这使得故障检测比单纯的心跳模式更具可伸缩性。为节点提供故障检测;如果无法访问代理，则节点可能经历了故障。
每个数据中心中的服务器都是一个筏对等集的一部分。这意味着它们一起工作来选举单个leader，一个被选中的服务器有额外的职责。领导负责处理所有的查询和事务。事务还必须作为协商一致协议的一部分复制到所有对等方。由于这个需求，当非leader服务器接收到RPC请求时，它会将其转发给集群leader。
Consul的使用场景
Consul的应用场景包括服务发现、服务隔离、服务配置：
- 服务发现场景中consul作为注册中心，服务地址被注册到consul中以后，可以使用consul提供的dns、http接口查询，consul支持health check。
- 服务隔离场景中consul支持以服务为单位设置访问策略，能同时支持经典的平台和新兴的平台，支持tls证书分发，service-to-service加密。
- 服务配置场景中consul提供key-value数据存储功能，并且能将变动迅速地通知出去，借助Consul可以实现配置共享，需要读取配置的服务可以从Consul中读取到准确的配置信息。
- Consul可以帮助系统管理者更清晰的了解复杂系统内部的系统架构，运维人员可以将Consul看成一种监控软件，也可以看成一种资产（资源）管理系统。
比如：docker实例的注册与配置共享、coreos实例的注册与配置共享、vitess集群、SaaS应用的配置共享、Consul与confd服务集成，动态生成nginx和haproxy配置文件或者Consul结合nginx构建高可用可扩展的Web服务。
Consul 使用了两个不同的 gossip pool，分别叫做 LAN 和 WAN，这是因为 Consul 原生支持多数据中心。在一个数据中心内部，LAN gossip pool 包含了这个数据中心所有的节点，包括 proxy 和 servers。WAN pool 是全局唯一的，所有数据中心的 servers 都在这个 pool 中。这两个 pool 的区别就是 LAN 处理的是数据中心内部的失败检测，事件广播等等，而 WAN 关心的是跨数据中心的。除了 gossip 协议之外，Consul 还使用了 Raft 协议来进行 leader election，选出 leader 之后复制日志的过程和 Etcd 基本一致。