[[392655]]

本文轉載自微信公眾號「小姐姐味道」，作者小姐姐養的狗02號。轉載本文請聯系小姐姐味道公眾號。 

k8s已經成為了絕對熱門的技術，一個上點規模的公司，如果不搞k8s，都不好意思出去見人。安裝k8s要突破種種網絡阻礙，但更大的阻礙還在后面...

我發現，很多k8s的文章，根本不說人話，包括那要命的官網。

要弄明白k8s的細節，需要知道k8s是個什么東西。它的主要功能，就是容器的調度--也就是把部署實例，根據整體資源的使用狀況，部署到任何地方。先不要扯別的，那會擾亂視線，增加復雜性。

注意任何這兩個字，預示著你并不能夠通過常規的IP、端口方式訪問部署的實例。復雜性由此而生。

我們學k8s，就要看它要調度哪些資源。以傳統的感覺來看，無非就是cpu、內存、網絡、io等。在了解怎么對這些資源調度之前，先要搞懂什么叫Pod，這可是k8s的核心概念之一。

搞不懂Pod，就沒法玩k8s。

本文的腦圖，可以在這里在線查看：http://mind.xjjdog.cn/mind/cloud-k8s

1. Pod

pod是k8s調度的最小單元，包含一個或者多個容器(這里的容器你可以暫時認為是docker)。

Pod擁有一個唯一的IP地址，在包含多個容器的時候，依然是擁有一個IP地址，它是怎么辦到的呢?

xjjdog之前寫過兩篇Docker原理的文章，指出其中兩個使用到的底層技術，就是namespace和cgroup，k8s在使用多個容器的時候，用到的就是共享namespace，這樣Pod里的容器就可以通過localhost通信了，就像兩個進程一樣。同理的，Pod 可以掛載多個共享的存儲卷(Volume)，這時內部的各個容器就可以訪問共享的 Volume 進行數據的讀寫。

一些邊車(Sidecar)，以及存活探針等，也是以容器的形式，存在于Pod中的。所以Pod是一個大雜燴，它取代了docker容器的一部分工作(這既是Pause容器的職責)，比如創建一些共享的net namespace等。

那如何表示、聲明一個Pod呢?又如何指定這些容器與Pod的關系呢?k8s選用了yaml這種配置方式，初衷是避免過度的API設計。

很好，這又引入了另外一個問題，那就是yml文件的膨脹。所有的k8s運維，都有過被yml文件給支配的恐懼。

沒有銀彈，只不過把問題轉移到另外一個場景罷了。

聲明一個Pod，就是寫yml文件。一個Pod的yml樣例，可能長得像下面這樣。

apiVersion: v1           #本版號 
kind: Service            #創建的資源類型 
metadata:                #元數據必選 
  namespace: bcmall      #綁定命名空間 
  name: bcmall-srv       #Service資源名稱 
spec:                    #定義詳細信息 
  type: NodePort         #類型 
  selector:              #標簽選擇器 
    app: container-bcmall-pod  
  ports:                 #定義端口 
    - port: 8080         #port 指定server端口,此端口用于集群內部訪問 
      targetPort: 80     #綁定pod端口 
      nodePort: 14000    #將server 端口映射到Node節點的端口,用于外網訪問 
      protocol: TCP      #端口協議 

注意kind這個選項，這將是k8s概念膨脹的噩夢!k8s的各種配置，基本上都是圍著這里轉。哦對了，要讓這些yml文件生效，你需要用到kubectl 命令，就像這樣。

kubectl create -f ./bcmall.yaml 

訪問一個Pod，可以通過它的IP，也可以通過內部的域名(這時候就需要CoreDNS)。當這么用的時候，其實Pod的表現，就相當于一臺普通的機器，里面的容器就是一堆進程而已。

2. 探針和鉤子

一個Pod被調度之后，就要進行初始化。初始化肯定是得有一個反饋的，否則都不知道最終有沒有啟動成功。這些健康檢查的功能，叫做探針(Probe)，一個比較怪異的英文名詞。

常見的有livenessProbe、readinessProbe、startupProbe等三種探針。

livenessProbe有點像心跳，如果判定不在線了，就會把它干掉;readinessProbe一般表示就緒狀態，也比較像心跳，證明你的服務在正常跑著;startupProbe用于判斷容器是否已經啟動好，避免一些超時等，比如你的JVM啟動完畢了，才能對外提供服務。

一般，花費120s startupProbe的啟動實踐，每隔5s檢測一下livenessProbe，每隔10s檢測一下readinessProbe,是常用的操作。

這些信息，也是在yml中配置的，具體的配置層次如何，這里不羅嗦，您就查文檔去吧。

再說一下鉤子(Hook)。主要有PostStart和PreStop兩種。PostStart 可以在容器啟動之后就執行，PreStop 則在容器被終止之前被執行。這沒什么神奇的，就是執行一些shell腳本而已，只不過比較常用，就提升到了關鍵字的級別。

我們來看看它長什么樣子。由于這些配置文件大同小異，后面就不再貼這樣的代碼了。

apiVersion: v1 
kind: Pod 
metadata: 
  labels: 
    test: liveness 
  name: liveness-exec 
spec: 
  containers: 
  - name: liveness 
    image: k8s.gcr.io/busybox 
    args: 
    - /bin/sh 
    - -c 
    - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600 
    livenessProbe: 
      exec: 
        command: 
        - cat 
        - /tmp/healthy 
      initialDelaySeconds: 5 
      periodSeconds: 5 

3. 高可用引起的名詞爆炸

上面說到，yaml的復雜性，是由于kind的種類多所引起的。首先我們要接觸的，就是ReplicaSet。

我們需要多個副本，才能做高可用。

原因很簡單，一個Pod就相當于一臺機器，當掉之后，就無法提供服務了，這是哪門子的高可用?所以對等的Pod，要有多份才行。

ReplicaSet簡稱RS，可以讓你的Pod數量一直保持在某個水平。但它在操作起來還是有點麻煩了，所以一般使用更加高級的Deployment。Deployment可以實現一些滾動升級的需求，但前提是你需要在spec.template.metadata.labels中設置了相應的鍵值對。

k8s的一些過濾工作，都是通過labels來實現的。這其實是一種非常折衷的做法，因為它本身并沒有做一些類似于sql查詢之類的工作，就只能在這一堆map的鍵值對上做文章。比如這樣：

kubectl get pod -n demo -l app=nginx,version=v1 

是不是很魔幻的寫法?不要緊，習慣了就好了。

這些yml配置，通常都是一環套一環的，還會有交叉引用，所以也會有優先級。高階的kind會直接順帶把低階的kind一起創建了，屬于一個級聯關系。

一切不過是yml文件包了一層而已。

好了，我們要接觸下一個kind：service了。

為什么需要Service?因為我們上面創建的Pod，哪怕是Deployment創建的Pod，你訪問它都要費些功夫。雖然Pod有IP，但如果它重啟了，或者銷毀了，IP就會動態變化。因為Pod是被調度的，它并不知道自己會被調度到哪一臺機器。

Service這個東西，就是要提供一種非IP的訪問途徑，使得不論Pod在哪里，我們都能訪問的到它。

如圖所示，通過Labels的過濾，可以把多個Pod歸結為一類，然后以某種類型對外暴露服務。Service說白了也是一個組合后的東西。

對外訪問的類型，這里要著重說明一下，因為它重要，所以要敲黑板。主要有4種：

ClusterIP 創建一個虛擬的IP，唯一且不可修改。所有訪問該IP的請求，都將被iptables轉發到后端。這是默認的行為，就是一個coredns的插件

NodePort 提供一個靜態端口(NodePort)來暴露服務，主要使用的技術是NAT

LoadBalancer LoadBalancer主要用于做外部的服務發現，即暴露給集群外部的訪問

ExternalName 使用較少，感興趣的可以自行了解

但是等等。k8s是如何實現跨主機的Pod相互訪問的呢?

在單個Node上的Pod相互訪問可以理解，直接通過docker0網橋分配的IP，就可相互訪問。

那k8s的底層網絡是真么設置的呢?答案可能令人沮喪。k8s本身并不負責網絡管理，也不為容器提供具體的網絡設置，它是通過CNI(容器網絡接口)來實現的。在不同的Node之上，不同的Pod訪問就費了點勁，這正是CNI的工作。常用的CNI插件有：Flannel、Calico、Canal、Weave。

沒錯，又是一堆名詞，而且各個都很難搞。

網絡方面是k8s最復雜的知識點，框架也奇多，后面的文章會專門進行介紹。

4. 內部組件

在開啟更多的Kind之前，我們來看一下k8s的內部組件。

下面這張圖，就是官網的一張圖片，說明了k8s的一系列必要的組件。其中，etcd根本就不是這個體系里的，但k8s的一些持久化狀態，需要有個地方存，就引入了這么一個組件，用來存儲配置信息。

其中左半部分，是k8s自身的組件;右半部分，就在每個Node(也就是物理機)上的守護進程。它們的作用如下：

• kube-apiserver 提供Rest接口，屬于k8s的靈魂，所有的認證、授權、訪問控制、服務發現等功能，都通過它來暴露
• kube-scheduler 一看就是個調度組件，實際上它的作用也是這樣。它會監聽未調度的 Pod，實現你指定的目標
• kube-controller-manager 負責維護整個k8s集群的狀態。注意是k8s集群的狀態，它不管Pod
• kubelet 這是個守護進程，用來和apiserver通信，匯報自己Node的狀態;一些調度命令，也是通過kubelet來接收執行任務
• kube-proxy kube-proxy其實就是管理service的訪問入口,包括集群內Pod到Service的訪問和集群外訪問service。我們上面提到的四種模式，就是通過proxy進行轉發的

這些組件的職責，已經是非常非常清楚了。難點還是在多種Kind概念上。

5. 更多概念

圖中的這些概念，本質上都是在Pod之上，又包了一層。層次越高，功能越抽象，依賴的配置也越多。下面將挑主要的進行介紹。

• StatefulSet Deployment部署后的實例，它的id都是隨機的，比如bcmall-deployment-5d45f98bd9，它是無狀態的。與此對用的是StatefulSet，生成的實例名稱是類似bcmall-deployment-1這樣的。它具備固定的網絡標記，比如主機名，域名等，可以按照順序來部署和擴展，非常適合類似MySQL這樣的實例部署
• DaemonSet 用于確保集群中的每一個節點只運行特定的pod副本，通常用于實現系統級后臺任務
• configMap和Secret 顧名思義，就是做配置用的，因為容器或多或少會需要外部傳入一些環境變量。可以用來實現業務配置的統一管理， 允許將配置文件與鏡像文件分離，以使容器化的應用程序具有可移植性
• PV和PVC 業務運行就需要存儲，可以通過PV進行定義。PV的生命周期獨立于Pod的生命周期，就是一段網絡存儲;PVC是用戶對于存儲的需求：Pod消耗節點資源，PVC消耗PV資源，PVC和PV是一一對應的。沒錯，它們都是通過yml文件聲明的
• **StorageClass ** 可以實現動態PV，是更進一步的封裝
• Job 只要完成就立即退出，不需要重啟或重建
• Cronjob 周期性任務控制，不需要持續后臺運行
• CRD

6. 資源限制

很好，我們終于要聊一點資源限制方面的內容了。k8s的資源限制，仍然是通過cgroup來實現的。

k8s提供了requests和limits 兩種類型參數對資源進行預分配和使用限制。

不要被這兩個詞給迷惑了。requests就相當于JVM參數中的-Xms，limits就相當于-Xmx。所以，如果你類比著把這兩個值設置成一樣的，是一種最佳的實踐方式。

只是它的設置有點怪異：

requests: 
 memory: "64Mi" 
 cpu: "250m" 
limits: 
 memory: "128Mi" 
 cpu: "500m" 

內存的單位是Mi，而cpu的單位是m，要多別扭有多別扭，但它是有原因的。

m是毫核的意思。比如，我們的操作系統有4核，把它乘以1000，那就是總CPU資源是4000毫核。如果你想要你的應用最多占用1/4核，那就設置成250m。

再來看內存，Mi是MiB的意思，我也搞不懂為啥不用MB，而使用Mi，可能是想讓你印象深刻吧(MB和MiB還真不一樣)。

若內存使用超出限制，會引發系統的OOM機制，但CPU不會，頂多會影響系統運行罷了。

k8s還提供了叫做LimitRange和ResourceQuota的Kind，用來限定CPU和Memory的申請范圍，功能更加高級。

7. 集群搭建工具

k8s的集群搭建，常見的有kind，minikube，kubeadm，rancher2等。其中rancher2可以說是相對來說比較容易的方式。它考慮了一些網絡不通的因素，有一些推薦的代理選項，對于新手來說，拿來嘗嘗鮮還是很好用的。

但在正常的使用中，還是推薦你使用kubeadm這個工具，這是官方維護和推薦的搭建工具，并做到了向下兼容，按照官方的指引，只需要kubeadm init就能搭建完畢。至于什么監控、日志等，反倒是好處理的了。

k8s最麻煩的有三點：

• yml文件概念爆炸
• 網絡方案多樣、復雜
• 權限、證書配置繁瑣

搞懂了這三個方面，可以說玩轉k8s就沒問題了。

作者簡介：小姐姐味道 (xjjdog)，一個不允許程序員走彎路的公眾號。聚焦基礎架構和Linux。十年架構，日百億流量，與你探討高并發世界，給你不一樣的味道。我的個人微信xjjdog0，歡迎添加好友，進一步交流。