kubernetes相關概念

kubernetes相關概念

 

 

 

 

kubernetes內部組件工做原理 http://dockone.io/article/5108

從物理層面來劃分的話，kubernetes分兩個角色，master節點和node節點：

Master

Master是整個集羣的控制中心，kubernetes的全部控制指令都是發給master，它負責具體的執行過程。通常咱們會把master獨立於一臺物理機或者一臺虛擬機，它的重要性不言而喻。

master上有這些關鍵的進程：

Kubernetes API Server（kube-apiserver)，提供了HTTP Rest接口關鍵服務進程，是全部資源增、刪、改、查等操做的惟一入口，也是集羣控制的入口進程。 #也就是說咱們想要增長或減小pod，配置一些服務（service）等等。都是要經過這個API總入口進入

Kubernetes Controller Manager(kube-controlker-manager)，是全部資源對象的自動化控制中心，能夠理解爲資源對象的大總管。

Kubernetes Scheduler(kube-scheduler)，負責資源調度（pod調度）的進程，至關於公交公司的「調度室」。 #主要針對pod，好比node在一節點仍是二節點，就是由他來調度

etcd Server，kubernetes裏全部資源對象的數據都是存儲在etcd中的。 #好比rc、service（svc）、pod這些資源對象全都存到了etcd下面

Node

除了Master，Kubernetes集羣中其餘機器被稱爲Node，早期版本叫作Minion。Node能夠是物理機也能夠是虛擬機，每一個Node上會被分配一些工做負載（即，docker容器），當Node宕機後，其上面跑的應用會被轉移到其餘Node上。

Node上有這些關鍵進程：

kubelet：負責Pod對應容器的建立、啓停等任務，同時與Master節點密切協做，實現集羣管理的基本功能。

kube-proxy：實現Kubernetes Service的通訊與負載均衡機制的重要組件。

Docker Engine（docker）：Docker引擎，負責本機容器的建立和管理。

kubectl get nodes #查看集羣中有多少個node

kubectl describe node <node name> #查看Node的詳細信息

Pod

查看pod命令： kubectl get pods #s能夠省略。

查看容器命令： docker ps

能夠看到容器和pod是有對應關係的，在咱們作過的實驗中，每一個pod對應（至少）兩個容器，一個是Pause容器，一個是rc裏面定義的容器（實際上，每一個pod裏能夠有多個應用容器）。這個Pause容器叫作「根容器」，只有當Pause容器「死亡」纔會認爲該pod「死亡」。Pause容器的IP以及其掛載的Volume資源會共享給該pod下的其餘容器。

pod定義示例： #跟上一章的rc差很少

apiVersion: v1

kind: pod #這個地方爲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'

每一個pod均可以對其能使用的服務器上的硬件資源進行限制（CPU、內存）。CPU限定的最小單位是1/1000（千分之一）個cpu，用m表示，

如100m，就是0.1個cpu。內存限定的最小單位是字節，能夠用Mi（兆） 表示，如128Mi就是128M。

在kubernetes裏，一個計算資源進行配額限定須要設定兩個參數：

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

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

資源限定示例：

spec:

containers: #定義容器

- name: db

image: mysql

resources:

requests: #最小值

memory: "64Mi"

cpu: "250m"

limits: #最大值

memory: "128Mi"

cpu: "500m"

Label

Label是一個鍵值對（標籤），其中鍵和值都由用戶自定義，Label能夠附加在各類資源對象上，如Node、Pod、Service、RC等。一個資源對象能夠定義多個Label，同一個Label也能夠被添加到任意數量的資源對象上。Label能夠在定義對象時定義，也能夠在對象建立完後動態添加或刪除。

Label示例：

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

爲了實現service和pod之間的關聯，又有了標籤（label）的概念，咱們把功能相同的pod設定爲同一個標籤，好比，能夠把全部提供mysql服務的pod貼上標籤name＝mysql，這樣mysql service要做用於全部包含name＝mysql標籤的pod上。

RC

RC是kubernetes中核心概念之一，簡單說它定義了一個指望的場景，即聲明某種pod的副本數量在任意時刻都符合某個預期

值，RC定義了以下幾個部分：

1）pod期待的副本數 #可定義多個

2）用於篩選目標pod的Label Selector

3）建立pod副本的模板（template）

RC一旦被提交到kubernetes集羣后，Master節點上的Controller Manager組件就會接收到該通知，它會按期巡檢集羣中存活的pod，並確保pod數量符合RC的定義值。能夠說經過RC，kubernetes實現了用戶應用集羣的高可用性，而且大大減小了管理員在傳統IT環境中不得不作的諸多手工運維工做，好比編寫主機監控腳本、應用監控腳本、故障恢復處理腳本等 #也就是說rc有一個機制，能夠自動的監控pod的數量是否符合預期，若是其中一個pod宕機了，能夠自動的啓動一個新的pod起來，這樣咱們不用去監控他，一切都是自動的

RC工做流程（假如，集羣中有3個Node）：

1）RC定義2個pod副本

2）假設系統會在2個Node上（Node1和Node2）建立pod

3）若是Node2上的pod（pod2）意外終止，這頗有多是由於Node2宕機

4）則會建立一個新的pod，假設會在Node3上建立pod3，固然也有可能在Node1上建立pod3

RC中動態修改pod副本數量：

kubectl scale rc <rc name> --replicas=n #n爲數量

利用動態修改pod的副本數，能夠實現應用的動態升級（滾動升級）：

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

2）新版本每增長1個pod，舊版本就減小一個pod，始終保持固定的值

3）最終舊版本pod數爲0，所有爲新版本

刪除RC：

kubectl delete rc <rc name>

刪除RC後，RC對應的pod也會被刪除掉

Deployment

在1.2版本引入的概念，目的是爲了解決pod編排問題，在內部使用了Replica Set，它和RC比較，類似度爲90%以上，能夠認爲是RC的升級版。 跟RC比較，最大的一個特色是能夠知道pod部署的進度。 #後期能夠逐漸的靠着Deployment去作，逐漸的把rc丟棄掉。目前仍是會有使用rc

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官方發佈了HPA，實現pod的動態擴容、縮容，它屬於一種kubernetes的資源對象。它經過追蹤分析

RC控制的全部目標pod的負載變化狀況，來決定是否須要針對性地調整目標Pod的副本數，這是HPA的實現原理。

pod負載度量指標：

1）CpuUtilizationPercentage

目標pod全部副本自身的cpu利用率平用均值。一個pod自身的cpu利用率＝該pod當前cpu的使用量／pod Request值。若是某

一個時刻，CPUUtilizationPercentage的值超過了80%，則斷定當前的pod已經不夠支撐業務，須要增長pod。

2）應用程序自定義的度量指標，好比服務每秒內的請求數（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控制的目標對象是一個名叫php-apache的Deployment裏的pod副本，當cpu平均值超過90%時就會擴容，pod副本數控制範圍是1－10.

除了以上的xml文件定義HPA外，也能夠用命令行的方式來定義：

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

Service

Service是kubernetes中最核心的資源對象之一，Service能夠理解成是微服務架構中的一個「微服務」，pod、RC、

Deployment都是爲Service提供嫁衣的。

簡單講一個service本質上是一組pod組成的一個集羣，前面咱們說過service和pod之間是經過Label來串起來的，相同Service的pod的Label同樣。同一個service下的全部pod是經過kube-proxy實現負載均衡，而每一個service都會分配一個全局惟一的虛擬ip，也叫作cluster ip（kubectl get svc)。在該service整個生命週期內，cluster ip是不會改變的，而在kubernetes中還有一個dns服務，它把service的name和cluster ip映射起來。（kubectl get svc出來的name和clusterip） #上一節講在沒有使用dns的時候，只能使用ip，用了dns以後，倉可使用<name>（web-rc.ymal的配置）

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地址以及端口 #這個出來的ip，咱們基本上不去用它

kubectl get svc tomcat-service -o yaml //查看service分配的cluster ip #就是指定查看他的格式是yaml

多端口的service： #就是說這個service裏面能夠有多個服務（好比web服務80的，還有php的）

apiVersion: v1

kind: Service

metadata:

name: tomcat-service

spec:

ports:

- port: 8080 #好比tomcat的8080

name: service-port

- port: 8005 #以及tomcat的8005

name: shutdown-port

selector:

tier: frontend

對於cluster ip有以下限制：

1）Cluster ip沒法被ping通，由於沒有實體網絡來響應 #可是能夠telnet <ip> <port>ping同他的端口

2）Cluster ip和Service port組成了一個具體的通訊端口，單獨的Cluster ip不具有TCP/IP通訊基礎，它們屬於一個封閉的空間。

3）在kubernetes集羣中，Node ip、pod ip、cluster ip之間的通訊，採用的是kubernetes本身設計的一套編程方式的特殊路由規則。

要想直接和service通訊，須要一個Nodeport，在service的yaml文件中定義：

apiVersion: v1

kind: Service

metadata:

name: tomcat-service

spec:

ports:

- port: 8080

nodeport: 31002 #大於30000

selector:

tier: frontend

它實質上是把cluster ip的port映射到了node ip的nodeport上了

Volume(存儲卷)

Volume是pod中可以被多個容器訪問的共享目錄，kubernetes中的volume和docker中的volume不同，主要有如下幾個方面：

1）kubernetes的volume定義在pod上，而後被一個pod裏的多個容器掛載到具體的目錄下 #同一個pod裏面的容易都是能夠去分享同一個volume的

2）kubernetes的volume與pod生命週期相同，但與容器的生命週期不要緊，當容器終止或者重啓時，volume中的數據並不會丟失

3）kubernetes支持多種類型的volume，如glusterfs，ceph等先進的分佈式文件系統

如何定義並使用volume呢？只須要在定義pod的yaml配置文件中指定volume相關配置便可：

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時建立的，初始內容爲空，不須要關心它將會在宿主機（node）上的哪一個目錄下，由於這是kubernetes自動分配的一個目錄，當pod從node上移除，emptyDir上的數據也會消失。因此，這種類型的volume不適合存儲永久數據，適合存放臨時文件。

2）hostPath

hostPath指定宿主機（node）上的目錄路徑，而後pod裏的容器掛載該共享目錄。這樣有一個問題，若是是多個node，雖然目錄同樣，可是數據不能作到一致，因此這個類型適合一個node的狀況。

配置示例：

volumes:

- name: "persistent-storage"

hostPath:

path: "/data"

3）gcePersistentDisk #離咱們比較遠

使用Google公有云GCE提供的永久磁盤（PD）存儲volume數據。毫無疑問，使用gcePersistentDisk的前提是kubernetes的

node是基於GCE的。

配置示例：

volumes:

- name: test-volume

gcePersistentDisk:

pdName: my-data-disk

fsType: ext4

4）awsElasticBlockStore #離咱們比較遠

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

5）NFS #這個離咱們比較近，後面會有演示

使用NFS做爲volume載體。

示例：

volumes:

- name: "NFS"

NFS:

server: ip地址

path: "/"

6）其餘類型

iscsi

flocker

glusterfs

rbd

gitRepo: 從git倉庫clone一個git項目，以供pod使用

secret: 用於爲pod提供加密的信息

persistent volume（PV）

PV能夠理解成kubernetes集羣中某個網絡存儲中對應的一塊存儲，它與volume相似，但有以下區別：

1）PV只能是網絡存儲，不屬於任何Node，但能夠在每一個Node上訪問到

2）PV並非定義在pod上，而是獨立於pod以外定義

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

以下是NFS類型的PV定義：

apiVersion: v1

kind: PersistentVolume

metadata:

name: pv0003

spec:

capacity:

storage: 5Gi

accessModes:

- ReadWriteOnce

nfs:

path: /somepath

server: ip

其中accessModes是一個重要的屬性，目前有如下類型：

ReadWriteOnce: 讀寫權限，而且只能被單個Node掛載

ReadOnlyMany: 只讀權限，容許被多個Node掛載

ReadWriteMany：讀寫權限，容許被多個Node掛載 #最大權限

1.若是某個pod想申請某種條件的PV，首先須要定義一個PersistentVolumeClaim（PVC）對象：

kind: persistentVolumeClaim

apiVersion: v1

metadata:

name: myclaim

spec:

accessModes:

- ReadWriteOnce

resources:

requests:

storage: 8Gi

2.而後在pod的vomume定義中引用上面的PVC：

volumes:

- name: mypd

persistentVolumeClaim:

ClaimName: myclaim

Namespace（命名空間）

當kubernetes集羣中存在多租戶的狀況下，就須要有一種機制實現每一個租戶的資源隔離。而namespace的目的就是爲了實現資源隔離。

kubectl get namespace //查看集羣全部的namespace

1.定義namespace：

apiVersion: v1

kind: Namespace

metadata:

name: dev

kubectl create -f dev-namespace.yaml //建立dev namespace

2.而後再定義pod，指定namespace

apiVersion: v1

kind: Pod

metadata:

name: busybox

namespace: dev

spec:

containers:

- image: busybox

command:

- sleep

- "500"

name: busybox

查看某個namespace下的pod：

kubectl get pod --namespace=dev

etcd

etcd是用來存儲kubernetes裏的集羣文件的（存配置文件配置的數據庫）

 

 

總結：

master（控制中心）：從物理層次去劃分兩個角色（master和node）。他包括四個服務或進程

node（真正工做的節點）：上面有docker、pod。由kubelet來管理。kube-porxy來提供總入口訪問他，實現負載均衡

pod（就是咱們的容器，上面的那一層）：pod裏面有一個pose容器，提供網絡和數據共享的一個容器

label（標籤）：經過label把pod和service關聯在一塊兒

rc：用來描述或定義pod的一個場景，用rc來定義

Deployment：是rc的升級版。他的特色是能夠知道pod部署的進度

HPA:是一個實現動態擴容縮容的一種資源對象

service：最終提供給用戶服務的。一個cluster IP，一個name，就能夠拿他去作事情了

volume：存儲卷

pv：vollume之上就是pv。咱們有了pv以後，才能夠把這麼多的pod數據落地。好比跑一個網站，那這個網站的數據存到哪裏去？數據庫數據存到哪裏去？最終要存到一個地方去，用pv來定義。有了pc還要建立一個pvc，pvc是要被pod引用的。pvc能夠自動的去關聯pv，只有pv是不行的

namespace（命名空間）：多租戶的時候，須要有一個隔離的機制