【K8s臺灣企業實戰經驗談：中華電信】因應短暫而量大的預購壓力，以微服務實現彈性部署與標準化維運

雲端服務當道，接連掀起了伺服器虛擬化、容器化、微服務化的風潮，應用系統的開發、整合、測試、上線的速度有了劇烈的提升，承載應用系統的平臺發生量變與質變，在企業IT環境裡面的工作負載，除了支撐日常關鍵應用系統的穩定運作，也面臨更多極端的需求，像是持續時間不長、負載量卻超高的應用服務，越來越常出現，該如何因應這樣的挑戰？

在iThome主辦的Kubernetes Summit大會當中，今年就有兩家臺灣電信業者談到他們導入容器服務平臺的經驗，中華電信就是其中之一，他們目前是將這樣的架構用在既有的預購系統上，而且，建置的平臺是企業級軟體──紅帽的OpenShift Container Platform，不過，即便如此，他們在系統搬遷過程中，仍經歷了預期以外的狀況，有意採用這類環境的企業，若能及早掌握可能影響搬遷作業的各種細節，應能減少出錯機會。

先拿預購系統開刀，因其服務特性很適合移植到雲端環境

身為成立時間最久的臺灣電信業者，中華電信所經營的各種通訊、網路與加值服務，背後都由資訊系統支撐，當中有許多都是十年以上的老舊系統，因此，他們近期開始思考把這些系統搬到雲端服務的環境，而預購系統的搬遷就是率先進行的工程。

為什麼是這套系統先行？中華電信資訊處工程師黃昭文表示，傳統預購系統最大問題就是瞬間的搶訂壓力，許多網站往往承受不住，為了解決問題，業界提出的作法是運用分散式架構，但同時也須面對一些問題，像是網路管理、多臺設備管理、資料庫系統負荷能力、儲存管理，建置這些環境的成本也很高。

第二個考量是預購系統的另一個特性：使用時間很短。一般而言，電信業者的預購系統，運作時間並不長，可能上線為期三天、一週，之後就會下架，若要建置專屬環境，不敷成本效益。

這是一般電信業者預購系統的運作架構，在設計上，是以分散負載的方式來考量，希望能夠妥善消化瞬間搶購的壓力，但需要針對網路管理、設備管理、儲存管理、高可用性的需求，來配置IT資源，搭建成本相當高，而且這類系統服務時間並不長，之後又需要撤下、回收，想要以更經濟的方式快速擴展（縮回）應用系統規模，相當不容易。（圖片來源／黃昭文）

這是中華電信建置的容器服務平臺，他們採用的是Red Hat OpenShit Container Platform，在Kubernetes Summit大會上，他們首度揭露目前系統的架構。（圖片來源／黃昭文）

歷經容器化、解構，進入微服務

在系統搬遷的作業時程上，中華電信規畫了下列3個階段。

第一階段：原貌搬遷

系統搬遷初期，他們對應用系統的調整幅度不大，優先考量服務正常運作。此時主要的工作，是將應用程式的執行環境，從實體伺服器、虛擬機器，搬到OpenShift。過程當中，他們先把虛擬機器當中的應用程式，放到Docker container，再將容器搬到OpenShift。以耗費時間而言，從VM轉到Docker較短，從Docker到OpenShift較久。

關於這階段的搬遷，黃昭文列出7大工作重點。首先是盤點程式行為，因為當應用程式改到OpenShift執行之後，開始會有一些橫向擴充（Scale out）的活動，可能就會相互衝突；其次是參數需重新設計，若能用對參數、改變參數餵送的方式，對於K8s的操作比較友善。

第二階段：系統解構

此時，中華電信開始執行預購系統的解構，提高邏輯的清晰度。相較之下，前一個階段，他們是把整個應用系統包進容器當中，但在這個階段，則是開始進行合理拆解，導入微服務的概念，讓系統上下游之間可透過RESTful API去串接，應用程式當中的不同部分，可以橫向擴充規模。同時，他們也選用輕量的Web應用程式框架，像是Spring Boot來進行改寫，而不再採用WebLogic這類應用程式伺服器。

關於Kubernetes平臺的使用上，黃昭文也特別提醒，要注意Pod的串接數量。他們發現，串連路徑越長，效能折損越大。所謂的Pod是指一群容器的代稱，對於K8s環境而言，是最小的物件模型單位。

他也秀出效能測試的圖表，當Pod串接到兩個站點時，網路呼叫的效能就會瞬間降至低點。若要增加效率，他提出以下幾個建議：我們可以在應用系統上游的呼叫端，導入共用連線（Connection Pool），或是運用非同步作業的機制，也可以在應用系統下游的服務端，採用高效能的應用程式框架。若需要非常高的效能，我們可以多個相關的容器封裝在同一個Pod裡面，如此可以大幅減輕網路流量的負擔。

第三階段：微服務、DevOps

在預購系統的搬遷進入最終階段之際，中華電信期望可以跨入微服務、DevOps的應用。

在此之前，黃昭文呼籲企業應評估自身體質是否適合，確認應用系統架構的調整，究竟是想要還是必要。同時，也要注意單位組織分工的變化，如果是橫向切割，未來在DevOps的流程當中，彼此合作會更為密切，在系統維運的慣性上，IT人員也要有心理準備，因為複雜度可能會提升。

在資料處理的結構與流程，這時也可能需要重新設計。例如，應用程式連接的資料庫系統可能需要拆解，才能支應微服務的存取需求，而拆解之後的資料內容同步，也需要注意。

事實上，這個階段的目標更為宏觀，希望達到獨立開發、高效率部署、維運標準化的要求。黃昭文坦言，其實在中華電信內部有太多系統，每一套系統都有不同維運的方式，對於經驗傳承、未來招募新人而言，都是困難的地方，於是，他們希望應用系統的開發與維運，從需求管理延伸到交付部署，都有一模一樣的流程，對於企業而言，不論是成本或管理考量，都會比較簡單、穩定。

掌握不同環境差異，可少走冤枉路

除了規畫三大階段，黃昭文也列出多項過程當中需注意的技術細節。首先是底層環境，有些商用軟體的登錄機碼或組態授權，會綑綁處理器或伺服器的型號，如果沒有處理好，系統搬移到另一個環境時，可能無法啟動。

軟硬體的相依性上，由於部分軟體授權有處理器核心數量授權限制，因此，若搬遷到新環境，提供的處理器核心數量很多時，也可能無法啟動系統。

系統軟體本身也有一些相依性的議題，那就是與作業系統核心（Kernel）版本之間的捆綁。舉例來說，若底層伺服器的作業系統更新核心，應用系統可能就會受到影響而停擺。

在容器的部份，黃昭文建議，每個容器裡面不要放置太多處理程序，否則當多個容器同時執行，可能會相互干擾。

接著要注意的部份，在於容器的執行權限，以及K8s或OpenShift本身的環境變數，在配置上，應避免與其衝突，因為若發生這樣的狀況，原本自定的部份，將會被系統覆蓋。

容器的Volume設定也要關照一下，當我們包好容器或採用他人的容器之後，請記得打開裡面的組態，例如，查看Dockerfile，確認儲存Volume掛載的位置，以防出現資訊遺漏的狀況。

在Kubernetes的部份，我們要注意ConfigMap的唯讀限制，有些應用程式需要修改設定時，若沒有考慮到這個因素的影響，可能就無法啟動。對於實體儲存配置上，也要關注可用空間的多寡，因為若出現容量不足的狀況，Kubernetes系統會停用Pod。

 相關報導  企業K8s實戰在臺灣