簡(jiǎn)介：?伴隨著 5G、IoT 等技術(shù)的快速發(fā)展，邊緣計(jì)算被越來越廣泛地應(yīng)用于電信、媒體、運(yùn)輸、物流、農(nóng)業(yè)、零售等行業(yè)和場(chǎng)景中，成為解決這些領(lǐng)域數(shù)據(jù)傳輸效率的關(guān)鍵方式。與此同時(shí)，邊緣計(jì)算形態(tài)、規(guī)模、復(fù)雜度的日益增長(zhǎng)，邊緣計(jì)算領(lǐng)域的運(yùn)維手段、運(yùn)維能力對(duì)邊緣業(yè)務(wù)創(chuàng)新速度的支撐日趨乏力。于是，Kubernetes 迅速成為邊緣計(jì)算的關(guān)鍵要素，幫助企業(yè)在邊緣更好地運(yùn)行容器，最大化利用資源、縮短研發(fā)周期。

作者｜何淋波（新勝）

背景

?

伴隨著 5G、IoT 等技術(shù)的快速發(fā)展，邊緣計(jì)算被越來越廣泛地應(yīng)用于電信、媒體、運(yùn)輸、物流、農(nóng)業(yè)、零售等行業(yè)和場(chǎng)景中，成為解決這些領(lǐng)域數(shù)據(jù)傳輸效率的關(guān)鍵方式。與此同時(shí)，邊緣計(jì)算形態(tài)、規(guī)模、復(fù)雜度的日益增長(zhǎng)，邊緣計(jì)算領(lǐng)域的運(yùn)維手段、運(yùn)維能力對(duì)邊緣業(yè)務(wù)創(chuàng)新速度的支撐日趨乏力。于是，Kubernetes 迅速成為邊緣計(jì)算的關(guān)鍵要素，幫助企業(yè)在邊緣更好地運(yùn)行容器，最大化利用資源、縮短研發(fā)周期。
?

但是，如果將原生 Kubernetes 直接應(yīng)用到邊緣計(jì)算場(chǎng)景下，仍然需要解決諸多問題，比如云與邊一般位于不同網(wǎng)絡(luò)平面，同時(shí)邊緣節(jié)點(diǎn)普遍位于防火墻內(nèi)部，采用云(中心)邊協(xié)同架構(gòu)，將導(dǎo)致原生 K8s 系統(tǒng)的運(yùn)維監(jiān)控能力面臨如下挑戰(zhàn)：
?

• K8s 原生運(yùn)維能力缺失(如 kubectl logs/exec 等無法執(zhí)行)
• 社區(qū)主流監(jiān)控運(yùn)維組件無法工作(如 Prometheus/metrics-server )

?

為了幫助企業(yè)解決原生 Kubernetes 在邊緣場(chǎng)景下關(guān)于應(yīng)用生命周期管理、云邊網(wǎng)絡(luò)連接、云邊端運(yùn)維協(xié)同、異構(gòu)資源支持等方方面面的挑戰(zhàn)，基于 K8s 實(shí)現(xiàn)的邊緣計(jì)算云原生開源平臺(tái) OpenYurt 應(yīng)運(yùn)而生，其也是 CNCF 在邊緣云原生版圖中的重要組成部分。本文將詳細(xì)介紹，作為 OpenYurt 核心組件之一的 Yurt-Tunnel 如何是擴(kuò)展原生 K8s 系統(tǒng)在邊緣場(chǎng)景下相關(guān)能力的。
?

Yurt-Tunnel 設(shè)計(jì)思路

?

由于邊緣可以訪問云端，因此可以考慮在云邊構(gòu)建可以反向穿透的隧道，從而保證云(中心)可以基于隧道主動(dòng)訪問邊緣。當(dāng)時(shí)我們也調(diào)查了很多開源的隧道方案，從能力以及生態(tài)兼容性等方面，最后我們選擇基于?ANP?設(shè)計(jì)并實(shí)現(xiàn)了 Yurt-Tunnel 整體解決方案，具備安全，非侵入、可擴(kuò)展、傳輸高效等優(yōu)點(diǎn)。
?

?

實(shí)現(xiàn)方式

在 K8s 云邊一體化架構(gòu)中構(gòu)建一個(gè)安全、非侵入、可擴(kuò)展的反向通道解決方案，方案中至少需要包括如下能力。

• 云邊隧道構(gòu)建
• 隧道兩端證書的自管理
• 云端組件請(qǐng)求被無縫倒流到隧道

Yurt-tunnel 的架構(gòu)模塊如下圖：
?

3.1 云邊隧道構(gòu)建

• 當(dāng)邊緣的 yurt-tunnel-agent 啟動(dòng)時(shí)，會(huì)根據(jù)訪問地址與 yurt-tunnel-server 建立連接并注冊(cè)，并周期性檢測(cè)連接的健康狀態(tài)以及重建連接等。

# https://github.com/openyurtio/apiserver-network-proxy/blob/master/pkg/agent/client.go#L189 # yurt-tunnel-agent的注冊(cè)信息: "agentID": {nodeName} "agentIdentifiers": ipv4={nodeIP}&host={nodeName}"

• 當(dāng) yurt-tunnel-server 收到云端組件的請(qǐng)求時(shí)，需要把請(qǐng)求轉(zhuǎn)發(fā)給對(duì)應(yīng)的 yurt-tunnel-agent 。因?yàn)槌宿D(zhuǎn)發(fā)初始請(qǐng)求之外，該請(qǐng)求 session 后續(xù)還有數(shù)據(jù)返回或者數(shù)據(jù)的持續(xù)轉(zhuǎn)發(fā)(如 kubectl exec )。因此需要雙向轉(zhuǎn)發(fā)數(shù)據(jù)。同時(shí)需要支持并發(fā)轉(zhuǎn)發(fā)云端組件的請(qǐng)求，意味需要為每個(gè)請(qǐng)求生命周期建立一個(gè)獨(dú)立的標(biāo)識(shí)。所以設(shè)計(jì)上一般會(huì)有兩種方案。

方案 1:?初始云邊連接僅通知轉(zhuǎn)發(fā)請(qǐng)求，tunnel-agent 會(huì)和云端建立新連接來處理這個(gè)請(qǐng)求。通過新連接可以很好的解決請(qǐng)求獨(dú)立標(biāo)識(shí)的問題，同時(shí)并發(fā)也可以很好的解決。但是為每個(gè)請(qǐng)求都需要建立一個(gè)連接，將消耗大量的資源。
?

方案 2: 僅利用初始云邊連接來轉(zhuǎn)發(fā)請(qǐng)求，大量請(qǐng)求為了復(fù)用同一條連接，所以需要為每個(gè)請(qǐng)求進(jìn)行封裝，并增加獨(dú)立標(biāo)識(shí)，從而解決并發(fā)轉(zhuǎn)發(fā)的訴求。同時(shí)由于需要復(fù)用一條連接，所以需要解耦連接管理和請(qǐng)求生命周期管理，即需要對(duì)請(qǐng)求轉(zhuǎn)發(fā)的狀態(tài)遷移進(jìn)行獨(dú)立管理。該方案涉及到封包解包，請(qǐng)求處理狀態(tài)機(jī)等，方案會(huì)復(fù)雜一些。
?

• OpenYurt 選擇的 ANP 組件，采用的是上述方案2，這個(gè)和我們的設(shè)計(jì)初衷也是一致的。

# https://github.com/openyurtio/apiserver-network-proxy/blob/master/konnectivity-client/proto/client/client.pb.go#L98 # 云邊通信的數(shù)據(jù)格式以及數(shù)據(jù)類型 type Packet struct {Type PacketType `protobuf:"varint,1,opt,name=type,proto3,enum=PacketType" json:"type,omitempty"`// Types that are valid to be assigned to Payload:// *Packet_DialRequest// *Packet_DialResponse// *Packet_Data// *Packet_CloseRequest// *Packet_CloseResponsePayload isPacket_Payload `protobuf_oneof:"payload"` }

?

• 請(qǐng)求轉(zhuǎn)發(fā)鏈路構(gòu)建封裝在 Packet_DialRequest 和 Packet_DialResponse 中，其中 Packet_DialResponse.ConnectID 用于標(biāo)識(shí) request ，相當(dāng)于 tunnel 中的 requestID。請(qǐng)求以及關(guān)聯(lián)數(shù)據(jù)封裝在 Packet_Data 中。Packet_CloseRequest 和 Packet_CloseResponse 用于轉(zhuǎn)發(fā)鏈路資源回收。具體可以參照下列時(shí)序圖：

?

• RequestInterceptor 模塊的作用

從上述分析可以看出，yurt-tunnel-server 轉(zhuǎn)發(fā)請(qǐng)求之前，需要請(qǐng)求端先發(fā)起一個(gè)Http Connect 請(qǐng)求來構(gòu)建轉(zhuǎn)發(fā)鏈路。但是為 Prometheus、metrics-server 等開源組件增加相應(yīng)處理會(huì)比較困難，因此在 Yurt-tunnel-server 中增加請(qǐng)求劫持模塊 Interceptor ，用來發(fā)起 Http Connect 請(qǐng)求。相關(guān)代碼如下:
?

# https://github.com/openyurtio/openyurt/blob/master/pkg/yurttunnel/server/interceptor.go#L58-82proxyConn, err := net.Dial("unix", udsSockFile)if err != nil {return nil, fmt.Errorf("dialing proxy %q failed: %v", udsSockFile, err)}var connectHeaders stringfor _, h := range supportedHeaders {if v := header.Get(h); len(v) != 0 {connectHeaders = fmt.Sprintf("%s\r\n%s: %s", connectHeaders, h, v)}}fmt.Fprintf(proxyConn, "CONNECT %s HTTP/1.1\r\nHost: %s%s\r\n\r\n", addr, "127.0.0.1", connectHeaders)br := bufio.NewReader(proxyConn)res, err := http.ReadResponse(br, nil)if err != nil {proxyConn.Close()return nil, fmt.Errorf("reading HTTP response from CONNECT to %s via proxy %s failed: %v", addr, udsSockFile, err)}if res.StatusCode != 200 {proxyConn.Close()return nil, fmt.Errorf("proxy error from %s while dialing %s, code %d: %v", udsSockFile, addr, res.StatusCode, res.Status)}

?

3.2 證書管理

為了保證云邊通道的長(zhǎng)期安全通信，同時(shí)也為了支持 https 請(qǐng)求轉(zhuǎn)發(fā)，yurt-tunnel 需要自行生成證書并且保持證書的自動(dòng)輪替。具體實(shí)現(xiàn)如下:
?

# 1. yurt-tunnel-server證書: # https://github.com/openyurtio/openyurt/blob/master/pkg/yurttunnel/pki/certmanager/certmanager.go#L45-90 - 證書存儲(chǔ)位置: /var/lib/yurt-tunnel-server/pki - CommonName: "kube-apiserver-kubelet-client" // 用于kubelet server的webhook校驗(yàn) - Organization: {"system:masters", "openyurt:yurttunnel"} // 用于kubelet server的webhook校驗(yàn)和yurt-tunnel-server證書的auto approve - Subject Alternate Name values: {x-tunnel-server-svc, x-tunnel-server-internal-svc的ips和dns names} - KeyUsage: "any"# 2. yurt-tunnel-agent證書： # https://github.com/openyurtio/openyurt/blob/master/pkg/yurttunnel/pki/certmanager/certmanager.go#L94-112 - 證書存儲(chǔ)位置: /var/lib/yurt-tunnel-agent/pki - CommonName: "yurttunnel-agent" - Organization: {"openyurt:yurttunnel"} // 用于yurt-tunnel-agent證書的auto approve - Subject Alternate Name values: {nodeName, nodeIP} - KeyUsage: "any"# 3. yurt-tunnel證書申請(qǐng)(CSR)均由yurt-tunnel-server來approve # https://github.com/openyurtio/openyurt/blob/master/pkg/yurttunnel/pki/certmanager/csrapprover.go#L115 - 監(jiān)聽csr資源 - 過濾非yurt-tunnel的csr(Organization中沒有"openyurt:yurttunnel") - approve還未Approved的csr# 4. 證書自動(dòng)輪替處理 # https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/client-go/util/certificate/certificate_manager.go#L224

3.3 無縫導(dǎo)流云端組件請(qǐng)求到隧道

?

因?yàn)樾枰獰o縫把云端組件的請(qǐng)求轉(zhuǎn)發(fā)到 yurt-tunnel-server ，也意味不需要對(duì)云端組件進(jìn)行任何修改。因此需要對(duì)云端組件的請(qǐng)求進(jìn)行分析，目前組件的運(yùn)維請(qǐng)求主要有以下兩種類型:
?

• 類型1: 直接使用 IP 地址訪問，如:?http://{nodeIP}:{port}/{path}
• 類型2: 使用域名訪問, 如:?http://{nodeName}:{port}/{path}

?

針對(duì)不同類型請(qǐng)求的導(dǎo)流，需要采用不同方案。
?

• 方案1: 使用 iptables dnat rules 來保證類型1的請(qǐng)求無縫轉(zhuǎn)發(fā)到 yurt-tunnel-server

# 相關(guān)iptables rules維護(hù)代碼: https://github.com/openyurtio/openyurt/blob/master/pkg/yurttunnel/iptables/iptables.go # yurt-tunnel-server維護(hù)的iptables dnat rules如下: [root@xxx /]# iptables -nv -t nat -L OUTPUT TUNNEL-PORT tcp -- * * 0.0.0.0/0 0.0.0.0/0 /* edge tunnel server port */[root@xxx /]# iptables -nv -t nat -L TUNNEL-PORT TUNNEL-PORT-10255 tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:10255 /* jump to port 10255 */ TUNNEL-PORT-10250 tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:10250 /* jump to port 10250 */[root@xxx /]# iptables -nv -t nat -L TUNNEL-PORT-10255 RETURN tcp -- * * 0.0.0.0/0 127.0.0.1 /* return request to access node directly */ tcp dpt:10255 RETURN tcp -- * * 0.0.0.0/0 172.16.6.156 /* return request to access node directly */ tcp dpt:10255 DNAT tcp -- * * 0.0.0.0/0 0.0.0.0/0 /* dnat to tunnel for access node */ tcp dpt:10255 to:172.16.6.156:10264

?

• 方案2: 使用 dns 域名解析 nodeName 為 yurt-tunnel-server 的訪問地址，從而使類型 2 請(qǐng)求無縫轉(zhuǎn)發(fā)到 yurt-tunnel

# x-tunnel-server-svc和x-tunnel-server-internal-svc的不同用途:- x-tunnel-server-svc: 主要expose 10262/10263端口，用于從公網(wǎng)訪問yurt-tunnel-server。如yurt-tunnel-agent- x-tunnel-server-internal-svc: 主要用于云端組件從內(nèi)部網(wǎng)絡(luò)訪問，如prometheus,metrics-server等# dns域名解析原理: 1. yurt-tunnel-server向kube-apiserver創(chuàng)建或更新yurt-tunnel-nodes configmap, 其中tunnel-nodes字段格式為: {x-tunnel-server-internal-svc clusterIP} {nodeName}，確保記錄了所有nodeName和yurt-tunnel-server的service的映射關(guān)系 2. coredns pod中掛載yurt-tunnel-nodes configmap，同時(shí)使用host插件使用configmap的dns records 3. 同時(shí)在x-tunnel-server-internal-svc中配置端口映射，10250映射到10263，10255映射到10264 4. 通過上述的配置，可以實(shí)現(xiàn)http://{nodeName}:{port}/{path}請(qǐng)求無縫轉(zhuǎn)發(fā)到y(tǒng)urt-tunnel-servers

?

• 云端請(qǐng)求擴(kuò)展:

?

如果用戶需要訪問邊緣的其他端口(10250 和 10255 之外)，那么需要在 iptables 中增加相應(yīng)的 dnat rules 或者 x-tunnel-server-internal-svc 中增加相應(yīng)的端口映射，如下所示:
?

# 例如需要訪問邊緣的9051端口 # 新增iptables dnat rule: [root@xxx /]# iptables -nv -t nat -L TUNNEL-PORT TUNNEL-PORT-9051 tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:9051 /* jump to port 9051 */[root@xxx /]# iptables -nv -t nat -L TUNNEL-PORT-9051 RETURN tcp -- * * 0.0.0.0/0 127.0.0.1 /* return request to access node directly */ tcp dpt:9051 RETURN tcp -- * * 0.0.0.0/0 172.16.6.156 /* return request to access node directly */ tcp dpt:9051 DNAT tcp -- * * 0.0.0.0/0 0.0.0.0/0 /* dnat to tunnel for access node */ tcp dpt:9051 to:172.16.6.156:10264# x-tunnel-server-internal-svc中新增端口映射 spec:ports:- name: httpsport: 10250protocol: TCPtargetPort: 10263- name: httpport: 10255protocol: TCPtargetPort: 10264- name: dnat-9051 # 新增映射port: 9051protocol: TCPtargetPort: 10264

當(dāng)然上述的 iptables dnat rules 和 service 端口映射，都是由?yurt-tunnel-server 自動(dòng)更新。用戶只需要在 yurt-tunnel-server-cfg configmap 中增加端口配置即可。具體如下:
?

# 注意：由于證書不可控因素，目前新增端口只支持從yurt-tunnel-server的10264轉(zhuǎn)發(fā) apiVersion: v1 data:dnat-ports-pair: 9051=10264 # 新增端口=10264(非10264轉(zhuǎn)發(fā)不支持) kind: ConfigMap metadata:name: yurt-tunnel-server-cfgnamespace: kube-system

?近期規(guī)劃

?

• 支持 kube-apiserver 的 EgressSelector 功能
• 驗(yàn)證 yurt-tunnel-server 多實(shí)例部署驗(yàn)證
• 支持 yurt-tunnel-agent 配置多個(gè) yurt-tunnel-server 地址
• 支持證書存儲(chǔ)目錄自定義
• 支持證書 Usage 定義更精細(xì)化，保證證書使用范圍可控
• 支持 yurt-tunnel-server 訪問地址變化后，yurt-tunnel-server 證書可自動(dòng)更新
• 支持 yurt-tunnel-agent 對(duì) yurt-tunnel-server 訪問地址的自動(dòng)刷新
• 支持非 NodeIP/NodeName 類型的請(qǐng)求轉(zhuǎn)發(fā)(如非主機(jī)網(wǎng)絡(luò) Pod 的云訪問邊)
• 支持通過 Tunnel 由邊緣 Pod 訪問云端 Pod
• 支持 yurt-tunnel 的獨(dú)立部署(非綁定 k8s )
• 支持更多協(xié)議轉(zhuǎn)發(fā)，如 gRPC, websocket, ssh 等

?

歡迎加入 OpenYurt 社區(qū)

?

作為阿里云邊緣容器服務(wù) ACK@Edge 的內(nèi)核，OpenYurt 已經(jīng)在 CDN、音視頻直播、物聯(lián)網(wǎng)、物流、工業(yè)大腦、城市大腦等數(shù)十個(gè)行業(yè)中得到商業(yè)化實(shí)踐、服務(wù)規(guī)模達(dá)數(shù)百萬 CPU 核。我們可喜地看到，現(xiàn)在有越來越多的開發(fā)者、開源社區(qū)、企業(yè)和學(xué)信機(jī)構(gòu)認(rèn)可 OpenYurt 的理念，并且正在加入到共同建設(shè) OpenYurt 的隊(duì)伍中，比如 VMware、Intel、深信服、招商局、浙大、EdgeX Foundry 社區(qū)、eKuiper 社區(qū)等。我們也歡迎更多的朋友共建 OpenYurt 社區(qū)，繁榮云原生邊緣計(jì)算生態(tài)，讓真正意義上的云原生在更多邊緣場(chǎng)景中創(chuàng)造價(jià)值。

原文鏈接

本文為阿里云原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。

總結(jié)

以上是生活随笔為你收集整理的Yurt-Tunnel 详解｜如何解决 K8s 在云边协同下的运维监控挑战的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。