istio 服务治理指引

Posted 2021-04-13 spark之路

服务治理的三种发展形态

• 应用程序中包含治理逻辑

• 治理逻辑独立的代码（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自动注入过程

1. kube-apiserver拦截到pod创建请求

2. kube-apiserver调用自动注入服务istio-sidecar-injector生成sidecar容器的描述并插入到原pod定义中。

3. kubelet根据新构造的pod定义启动pod

istio的流量治理过程

控制面

1. 运维人员通过命令行创建流量规则

2. pilot将流量规则转换为Envoy的标准格式

3. Pilot将规则下发到Envoy

数据面

1. Envoy拦截pod的Inbound和Outbound流量

2. 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}