Docker

Docker 對進(jìn)程進(jìn)行封裝隔離酪穿，屬于操作系統(tǒng)層面的虛擬化技術(shù)。
Docker 在容器的基礎(chǔ)上晴裹，進(jìn)行了進(jìn)一步的封裝被济，從文件系統(tǒng)、網(wǎng)絡(luò)互聯(lián)到進(jìn)程隔離等等涧团，極大的簡化了容器的創(chuàng)建和維護(hù)只磷。使得 Docker 技術(shù)比虛擬機(jī)技術(shù)更為輕便经磅、快捷。

Docker 和傳統(tǒng)虛擬化方式的不同之處：
傳統(tǒng)虛擬機(jī)技術(shù)是虛擬出一套硬件后钮追，在其上運(yùn)行一個完整操作系統(tǒng)预厌，在該系統(tǒng)上再運(yùn)行所需應(yīng)用進(jìn)程；而容器內(nèi)的應(yīng)用進(jìn)程直接運(yùn)行于宿主的內(nèi)核畏陕，容器內(nèi)沒有自己的內(nèi)核配乓，而且也沒有進(jìn)行硬件虛擬。因此容器要比傳統(tǒng)虛擬機(jī)更為輕便惠毁。

K8S

K8S犹芹，就是基于容器的集群管理平臺，它的全稱鞠绰，是kubernetes腰埂。
在現(xiàn)實(shí)的生產(chǎn)環(huán)境中 Docker 本身是一個相對底層的容器引擎，在有很多服務(wù)器的集群中蜈膨，不太可能單獨(dú)去管理任務(wù)和資源屿笼。所以我們需要 Kubernetes 這樣的系統(tǒng)來進(jìn)行任務(wù)的編排和調(diào)度。

關(guān)于pod

Kubernetes 中部署的最小單位是 pod翁巍，而不是 Docker 容器驴一。實(shí)時上 Kubernetes 是不依賴于 Docker 的，完全可以使用其他的容器引擎在 Kubernetes 管理的集群中替代 Docker灶壶。

Kubernetes 引入 Pod 主要基于下面兩個目的：

• 可管理性肝断。
  有些容器天生就是需要緊密聯(lián)系，一起工作驰凛。Pod 提供了比容器更高層次的抽象胸懈，將它們封裝到一個部署單元中。Kubernetes 以 Pod 為最小單位進(jìn)行調(diào)度恰响、擴(kuò)展趣钱、共享資源、管理生命周期胚宦。
• 通信和資源共享首有。
  Pod 中的所有容器使用同一個網(wǎng)絡(luò) namespace，即相同的 IP 地址和 Port 空間间唉。它們可以直接用 localhost 通信绞灼。同樣的，這些容器可以共享存儲呈野，當(dāng) Kubernetes 掛載 volume 到 Pod低矮，本質(zhì)上是將 volume 掛載到 Pod 中的每一個容器。

在與 Docker 結(jié)合使用時被冒，一個 pod 中可以包含一個或多個 Docker 容器军掂。但除了有緊密耦合的情況下轮蜕，通常一個 pod 中只有一個容器，這樣方便不同的服務(wù)各自獨(dú)立地擴(kuò)展蝗锥。Pod 中的容器會作為一個整體被 Master 調(diào)度到一個 Node 上運(yùn)行跃洛。Pods 有兩種使用方式：

• 運(yùn)行單一容器。
  one-container-per-Pod 是 K8s 最常見的模型终议，這種情況下汇竭，只是將單個容器簡單封裝成 Pod。即便是只有一個容器穴张，K8s 管理的也是 Pod 而不是直接管理容器细燎。
• 運(yùn)行多個容器。
  但問題在于：哪些容器應(yīng)該放到一個 Pod 中皂甘？
  答案是：這些容器聯(lián)系必須非常緊密嗡官，而且需要直接共享資源蚕钦。

關(guān)于Controller

Kubernetes 通常不會直接創(chuàng)建 Pod，而是通過 Controller 來管理 Pod 的贝或。Controller 中定義了 Pod 的部署特性块差，比如有幾個副本闹司，在什么樣的 Node 上運(yùn)行等撕彤。為了滿足不同的業(yè)務(wù)場景源祈，Kubernetes 提供了多種 Controller，包括 Deployment墓塌、ReplicaSet档冬、DaemonSet、StatefuleSet桃纯、Job 等。

實(shí)戰(zhàn)

參考官網(wǎng)提供的一個實(shí)踐方案披坏。結(jié)果是把一個 node.js 的簡單的 Hello World 應(yīng)用态坦，在 Kubernetes 上部署成為一個復(fù)制應(yīng)用，將代碼變成一個 Docker 鏡像棒拂，并且在Google Container Engine上運(yùn)行它伞梯。（Kubernetes 是可以運(yùn)行在許多不同環(huán)境的開源項目，無論是筆記本還是高可用多點(diǎn)集群帚屉，公有云還是本地環(huán)境谜诫，無論是虛擬機(jī)還是物理機(jī)。范例提到的是google的k8s托管環(huán)境攻旦。）

步驟：

1. 登陸google云平臺喻旷，創(chuàng)建并配置項目，記下配置的PROJECT_ID

2. 創(chuàng)建nodejs項目并起服務(wù)

3. 創(chuàng)建一個docker容器鏡像
   先創(chuàng)建dockerfile

// 讓搭建的 Docker 鏡像基于 Docker 鏡像倉庫的 Node.js LTS鏡像
// 開放 8080 端口牢屋，復(fù)制我們的 server.js 文件到鏡像并啟動 Node 服務(wù)
FROM node:4.4
EXPOSE 8080
COPY server.js .
CMD node server.js

然后使用docker構(gòu)建容器并用project_id標(biāo)記
docker build -t gcr.io/$PROJECT_ID/hello-node:v1 .（范例文件夾命名為hello-node）
docker run -d -p 8080:8080 --name hello_tutorial gcr.io/$PROJECT_ID/hello-node:v1通過docker run本地運(yùn)行鏡像試試可否正常訪問且预。
最后推送鏡像到google容器倉庫（命令行需要先安裝Google Cloud SDK）
gcloud docker push gcr.io/$PROJECT_ID/hello-node:v1
如果一切順利槽袄，應(yīng)該會在控制臺中看到容器鏡像

4. 創(chuàng)建一個集群
   集群由一個 master API server 和一組叫做 node 的虛擬機(jī)構(gòu)成。
   先選擇地區(qū)锋谐，再通過gcloud container clusters create hello-world創(chuàng)建一個集群遍尺。另外可以通過Google Cloud Console的New container cluster可視化創(chuàng)建一個集群。
   最后通過gcloud container clusters get-credentials hello-world部署容器式應(yīng)用到 Kubernetes 集群涮拗。

5. 創(chuàng)建pod
   借助kubectl run命令來創(chuàng)建一個pod
   kubectl run hello-node --image=gcr.io/$PROJECT_ID/hello-node:v1 --port=8080

6. 允許外部訪問
   在我們的開發(fā)機(jī)上乾戏，我們可以使用kubectl expose以及--type="LoadBalancer"標(biāo)識需要從外部 IP 訪問來公開 pod。
   kubectl expose deployment hello-node --type="LoadBalancer"
   此命令中使用deployment這個標(biāo)識指定了我們將使用底層架構(gòu)來提供負(fù)載均衡三热。*我們開放的是 deployment鼓择，而不是直接公開 pod，這將會讓所有由 deployment 管理的 pod 負(fù)載均衡（這只有一個 pod康铭，我們一會會復(fù)制多個）

Kubernetes 的狀態(tài)

7. 滾動升級你的網(wǎng)站
   與往常一樣惯退，修復(fù) bug 或者添加功能的應(yīng)用，部署到生產(chǎn)環(huán)境从藤。
   首先編輯修改代碼催跪。
   再構(gòu)建鏡像docker build -t gcr.io/$PROJECT_ID/hello-node:v2 .
   上傳gcloud docker push gcr.io/$PROJECT_ID/hello-node:v2
   借助kubectl set image命令用新的鏡像更新deployment，它會創(chuàng)建新的pod并刪除舊的pod
   kubectl set image deployment/hello-node hello-node=gcr.io/$PROJECT_ID/hello-node:v2

當(dāng)然夷野，我們也可以借助 Kubernetes Web UI 圖形化管理懊蒸，用它來部署容器化應(yīng)用，以及監(jiān)視和管理你的群集悯搔。

12要素

12-Factor 為構(gòu)建如下的 SaaS(software as a service 軟件即服務(wù)) 應(yīng)用提供了方法論：

• 使用標(biāo)準(zhǔn)化流程自動配置骑丸，從而使新的開發(fā)者花費(fèi)最少的學(xué)習(xí)成本加入這個項目。
• 和操作系統(tǒng)之間盡可能的劃清界限妒貌，在各個系統(tǒng)中提供最大的可移植性通危。
• 適合部署在現(xiàn)代的云計算平臺，從而在服務(wù)器和系統(tǒng)管理方面節(jié)省資源灌曙。
• 將開發(fā)環(huán)境和生產(chǎn)環(huán)境的差異降至最低菊碟，并使用持續(xù)交付實(shí)施敏捷開發(fā)。
• 可以在工具在刺、架構(gòu)和開發(fā)流程不發(fā)生明顯變化的前提下實(shí)現(xiàn)擴(kuò)展逆害。

這套理論適用于任意語言和后端服務(wù)（數(shù)據(jù)庫、消息隊列蚣驼、緩存等）開發(fā)的應(yīng)用程序魄幕。

1. 基準(zhǔn)代碼（一份基準(zhǔn)代碼，多份部署）
   每個應(yīng)用只對應(yīng)一份基準(zhǔn)代碼颖杏，但可以同時存在多份部署纯陨。每份部署相當(dāng)于運(yùn)行了一個應(yīng)用的實(shí)例。通常會有一個生產(chǎn)環(huán)境，一個或多個預(yù)發(fā)布環(huán)境队丝。此外靡馁，每個開發(fā)人員都會在自己本地環(huán)境運(yùn)行一個應(yīng)用實(shí)例，這些都相當(dāng)于一份部署机久。

2. 依賴（顯式聲明依賴關(guān)系）
   12-Factor規(guī)則下的應(yīng)用程序不會隱式依賴系統(tǒng)級的類庫臭墨。 它一定通過依賴清單，確切地聲明所有依賴項膘盖。此外胧弛，在運(yùn)行過程中通過依賴隔離工具來確保程序不會調(diào)用系統(tǒng)中存在但清單中未聲明的依賴項。這一做法會統(tǒng)一應(yīng)用到生產(chǎn)和開發(fā)環(huán)境侠畔。

3. 配置（在環(huán)境中存儲配置）
   12-Factor推薦將應(yīng)用的配置存儲于環(huán)境變量中（ env vars, env ）结缚。環(huán)境變量可以非常方便地在不同的部署間做修改，卻不動一行代碼软棺；與配置文件不同红竭，不小心把它們簽入代碼庫的概率微乎其微；與一些傳統(tǒng)的解決配置問題的機(jī)制（比如 Java 的屬性配置文件）相比喘落，環(huán)境變量與語言和系統(tǒng)無關(guān)茵宪。

4. 后端服務(wù)（把后端服務(wù)當(dāng)作附加資源）
   12-Factor 應(yīng)用不會區(qū)別對待本地或第三方服務(wù)。 對應(yīng)用程序而言瘦棋，兩種都是附加資源稀火，通過一個 url 或是其他存儲在配置中的服務(wù)定位/服務(wù)證書來獲取數(shù)據(jù)。12-Factor 應(yīng)用的任意部署赌朋，都應(yīng)該可以在不進(jìn)行任何代碼改動的情況下凰狞，將本地 MySQL 數(shù)據(jù)庫換成第三方服務(wù)（例如 Amazon RDS）。類似的沛慢，本地 SMTP 服務(wù)應(yīng)該也可以和第三方 SMTP 服務(wù)（例如 Postmark ）互換赡若。上述 2 個例子中，僅需修改配置中的資源地址团甲。
   每個不同的后端服務(wù)是一份資源斩熊，這些資源和它們附屬的部署保持松耦合。
   部署可以按需加載或卸載資源伐庭。例如，如果應(yīng)用的數(shù)據(jù)庫服務(wù)由于硬件問題出現(xiàn)異常分冈，管理員可以從最近的備份中恢復(fù)一個數(shù)據(jù)庫圾另，卸載當(dāng)前的數(shù)據(jù)庫，然后加載新的數(shù)據(jù)庫 – 整個過程都不需要修改代碼雕沉。

5. 構(gòu)建集乔，發(fā)布，運(yùn)行（嚴(yán)格分離構(gòu)建和運(yùn)行）
   12-factor 應(yīng)用嚴(yán)格區(qū)分構(gòu)建，發(fā)布扰路，運(yùn)行這三個步驟尤溜。

• 構(gòu)建階段 是指將代碼倉庫轉(zhuǎn)化為可執(zhí)行包的過程。構(gòu)建時會使用指定版本的代碼汗唱，獲取和打包依賴項宫莱，編譯成二進(jìn)制文件和資源文件。
• 發(fā)布階段 會將構(gòu)建的結(jié)果和當(dāng)前部署所需配置相結(jié)合哩罪，并能夠立刻在運(yùn)行環(huán)境中投入使用授霸。
• 運(yùn)行階段 （或者說“運(yùn)行時”）是指針對選定的發(fā)布版本，在執(zhí)行環(huán)境中啟動一系列應(yīng)用程序進(jìn)程际插。

6. 進(jìn)程（以一個或多個無狀態(tài)進(jìn)程運(yùn)行應(yīng)用）
   12-Factor 應(yīng)用的進(jìn)程必須無狀態(tài)且無共享碘耳。 任何需要持久化的數(shù)據(jù)都要存儲在后端服務(wù)內(nèi)，比如數(shù)據(jù)庫框弛。

7. 端口綁定（通過端口綁定提供服務(wù)）
   12-Factor 應(yīng)用完全自我加載而不依賴于任何網(wǎng)絡(luò)服務(wù)器就可以創(chuàng)建一個面向網(wǎng)絡(luò)的服務(wù)辛辨。互聯(lián)網(wǎng)應(yīng)用通過端口綁定來提供服務(wù) 瑟枫，并監(jiān)聽發(fā)送至該端口的請求斗搞。
   端口綁定這種方式也意味著一個應(yīng)用可以成為另外一個應(yīng)用的后端服務(wù) ，調(diào)用方將服務(wù)方提供的相應(yīng) URL 當(dāng)作資源存入配置以備將來調(diào)用力奋。

8. 并發(fā)（通過進(jìn)程模型進(jìn)行擴(kuò)展）
   在 12-factor 應(yīng)用中榜旦，進(jìn)程是一等公民。12-Factor 應(yīng)用的進(jìn)程主要借鑒于unix 守護(hù)進(jìn)程模型景殷。
   

   進(jìn)程和進(jìn)程類型關(guān)系

9. 易處理（快速啟動和優(yōu)雅終止可最大化健壯性）
   12-Factor 應(yīng)用的進(jìn)程易處理（disposable）的溅呢，意思是說它們可以瞬間開啟或停止。 這有利于快速猿挚、彈性的伸縮應(yīng)用咐旧，迅速部署變化的代碼或配置，穩(wěn)健的部署應(yīng)用绩蜻。
   進(jìn)程應(yīng)當(dāng)追求最小啟動時間铣墨，一旦接收終止信號就會優(yōu)雅的終止。進(jìn)程還應(yīng)當(dāng)在面對突然死亡時保持健壯办绝，例如底層硬件故障伊约。

10. 開發(fā)環(huán)境與線上環(huán)境等價（盡可能的保持開發(fā)，預(yù)發(fā)布孕蝉，線上環(huán)境相同）
    12-Factor 應(yīng)用的開發(fā)人員應(yīng)該反對在不同環(huán)境間使用不同的后端服務(wù)屡律，即使適配器已經(jīng)可以幾乎消除使用上的差異。這是因?yàn)榻祷矗煌暮蠖朔?wù)意味著會突然出現(xiàn)的不兼容超埋，從而導(dǎo)致測試、預(yù)發(fā)布都正常的代碼在線上出現(xiàn)問題。這些錯誤會給持續(xù)部署帶來阻力霍殴。從應(yīng)用程序的生命周期來看媒惕，消除這種阻力需要花費(fèi)很大的代價。

• 縮小時間差異：開發(fā)人員可以幾小時来庭，甚至幾分鐘就部署代碼妒蔚。
• 縮小人員差異：開發(fā)人員不只要編寫代碼，更應(yīng)該密切參與部署過程以及代碼在線上的表現(xiàn)巾腕。
• 縮小工具差異：盡量保證開發(fā)環(huán)境以及線上環(huán)境的一致性面睛。

11. 日志（把日志當(dāng)作事件流）
    12-factor應(yīng)用本身從不考慮存儲自己的輸出流。不應(yīng)該試圖去寫或者管理日志文件尊搬。相反叁鉴，每一個運(yùn)行的進(jìn)程都會直接的標(biāo)準(zhǔn)輸出（stdout）事件流。開發(fā)環(huán)境中佛寿，開發(fā)人員可以通過這些數(shù)據(jù)流幌墓，實(shí)時在終端看到應(yīng)用的活動。

12. 管理進(jìn)程（后臺管理任務(wù)當(dāng)作一次性進(jìn)程運(yùn)行）
    進(jìn)程構(gòu)成是指用來處理應(yīng)用的常規(guī)業(yè)務(wù)（比如處理 web 請求）的一組進(jìn)程冀泻。

參考

干貨滿滿常侣！10分鐘看懂Docker和K8S
12要素
k8s中文社區(qū)pod名詞解釋
k8s基本概念
借助k8s Web UI進(jìn)行圖形化管理