Kubernetes理論基礎

Kubernetes理論基礎

Kubernetes定義

​ kubernetes是Google開源的容器集羣管理系統，2014年6月開源。在Docker技術之上，爲容器應用提供資源調度、部署運行、服務發現、擴容縮容、等功能，能夠看作是基於容器的micro-pass平臺，pass的表明性項目。

Kubernetes特性

• 強大的容器編排能力
• 輕量級
• 開放開源

Kubernetes核心概念

1. Pod

Pod是若干容器的組合，一個Pod內的容器都必須運行在同一臺宿主機上，這些容器使用相同的命名空間，IP地址和端口，能夠經過localhost互相發現和通訊。能夠共享一塊存儲卷空間。是Kubernetes中最小的管理單位。經過Pod更高層次的抽象，提供了更加靈活的管理方式。

2. Service

Service是應用服務的抽象，定義了Pod的邏輯上的集合和訪問Pod集合的策略。Service將代理Pod對外表現爲一個單一的訪問接口，外部不須要了解Pod如何運行，這給擴展和維護帶來不少好處，提供了一套簡化的服務代理和發現機制

例如：

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

​ 上面定義一個名爲 "tomcat-service" 的Service，服務端口爲8080，全部擁有"fronted"的這個Label的全部Pod實例都屬於這個Service。即全部 tomcat-service的流量都會被轉發到這些Pod

3. Replication Controller（RC）

​ 顧名思義"RC"用來控制作複製控制，確保用戶定義的Pod副本數保持不變。RC是彈性伸縮、滾動升級的核心。

例如：

apiVersion: v1
kind: ReplicationContorller
metadata:
 name: nginx
spec:
 replicas: 3
 selector:
   app: nginx
 template:
   metadata:
     name: nginx
     labels:
       app: ningx
   spec:
     containers:
       - name: nginx
       - images: nginx
       ports:
        - containerPort: 80

​ 上面展現了建立三個nginx的Pod，Kubernetes中Controller Manger會盡可能將擁有"app: nginx"標籤的三個Pod會分佈不一樣的Node上，保證集羣中老是會有符合RC定義的數量的Pod。當任意一個Pod、或者所屬的Node出現問題，Controller Manager會自動建立新的Pod。

​ 能夠經過控制RC來控制Pod的副本數量，來達到動態縮放的目的:

kebectl scale rc nginx --replicas=1

​ RS 和 RC 什麼關係 ？

4. Replica Sets (RS)

​ ReplicaSet（RS）是 RC 的升級版，它們的區別是對選擇器的支持。RS支持 labels user guide中描述的set-based選擇器要求，而 RC 僅僅支持qeuality-based的選擇器要求。(看一眼超連接內容、或者下文Label的內容)

​ RS 雖然能夠單獨使用，可是仍是被Deployments用做Pod的建立、刪除、更新。使用Deployment時，沒必要關心RS。能夠經過Deployment管理RS。

​ RS 和 RC都是確保運行指定數量的Pod。Deployment 是一個更高層次的概念，能夠管理RS，而且提供對Pod更新等功能，建議使用Deployment來管理RS。

​ RS 對我是隱藏的？ 直接使用Deployment來管理?

5. Deployment

​ Deployment是爲了更好的解決Pod的編排問題，在內部使用RS（RC升級版）來實現目的。在Deployment中描述目標狀態，Deployment Controller就會自動實現Deploymen中描述的目標狀態，並指導當前Pod的進度狀態。（部署是否完成）

​ Deployment建立的對象不能手動進行管理！

例如：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80

​ 能夠看到上面並無RS/RC的配置。可是Deployment會自動使用RS的方式建立Pod和Pod副本。

6. Label

​ Label就是一對 key/value，能夠被關聯到對象（Node、Pod、Service、RS），一個對象能夠關聯任意數量的Label，同一個Label也能夠被關聯到任務數量的對象上。一般在定義對象時肯定，也能夠建立對象後動態添加刪除。

​ 能夠經過對象的Label來實現多維度的資源分組管理，能夠方便的進行資源分配、調度、配置、部署等管理工做。經常使用的Label以下：

* 版本標籤release: stable、canary
* 環境標籤env: dev、production
* 架構標籤tier: frontend、backend、middleware
* 分區標籤partition: customerA、customerB
* 質量管控標籤track: daily、weekly  Master

Selector能夠理解爲SQL查詢語句中的where條件，在定義定義Service、RC/RS、Deployment時，指定相應的Label就會和自動對應的Pod對象。

7. Horizontal Pod Autoscaler（HPA）

​ 上面說到能夠經過命令（kebectl scale）手動調節Pod的數量上限擴容縮容，顯然這不夠自動化。從Kubernetes1.1版本開始，HPA功能被當作重量級特性推出。與RC、Deployment同樣，都屬於Kubernetes的一種資源對象，經過追蹤分析RC控制的全部目標Pod的負載狀況針對性的調整目標Pod的副本數量（實現原理？）。

​ Pod負載度量指標:

* CPUutilizationPercentage
    這是一個算數平均值，即全部Pod的自身CPU利用率的平均值。
* 應用自定義指標（TPS/QPS)

8. Master

​ Master是Kubernetes集羣中的控制節點，通常會獨自佔據一個服務器，Master節點上有如下關鍵組件：

Kubernetes API server (kube-apiserver), http rest接口的關鍵進程，是全部操做指令的惟一入口。
Kubernetes Controller Manager(kube-controller-manager), 全部資源對象的自動化控制中心。
Kubernetes Scheduler (kkube-scheduler,負責資源(Pod)的調度。Pod的"調度室"

9. Node

​ Node能夠理解爲Kubernetes集羣中的計算節點/工做節點，當某個Node宕機時，這個Node節點上的負載會自動轉移到其餘節點上去。Node節點上有一下關鍵組件：

kubelet: Pod 對應的容器建立、啓停、等
kube-proxy: 實現 Service的通訊與負載均衡機制的重要組件
docker: e，就是docker

10. Namespace

​ 當團隊或者項目中有多個用戶時，可使用Namepace來區分，namespace是一種將集羣資源劃分多個用途的方法。主要用於實現多租戶的資源隔離，經過Namespace將集羣內部資源對象分配到不一樣的Namespace中。造成邏輯上的分組，Kubernetes集羣啓動後會自動建立一個"default"的namespace。

11. Volume

​ Volume（存儲卷）能夠被理解爲Pod中的共享目錄，volume被定義在Pod上，Pod內的容器能夠訪問掛載。volume與Pod的生命週期相同，與具體的docker 容器生命週期不相關，某個docker容器刪除或中止時，Volume中的數據不回丟失，volume支持不少種類型文件系統，GFS/Ceph/NFS。

​ 在Kubernetes中volume有幾種類型：

1. emptyDir: 無需指定對應宿主機上的目錄文件、無需永久保留的臨時目錄，跟隨Pod的移除而被移除。
2. hostPath: 爲Pod掛載宿主機上的文件或目錄，使用宿主機的文件系統存儲，這樣的方式Kubernetes沒法對宿主機上的資源歸入管理（好比資源配額），各個Node節點上的目錄文件不一樣而致使Valume的訪問結果不一致。
3. gcePersistentDisk: Google共有云提供的永久磁盤。
4. awsElasticBloukStore: AWS提供的 EBS Volume存儲。
5. NFS: 網絡文件存儲系統
6. iscsi: iscsi 存儲設備
7. flocker: Flocker ?? 
8. glusterfs: 開源的ClusterFS網絡文件存儲系統
9. rbd: Linux 塊設備共存存儲
10. gitRepo: 從GIT 庫cone一個git repository 給Pod用
11. secret: Kubernetes中一種保存機密信息的volume，Pod經過掛載的方式獲取帳號密碼信息

Kubernetes的服務發現機制

​ Kubernetes中的每一個Service都有一個惟一的Cluster IP 和惟一的名字，名字是開發者本身定義，部署的時候也不會改變，能夠固定在配置中，因此這個問題就是：用Service 名字找到對應Cluster IP。

​ 老的解決方案中須要設置一大堆環境變量，每一個Service建立時就會生成對應的環境變量，而後Service中的每一個Pod啓動時就會加載這些變量。在後來的版本中引入了DNS系統，把服務名做爲DNS域名，這樣程序就能夠直接使用服務名來創建通訊。

外部系統訪問Service的問題

Kubernetes集羣中有三種IP：

• Node IP：Node 計算節點的IP

• Pod IP：Pod 的IP地址

• Cluster IP: Service 的IP地址

解釋

• Node IP 是集羣中每一個物理節點的IP地址，是真實存在於物理網絡中的。

• Pod IP 是每一個Pod的IP地址，是docker 根據docker0 網橋的IP地址段進行分配的，是衣蛾虛擬的二層網絡。Kubernetes集羣中要求位於不一樣Node上的Pod可以直接通訊，因此一個Pod內的容器和另外一個Pod內的容器通訊就是經過Pod IP 所在的虛擬二層網絡完成的。而實際的TCP/IP流量測試經過Node IP所在屋裏網卡流出的。

• Cluster IP 屬於Service，也是一個虛擬的IP地址。僅僅做用於Kubernetes Service 這個對象、沒法ping、只能和Service Port組成一個具體的通訊端口。Kubernetes集羣外部沒法直接使用個IP，而當服務必須被外部訪問時，能夠採用NodePort 的方法。

  例如:

  apiVersion: v1
  kind: Service
  metadata:
    name: nginx-service
  spec:
    type: NodePort
    ports:
     - port: 8080
     nodePort: 31002
    selector:
      tier: frontend

  咱們訪問http://Node:31002 便可

• NodePort 衍生的負載均衡問題

  ​ NodePort的方式在每一個Node節點上開放了端口，想讓用戶的請求轉發到這些Node上的端口，就須要一個負載均衡器。負載均衡器能夠在Kubernetes集羣內部，仍是也能夠在集羣外部？

  ​ 在集羣外部，好比GCE公有云，只要把Service的type=NodePort改成type=LoadBalancer，Kubernetes就會自動建立一個對應的Load balancer，並返回他的IP地址供外部客戶端使用。其餘雲看支不支持了。

• 最後，能夠經過 NodePort、LB、Ingress（還沒研究）這三個方式?

  • Ingress阿里雲的文檔

參考：

http://www.k8smeetup.com/article/E1eohwDEzm

國內開源的K8s相關平臺：

• domeos官網 、 文檔、github