我们经常有这样的需求当svcb运行一段时间后svcb添加了新feature版本要升级到v0.2了这时我们会部署svcb:v0.2并将流量逐步切到v0.2上。我们先来部署一下svcb:v0.2// svcb-v0.2.yaml apiVersion: extensions/v1beta1 kind: Deployment metadata: name: svcb-v0.2 spec: replicas: 1 template: metadata: labels: app: svcb version: v0.2 spec: containers: - name: svcb image: docker.io/bigwhite/istio-demo-svcb:v0.2 imagePullPolicy: Always我们可以看到服务名不变但版本的label变成了v0.2我们来执行这次部署# kubectl apply -f (istioctl kube-inject -f svcb-v0.2.yaml) deployment svcb-v0.2 created # kubectl get pods NAME READY STATUS RESTARTS AGE svca-1997590752-pq9zg 2/2 Running 0 9h svcb-2008973769-gq0lh 2/2 Running 0 9h svcb-v0.2-3233505404-0g55w 2/2 Running 0 1m svcb服务下又增加了一个endpoint: # kubectl describe svc/svcb .... ... Selector: appsvcb Type: ClusterIP IP: 10.105.119.194 Port: unset 80/TCP Endpoints: 10.40.0.28:8080,10.46.0.12:8080 ... ...此时如果按照Kubernetes的调度方式v0.1和v0.2版本的两个svcb pod应该1:1均衡地承载流量。为了方便查看流量分布我们将每个版本的svcb的pod副本数量都扩展为2个replicas: 2这样Service Mesh中一共会有4个 svcb endpoints。通过curl访问svca注入流量后我们发现流量都集中在一个svcb:v0.2的pod上并且长时间没有变化。我们通过下面的route rule规则来尝试将流量在svcb:v0.1和svcb:v0.2之间1:1均衡// route-rules-svcb-v0.2-50.yaml apiVersion: config.istio.io/v1alpha2 kind: RouteRule metadata: name: route-rules-svcb spec: destination: name: svcb precedence: 1 route: - labels: version: v0.1 weight: 50 - labels: version: v0.2 weight: 50 # istioctl create -f route-rules-svcb-v0.2-50.yaml Created config route-rule/default/route-rules-svcb at revision 30080638按照Istio文档中的说法这个规则的生效需要一些时间。之后我们注入流量发现流量切换到svcb:v0.1的一个Pod上去了并且很长一段时间不曾变化未均衡到svcb:v0.2上去。我们更新一下route rule将流量全部切到svcb:v0.2上去//route-rules-svcb-v0.2-100.yaml apiVersion: config.istio.io/v1alpha2 kind: RouteRule metadata: name: route-rules-svcb spec: destination: name: svcb precedence: 1 route: - labels: version: v0.2 weight: 100 # istioctl replace -f route-rules-svcb-v0.2-100.yaml Updated config route-rule/default/route-rules-svcb to revision 30082944我们用Istio的replace命令更新了规则route-rules-svcb。更新后再次注入流量这回流量重新集中在svcb:v0.2的一个Pod上了再过一段时间另外一个svcb:v0.2的pod上才有了一些流量。但svcb:v0.1上不再有流量这个切换是成功的。在Kubernetes的Service的负载均衡中Kubernetes就利用了iptables的概率转发random –probability 0.5因此这种流量均衡并非是精确的只有在长时间大量流量经过后才能看到流量的分布与设定的权重是相似的可能Istio也是如此这里仅是入门就不深入挖掘了。当然Istio在路由规则设施方面的“能耐”远不止上面例子中所展示的那样如果要悉数列出那本文的长度可是要爆掉了。有兴趣的朋友可以去翻看官方文档。五、插件安装Istio的强大微服务治理能力还体现在其集成了Grafana、Prometheus、ServiceGraph、Zipkin等Addons应用程序无需做任何改动就可以具有数据收集、度量与可视化的监控能力、服务的分布式跟踪能力等。我们可以在Istio的安装包中找到这些Addons的安装文件我们来逐一试试。1、Prometheus Grafana我们先来安装一下Prometheus和Grafana插件位于istio-0.4.0/install/kubernetes/addon下面# kubectl apply -f prometheus.yaml configmap prometheus created service prometheus created deployment prometheus created # kubectl apply -f grafana.yaml service grafana created deployment grafana created # kubectl get pods -n istio-system NAME READY STATUS RESTARTS AGE grafana-3617079618-zpglx 1/1 Running 0 5m prometheus-168775884-ppfxr 1/1 Running 0 5m ... ... # kubectl get svc -n istio-system NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE grafana 10.105.21.25 none 3000/TCP 16m prometheus 10.103.160.37 none 9090/TCP 16m ... ...浏览器中输入Prometheus的服务地址http://10.103.160.37:9090访问Prometheus点击菜单项status - targets查看各个target的状态是否正常如果像上图所示那样各个target都是up状态那就说明Istio运行时OK的。否则请参考istio troubleshooting中的内容对Istio逐一进行排查尤其是istio-mesh这个Target在istio-0.3.0kubernetes 1.7.3的环境中就是Down的状态。浏览器输入grafana的服务地址切换到Istio Dashboard并向Istio Service Mesh注入流量我们会看到仪表盘变化如下2、ServiceGraphServiceGraph插件是用来查看服务调用关系的我们来创建一下该组件# kubectl apply -f servicegraph.yamldeployment servicegraph createdservice servicegraph created# kubectl get svc -n istio-systemNAME CLUSTER-IP EXTERNAL-IP PORT(S) AGEservicegraph 10.108.245.21 none 8088/TCP 52s... ...创建成功后向Service Mesh网络注入流量然后访问ServiceGraphhttp://{servicegraph_ip}:8088/dotviz在我的环境里我看到的图示如下调用关系似乎有些乱难道是我在程序使用的调用方法不够标准:(3、ZipkinIstio集成了Zipkin利用Zipkin我们可以做分布式服务调用的追踪。之前自己曾经搭建过基于Jaeger和OpenTracing的分布式调用服务十分繁琐。并且要想使用tracing对应用代码的侵入必不可少。我们安装一下Zipkin Addon# kubectl apply -f zipkin.yamldeployment zipkin createdservice zipkin created# kubectl get svc -n istio-systemNAME CLUSTER-IP EXTERNAL-IP PORT(S) AGEzipkin 10.105.7.219 none 9411/TCP 1h我们访问以下Zikpin的UI通过浏览器打开http://{zipkinserviceip}:9411。接下来我们向Service Mesh注入一些流量然后在Zipkin首页的“服务名”下拉框中选择”svcb”查找跟踪情况我们看到在没有对svcasvcb做任何修改的情况下我们依然可以在Zipkin中找到svcb相关的调用。点击其中一个trace可以查看细节
说明Svcb到外部服务的通信被打通了！
发布时间：2026/7/2 5:06:38
我们经常有这样的需求当svcb运行一段时间后svcb添加了新feature版本要升级到v0.2了这时我们会部署svcb:v0.2并将流量逐步切到v0.2上。我们先来部署一下svcb:v0.2// svcb-v0.2.yaml apiVersion: extensions/v1beta1 kind: Deployment metadata: name: svcb-v0.2 spec: replicas: 1 template: metadata: labels: app: svcb version: v0.2 spec: containers: - name: svcb image: docker.io/bigwhite/istio-demo-svcb:v0.2 imagePullPolicy: Always我们可以看到服务名不变但版本的label变成了v0.2我们来执行这次部署# kubectl apply -f (istioctl kube-inject -f svcb-v0.2.yaml) deployment svcb-v0.2 created # kubectl get pods NAME READY STATUS RESTARTS AGE svca-1997590752-pq9zg 2/2 Running 0 9h svcb-2008973769-gq0lh 2/2 Running 0 9h svcb-v0.2-3233505404-0g55w 2/2 Running 0 1m svcb服务下又增加了一个endpoint: # kubectl describe svc/svcb .... ... Selector: appsvcb Type: ClusterIP IP: 10.105.119.194 Port: unset 80/TCP Endpoints: 10.40.0.28:8080,10.46.0.12:8080 ... ...此时如果按照Kubernetes的调度方式v0.1和v0.2版本的两个svcb pod应该1:1均衡地承载流量。为了方便查看流量分布我们将每个版本的svcb的pod副本数量都扩展为2个replicas: 2这样Service Mesh中一共会有4个 svcb endpoints。通过curl访问svca注入流量后我们发现流量都集中在一个svcb:v0.2的pod上并且长时间没有变化。我们通过下面的route rule规则来尝试将流量在svcb:v0.1和svcb:v0.2之间1:1均衡// route-rules-svcb-v0.2-50.yaml apiVersion: config.istio.io/v1alpha2 kind: RouteRule metadata: name: route-rules-svcb spec: destination: name: svcb precedence: 1 route: - labels: version: v0.1 weight: 50 - labels: version: v0.2 weight: 50 # istioctl create -f route-rules-svcb-v0.2-50.yaml Created config route-rule/default/route-rules-svcb at revision 30080638按照Istio文档中的说法这个规则的生效需要一些时间。之后我们注入流量发现流量切换到svcb:v0.1的一个Pod上去了并且很长一段时间不曾变化未均衡到svcb:v0.2上去。我们更新一下route rule将流量全部切到svcb:v0.2上去//route-rules-svcb-v0.2-100.yaml apiVersion: config.istio.io/v1alpha2 kind: RouteRule metadata: name: route-rules-svcb spec: destination: name: svcb precedence: 1 route: - labels: version: v0.2 weight: 100 # istioctl replace -f route-rules-svcb-v0.2-100.yaml Updated config route-rule/default/route-rules-svcb to revision 30082944我们用Istio的replace命令更新了规则route-rules-svcb。更新后再次注入流量这回流量重新集中在svcb:v0.2的一个Pod上了再过一段时间另外一个svcb:v0.2的pod上才有了一些流量。但svcb:v0.1上不再有流量这个切换是成功的。在Kubernetes的Service的负载均衡中Kubernetes就利用了iptables的概率转发random –probability 0.5因此这种流量均衡并非是精确的只有在长时间大量流量经过后才能看到流量的分布与设定的权重是相似的可能Istio也是如此这里仅是入门就不深入挖掘了。当然Istio在路由规则设施方面的“能耐”远不止上面例子中所展示的那样如果要悉数列出那本文的长度可是要爆掉了。有兴趣的朋友可以去翻看官方文档。五、插件安装Istio的强大微服务治理能力还体现在其集成了Grafana、Prometheus、ServiceGraph、Zipkin等Addons应用程序无需做任何改动就可以具有数据收集、度量与可视化的监控能力、服务的分布式跟踪能力等。我们可以在Istio的安装包中找到这些Addons的安装文件我们来逐一试试。1、Prometheus Grafana我们先来安装一下Prometheus和Grafana插件位于istio-0.4.0/install/kubernetes/addon下面# kubectl apply -f prometheus.yaml configmap prometheus created service prometheus created deployment prometheus created # kubectl apply -f grafana.yaml service grafana created deployment grafana created # kubectl get pods -n istio-system NAME READY STATUS RESTARTS AGE grafana-3617079618-zpglx 1/1 Running 0 5m prometheus-168775884-ppfxr 1/1 Running 0 5m ... ... # kubectl get svc -n istio-system NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE grafana 10.105.21.25 none 3000/TCP 16m prometheus 10.103.160.37 none 9090/TCP 16m ... ...浏览器中输入Prometheus的服务地址http://10.103.160.37:9090访问Prometheus点击菜单项status - targets查看各个target的状态是否正常如果像上图所示那样各个target都是up状态那就说明Istio运行时OK的。否则请参考istio troubleshooting中的内容对Istio逐一进行排查尤其是istio-mesh这个Target在istio-0.3.0kubernetes 1.7.3的环境中就是Down的状态。浏览器输入grafana的服务地址切换到Istio Dashboard并向Istio Service Mesh注入流量我们会看到仪表盘变化如下2、ServiceGraphServiceGraph插件是用来查看服务调用关系的我们来创建一下该组件# kubectl apply -f servicegraph.yamldeployment servicegraph createdservice servicegraph created# kubectl get svc -n istio-systemNAME CLUSTER-IP EXTERNAL-IP PORT(S) AGEservicegraph 10.108.245.21 none 8088/TCP 52s... ...创建成功后向Service Mesh网络注入流量然后访问ServiceGraphhttp://{servicegraph_ip}:8088/dotviz在我的环境里我看到的图示如下调用关系似乎有些乱难道是我在程序使用的调用方法不够标准:(3、ZipkinIstio集成了Zipkin利用Zipkin我们可以做分布式服务调用的追踪。之前自己曾经搭建过基于Jaeger和OpenTracing的分布式调用服务十分繁琐。并且要想使用tracing对应用代码的侵入必不可少。我们安装一下Zipkin Addon# kubectl apply -f zipkin.yamldeployment zipkin createdservice zipkin created# kubectl get svc -n istio-systemNAME CLUSTER-IP EXTERNAL-IP PORT(S) AGEzipkin 10.105.7.219 none 9411/TCP 1h我们访问以下Zikpin的UI通过浏览器打开http://{zipkinserviceip}:9411。接下来我们向Service Mesh注入一些流量然后在Zipkin首页的“服务名”下拉框中选择”svcb”查找跟踪情况我们看到在没有对svcasvcb做任何修改的情况下我们依然可以在Zipkin中找到svcb相关的调用。点击其中一个trace可以查看细节
![终极指南：如何使用Awesome-CGM数据集快速开始糖尿病研究 [特殊字符]](http://pic.xiahunao.cn/yaotu/终极指南：如何使用Awesome-CGM数据集快速开始糖尿病研究 [特殊字符])
![华为OD机试2025C卷-字符串变换最小次数[100分]（ Java _ Python3 _ C++ _ C语言 _ JsNode _ Go）实现100%通过率](http://pic.xiahunao.cn/yaotu/华为OD机试2025C卷-字符串变换最小次数[100分]（ Java _ Python3 _ C++ _ C语言 _ JsNode _ Go）实现100%通过率)
![华为OD机试2025C卷-内存资源分配[100分]（ Java _ Python3 _ C++ _ C语言 _ JsNode _ Go）实现100%通过率](http://pic.xiahunao.cn/yaotu/华为OD机试2025C卷-内存资源分配[100分]（ Java _ Python3 _ C++ _ C语言 _ JsNode _ Go）实现100%通过率)
