kubernetes內(nèi)部組件工作原理 http://dockone.io/article/5108

Master

Master是整個(gè)集群的控制中心，kubernetes的所有控制指令都是發(fā)給master，它負(fù)責(zé)具體的執(zhí)行過程。一般我們會(huì)把master獨(dú)立于一臺(tái)物理機(jī)或者一臺(tái)虛擬機(jī)，它的重要性不言而喻。

master上有這些關(guān)鍵的進(jìn)程：

Kubernetes API Server（kube-apiserver)，提供了HTTP Rest接口關(guān)鍵服務(wù)進(jìn)程，是所有資源增、刪、改、查等操作的唯一入口，也是集群控制的入口進(jìn)程。

Kubernetes Controller Manager(kube-controlker-manager)，是所有資源對象的自動(dòng)化控制中心，可以理解為資源對象的大總管。

Kubernetes Scheduler(kube-scheduler)，負(fù)責(zé)資源調(diào)度（pod調(diào)度）的進(jìn)程，相當(dāng)于公交公司的“調(diào)度室”。 etcd Server，kubernetes里所有資源對象的數(shù)據(jù)都是存儲(chǔ)在etcd中的。

Node

除了Master，Kubernetes集群中其他機(jī)器被稱為Node，早期版本叫做Minion。Node可以是物理機(jī)也可以是虛擬機(jī)，每個(gè) Node上會(huì)被分配一些工作負(fù)載（即，docker容器），當(dāng)Node宕機(jī)后，其上面跑的應(yīng)用會(huì)被轉(zhuǎn)移到其他Node上。

Node上有這些關(guān)鍵進(jìn)程： kubelet：負(fù)責(zé)Pod對應(yīng)容器的創(chuàng)建、啟停等任務(wù)，同時(shí)與Master節(jié)點(diǎn)密切協(xié)作，實(shí)現(xiàn)集群管理的基本功能。 kube-proxy：實(shí)現(xiàn)Kubernetes Service的通信與負(fù)載均衡機(jī)制的重要組件。 Docker Engine（docker）：Docker引擎，負(fù)責(zé)本機(jī)容器的創(chuàng)建和管理。

kubectl get nodes #查看集群中有多少個(gè)node kubectl describe node #查看Node的詳細(xì)信息

Pod

查看pod命令： kubectl get pods 查看容器命令： docker ps

可以看到容器和pod是有對應(yīng)關(guān)系的，在我們做過的實(shí)驗(yàn)中，每個(gè)pod對應(yīng)兩個(gè)容器，一個(gè)是Pause容器，一個(gè)是rc里面定義的容器（實(shí)際上，每個(gè)pod里可以有多個(gè)應(yīng)用容器）。這個(gè)Pause容器叫做“根容器”，只有當(dāng)Pause容器“死亡”才會(huì)認(rèn)為該 pod“死亡”。Pause容器的IP以及其掛載的Volume資源會(huì)共享給該pod下的其他容器。

pod定義示例：

  apiVersion: v1   kind: pod   metadata:    name: myweb    labels:          name: myweb   spec:      containers:      - name: myweb        image: kubeguide/tomcat-app:v1        ports:        - containerPort: 8080        env:        - name: MYSQL_SERVICE_HOST          value: 'mysql'        - name: MYSQL_SERVICE_PORT    value: '3306'

每個(gè)pod都可以對其能使用的服務(wù)器上的硬件資源進(jìn)行限制（CPU、內(nèi)存）。CPU限定的最小單位是1/1000個(gè)cpu，用m表示，如100m，就是0.1個(gè)cpu。內(nèi)存限定的最小單位是字節(jié)，可以用Mi（兆） 表示，如128Mi就是128M。

在kubernetes里，一個(gè)計(jì)算資源進(jìn)行配額限定需要設(shè)定兩個(gè)參數(shù)：

1） requests：該資源的最小申請量

2） Limits：該資源允許的最大使用量。

資源限定示例： spec:

  spec:    containers:    - name: db           image: mysql           resources:         requests:          memory: "64Mi"          cpu: "250m"               limits:          memory: "128Mi"                   cpu: "500m"

Label

Label是一個(gè)鍵值對，其中鍵和值都由用戶自定義，Label可以附加在各種資源對象上，如Node、Pod、Service、RC等。一個(gè)資

源對象可以定義多個(gè)Label，同一個(gè)Label也可以被添加到任意數(shù)量的資源對象上。Label可以在定義對象時(shí)定義，也可以在對象創(chuàng)建完后動(dòng)態(tài)添加或刪除。

Label示例：

"release":"stable", "environment":"dev", "tier":"backend"等等。

RC

RC是kubernetes中核心概念之一，簡單說它定義了一個(gè)期望的場景，即聲明某種pod的副本數(shù)量在任意時(shí)刻都符合某個(gè)預(yù)期值，RC定義了如下幾個(gè)部分：

1） pod期待的副本數(shù)

2） 用于篩選目標(biāo)pod的Label Selector

3） 創(chuàng)建pod副本的模板（template）

RC一旦被提交到kubernetes集群后，Master節(jié)點(diǎn)上的Controller Manager組件就會(huì)接收到該通知，它會(huì)定期巡檢集群中存活的 pod，并確保pod數(shù)量符合RC的定義值?？梢哉f通過RC，kubernetes實(shí)現(xiàn)了用戶應(yīng)用集群的高可用性，并且大大減少了管理員在傳統(tǒng)IT環(huán)境中不得不做的諸多手工運(yùn)維工作，比如編寫主機(jī)監(jiān)控腳本、應(yīng)用監(jiān)控腳本、故障恢復(fù)處理腳本等

RC工作流程（假如，集群中有3個(gè)Node）：

1） RC定義2個(gè)pod副本

2） 假設(shè)系統(tǒng)會(huì)在2個(gè)Node上（Node1和Node2）創(chuàng)建pod

3） 如果Node2上的pod（pod2）意外終止，這很有可能是因?yàn)镹ode2宕機(jī)

4） 則會(huì)創(chuàng)建一個(gè)新的pod，假設(shè)會(huì)在Node3上創(chuàng)建pod3，當(dāng)然也有可能在Node1上創(chuàng)建pod3

RC中動(dòng)態(tài)修改pod副本數(shù)量：

kubectl scale rc –replicas=n

利用動(dòng)態(tài)修改pod的副本數(shù)，可以實(shí)現(xiàn)應(yīng)用的動(dòng)態(tài)升級(jí)（滾動(dòng)升級(jí)）：

1） 以新版本的鏡像定義新的RC，但pod要和舊版本保持一致（由Label決定）

2） 新版本每增加1個(gè)pod，舊版本就減少一個(gè)pod，始終保持固定的值

3） 最終舊版本pod數(shù)為0，全部為新版本

刪除RC

kubectl delete rc

刪除RC后，RC對應(yīng)的pod也會(huì)被刪除掉

Deployment

在1.2版本引入的概念，目的是為了解決pod編排問題，在內(nèi)部使用了Replica Set，它和RC比較，相似度為90%以上，可以認(rèn)為是RC的升級(jí)版。 跟RC比較，最大的一個(gè)特點(diǎn)是可以知道pod部署的進(jìn)度。

Deployment示例：

  apiVersion: extensions/v1beta1   kind: Deployment   metadata:      name: frontend   spec:      replicas: 1      selector:          matchLabels:              tier: frontend          matchExpressions:              - {key: tier, operator: In, values: [frontend]}      template:          metadata:              labels:                  app: app-demo                  tier: frontend          spec:              containers:              - name: tomcat-demo                  image: tomcat                  imagePullPolicy: IfNotPresent                  ports:                  - containerPort: 8080

  kubectl create  -f tomcat-deployment.yaml   kubectl get deployment

HPA(Horizontail Pod Autoscaler)

在1.1版本，kubernetes官方發(fā)布了HPA，實(shí)現(xiàn)pod的動(dòng)態(tài)擴(kuò)容、縮容，它屬于一種kubernetes的資源對象。它通過追蹤分析 RC控制的所有目標(biāo)pod的負(fù)載變化情況，來決定是否需要針對性地調(diào)整目標(biāo)Pod的副本數(shù)，這是HPA的實(shí)現(xiàn)原理。

pod負(fù)載度量指標(biāo)：

1） CpuUtilizationPercentage

目標(biāo)pod所有副本自身的cpu利用率平用均值。一個(gè)pod自身的cpu利用率＝該pod當(dāng)前cpu的使用量／pod Request值。如果某一個(gè)時(shí)刻，CPUUtilizationPercentage的值超過了80%，則判定當(dāng)前的pod已經(jīng)不夠支撐業(yè)務(wù)，需要增加pod。

2） 應(yīng)用程序自定義的度量指標(biāo)，比如服務(wù)每秒內(nèi)的請求數(shù)（TPS或QPS）

HPA示例：

  apiVerion: autosacling/v1   kind: HorizontalPodAutoscaler   metadata:      name: php-apache    namespace: default   spec:    maxReplicas: 10      minReplicas: 1      scaleTargetRef:        kind: Deployment        name: php-apache      targetCPUUtilizationPercentage: 90

說明：HPA控制的目標(biāo)對象是一個(gè)名叫php-apache的Deployment里的pod副本，當(dāng)cpu平均值超過90%時(shí)就會(huì)擴(kuò)容，pod副本 數(shù)控制范圍是1－10.
除了以上的xml文件定義HPA外，也可以用命令行的方式來定義：

  kubectl autoscale deployment php-apache --cpu-percent=90 --min=1 --max=10

Service

Service是kubernetes中最核心的資源對象之一，Service可以理解成是微服務(wù)架構(gòu)中的一個(gè)“微服務(wù)”，pod、RC、 Deployment都是為Service提供嫁衣的。

簡單講一個(gè)service本質(zhì)上是一組pod組成的一個(gè)集群，前面我們說過service和pod之間是通過Label來串起來的，相同Service的 pod的Label一樣。同一個(gè)service下的所有pod是通過kube-proxy實(shí)現(xiàn)負(fù)載均衡，而每個(gè)service都會(huì)分配一個(gè)全局唯一的虛擬 ip，也叫做cluster ip。在該service整個(gè)生命周期內(nèi)，cluster ip是不會(huì)改變的，而在kubernetes中還有一個(gè)dns服務(wù)，它把 service的name和cluster ip映射起來。

service示例:(文件名tomcat-service.yaml)

  apiVersion: v1   kind: Service   metadata:     name: tomcat-service   spec:       ports:      - port: 8080        selector:             tier: frontend

  kubectl create -f tomcat-service.yaml   kubectl get endpoints  //查看pod的IP地址以及端口   kubectl get svc tomcat-service -o yaml  //查看service分配的cluster ip

多端口的service

  apiVersion: v1   kind: Service metadata:      name: tomcat-service   spec:      ports:          - port: 8080              name: service-port          - port: 8005              name: shutdown-port        selector:            tier: frontend

對于cluster ip有如下限制：

1） Cluster ip無法被ping通，因?yàn)闆]有實(shí)體網(wǎng)絡(luò)來響應(yīng)

2） Cluster ip和Service port組成了一個(gè)具體的通信端口，單獨(dú)的Cluster ip不具備TCP/IP通信基礎(chǔ)，它們屬于一個(gè)封閉的空間。

3） 在kubernetes集群中，Node ip、pod ip、cluster ip之間的通信，采用的是kubernetes自己設(shè)計(jì)的一套編程方式的特殊路由規(guī)則。

要想直接和service通信，需要一個(gè)Nodeport，在service的yaml文件中定義：

  apiVersion: v1   kind: Service   metadata:    name: tomcat-service   spec:      ports:      - port: 8080        nodeport: 31002    selector:          tier: frontend

它實(shí)質(zhì)上是把cluster ip的port映射到了node ip的nodeport上了

Volume(存儲(chǔ)卷)

Volume是pod中能夠被多個(gè)容器訪問的共享目錄，kubernetes中的volume和docker中的volume不一樣，主要有以下幾個(gè)方 面： 1）kubernetes的volume定義在pod上，然后被一個(gè)pod里的多個(gè)容器掛載到具體的目錄下 2）kubernetes的volume與pod生命周期相同，但與容器的生命周期沒關(guān)系，當(dāng)容器終止或者重啟時(shí)，volume中的數(shù)據(jù)并不會(huì) 丟失 3）kubernetes支持多種類型的volume，如glusterfs，ceph等先進(jìn)的分布式文件系統(tǒng)
如何定義并使用volume呢？只需要在定義pod的yaml配置文件中指定volume相關(guān)配置即可：

  template:        metadata:          labels:              app: app-demo                tier: frontend          spec:              volumes:                  - name: datavol                      emptyDir: {}              containers:              - name: tomcat-demo                 image: tomcat                  volumeMounts:                      - mountPath: /mydata-data                        name: datavol                    imagePullPolicy: IfNotPresent

說明: volume名字是datavol，類型是emptyDir，將volume掛載到容器的/mydata-data目錄下
volume的類型：

1）emptyDir 是在pod分配到node時(shí)創(chuàng)建的，初始內(nèi)容為空，不需要關(guān)心它將會(huì)在宿主機(jī)（node）上的哪個(gè)目錄下，因?yàn)檫@是kubernetes自 動(dòng)分配的一個(gè)目錄，當(dāng)pod從node上移除，emptyDir上的數(shù)據(jù)也會(huì)消失。所以，這種類型的volume不適合存儲(chǔ)永久數(shù)據(jù)，適合 存放臨時(shí)文件。
2）hostPath hostPath指定宿主機(jī)（node）上的目錄路徑，然后pod里的容器掛載該共享目錄。這樣有一個(gè)問題，如果是多個(gè)node，雖然目 錄一樣，但是數(shù)據(jù)不能做到一致，所以這個(gè)類型適合一個(gè)node的情況。
配置示例：

  volumes:    - name: "persistent-storage"      hostPath:        path: "/data"

3）gcePersistentDisk 使用Google公有云GCE提供的永久磁盤（PD）存儲(chǔ)volume數(shù)據(jù)。毫無疑問，使用gcePersistentDisk的前提是kubernetes的 node是基于GCE的。
配置示例：

        volumes:          - name: test-volume            gcePersistentDisk:              pdName: my-data-disk              fsType: ext4

4）awsElasticBlockStore

與GCE類似，該類型使用亞馬遜公有云提供的EBS Volume存儲(chǔ)數(shù)據(jù)，使用它的前提是Node必須是aws EC2。

5） NFS使用NFS作為volume載體。

示例：

        volumes:          - name: "NFS"            NFS:              server: ip地址              path: "/"

6） 其他類型

iscsi flocker glusterfs

rbd

gitRepo: 從git倉庫clone一個(gè)git項(xiàng)目，以供pod使用 secret: 用于為pod提供加密的信息

persistent volume（PV）

PV可以理解成kubernetes集群中某個(gè)網(wǎng)絡(luò)存儲(chǔ)中對應(yīng)的一塊存儲(chǔ)，它與volume類似，但有如下區(qū)別：

1） PV只能是網(wǎng)絡(luò)存儲(chǔ)，不屬于任何Node，但可以在每個(gè)Node上訪問到

2） PV并不是定義在pod上，而是獨(dú)立于pod之外定義

3） PV目前只有幾種類型：GCE Persistent Disk、NFS、RBD、iSCSCI、AWS ElasticBlockStore、GlusterFS

如下是NFS類型的PV定義：

  apiVersion: v1  kind: PersistentVolumemetadata:    name: pv0003  spec:    capacity:      storage: 5Gi    accessModes:      - ReadWriteOnce    nfs:      path: /somepath      server: ip  

其中accessModes是一個(gè)重要的屬性，目前有以下類型：

ReadWriteOnce: 讀寫權(quán)限，并且只能被單個(gè)Node掛載
eadOnlyMany: 只讀權(quán)限，允許被多個(gè)Node掛載

ReadWriteMany：讀寫權(quán)限，允許被多個(gè)Node掛載如果某個(gè)pod想申請某種條件的PV，首先需要定義一個(gè)PersistentVolumeClaim（PVC）對象：

  kind: persistentVolumeClaim  apiVersion: v1  metadata:    name: myclaim  spec:    accessModes:      - ReadWriteOnce    resources:      requests:        storage: 8Gi

然后在pod的vomume定義中引用上面的PVC：

  volumes:    - name: mypd      persistentVolumeClaim:        ClaimName: myclaim

Namespace（命名空間）

當(dāng)kubernetes集群中存在多租戶的情況下，就需要有一種機(jī)制實(shí)現(xiàn)每個(gè)租戶的資源隔離。而namespace的目的就是為了實(shí)現(xiàn)資源隔離。

  kubectl get namespace  //查看集群所有的namespace

定義namespace：

  apiVersion: v1  kind: Namespace  metadata:    name: dev

  kubectl create -f dev-namespace.yaml  //創(chuàng)建dev namespace

  apiVersion: v1  kind: Pod  metadata:    name: busybox    namespace: dev  spec:    containers:    - image: busybox      command:        - sleep        - "500"      name: busybox

然后再定義pod，指定namespace 查看某個(gè)namespace下的pod：

  kubectl get pod --namespace=dev