前言

rust-grpc-proxy 目前功能基本完善。是時(shí)候上環(huán)境開始應(yīng)用了。
之前考慮是gateway模式或者sidecar模式。
思考良久之后，覺得兩種模式都有使用場景，那就都支持。本次就帶來sidecar模式的食用姿勢。

原理

微服務(wù)幾乎都是在k8s上搭建的。而rust-grpc-proxy作為無侵入的grpc轉(zhuǎn)http代理，當(dāng)然也要實(shí)現(xiàn)自動(dòng)部署在k8s上。所以我們的目標(biāo)如下

• rust-grpc-proxy能夠作為sidecar運(yùn)行在各個(gè)pod中
• 能夠根據(jù)標(biāo)簽實(shí)現(xiàn)自動(dòng)注入，基于k8s的webhook能力

sidecar

為什么會(huì)優(yōu)先推薦sidecar(邊車模式)，這是因?yàn)槟軌虮苊庠诩耗Ｊ较?#xff0c;rust-grpc-proxy受某個(gè)節(jié)點(diǎn)的拖累，從而導(dǎo)致整個(gè)代理的低效，甚至是不可用。
rust-grpc-proxy 鏡像目前最新版只有20MB，拉起非常快，并且會(huì)持續(xù)掃描主容器，直到超時(shí)或者代理成功。
因?yàn)槭鞘褂胷ust開發(fā)的，你可以大膽且放心的使用，資源消耗很小，安全性也有足夠保證。
鏡像也能夠單獨(dú)拿出來作為pod使用，可以通過配置文件，或者環(huán)境變量指定配置，具體參考上一篇博文的內(nèi)容。

webhook

k8s的擴(kuò)展功能里，允許用戶在準(zhǔn)入階段(圖中3)修改和認(rèn)證請求，所以我們可以用MutatingAdmissionWebhook實(shí)現(xiàn)代理自動(dòng)注入。
更多參考：https://v1-23.docs.kubernetes.io/zh/docs/reference/access-authn-authz/extensible-admission-controllers/

實(shí)現(xiàn)

安裝k8s

教程很多了，這里就不寫了
我的 k8s 版本是 1.24.9
之后的操作都在命名空間：qa

設(shè)置webhook

首先下載代碼：git地址：https://github.com/woshihaoren4/grpc-proxy
進(jìn)入 deploy目錄

//建證書
./webhook-create-signed-cert.sh //生成 mutating_admission.yaml
cat ./webhook_mutating.yaml | ./webhook-patch-ca-bundle.sh > /tmp/mutating_admission.yaml//添加權(quán)限
kubectl apply -f webhook_rbac.yaml//生成service
kubectl apply -f webhook_service.yaml//生成deployment
kubectl apply -f webhook_deployment.yaml//生成admission
kubectl apply -f /tmp/mutating_admission.yaml 

說明1：webhook的鏡像是：registry.cn-hangzhou.aliyuncs.com/wshr/wd:sidecar-v4
代碼位置：https://github.com/woshihaoren4/grpc-proxy/tree/main/webhook

說明2：這個(gè)webhook的作用是 在檢測到創(chuàng)建或者更新pod時(shí)，如果存在 rustGrpcProxyEnable 標(biāo)簽，則自動(dòng)將rust-grpc-proxy注入到pod配置中，并將這個(gè)標(biāo)簽的value 作為目標(biāo)服務(wù)的端口 從而進(jìn)行代理。

說明3：如果你用的rancher，需要編輯集群的yaml文件，添加如下配置. 否則創(chuàng)建證書請求一直是Approved 而不Issued

services:kube-controller: extra_args: cluster-signing-cert-file: "/etc/kubernetes/ssl/kube-ca.pem"cluster-signing-key-file: "/etc/kubernetes/ssl/kube-ca-key.pem"

說明4：建議在webhook_mutating.yaml文件中開啟這個(gè)選項(xiàng)namespaceSelector讓webhook只在特定命名空間中生效，如果開啟了這個(gè)，則需要設(shè)置命名空間標(biāo)簽

kubectl label namespace <namespace> <key>=enabled

使用

創(chuàng)建一個(gè)帶標(biāo)簽的pod
這里用到的鏡像就是之前的echo測試程序打包成的

kubectl apply -f echo_deployment.yaml

重點(diǎn)內(nèi)容是這個(gè)標(biāo)簽：rustGrpcProxyEnable: "1234" 只有存在這個(gè)標(biāo)簽才會(huì)添加代理。1234 是echo服務(wù)的grpc端口

spec:template:labels:app: echo-serverrustGrpcProxyEnable: "1234"

等待一段時(shí)間后，可以看到pod已經(jīng)創(chuàng)建成功。想要測試我們還需要開放一個(gè)外網(wǎng)端口

 kubectl apply -f ./echo_service.yaml

echo_service.yaml 中的內(nèi)容是創(chuàng)建一個(gè)node端口的service，并且映射到echo-server 服務(wù)上。大體如下配置

spec:ports:- name: httpnodePort: 30000port: 6789protocol: TCPtargetPort: 6789selector:app: echo-server

設(shè)置成功后，發(fā)起一個(gè)測試命令

• <NODE_HOST> 替換為節(jié)點(diǎn)地址

curl --location --request GET 'http://<NODE_HOST>:30000/api/v1/echo/hello/get?query=666' \
--header 'echo-hello: world' \
--header 'MD-hello: world'

然后就可以看到返回內(nèi)容{"response": "GET [test-server]---> request=hello query=666"} 表明測試成功

尾語

本文涉及了很多非rust-grpc-proxy 相關(guān)的內(nèi)容，需要和代碼一起看。但容器化 微服務(wù)，云原生都是大勢所趨，rust-grpc-proxy本意就是基于云原生設(shè)計(jì)的。