服务网格GRPC协议多种编程语言实践.3.GRPC协议示例的容器实践

本文涉及的产品
容器服务 Serverless 版 ACK Serverless,317元额度 多规格
容器服务 Serverless 版 ACK Serverless,952元额度 多规格
容器镜像服务 ACR,镜像仓库100个 不限时长
简介: 本篇使用上一篇分发的镜像,在阿里云容器服务(ACK)上部署。4个版本的client通过调用变量`GRPC_SERVER`定义的服务`grpc-server-svc.grpc-best.svc.cluster.local`,均匀地路由到4个版本的server上。与此同时,我们通过配置`istio-ingressgateway`的`Gateway`可以将外部请求按负载均衡策略路由到4个版本的grpc server上。

1 容器资源

本篇使用上一篇分发的镜像,在阿里云容器服务(ACK)上部署。

4个版本的client通过调用变量GRPC_SERVER定义的服务grpc-server-svc.grpc-best.svc.cluster.local,均匀地路由到4个版本的server上。与此同时,我们通过配置istio-ingressgatewayGateway可以将外部请求按负载均衡策略路由到4个版本的grpc server上。

示例完整的拓扑如下图所示。
grpc_kube.png

grpc-server-svc

本系列的示例只有一个命名为grpc-server-svc的grpc类型的Service。grpc类型的服务,spec.ports.name的值需要以grpc开头。

apiVersion: v1
kind: Service
metadata:
  namespace: grpc-best
  name: grpc-server-svc
  labels:
    app: grpc-server-svc
spec:
  ports:
    - port: 9996
      name: grpc-port
  selector:
    app: grpc-server-deploy

server deployment

完整的deployment详见kube/deployment目录,这里以node server的deployment文件grpc-server-node.yaml为例,对服务端进行说明。

apiVersion: apps/v1
kind: Deployment
metadata:
  namespace: grpc-best
  name: grpc-server-node
  labels:
    app: grpc-server-deploy
    version: v3
spec:
  replicas: 1
  selector:
    matchLabels:
      app: grpc-server-deploy
      version: v3
  template:
    metadata:
      labels:
        app: grpc-server-deploy
        version: v3
    spec:
      serviceAccountName: grpc-best-sa
      containers:
        - name: grpc-server-deploy
          image: registry.cn-beijing.aliyuncs.com/asm_repo/grpc_server_node:1.0.0
          imagePullPolicy: Always
          ports:
            - containerPort: 9996
              name: grpc-port

服务端的4个deployment都需要定义app标签的值为grpc-server-deploy,以匹配grpc-server-svcselector。每种语言的version标签要各部相同。

client deployment

客户端和服务端有两处不同。

  • 服务端启动后会持续运行,而客户端完成请求后就会结束进程,因此,需要实现一种死循环的方式保持客户端容器不自己退出。
  • 需要定义变量GRPC_SERVER的值,在客户端容器启动时传递给grpc client。

这里以go client的deployment文件grpc-client-go.yaml为例,对客户端进行说明。

apiVersion: apps/v1
kind: Deployment
metadata:
  namespace: grpc-best
  name: grpc-client-go
  labels:
    app: grpc-client-go
spec:
  replicas: 1
  selector:
    matchLabels:
      app: grpc-client-go
  template:
    metadata:
      labels:
        app: grpc-client-go
    spec:
      serviceAccountName: grpc-best-sa
      containers:
        - name: grpc-client-go
          image: registry.cn-beijing.aliyuncs.com/asm_repo/grpc_client_go:1.0.0
          command: ["/bin/sleep", "3650d"]
          env:
            - name: GRPC_SERVER
              value: "grpc-server-svc.grpc-best.svc.cluster.local"
          imagePullPolicy: Always

其中,command: ["/bin/sleep", "3650d"]是定义grpc_client_go启动后执行的命令,通过长久地sleep的方式保持客户端容器运行。env中定义了GRPC_SERVER变量,值为grpc-server-svc.grpc-best.svc.cluster.local

2 部署

首先在ACK实例中创建名称为grpc-best的命名空间,然后为该命名空间启用自动注入sidecar。

alias k="kubectl --kubeconfig $USER_CONFIG"
k create ns grpc-best
k label ns grpc-best istio-injection=enabled

执行如下命令部署ServiceAccount、Service,及8个Deployment。

k apply -f grpc-sa.yaml
k apply -f grpc-svc.yaml
k apply -f deployment/grpc-server-java.yaml
k apply -f deployment/grpc-server-python.yaml
k apply -f deployment/grpc-server-go.yaml
k apply -f deployment/grpc-server-node.yaml
k apply -f deployment/grpc-client-java.yaml
k apply -f deployment/grpc-client-python.yaml
k apply -f deployment/grpc-client-go.yaml
k apply -f deployment/grpc-client-node.yaml

3 从POD侧验证

kube验证包括两侧,一侧是从client容器请求grpc server service,另一侧是从本地请求ingressgateway。这里演示从client容器请求4个server容器的过程。

首先通过如下命令,获取4个client容器的名称。

client_java_pod=$(k get pod -l app=grpc-client-java -n grpc-best -o jsonpath={.items..metadata.name})
client_go_pod=$(k get pod -l app=grpc-client-go -n grpc-best -o jsonpath={.items..metadata.name})
client_node_pod=$(k get pod -l app=grpc-client-node -n grpc-best -o jsonpath={.items..metadata.name})
client_python_pod=$(k get pod -l app=grpc-client-python -n grpc-best -o jsonpath={.items..metadata.name})

然后通过如下命令,在client容器中执行对grpc server service的请求。

k exec "$client_java_pod" -c grpc-client-java -n grpc-best -- java -jar /grpc-client.jar

k exec "$client_go_pod" -c grpc-client-go -n grpc-best -- ./grpc-client

k exec "$client_node_pod" -c grpc-client-node -n grpc-best -- node proto_client.js
  
k exec "$client_python_pod" -c grpc-client-python -n grpc-best -- sh /grpc-client/start_client.sh

最后我们以node client为例,通过一个循环,验证grpc server service的负载均衡。

for ((i = 1; i <= 100; i++)); do
  k exec "$client_node_pod" -c grpc-client-node -n grpc-best -- node kube_client.js > kube_result
done
sort kube_result | grep -v "^[[:space:]]*$" | uniq -c | sort -nrk1

输出如下,均匀路由4个版本的服务,符合预期。

  26 Talk:PYTHON
  25 Talk:NODEJS
  25 Talk:GOLANG
  24 Talk:JAVA

4 从本地验证

接下来,我们再来验证从本地请求istio-ingressgateway。进入服务网格(ASM)实例,定义GRPC服务的Gateway,将如下内容复制到页面。

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  namespace: grpc-best
  name: grpc-gateway
spec:
  selector:
    istio: ingressgateway
  servers:
    - port:
        number: 9996
        name: grpc
        protocol: GRPC
      hosts:
        - "*"

使用如下命令获取istio-ingressgateway的IP。

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

使用如下命令验证grpc server service的负载均衡。

docker run -d --name grpc_client_node -e GRPC_SERVER="${INGRESS_IP}" registry.cn-beijing.aliyuncs.com/asm_repo/grpc_client_node:1.0.0 /bin/sleep 3650d
client_node_container=$(docker ps -q)

docker exec -e GRPC_SERVER="${INGRESS_IP}" -it "$client_node_container" node kube_client.js

for ((i = 1; i <= 100; i++)); do
  docker exec -e GRPC_SERVER="${INGRESS_IP}" -it "$client_node_container" node kube_client.js >> kube_result
done
sort kube_result | grep -v "^[[:space:]]*$" | uniq -c | sort -nrk1
目录
相关文章
|
4月前
|
机器学习/深度学习 Kubernetes Cloud Native
云原生技术演进之旅:从容器到服务网格
在云计算的浪潮中,云原生技术以其独特的灵活性和可扩展性引领了新的技术革命。本文将深入探讨云原生技术的发展脉络,从容器技术的突破,到Kubernetes的集群管理,再到服务网格的微服务通信解决方案,揭示云原生如何不断适应和塑造现代应用的需求。文章将通过数据支撑和案例分析,展示云原生技术在实际应用中的优势和挑战,并预测其未来的发展趋势。
54 1
|
1月前
|
负载均衡 Cloud Native 安全
云原生时代的开发者指南:从容器到服务网格
【9月更文挑战第32天】在云原生技术日益成为企业数字化转型的核心力量之际,了解其背后的理念与实践对于开发者而言至关重要。本文旨在通过浅显易懂的语言,为读者揭开云原生技术的神秘面纱,从容器化的基础谈起,逐步深入到服务网格的高级应用,带领开发者们在云原生的海洋中航行。
41 1
|
2月前
|
Cloud Native 持续交付 Docker
云原生技术入门与实践:Docker容器化部署示例
【9月更文挑战第25天】在数字化转型的浪潮下,云原生技术成为推动企业创新的重要力量。本文旨在通过浅显易懂的语言,为初学者揭示云原生技术的核心概念及其应用价值。我们将以Docker容器为例,逐步引导读者了解如何将应用程序容器化,并在云端高效运行。这不仅是对技术趋势的跟随,更是对资源利用和开发效率提升的探索。
61 4
|
3月前
|
运维 负载均衡 监控
探索微服务架构下的服务网格(Service Mesh)实践之路
【8月更文挑战第30天】 在当今日益复杂的分布式系统中,微服务架构已成为众多企业解决系统扩展与维护难题的利器。然而,随着服务的不断增多和网络交互的复杂性提升,传统的微服务管理方式开始显得力不从心。服务网格(Service Mesh)作为一种新兴的解决方案,旨在通过提供应用层的网络基础设施来简化服务间通讯,并增强系统的可观察性和安全性。本文将分享我在采用服务网格技术过程中的经验与思考,探讨如何在现代云原生环境中有效地实施服务网格,以及它给开发和运维带来的变革。
|
3月前
|
Cloud Native 云计算 开发者
云原生技术实践:Docker容器化部署示例
【8月更文挑战第31天】本文通过深入浅出的方式,介绍了如何在云计算时代利用Docker容器技术实现应用的快速部署和高效管理。文章不仅解释了Docker的基本概念和优势,还提供了详细的操作步骤和代码示例,帮助初学者轻松入门。让我们一起探索云原生的世界,解锁应用部署的新姿势!
|
4月前
|
敏捷开发 运维 Cloud Native
云原生架构的演进之路:从容器化到服务网格
在数字化转型的浪潮中,云原生技术以其灵活性、可扩展性和弹性成为企业IT架构的新宠。本文将探讨云原生技术的演进路径,特别是容器化技术和服务网格的发展,以及它们如何共同推动现代应用的开发和部署。通过分析实际案例,我们揭示了云原生技术如何助力企业实现敏捷开发和高效运维,同时指出了未来云原生技术的发展趋势。
|
3月前
|
运维 Kubernetes Cloud Native
云原生技术演进:从容器到服务网格
【8月更文挑战第14天】云原生技术的迅速发展,不仅重塑了软件开发与部署的流程,也重新定义了企业IT架构的未来。本文将深入探讨容器技术的兴起、Kubernetes成为事实上的工业标准,以及服务网格的出现如何进一步优化微服务间的通信。通过分析这些技术的发展脉络,我们将揭示它们是如何共同促进现代云原生生态系统的成熟和扩展,同时指出这些技术面临的挑战和未来的发展方向。
|
4月前
|
Kubernetes Cloud Native 持续交付
云原生架构的核心组成部分通常包括容器化(如Docker)、容器编排(如Kubernetes)、微服务架构、服务网格、持续集成/持续部署(CI/CD)、自动化运维(如Prometheus监控和Grafana可视化)等。
云原生架构的核心组成部分通常包括容器化(如Docker)、容器编排(如Kubernetes)、微服务架构、服务网格、持续集成/持续部署(CI/CD)、自动化运维(如Prometheus监控和Grafana可视化)等。
|
3月前
|
运维 Cloud Native 持续交付
云原生之旅:从容器化到服务网格的探索
在数字化浪潮中,云原生技术如同一艘扬帆起航的船,带领企业驶向灵活、高效的未来。本文将带你领略云原生的魅力,从容器化技术的基石铺就,到微服务架构的精细打磨,再到服务网格的智能导航,我们一同探索云原生如何重塑软件开发和运维的生态。你将看到,随着技术的深入,云原生不仅仅是一种技术选择,更是一场关于创新和变革的航行。
37 0
|
4月前
|
Kubernetes Cloud Native Docker
云原生架构的演进:从容器化到服务网格
本文深入探讨了云原生技术从最初的容器化技术,如Docker和Kubernetes,发展到现代的服务网格架构,如Istio。文章将通过分析云原生技术的演进路径,揭示其在处理微服务复杂性、流量管理和安全性方面的优势。我们将通过具体案例展示服务网格如何优化分布式系统的性能,并预测未来云原生技术的发展趋势。
48 2
下一篇
无影云桌面