這是今天session的agenda：
•Why Containers?
•Relationship between Containers and Dockers?
•Why Kubernetes？
•Relationship between Kyma and Kubernetes
•A real example: Commerce cloud extension via Kyma
之是以要在Kyma真正開始前做容器，Docker，Kubernetes的鋪墊，是因為Kyma基于Kubernetes，而Kubernetes又是容器編排架構，Docker又是一種流行的容器運作時實作技術，如果不提Kubernetes，Docker和容器，沒有接觸過這些概念的同僚一定會覺得一頭霧水。
我們先來看容器。
我們說任何技術都有其使用場景和解決的痛點。那麼為什麼這些年來容器技術非常火呢？
得益于近些年微服務架構的火熱，很多企業包括SAP自己也在開發基于微服務架構的新應用，比如在坐很多同僚所在團隊正在做的事情。而基于微服務架構的SaaS軟體開發，業界有一套标準，或者說是最佳實踐，那就是著名的twelve-factor标準：
https://12factor.net/zh_cn/
而容器，就是一種有助于開發人員以更小的代價去開發一個滿足這12個準則的基于微服務架構的雲原生應用的技術。比如這個準則裡提到的，微服務應用的build，release和運作階段應該嚴格區分，應用通過一個或多個無狀态的程序進行執行，彼此隔離，通過程序模型進行水準擴充，等等，這些通過容器技術都可輕易實作，不需要開發人員付出額外代價。
是以，我們需要記住一個結論，容器的使用場景，永遠是和微服務架構，SaaS，雲原生應用這些緊密相連的。
那麼容器具體來說到底是一個什麼東西呢？字面意思，用來裝東西的集裝箱。
裝什麼東西？除了應用程式本身之外，還包括這個應用要能正常運作所需的運作環境和庫檔案等外部依賴。
我們想象一下現實世界中的集裝箱。一輛汽車從碼頭上被裝到集裝箱裡，然後被貨船載到另一個碼頭裡。
這裡的汽車就好比我們的應用，集裝箱就是容器，汽車在不同的碼頭上裝入集裝箱就好比應用的部署。
這就是slide裡第一條，Convenient package to ship things的概念。
Open specification：
要注意，容器 != Docker。Docker隻是容器技術的一種商業化實作方案。
在2015年，由Google，Docker、CoreOS、IBM、微軟、Redhat等廠商聯合起來，成立了一個OCI（Open Container Initiative）組織，并于推出了第一個開放容器标準，旨在避免容器技術的碎片化。該标準主要分為運作時标準和容器鏡像标準。
Isolated：容器隔離。這個很好了解，容器裡運作的應用彼此之間是隔離的，一個應用出故障不會影響到其他容器。可以獨立分别進行水準擴充。
Portable：既然容器封裝了所有運作應用程式所必需的相關的細節，比如應用依賴以及作業系統，這就使得鏡像從一個環境移植到另外一個環境更加靈活。比如，同一個鏡像可以在Windows或Linux，開發、測試或生産環境中運作。基于容器的應用，既能運作在開發者的筆記本電腦上，也能運作在雲服務提供商的資料中心上。真正做到一次建構，到處運作。
LightWeight：輕量級。虛拟機和容器的目的類似，都緻力于對應用程式及其關聯性進行隔離，進而建構起一套能夠不依賴于具體環境而運作的應用單元。虛拟機是在實體伺服器的上層用軟體來模拟特定的硬體系統。Hypervisor位于硬體和系統之間，是建立虛拟機必須的一個部分。虛拟機軟體必須使用Hypervisor作為一個中間層，是虛拟機技術的核心，當宿主作業系統啟動虛拟機時，會通過hypervisor給虛拟機配置設定記憶體，CPU，網絡和磁盤等資源，并加載虛拟的作業系統，因而需要消耗主控端大量的實體資源。
一台主控端上運作的多個容器化應用共享這台主控端作業系統的核心，因而不需要虛拟機技術的hypervisor中間層，因而同虛拟機技術相比，更加輕量化，啟動速度更快。
那麼容器和docker的關系又是怎樣的？
前面已經說到了，Docker隻是基于開放容器标準的一種比較受歡迎的實作。Docker之于容器，相當于React，Angular和Vue之于UI開發架構。
既然大多數時候我們在談到容器時，都會不自覺地想到Docker，那麼Docker到底是用什麼實作的呢？
著名的計算機科學家王垠，曾經在他的個人部落格上撰文，聲稱Docker和Kubernetes并不是什麼了不起的技術。從科學家的角度出發，這個論斷不能算錯誤，因為Docker底層确實就是對Linux裡很多原語做了很好的封裝，是以從商業化的角度取得了成功。
以下是一些Docker封裝的Linux系統原語的一些例子。Jerry是SAP Docker和Kubernetes教育訓練課程的講師之一，在這個課程上，我們會對Docker如何憑借這些原語實作開放容器标準做深入的讨論。
接下來，我們引入Kubernetes。為什麼有了Docker後，還需要Kubernetes？
我們知道從結果上看，Docker和虛拟機都可以做到讓應用在隔離的環境下運作，差別在于Docker運作環境仍然能夠和主控端共享作業系統核心，而虛拟機則通過付出更多主控端系統資源的代價，構造出一個完全虛拟的作業系統，讓應用在裡面運作。
然而Docker容器和虛拟機還是有一些問題沒有解決，就是容器在大型分布式叢集上的部署，微服務應用中的容器管理和協同，自動地水準擴充，自動修複和彈性伸縮等等。
這也是Kubernetes大顯身手的地方。誕生于2015年7月的Kubernetes，是Google内部多年使用的容器叢集管理系統Borg的開源版本。由于凝聚了Google在容器編排領域多年的深厚功力，釋出之後很快就一飛沖天，如今已經成為事實上的容器叢集管理領域的标準和霸主。
Kubernetes源自古希臘語，意為“舵手”。有人調侃說，Google選擇Kubernetes這個單詞，暗示了自己想在容器編排管理這個領域裡扮演舵手和上司者的角色。