[k8s] Kubernetes 和雲端運算

在之前, 當我們說到雲端,
想到的是一套虛擬機管理系統 (如: OpenStack),
提供不定使用者按照需求的計算資源 (以虛擬機的數量和規格計算),
隨著雲端的發展, 網路虛擬化加入 (基於 OpenVSwitch 或是 SDN 技術),
因此, 網路資源的使用與計費也加入雲端運算的列表中,
並開始有基於流量的 scaling 技術成熟,
使得 "按需求計算 (On demand)" 變成 "動態調整計算 (Auto-scaling)."

一般而言, 雲端運算仍圍繞著虛擬化的概念打造, 尤其是虛擬機,
透過虛擬化技術, OpenStack 可以將硬體資源切割成多個獨立的單元,
保證各運算單元之間的獨立性, 以及所可以取用的計算與網路資源,
提供遠端使用者一致的介面進行操作,
然而, 虛擬機也成了雲端運算的瓶頸, 考慮到所帶來的 overhead,
當計算需並非隨時間改變時 (通常一說是工作週期 > 0.3~0.5),
自己建構伺服器就變得更為有效的選擇.

對此, 雲端運算有兩種回應方式,
例如 OpenStack 使用的 KVM 技術就走向半虛擬化 (共享 Linux kernel),
或是更極端的, MaaS (Metal as a Service) 直接租借實體機,
這些不同的變化, 一方面讓雲端有更多樣的選擇,
另一方面也反映出雲端運算所受到的限制.

在所有的虛擬化技術中, Container 是一個有趣且有潛力的方法,
其中, 最為大家熟知的 Container 技術大概是 docker,
然而, Container 事實上並不是一個新的技術, 也不一個為了虛擬化所研發的方法,
其技術比較像是一組設定, 將一群執行續困在一個沙盒中,
藉由限制其對系統資源的存取以及網路虛擬化,
來模擬一個虛擬的計算空間, 稱為 Container.

和傳統的虛擬化技術不同, Container 並沒有虛擬完整的 IO 介面,
比較起來, 更近似於一群程式, 因此, 無法直接復用 OpenStack 等既有系統,
但是, 就如虛擬機透過雲端擴展的計算潛力, 以及巨量應用,
Container 也需要一個跨實體機的系統調度資源平台, 才能提供 On demand 的應用,
這也是 Kubernetes 創立的動機與環境.

考慮到已有許多文章在介紹 Kubernetes 的建置, 操作, 與管理,
本系列文章會把重點放在以下五個項目:
  1. Container 的虛擬化技術, 著重在和虛擬機的不同以及其限制
  2. Kubernetes 的架構, 比較和 OpenStack 的差異以及其原因
  3. Kubernetes 和 OpenStack 在網路虛擬化上的差異
  4. Kubernetes 和 OpenStack 在計算框架上的差異, 著重於 auto-scaling 和 cluster 架構
  5. Kubernetes 如何提供基於輸入流量的平行化與 auto-scaling 機制
事實上, 以上 5 點仍有許多是筆者目前仍未釐清但好奇的部分,
也就作為目標, 但是篇幅與文章可能會隨著資料的蒐集和閱讀而異,
希望可以繼續維持至少一個月兩篇的速度, 和大家分享.


留言

熱門文章

LTE筆記: RSRP, RSSI and RSRQ

[WiFi] WiFi 網路的識別: BSS, ESS, SSID, ESSID, BSSID

LTE筆記: 波束成型 (beamforming) 和天線陣列