自拍偷在线精品自拍偷,亚洲欧美中文日韩v在线观看不卡

使用 WebAssembly 對 Istio 進行擴展

開發(fā) 前端
對于 Istio 來說,WebAssembly 也使得 Istio 的擴展能力得到了極大的提升,Isstio 從 1.12 版本開始引入 WASM 擴展 Envoy,當(dāng)你需要添加 Envoy 或 Istio 不支持的自定義功能時,那么我們就可以使用 Wasm 插件,比如使用 Wasm 插件來添加自定義驗證、認證、日志或管理配額等等。

WebAssembly(簡稱為 Wasm)的誕生源自前端,是一種為了解決日益復(fù)雜的 Web 前端應(yīng)用以及有限的 JavaScript 性能而誕生的技術(shù)。它本身并不是一種語言,而是一種字節(jié)碼標(biāo)準。WASM 字節(jié)碼和機器碼非常接近,因此可以非??焖俚难b載運行。任何一種語言,都可以被編譯成 WASM 字節(jié)碼,然后在 WASM 虛擬機中執(zhí)行,理論上,所有語言,包括 JavaScript、C、C++、Rust、Go、Java 等都可以編譯成 WASM 字節(jié)碼并在 WASM 虛擬機中執(zhí)行。當(dāng)然不僅可以嵌入瀏覽器增強 Web 應(yīng)用,也可以應(yīng)用于其他的場景。

WebAssembly

WebAssembly 是為下列目標(biāo)而生的:

  • 快速、高效、可移植 —— 通過利用常見的硬件能力,WebAssembly 代碼在不同平臺上能夠以接近本地速度運行。
  • 可讀、可調(diào)試 —— WebAssembly 是一門低階語言,但是它也有一種人類可讀的文本格式,這允許通過手工來寫代碼,看代碼以及調(diào)試代碼。
  • 保持安全 —— WebAssembly 被限制運行在一個安全的沙箱執(zhí)行環(huán)境中。像其他網(wǎng)絡(luò)代碼一樣,它遵循瀏覽器的同源策略和授權(quán)策略。
  • 不破壞網(wǎng)絡(luò) —— WebAssembly 的設(shè)計原則是與其他網(wǎng)絡(luò)技術(shù)和諧共處并保持向后兼容。

Istio WASM

對于 Istio 來說,WebAssembly 也使得 Istio 的擴展能力得到了極大的提升,Isstio 從 1.12 版本開始引入 WASM 擴展 Envoy,當(dāng)你需要添加 Envoy 或 Istio 不支持的自定義功能時,那么我們就可以使用 Wasm 插件,比如使用 Wasm 插件來添加自定義驗證、認證、日志或管理配額等等。

Envoy 架構(gòu)

首先我們再回顧下 Envoy 的過濾機制,Envoy 通過過濾器來實現(xiàn)各種功能,比如路由、負載均衡、TLS、認證、日志、監(jiān)控等等。Envoy 提供了進程外架構(gòu)、支持 L3/L4 filter、HTTP L7 filter,過濾器包括偵聽器過濾器(Listener Filters)、網(wǎng)絡(luò)過濾器(Network Filters)、HTTP 過濾器(HTTP Filters)三種類型。

偵聽器過濾器

偵聽器過濾器在初始連接階段訪問原始數(shù)據(jù)并操作 L4 連接的元數(shù)據(jù)。例如,TLS 檢查器過濾器標(biāo)識連接是否經(jīng)過 TLS 加密,并解析與該連接關(guān)聯(lián)的 TLS 元數(shù)據(jù);HTTP Inspector Filter 檢測應(yīng)用協(xié)議是否是 HTTP,如果是的話,再進一步檢測 HTTP 協(xié)議類型 (HTTP/1.x or HTTP/2) ,這兩種過濾器解析到的元數(shù)據(jù)都可以和 FilterChainMatch 結(jié)合使用。

網(wǎng)絡(luò)過濾器

網(wǎng)絡(luò)過濾器訪問和操作 L4 連接上的原始數(shù)據(jù),即 TCP 數(shù)據(jù)包。例如,TCP 代理過濾器將客戶端連接數(shù)據(jù)路由到上游主機,它還可以生成連接統(tǒng)計數(shù)據(jù)。此外,MySQL proxy、Redis proxy、Dubbo proxy、Thrift proxy 等都屬于網(wǎng)絡(luò)過濾器。

HTTP 過濾器

HTTP 過濾器在 L7 上運行,由網(wǎng)絡(luò)過濾器(即 HTTP 連接管理器,HTTP Connection Manager)創(chuàng)建。這些過濾器用于訪問、操作 HTTP 請求和響應(yīng),例如,gRPC-JSON 轉(zhuǎn)碼器過濾器可以為 gRPC 后端提供一個 REST API,并將請求和響應(yīng)轉(zhuǎn)換為相應(yīng)的格式。此外,還包括 JWT、Router、RBAC 等多種過濾器。

WASM 插件

有很多編程語言都支持編寫 WASM 插件,比如 C、C++、Rust、Go、Java 等等,這里我們以 Go 語言為例來編寫一個簡單的 WASM 插件,編寫 WASM 的工具有 Solo.io 團隊的 wasme、tinygo等,目前應(yīng)用比較多是 tinygo,tinygo 支持的包可以查看 https://tinygo.org/docs/reference/lang-support/stdlib/ 進行了解。

TinyGo 是 Go 編程語言規(guī)范的一個編譯器實現(xiàn),為什么不使用官方的 Go 編譯器?目前官方編譯器無法生成可以在瀏覽器外部運行的 WASM 二進制文件,因此也無法生成與 Proxy-Wasm 兼容的二進制文件。

Proxy-Wasm

Proxy-Wasm是開源社區(qū)針對「網(wǎng)絡(luò)代理場景」設(shè)計的一套 ABI 規(guī)范,定義了網(wǎng)絡(luò)代理和運行在網(wǎng)絡(luò)代理內(nèi)部的 Wasm 虛擬機之間的接口,屬于當(dāng)前的事實規(guī)范。當(dāng)前支持該規(guī)范的網(wǎng)絡(luò)代理軟件包括 Envoy、MOSN 和 ATS(Apache Traffic Server),支持該規(guī)范的 Wasm 擴展 SDK 包括 C++、Rust 和 Go。采用該規(guī)范的好處在于能讓 Wasm 擴展程序在不同的網(wǎng)絡(luò)代理產(chǎn)品上運行,比如 MOSN 的 Wasm 擴展程序可以運行在 Envoy 上,而 Envoy 的 Wasm 擴展程序也可以運行在 MOSN 上。

Proxy-Wasm 規(guī)范定義了宿主機與 Wasm 擴展程序之間的交互細節(jié),包括 API 列表、函數(shù)調(diào)用規(guī)范以及數(shù)據(jù)傳輸規(guī)范這幾個方面。其中,API 列表包含了 L4/L7、property、metrics、日志等方面的擴展點,涵蓋了網(wǎng)絡(luò)代理場景下所需的大部分交互點。目前實現(xiàn)該規(guī)范的 Wasm 擴展 SDK 包括 AssemblyScript、C++、Rust 和 Go:

  • AssemblyScript SDK
  • C++ SDK
  • Go (TinyGo) SDK
  • Rust SDK

為了方便,我們也直接選擇已有的 proxy-wasm-go-sdk 這個 SDK 進行開發(fā)。這個 Proxy-Wasm Go SDK 是用于使用 Go 編程語言在 Proxy-Wasm ABI 規(guī)范之上擴展網(wǎng)絡(luò)代理(例如 Envoyproxy)的 SDK,有了這個 SDK,每個人都可以輕松地生成與 Proxy-Wasm 規(guī)范兼容的 Wasm 二進制文件,而無需了解低級且對于沒有專業(yè)知識的人來說難以理解的 Proxy-Wasm ABI 規(guī)范。

環(huán)境準備

首先安裝 tinygo 工具,前往 https://github.com/tinygo-org/tinygo/releases/tag/v0.30.0 下載對應(yīng)的版本,比如我們這里是 Linux 系統(tǒng),可以使用下面的命令進行安裝:

# linux
$ wget https://github.com/tinygo-org/tinygo/releases/download/v0.30.0/tinygo0.30.0.linux-amd64.tar.gz
$ tar -xvf tinygo0.30.0.linux-amd64.tar.gz
$ export PATH=$PATH:~/tinygo/bin
$ tinygo version
tinygo version 0.30.0 linux/amd64 (using go version go1.17 and LLVM version 16.0.1)

當(dāng)然我們也可以直接使用 docker 鏡像來進行編譯。

編寫插件

接下來我們就可以來編寫一個 WASM 插件,這里我們將包含一個 Envoy 過濾器,將來自 http://service/banana/X 的請求重定向到 http://service/status/X,這里我們使用 Go 語言來編寫插件,首先初始化項目:

$ mkdir wasm-go-demo && cd wasm-go-demo
$ go mod init github.com/cnych/wasm-go-demo
$ go get github.com/tetratelabs/proxy-wasm-go-sdk

然后創(chuàng)建 main.go 文件,內(nèi)容如下:

package main

import (
 "regexp"

 "github.com/tetratelabs/proxy-wasm-go-sdk/proxywasm"
 "github.com/tetratelabs/proxy-wasm-go-sdk/proxywasm/types"
)

type vmContext struct {
 // 嵌入默認的 VM 上下文,這樣我們就不需要重新實現(xiàn)所有方法
 types.DefaultVMContext
}

func (ctx *vmContext) NewPluginContext(contextID uint32) types.PluginContext {
 return &pluginContext{}
}

type pluginContext struct {
 // 嵌入默認的插件上下文,這樣我們就不需要重新實現(xiàn)所有方法
 types.DefaultPluginContext

 pattern     string
 replaceWith string
 configData  string // 保存插件的一些配置信息
}

// 注入額外的 Header
var additionalHeaders = map[string]string{
 "who-am-i":    "go-wasm-demo",
 "injected-by": "istio-api!",
 "site":        "youdianzhishi.com",
 "author":      "陽明",
 // 定義自定義的header,每個返回中都添加以上header
}

// NewHttpContext 為每個 HTTP 請求創(chuàng)建一個新的上下文。
func (ctx *pluginContext) NewHttpContext(contextID uint32) types.HttpContext {
 return &httpRegex{
  contextID:     contextID,
  pluginContext: ctx,
 }
}

// OnPluginStart 在插件被加載時調(diào)用。
func (ctx *pluginContext) OnPluginStart(pluginCfgSize int) types.OnPluginStartStatus {
 proxywasm.LogWarnf("regex/main.go OnPluginStart()")
 // 獲取插件配置
 data, err := proxywasm.GetPluginConfiguration()
 if data == nil {
  return types.OnPluginStartStatusOK
 }
 if err != nil {
  proxywasm.LogWarnf("failed read plug-in config: %v", err)
  return types.OnPluginStartStatusFailed
 }

 proxywasm.LogWarnf("read plug-in config: %s\n", string(data))

 // 插件啟動的時候讀取配置
 ctx.configData = string(data)
 ctx.pattern = "banana/([0-9]*)"
 ctx.replaceWith = "status/$1"

 return types.OnPluginStartStatusOK
}

// OnPluginDone 在插件被卸載時調(diào)用。
func (ctx *pluginContext) OnPluginDone() bool {
 proxywasm.LogWarnf("regex/main.go OnPluginDone()")
 return true
}

type httpRegex struct {
 // 嵌入默認的 HTTP 上下文,這樣我們就不需要重新實現(xiàn)所有方法
 types.DefaultHttpContext
 // contextID 是插件上下文的 ID,它是唯一的。
 contextID     uint32
 pluginContext *pluginContext
}

// OnHttpResponseHeaders 在收到 HTTP 響應(yīng)頭時調(diào)用。
func (ctx *httpRegex) OnHttpResponseHeaders(numHeaders int, endOfStream bool) types.Action {
 proxywasm.LogWarnf("%d httpRegex.OnHttpResponseHeaders(%d, %t)", ctx.contextID, numHeaders, endOfStream)

 // 添加 Header
 for k, v := range additionalHeaders {
  if err := proxywasm.AddHttpResponseHeader(k, v); err != nil {
   proxywasm.LogWarnf("failed to add response header %s: %v", k, err)
  }
 }

 //為了便于演示觀察,將配置信息也加到返回頭里
 proxywasm.AddHttpResponseHeader("configData", ctx.pluginContext.configData)
 return types.ActionContinue
}

// OnHttpRequestHeaders 在收到 HTTP 請求頭時調(diào)用。
func (ctx *httpRegex) OnHttpRequestHeaders(numHeaders int, endOfStream bool) types.Action {
 proxywasm.LogWarnf("%d httpRegex.OnHttpRequestHeaders(%d, %t)", ctx.contextID, numHeaders, endOfStream)

 re := regexp.MustCompile(ctx.pluginContext.pattern)
 replaceWith := ctx.pluginContext.replaceWith

 s, err := proxywasm.GetHttpRequestHeader(":path")
 if err != nil {
  proxywasm.LogWarnf("Could not get request header: %v", err)
 } else {
  result := re.ReplaceAllString(s, replaceWith)
  proxywasm.LogWarnf("path: %s, result: %s", s, result)

  err = proxywasm.ReplaceHttpRequestHeader(":path", result)
  if err != nil {
   proxywasm.LogWarnf("Could not set request header to %q: %v", result, err)
  }
 }

 return types.ActionContinue
}

func (ctx *httpRegex) OnHttpStreamDone() {
 proxywasm.LogWarnf("%d OnHttpStreamDone", ctx.contextID)
}

func main() {
 proxywasm.LogWarnf("regex/main.go main() REACHED")
 // 設(shè)置 VM 上下文,這樣我們就可以在插件啟動時讀取配置。
 proxywasm.SetVMContext(&vmContext{})
}

在上面的代碼中,我們主要關(guān)注 pluginContext 和 httpRegex 這兩個結(jié)構(gòu)體,其中 pluginContext 結(jié)構(gòu)體主要用于插件的初始化,而 httpRegex 結(jié)構(gòu)體主要用于處理 HTTP 請求,這里我們主要關(guān)注 OnHttpRequestHeaders 和 OnHttpResponseHeaders 這兩個方法,這兩個方法分別用于處理 HTTP 請求頭和響應(yīng)頭,我們在這兩個方法中添加了一些自定義的 Header,然后在 Istio 中就可以看到這些 Header 了。

部署插件

代碼編寫完成后,我們就可以使用 tinygo 來編譯了,執(zhí)行以下命令:

tinygo build -o main.wasm -scheduler=none -target=wasi main.go

上面的命令會生成一個 main.wasm 文件,這個文件就是我們的 WASM 插件,接下來我們就可以將這個插件部署到 Istio 中了。

部署 WASM

我們可以將這個 main.wasm 文件放到一個 ConfigMap 中,然后掛載到 Envoy 中,這樣就可以在 Envoy 中使用了,比如我們可以使用下面的命令來創(chuàng)建一個 ConfigMap:

kubectl create configmap new-filter --from-file=new-filter.wasm=main.wasm

然后接下來我們以 httpbin 為例來測試下,這里我們需要修改下 httpbin 的部署文件,將 ConfigMap 掛載到 Envoy 中。

部署 WASM

修改后的部署文件如下所示:

# httpbin.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  name: httpbin
---
apiVersion: v1
kind: Service
metadata:
  name: httpbin
  labels:
    app: httpbin
    service: httpbin
spec:
  ports:
    - name: http
      port: 8000
      targetPort: 80
  selector:
    app: httpbin
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: httpbin
spec:
  selector:
    matchLabels:
      app: httpbin
      version: v1
  template:
    metadata:
      labels:
        app: httpbin
        version: v1
      annotations:
        # 不能在容器上使用 volume 掛載,因為它來自 injector。
        # NOTE: 我們這個示例始終掛在 "new-filter" ConfigMap 到 /var/local/wasm/new-filter.wasm
        sidecar.istio.io/userVolume: '[{"name":"new-filter","configMap":{"name":"new-filter"}}]'
        sidecar.istio.io/userVolumeMount: '[{"mountPath":"/var/local/wasm","name":"new-filter"}]'
    spec:
      serviceAccountName: httpbin
      containers:
        - image: docker.io/kennethreitz/httpbin
          imagePullPolicy: IfNotPresent
          name: httpbin
          ports:
            - containerPort: 80

直接應(yīng)用上面的資源對象即可:

kubectl apply -f httpbin.yaml
# 當(dāng)然要需要創(chuàng)建 VirtualService,在 Istio 根目錄下面
kubectl apply -f samples/httpbin/httpbin-gateway.yaml

部署完成后接下來我們先訪問下 httpbin 服務(wù),看下是否正常:

$ export GATEWAY_URL=$(kubectl get po -l istio=ingressgateway -n istio-system -o 'jsnotallow={.items[0].status.hostIP}'):$(kubectl get svc istio-ingressgateway -n istio-system -o 'jsnotallow={.spec.ports[?(@.name=="http2")].nodePort}')
$ curl -v http://$GATEWAY_URL/status/418
> GET /status/418 HTTP/1.1
> User-Agent: curl/7.29.0
> Host: 192.168.0.20:31896
> Accept: */*
>
< HTTP/1.1 418 Unknown
< server: istio-envoy
< date: Fri, 08 Dec 2023 07:28:57 GMT
< x-more-info: http://tools.ietf.org/html/rfc2324
< access-control-allow-origin: *
< access-control-allow-credentials: true
< content-length: 135
< x-envoy-upstream-service-time: 2
<

    -=[ teapot ]=-

       _...._
     .'  _ _ `.
    | ."` ^ `". _,
    \_;`"---"`|//
      |       ;/
      \_     _/
        `"""`

上面我們編寫的插件邏輯是當(dāng)我們訪問 http://service/banana/X 時,會將請求重定向到 http://service/status/X,所以我們可以使用下面的命令來測試下:

$ curl -v http://$GATEWAY_URL/banana/418
> GET /banana/418 HTTP/1.1
> User-Agent: curl/7.29.0
> Host: 192.168.0.20:31896
> Accept: */*
>
< HTTP/1.1 404 Not Found
< server: istio-envoy
< date: Fri, 08 Dec 2023 07:30:19 GMT
< content-type: text/html
< content-length: 233
< access-control-allow-origin: *
< access-control-allow-credentials: true
< x-envoy-upstream-service-time: 9
<
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<title>404 Not Found</title>
<h1>Not Found</h1>
<p>The requested URL was not found on the server.  If you entered the URL manually please check your spelling and try again.</p>

從結(jié)果可以看到,我們定義的插件并沒有生效,其實也能預(yù)料到,現(xiàn)在我們只是將編譯后的 WASM 文件掛載到了 Envoy 中,但是 Envoy 并不知道這個文件是用來做什么的,或者說 Envoy 并不知道要將這個文件當(dāng)成 WASM 插件來使用。

$ kubectl get pods -l app=httpbin
NAME                       READY   STATUS    RESTARTS   AGE
httpbin-55db5999b4-qtlcg   2/2     Running   0          8m23s
$ kubectl exec -it httpbin-55db5999b4-qtlcg -c istio-proxy -- ls /var/local/wasm
new-filter.wasm

wasm 插件

這個時候我們還需要使用到一個名為 EnvoyFilter 的 CRD 資源對象,EnvoyFilter 提供了一種機制,可以自定義 Istio Pilot 生成的 Envoy 配置,使用 EnvoyFilter 可以修改某些字段的值、添加特定的過濾器,甚至添加全新的監(jiān)聽器、集群等。需要注意的是這個功能必須小心使用,因為不正確的配置可能會導(dǎo)致整個網(wǎng)格不穩(wěn)定。與其他 Istio 網(wǎng)絡(luò)對象不同,EnvoyFilters 是附加應(yīng)用的。對于特定命名空間中給定工作負載來說,可以存在任意數(shù)量的 EnvoyFilters,這些 EnvoyFilters 的應(yīng)用順序如下:首先是配置根命名空間中所有的 EnvoyFilters,然后是工作負載所在命名空間中匹配到的所有 EnvoyFilters。

比如我們可以使用下面的配置來將我們的 WASM 插件掛載到 Envoy 中:

# httpbin-wasm-filter.yaml
apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: httpbin-wasm-filter
spec:
  workloadSelector:
    labels:
      app: httpbin
  configPatches:
    - applyTo: HTTP_FILTER
      match:
        context: SIDECAR_INBOUND # 僅對入站流量進行過濾
        listener:
          filterChain:
            filter:
              name: envoy.filters.network.http_connection_manager
              subFilter:
                name: envoy.filters.http.router
      patch:
        operation: INSERT_BEFORE # 在 router 之前插入
        value:
          name: mydummy
          typed_config:
            "@type": type.googleapis.com/udpa.type.v1.TypedStruct
            type_url: type.googleapis.com/envoy.extensions.filters.http.wasm.v3.Wasm
            value:
              config:
                configuration:
                  "@type": type.googleapis.com/google.protobuf.StringValue
                  value: dummy
                root_id: "regex_replace"
                vm_config:
                  code:
                    local:
                      filename: /var/local/wasm/new-filter.wasm
                  runtime: envoy.wasm.runtime.v8
                  vm_id: myvmdummy

上面的 EnvoyFilter 對象中,首先我們通過 workloadSelector 來指定要對哪些 Pod 進行過濾,這里我們指定了 app: httpbin,表示只對 httpbin 這個 Pod 進行過濾,然后主要關(guān)注 configPatches 字段,這個字段用于配置 Envoy 的過濾器,其中的 match 字段用于匹配 Envoy 的過濾器,這里我們匹配的是 envoy.filters.network.http_connection_manager,然后 patch 字段用于指定要掛載的 WASM 插件,在 value.config 中指定了插件的配置信息以及 WASM 插件的路徑。

然后直接應(yīng)用上面的這個資源對象即可:

kubectl apply -f httpbin-wasm-filter.yaml

部署完成后我們可以先查看 httpbin 應(yīng)用的 sidecar 日志:

$ kubectl logs -f httpbin-55db5999b4-qtlcg -c istio-proxy
# ......
2023-12-08T07:48:03.605802Z     warning envoy wasm external/envoy/source/extensions/common/wasm/context.cc:1151 wasm log: regex/main.go main() REACHED  thread=25
2023-12-08T07:48:03.606902Z     warning envoy wasm external/envoy/source/extensions/common/wasm/context.cc:1151 wasm log regex_replace myvmdummy: read plug-in config: dummy
        thread=25
2023-12-08T07:48:03.729847Z     info    Readiness succeeded in 1.025422807s
2023-12-08T07:48:03.730148Z     info    Envoy proxy is ready

正?,F(xiàn)在就可以看到上面我們在插件中添加的一些日志了,然后我們再來測試下 httpbin 服務(wù),訪問 http://service/banana/X,看下是否能夠正常重定向到 http://service/status/X:

$ curl -v http://$GATEWAY_URL/banana/418
> GET /banana/418 HTTP/1.1
> User-Agent: curl/7.29.0
> Host: 192.168.0.20:31896
> Accept: */*
>
< HTTP/1.1 418 Unknown
< server: istio-envoy
< date: Fri, 08 Dec 2023 08:11:17 GMT
< x-more-info: http://tools.ietf.org/html/rfc2324
< access-control-allow-origin: *
< access-control-allow-credentials: true
< content-length: 135
< x-envoy-upstream-service-time: 10
< who-am-i: go-wasm-demo
< injected-by: istio-api!
< site: youdianzhishi.com
< author: 陽明
< configdata: dummy
<

    -=[ teapot ]=-

       _...._
     .'  _ _ `.
    | ."` ^ `". _,
    \_;`"---"`|//
      |       ;/
      \_     _/

從上面的結(jié)果可以看到,我們的插件已經(jīng)生效了,當(dāng)我們訪問 http://service/banana/X 時,會將請求重定向到 http://service/status/X,并且在響應(yīng)頭中添加了我們定義的一些 Header。到這里我們就實現(xiàn)了一個簡單的 WASM 插件,當(dāng)然這個插件只是一個簡單的示例,實際上我們可以實現(xiàn)更加復(fù)雜的邏輯,比如可以實現(xiàn)自定義認證、自定義日志、自定義路由等等。

WasmPlugin API

需要注意的是這里我們的部署方式是創(chuàng)建一個包含已編譯的 Wasm 插件的 ConfigMap,將 ConfigMap 掛載到 Pod 的 Envoy Sidecar 中去,然后通過 EnvoyFilter 配置 Envoy,從本地文件加載 Wasm 插件。這種方法的確可以實現(xiàn)我們的需求,但是配置 EnvoyFilter 對象有點復(fù)雜,功能豐富的 Wasm 插件可能超出 ConfigMap 1MB 的大小限制。為了解決這個問題,Istio 便引入了一個新的用于自定義 Wasm 插件對 Istio 代理功能進行擴展的新頂層 API - WasmPlugin CRD,不再需要使用 EnvoyFilter 資源向代理添加自定義 Wasm 模塊,取而代之的是使用 WasmPlugin 資源:

apiVersion: extensions.istio.io/v1alpha1
kind: WasmPlugin
metadata:
  name: your-filter
spec:
  selector:
    matchLabels:
      app: server
  phase: AUTHN
  priority: 10
  pluginConfig:
    someSetting: true
    someOtherSetting: false
    youNameIt:
      - first
      - second
  url: docker.io/your-org/your-filter:1.0.0

WasmPlugin 和 EnvoyFilter 之間有不少相似的地方,但也存在一些不同之處。比如在上面的示例中是將 Wasm 模塊部署到與 selector 字段匹配的所有工作負載 —— 這與 EnvoyFilter 是完全相同的。

接下來的字段是 phase,該字段決定了 Wasm 模塊將被注入到代理過濾器鏈中的哪個位置。我們?yōu)槠涠x了四個不同的階段:

  • AUTHN:在所有 Istio 身份驗證和授權(quán)過濾器之前。
  • AUTHZ:在 Istio 身份驗證過濾器之后以及所有一級授權(quán)過濾器之前,即應(yīng)用于 AuthorizationPolicy 資源之前。
  • STATS:在所有授權(quán)過濾器之后,以及 Istio 統(tǒng)計過濾器之前。
  • UNSPECIFIED_PHASE:讓控制平面決定注入的位置,通常位于過濾器鏈的末端,也就是在路由之前。這也是該 phase 字段的默認值。

pluginConfig 字段用于 Wasm 插件的具體配置。在此字段中輸入的任何內(nèi)容都將通過 JSON 格式進行編碼并傳遞到過濾器中,我們可以在 Proxy-Wasm SDK 的配置回調(diào)中訪問它,比如在 Go SDK 中的 OnPluginStart 回調(diào)中可以獲取這些配置信息。

url 字段指定了 Wasm 模塊的拉取位置,這里的 url 是一個 docker URI,除了通過 HTTP、HTTPS 和本地文件系統(tǒng) (使用 file://)方式加載 Wasm 模塊之外,還可以使用 OCI 鏡像格式作為分發(fā) Wasm 插件,這也是推薦的方式。

接下來我們按照上面的要求在代碼根目錄中新建一個 Dockerfile,用來將我們的 Wasm 插件打包到 Docker 鏡像中:

# Dockerfile for building "compat" variant of Wasm Image Specification.
# https://github.com/solo-io/wasm/blob/master/spec/spec-compat.md

FROM scratch

COPY main.wasm ./plugin.wasm

當(dāng)然也可以將構(gòu)建的動作放到 Dockerfile 中,進行多階段構(gòu)建:

FROM tinygo/tinygo as build
WORKDIR /src

COPY . .
RUN go env -w GOPROXY=https://goproxy.cn,direct
RUN tinygo build -o main.wasm -scheduler=none -target=wasi ./main.go

FROM scratch

COPY --from=build /src/main.wasm ./plugin.wasm

直接使用 docker build 命令來構(gòu)建鏡像即可,構(gòu)建完成后推送到鏡像倉庫:

docker build -t cnych/wasm-go-demo:v0.1 .
docker.io/cnych/wasm-go-demo:v0.1

接下來就可以使用 WasmPlugin 資源對象來部署我們的 WASM 插件了,創(chuàng)建如下所示的 WasmPlugin 資源對象:

# httpbin-wasm-plugin.yaml
apiVersion: extensions.istio.io/v1alpha1
kind: WasmPlugin
metadata:
  name: httpbin-wasm-plugin
  namespace: default
spec:
  selector:
    matchLabels:
      app: httpbin
  url: oci://docker.io/cnych/wasm-go-demo:v0.1
  pluginConfig:
    testConfig: abcd
    website: youdianzhishi.com
    listconfig:
      - abc
      - def

先刪除之前的 EnvoyFilter 資源:

$ kubectl delete cm new-filter
configmap "new-filter" deleted
$ kubectl delete envoyfilter httpbin-wasm-filter
envoyfilter.networking.istio.io "httpbin-wasm-filter" deleted

記得將 httpbin.yaml 中的 sidecar.istio.io/userVolume 和 sidecar.istio.io/userVolumeMount 字段刪除:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: httpbin
spec:
  selector:
    matchLabels:
      app: httpbin
      version: v1
  template:
    metadata:
      labels:
        app: httpbin
        version: v1
      # annotations: # 去掉這里的注解
    spec:
      serviceAccountName: httpbin
      containers:
        - image: docker.io/kennethreitz/httpbin
          imagePullPolicy: IfNotPresent
          name: httpbin
          ports:
            - containerPort: 80

然后直接應(yīng)用上面的 WasmPlugin 資源對象:

$ kubectl apply -f httpbin-wasm-plugin.yaml
$ kubectl get wasmplugins
NAME                  AGE
httpbin-wasm-plugin   5s

部署完成后我們可以先查看 httpbin 應(yīng)用的 sidecar 日志:

$ kubectl logs -f httpbin-86869bccff-6wqdc -c istio-proxy
# ......
2023-12-08T08:43:11.360127Z     warning envoy wasm external/envoy/source/extensions/common/wasm/context.cc:1151 wasm log: regex/main.go main() REACHED  thread=25
2023-12-08T08:43:11.360757Z     warning envoy wasm external/envoy/source/extensions/common/wasm/context.cc:1151 wasm log: regex/main.go OnPluginStart() thread=25
2023-12-08T08:43:11.360895Z     warning envoy wasm external/envoy/source/extensions/common/wasm/context.cc:1151 wasm log: read plug-in config: {"listconfig":["abc","def"],"testConfig":"abcd","website":"youdianzhishi.com"}
        thread=25
2023-12-08T08:43:12.692961Z     info    Readiness succeeded in 6.774251572s
2023-12-08T08:43:12.693263Z     info    Envoy proxy is ready

可以看到我們的插件已經(jīng)生效了,然后我們再來測試下 httpbin 服務(wù),訪問 http://service/banana/X,看下是否能夠正常重定向到 http://service/status/X:

$ curl -v http://$GATEWAY_URL/banana/418
> GET /banana/418 HTTP/1.1
> User-Agent: curl/7.29.0
> Host: 192.168.0.20:31896
> Accept: */*
>
< HTTP/1.1 418 Unknown
< server: istio-envoy
< date: Fri, 08 Dec 2023 08:45:29 GMT
< x-more-info: http://tools.ietf.org/html/rfc2324
< access-control-allow-origin: *
< access-control-allow-credentials: true
< content-length: 135
< x-envoy-upstream-service-time: 8
< who-am-i: go-wasm-demo
< injected-by: istio-api!
< site: youdianzhishi.com
< author: 陽明
< configdata: {"listconfig":["abc","def"],"testConfig":"abcd","website":"youdianzhishi.com"}
<

    -=[ teapot ]=-

       _...._
     .'  _ _ `.
    | ."` ^ `". _,
    \_;`"---"`|//
      |       ;/
      \_     _/
        `"""`

從上面的結(jié)果可以看到結(jié)果是符合我們的預(yù)期的,證明我們的插件已經(jīng)生效了。

性能數(shù)據(jù)

參考阿里云性能測試結(jié)果(僅供參考):

1000 并發(fā) 1000QPS 持續(xù) 10 秒鐘

基準

WASM

LUA

平均延遲

0.6317 secs

0.6395 secs

0.7012 secs

延遲 99%分布

0.9167 secs

0.9352 secs

1.1355 secs

QPS

1541

1519

1390

Total

16281

16109

1390

相對于基準版本,增加 Wasm 插件的兩個版本,平均延遲多出幾十個到幾百個毫秒,增加耗時比為:

  • wasm:1.2% (0.6395-0.6317)/0.6317和 1% (1.3290-1.2078)/1.2078
  • lua:11%(0.7012-0.6317)/0.6317和 20% (1.4593-1.2078)/1.2078

可以看出 WASM 版本的性能明顯優(yōu)于 LUA 版本。

責(zé)任編輯:姜華 來源: k8s技術(shù)圈
相關(guān)推薦

2021-12-27 10:46:07

WebAPIserver簽名

2009-08-31 14:45:10

C#擴展方法

2021-05-06 09:33:32

OperatorKubernetes開源

2022-06-02 08:01:11

云原生工具

2018-07-30 13:29:04

WebAssemblyGo語言

2021-05-09 22:48:40

SQL數(shù)據(jù)庫變量

2024-01-02 07:37:52

FlaggerKubernetesIstio

2021-06-15 20:59:14

Kubernetes調(diào)試容器

2022-08-30 08:00:00

架構(gòu)數(shù)據(jù)庫Postgres

2021-03-05 00:06:12

Docker容器內(nèi)存

2022-08-15 15:16:20

機器學(xué)習(xí)圖片深度學(xué)習(xí)

2021-08-30 14:23:05

BlazorHTTP請求

2010-12-15 15:30:45

組策略

2023-07-13 11:24:14

SQL優(yōu)化賦值

2009-10-22 09:32:51

ghostlinux系統(tǒng)備份

2021-09-27 16:39:10

PythonGif壓縮

2023-11-20 07:19:33

2010-12-07 16:17:40

SQL Server

2009-04-03 13:20:05

C#擴展方法調(diào)用

2022-03-08 20:08:53

PostgreSQLCitus語言
點贊
收藏

51CTO技術(shù)棧公眾號