本文轉載自微信公眾號「 Java藝術」，轉載本文請聯系 Java藝術公眾號。

Docker與Kubernetes是什么關系?這可能是我們剛接觸Kubernetes時都有的一個疑問。那么Kubernetes是什么?

Kubernetes是一個容器集群編排管理系統，用于實現容器集群的自動化部署、自動擴縮容等功能。Docker提供用于運行應用程序的容器技術，而Kubernetes本身并不提供用于運行應用程序的容器，而是負責管理容器。

了解Docker與Kubernetes的關系之后，就能理解為什么我們要先學習Docker再學習Kubernetes，這與先學習Spring框架才能更好地學習Spring Boot、Spring Cloud是一樣的。如果還不了解Docker可以先看下上一篇《開發也需了解的運維知識之Docker》。

作為開發，我們為什么要了解容器技術，這不是運維該學習的嗎?作為開發者，只有足夠了解容器技術，才能做好技術選型，以及開發部署在Kubernetes容器服務之上的應用應該要注意哪些問題。如果運維不了解代碼，開發也不了解Kubernetes，誰能解決將服務遷移到Kubernetes上遇到的各種問題呢?

關于Kubernetes

學習Kubernetes首先要了解Kubernetes的架構，了解一些“概念”，再了解配置文件。配置文件這塊對初學者來說是最難理解的，因此推薦大家閱讀《Kubernetes in Action中文版》這本書，跟著例子一步步掌握一些配置文件中每種kind的作用，每個配置項的作用是什么。

Kubernetes管理所有可用的物理機，以阿里云容器服務Kubernetes為例，Kubernetes負責管理一堆ECS實例，這需要我們在創建Kubernetes集群時，購買足夠的ECS實例，至少兩臺。后續也可將新購買的ECS實例加到Kubernetes集群，由Kubernetes管理。

開發者和運維都不需要知道一個應用程序部署在哪個ECS實例上，只需要指定運行應用程序所需要的cpu、內存等資源，Kubernetes會根據要求計算出滿足條件的節點(ECS)，并在節點(ECS)上從鏡像倉庫拉取應用程序的鏡像創建容器并運行容器，并且監控容器的整個生命周期。我們可以把Kubernetes管理的所有節點(ECS)看成一個大的物理機，這臺大的物理機的cpu、內存是所有節點(ECS)的總和。

(圖片來之《Kubernetes in Action》)

如上圖所示，開發者只需要將應用構造成鏡像，并將鏡像push到遠程鏡像倉庫，然后編寫一個配置文件，在配置文件中描述應用程序鏡像運行所需要的資源、鏡像從哪拉取等，使用kubectl調用Kubernetes提供的API就能將應用程序部署到Kubernetes。

Kubernetes由兩種類型的節點組成。

(圖片來自《Kubernetes in Action》)

一種是主節點Master，負責控制和管理整個集群，為實現高可用，主節點也要求部署集群。主節點上會部署一些組件，這些組件可以運行在單個主節點上，或者通過副本分別部署在多個主節點上，實現高可用。如基于Reft協議實現的數據強一致性存儲服務etcd、提供給我們使用的Kubernetes API服務、調度應用部署的Scheculer組件、執行集群功能的Controller Manager組件。這些組件我們可以先這么簡單了解，暫時不用過于深究。

另一種是工作節點，運行用戶實際部署的應用。

假設我們在阿里云購買了托管的Kubernetes服務，那么主節點就由阿里云托管，而工作節點就是我們購買的ECS實例，一個集群中有多少個ECS實例就是有多少個工作節點。

工作節點就是運行容器的機器，除了運行用于運行我們部署的應用程序的容器外，每個工作節點上還會運行一些組件，這些組件負責運行、監控和管理應用服務。如Docker、Kubelet、Kube-proxy。Docker我們已經很熟悉了;Kubelet負責與主節點的Kubernetes API服務通信，并管理它所在的工作節點的容器;Kube-proxy負責組件之間的負載均衡網絡流量。

上圖是根據到目前為止我們對Kubernetes的了解所畫出的一個應用部署流程圖。

• 1、開發者在本地機器構建應用程序鏡像;
• 2、開發者將本地應用程序鏡像psuh到鏡像倉庫;
• 3、開發者為運行應用程序編寫描述文件(yaml配置文件);
• 4、開發者使用kubectl調用Kubernetes API將應用程序描述文件提交給Kubernetes;
• 5、Scheduler組件根據描述文件調度工作節點部署應用程序;
• 6、在工作節點上由Container runtime負責從鏡像倉庫拉取鏡像、創建容器并運行容器;

在實際項目部署時，我們可能最關系也最難理解就是網絡和容器這部分內容。比如，在不使用Kubernetes時，我們部署一個需要SSD資源的應用程序時，先購買SSD掛載在該服務器上，而使用Kubernetes時，我們要告訴Kubernetes只在具有SSD的節點中選擇節點部署應用。網絡和容器卷的內容還是很多很復雜的，本篇就不過多介紹，后續文章中再介紹，當然也只是簡單的理解和怎么去用，因為筆者目前理解的也不多。

需要了解的一些概念

namespaces：用于區分不同的資源，如測試環境資源、生產環境資源;當然也可以使用labels區分。不指定namespaces則默認使用default，如果使用非defalut名稱空間，則在使用kubectl創建secret、創建ServiceAccount等都需要明確指定namespaces。

節點(Node)：節點就是實際的機器或者虛擬機，例如阿里云ECS。

Pod：Pod是Kubernetes創建或部署的最小基本單位，一個Pod封裝一個或多個應用容器，存儲資源、一個獨立的網絡IP以及管理控制容器運行方式的策略選項。

(圖片來自《Kubernetes in Action》)

如上圖所示，當一個Pod包含多個容器時，這些容器總是運行于同一個工作節點上，不會跨越多個工作節點。例如我們部署一個java程序，可以在一個Pod中運行多個該java程序的容器。Pod可以封裝緊密耦合的應用，它們需要由多個容器組成，它們之間能夠共享資源，例如前后端部署在一起(這個例子不恰當)。而對于我們開發java微服務應用來說，一般一個Pod只會運行一個容器，因此初學時可以不用過多去糾結這些概念。

Service：Service抽象的概念，是Pod的邏輯分組，這一組Pod能夠被Service訪問到，通常是通過Label、Selector實現。例如：

apiVersion: v1 
kind: Service 
metadata: 
  name: demo-srv-service 
  namespace: sit 
spec: 
  selector: 
    app: demo-srv 
    env: sit 
  ports: 
    - protocol: TCP 
      port: 80 
      targetPort: 8080 

通過selector匹配app為demo-srv、env為sit的一組Pod，這組Pod對應demo-srv-service這個Service。更簡單一點理解，假設我們部署一個java程序，一個Pod只啟動一個該java程序的容器，那么啟動多個該java程序就對應多個Pod，而這組Pod對應同一個Service。

ReplicationController：ReplicationController(簡稱RC)是確保用戶定義的Pod副本數保持不變。在用戶定義范圍內，如指定一個java程序部署的集群數量為3，如果Pod超過3(例如手動啟動)，則RC會終止額外的Pod，如果少于3(例如內存溢出導致)，RC會創建新的Pod，始終保持在定義范圍。

ReplicaSet：ReplicaSet簡稱RS，是RC的升級版本。RS和RC之間的唯一區別是對選擇器(Selector)的支持，這里不做過多介紹。

Deployments：Deployment為Pod和ReplicaSet提供聲明式更新。你只需要在Deployment中描述你想要的目標狀態是什么，Deployment Controller就會幫你將Pod和ReplicaSet的實際狀態改變到你的目標狀態。

apiVersion: apps/v1 
kind: Deployment 
metadata: 
  name: demo-srv-deployment 
  namespace: sit 
spec: 
  # 副本數，運行多少個`Pod` 
  replicas: 3 
  # 選擇器，使用標簽匹配 
  selector: 
    matchLabels: 
      app: demo-srv 
  template: 
    metadata: 
      # 標簽 
      labels: 
        app: demo-srv 
        env: sit 
    spec: 
      # 容器，指定多個容器就會在一個`Pod`內運行多個容器 
      containers: 
        - name: demo-srv 
          image: registry.cn-shenzhen.aliyuncs.com/wujiuye/demo-srv 

DaemonSet：確保每個節點(物理機器或者虛擬機)上只運行一個該應用的Pod。如阿里云的實現的日記收集，就是在每個節點上運行一個用于收集日記的應用程序容器，對應一個Pod。

網絡通信

Pod之間的網絡通信：

Kubernetes集群中的所有Pod都在同一個共享網絡地址空間中，這意味著每個Pod都可以通過其他Pod的IP地址來實現相互訪問。這也表示它們之間沒有NAT網關。當兩個Pod彼此之間發送網絡數據包時，它們都會將對方的實際IP地址看作數據包中的源IP。

無論是將兩個Pod安排在單一的還是不同的工作節點上，同時不管實際節點間的網絡拓撲結構如何，這些Pod內的容器都能夠像在局域網上的計算機一樣通信。

Service之間的網絡通信：

Kubernetes service為一組功能相同的Pod提供單一不變的接入點。當服務存在時，它的IP地址和端口不會改變。客戶端通過IP地址和端口號建立連接，這些連接會被路由到提供該服務的任意一個Pod上，會實現負載均衡。通過這種方式，客戶端不需要知道每個單獨的提供服務的Pod的地址，這樣這些Pod就可以在集群中隨時被創建或移除。

假設現有一個項目，該項目有兩個微服務，分別是demo-srv、demo-cap。現在將這兩個服務部署到阿里云容器服務Kubernetes上，在控制臺的服務列表頁可以看到，這兩個服務都有一個集群IP，不管這個兩個服務部署多少個Pod，也不管Pod怎么變，其它服務都可以通過這個集群IP訪問背后的Pod，當然訪問背后Pod也是實現負載均衡的。

也是因為如此，我們開發微服務實現的服務發現都是基于Service的，那么在應用程序中實現負載均衡就顯得多余了。

類型：

• ClusterIP：通過集群的內部IP暴露服務，選擇該值，服務只能夠在Kubernetes集群內部可以訪問。
• NodePort：通過每個Node上的IP和靜態端口(NodePort)暴露服務。NodePort服務會路由到ClusterIP服務，這個ClusterIP服務會自動創建。通過請求:，可以從集群的外部訪問一個NodePort服務。
• LoadBalancer：如使用阿里云提供的負載均衡器，可以向外部暴露服務。外部的負載均衡器可以路由到NodePort服務和ClusterIP服務。

本篇就介紹到這，Kubernetes要學的知識點很多，但作為開發，我們可能不會去過多的關注一些細節，本篇介紹的知識點是筆者認為作為開發應掌握的知識的。網絡、容器卷這部署建議多了解一些，網絡有關服務間的調用，而容器卷有關日記的打印、文件存儲，如果使用阿里云容器服務，那么日記這塊我們可以不輸出到文件，使用阿里提供的日記服務收集日記。但如果需要持久化存儲的服務，就必須要了解容器卷Volume。

不懂的概念可以查閱官方文檔：http://docs.kubernetes.org.cn

想要深入學習還是推薦閱讀《Kubernetes in Action》中文版