手把手教你理解並建立 GCP Load Balancer

Photo by Marion Michele on Unsplash

My Blog

English version

前言

為什麼要使用 Load Balancer?

1. 可以分攤流量, 利用多台機器跑多個服務
2. 當一台機器掛了，你還有另外一台
3. 當負載到達一定程度，可以啟動 auto scaling (本篇不會使用到)
4. 配合適當的 CI / CD, 以及健康檢查，可達到 rolling upgrade 的效果

本篇重點

• 本篇分享最簡單易設的 unmanaged Load Balancer
• 為避免混淆，本篇對於有意義的元件術語，將維持原文，不會特別翻譯
• 詳解每個元件行為

簡單的概念圖如下 (圖片來源： Google )：

1. IPv4 以及 IPv6 的使用者，對我們的服務發請求
2. 我們設定的 IPv4 以及 IPv6 Forwading rules，會將使用者導向我們設定好的 HTTP(S) proxy
3. 到了 HTTP(S) proxy 的 request, 會根據我們設定好的 url-map 規則，導向相對應的backend-service, 例如說， 透過 domain name 為 'test1' 的 request, 導向backend-service 1, 而 'test2' 的 request 導向 backend-service 2
4. backend-service 由 instance group 組成，舉例來說，我們可以指定， backend-service A 導向 instance group A 的 port 8000 , 而 backend-service B 導向 instance group B 的 port 6000
5. instance group, 顧名思義，由 instance 所組成，當我們在 instance group 中設定好特定的 port, 並且設定好 backend-service, 那麼 request 將會經由 backend-service, 再到 instance group 指定的 port, 最後到依照 instance 本身的負載狀況, 將 request 導向適合服務的 instance
6. 每個 backend-service 都可以設定一個 health-check, health-check 會根據指定的頻率向指定的 port 探測並取得回應，如果回應的速度低於我們設立的門檻，那麼該 instance 就會被判定為不健康。 request 不會導向已被判定為不健康的 instance
7. 如果有 SSL 需求，可建立 SSL certificate, 並且掛在 HTTPS proxy
8. 以下我們就開始來實作吧!

安裝 Google Cloud SDK

本篇所有的指令都會使用到 Google Cloud SDK 的指令, 所有在我們開始之前，先安裝它哦！ 根據你的作業系統的不同，安裝方法也不一樣哦，請參考官方文件

建立 instance

• 建立兩個 instances

1. 建立二台機器, 叫做 test-01, test-02
2. 開機碟的空間為 30GB
3. 從 ubuntu-os-cloud, 來 pull 我們需要的 image
4. 我們使用 ubuntu-1804-lts 的 image 版本, 這會自動使用這個版本的最新版
5. 硬碟類型為 pd-standard, 不知道類型可以跑 gcloud compute disk-types list 來看看
6. 機器型號為 f1-micro, 不知道類型可以跑 gcloud compute machine-types list 來看看
7. tags 用來當作該 instance 的一個識別，等等開防火牆的時候會用到
8. zone 指定該 instance 的地區, 有些資源只有相同 zone 或者 region 可以取用，要注意
9. 可參考官方文件

instance 環境建置

以下為 instance 上的環境建置範例，與本篇主題較無關係，可跳過

開啟防火牆

看服務跑在哪一個 port, 我們需要將防火牆打開，這樣 instance group 才能將 request 從 Load Balancer 經由 backend-service 導向相對應的 port, 可參考官方文件

外部靜態 IP

這邊建立一個 IPv4 的靜態 IP , 之後會用到, 可參考官方文件

Instance group

Instance group 可由多個 instance 所組成，為組成 backend-service 的主體, 可參考官方文件

• 建立 instance group, 之後 Load Balancer 可以用它來建立不同的 backend-service

• 設定 named port, 所以不同的 backend-service 可以指定要用哪一個 port

• 將現有的 instance 加到 instance group

Health check

health-check , 可根據我們指定的頻率，探測指定的 port, 如果該 port 無回應， health-check 將判定這個 port 不健康， backend-service 不會將 request 送往不健康的 instance

可參考官方文件

Backend service

這邊的 --port-name, 就是上面我們在 instance-group 中，建立的 port, 在此範例中，不同的 backend-service 會將 request 導向不同的 port, 這邊看起來沒有提到 instance group ? 別緊張，下一步我們就會把 instance group 加到 backend-service 當中。

同理， health-check 也是掛在 backend-service 上的, 因為 backend-service 將決定要將 request 導向哪一個 instance。可參考官方文件

• 建立後端服務

接下來，我們將 instance group 加到我們剛剛建立的 backend-service, 因為我們在建立 backend-service 時就已指定了 port, 所以 backend-service 會將 request 導向所屬的 instance group 中已指定的 port, 嗯, 聽起來有點饒舌, 不過的確是這樣。

除了設定導向的 port 之外，這邊也會設定 instance 的負載門檻。 設定 UTILIZATION 表示使用率，當使用到 80 % 時， backend-service 便會停止將 request 導向這個 instance

capacity-scaler 表示， 1 * 0.8, 所以說，如果你有多個 backend-service 使用這個 instance-group, 那你希望多保留一些 instance-group 的可使用率，給其他 backend-service 使用，那就可以將 capacity-scaler 調低，如此一來，當這個 backend-service 已使用了 capacity-scaler * max-utilization 的 CPU 時，來自於該 backend-service 的請求就不會導向該 instance-group, 可以很大程度地保留該 instance-group 服務其他 backend-service 的可用性。

下面範例，可參考官方文件

• 將 instance group 加到 backend-service

URL map

前面介紹完了 backend-service, 那這個 url-map, 就是將 request 導向 backend-service 的元件。

首先，我們要先建立一個 url-map, 並且給予一個默認的 backend-service, 意思就是說，如果沒有特別指定的話，收到的 request 要導向哪一個 backend-service

下面範例，可參考官方文件

• 建立 URL-map

上面建立了 url-map, 並且指定了一個默認的 backend-service, 現在我們可以定義怎麼樣的 request 該導向哪一個 backend-service。

路徑的指定，我們需要使用 path-matcher, 範例如下：

path-matcher: 建立一個 path-matcher, 並給予指定的路徑規則

new-hosts: 當 request 是對 host sunday.com.tw 發請求時，會套用此規則

所以就是說, 當 request 的 host 為 sunday.com.tw 時，會導向 backend-service-port1

以下為範例，可參考官方文件

• 新增 path-matcher

這邊可以看到比上面多了一個新的元件，叫做 path-rules

當 request 的 host 為 monday.com.tw, 默認路徑如 / 會導向 backend-service-port2

當 request 的路徑為 happy, 如 monday.com.tw/happy, 會導向 backend-service-port1

當 request 的路徑為 unhappy, 如 monday.com.tw/unhappy, 會導向 backend-service-port2

當 request 的路徑為 sad, 如 monday.com.tw/sad, 會導向 backend-service-port3

以下範例同上，當 request 為 tuesday.com.tw 時，導向 backend-service-port3

建立 SSL 憑證

要讓我們的服務支援 HTTPS, 我們需要建立 ssl-certificates, ssl-certificates 分成 self-managed, 以及 google-managed。

self-managed 顧名思義就是你提供你自己的 ssl 簽證，以下範例採用 google-managed

可參考官方文件

HTTP proxy

所有來自 HTTP 的請求，都會先到這裡，再經由我們剛剛建立的 url-map 導向指定的 backend-service

可參考官方文件

• 建立 HTTP proxy

HTTPS proxy

所有來自 HTTPS 的請求，都會先到這裡，再經由我們剛剛建立的 url-map 導向指定的 backend-service

並且，我們剛剛建立的 ssl-certificates 也要掛在這, 這樣 target-https-proxies 才能支援 HTTPS

可參考官方文件

• 建立 HTTPS proxy

查看外部靜態 IP 清單

列出我們一開始建立的 addresses

可參考官方文件

轉發規則

當 request 的 address 以及 port 符合 forwarding-rules, 導向指定的 target-http-proxy

下面範例的 [LB_IP_ADDRESS] 請替換為上面建立的靜態 IP

可參考官方文件

• 建立 HTTP forwarding-rules

當 request 的 address 以及 port 符合 forwarding-rules, 導向指定的 target-https-proxy

下面範例的 [LB_IP_ADDRESS] 請替換為上面建立的靜態 IP

可參考官方文件

• 建立 HTTPS forwarding-rules

總結

以上便是 GCP Load Balancer 的 gcloud 各元件順序流程，順序如下： request => forwarding-rules => target-http(s)-proxy => url-map => backend-service => instance-group => instance

照著以上範例跑完之後，只要在 instance 跑服務，並且跑在範例上指定的 port 號，那 request 應會照著上面的順序到達我們的服務。

我花了不少時間來寫這篇文章，希望有幫到需要的人，如果你已經看到這裡，很感謝你把它看完了！

如果有發現任何錯誤，還請不吝指教哦！

請不吝你的掌聲

如果覺得本文寫得不錯, 或是有幫到你的地方, 對你來說無價的掌聲, 對我來說也是無價的！

普通： 拍個 10 下意思意思！
還可以： 拍個 20 下交代交代！
不錯誒： 稍微有感情的 30 下！
很好： 真誠的 40 下！
棒透了： 瘋狂的 50 下連擊！

小技巧: 按著不放就可以連拍哦, 輕鬆愜意~

Write Medium in Markdown? Try Markdium!