Docker和 K8s 到底啥關系？想學K8s，必須得先學 Docker 嗎？
常見的應急響應對象有哪些想學K8s，必須得先學會 Docker 嗎？這是很多網友在開始琢磨著想要學 K8s 的時候都會冒出來的想法。那么今天我們就跟大家說說這個話題，要回答這個問題，我們需要先搞清楚 Docker 和 K8s 他們的角色是什么，相互之間是什么關系。
K8s 和 Docker 的關系
Docker 和 K8s 這兩個經常一起出現，兩者的Logo 看著也有一定聯系一個是背上馱著集裝箱的鯨魚一個是船的舵輪。
不過兩者不能放在一個維度上討論，Docker 是當前流行的 Linux 容器解決方案，利用 Namespaces 、Cgroups 以及聯合文件系統UnionFS 實現了同一主機上容器進程間的相互隔離。
NameSpaces：隔離進程，讓進程只能訪問到本命名空間里的掛載目錄、PID、NetWork 等資源
Cgroups: 限制進程能使用的計算機系統各項資源的上限，包括 CPU、內存、磁盤、網絡帶寬等等
聯合文件系統UnionFS : 保存一個操作系統的所有文件和目錄，在它基礎之上添加應用運行依賴的文件。創建容器進程的時候給進程指定Mount Namespace 把鏡像文件掛載到容器里，用 chroot 把進程的 Root目錄切換到掛載的目錄里，從而讓容器進程各自擁有獨立的操作系統目錄。
而 K8s 是擁有容器編排能力的集群管理解決方案，可以按照應用的定義調度各個運行著應用組件 Docker 容器，但是 Docker 并不是 K8s 對容器的唯一選擇，K8s 的 容器運行時支持對接多種容器 ，比如CoreOS公司的Rkt容器（之前稱為Rocket，現更名為Rkt），Apache 開源的 Mesos 容器等。只要容器實現了 K8s 容器運行時的接口約定，都能讓 K8s 進行調度。
圖片紅框里的容器運行時負責對接具體的容器實現
Docker 公司也推出過自己的容器集群管理方案 Docker Swarm ，跟 K8s 算是競品，但是在生產上幾乎沒人使用。
Docker Swarm 沒有流行起來的深層次的原因就不深究了，從一些IT媒體的報道看，可能的原因是
跟 Docker 深度綁定，人天生對集權主義非常反感。
Docker 公司在大規模集群管理上的經驗不足，不像谷歌那樣能高屋建瓴地給出好的解決方法。
容器用 Docker，需要學到什么程度
看完 K8s 和 Docker 的關系后，我們已經有答案了，想學 K8s 不一定非得會 Docker。但是畢竟 Docker 還是目前最流行的 Linux 容器方案，絕大部分情況下我們還是會選擇使用 Docker，那么我們 Docker 掌握到什么程度更易于我們學習 K8s 呢？
這個主要看我們想學會 K8s 干什么，即使運行在 K8s 之上的容器選擇 Docker，如果我們是搭建一些基建類的軟件，比如 MySQL、Redis之類的，因為這些組織已經提供了軟件容器的鏡像，我的使用體驗是，完全用不到那些 Docker 的各種命令。
比如要在 K8s 集群上運行一個 MySQL 應用，寫好應用的清單文件（就是各種配置和期望的狀態），然后直接運行
kubectl apply -f mysql.yaml 就好，K8s 的容器運行時會根據清單文件里的鏡像名，幫我們調 Docker 的接口去下載鏡像、運行容器。
apiVersion: apps/v1 kind: Deployment metadata: name: mysql spec: selector: matchLabels: app: mysql strategy: type: Recreate template: metadata: labels: app: mysql spec: containers: - image: mysql:5.7 name: mysql env: - name: MYSQL_ROOT_PASSWORD value: superpass ports: - containerPort: 3306 name: mysql volumeMounts: - name: mysql-persistent-storage mountPath: /var/lib/mysql - name: mysql-config mountPath: /etc/mysql/conf.d/my.cnf subPath: my.cnf
學會這幾個簡單的 Docker 知識就能支撐我們開始 K8s 的學習和練習啦，其他 Docker 相關的知識完全可以在做 K8s 練習時遇到問題、解決問題的過程中再學
