常用的构建方法 https://skyao.io/learning-envoy/ 手动配置构建环境，手动构建Envoy。 使用Envoy提供的预制于Docker中的构建环境进行手动构建二进制Envoy 使用Envoy提供的预制于Docker中的构建环境进行手动构建二进制Envoy，并直接将Envoy程序打包成Docker镜像 提供Bootstrap配置文件，存在使用xDS的动态资源时，还需要基于文件或管理服务器向其提供必须的配置信息 也可使用Envoy的配置生成器生成示例性配置 基于Bootstrap配置文件启动Envoy实例 直接启动二进制Envoy 于Kubernetes平台基于Sidecar的形式运行Envoy，或运行单独的Envoy Pod（Edge Proxy） 启动Envoy 启动Envoy时，需要通过（-c 选项为其指定初始配置文件以提供引导配置（Bootstrap configuration），这也是使用v2APl的必然要求； text 1 envoy -c <path to config>.{json,yaml,pb,pb_text} 扩展名代表了配置信息的组织格式； 引导配置是Envoy配置信息的基点，用于承载Envoy的初始配置，它可能包括静态资源和动态资源的定义 静态资源（static_resources）于启动直接加载 动态资源（dynamic_resources）则需要通过配置的xDS服务获取并生成 通常，Listener 和 Cluster 是Envoy得以运行的基础，而二者的配置可以全部为静态格式，也可以混合使用动态及静态方式提供，或者全部配置为动态； 一个yaml格式纯静态的基础配置框架类似如下所示： yaml 1 2 3 4 5 6 7 8 9 10 11 static_resources: linteners: - name: ... address: {} filter_chains: [] clusters: - name: ... type: ... connect_timeout: {} lb_policy: ... load_assignment: {} Listener 简易静态配置 侦听器主要用于定义Envoy监听的用于接收Down streams请求的套接字、用于处理请求时调用的过滤器链及相关的其它配置属性;目前envoy仅支持tcp的协议 yaml 1 2 3 4 listeners: - name: address: socket_address: { address: ....

official front proxy 在一个Services Mash内部中，都会存在一到多个微服务，为了将南北向流量统一引入网格内部管理，通常存在单独运行的envoy实例。 Envoy的listener支持面向下游客户端一侧的TLS会话，并可选地支持验正客户端证书； listener中用到的数字证书可于配置中静态提供，也可借助于SDS动态获取; tls_context 是 listeners 当中某一个 filter_chains 中上线文中的配置，tls_context 配置在哪个 listeners当中就隶属于哪个listeners。 yaml 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 listeners: ... filter_chains: - filters: .. tls_context: common_tls_context: {} # 常规证书相关设置； tls_params: {} # TLS协议版本，加密套件等； tls_certifcates: [] # 用到的证书和私钥文件； - certifcate_chain: {} filename: # 证书文件路径; private_key: {} # 私钥; filename: # 私钥文件路径; password: {} # 私钥口令； filename: # 口令文件路径； tls_certifcate_sds_secret_configs: [] # 要基于SDS API获取TLS会话的相关信息时的配置； require_client_certifcate: # 是否验证客户端证书； 例如，下面示例将前面的Ingress示例中的Envoy配置为通过TLS提供服务，并将所有基于http协议的请求重定向至https；...

显示配置文件中的差异 istioctl profile diff default demo 显示对应配置的profile istioctl profile dump demo 显示可用的配置 istioctl profile list 安装指定配置的istio istioctl install --set profile=demo 生成配置清单 istioctl manifest generate istioctl验证安装: istioctl manifest generate --set profile=demo |istioctl verify-install - istio的非侵入式流量治理 流量治理是一个非常宽泛的话题，例如： ◎ 动态修改服务间访问的负载均衡策略，比如根据某个请求特征做会话保持； ◎ 同一个服务有两个版本在线，将一部分流量切到某个版本上； ◎ 对服务进行保护，例如限制并发连接数、限制请求数、隔离故障服务实例等； ◎ 动态修改服务中的内容，或者模拟一个服务运行故障等。 在Istio中实现这些服务治理功能时无须修改任何应用的代码。较之微服务的SDK方式，Istio以一种更轻便、透明的方式向用户提供了这些功能。用户可以用自己喜欢的任意语言和框架进行开发，专注于自己的业务，完全不用嵌入任何治理逻辑。只要应用运行在Istio的基础设施上，就可以使用这些治理能力。 一句话总结 Istio 流量治理的目标：以基础设施的方式提供给用户非侵入的流量治理能力，用户只需 关注自己的业务逻辑开发，无须关注服务访问管理。 istio服务架构 在istio1.8中，istio的分为 envoy （数据平面） 、istiod （控制平面） 、addons（管理插件） 及 istioctl （命令行工具，用于安装、配置、诊断分析等操作）组成。 Pilot Pilot是Istio控制平面流量管理的核心组件，管理和配置部署在Istio服务网格中的所有Envoy代理实例。 pilot-discovery为envoy sidecar提供服务发现，用于路由及流量的管理。通过kubernetes CRD资源获取网格的配置信息将其转换为xDS接口的标准数据格式后，通过gRPC分发至相关的envoy sidecar Pilot组件包含工作在控制平面中的 pilot-discovery 和工作与数据平面的pilot-agent 与Envoy(istio-proxy) pilot-discovery主要完成如下功能： 从service registry中获取服务信息 从apiserver中获取配置信息。 将服务信息与配置信息适配为xDS接口的标准数据格式，通过xDS api完成配置分发。 pilot-agent 主要完成如下功能...

Istio用于提供统一方式来集成微服务的开放平台，管理微服务之间的流量，执行策略和汇总遥测数据。Istio的控制平面在基础集群管理平台（例如Kubernetes）上提供了一个抽象层。 Istio组成： 在Istio1.8中，istio由以下组件组成：istio-component istio服务网格分为数据平面和控制平面 数据平面：数据平面是由一组代理组成 envoy：Sidecar Proxy 每个微服务代理来处理入口/出口业务服务之间的集群中，并从外部服务的服务。代理形成一个*安全的微服务网格，*提供了丰富的功能集合 控制平面：管理与配置代理的流量规则。 istiod：istio的控制平面，提供了服务发现，配置和证书管理，包含如下组件： Pilot ：负责运行时配置，（服务发现，智能路由） Citadel：负责证书的颁发与轮替 Galley：负责配置的管理（验证，提取，分发等功能） istio卸载 bookinfo卸载 text 1 kubectl delete -f samples/bookinfo/platform/kube/bookinfo.yaml istio卸载 text 1 istioctl manifest generate|kubectl delete -f - addons text 1 2 3 4 kubectl delete -f samples/addons/prometheus.yaml kubectl delete -f samples/addons/jaeger.yaml kubectl delete -f samples/addons/kiali.yaml kubectl delete -f samples/addons/grafana.yaml

数字证书 互联网上任意双方之间实现通信时，证书的目的有两种， 主机证书，主要实现主机与主机之间进程间通信的。 个人证书，主要用作个人通信的，主要用作加密的数据的发送。 主机类证书所拥有的标识主要为主机名，主机证书名称一定要与互联网之上访问名称一致，否则此证书为不可信证书。 对于一个安全的通信，应该有以下特征： 完整性：消息在传输过程中未被篡改 身份验证：确认消息发送者的身份 不可否认：消息的发送者无法否认自己发送了信息 显然，数字签名和消息认证码是不符合要求的，这里就需要数字证书来解决其弊端。 数字证书（digital certificate）又称公开密钥认证 PKC（英语：Public key certificate）。是在互联网通信中，方式数字签名的秘钥被篡改，是用来证明公开密钥拥有者的身份。此文件包含了公钥信息、拥有者身份信息（主体）、以及数字证书认证机构（发行者）对这份文件的数字签名，以保证这个文件的整体内容正确无误。 数字证书认证机构 CA (Certificate Authority)：是负责发放和管理数字证书的权威机构。 公钥证书的格式标准 X.509是密码学中公钥明证PKC的格式标准，所有的证书都符合ITU-T X.509国际标准。X.509证书的结构是用ASN1 (Abstract Syntax Notation One)进行描述数据结构，并使用ASN.1语法进行编码。 证书规范 X.509指的是ITU和ISO联合制定的（RFC5280）里定义的的 X.509 v3 前使用最广泛的标准为X.509的 v3版本规范 (RFC5280）, 一般遵从X.509格式规范的证书，会有以下的内容： 证书组成结构 结构 说明 版本 现行通用版本是 V3， 序号 用来识别每一张证书，用来追踪和撤销证书。只要拥有签发者信息和序列号，就可以唯一标识一个证书，最大不能过20个字节；由CA来维护 主体 拥有此证书的法人或自然人身份或机器，包括： 国家（C，Country） 州/省（S，State）** 地域/城市（L，Location） 组织/单位（O，Organization） 通用名称（CN，Common Name）：在TLS应用上，此字段一般是域名 发行者 以数字签名形式签署此证书的数字证书认证机构 有效期(Validity) 此证书的有效开始时间，在此前该证书并未生效；此证书的有效结束时间，在此后该证书作废。 公开密钥用途 指定证书上公钥的用途，例如数字签名、服务器验证、客户端验证等 公开密钥 公开密钥指纹 数字签名 使用信任的CA对内容进行 主体别名 例如一个网站可能会有多个域名（www.jd.com www.360buy.com..） 一个组织可能会有多个网站（*.baidu.com tieba.baidu.com），不同的网域可以一并使用同一张证书，方便实现应用及管理。 互联网上任意双方之间实现通信时，证书的目的有两种， 主机证书，主要实现主机与主机之间进程间通信的。 个人证书，主要用作个人通信的，主要用作加密的数据的发送。 主机类证书所拥有的标识主要为主机名，主机证书名称一定要与互联网之上访问名称一致，否则此证书为不可信证书。 数字证书文件格式 X....