【東東老師 X 思想科技】建立 Load Balancer 的整體架構和步驟

這裡就假設你已經準備好一台「無狀態的」機器，在上面已架設好 Apache 的網頁，如下範例：

你會看到我的網頁是 HTTP，沒有 SSL 憑證的狀態，這個不用擔心，因為我會把 SSL 憑證做在 LB 的前端上面，而流量進入到 VM，就可以不用再做 HTTPS。沒問題的話就開始後續的動作。

(一) 建立映像檔

首先我們先把 VM 關機，然後去 Image 的頁面。為什麼要關機呢？因為開機時 VM 還是會有對 Disk 的讀寫，這時建立 Image 可能會有讀寫不完全的問題，所以關機再建 Image 比較好。

在命名的部分，建議加上版本號碼，因為以後如果你的網站要改版，你會建很多個 Image，為了方便管理，你可以使用一套命名規則來給 Image 命名。然後指向我們剛建立的主機的 Boot Disk。而 Location 的部分，如果你的 Image 非常重要，建議選 Multi-Regional，像我只是為了 Demo 就選 Regional 即可，沒問題就按下 Create。

另外因為 Google 會把所有 VM 的公開 Image  (如 Debian、Ubuntu…) 都放在同一個頁面，所以你很難找到你剛建立的映像檔，你可以把 Project ID 複製起來，貼到 Filter，指定欄位 Created By，再貼上 Project ID，按下 Enter，就能快速找到你建好的 Image 如下：

(二) 建立執行個體範本，指向你的映像檔

點擊 Compute Engine => Intance Template。

在命名的部分，就依照你的命名原則來設定，例如也加上版本號碼，跟 Image 對齊。Location 指的是，你的 Template 要存在哪裡？Template 只是一個小小的設定檔，不是真的機器，也不會佔儲存費用。它提醒的是，如果你存在 Global，有可能你要用的時候，剛好別的 Region 壞掉了，那你取得 Template 的時間會比較長，因為要等它從其他 Region 拿過來，所以建議你選 Regional。但如果選只台灣 Region (asia-east1) ，萬一台灣的壞掉，就拿不到 Template 也是很麻煩，

那這樣不是選 Global 比較好？其實不管選哪個，實際上 Template 拿不到的機率很低，所以選哪個都可以。

接下來選擇規格，我是為了 Demo 而選擇最便宜的 f1-micro。

接下來 Placement Policy 的部分，是在問你在同一個 Zone (機房) 裡，主機要不要集中在同一台實體機上。

這裡分成兩種：

1. No Policy

主機「可能」會放在不同的實體機上，因為 GCP 會因應客戶持續不斷的開機需求，去分配機器開在哪裡，如果不指定，主機有可能會開在同一台實體機上，那實體機有問題，上面的主機會同時無法運作，算是風險比較高的。

2. Spread

主機「一定」會放在不同的實體機上，這樣就不會因為某台實體機的問題，讓你的主機同時不能運作，比較保險，那我們就選 Spread。接下來是最重要的 Boot Disk，要指向你建立的 Image。在這裡你可以選擇用哪種 Disk，以及它的大小。但要注意，Instance Template 是建立完成後，就不能再回來改的，如果你設定錯誤，就必須要重新建立 Template，所以這邊要小心設定。

接下來是 Identity and API access 就照你原本 VM 的設定，如果你原本就沒有調整，那就保持預設即可。

在 Firewall 的部分，請同時把下方 Advanced options 和 Networking 展開。在這裡，HTTP 和 HTTPS 是完全對外開放的，不限任何的 IP 來源。但我們的主機只要允許 Load Balancer 的流量進來就好了，所以這邊不要打勾。

那下面還有一個 Allow Load Balancer Health Checks 是不是應該勾起來？它是要幫你檢查主機是否健康的機制，它的流量會從特定的網段過來，這裡勾起來就會自動允許那個來檢查的網段 35.191.0.0/16 和 130.211.0.0/22。但是我建議不要勾。

我的做法是，你一定要設定專屬的網路標記 (Network Tag)，這樣你未來才方便調整套用到 IG 的防火牆規則，你想開什麼協定、哪一個 Port、從什麼網段，你都可以在防火牆規則的頁面自由調整，例如我在這裡設定 apache-1，

我如果要調整防火牆，我就在相關的防火牆規則加上 “apache-1” 這個標記就好了，因為你的 Template 是完全不能修改的，防火牆設錯就必須刪除重建，毫無任何彈性，還不如只設定專屬的網路標記，未來防火牆想怎麼改就怎麼改，方便很多！

後面設定防火牆的部分會再詳細說明。

在 Networking 下方的 Network Interfaces 部分，這邊看你是否要部署到特定的 VPC 或 Subnet ，再視情況調整，重要的是 IP 要改成 None，為什麼不要 IP 呢？

因為 Load Balancer 會用一個 IP 專門對外服務，所以你不需要給 Instance Group 的機器再分配外部 IP，不然會變成，你已經有 LB 的 IP 對外，同時你的每一台主機也都有外部 IP，這樣有人就可以繞過 LB 直接到達你的主機，是有資安疑慮的。所以請把外部 IP 設為 None，沒問題的話再按下 Done。

這裡小小補充一下，針對上述 Instance Template 的建立，你也可以在 Management 的 Automation 當中，使用開機指令碼 (Startup-Scripts) 設定到執行個體範本，不用 Image。每當 IG 擴充機器時，機器會自動執行 Startup-Scripts 的指令，自動連線到某個地方安裝應用程式或抓取程式碼。不過每次開機器時，你必須要等它花時間抓到相關檔案，並且安裝設定完成，才能對外服務。

萬一它連線或安裝異常，你還要「趕快」人工連進去除錯，是「每一台擴充出來的機器」都要除錯，因為 Load Balancer 要送流量進來了，你不趕快調整，新的用戶就會進到有問題的機器，反而導致你可能會手忙腳亂。所以還是建議直接使用都安裝設定完成的 Image，是比較好的選擇，這裡我們就不做任何設定。

至於其他的進階選項，看你有沒有特殊需求，再調整即可，不然就保持預設，點擊最下面的 Create，就建立完成了。

(三) 建立執行個體群組，使用你的執行個體範本

進入執行個體群組頁面後，選擇無狀態的 (Stateless)，然後選擇你的 Instance Template。

Location 請選擇 Multiple Zones，因為你既然要 Autoscale，就是想提高可用性，你不會把所有機器都集到同一個機房 (Zone)，在這裡你就應該選擇 Multiple Zones，讓機器橫跨 A、B、C 三個 Zone，萬一有個 Zone 無法連線，其他 Zone 的主機還是可以對外服務。

在可用的選項中，包含 Even 和 Balanced 兩種：

(1) Even 

指的是 IG 會 100% 做到機器都平均分散三個 Zone 中，使命必達的概念。

(2) Balanced 

指的是 IG 會「儘量」做到機器都平均分散三個 Zone 中。為什麼說「儘量」？

因為它會考慮每個 Zone 的資源可用性，例如 CPU、記憶體和 Disk 是否足夠，以及其他資源包含配額、硬體、成本等，然後把機器開在相對足夠的 Zone，所以和 Even 比起來，「比較不平均」，但保留了一點開機器的彈性。像是台灣 Region asia-east-1 的 Zone B，因為是預設選項，所以經常機器被開滿，所以選擇 Balanced 是比較好的選項。

至於 Allow Instance Redistribution 是什麼意思？指的是你的主機會被 IG 主動重新分配，就是它會自動從機器多的 Zone 刪除機器，再增加到機器少的 Zone。

假設你有 12 台機器分布在A、B、C 三個 Zone，每個 Zone 4台。如果你不小心刪掉了 Zone C 的 3 台，IG 會這樣調整：

(1) 從 Zone A 和 Zone B 各刪掉1台

(2) 在 Zonce C 新增 2 台

(3) 這樣每個 Zone 就又都是3台了，達到平衡。

要注意你只是刪掉 3 台機器，它又主動多刪掉你 2 台，整體運作能力會暫時下降。因為你的機器並沒有異常，就這樣突然被刪掉，再去另一個 Zone 開起來，反而讓你的系統不穩。所以當你在 Target Distribution Shape 選擇 Even 時，為了保持平均，它才會問你要不要勾 Allow Instance Redistribution，

當然我建議不用勾選，確保系統穩定比較重要。如果你選 Balanced，預設就不會再給你選擇 Redistribution 了。

接下來是 Autoscaling Mode，它問你三種模式要選擇哪一種？

(1) On：自動增加也自動縮減機器

(2) Sacle out：自動增加機器，但不自動縮減

(3) Off：不要擴充也不要縮減

選 (1) 的話，流量增加會增加機器，流量減少會自動減少機器，我們可以理解除了增加可用性，也是為了節省成本。

選 (2) 則是為了穩定性考量，怕下次流量突然爆增，所以機器寧可增加也不要縮減。

那選 (3) 是為了什麼？一方面是成本考量，不要多開機器，另一方面，如果機器有問題，IG 會自動刪掉它然後重建，就是你的服務不管碰到什麼問題，它都會一直復活，至少你不用人工進去處理，還是節省不少你維護的時間。

所以三個選項各有考量，我們在這裡就選擇 (1)，自動增加和縮減機器。

Minimum/Maximum number of instances 就是你整個 IG 機器數量的上下限，我們就先設定1～3 台。

Autoscaling signals  指的是觸發你擴充機器的時機，有 4 種 Signal Type 可以選擇：

(1) CPU Utilization

指的是 IG 裡所有機器的 CPU 使用率，是最基本的選項。

(2) HTTP Load Balancing Utilization

指的是 LB 的使用率，它並不是特定的效能指標，它包含 CPU、網路流量、HTTP Session 數量、每秒請求數 (RPS) 和 Disk I/O，由 GCP 綜合考量所計算出來的指標，所以不會只偏重單一指標，是從整體角度來看。

(3) Cloud Pub/Sub Queue

這部分和資料處理管道 (Pileline) 有關，例如你的主機是拿來做串流資料 (Streaming Data) 處理的，前端資料來源都從 Load Balancer 進來，然後分散給不同的機器來處理，這裡就是確認每台機器收到多少消息，包含還沒處理完的訊息，因為前端的資料量可能時大時小，如果累積的訊息太多，機器會來不及處理，就可使用這個指標讓它自動擴充機器來幫忙處理。

(4) Cloud Monitoring Metric 

指的就是 Cloud Monitoring 的指標，都可以拿來判斷是否要擴充機器，以前只能用 CPU 來判斷，但有些機器可能是記憶容易飆高，這樣用 CPU 判斷就不夠精準，你就可以選擇其他指標例如記憶體使用率 (Memory Usage)，或進來的網路流量 (Ingress Bytes) 等等。

如果你只是在測試，想要讓 Autoscale 馬上發生，可以直接調成 5%，在此我們就先使用預設的 CPU Utilization 60%。

Predictive Autoscaling 指的是透過預測來提早擴充，它會依照你過去主機擴充的指標，例如上面設定的 CPU 使用率，我們原本設定 60% 才擴充，它可能 CPU 到 58% 的時候，就預測可能要超過 60% 了，於是提前擴充機器。這樣的好處是，你原本的機器就不會因為新的還沒擴充出來，自己在那邊獨撐大局，造成機器不穩定的狀況。

不過它需要你的歷史資料，用來建立機器學習的模型，才方便預測。所以你的服務至少要開 3 天以上，才有足夠資料讓它可以訓練。在這裡我們就選擇 Off 即可，這段沒問題就可按下 Done。

Autoscaling Schedules 是依照時間來自動擴充的功能，如果你能確定流量較大的時間，例如每天晚上八點到十點，你就可以設定此功能。但我們現在是依照 CPU 的負載來決定是否擴充，這兩個功能是互斥的，所以就不能再設定它。如下圖它呈現反灰的狀態。

Initialization period 指的是新的機器擴充要等它多久，每一台新擴充的機器，都是需要跑一遍開機過程的，所以要預留時間等它開好。因為開機時，機器是很忙的，CPU 一定都會飆非常高，像我今天的 custom-vm 剛開機時，CPU 已經飆到 93%。

如果這個值設太短，例如 5 秒鐘，那新的機器還在開機當中，CPU 還是很高，追成 IG 誤判它 CPU 飆高，所以當場又決定再擴充一台新的。代表你新的機器還沒開好，又再開新的，如果每一台都要開機很久，它就一直開新到直到上限開好開滿。但是如果你時間設太長，你又要等很久才能確認總體的負載，

萬一用戶流量突然爆增，你的擴充又會來不及。所以針對這種情況，你需要測試你的主機，從開機到準備對外服務，差不多要多久，越精準越好，才能兼顧擴充速並並減少誤判。在這裡我們也依照預設的 60 秒即可。

Scale-in controls 就是反過來，關於機器縮減的速度控制，你的用戶流量突然降下來，但沒多久又飆上去，這時如果機器自動縮減了，會來不及再次擴充出來應付流量。這裡就是為了防止機器太快縮減，設定的緩衝時間，例如我們設定 10 分鐘內不要刪除超過 1 台機器，或 50% 的機器。

VM instance Lifecycle 指的是設定主機有狀況的時候，要做哪些反應。Default Action On Failure 指的是因為我們已經設定要 Autoscale 了，所以主機有問題 (Fail) 的話，它固定就是會 Repair Instance。要注意字面上是「修復」，實際上它就是把機器刪掉，再重新建立。它沒有那麼好會去幫你 Debug 啦 XD！

在 Autohealing 的部分，承上提到的 Fail，GCP 是用它自己的標準來判斷是否 Fail。我們通常是透過「健康狀態檢查」(Health Check) ，明確地判斷它「健康」或「不健康」，再決定要不要「修復」你的主機，如果你之前還沒建立過 Health Check，可以在這裡點擊建立。

當我們進入 Health Check 之後，首先給它命名。在 Scope 部分，是依照 Load Balancer 的屬性來決定的，我們後續是要建立 Global 的 LB，所以我們在這裡也選 Global。而 Protocol 部分，因為我們是網頁，你可以選擇 HTTP 或 TCP，但我們「一定要」選 HTTP，因為它能夠檢查你的網頁回應碼是不是 “200 OK”。

如果你選 TCP，那網頁可能是 404 Error，而檢查結果仍然是「健康」，那就是誤判，所以千萬不要選錯。至於 Logs 的部分，就是記錄檢查成功或失敗的 Log，你可以視情況決定要不要勾，在這裡我就勾起來。

Health Criteria 就是你的判斷基準，怎樣叫健康，怎樣叫不健康。例如預設值提到的，每 5 秒鐘檢查一次你的網頁，然後等 5 秒鐘看有沒有回應 “200 OK”，如果連續兩次都回應 “200 OK”，則視為「健康」；如果連續兩次都不回應 “200 OK”，則視為「不健康」；那如果介於兩者之間呢？那就是繼續等它檢查結果，直到確定是否健康為止。如果沒問題就可按下 Save。

Updates During VM Instance Repair 指的是我們的應用程式會改版，在 IG 上就是會更換 Instance Template，這裡是問要不要趁主機因為異常而重建的時候，順便開新版的機器。你可以 Keep the same instance configuration 保持舊版，或是 Update the instance configuration 順便換新版。這要取決於你的 CI/CD 版本控管政策來決定。在這裡我們只有一個版本，所以保持預設值即可。

Port mapping 是設定 Load Balancer 進來的時候，是經過哪一個 Port，你可以先給它取個名字，或是設定 LB 的時候再設定也可以。我們就先設定 Name 為 http，Port 設定為 80。如果沒問題，就可以按下 Create 了。

接下來它會切到 Instance Group 的畫面如下：

我們再點進去，你會看到它目前顯示 0% Healthy。不要懷疑，這是正常的！因為防火牆還沒開放 Health Check 的網段來存取主機的網頁。

我們可以再點右邊的 Errors，查看錯誤訊息。如果你不知道為什麼它顯示不建康，都可以從這裡查到。

另一方面，我們也可以去 Cloud Logging 查看，點擊 Instance Group，你會看到因為 IG 檢查不到主機，所以視為「不健康」，觸發它刪掉原有的主機，然後再重建，結果又檢查不健康，再次刪除重建……。

我們把 “healthCheckProbeResult” 這個 Log 展開，會看到它的檢查結果，上面有註明是從哪裡來檢查的，以及它去訪問哪一個 IP。

接下來，我們就去設定防火牆，讓 Health Check 可以找到主機。注意我們是點擊「防火牆規則」，不是「防火牆政策」喔！！

命名通常是越清楚越好，例如命名為 “detault-allow-health-check-http”，其中 “detault” 是每個 Project 裡第一個 VPC 的名字。Log 可以打開，你可以確認每一次檢查主機的結果。順序就保持預設的 1000，方向是 Ingress，代表進入某台主機，動作就是 Allow。

Target Tag 是關鍵，我們在這裡要設定跟 Instance Template 一模一樣的 Tag，這樣規則就可以套用到這個 IG 所有主機了。接下來設定 Health Check 的來源網段為 35.191.0.0/16 和 130.211.0.0/22。

Health Check 要檢查的 Port 是 80，所以這裡就設 80，其他 Port 不用開，然後按下 Create。

防火牆生效的速度很快，過沒多久，IG 的檢查狀態就變成 Healthy 了。

我們也去 Log 看一下，它也顯示為 Healthy。

我們也可以去 Compute Engine 頁面，IG 開的機器也會列在這裡，你可以看到它的命名規則是 “IG 的名字 + 隨機英數4碼”，如果到時有 Autoscale ，產生新機器的話，也是用這樣的方式命名的。

(四) 建立負載平衡器，接到你的執行個體群組

1. 設定精靈

我們就直接從 Network Services 進入 Load Balancing，點擊建立 LB。

它會先問你，要用 Application Load Balancer 或是 Network Load Balancer，你只要是網站使用 HTTP 或 HTTPS 協定的就用 ALB，其他協定或 Port 就選 NLB。

第二個問題也很簡單，你的網站是對外就選 Public，如果是對內就選 Internal。會有 Internal 嗎？有的，如果你的系統架構有拆前端 Web 主機和 AP 主機的話，那 Web 主機可設定為 Public，AP 主機可設為 Internal，這樣 AP 主機就不會直接對外，提高安全性。

再來是你的服務對向是全球的，還是只針對特定區域，例如只有台灣？

如果你有國外的巿場，你可以將主機同時部署在多個 Region，這樣 LB 可以依照用戶所在的位置，就近轉發到最近的主機，快速回應用戶。在這個範例裡選哪一個都可以，在這裡我們就選 Global。

在這裡我們要選 Global External ALB 或 Classic ALB，但兩者界面其實差不多，只是 Global External ALB 有強調進階流量管理，可以寫語法來做到更複雜的功能，例如依照封包標頭導向不同機器 (Header-Based Routing)、依照權重分流 (Weight-Based Splitting) 等等。在這個範例裡選哪一個都可以，也沒有價格差異，我們就選 Global External ALB。

接下來再次確認你的選擇有沒有錯誤，沒有就按 Congifure，開始設定 LB 的細節。

2. 前端 (Front End) 設定 (包含 IP 和 SSL 憑證)

現在進入前端設定的部分，左邊給 LB 命名 “lb-1”，右邊則是對前端命名 “fe-1”，在 Protocol 部分，我們原本的網站是 HTTP 的，因為我們要把 SSL 憑證做在 LB 上，讓 LB 來處理 SSL 加密，所以這裡務必選擇 HTTPS。

PS. 假如你現在還沒有自己的 DNS 網域，而且只是為了練習的話，請選擇 HTTP 就好。

IP 也務必要固定下來，所以我們把 “Ephemeral” 改成 “Create IP Address”。

然後我們給 IP 取名字，例如 “lb-ip”， Google 會從它的 IP Pool 中挑選一個發配出來。

再來就是 SSL 憑證，我們點擊 “Create A New Certificate”。

它會轉到建立憑證的視窗，我們先給憑證命名 “cert-web1”，在建立模式檔中，如果你自己有另外購買憑證，可以直接上傳，但憑證的展期你要自己再次上傳。如果你用 Google 的憑證，就可以自動展期，一勞永逸。下方要設定你的網域，在這個範例中，我們使用 “web1.dongdonggcp.com”，然後按下 “Create”。

PS.不要輸入跟我一樣的網域喔！如果你自己沒有網域，記得前面的通訊協定選擇 HTTP 就好，因為它後面會要求你驗證 DNS 的 TXT Record。

回到原本前端的頁面，這時我們勾選 “HTTP to HTTPS Redirect”，代表如果有人在瀏覽器輸入 “http://web1.dongdonggcp.com 的話”，它可以自動導向 “https://web1.dongdonggcp.com”。

如果沒勾，它會打不開網頁喔！因為兩者本來就是不同的 Port (連接埠)，就像不同的碼頭，你停錯碼頭就找不到店家，網頁就進不去。其實像 Open Source 的 Web Server 例如 Apache、Nginx 或 IIS，很久以前就已經有這個功能了，而 GCP 的 LB 後來也在用戶的建議之下，做到可以一鍵勾選，提高了方便性，設定好之後就按下 Done。

它回會到 LB 的主畫面，接下來我們按下 “Beckend Configuration” 進行後端的設定。注意這裡的「後端」是從 LB 的角度，指的是要迎接流量進來的主機群，而不是後端 AP 主機或資料庫的意思。

3. 後端設定 (包含 Cloud CDN 和 Cloud Armor)

我們展開下拉式選單，點擊 “Create A Backend Service”。

它會跳出建立「後端服務」的視窗，注意一個「後端服務」，可以接多個「後端」，「後端服務」指的是 LB 的組成部分，「後端」則是連接的 IG，這裡不要混淆喔！在通訊協定的部分，我們原始主機就是用 HTTP，所以就選 HTTP，注意這裡很容易選錯，選錯就不會通喔！

接下來設定「後端」，我們選擇我們建好的 IG 名稱 “apache-ig-1”，你會看到它自動帶入 Port 80，這是我們在建立 IG 時就預先設定好的。

接下來是設定平衡模式，就是 LB 要怎麼分流的意思。你可能會想，LB 不是平均分配流量到不同機器嗎？

為什麼還要設定如何分流？要注意，同一個 IG 裡面的機器，是可以平均分配的，這裡提到的是「不同 IG 之間的分流」，它是說如果第一個 IG 已經達到最大利用率 (Utilization) 之後，會再把流量送到第二個 IG，所以不同 IG 之間，收到的流量可能會不同。而在這個範例當中，我們只有一個 IG，所以不需要特別設定，保持預設即可。

沒問題就按下 “Done”。

接下來進入 Cloud CDN 的部分，我們就直接勾選 “Enable Cloud CDN”。

在 Cache Mode (快取模式) 的部分，通常我們選 “Cache Static Content” 即可，而首頁經常會變動，所以這個選項並不會 Cache 首頁，但我們在這個範例只有首頁這張網頁，為了要示範 Cloud CDN 的效果，所以故意去選 “Force Cache All Content”，這樣我們到時候就可以看到首頁被 Cache 的樣子。

下面的 Client TTL 是指內容在用戶端瀏覽器存留的時間，瀏覽器會記錄某個內容已經存在多久，如果超過某個時間，例如一個小時，它就會再次向 Cloud CDN 確認內容有沒有更新，如果有更新，就會重新抓取，如果沒更新，瀏覽器就會再使用原來的內容。

Default TTL，指的是內容放在 Cloud CDN 上存留的時間，如果超過某個時間，例如一個小時，它就會再次向原本的主機確認內容有沒有更新。在這裡我們都保持預設即可。

再往下又出現一個 Health Check，這跟我們在 IG 設定的 Health Check 有什麼不同？這裡是要給 LB 判斷，這個後端的 IG 整體是否健康，健康的話，才會送流量過來。原本 IG 的 Health Check 是看主機是否健康，不健康就會刪除重建機器。所以同一個 Health Check，但在不同地方，發揮的效果是不同的喔！

再往下問你要不要啟動 Logging 功能，這裡是指後端服務，有被存取的話都會記錄。它還提供 Sample Rate (取樣率)，因為 Log 量可能會很大，如果每一筆都記，資料量太大也會花很多錢，所以它貼心地讓你設定 0~1 之間的數值，例如 0.1 代表每 10 筆記錄 1 筆，就可以節省成本。在這個範例只是要測試它的效果，所以我們還是設為 1。

接下來這邊你可能看不出來，這是在設定什麼功能？這其實就是 Cloud Armor，它預設就自動帶入 “Default Security Policy”，這個 Policy 的詳細內容就是下方的 “Name” 和 “Throttle Action Settings”，就是節流閥的意思。預設是說， 如果一分鐘之內，每一個 IP 如果有超過 500 個 Request 進來，超過的部分就禁存存取。我們在這個範例想要測試它的效果，所以就乾脆不要設定 “IP Address” 了，我們改成 “ALL”，代表不分 IP，只要整個後端服務在一分鐘之內，只超過 500 個 Request 就開始拒絕。接著我按下 Create。

這樣我們 LB 後端就設定好了，接下來進入 Routing Rules。

4.分流規則

因為我們只有一個前端和一個後端服務，從頭到尾只有一條路，所以不用再做任何設定。如果你有多個後端，例如有 web1.dongdonggcp.com 和 web2.dongdonggcp.com，那我們就可以設定 LB，讓它依照用戶輸入的網址，流向不同的後端主機。在這裡我們可以直接點擊 “Review And Finalize”。

我們可以在這裡給 LB 做最終檢查，看看有沒有設定錯誤的地方，比較重要的地方例如：前端是 HTTP 或 HTTPS、憑證是否有設定好，以及後端 IG 是否正確、是否使用正確的 Port 等等。因為設錯要再改會很花時間，所以建議多看一下，沒問題我們就按下 “Create”。

在等待建立過程當中，你會看到它正在轉圈圈，大約 2 分鐘就會建立完成，但實際上還沒全部完成喔，後面還有一些步驟。

現在我們看到兩個 LB 顯示為綠色勾勾，除了我們設定的 “lb-1”，還有一個叫 “fe-1-redirect”，就是幫我們把 HTTP 轉發到 HTTPS 的功能。我們可以點擊 “lb-1” 進去看看。

你會看到我們剛設定好的憑證，再點進去會看到 “Provisioning” 的狀態，再往下查看網域，顯示為 “Failed_Not_Visible” 的狀態，因為你如果使用 GCP 的免費憑證，它會要求你的網域必須解析到 LB 的 IP。如果沒有就會呈現這個狀態，直到你去設定 DNS，讓它解析成功為止。

設定 DNS 網域解析到你 LB 的 IP 位址

DNS 的設定界面不一定在 GCP 上喔，這裡指的是你註冊 DNS (購買網域) 的地方，你可能用的是 Hinet 的 DNS，或是國外的 GoDaddy 或 Namecheap 等等。像我是在 GoDaddy 註冊 DNS 的，但是我已經轉移管理權限到 Cloud DNS 了。我就直接從 Cloud DNS 點擊進入我的網域。

在 DNS Name 的部分，輸入子網域就好了，例如 “web1”。而 Resource Record Type，我們是要指向主機的 IP 位址，選擇 A Record，其他保持預設。下方則是輸入 LB 的 IP 位址，按下 Create。

文章轉載自《東東GCP 教學》網站