微服务学习笔记 K8S、ISTIO、微服务、容器不得不说的故事

微服务运行在容器内；容器依靠K8S进行编排、服务发现、负载均衡等；Istio和K8S进行融合，在利用K8S的一些功能的基础上（服务注册），对K8S进行功能的扩展，追加了一些服务治理功能（熔断、限流、动态路由、调用链追踪）。

微服务与容器

为了微服务的快速部署和迭代，如今的微服务架构中，通常将微服务部署在容器内。使用容器的好处

K8S

K8S是一个基于容器技术的分布式架构方案。利用K8S，我们可以很好的对容器进行管理。

其架构如下：

K8S的最基础单位是Pod，一个Pod下可以支持许多容器，Pod中的容器共享网络地址和文件系统。

通常K8S分为两部分，一部分是MASTER，一部分是NODE。

• Master组件提供集群的管理控制中心。
• Node是Kubernetes中的工作节点，通常一个云服务器（或者一台主机）为一个Node，所有Node由Master统一管理。一个Node由一个kubelet，一个kube-proxy，多个Pod组成。

K8S的Service和kube-proxy

K8S的Service是一个抽象概念，他包含了一组Pod（通常这组Pod是一组有相同功能的微服务，即微服务集群）和一种可以访问它们的策略。

因为service是服务的抽象，所以由kube-proxy 负责对所有service进行实现。proxy为 Service 实现了一种 VIP（虚拟 IP）的形式，在k8s内只要通过这个vip即可对service进行访问。

kube-proxy会监视Kubernetes master 相关操作，当Kubernetes master 对 Service 对象和 Endpoints 对象的进行添加和移除的时候，kube-proxy会对上述的变化做出相应的响应（参考下文）。

K8S的Service控制器和endpoint控制器

EndPoint管理器监听master的API服务器中service资源和pod资源的变化，每当master使用Service控制器对服务进行创建或删除的时候，EndPoint管理器会自动更新保存在etcd上的endpoint资源。

K8S的kube-proxy

kube-proxy是Kubernetes的核心组件，部署在每个Node节点上，它是实现Kubernetes Service的通信与负载均衡机制的重要组件; kube-proxy负责为Pod创建代理服务，从apiserver获取所有server信息（就是上面endpoint信息以及service信息），并根据server信息创建代理服务，实现server到Pod的请求路由和转发，从而实现K8s层级的虚拟转发网络。
更为详细的解释可以参考这个

Istio

Isio是基于边车模式（sidecar）以及service mesh模式（服务网格）产生的框架。他的目的是将与业务无关的服务治理功能和具体的业务功能进行解耦，并对服务治理治理功能进行统一管理。

Istio 的架构

Istio 的架构在逻辑上分为“控制面”和“数据面”。

• “数据面“：由一组 Sidecar 构成。这些 Sidecar 可以调节和控制微服务及 Mixer 之间所有的网络通信。（数据面的组件有 Envoy（在 Istio 中，默认的 Sidecar 是 Envoy））
• “控制面“：负责管理和配置代理路由流量。此外，控制面通过 Mixer 来实施策略和收集各个 Sidecar 的遥测数据。（控制面的组件有 Pilot、Mixer、Citadel）

每个组件的作用

• Envoy用于调解服务网格中所有服务的入站和出站流量。所有经过 Envoy 的流量行为都会调用 Mixer。

• Pilot 为 Sidecar 提供“服务发现”功能（发现所有的Pod）（服务注册功能由基础平台提供（如K8S）），此外，Pilot还用于对整个Istio的流量进行统一管理和配置。

• Mixer 是一个独立于平台的组件，通过从 Sidecar 和一些其他服务处收集数据，进而在整个 Service Mesh 上控制访问和执行策略。（从envoy收集到的数据会在mixer进行统一管理，并展示给运维；Mixer分为Policy和Telemetry两个子模块。Policy用于向Envoy提供准入策略控制，黑白名单控制，速率限制等相关策略；Telemetry为Envoy提供了数据上报和日志搜集服务，以用于监控告警和日志查询）
  

• Citadel 通过内置身份和凭证管理提供“服务间”和“最终用户”身份验证。

K8S和Istio

Istio能为K8S扩展熔断、限流、动态路由、调用链追踪等功能，这些是K8S所不具备的。

在Istio融合至K8S的过程中，Istio的服务发现就是从Kube-apiserver中获取Service和Endpoint，然后将其转换成Istio服务模型的Service和ServiceInstance，但是其数据面组件不再是Kube-proxy，而是在每个Pod里部署的Sidecar，也可以将其看作每个服务实例的Proxy。这样，Proxy的粒度就更细了，和服务实例的联系也更紧密了，可以做更多更细粒度的服务治理通过拦截Pod的Inbound流量和Outbound流量，并在Sidecar上解析各种应用层协议，Istio可以提供真正的应用层治理、监控和安全等能力。