4 Istio与Kubernetes
4.1 Kubernetes介绍
Kubernetes是一款用于管理容器化工作的负载和服务的可移植、可扩展的开源平台,拥有庞大、快速发展的生态系统,它面向基础设施,将计算、网络、存储等资源进行紧密整合,为容器提供最佳运行环境,并面向应用提供封装好的、易用的工作负载与服务编排接口,以及运维所需的资源规格、弹性、运行参数、调度等配置管理接口,是新一代的云原生基础设施平台。
从平台架构而言,Kubernetes的设计围绕平台化理念,强调插件化设计与易扩展性,这是它与其他同类系统的最大区别之一,保障了对各种不同客户应用场景的普遍适应性。另外,Kubernetes与其他容器编排系统的显著区别是Kubernetes并不把无状态化、微服务化等条件作为可运行的工作负载的约束。如今,容器技术已经进入产业落地期,而Kubernetes作为容器平台的标准已经得到了广泛应用。
4.2 Istio是Kubernetes的好帮手
从场景来看,Kubernetes已经提供了非常强大的应用负载的部署、升级、扩容等运行管理能力。Kubernetes 中的 Service 机制也已经可以做服务注册、服务发现和负载均衡,支持通过服务名访问到服务实例。 从微服务的工具集观点来看,Kubernetes本身是支持微服务的架构,在Pod中部署微服务很合适,也已经解决了微服务的互访互通问题,但对服务间访问的管理如服务的熔断、限流、动态路由、调用链追踪等都不在Kubernetes的能力范围内。那么,如何提供一套从底层的负载部署运行到上层的服务访问治理端到端的解决方案? 目前,最完美的答案就是在Kubernetes上叠加Istio这个好帮手
4.3 Kubernetes是Istio的好基座
Istio最大化地利用了Kubernetes这个基础设施,与之叠加在一起形成了一个更强大的用于进行服务运行和治理的基础设施,充分利用了Kubernetes的优点实现Istio的功能,例如:
1.数据面
数据面Sidecar运行在Kubernetes的Pod里,作为一个Proxy和业务容器部署在一起。在服务网格的定义中要求应用程序在运行的时感知不到Sidecar的存在。而基于Kubernetes的一个 Pod 多个容器的优秀设计使得部署运维 对用户透明,用户甚至感知不到部署 Sidecar的过程。用户还是用原有的方式创建负载,通过 Istio 的自动注入服务,可以自动给指定的负载注入Proxy。如果在另一种环境下部署和使用Proxy,则不会有这样的便利。
2.统一服务发现
Istio的服务发现机制非常完美地基于Kubernetes的域名访问机制构建而成,省去了再搭一个类似 Eureka 的注册中心的麻烦,更避免了在 Kubernetes 上运行时服务发现数据不一致的问题。
3.基于Kubernetes CRD描述规则
Istio的所有路由规则和控制策略都是通过 Kubernetes CRD实现的,因此各种规则策略对应的数据也被存储在 Kube-apiserver 中,不需要另外一个单独的 APIServer 和后端的配置管理。所以,可以说Istio的APIServer就是Kubernetes的APIServer,数据也自然地被存在了对应Kubernetes的etcd中。
Istio非常巧妙地应用了Kubernetes这个好基座,基于Kubernetes的已有能力来构建自身功能。Kubernetes里已经有的,绝不再自己搞一套,避免了数据不一致和用户使用体验的问题。
Istio和Kubernetes架构的关系,可以看出,Istio不仅数据面Envoy跑在Kubernetes的Pod里,其控制面也运行在Kubernetes集群中,其控制面组件本身存在的形式也是以Kubernetes Deployment和Service,基于Kubernetes扩展和构建。
回顾一下上面提到的K8S组件
APIServer
API Server提供了k8s各类资源对象(pod,RC,Service等)的增删改查及watch等HTTP Rest接口,是整个系统的数据总线和数据中心。 kubernetes API Server的功能: -提供了集群管理的REST API接口(包括认证授权、数据校验以及集群状态变更); -提供其他模块之间的数据交互和通信的枢纽(其他模块通过API Server查询或修改数据,只有API Server才直接操作etcd); -是资源配额控制的入口; -拥有完备的集群安全机制.
- Deployment
一旦运行了 Kubernetes 集群,就可以在其上部署容器化应用程序。 为此,需要创建 Kubernetes Deployment 配置。 Deployment 负责 Kubernetes 如何创建和更新应用程序的实例。
- Service
Service可以看作是一组提供相同服务的Pod对外的访问接口。借助Service,应用可以方便地实现服务发现和负载均衡
- Ingress
ingress是Kubernetes资源的一种,可以让外部请求访问到k8s内部的资源上
总结
Kubernetes在容器编排领域已经成为无可争辩的事实标准;微服务化的服务与容器在轻量、敏捷、快速部署运维等特征上匹配,这类服务在容器中的运行也正日益流行;随着Istio 的成熟和服务网格技术的流行,使用 Istio 进行服务治理的实践也越来越多,正成为服务治理的趋势;而 Istio 与 Kubernetes 的天然融合且基于 Kubernetes 构建,也补齐了Kubernetes的治理能力,提供了端到端的服务运行治理平台。这都使得Istio、微服务、容器及Kubernetes形成一个完美的闭环。 云原生应用采用 Kubernetes 构建应用编排能力,采用 Istio 构建服务治理能力,将逐渐成为企业技术转型的标准配置。
5 Istio与服务网格
5.1 时代选择服务网格
在云原生时代,随着采用各种语言开发的服务剧增,应用间的访问拓扑更加复杂,治理需求也越来越多。原来的那种嵌入在应用中的治理功能无论是从形态、动态性还是可扩展性来说都不能满足需求,迫切需要一种具备云原生动态、弹性特点的应用治理基础设施。
采用Sidecar代理与应用进程的解耦带来的是应用完全无侵入、也屏蔽了开发语言无关等特点解除了开发语言的约束,从而极大降低了应用开发者的开发成本。
这种方式也经常被称为一种应用的基础设施层,类比TCP/IP网络协议栈,应用程序像使用TCP/IP一样使用这个通用代理:TCP/IP 负责将字节码可靠地在网络节点之间传递,Sidecar 则负责将请求可靠地在服务间进行传递。TCP/IP 面向的是底层的数据流,Sidecar 则可以支持多种高级协议(HTTP、gRPC、HTTPS 等),以及对服务运行时进行高级控制,使服务变得可监控、可管理。
然后,从全局来看,在多个服务间有复杂的互相访问时才有服务治理的需求。即我们关注的是这些 Sidecar 组成的网格,对网格内的服务间访问进行管理,应用还是按照本来的方式进行互相访问,每个应用程序的入口流量和出口流量都要经过Sidecar代理,并在Sidecar上执行治理动作。
最后,Sidecar是网格动作的执行体,全局的管理规则和网格内的元数据维护需要通过一个统一的控制面实现。
Sidecar拦截入口流量,执行治理动作。这就引入两个问题:
◎ 增加了两处延迟和可能的故障点;
◎ 多出来的这两跳对于访问性能、整体可靠性及整个系统的复杂度都带来了新的挑战。
所以,对于考虑使用服务网格的用户来说,事情就会变成一个更简单的选择题:是否愿意花费额外的资源在这些基础设施上来换取开发、运维的灵活性、业务的非侵入性和扩展性等便利。
目前,华为、谷歌、亚马逊等云服务厂商将这种服务以云服务形态提供了出来,并和底层的基础设施相结合,提供了完整的服务治理解决方案。这对于广大应用开发者来说,更加方便和友好。
5.2 服务网格选择Istio
在多种服务网格项目和产品中,最引人注目的是后来居上的 Istio,它有希望成为继Kubernetes之后的又一款
重量级产品。
Istio 解决了生产大规模集群的性能、资源利用率和可靠性问题,提供了众多生产中实际应用的新特性,已经达到企业级可用的标准。
首先,在控制面上,Istio作为一种全新的设计,在功能、形态、架构和扩展性上提供了远超服务网格的能力范围。它提供了一套标准的控制面规范,向数据面传递服务信息和治理规则。
Istio使用Envoy V2版本的API,即gRPC协议。标准的控制面API解耦了控制面和数据面的绑定。
最后,在大厂的支持上,Istio 由谷歌和 IBM 共同推出,从应用场景的分析规划到本身的定位,从自身架构的设计到与周边生态的结合,都有着比较严密的论证。Istio项目在发起时已经确认了将云原生生态系统中的容器作为核心,将Kubernetes作为管理容器的编排系统,需要一个系统管理在容器平台上运行的服务之间的交互,包括控制访问、安全、运行数据收集等,而 Istio 正是为此而生的;另外,Istio 成为架构的默认部分,就像容器和Kubernetes已经成为云原生架构的默认部分一样。
云原生社区的定位与多个云厂商的规划也不谋而合。华为云已经在 2018 年 8 月率先在其容器服务CCE(Cloud Container Engine)中内置Istio;Google的GKE也在2018年12月宣布内置 Istio;越来越多的云厂商也已经选择将 Istio作为其容器平台的一部分提供给用户,即提供一套开箱即用的容器应用运行治理的全栈服务。正因为看到了 Istio 在技术和产品上的巨大潜力,各大厂商在社区的投入也在不断加大,其中包括Google、IBM、华为、思科、红帽等主流厂商。istio原理图
总结
时代选择服务网格是因为架构的发展 服务网格选择istio是因为提供一套开箱即用的容器应用运行治理的全栈服务