ecs中怎麼配置slb

『壹』 阿里雲ECS伺服器SLB負載均衡實踐

​ 負載均衡構建在原有網路結構之上，它提供了一種透明且廉價有效的方法擴展伺服器和網路設備的帶寬、加強網路數據處理能力、增加吞吐量、提高網路的可用性和靈活性。

擁有大量用戶的企業，經常會面臨如下的難題：在高並發的情況下，經常會導致伺服器響應速度慢，嚴重的情況會直接導致伺服器停止服務。此時，會導致企業的業務中斷，影響客戶的正常訪問。

負載均衡應運而生

<u>需求：本次實驗最低需求兩台雲伺服器ECS</u>

上圖創建了兩台雲伺服器ECS實例和一個負載均衡實例，它們各自擁有各自的彈性IP地址

在瀏覽器兩個頁面分別輸入兩台雲伺服器ECS的彈性IP訪問

比較兩台ECS的訪問結果，發現部署的網站內容相同，只是顯示的後端伺服器IP不同。

在阿里雲登陸界面選擇用RAM用戶登錄

使用實驗提供的 子用戶名稱 和 子用戶名密碼 登陸阿里雲管理控制台

<img src="https://upload-images.jianshu.io/upload_images/20425542-fa1a73a6dc138f09.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240" alt="4.登陸.png" style="zoom:50%;" />

<img src="https://upload-images.jianshu.io/upload_images/20425542-4d17f4b440d7c9a5.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240" alt="5.登陸.png" style="zoom:50%;" />

登錄後點擊左側 導航欄的 產品與服務 選擇 負載均衡

<img src="https://upload-images.jianshu.io/upload_images/20425542-3bad79d4ddfed80d.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240" alt="6.png" style="zoom: 67%;" />

a. 在控制台點擊左側 實例管理 ，在右側頁面中的紅框處看到負載均衡的 公網服務地址

該公網服務地址即為負載均衡實例的彈性IP地址

b.在瀏覽器上輸入a的公網服務地址並訪問

可見後端伺服器IP尾數為131（ECS-2)，但當我們刷新一遍後，如下圖

後端伺服器IP尾數變為130(第二台ECS-1)

當我們不停的刷新，會發現後端伺服器IP 實在這兩台ECS的 內外地址 之間輪流轉換

因為我們在第二步配置的兩台ECS的權重是相同的

下一步我們試著改變兩台ECS的權重不相同看看效果如何

a.進入控制台--選擇負載均衡--實例管理--點擊進入實例--默認伺服器組，進入如下圖所示

b.勾選兩台伺服器--點擊修改權重

c.設置權重 30，90，效果如下圖

d.在瀏覽器中，刷新多次 負載均衡服務地址 的頁面，統計頁面的 後端伺服器IP 。

可以發現：每 4 次刷新，將有 3 次訪問 權重 為 90 的 ECS實例， 1 次訪問權重為 30 的 ECS實例。

用戶可以根據實際情況調整負載均衡器的請求分發，一般將 配置高的伺服器設置的權重調高 ， 配置較低的伺服器設置的權重調低 。這樣可以避免在高並發時，配置較低的伺服器因為壓力較大服務異常的發生。

a.實例管理界面---監聽---修改監聽配置

b.點擊修改

c.開啟會話保持、可選擇修改會話保持超時時間

d.依次點擊下一步，不修改

e. 再次在瀏覽器中輸入 負載均衡 的 IP地址 ， 多次刷新 ，發現在會話保持的超時時間內請求 只會分發到某一台 ECS 上（究竟是哪一台 ECS 沒有規定），時間超出後，重新按照權重比例分發。

a.進入實例

b.點擊停止

<img src="https://upload-images.jianshu.io/upload_images/20425542-e7d5f08534cd1938.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240" alt="28.png" style="zoom:67%;" />

c.返回，顯示如下圖所示，ECS-2已關閉

d.在監聽頁面和實例管理頁面，健康狀態顯示異常

e. 再次刷新瀏覽器中 負載均衡 的 IP地址 ，此時，請求發送到 健康檢查狀態 為 正常 的ECS-1上。

『貳』 阿里slb做為k8s的負載均衡的限制

如果在本地搭建，我們可以使用haproxy+keepalived方式輕松實現k8s中的負載均衡，但是阿里的ecs不能使用keepalived,所以我們被迫只能使用阿里的 slb了。

既然keepalived的方式不能使用，那我們就使用阿里的slb進行負載均衡唄，由於該負載均衡不需要被外部訪問，只提供對k8s集群節點之間的訪問,所以我們就使用私網的slb。
[圖片上傳失敗...(image-b02d7-1604545387128)]

我們保證該slb和k8s集群節點的node屬於同一個區域網內，具體配置如下

第一步就是監聽該slb的6443埠，該埠後端的伺服器組分別是3台ecs的6443埠(apiserver服務)。接著我們可以 在master1節點 上執行如下命令

由於後端伺服器組的 apiserver 都尚未運行，預期會出現一個連接拒絕錯誤。然而超時意味著負載均衡器不能和控制平面節點通信。 如果發生超時，請重新配置負載均衡器與控制平面節點進行通信。

我們在master1節點上創建kubeadm-config.yaml文件，用於初始化控制平面節點，如下。

接著我們在master1節點上執行如下命令初始化

最後結果如下

看上面的日誌好像是kubelet的問題。我們先確認kubelet是否運行,發現處於running狀態。

接著查看kubelet的日誌

發現一個奇怪的問題，https://192.168.4.11:6443提示timeout。

接著我們在master1節點上首先測試本地的6443埠是否已經啟用

看到master1節點的6443埠已經被佔用，接著我們在 master1 節點測試slb的6443埠服務，按理說master1節點的6443服務已經啟用，那麼slb的6443服務也應該是可用可連通的。

遺憾的是slb的6443埠並沒有連通，我們在master2,master3節點上分別連接slb的6443埠，發現都timeout。 我們又找了同一區域網內的另一台ecs，該ecs不屬於slb的後端伺服器，在該ecs上卻能連接slb的6443埠 ，現在問題找到了：

帶著這個疑問我們提了阿里工單，客服最後給出結論。

私網的slb是不可以使用了，我們換成公網slb之後重新按照上述流傳執行一遍，最後初始化控制平面節點成功。

初始化之前slb的6443埠負載的後端伺服器組的6443服務肯定都沒有啟動。
初始化開始後先在本地拉取相關鏡像，隨後apiserver等服務啟動起來，也就是本地的6443服務已經啟動。
接著驗證slb的6443的連通性，由於master1節點的6443服務已經啟動，那麼slb的後端組在健康檢查中就會發現有master1節點6443埠一起啟動，所以slb的6443埠服務也就正常啟動了。

通過上面的描述，在 控制平面節點 上大致需要滿足以下倆點才能初始化成功

優點：可以將kubeconfig文件復制到你筆記本電腦上，進而可以在你本地訪問集群，也正是由於這種方式可能造成安全泄漏的問題。
缺點：apiserver暴露的ip是公網ip，一是各個節點之間溝通的效率變低，二是具有安全性問題。

如果公司非得使用私網的話，我們可以採取這種方式，大概拓撲圖如下

最上層是一個私網的slb,該slb的後端伺服器組為倆個haproxy,使用倆台haproxy可以避免haproxy的單點故障，haproxy的後端伺服器為3台k8s的master節點。

估計看到這里有人會有疑問，上面介紹的私網slb方式會導致四層監聽的後端伺服器無法訪問私網SLB問題，那麼該種方式就不會有這個問題嗎？我們帶著疑問進行測試。

我們准備6台ecs,配置如下

slb監聽6443埠，該埠的後端伺服器組為倆台haproxy並監聽8888埠。

haproxy監聽8888埠，該埠的後端伺服器組為3台控制平面節點並監聽6443埠,haproxy.cfg文件如下。

我們使用haproxy:1.7鏡像，在倆台haproxy所在節點分別執行如下操作：

kubeadm-config文件中controlPlaneEndpoint參數應為私網slb+6443埠，配置文件如下

執行初始化，發現可以初始化成功

以下所有測試在 master1 節點上測試
我們首先測試master1節點的apserver服務，6443埠是否已經被佔用

master1節點的6443埠顯示已經被佔用，接著我們測試haproxy節點的8888埠是否連通

顯示haproxy的8888埠已經連通，接著測試slb的6443埠是否被佔用,發現可以連通

到此說明我們的3層架構都已經連通,說明此方案是可以執行的。

之前提的那個疑問我們現在得到了答案。 但有一點是需要特別注意的

優點：由於中間多了一層haproxy，所以巧妙的解決了私網slb四層監聽的後端伺服器無法訪問私網SLB問題。
缺點：很顯而易見了，中間多了一層haproxy的轉發代理，而且也增加了成本。

現在大概有倆中方式可以實現k8s的高可用，一種是使用公網slb的方式，另一種是使用私網+haproxy+node的方式，這倆中方式各有優缺點，結合自己的實際情況選擇適合的方案。

『叄』 slb配置詳解

我們一起來快速認識一下，負載均衡——SLB。負載均衡SLB是將訪問流量根據轉發策略分發到後端多台雲伺服器（ECS實例）的流量分發控制服務。包含兩種含義：一是通過流量分發，擴展應用系統的服務能力；二是消除單點故障，提高應用系統的可用性。

應用場景
我們具體來看一看它的使用場景。
第一個使用場景的是用於高訪問量的業務。
當你的應用訪問量非常大，單台的伺服器已經無法承載這個訪問量的時候，就可以使用負載均衡，將流量分發到不同的伺服器上去。
第二個場景是橫向擴張系統。
當你已經使用了負載均衡，在業務有波動時可以在後端非常方便的添加和減少ECS來調整自己應用的服務能力。
第三個應用場景是消除單點故障。
當我們在使用負載均衡時，後端有多台ECS在同時工作的。一旦其中一台ECS上的應用發生了故障，那麼負載均衡會通過一個健康檢查的機制來及時的發現這個故障，並且能屏蔽對這台ECS的流量轉發，然後將用戶的請求轉發到另一台正常工作的ECS實例上。
同城的容災
阿里雲負載均衡可以實現同地域多可用區之間同地域容災，當主可用區出現故障是，可以在短時間內切換到另一備用可用區，以恢復服務能力。同時，主可用區恢復訪問時，它會自動切換到主可用區。


跨地域容災
跨地域容災通過雲解析做智能DNS，將域名解析到不同地域的負載均衡實例地址下，以實現全局負載均衡，當某個地域出現不可用時，暫停對應解析即可實現所有用戶訪問不受影響。

配置負載均衡
下面我們來演示一下負載均衡該如何去配置。
首先要做好准備工作，我們需要開通一台負載均衡實例和與負載均衡同一個地域的兩台ECS伺服器。

創建好以後，我們就可以在負載均衡的控制台看到這樣一台實例了。
接下來，我們要給這個負載均衡創建一個監聽。「監聽」可以簡單的理解為對應後端伺服器裡面的一個應用，比如一個網站我們來點擊監聽，然後點擊添加監聽。


假設我們的後端伺服器裡面有一個http的網站前端協議埠，我們可以將前後端協議埠TCP都寫成80，然後根據自己的需要來選擇調度演算法，其實就是流量的轉發方式。

下一步是健康檢查，我們可以選擇TCP方式。

健康檢查埠會默認的和後端伺服器的埠保持一致，直接確認就好了。現在，一個監聽就配置好了。
接下來要去規定這台負載均衡的後端伺服器是哪些。點擊後端伺服器，然後點擊未添加伺服器，將我們剛才創建的兩台伺服器勾選，然後批量添加就可以了。

這里有一個權重需要大家注意一下，這里的權重就是一個比例的概念，如果兩台伺服器寫的都是100，流量將會以1:1的方式被轉發到後端的兩台伺服器上。