大家好,又见面了,我是你们的朋友全栈君。
服务网格
服务网格(Service Mesh)这个术语通常用于描述构成这些应用程序的微服务网络以及应用之间的交互。随着规模和复杂性的增长,服务网格越来越难以理解和管理。它的需求包括服务发现、负载均衡、故障恢复、指标收集和监控以及通常更加复杂的运维需求,例如 A/B 测试、金丝雀发布、限流、访问控制和端到端认证等。
服务网格的工作
- Istio 将服务请求路由到目的地址,根据中的参数判断是到生产环境、测试环境还是 staging 环境中的服务(服务可能同时部署在这三个环境中),是路由到本地环境还是公有云环境?所有的这些路由信息可以动态配置,可以是全局配置也可以为某些服务单独配置。
- 当 Istio 确认了目的地址后,将流量发送到相应服务发现端点,在 Kubernetes 中是 service,然后 service 会将服务转发给后端的实例。
- Istio 根据它观测到最近请求的延迟时间,选择出所有应用程序的实例中响应最快的实例。
- Istio 将请求发送给该实例,同时记录响应类型和延迟数据。
- 如果该实例挂了、不响应了或者进程不工作了,Istio 将把请求发送到其他实例上重试。
- 如果该实例持续返回 error,Istio 会将该实例从负载均衡池中移除,稍后再周期性得重试。
- 如果请求的截止时间已过,Istio 主动失败该请求,而不是再次尝试添加负载。
- Istio 以 metric 和分布式追踪的形式捕获上述行为的各个方面,这些追踪信息将发送到集中 metric 系统。 Istio 提供了一个完整的解决方案,通过为整个服务网格提供行为洞察和操作控制来满足微服务应用程序的多样化需求。
istio安全通信路径
1.out-of-band telemetry propogation:带外遥测繁殖
2.Control flow during request processing:请求处理期间的控制流程
3.Application traffic:前景流量
Sidecar:代理负责证书生命周期的管理,包括证书的生成、分发、刷新和注销。在Pod内部sidecar会与应用容器之间建立本地TCP连接,其中使用mTLS(双向传输层加密)。
因为一个节点上甚至一个Pod内都不一定运行一个容器,容器可能会被暴露到外部访问,保证传输层的双向加密,可以保证流量传输的安全。
Istio对Pod要求
- 需要给端口正确命名:服务端口必须进行命名。端口名称只允许是<协议>[-<后缀>-]模式,其中<协议>部分可选择范围包括 http、http2、grpc、mongo 以及 redis,Istio 可以通过对这些协议的支持来提供路由能力。例如 name: http2-foo 和 name: http 都是有效的端口名,但 name: http2foo 就是无效的。如果没有给端口进行命名,或者命名没有使用指定前缀,那么这一端口的流量就会被视为普通 TCP 流量(除非显式的用 Protocol: UDP 声明该端口是 UDP 端口)。
- 关联服务:Pod 必须关联到 Kubernetes 服务,如果一个 Pod 属于多个服务,这些服务不能再同一端口上使用不同协议,例如 HTTP 和 TCP。
- Deployment 应带有 app 以及 version 标签:在使用 Kubernetes Deployment 进行 Pod 部署的时候,建议显式的为 Deployment 加上 app 以及 version 标签。每个 Deployment 都应该有一个有意义的 app 标签和一个用于标识 Deployment 版本的 version 标签。app 标签在分布式跟踪的过程中会被用来加入上下文信息。Istio 还会用 app 和 version 标签来给遥测指标数据加入上下文信息。
Istio的优点
用于连接、保护、控制和观测服务 Istio 提供一种简单的方式来为已部署的服务建立网络,该网络具有负载均衡、服务间认证、监控等功能,而不需要对服务的代码做任何改动。想要让服务支持 Istio,只需要在您的环境中部署一个特殊的 sidecar 代理,使用 Istio 控制平面功能配置和管理代理,拦截微服务之间的所有网络通信:
- HTTP、gRPC、WebSocket 和 TCP 流量的自动负载均衡。
- 通过丰富的路由规则、重试、故障转移和故障注入,可以对流量行为进行细粒度控制。
- 可插入的策略层和配置 API,支持访问控制、速率限制和配额。
- 对出入集群入口和出口中所有流量的自动度量指标、日志记录和跟踪。
- 通过强大的基于身份的验证和授权,在集群中实现安全的服务间通信。
Istio 旨在实现可扩展性,满足各种部署需求。 Istio 简化了断路器、超时和重试等服务级别属性的配置,并且可以轻松设置 A/B测试、金丝雀部署和基于百分比的流量分割的分阶段部署等重要任务。
Istio平台支持
Istio 是独立于平台的,旨在运行在各种环境中,包括跨云、内部部署、Kubernetes、Mesos 等。您可以在 Kubernetes 上部署 Istio 或具有 Consul 的 Nomad 上部署。Istio 目前支持:
- 在 Kubernetes 上部署的服务
- 使用 Consul 注册的服务
- 在虚拟机上部署的服务
Istio架构
Istio 服务网格逻辑上分为数据平面和控制平面。
- 数据平面由一组以 sidecar 方式部署的智能代理(Envoy)组成。这些代理可以调节和控制微服务及 Mixer 之间所有的网络通信。
- 控制平面负责管理和配置代理来路由流量。此外控制平面配置 Mixer 以实施策略和收集遥测数据。
架构
实现服务连接架构
- Mixer
Mixer 是一个独立于平台的组件,负责在服务网格上执行访问控制和使用策略,并从 Envoy 代理和其他服务收集遥测数据。代理提取请求级属性,发送到 Mixer 进行评估。有关属性提取和策略评估的更多信息,请参见 Mixer 配置。 Mixer 中包括一个灵活的插件模型,使其能够接入到各种主机环境和基础设施后端,从这些细节中抽象出 Envoy 代理和 Istio 管理的服务。
- Pilot
Pilot 为 Envoy sidecar 提供服务发现功能,为智能路由(例如 A/B 测试、金丝雀部署等)和弹性(超时、重试、熔断器等)提供流量管理功能。它将控制流量行为的高级路由规则转换为特定于 Envoy 的配置,并在运行时将它们传播到 sidecar。
Pilot 将平台特定的服务发现机制抽象化并将其合成为符合 Envoy 数据平面 API 的任何 sidecar 都可以使用的标准格式。这种松散耦合使得 Istio 能够在多种环境下运行(例如,Kubernetes、Consul、Nomad),同时保持用于流量管理的相同操作界面。
- Citadel
Citadel 通过内置身份和凭证管理可以提供强大的服务间和最终用户身份验证。可用于升级服务网格中未加密的流量,并为运维人员提供基于服务标识而不是网络控制的强制执行策略的能力。从 0.5 版本开始,Istio 支持基于角色的访问控制,以控制谁可以访问您的服务。
Istio的svc
代码语言:javascript复制[root@k8-master-1 istio-1.0.0]# kubectl get svc -n istio-system
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S)
grafana ClusterIP 10.111.208.248 <none> 3000/TCP
istio-citadel ClusterIP 10.100.90.87 <none> 8060/TCP,9093/TCP
istio-egressgateway ClusterIP 10.104.226.35 <none> 80/TCP,443/TCP
istio-galley ClusterIP 10.111.83.5 <none> 443/TCP,9093/TCP
istio-ingressgateway NodePort 10.104.131.107 <none> 80:31380/TCP,443:31390/TCP,31400:31400/T
istio-pilot ClusterIP 10.107.79.16 <none> 15010/TCP,15011/TCP,8080/TCP,9093/TCP
istio-policy ClusterIP 10.107.216.191 <none> 9091/TCP,15004/TCP,9093/TCP
istio-sidecar-injector ClusterIP 10.105.23.193 <none> 443/TCP
istio-statsd-prom-bridge ClusterIP 10.107.140.36 <none> 9102/TCP,9125/UDP
istio-telemetry ClusterIP 10.107.51.138 <none> 9091/TCP,15004/TCP,9093/TCP,42422/TCP
jaeger-agent ClusterIP None <none> 5775/UDP,6831/UDP,6832/UDP
jaeger-collector ClusterIP 10.98.131.177 <none> 14267/TCP,14268/TCP
jaeger-query ClusterIP 10.101.114.183 <none> 16686/TCP
prometheus ClusterIP 10.111.99.143 <none> 9090/TCP
servicegraph NodePort 10.102.175.94 <none> 8088:30009/TCP
tracing ClusterIP 10.100.254.132 <none> 80/TCP
zipkin ClusterIP 10.100.208.206 <none> 9411/TCP
- istio-egressgateway
- 出口网关,可选的
- istio-ingressgateway
- 入口网关,必须的
- 对外流量入口,所有从外部访问集群内部的服务都需要经过入口网关ingressgateway。需要多实例、防止单点;同时要保证多实例进行负载均衡;
- 如果异常则导致整个流量入口异常
- 承担相对较大的并发和高峰流量
- istio-pilot
- 控制sidecar中envoy的启动与参数配置
- 如果异常则envoy无法正常启动,应用服务的流量无法进行拦截和代理
- 所有配置、流量规则、策略无法生效
- 必要组件
- istio-sidecar-injector
- 现sidecar自动注入功能组件
- istio-statsd-prom-bridge
- 暴露9102、9125端口
- 9125是statsdUdpAddress配置的地址
- 9102是prometheus的Metric接口
- 这个是istio-statsd-prom-bridge组件提供的服务
- 这个 statsd是一个转换为prometheus的组件,用来统计envoy 生成的数据,这个是必须的
- 暴露9102、9125端口
- istio-policy
- Mixer相关组件,用于与envoy交互,check需要上报的数据,确定缓存内容,挂掉会影响check相关功能,除非设置为不进行check
- 不能直接关闭或者说禁能这个策略组件,因为默认请求都是要去policy pods进行check检测的,如果失败则会导致请求失败
- 通过安装参数–set mixer.enabled=false禁能
- istio-telemetry
- Mixer相关组件的Service,用于采集envoy上报的遥测数据
- 高并发下会有性能影响,会间接导致整体性能下降,业界针对这个有较多探讨;可以禁能
- 为提高性能,需要设置为多实例,防止单点;均衡流量
- istio-citadel
- 用于安全相关功能,为服务和用户提供认证和鉴权、管理凭据和 RBAC,挂掉则会导致认证,安全相关功能失效
- –set security.enabled=false如果要禁能则通过设置security,它对应的镜像就是citadel
- 如果前期不使用安全相关的功能可以禁能,不会影响整体使用
- 如果部署了 istio-citadel,则 Envoy 每 15 分钟会进行一次重新启动来刷新证书
- istio-galley
- stio API配置的校验、各种配置之间统筹,为 Istio 提供配置管理服务,包含有Kubernetes CRD资源的listener,通过用Kubernetes的Webhook机制对Pilot 和 Mixer 的配置进行验证
- 这个服务挂掉会导致配置校验异常,是一个必须的组件
- 比如创建gateway、virtualService等资源,就会需要校验
- prometheus
- 暴露9090端口
- prometheus组件的Service
- 如果采用外部的prometheus则不用
- 其他组件如jaeger、grafana则同样采用外部系统,因此可以不用和istio一起安装
发布者:全栈程序员栈长,转载请注明出处:https://javaforall.cn/127869.html原文链接:https://javaforall.cn