点击上方蓝字 👆关注【云原生百宝箱】公众号，别让消息溜走
后台回复【加群】，与牛人互动不停
为什么需要Istio，因为它提高了系统的弹性、安全性，并有助于应用程序的可观察性。Istio有两个关键概念：VirtualService和DestinationRule。VirtualService告诉Istio如何定向流量，而DestinationRule指导了在Service中的具体路径。
Kubernetes 和 Istio 是一个伟大的组合。
他们愉快地连接集群中的 Pod。
但为什么需要 istio 呢？
因为它提高了弹性、安全性并有助于提高应用程序的可观察性。
要了解 istio，你需要了解两件事。
1. VirtualService。
2. DestinationRule。
VirtualService 告诉 Istio 如何引导流量
如下的VirtualService 配置定义了以下内容，
1. 将 95% 的流量发送到旧子集。
2. 新子集获得 5% 的流量。
kind: VirtualService
metadata:
name: service-b-vs
spec:
hosts:
- Service-B
http:
- route:
- destination:
host: Service-B
subset: old
weight: 95
- destination:
host: Service-B
subset: new
weight: 5这是一个 Istio 中的 VirtualService 的配置文件，用于定义服务路由规则。以下是对配置文件中各字段的解释：
•
kind: VirtualService: 表示这是一个 Istio 中的 VirtualService 资源。•
metadata: 包含资源的元信息，其中name字段指定了这个 VirtualService 的名称，这里是 "service-b-vs"。•
spec: 包含了 VirtualService 的规格，定义了服务的路由规则。•
route: 包含了多个路由规则，这些规则指定了不同的目标（destination）和相应的权重（weight）。•
destination: 同样指定了目标服务和子集，但这次是 "new" 子集。•
weight: 指定了将流量路由到这个目标的权重，这里是 5。•
destination: 指定了目标服务的名称和子集。在这个例子中，目标服务是 "Service-B"，子集是 "old"。•
weight: 指定了将流量路由到这个目标的权重，这里是 95。• 第一个路由规则：
• 第二个路由规则：
•
hosts: 指定了应用这个 VirtualService 的主机名。在这个例子中，主机名是 "Service-B"。•
http: 定义了针对 HTTP 请求的路由规则。
通过这个配置，流量将以95%的权重路由到 "old" 子集，以5%的权重路由到 "new" 子集。这种权重分配的目的可能是逐渐将流量从 "old" 版本过渡到 "new" 版本，以进行无缝的服务更新。
DestinationRule 指示 Service-B 中的去向
简单来说：
• old表示应用程序 1.0
• new表示应用程序 2.0
目标规则配置：
kind: DestinationRule
metadata:
name: service-b-dr
spec:
host: Service-B
subsets:
- name: old
labels:
App: "1.0"
- name: new
labels:
App: "2.0"这是一个 Istio 中的 DestinationRule 的配置文件，用于定义服务的子集，并为每个子集定义标签。以下是对配置文件中各字段的解释：
•
kind: DestinationRule: 表示这是一个 Istio 中的 DestinationRule 资源。•
metadata: 包含资源的元信息，其中name字段指定了这个 DestinationRule 的名称，这里是 "service-b-dr"。•
spec: 包含了 DestinationRule 的规格，定义了服务的子集。• 第一个子集：
• 第二个子集：
•
name: 子集的名称，这里是 "old"。•
labels: 包含了一组标签，这里标签的键是 "App"，值是 "1.0"。•
name: 子集的名称，这里是 "new"。•
labels: 包含了一组标签，这里标签的键是 "App"，值是 "2.0"。•
host: 指定了这个 DestinationRule 生效的服务的名称，这里是 "Service-B"。•
subsets: 包含了多个子集的定义，每个子集都有一个名称和一组标签。
通过这个配置，服务 "Service-B" 被划分为两个子集，分别是 "old" 和 "new"。每个子集都有一组标签，用于标识服务的版本或其他属性。这些标签可以在 Istio 的流量管理规则中使用，例如在 VirtualService 中进行流量路由。这种标签的使用有助于实现服务的细粒度流量控制和版本管理。
CICD之平滑升级与灰度发布
在云服务的部署过程中平滑升级和灰度发布是两个非常重要的发布策略，也是运维水平高低的体现。
平滑升级主要解决0宕机部署，灰度发布主要解决流量控制。
下面对两种策略的目标和实现方式的核心点做了介绍。
平滑升级
平滑升级实现在升级部署过程中，不中断对外服务，也就是用户可以持续使用，感觉不到服务的升级，如果升级到新版本如果有问题，也可以在用户使用之前做回退或修复，避免有问题的版本被用户使用。
目标：服务升级过程中保持对外服务不中断，实现0宕机部署。
实现方式：其关键在于每一时刻均有至少一个节点还能正常提供服务。步骤如下：
1. 需要部署多个服务节点，将服务分为A、B两批更新
2. 更新服务时，先将A批服务的路由从HAProxy上面摘下来
3. 更新A批服务
4. A批服务健康检查正常后，重新加入路由
5. 摘下B批服务的路由
6. 更新B批容器
7. B批服务健康检查正常后，重新加入路由
8. 服务平滑升级完毕
使用场景
1. 不影响线上用户使用的情况下，对服务进行升级
灰度发布
线上流量通过分流规则访问到不同的后端服务。虽然所有用户访问的都是同一个域名，但是他们真正访问的服务是不同的。
目标：线上用户流量可以按照分流规则分配到不同的后端服务。
原理：不通版本的服务可以共享同一路由信息，通过调整HAProxy权重的方式来做到按规则分流。
实现方式：例如有服务的两个版本A 和 a，他们使用相同的路由，挂在同一个域名（例如）的后端，但是A和a的权重不一样，通过调整权重将流量分配到不同的后端，实现灰度发布。
使用场景
1. A/B测试
2. 服务升级发布时，保持新旧版本并存，测试完毕之前，让测试人员流量进入新版本，线上用户流量进入旧版本
原文作者：云原生AI百宝箱；如有侵权，请联系管理员删除。
