非容器应用与K8s工作负载的服务网格化实践-5 基于ASM的POD和VM混合流量转移实践

本文涉及的产品
容器镜像服务 ACR,镜像仓库100个 不限时长
简介: 本系列的第一篇展示了WorkloadEntry带来的VM与POD同等负载能力。第二、三篇展示了ASM VM PROXY带来的VM流量转移能力。本篇将结合这两种能力,完整地展示ASM支持非容器应用网格化的流量管理能力。由于篇幅所限,安全相关能力不做展示,但网格化后VM中的应用间、及与POD互访都具备了请求认证和来源认证的能力,再结合RBAC可以完整实现认证和授权。

本系列的第一篇展示了WorkloadEntry带来的VM与POD同等负载能力。第二、三篇展示了ASM VM PROXY带来的VM流量转移能力。本篇将结合这两种能力,完整地展示ASM支持非容器应用网格化的流量管理能力。由于篇幅所限,安全相关能力不做展示,但网格化后VM中的应用间、及与POD互访都具备了请求认证和来源认证的能力,再结合RBAC可以完整实现认证和授权。

1 搭建实验环境

本篇实验将完整展示端到端的全链路POD和VM混合流量转移。示例需要一个ack集群和2个ecs节点。在ack集群中,包含hello1/hello2/hello3 各1个版本为en的POD,2个ecs节点各启动一个hello2 app,每个app对应一个版本(fr/es)的hello容器。

请求从hello1 POD到hello2 service(endpoints包含ack中的一个hello2 POD和ecs中的2个hello2 app),再hello2到hello3 POD。在此基础上,我们希望路由到hello2 en/fr/es的流量比例为:30%:60%:10%。

5-1-asm-vm-best-practice.png

示例(http_hybrid_demo)包含如下元素:

  • hello1/hello2/hello3 deployment(镜像http_springboot_v1)
  • hello2 docker containers(镜像http_springboot_v1/http_springboot_v2/http_springboot_v3)
  • 入口网关:istio-ingressgateway
  • 入口流量配置:gateway/virtualservice
  • hello1流量配置:hello1 service/hello1 virtualservice/hello1 destinationrule
  • hello2流量配置:hello2 service/hello2 virtualservice/hello2 destinationrule
  • hello3流量配置:hello3 service/hello3 virtualservice/hello3 destinationrule
  • hello2 serviceentry/hello2 workloadentry

hello2 POD和VM

本篇实验的核心是将POD和VM作为同一Service下的负载。通过配置VirtualService流量比例,让上游服务按照配比路由到POD和VM。

首先来看hello2的deployment,示意如下。

  • 标签app: hello2-deploy这个配置需要和余文的workloadentry中的一致
  • 标签version: v1和镜像http_springboot_v1决定了这是hello2 service中的版本1的endpoint
apiVersion: apps/v1
kind: Deployment
metadata:
  namespace: hybrid-hello
  name: hello2-deploy-v1
  labels:
    app: hello2-deploy
    version: v1
spec:
...
    spec:
      containers:
        - name: hello-v1-deploy
          image: registry.cn-beijing.aliyuncs.com/asm_repo/http_springboot_v1:1.0.1
          env:
            - name: HTTP_HELLO_BACKEND
              value: "hello3-svc.hybrid-hello.svc.cluster.local"
...

紧接着,我们来看相应的hello2 v2和v3的实例。在VM中按如下命令启动Docker Container:

sh vm/ssh2.sh

docker run \
--rm \
--network host \
--name http_v2 \
-e HTTP_HELLO_BACKEND=hello3-svc.hybrid-hello.svc.cluster.local \
registry.cn-beijing.aliyuncs.com/asm_repo/http_springboot_v2:1.0.1
sh vm/ssh3.sh

docker run \
--rm \
--network host \
--name http_v3 \
-e HTTP_HELLO_BACKEND=hello3-svc.hybrid-hello.svc.cluster.local \
registry.cn-beijing.aliyuncs.com/asm_repo/http_springboot_v3:1.0.1

然后,我们通过如下命令创建WorkloadEntry,将VM中的Docker Containers加入网格。

aliyun servicemesh AddVmAppToMesh \
--ServiceMeshId "$MESH_ID" \
--Namespace hybrid-hello \
--ServiceName hello2-svc \
--Ips "$VM_PRI_2","$VM_PRI_3" \
--Ports http:8001 \
--Labels app=hello2-deploy \
--Force true

这里定义的标签app=hello2-deploy与前文中hello2 deployment中定义的一致。

2 互访验证

执行如下脚本部署上述及其他CRD,完成实验环境的基本搭建。脚本在http_hybrid_demo/asm路径下,不再冗述。

sh asm/ack.deploy.sh
sh asm/asm.deploy.sh
sh vm/dns.fake.sh

本篇的互访验证较之前两篇,须重点关注从hello1到hello2各endpoints的情况。因为这是混合流量的关键点。

首先从hello1 POD出发,直接访问hello2的3个endpoints:

echo "1 Test access vm ip directly"

echo "curl to POD $hello2_ip"
k exec "$hello2_pod" -c hello-v1-deploy -n hybrid-hello -- curl -s localhost:8001/hello/eric
echo
VMS=("$VM_PRI_2" "$VM_PRI_3")
for vm in "${VMS[@]}"; do
  echo "curl to VM $vm"
  k exec "$hello1_pod" -c hello-v1-deploy -n hybrid-hello -- \
    curl -s "$vm":8001/hello/eric
  echo
done

期待的结果如下,证明hello1 POD到hello2 endpoints之间的链路是通的。

curl to POD 172.18.0.194
Hello eric(172.18.0.194)<-Hello eric(172.18.0.254)
curl to VM 192.168.0.171
Bonjour eric(192.168.0.171)<-Hello eric(172.18.0.254)
curl to VM 192.168.0.172
Hola eric(192.168.0.172)<-Hello eric(172.18.0.254)

然后我们在hello1 POD中请求hello2 service,验证依次路由到这3个endpoints:

for i in {1..6}; do
  k exec "$hello1_pod" -c hello-v1-deploy -n hybrid-hello -- \
    curl -s hello2-svc.hybrid-hello.svc.cluster.local:8001/hello/eric
  echo
done

期待的结果如下,证明3个hello2的各endpoints可以被hello2 service成功发现。这一步是最关键的。

因为hello1可以成功访问到hello2 service后面的3个endpoints,意味着作为同一个service的POD和VM混合流量管理基本验证通过。

Hello eric(172.18.0.194)<-Hello eric(172.18.0.254)
Hola eric(192.168.0.172)<-Hello eric(172.18.0.254)
Bonjour eric(192.168.0.171)<-Hello eric(172.18.0.254)

最后我们向hello1 service发起请求,确认3个service链路的情况:

for i in {1..6}; do
  resp=$(k exec "$hello1_pod" -c hello-v1-deploy -n hybrid-hello -- curl -s hello1-svc.hybrid-hello.svc.cluster.local:8003/hello/eric)
  echo $i "$resp"
done

期待的结果如下,3个service的物理链路验证完毕。

1 Hello eric(172.18.1.8)<-Bonjour eric(192.168.0.171)<-Hello eric(172.18.0.254)
2 Hello eric(172.18.1.8)<-Hello eric(172.18.0.194)<-Hello eric(172.18.0.254)
3 Hello eric(172.18.1.8)<-Hola eric(192.168.0.172)<-Hello eric(172.18.0.254)

3 流量转移

接下来,我们部署hello2的virtualservice和destinationrule,验证混合POD和VM的流量转移。

流量配置

sh asm/asm_traffic_shift.sh

执行如下脚本验证流量配比的配置已经生效:

m get virtualservice -n hybrid-hello hello2-vs -o jsonpath={.spec.http[0].route}       

期待的结果如下:

[map[destination:map[host:hello2-svc subset:v1] weight:30] map[destination:map[host:hello2-svc subset:v2] weight:60] map[destination:map[host:hello2-svc subset:v3] weight:10]]

编辑workloadentry,增加version标签:

spec:
  address: 192.168.0.171
  labels:
    app: hello-workload
    version: v2
spec:
  address: 192.168.0.172
  labels:
    app: hello-workload
    version: v3

流量验证

sh asm/test_mesh.sh

hello1_pod=$(k get pod -l app=hello1-deploy -n hybrid-hello -o jsonpath={.items..metadata.name})

for i in {1..100}; do
  resp=$(k exec "$hello1_pod" -c hello-v1-deploy -n hybrid-hello -- curl -s hello1-svc.hybrid-hello.svc.cluster.local:8003/hello/eric)
  echo "$resp" >>test_traffic_shift_result
done

echo "expected 30%(Hello eric)-60%(Bonjour eric)-10%(Hola eric):"
sort test_traffic_shift_result | uniq -c | sort -nrk1

期待的结果如下:

expected 30%(Hello eric)-60%(Bonjour eric)-10%(Hola eric):
  54 Hello eric(172.18.1.8)<-Bonjour eric(192.168.0.171)<-Hello eric(172.18.0.254)
  34 Hello eric(172.18.1.8)<-Hello eric(172.18.0.194)<-Hello eric(172.18.0.254)
  12 Hello eric(172.18.1.8)<-Hola eric(192.168.0.172)<-Hello eric(172.18.0.254)

4 全链路

最后我们增加gateway进行端到端验证。执行asm_z.sh脚本增加配置:

sh asm/asm_z.sh

执行test_z.sh脚本进行全链路流量转义的验证。示意如下:

alias k="kubectl --kubeconfig $USER_CONFIG"
IP=$(k -n istio-system get service istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}')

for i in {1..100}; do
  resp=$(curl -s "$IP":8003/hello/asm)
  echo $i "$resp"
  if [[ -z $resp ]]; then
    echo "error in accessing loop, stop."
    rm -rf z_result
    exit
  fi
  echo "$resp" >>z_result
done

echo "expected 30%(Hello eric)-60%(Bonjour eric)-10%(Hola eric):"
sort z_result | uniq -c | sort -nrk1
expected 30%(Hello eric)-60%(Bonjour eric)-10%(Hola eric):
  61 Hello asm(172.18.0.245)<-Bonjour asm(192.168.0.170)<-Hello asm(172.18.0.247)
  28 Hello asm(172.18.0.245)<-Hello asm(172.18.0.246)<-Hello asm(172.18.0.247)
  11 Hello asm(172.18.0.245)<-Hola asm(192.168.0.172)<-Hello asm(172.18.0.247)

到此,POD和VM混合流量转移验证完毕。实验示例使用的是http协议,结合前一篇我们可以完成grpc协议的POD和VM混合流量转移的实践,不再冗述。

本篇示例完整演示了非容器应用网格化过程中最重要的场景。覆盖到从istio-ingressgateway到deployment、workloadentry等各种CRD的配置,完整地展示了POD和VM作为同一个service的混合流量的各技术点的配置。

接下来,我们将视角深入VM中,完成VM中应用的分组和同一分组的多个副本动态加入和删除的实现。

相关实践学习
深入解析Docker容器化技术
Docker是一个开源的应用容器引擎,让开发者可以打包他们的应用以及依赖包到一个可移植的容器中,然后发布到任何流行的Linux机器上,也可以实现虚拟化,容器是完全使用沙箱机制,相互之间不会有任何接口。Docker是世界领先的软件容器平台。开发人员利用Docker可以消除协作编码时“在我的机器上可正常工作”的问题。运维人员利用Docker可以在隔离容器中并行运行和管理应用,获得更好的计算密度。企业利用Docker可以构建敏捷的软件交付管道,以更快的速度、更高的安全性和可靠的信誉为Linux和Windows Server应用发布新功能。 在本套课程中,我们将全面的讲解Docker技术栈,从环境安装到容器、镜像操作以及生产环境如何部署开发的微服务应用。本课程由黑马程序员提供。 &nbsp; &nbsp; 相关的阿里云产品:容器服务 ACK 容器服务 Kubernetes 版(简称 ACK)提供高性能可伸缩的容器应用管理能力,支持企业级容器化应用的全生命周期管理。整合阿里云虚拟化、存储、网络和安全能力,打造云端最佳容器化应用运行环境。 了解产品详情: https://www.aliyun.com/product/kubernetes
目录
相关文章
|
7月前
|
存储 负载均衡 测试技术
ACK Gateway with Inference Extension:优化多机分布式大模型推理服务实践
本文介绍了如何利用阿里云容器服务ACK推出的ACK Gateway with Inference Extension组件,在Kubernetes环境中为多机分布式部署的LLM推理服务提供智能路由和负载均衡能力。文章以部署和优化QwQ-32B模型为例,详细展示了从环境准备到性能测试的完整实践过程。
|
8月前
|
存储 人工智能 Kubernetes
ACK Gateway with AI Extension:面向Kubernetes大模型推理的智能路由实践
本文介绍了如何利用阿里云容器服务ACK推出的ACK Gateway with AI Extension组件,在Kubernetes环境中为大语言模型(LLM)推理服务提供智能路由和负载均衡能力。文章以部署和优化QwQ-32B模型为例,详细展示了从环境准备到性能测试的完整实践过程。
|
Kubernetes 持续交付 开发者
探索并实践Kubernetes集群管理与自动化部署
探索并实践Kubernetes集群管理与自动化部署
447 93
|
8月前
|
存储 人工智能 物联网
ACK Gateway with AI Extension:大模型推理的模型灰度实践
本文介绍了如何使用 ACK Gateway with AI Extension 组件在云原生环境中实现大语言模型(LLM)推理服务的灰度发布和流量分发。该组件专为 LLM 推理场景设计,支持四层/七层流量路由,并提供基于模型服务器负载感知的智能负载均衡能力。通过自定义资源(CRD),如 InferencePool 和 InferenceModel,可以灵活配置推理服务的流量策略,包括模型灰度发布和流量镜像。
|
9月前
|
Kubernetes 监控 Serverless
基于阿里云Serverless Kubernetes(ASK)的无服务器架构设计与实践
无服务器架构(Serverless Architecture)在云原生技术中备受关注,开发者只需专注于业务逻辑,无需管理服务器。阿里云Serverless Kubernetes(ASK)是基于Kubernetes的托管服务,提供极致弹性和按需付费能力。本文深入探讨如何使用ASK设计和实现无服务器架构,涵盖事件驱动、自动扩展、无状态设计、监控与日志及成本优化等方面,并通过图片处理服务案例展示具体实践,帮助构建高效可靠的无服务器应用。
|
9月前
|
监控 Kubernetes Cloud Native
基于阿里云容器服务Kubernetes版(ACK)的微服务架构设计与实践
本文介绍了如何基于阿里云容器服务Kubernetes版(ACK)设计和实现微服务架构。首先概述了微服务架构的优势与挑战,如模块化、可扩展性及技术多样性。接着详细描述了ACK的核心功能,包括集群管理、应用管理、网络与安全、监控与日志等。在设计基于ACK的微服务架构时,需考虑服务拆分、通信、发现与负载均衡、配置管理、监控与日志以及CI/CD等方面。通过一个电商应用案例,展示了用户服务、商品服务、订单服务和支付服务的具体部署步骤。最后总结了ACK为微服务架构提供的强大支持,帮助应对各种挑战,构建高效可靠的云原生应用。
|
11月前
|
人工智能 运维 监控
阿里云ACK容器服务生产级可观测体系建设实践
本文整理自2024云栖大会冯诗淳(花名:行疾)的演讲,介绍了阿里云容器服务团队在生产级可观测体系建设方面的实践。冯诗淳详细阐述了容器化架构带来的挑战及解决方案,强调了可观测性对于构建稳健运维体系的重要性。文中提到,阿里云作为亚洲唯一蝉联全球领导者的容器管理平台,其可观测能力在多项关键评测中表现优异,支持AI、容器网络、存储等多个场景的高级容器可观测能力。此外,还介绍了阿里云容器服务在多云管理、成本优化等方面的最新进展,以及即将推出的ACK AI助手2.0,旨在通过智能引擎和专家诊断经验,简化异常数据查找,缩短故障响应时间。
阿里云ACK容器服务生产级可观测体系建设实践
|
9月前
|
监控 Cloud Native Java
基于阿里云容器服务(ACK)的微服务架构设计与实践
本文介绍如何利用阿里云容器服务Kubernetes版(ACK)构建高可用、可扩展的微服务架构。通过电商平台案例,展示基于Java(Spring Boot)、Docker、Nacos等技术的开发、容器化、部署流程,涵盖服务注册、API网关、监控日志及性能优化实践,帮助企业实现云原生转型。
|
10月前
|
开发框架 Prometheus 监控
使用阿里云服务网格高效管理LLM流量:(二)流量可观测
本文介绍如何使用阿里云服务网格提供的增强能力灵活、全面的观测集群中的LLM流量。
|
11月前
|
运维 Kubernetes 调度
阿里云容器服务 ACK One 分布式云容器企业落地实践
阿里云容器服务ACK提供强大的产品能力,支持弹性、调度、可观测、成本治理和安全合规。针对拥有IDC或三方资源的企业,ACK One分布式云容器平台能够有效解决资源管理、多云多集群管理及边缘计算等挑战,实现云上云下统一管理,提升业务效率与稳定性。

相关产品

  • 容器服务Kubernetes版
  • 推荐镜像

    更多
    下一篇
    oss云网关配置