istio服务治理op

发表于 | 分类于

服务治理的三种发展形态

  • 应用程序中包含治理逻辑
  • 治理逻辑独立的代码（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[-]形式，protocol可以使tcp、http、http2、https、mysql、redis等。istio根据端口定义的协议提供对应的路由能力。如果端口未命名或没有基于这种格式，则端口的流量会当成tcp流量来处理。

  • 服务关联

    如果一个pod属于多个k8s服务，则要求服务不能再同一个端口使用不同的协议。

  • Deployment使用app和version标签：

    每个deployment都需要一个有业务意义的app标签和一个表示版本的version标签。分布式追踪可以通过app标签补齐上下文信息，还可以通过app和version为遥测数据补齐上下文信息。

openshift deploy组件的注入问题

当开启了namespace的自动注入，又是在用openshift的deploy进行服务部署时，会发生deploy组件complete之后istio-proxy容器不会停止。这时，我们可以修改下istio-inject的ConfigMap配置：

当检测到

1
2
3
4
5
neverInjectSelector:
  - matchExpressions:
    - {key: openshift.io/build.name, operator: Exists}
  - matchExpressions:
    - {key: openshift.io/deployer-pod-for.name, operator: Exists}