Google在云计算领域的三驾马车是kubernetes, istio, knative，分别引领了云原生技术的发展方向, 基础设施能力底座、服务网格、serverless。
kubernetes
kubernetes是云原生技术的根本，虽然不使用kubernetes也可以做云原生技术落地，但kubernetes已经作为云原生技术的基础技术底座，它提供了底层基础设施(计算、网络、存储)的能力抽象，应用的编排部署能力，内置了微服务框架中的注册中心，配置中心等功能，提供了简单的流量治理功能等。
基础设施的能力抽象
kubernetes提供了基础设施的能力抽象，他更像是一个基础设施能力平台，内置的容器CRI, CNI, CSI等容器运行时，网络，存储的接入标准，第三方可以很方便的进行接入，很多优秀的网络组件服务，存储服务提供商都提供了能力接入。
应用的编排部署
kubernetes提供了各种资源类型的定义，包括deployment, statefulset, job，service等，还通过CRD提供了灵活的扩展能力。在传统的资产管理中，一般会有资产配置中心(CMDB)做统一资产的管控，而kubernetes内置了该功能，可以通过资源定义的一些注解以及label实现对资产的管理。不光是资产配置管理，在应用的运行时定义，运维能力等方面，kubernetes也集成了基础的能力。开发者还可以通过operator对在kubernetes集群运行的应用运维能力进行更多的扩展。
对于任务的管理，包括定时任务，单个触发的任务，kubernetes提供了job, cronjob的资源类型。这些能力也可以取代类似elastic-job这种调度中间件复用给上层应用做能力扩展。
在传统的配置中心领域，apollo是优秀的解决方案，它的核心功能是通过集成sdk的方式对配置的进行修改，下发，生效等管理，并且能统一管理不同的环境，不同集群的配置。但在云原生的解决方案中，kubernetes自带的配置中心(configmap)比它更合适。kubernetes提供的配置中心可以通过环境变量，配置文件等各种注入方式对应用进行配置下发，还可以通过请求配置中心接口或者监听配置中心变更实现配置的热加载。
在应用的编排部署层面，kubernetes作为技术底座，在技术越底层，要求其抽象能力越高，扩展能力越强。为了解决资源配置越来越多的运维成本，helm通过模板技术提供了应用打包以及版本管理的能力，helm在一定程度上缓解了资源管理的问题，可以在资源发布的时候打包所有资源，在升级的时候提供版本管理，但实际生效的还是同样多的资源配置，并未从日常问题调查，资源管理等方面根本上解决问题。OAM(以应用为中心)从应用角度对相关资源再进行抽象一层，慢慢在成为应用编排部署的标准。
OAM架构(图片取自OAM官网介绍)
服务治理
随着kubernetes成为基础设施技术底座，它提供的服务注册中心慢慢成为了微服务框架里面统一服务注册中心标准。越来越多的微服务框架支持了kubernetes服务注册中心，包括dubbo 3, spring cloud等。
kubernetes的ingress提供了一定流量转发，流量治理能力，默认官方的ingress-controller是nginx-controller。nginx是极其优秀的代理服务以及web server服务，据说nginx开发的初衷只是做web server，代理服务是其技术不断迭代更新的结果，渐渐的，nginx又回归到了web server服务。因为在云原生的领域中，代理是比较重要的组件，它有了更高的要求，除了需要具备高性能的代理功能之外，也需要多种策略的负载均衡，重试，熔断，降级，限流等更丰富的能力，动态变更的能力，多语言扩展能力，以及可观测性。在ingress 规则类型定义中，过于简单，实际应用场景需要更多的流量治理方式的支持，比如说rewrite, return, 基于请求的每个字段定义不同的行为，虽然nginx-controller通过注解可以定义更丰富的功能，甚至可以添加if语句，但使用体验不佳，注定要被新的网关服务取代，比如istio。
istio
istio是服务网格的解决方案。服务皆可网格，在每个服务前面加一层代理，可以在代理层面做比如重试，熔断，降级，限流等服务治理能力, 可以做协议转换，注册发现等功能，可以做安全，可观测性的能力提供。服务网格可以提供多语言服务之间调用的通用能力，可以把原来微服务框架的框架能力，比如负载均衡，流量治理等功能，沉淀为基础能力，解决了传统方式的痛点，服务网格成为了下一代微服务框架。而istio在逐渐成为服务网格的标准。
istio架构图(取自istio官网)
istio通过crd定义了很多资源类型，比如gateway, virtaulservice, destinationrule等，集成Kubernetes的服务发现等能力，通过管理数据面的代理(envoy), 以及集成云原生可观测性的解决方案，提供流量治理，安全，可观测性的能力。
流量治理
流量治理的能力主要是代理(envoy)提供的，envoy跟nginx一样，是高性能，低资源使用的代理服务，在架构以及性能方面两者相差无几，但envoy提供了协议(HTTP/2, GRPC)的透明转发，提供了动态的配置功能xDS，提供了强大的可观测性，更现代，更"云原生"，envoy已经逐渐成为云原生数据面代理的标准(虽然nginx也推出了nginx mesh功能, 前景不太乐观)。
在流量治理层面，协议也比较重要，国内使用dubbo以及其他私有rpc协议的也比较多，在RPC协议层面GRPC不一定是未来的标准，但其他私有协议会积极的接入envoy。
通过istio我们可以很方便对代理进行管理。
1）代理部署 根据业务类型可以定义不同的南/北流量走向和东/西流量走向的代理，代理即可以以单独的组件进行部署，承接集群南/北流量，也可以以sidecar的形式跟服务部署在一起，通过iptables进行透明的流量转发，承接服务间东/西流量。
2）配置管理 转换CRD资源的定义为代理所需的配置格式，集成代理的xDS功能，进行配置的下发，生效。
3）更新 代理的更新以及版本升级都是istio进行管理的。
4）功能扩展 根据所需功能对代理进行功能扩展，比如定义一些filter进行特定协议的处理以及规则的转发，引入WASAM，增强了代理可扩展能力等。
中间件和数据库是特殊的服务，在微服务框架中，这块能力的接入一般是通过SDK进行接入, 但这块能力是否能沉淀到sidecar层？对于业务应用来说，他不关心具体的缓存服务对应的是redis还是memcache，消息服务是Kafka还是rocketmq，只需要标准化接入方式，能接入就好了;但对于各种中间件&数据库，因为底层实现的差异，使用方式和通信协议各不相同。如果代理层能做一层协议转发，对应用层就完全透明了。Dapr(分布式应用运行时)正在尝试制定这块标准。
可观测性
在可观测性方面，不同的数据类型，指标，日志，链路数据对应着不同的解决方案，比如指标有prometheus, grafana;日志有ELK;链路监控有zipkin, jaeger等, 但在云原生的架构中，随着产生的数据量越来越大，单纯收集到各个数据类型的数据，再经过专业的人员进行数据分析已经满足不了日常的工作所需，需要对不同数据类型进行集中处理，计算，最终结果展示给所需人员。OpenTelemetry作为一个新兴的云原生解决方案，在定义这个领域的标准。
knative
knative是google开源的serverless架构方案，旨在提供一套简单易用的serverless方案，把serverless标准化。serverless通过架构的优化，实现资源的按需分配。knative基于istio提供的serving功能，可以做severless的解决方案，eventing功能提供了FaaS方案。但对于serverless方案，服务的冷启动时长是当前应用普及的难点之一，另外对于FaaS, 使用场景也是有限的。
knative架构图(取自knative官网)
微软开源的KEDA作为kubernetes HPA方案的补充能力，提供了多数据源的事件监听，逐渐成为kubernetes自动扩缩容的标准方案。
从目前来看，kubernetes已经成为根基，istio还在服务网格技术领域打造自己作为标准的地位，而knative因为使用场景问题，前景未知。
技术浪潮还在不断的迭代发展，后浪推前浪，一浪接一浪，旧的问题被解决，新的问题需要更多的人员持续优化。我们，是受益者，也希望能成为参与者。
