系統綜合實踐——第6次實踐作業：docker容器和K8s的技術總結報告
通過前5次的實踐作業，我們已經對於容器技術有了一個直觀的理解和體會，此次報告，按老師要求把自己設想成相關領域的一個技術大牛，面對技術小白們，介紹一下docker容器和K8s的相關技術。
一、實踐記錄
課題小組-19：【源且歸於本能】
成員1：032092133-潘傑
成員2：032092135-蘭昌龍
1.實踐問答
（1）時間記錄
- 開始時間——2021/05/16 19：00
- 結束時間——2021/05/21 22：00
- 有效時長——10h
（2）難易程度
- B.比較困難
2.實驗環境
- VisualBox_6.1虛擬機
- Ubuntu 18.04.5 Desktop amd64 的虛擬機系統;
【軟件工具】
- K8s
- nano/Text Editor
- Docker Engine-Community
- docker-hub
- aliyun鏡像倉庫
- Firefox瀏覽器
- NginX
- mysql-5.7
- PHP
- apache-tomcat-8.5.65.tar.gz
- jdk-8u211-linux-x64.tar.gz
- python：3.9.4
3.實驗任務
匯報內容：
1）引言：包含相關技術的起源、背景，文章結構
2）容器：對於傳統技術的影響，應用場景等
3）K8S：主要功能，核心組件，網絡插件等
4）相關技術在使用過程中的一些重點和難點
5）總結與展望
6）參考文獻
(提示：為便於程序修改調試，在容器啟動時需將本地文件目錄掛載至容器內的工作目錄； )
（1）容器docker
（2）K8s
二、技術模塊1——容器
In a word：容器就是將軟件打包成標准化單元，以用於開發、交付和部署。
1.技術背景
（1）容器技術
基本概念
- 容器是一種沙盒技術，主要目的是為了將應用運行在其中，與外界隔離；同時，方便這個沙盒可以被轉移到其它宿主機器上。
- 有效的將單個操作系統的資源划分到孤立的組中，以便更好的在孤立的組之間平衡有沖突的資源使用需求，這種技術就是容器技術。
發展歷程
- 容器技術在約二十年前就出現了，從1979年的Chroot Jail開始，但直到2013年Docker推出之后才遍地開花，其中有偶然因素，也有大環境造就的必然因素。
組成
- 本質上，它是一個特殊的進程：
- 通過名稱空間（Namespace）、控制組（Control groups）、切根（chroot）技術把資源、文件、設備、狀態和配置划分到一個獨立的空間。
（2）容器 -vs- 虛擬機
虛擬機
- 虛擬機通常包括整個操作系統和應用程序，里面運行的是一個真實的操作系統。
比較
- 本質上虛擬機是Hypervisor虛擬化出來的硬件上安裝不同的操作系統，而容器是宿主機上運行的不同進程。
- 從用戶體驗上來看，虛擬機是重量級的，占用物理資源多，啟動時間長。容器則占用物理資源少，啟動迅速。
- 相對地，虛擬機隔離的更徹底，容器則要差一些。
（3）docker
起源
Docker 是一個開源項目，誕生於 2013 年初，最初是 dotCloud 公司內部的一個業余項目。它基於 Google 公司推出的 Go 語言實現。 項目后來加入了 Linux 基金會，遵從了 Apache 2.0 協議，項目代碼在 GitHub 上進行維護。
基本架構
- Docker 使用客戶端-服務器 (C/S) 架構模式，使用遠程API來管理和創建Docker容器。
- Docker 主要有以下幾部分組成：
- Docker Client 客戶端
- Docker daemon 守護進程
- Docker Image 鏡像
- Docker Container 容器
- Docker Registry 倉庫
2.對傳統技術的影響
作為一種新興的虛擬化方式，Docker 跟傳統的虛擬化方式相比具有眾多的優勢：
（1）更快速的交付和部署
Docker在整個開發周期都可以完美的輔助你實現快速交付。Docker允許開發者在裝有應用和服務本地容器做開發。可以直接集成到可持續開發流程中。
例如：開發者可以使用一個標准的鏡像來構建一套開發容器，開發完成之后，運維人員可以直接使用這個容器來部署代碼。 Docker 可以快速創建容器，快速迭代應用程序，並讓整個過程全程可見，使團隊中的其他成員更容易理解應用程序是如何創建和工作的。 Docker 容器很輕很快！容器的啟動時間是秒級的，大量地節約開發、測試、部署的時間。
（2）高效的部署和擴容
Docker 容器幾乎可以在任意的平台上運行，包括物理機、虛擬機、公有雲、私有雲、個人電腦、服務器等。 這種兼容性可以讓用戶把一個應用程序從一個平台直接遷移到另外一個。
Docker的兼容性和輕量特性可以很輕松的實現負載的動態管理。你可以快速擴容或方便的下線的你的應用和服務，這種速度趨近實時。
（3）更高的資源利用率
Docker 對系統資源的利用率很高，一台主機上可以同時運行數千個 Docker 容器。容器除了運行其中應用外，基本不消耗額外的系統資源，使得應用的性能很高，同時系統的開銷盡量小。傳統虛擬機方式運行 10 個不同的應用就要起 10 個虛擬機，而Docker 只需要啟動 10 個隔離的應用即可。
（4）更簡單的管理
使用 Docker，只需要小小的修改，就可以替代以往大量的更新工作。所有的修改都以增量的方式被分發和更新，從而實現自動化並且高效的管理。而且，隨着容器技術的不斷普及和發展，隨之而來的容器管理、編排技術也會同樣得到發展。
3.應用場景
(1）作為雲主機使用
相比虛擬機來說，容器使用的是一系列非常輕量級的虛擬化技術，使得其啟動、部署、升級跟管理進程一樣迅速，用起來靈活又感覺跟虛擬機一樣沒什么區別，所以有些人直接使用Docker的Ubuntu等鏡像創建容器，當作輕量的虛擬機來使用。
(2）作為服務使用
如果你僅僅把Docker容器當作一個輕量的固定虛擬機用，那其實只能算是另類用法，Docker容器最重要價值在於提供一整套平台無關的標准化技術，簡化服務的部署、升級、維護，只要把需要運維的各種服務打包成標准的集裝箱，就可以在任何能運行Docker的環境下跑起來，達到開箱即用的效果，這個特點才是Docker容器風靡全球的根本原因。
Web應用服務
持續集成和持續部署
(3） 微服務架構使用
如果說上面兩種應用場景還不足以體現出與傳統的PaaS平台相比的巨大優勢的話，那么對微服務的架構這種復雜又靈活的使用場景的無縫支持絕對具有革命意義。
微服務架構將傳統分布式服務繼續拆分解耦，形成一些更小服務模塊，服務模塊之間獨立部署升級，這些特性與容器的輕量、高效部署不謀而合。
4.實現的重、難點
（1）網絡配置
Docker作為目前最火的輕量級容器技術，有很多令人稱道的功能，如Docker的鏡像管理。然而，Docker同樣有着很多不完善的地方，網絡方面就是Docker比較薄弱的部分。
Docker的4種網絡模式
我們在使用docker run創建Docker容器時，可以用--net選項指定容器的網絡模式，Docker有以下4種網絡模式：
- host模式，使用--net=host指定。
- container模式，使用--net=container:NAME_or_ID指定。
- none模式，使用--net=none指定。
- bridge模式，使用--net=bridge指定，默認設置。
解決方案
- Docker自身的網絡功能比較簡單，不能滿足很多復雜的應用場景。因此，有很多開源項目用來改善Docker的網絡功能，如pipework、weave、flannel等。
- 我們應該注意到，諸如pipework並不是一套解決方案，它只是一個網絡配置工具，我們可以利用它提供的強大功能，幫助我們構建自己的解決方案。
- pipework不僅可以使用Linux bridge連接Docker容器，還可以與OpenVswitch結合，實現Docker容器的VLAN划分。
（2）數據庫的容器化部署
近2年Docker的火熱，使得開發者恨不得把所有的應用、軟件都部署在Docker容器中，但是，Docker並不適合部署數據庫，有如下7大原因：
①數據安全問題
使用當前的存儲驅動程序，Docker 仍然存在不可靠的風險。如果容器崩潰並數據庫未正確關閉，則可能會損壞數據。
②性能問題
MySQL 屬於關系型數據庫，對IO要求較高。當一台物理機跑多個時，IO就會累加，導致IO瓶頸，大大降低 MySQL 的讀寫性能。
針對性解決方案：
(1)數據庫程序與數據分離
(2)跑輕量級或分布式數據庫
(3)合理布局應用
③網絡問題
要理解 Docker 網絡，您必須對網絡虛擬化有深入的了解。
④狀態
在 Docker 中打包無狀態服務是很酷的，可以實現編排容器並解決單點故障問題。但是，將數據庫放在同一個環境中，它將會是有狀態的，並使系統故障的范圍更大。下次您的應用程序實例或應用程序崩潰，可能會影響數據庫。
⑤資源隔離
資源隔離方面，Docker 確實不如虛擬機KVM，Docker是利用Cgroup實現資源限制的，只能限制資源消耗的最大值，而不能隔絕其他程序占用自己的資源。如果其他應用過渡占用物理機資源，將會影響容器里 MySQL 的讀寫效率。需要的隔離級別越多，獲得的資源開銷就越多。
⑥雲平台的不適用性
大部分人通過共有雲開始項目。雲簡化了虛擬機操作和替換的復雜性，因此不需要在夜間或周末沒有人工作時間來測試新的硬件環境。當我們可以迅速啟動一個實例的時候，為什么我們不需要擔心這個實例運行的環境？這就是為什么我們向雲提供商支付很多費用的原因。當我們為實例放置數據庫容器時，上面說的這些便利性就不存在了。
⑦運行數據庫的環境需求
常看到 DBMS 容器和其他服務運行在同一主機上。然而這些服務對硬件要求是非常不同的。數據庫（特別是關系型數據庫）對 IO 的要求較高。一般數據庫引擎為了避免並發資源競爭而使用專用環境。如果將你的數據庫放在容器中，那么將浪費你的項目的資源。因為你需要為該實例配置大量額外的資源。
docker適合跑輕量級或分布式數據庫，當docker服務掛掉，會自動啟動新容器，而不是繼續重啟容器服務。
解決方案
容器化的優點使得開發者嘗到了甜頭，希望隨着技術的發展能夠更加完美的解決方案出現。
三、技術模塊2——K8s
1.技術背景
- Kubernetes（k8s）是跨主機集群的自動部署、擴展以及運行應用程序容器的開源平台，這些操作包括部署，調度和節點集群間擴展。
- wikipedia給出的定義：K8s是用於自動部署、擴展和管理容器化（containerized）應用程序的開源系統。Google設計並捐贈給Cloud Native Computing Foundation（今屬Linux基金會）來使用的。它支持一系列容器工具, 包括Docker等。CNCF於2017年宣布首批Kubernetes認證服務提供商（KCSPs），包含IBM、華為、MIRANTIS、inwinSTACK迎棧科技等服務商。
- 在《Kubernetes權威指南（第二版）》中給出的定義：她是一個全新的基於容器技術的分布式架構領先方案，她提供了強大的自動化機制，系統后期的運維難度和運維成本大幅度降低。她是Google的大閨女Borg的開源版本。使用K8s提供的解決方案，可以節省大概30%的開發成本，可以將精力更加集中於業務本身。
2.應用場景
雲 和 k8s 的關系
雲：使用容器構建的一套服務集群網絡，雲是由很多的容器構成。
k8s：用來管理雲中的容器
k8s 在企業中的應用場景
首先我們了解一下 k8s 的三個基本特點：
可移植: 支持公有雲，私有雲，混合雲，多重雲（multi-cloud）
可擴展: 模塊化，插件化，可掛載，可組合
自動化: 自動部署，自動重啟，自動復制，自動伸縮/擴展
1.1 自動化運維平台
對於中小型企業，為了降本增效，使用 k8s 來構建一套自動化運維平台，提供了應用部署，規划，更新，維護的一種機制。
對於大型互聯網公司更要使用容器化部署。現在服務器越來越多，不可能都人工部署，需要使用自動化的運維平台來監控服務，來實現自動服務化的部署、運維。
1.2 充分利用服務器資源
1.3 服務無縫遷移
在開發環境開發，然后拿到測試環境去測試，但往往一上線就會有 bug，因為應用的運行、配置、管理、所有生存周期將與當前操作系統綁定，所以生產環境的不一致就可能導致錯誤。
使用容器化解決方案，每個應用可以被打包成一個容器鏡像（紅色圈起來表示把服務部署在容器中），使用容器可以在 開發 或 測試 的階段，為應用創建容器鏡像，這些鏡像能夠完全脫離環境，每個應用不需要與其余的應用堆棧組合，也不依賴於生產環境基礎結構，這使得從研發到測試、生產能提供一致環境。使用 kubernetes 來管理這些容器，便能夠實現服務的無縫遷移。
3.實現的重、難點
核心概念
-
集群
在集群管理方面，K8s將集群中的機器划分為一個Master節點和一群工作節點Node。Master節點上運行着集群管理相關的一組進程kube-apiserver、kube-controller-manager和kube-scheduler。這些進程自動化實現了整個集群的資源管理、Pod調度、彈性伸縮、安全控制、系統監控和糾錯等管理功能。 -
Kubernetes Master
Master指的是集群控制節點。每個K8s集群里需要有一個Ms節點負責整個集群的管理和控制。Kubernetes Master提供集群的獨特視角，並且擁有一系列組件。 -
Node
節點是物理或者虛擬機器，作為Kubernetes worker，通常稱為Minion。每個節點都運行如下Kubernetes關鍵組件：
(1) Kubelet：與Master節點協作，是主節點的代理，負責Pod對應容器的創建，啟動，停止等任務。默認情況下Kubelet會向Master注冊自己。Kubelet定期向主機點匯報加入集群的Node的各類信息。
(2) Kube-proxy：Kubernetes Service使用其將鏈接路由到Pod，作為外部負載均衡器使用，在一定數量的Pod之間均衡流量。比如，對於負載均衡Web流量很有用。
(3) Docker或Rocket：Kubernetes使用的容器技術來創建容器 -
Pod
Pod是K8s最重要也是最基礎的概念！每個Pod都有一個特殊的被稱為“根容器”的Pause容器，此容器與引入業務無關並且不易死亡。且以它的狀態代表整個容器組的狀態！Pause容器對應的鏡像屬於K8s平台的一部分，除了Pause容器，每個Pod還包含一個或多個用戶業務容器 -
Lable
Lable類似Docker中的tag，一個是對“特殊”鏡像、容器、卷組等各種資源做標記，一個是attach到各種諸如Node、Pod、Server、RC資源對象上。不同的是Lable是一對鍵值對！Lable類似Tag，可使用K8s專有的標簽選擇器（Label Selector）進行組合查詢。 -
Replication Controller
Replication Controller，簡稱RC，她用來干啥呢？就是通過她來實現Pod副本數量的自動控制！RC確保任意時間都有指定數量的Pod“副本”在運行。 -
Service
微服務架構中的一個“微服務”，她是正真的新娘，而之前的Pod，RC等資源對象其實都是嫁衣。
每個Pod都會被分配一個單獨的IP地址，而且每個Pod都提供了一個獨立的Endpoint（Pod lP + ContainerPort）以被客戶端訪問，現在多個Pod副本組成了一個集群來提供服務，客戶端要想訪問集群，一般的做法是部署一個負載均衡器（軟件或硬件），為這組Pod開啟一個對外的服務端口如8000端口，並且將這些Pod的Endpoint列表加入8000端口的轉發列表中，客戶端就可以通過負載均衡器的對外IP地址 + 服務端口來訪問此服務，而客戶端的請求最后會被轉發到哪個Pod，則由負載均衡器的算法所決定。
K8s的server定義了一個服務的訪問入口地址，前端（Pod）通過入口地址訪問其背后的一組由Pod副本組成的集群實例，service與其后端Pod副本集群之間通過Label Selector 實現“無縫對接”。