Kuma与istio

kuma

什么是kuma？官方给出的解释 Amodern distributed Control Plane with a bundled Envoy Proxy intergration（一个域Envoy代理组件捆包在一起的现代化分别是控制平面）

觉得来说Kuma就是基于Envoy作为数据平面的控制平面组件。

可能很多人没听说过kuma，kuma是Kong组织实现的Service Mesh控制平面，数据面使用的是Envoy，和Istio类似。

（那么有人问了Kong又是哪个，Kong组织最出名的项目基于Openresty开发的API网关Kong）

Kuma架构图

Kuma加入CNCF黑盒

在前几天，Kuma已经加入了CNCF，因为控制面板采用了CNCF家族已经毕业的Envoy，所以其可用性和未来应该还是挺不错的。

　　从架构上来讲，Kuma非常的简单，而Istio非常的复杂，组件繁多，流程复杂。安装部署、维护也是老大难的问题。而Istio自己也发现了这个问题，从今年年初发版的1.5版本开始逐步的减少组件、简化流程，一切为了实际生产。

1.5以前的架构

1.5以后的架构

istio

Istio 相关组件介绍istio-citadel、istio-pilot、istio-galley、istio-policy..._istio policy-CSDN博客

istio是什么

• Istio 是 用于服务治理 的开放平台
• Istio 是 Service Mash形态 的用于服务治理的开放平台
• Istio 是一个与 Kubernetes紧密结合 的 适用于云原生场景的 Service Mash 形态的 用于服务治理的开放平台。这里的治理 不局限于微服务治理，任何服务，
• 要服务间有访问，如果需要对服务间的访问进行管理，就可以使用Istio。根据Isio官方介绍，服务治理及连接（connect）、安全（secret）、策略执行（control）和可观察性（observe）。
• 连接：Istio 通过集中配置的流量规则控制服务间的流量和调用，实现负载均衡、熔断、故障注入、重试、定向等服务治理功能。
• 安全：Istio 通过透明的认证机制、通道加密、服务访问权限等安全能力，可增强服务访问的安全性。
• 策略执行：Istio 通过可动态插拔、可扩展的策略实现访问控制、速率限制、额配管理、服务计费等能力。
• 可观察性：动态获取服务运行数据和输出，提供强大的调用链、监控和调用日志收集输出的能力。配合可视化工具，可方便运维人员了解服务的运行状态，发现并解决问题。

istio提供的主要能力

服务运行可观察性：监控应用及网络相关数据，将相关指标与日志记录发生至任意收集、聚合与查询系统中意实现功能扩展，追踪分析性能热点并对分布式故障模式进行诊断。
弹性效率：提供了统一的方法配置重试、负载均衡、流量控制和断路器等来解决网络可靠性低所造成的各类常见故障，更轻松地运维高弹性服务网格。
研发人员生产力：确保研发人员专注于基于已选择的编程语言构建业务能力，不用在代码中处理分布式系统问题，从而极大地提升生产能力。
策略驱动型运营：解耦开放和运维团队的工作，在无须更改代码的前提下提升安全性、监控能力、扩展性与服务拓扑水平。运营人员能够不依赖开发提供的能力精确控制生产水平。
默认安全：允许运维人员配置TLS双向认证，并保护各服务之间的所有通信，并且开发人员与运维人员不用维护证书，以应对分布式计算中经常存在的大量网络安全问题。
增量适用：考虑到在网络内运行的各类服务的透明性，允许团队按照自己的节奏和需求逐步使用各项功能，例如先观察服务运行情况再进行服务治理等。

istio做了什么

首先来看下Istio在服务访问过程中做了什么。一个简单的Client访问Server，对两者使用开发语言没有任何要求，可以是Client采用node.js编写，server采用java编写。在Client中访问服务server，在两个程序中不用包含任何服务访问管理的逻辑。

来看看Istio在其中做了什么：

• 自动通过服务发现获取server服务实例的列表，并根据负载均衡策略选择一个服务实例。
• 对服务双方启用双向认证和通道加密。
• 如果某个服务实例连续访问出错，则可以自动将该实例隔离一段时间，以提高访问质量。
• 设置最大连接数、最大请求数、访问超时等对服务进行保护。
• 限流。
• 对请求进行重试。
• 修改请求中的内容。
• 将一定特征的服务重定向。
• 灰度发布
• 自动记录服务访问信息。
• 记录调用链，进行分布式追踪。
• 根据访问数据形成完整的应用访问拓扑。

所有这些功能，都不用用户修改代码，用户只需要在Istio 的控制面做些配置即可，并且动态生效。以灰度测试为例，在Istio中通过简单配置实现灰度发布，核心是实现两个版本同时在线，并通过一定的流量策略将部分流量引流到新版本上。无须改动代码，只需要简单的一个配置即可：

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: server
spec:
  hoste:
  - server
  http:
  - match:
    - headers:
      cookie:
        exact: "group=dev"
    route:
    - destination:
      name: v2
  - route:
    - destination:
      name: va    

将group为dev的流量转发到server的v2版本，其他用户访问的还是v1，从而实现灰度发布。整个过程中除了Istio配置需要修改，其他不需要做任何事情。

组件介绍

在集群中通过“kubectl get svc -n istio-system” 获取isto 的各组件

NAME                     TYPE           CLUSTER-IP       EXTERNAL-IP   PORT(S)                                                                                                                      AGE
grafana                  ClusterIP      10.109.18.105    <none>        3000/TCP                                                                                                                     46h
istio-citadel            ClusterIP      10.97.247.24     <none>        8060/TCP,15014/TCP                                                                                                           46h
istio-egressgateway      ClusterIP      10.106.34.148    <none>        80/TCP,443/TCP,15443/TCP                                                                                                     46h
istio-galley             ClusterIP      10.103.74.254    <none>        443/TCP,15014/TCP,9901/TCP,15019/TCP                                                                                         46h
istio-ingressgateway     LoadBalancer   10.99.94.178     localhost     15020:30397/TCP,80:32621/TCP,443:32749/TCP,15029:31666/TCP,15030:32662/TCP,15031:30400/TCP,15032:32139/TCP,15443:32435/TCP   46h
istio-pilot              ClusterIP      10.98.146.59     <none>        15010/TCP,15011/TCP,8080/TCP,15014/TCP                                                                                       46h
istio-policy             ClusterIP      10.109.93.7      <none>        9091/TCP,15004/TCP,15014/TCP                                                                                                 46h
istio-sidecar-injector   ClusterIP      10.100.143.27    <none>        443/TCP                                                                                                                      46h
istio-telemetry          ClusterIP      10.110.99.43     <none>        9091/TCP,15004/TCP,15014/TCP,42422/TCP                                                                                       46h
jaeger-agent             ClusterIP      None             <none>        5775/UDP,6831/UDP,6832/UDP                                                                                                   46h
jaeger-collector         ClusterIP      10.108.7.167     <none>        14267/TCP,14268/TCP,14250/TCP                                                                                                46h
jaeger-query             ClusterIP      10.107.85.181    <none>        16686/TCP                                                                                                                    46h
kiali                    ClusterIP      10.103.150.239   <none>        20001/TCP                                                                                                                    46h
prometheus               ClusterIP      10.110.122.226   <none>        9090/TCP                                                                                                                     46h
tracing                  ClusterIP      10.105.32.84     <none>        80/TCP                                                                                                                       46h
zipkin                   ClusterIP      10.107.56.80     <none>        9411/TCP                                                                                                                     46h

istio-pilot

pilot是Istio的控制中心，下发控制指令完成作业。Pilot中间从平台提取数据并将构建和转换成Istio的服务发现模型。因此Pilot只有服务发现功能，而无服务注册功能。这种抽象框架解耦了Pilot和底层平台的不同实现，可以支持kubernetes、Consul等平台。

除了服务发现，Pilot更重要的一个功能是向数据面下发规则，包括VirtualService、DestinationRule、Gateway、ServiceEntry等流量治理规则，也包括认证授权等安全机制。Pilot负责将各种规则转换成Envoy可识别的格式，通过标准的xDS协议发送给Envoy，指导Envoy完成动作。在通信上Envoy通过gRPC流式订阅Pilot的配置资源。例如Pilot将VirtualService表达的路由规则分发到Envoy上，Envoy将根据该路由规则进行流量转发。

telemetry

telemetry是专门用于收集遥测数据的Mixer服务组件，如服务列表所示，在部署上，Istio 控制面部署了两个Mixer组件：telemetry和policy，分别处理遥测数据的收集和策略的执行。查看两个组件的Pod镜像会发现，容器的镜像是一样的，都是“/istio/mixer”。
Mixer 是Istio独有的一种设计，不同于Pilot，在其他平台上总能找到类似功能的服务组件。从调用时机来说，Pilot管理的是配置数据，在配置改变时和数据面交互即可；然而，对于Mixer来说，在服务间交互时Envoy都会对Mixer进行一次调用，因此这是一种实时管理。当然，通过在Mixer和Proxy上使用缓存机制，可保证不用每次进行数据请求时都和Mixer交互。

当网络中的两个服务间有交互发生时，服务的代理Envoy就会上报遥测数据给telemetry 服务组件。telemetry服务组件根据配置将生成访问Mixer等数据分发给后端的遥测服务。数据面代理通过report 接口上报数据时访问数据会被批量上报。

在架构上，Mixer 作为中介来解耦数据面和不同后端的对接，以提供灵活性和扩展能力。运维人员可以动态配置各种遥测后端，来收集指定的服务运行数据。

policy

policy 时另外一个Mixer服务，和telemetry基本上是完全相同的机制和流程。数据面在转发服务的请求前，调用policy的Check接口检查是否允许访问。Mixer根据配置将请求转发到对应的Adapter做对应检查，给代理返回允许访问还是拒绝。可以对接如 配额、授权、黑白名单等不同的控制后端，对服务间的访问进行可扩展的控制。

citadel

citadel是Istio的核心安全组件，提供了自动生成、分发、轮换与撤销密钥和证书功能。Citaldel一直监听kube-apiserver。以secret的形式对每个服务都生成密钥，并在Pod创建时挂载到Pod上，代理容器使用这些文件来做身份认证，进而替代俩端服务的双向TLS认证、通道加密、访问授权等问题功能，这样用户就不用再代码里维护证书密钥了。俩个服务之间采用HTTP通信，通过配置即可对服务增加认证功能，双方的Envoy会建立双向认证的TLS通道，从而在服务间启动双向认证的HTTPS。

galley

galley并不直接向数据面提供业务能力，而是在控制面上向其他组件提供支持。galley作为负责配置管理的组件，验证配置信息的格式和内容的正确性，并将这些配置信息提供给管理面的Pilot和Mixer服务使用，这样其他的管理组件只用和galley打交道，从而与底层平台解耦。在新的版本中galley的作用越来越重要。

Sidecar-injector

sidecar-injector 是负责自动自动注入的组件，只要开启自动注入，在Pod创建时就会自动调用istio-sidecar-injector 向Pod中注入Sidecar 容器。
在kubernetes环境中，根据自动注入配置，Kube-apiserver 在拦截到Pod创建的请求时，会调用自动注入服务istio-sidecar-injector 生成Sidecar容器描述并将其插入原Pod的定义中，这样，在创建的Pod内除了包括业务容器，还包括Sidecar容器。这个注入过程对用户透明，用户使用原始的方式创建工作负载。

IStio proxy

在很多和Istio相关的地方，会将Envoy、Sidecar、Proxy等术语有时是混着用的，都表示Istio数据面的轻量代理。但关注Pod详细信息，会发现这个容器的正式名称是istio-proxy，不是通用的Envoy镜像，而是叠加了Istio的Proxy功能的一个扩展版本。另外，在istio-proxy容器中除了有Envoy外还有一个Pilot-agent的守护进程。未来如果能在istio-proxy 中提供Mixer的部分能力，将会是一个非常紧凑的设计。

Envoy是用C++开发的非常有影响力的轻量级高性能开源服务代理。作为服务网格的数据面，Envoy提供了动态服务发现、负载均衡、TLS、HTTP/2及gRPC代理、熔断器、健康检查、流量拆分、灰度发布、故障注入等功能，istio描述的大部分自治能力最终都落实到Envoy的实现上。

在Istio中，规则被描述的对象都是被访问者，但是真正的规则执行位置，对于不同的类型的动作可能不同，可能在被访问服务的Sidecar拦截到Inbound流量时，或是在访问者的Sidecar拦截到outbound流量时执行，一般后者居多。当给一个服务定义流量规则时，所有访问该服务的Sidecar都收到规则，并且执行相同的治理逻辑，从而对目标服务执行一致的治理。下面列出常用的服务治理规则和其执行位置。

Ingress getway

ingressgateway 就是入口处的Gateway，从网络外访问网格内的服务就是通过这个Gateway进行的。ingressgateway比较特别的是，是一个LoadBalance类型的Service，不同于其他服务组件只有一两个端口，ingressgateway开发了一组端口，这些就是网格内服务的外部访问端口。网格入口网关ingressgateway的负载和网格内的Sidecar是同样的执行体，也和网格内的其他Sidecar一样从Pilot接收流量规则并执行。因为入口处的流量都走这个服务，会有较大的并发可能出现流量峰值，所有需要评估流量来规划和实例数。Istio通过一个特有的资源对象Gateway来配置和对外的协议、端口等。

其他组件

除了以“Istio” 为前缀的以上几个Istio自有组件，在集群中一般还安装了jaeger-agent、jaeger-collector、jaeger-query、Kiail、Prometheus、Tracing、ZIPkin组件，这些组件提供了Istio调用链、监控等功能，可以选择安装来完成完整的服务监控管理功能。