istio 服务治理指引
服务治理的三种发展形态
应用程序中包含治理逻辑
治理逻辑独立的代码（SDK模式）
治理逻辑独立的进程（SIDECAR模式）
spring cloud + k8s 与 istio + k8s的比较
| 项目 | istio + k8s | spring cloud + k8s |
|---|---|---|
| 架构设计 | 基于Kubernetes能力构建 | 和Kubernetes无结合 |
| 服务发现 | 使用k8s服务名，和k8s一致的服务发现机制 | 两套服务发现。有服务发现数据不一致的问题。k8s中pod的正常迁移会引起重新进行服务注册 |
| 使用体验 | 完全的k8s使用体验。sidecar自动注入pod，业务无感知，和部署普通k8s服务无差别。 | 和k8s无结合，k8s只是提供了运行环境 |
| 控制面 | 无需额外的APIServer和规则策略定义。基于k8s CRD进行扩展。 | 需自行安装和维护控制面来管理治理规则。 |
istio的几个约束
端口命名：
服务端口必须进行命名，而且名称只能是protocol[-<suffix>]形式，protocol可以使tcp、http、http2、https、mysql、redis等。istio根据端口定义的协议提供对应的路由能力。如果端口未命名或没有基于这种格式，则端口的流量会当成tcp流量来处理。
服务关联
如果一个pod属于多个k8s服务，则要求服务不能在同一个端口使用不同的协议。
Deployment使用app和version标签：
每个deployment都需要一个有业务意义的app标签和一个表示版本的version标签。分布式追踪可以通过app标签补齐上下文信息，还可以通过app和version为遥测数据补齐上下文信息。
Service descriptors:
• Each service port name must start with the protocol name, for example, name: http.
Deployment descriptors:
The pods must be associated with a Kubernetes service.
The pods must not run as a user with UID 1337.
It is recommended that app and version labels are added to provide contextual information for metrics and telemetry.
If you don’t have NET_ADMIN security rights, you would need to use the Istio CNI plugin to remove the NET_ADMIN requirement.
基本概念讲解 https://jimmysong.io/posts/istio-traffic-management-basic-concepts/
流量管理资源配置
下面将带您了解 Istio 流量管理相关的基础概念与配置示例。
VirtualService在 Istio 服务网格中定义路由规则，控制流量路由到服务上的各种行为。DestinationRule是VirtualService路由生效后，配置应用与请求的策略集。ServiceEntry通常用于在 Istio 服务网格之外启用的服务请求。Gateway为 HTTP/TCP 流量配置负载均衡器，最常见的是在网格边缘的操作，以启用应用程序的入口流量。EnvoyFilter描述了针对代理服务的过滤器，用来定制由 Istio Pilot 生成的代理配置。一定要谨慎使用此功能。错误的配置内容一旦完成传播，可能会令整个服务网格陷入瘫痪状态。这一配置是用于对 Istio 网络系统内部实现进行变更的。
istio自动注入过程
kube-apiserver拦截到pod创建请求
kube-apiserver调用自动注入服务istio-sidecar-injector生成sidecar容器的描述并插入到原pod定义中。
kubelet根据新构造的pod定义启动pod
istio的流量治理过程
控制面
运维人员通过命令行创建流量规则
pilot将流量规则转换为Envoy的标准格式
Pilot将规则下发到Envoy
数据面
Envoy拦截pod的Inbound和Outbound流量
Envoy对经过的流量按规则进行治理
istio配置
# 修改istio的ConfigMap，打开日志
values.global.proxy.accessLogFile="/dev/stdout"
openshift deploy组件的注入问题
当开启了namespace的自动注入，又是在用openshift的deploy进行服务部署时，会发生deploy组件complete之后istio-proxy容器不会停止。这时，我们可以修改下istio-inject的ConfigMap配置：
neverInjectSelector:
- matchExpressions:
- {key: openshift.io/build.name, operator: Exists}
- matchExpressions:
- {key: openshift.io/deployer-pod-for.name, operator: Exists}