Castle on a Cloud

在 前一篇文章 中, 我們說到 container 技術可以減低虛擬機的 overhead, 因此, 下一個問題就是, container 是怎麼做到的? 其技術特徵和虛擬機的技術差異為何? 事實上, container 的概念主要來自於 linux 的多工與分離, 就像是我們高中程式課在工作站寫 c code 的經驗, 不同使用者, 以不同帳戶同時登入同一台主機, 每個使用者有自己的空間 (namespaces), 分隔獨立的程式 (PID), 並共享工作站的資源 (CPU, 記憶體, 以及硬碟等), 這樣的概念就是最基本的 container 的由來. 不過, 上述的行為只解釋了對於檔案系統與程式的隔離, 接著, 在工作站環境中, 另一個問題就是, 假如有一個使用者寫了一個無止盡的 while loop, 將拖慢所有人的速度, 為了避免此狀況發生, cgroup 在 2006 年被提出, 用以限制, 控制與分離一個行程群組的資源 (例如: CPU, 記憶體, 磁碟輸入輸出等), 可以參考:  https://access.redhat.com/documentation/zh-tw/red_hat_enterprise_linux/6/html/resource_management_guide/ch01 https://delftswa.github.io/chapters/docker/ 在上圖中, 我們介紹了 namespaces 和 cgroup 的功能, 剩下來相關的套件, SELinux, capabilities, AppArmor, 和安全性相關, Netlink 和 Netfilter 則和網路虛擬化相關, 在下一篇文章 (2) 中, 我們預計先研讀網路虛擬化的部分, 安全性則先跳過, 之後 (3) 再往上介紹 libvrit, LXC, systemd-nspawn 三個模組, 最後 (4) 則是比較 docker 和 linux container (如: LXC) 的不同. 預計先透過這一系列四篇文章介紹 docker 的基礎, 並在之後繼續介紹 kubernetes 的技術 [Update]  Docker使用的Linux核心模組功能包括下列各項： Namespace

在之前, 當我們說到雲端, 想到的是一套虛擬機管理系統 (如: OpenStack), 提供不定使用者按照需求的計算資源 (以虛擬機的數量和規格計算), 隨著雲端的發展, 網路虛擬化加入 (基於 OpenVSwitch 或是 SDN 技術), 因此, 網路資源的使用與計費也加入雲端運算的列表中, 並開始有基於流量的 scaling 技術成熟, 使得 "按需求計算 (On demand)" 變成 "動態調整計算 (Auto-scaling)." 一般而言, 雲端運算仍圍繞著虛擬化的概念打造, 尤其是虛擬機, 透過虛擬化技術, OpenStack 可以將硬體資源切割成多個獨立的單元, 保證各運算單元之間的獨立性, 以及所可以取用的計算與網路資源, 提供遠端使用者一致的介面進行操作, 然而, 虛擬機也成了雲端運算的瓶頸, 考慮到所帶來的 overhead, 當計算需並非隨時間改變時 (通常一說是工作週期 > 0.3~0.5), 自己建構伺服器就變得更為有效的選擇. 對此, 雲端運算有兩種回應方式, 例如 OpenStack 使用的 KVM 技術就走向半虛擬化 (共享 Linux kernel), 或是更極端的, MaaS (Metal as a Service) 直接租借實體機, 這些不同的變化, 一方面讓雲端有更多樣的選擇, 另一方面也反映出雲端運算所受到的限制. 來自:  https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/ 在所有的虛擬化技術中, Container 是一個有趣且有潛力的方法, 其中, 最為大家熟知的 Container 技術大概是 docker, 然而, Container 事實上並不是一個新的技術, 也不一個為了虛擬化所研發的方法, 其技術比較像是一組設定, 將一群執行續困在一個沙盒中, 藉由限制其對系統資源的存取以及網路虛擬化, 來模擬一個虛擬的計算空間, 稱為 Container. 和傳統的虛擬化技術不同, Container 並沒有虛擬完整的 IO 介面, 比較起來, 更近似於一群程式, 因此, 無法直接復用 OpenStack 等既有系統, 但是,