sidecar

背景 最近因工作原因开始了解Service Mesh与Envoy，为系统性梳理所学内容，因此沉淀了此文档，但由于所知有限，如文档中有描述不当之处，希望不吝赐教。 提到Envoy就不得不提Service Mesh，说到Service Mesh就一定要谈及微服务了，那么我们就先放下Envoy，简单了解下微服务、Service Mesh以及Envoy在Service Mesh中处于一个什么样的角色。 过去几年间，架构领域最火的方向非微服务莫属，那么微服务架构到底为我们带来了什么样的好处呢？下面通过一张图说明架构的演进，如下： 伴随着业务规模的变大，微服务的好处显而易见，例如它本身所具备的可扩展性、易维护性、故障和资源隔离性等诸多特性使得产品的生产研发效率大大提高，同时，基于微服务架构设计，研发人员可以构建出原生对于“云”具备超高友好度的系统，让产品的持续集成与发布变得更为便捷。 然而没有所谓的银弹，微服务带来很多好处的同时也引入了很多问题。在云原生模型里，一个应用可以由数百个服务组成，每个服务可能有数千个实例，每个实例的状态可能持续的发生变化，此时，服务间的通信不仅异常复杂，而且都是运行时的行为，管理好服务间通信对于保证端到端的性能与可靠性来说无疑成为重中之重。在Service Mesh没有出现之前，微服务框架之间的通讯大多采用SDK方案，但该方式短板也非常明显，例如对业务有侵入性

日志收集 Kubernetes 集群中监控系统的搭建，除了对集群的监控报警之外，还有一项运维工作是非常重要的，那就是日志的收集。 介绍 应用程序和系统日志可以帮助我们了解集群内部的运行情况，日志对于我们调试问题和监视集群情况也是非常有用的。而且大部分的应用都会有日志记录，对于传统的应用大部分都会写入到本地的日志文件之中。对于容器化应用程序来说则更简单，只需要将日志信息写入到 stdout 和 stderr 即可，容器默认情况下就会把这些日志输出到宿主机上的一个 JSON 文件之中，同样我们也可以通过 docker logs 或者 kubectl logs 来查看到对应的日志信息。 但是，通常来说容器引擎或运行时提供的功能不足以记录完整的日志信息，比如，如果容器崩溃了、Pod 被驱逐了或者节点挂掉了，我们仍然也希望访问应用程序的日志。所以，日志应该独立于节点、Pod 或容器的生命周期，这种设计方式被称为 cluster-level-logging，即完全独立于 Kubernetes 系统，需要自己提供单独的日志后端存储、分析和查询工具。 Kubernetes 中的基本日志 下面这个示例是 Kubernetes 中的一个基本日志记录的示例，直接将数据输出到标准输出流，如下： apiVersion: v1 kind: Pod metadata: name: counter spec:

1.部署 Bookinfo 应用 要在 Istio 中运行这一应用，无需对应用自身做出任何改变。我们只要简单的在 Istio 环境中对服务进行配置和运行，具体一点说就是把 Envoy sidecar 注入到每个服务之中。这个过程所需的具体命令和配置方法由运行时环境决定，而部署结果较为一致，如下图所示： 所有的微服务都和 Envoy sidecar 集成在一起，被集成服务所有的出入流量都被 sidecar 所劫持，这样就为外部控制准备了所需的 Hook，然后就可以利用 Istio 控制平面为应用提供服务路由、遥测数据收集以及策略实施等功能。 接下来可以根据 Istio 的运行环境，按照下面的讲解完成应用的部署。 进入 Istio 安装目录。 启动应用容器： 如果集群用的是 手工 Sidecar 注入 ，使用如下命令： $ kubectl apply -f <(istioctl kube-inject -f samples/bookinfo/platform/kube/bookinfo.yaml) istioctl kube-inject 命令用于在在部署应用之前修改 bookinfo.yaml 如果集群使用的是 自动 Sidecar 注入 ，只需简单的 kubectl 就能完成服务的部署。 $ kubectl apply -f samples/bookinfo/platform

　　背景： 　　 　　在阿里服务端开发以Java为主的大背景下，其他异构语言业务如何调用现有Java服务，如何与集团中间件打通，就成为使用非Java语言团队必须要解决的首要问题。 　　 　　已有方案问题： 　　 　　在ServiceMesh方案成熟之前，我们采用：通过Dart C/C++扩展方式调用各中间件客户端SO库（类JNI）。该方案在业务初期很好的解决了Dart服务端生态建设问题。但是该方案还存在以下几个问题： 　　 　　运维耦合度高。业务代码和客户端SO库代码打包在一起，运行在同一进程，一旦微服务框架需要升级，业务代码也需要维护和重启。 　　 　　复杂性：进程内的多个语言环境，跨语言数据表示和传输等问题，都会增加系统的复杂性，降低原有服务的性能。 　　 　　接入成本高 　　 　　新功能滞后 　　 　　ServiceMesh方案: 　　 　　由于现有方案存在的一些问题，我们转向ServiceMesh寻找解决问题的思路 　　 　　如上图所示：与目前比较常见的微服务框架相比，ServiceMesh把微服务客户端核心功能独立出来，并作为一个独立Proxy进程部署在每一个主机上，业务进程通过Proxy进程与外界通信。这个独立的Proxy进程就是ServiceMesh的核心: SideCar。 　　 　　业务进程和SideCar之间最常见的两种通信方案：1.

官方文档： https://www.consul.io/docs/connect/index.html#getting-started-with-connect consul connect的功能类似与envoy，作为一个sidecar，用于实现service mesh，按我的理解，所谓的service mesh其实就是通过服务注册和服务发现，以及sidecar，屏蔽调用服务的ip和端口，仅仅通过服务名即可相互调用，同时由于sidecar的存在，还可以在sidecar这一层增加对服务的鉴权、流量控制等功能。 其实最终又归为计算机界的那句名言，任何都可以通过增加一层来解决，这里的这一层就是sidecar。 来源： https://www.cnblogs.com/lit10050528/p/11330284.html

此篇博文istio相关介绍和测试用例来源于网络，这里结合自己配置加以整理。 istio 介绍 官方中文参考文档 官方英文参考文档 服务网格（Service Mesh）这个术语通常用于描述构成这些应用程序的微服务网络以及应用之间的交互。随着规模和复杂性的增长，服务网格越来越难以理解和管理。它的需求包括服务发现、负载均衡、故障恢复、指标收集和监控以及通常更加复杂的运维需求，例如 A/B 测试、金丝雀发布、限流、访问控制和端到端认证等。 Istio 提供了一个完整的解决方案，通过为整个服务网格提供行为洞察和操作控制来满足微服务应用程序的多样化需求。 使用istio的目标 Istio 提供一种简单的方式来为已部署的服务建立网络，该网络具有负载均衡、服务间认证、监控等功能，只需要对服务的代码进行一点或不需要做任何改动。想要让服务支持 Istio，只需要在您的环境中部署一个特殊的 sidecar 代理，使用 Istio 控制平面功能配置和管理代理，拦截微服务之间的所有网络通信： HTTP、gRPC、WebSocket 和 TCP 流量的自动负载均衡。 通过丰富的路由规则、重试、故障转移和故障注入，可以对流量行为进行细粒度控制。 可插入的策略层和配置 API，支持访问控制、速率限制和配额。 对出入集群入口和出口中所有流量的自动度量指标、日志记录和跟踪。 通过强大的基于身份的验证和授权

官网本身有详细的说明，这里简述，当快速入门 目录 什么是ISTIO Istio 是一个用来连接、管理和保护微服务的开放平台。 Istio 提供一种简单的方式来为已部署的服务建立网络，该网络具有负载均衡、服务间认证、监控等功能，而不需要对服务的代码做任何改动。想要让服务支持 Istio，只需要在您的环境中部署一个特殊的 sidecar，使用 Istio 控制平面功能配置和管理代理，拦截微服务之间的所有网络通信。 HTTP、gRPC、WebSocket 和 TCP 流量的自动负载均衡。 通过丰富的路由规则、重试、故障转移和故障注入，可以对流量行为进行细粒度控制。 可插入的策略层和配置 API，支持访问控制、速率限制和配额。 对出入集群入口和出口中所有流量的自动度量指标、日志记录和跟踪。 通过强大的基于身份的验证和授权，在集群中实现安全的服务间通信。 ISTIO有什么用 Istio 提供了一个完整的解决方案，通过为整个服务网格提供行为洞察和操作控制来满足微服务应用程序的多样化需求。它在服务网络中统一提供了许多关键功能： 流量管理。控制服务之间的流量和API调用的流向，使得调用更可靠，并使网络在恶劣情况下更加健壮。 服务身份和安全。为网格中的服务提供可验证身份，并提供保护服务流量的能力，使其可以在不同可信度的网络上流转。 策略执行。将组织策略应用于服务之间的互动，确保访问策略得以执行

Istio各个Deployment包含的容器组件 Deployment 名称 Container和Port Container和Port istio-pilot pilot: 8080,15010 proxyv2: 15003,15005,15007 istio-galley galley: 443,9093 istio-egressgateway proxyv2: 80,443,15090 istio-ingressgateway proxyv2: 80,443,31400,15011,8060,853,15030,15031,15090 grafana grafana: 3000 istio-policy mixer: 9093,42422 proxyv2: 9091,15004,15090 istio-telemetry mixer: 9093,42422 proxyv2: 9091,15004,15090 prometheus prometheus: 9090 istio-citadel citadel: 8086 istio-sidecar-injector sidecar-injector istio-tracing jaegertracing/all-in-one: 9411,16686 UDP:5775,6832,6831 istio-ingress proxyv2