k8s介紹及與docker搭建叢集

思維的深度發表於2018-05-13

一、Kubernetes系列之介紹篇

 
•Kubernetes介紹
1.背景介紹
  雲端計算飛速發展
    - IaaS
    - PaaS
    - SaaS
  Docker技術突飛猛進
    - 一次構建,到處執行
    - 容器的快速輕量
    - 完整的生態環境
2.什麼是kubernetes
  首先,他是一個全新的基於容器技術的分散式架構領先方案。Kubernetes(k8s)是Google開源的容器叢集管理系統(谷歌內部:Borg)。在Docker技術的基礎上,為容器化的應用提供部署執行、資源排程、服務發現和動態伸縮等一系列完整功能,提高了大規模容器叢集管理的便捷性。
  Kubernetes是一個完備的分散式系統支撐平臺,具有完備的叢集管理能力,多擴多層次的安全防護和准入機制、多租戶應用支撐能力、透明的服務註冊和發現機制、內建智慧負載均衡器、強大的故障發現和自我修復能力、服務滾動升級和線上擴容能力、可擴充套件的資源自動排程機制以及多粒度的資源配額管理能力。同時Kubernetes提供完善的管理工具,涵蓋了包括開發、部署測試、運維監控在內的各個環節。
Kubernetes中,Service是分散式叢集架構的核心,一個Service物件擁有如下關鍵特徵:
  • 擁有一個唯一指定的名字
  • 擁有一個虛擬IP(Cluster IP、Service IP、或VIP)和埠號
  • 能夠體統某種遠端服務能力
  • 被對映到了提供這種服務能力的一組容器應用上
  Service的服務程式目前都是基於Socket通訊方式對外提供服務,比如Redis、Memcache、MySQL、Web Server,或者是實現了某個具體業務的一個特定的TCP Server程式,雖然一個Service通常由多個相關的服務程式來提供服務,每個服務程式都有一個獨立的Endpoint(IP+Port)訪問點,但Kubernetes能夠讓我們通過服務連線到指定的Service上。有了Kubernetes內奸的透明負載均衡和故障恢復機制,不管後端有多少服務程式,也不管某個服務程式是否會由於發生故障而重新部署到其他機器,都不會影響我們隊服務的正常呼叫,更重要的是這個Service本身一旦建立就不會發生變化,意味著在Kubernetes叢集中,我們不用為了服務的IP地址的變化問題而頭疼了。
  容器提供了強大的隔離功能,所有有必要把為Service提供服務的這組程式放入容器中進行隔離。為此,Kubernetes設計了Pod物件,將每個服務程式包裝到相對應的Pod中,使其成為Pod中執行的一個容器。為了建立Service與Pod間的關聯管理,Kubernetes給每個Pod貼上一個標籤Label,比如執行MySQL的Pod貼上name=mysql標籤,給執行PHP的Pod貼上name=php標籤,然後給相應的Service定義標籤選擇器Label Selector,這樣就能巧妙的解決了Service於Pod的關聯問題。
  在叢集管理方面,Kubernetes將叢集中的機器劃分為一個Master節點和一群工作節點Node,其中,在Master節點執行著叢集管理相關的一組程式kube-apiserver、kube-controller-manager和kube-scheduler,這些程式實現了整個叢集的資源管理、Pod排程、彈性伸縮、安全控制、系統監控和糾錯等管理能力,並且都是全自動完成的。Node作為叢集中的工作節點,執行真正的應用程式,在Node上Kubernetes管理的最小執行單元是Pod。Node上執行著Kubernetes的kubelet、kube-proxy服務程式,這些服務程式負責Pod的建立、啟動、監控、重啟、銷燬以及實現軟體模式的負載均衡器。
  在Kubernetes叢集中,它解決了傳統IT系統中服務擴容和升級的兩大難題。你只需為需要擴容的Service關聯的Pod建立一個Replication Controller簡稱(RC),則該Service的擴容及後續的升級等問題將迎刃而解。在一個RC定義檔案中包括以下3個關鍵資訊。
  • 目標Pod的定義
  • 目標Pod需要執行的副本數量(Replicas)
  • 要監控的目標Pod標籤(Label)
  在建立好RC後,Kubernetes會通過RC中定義的的Label篩選出對應Pod例項並實時監控其狀態和數量,如果例項數量少於定義的副本數量,則會根據RC中定義的Pod模板來建立一個新的Pod,然後將新Pod排程到合適的Node上啟動執行,知道Pod例項的數量達到預定目標,這個過程完全是自動化。
  
 Kubernetes優勢:
    - 容器編排
    - 輕量級
    - 開源
    - 彈性伸縮
    - 負載均衡
•Kubernetes的核心概念
1.Master
  k8s叢集的管理節點,負責管理叢集,提供叢集的資源資料訪問入口。擁有Etcd儲存服務(可選),執行Api Server程式,Controller Manager服務程式及Scheduler服務程式,關聯工作節點Node。Kubernetes API server提供HTTP Rest介面的關鍵服務程式,是Kubernetes裡所有資源的增、刪、改、查等操作的唯一入口。也是叢集控制的入口程式;Kubernetes Controller Manager是Kubernetes所有資源物件的自動化控制中心;Kubernetes Schedule是負責資源排程(Pod排程)的程式
 
2.Node
  Node是Kubernetes叢集架構中執行Pod的服務節點(亦叫agent或minion)。Node是Kubernetes叢集操作的單元,用來承載被分配Pod的執行,是Pod執行的宿主機。關聯Master管理節點,擁有名稱和IP、系統資源資訊。執行docker eninge服務,守護程式kunelet及負載均衡器kube-proxy.
  • 每個Node節點都執行著以下一組關鍵程式
  • kubelet:負責對Pod對於的容器的建立、啟停等任務
  • kube-proxy:實現Kubernetes Service的通訊與負載均衡機制的重要元件
  • Docker Engine(Docker):Docker引擎,負責本機容器的建立和管理工作
  Node節點可以在執行期間動態增加到Kubernetes叢集中,預設情況下,kubelet會想master註冊自己,這也是Kubernetes推薦的Node管理方式,kubelet程式會定時向Master彙報自身情報,如作業系統、Docker版本、CPU和記憶體,以及有哪些Pod在執行等等,這樣Master可以獲知每個Node節點的資源使用情況,冰實現高效均衡的資源排程策略。、
 
3.Pod
  執行於Node節點上,若干相關容器的組合。Pod內包含的容器執行在同一宿主機上,使用相同的網路名稱空間、IP地址和埠,能夠通過localhost進行通。Pod是Kurbernetes進行建立、排程和管理的最小單位,它提供了比容器更高層次的抽象,使得部署和管理更加靈活。一個Pod可以包含一個容器或者多個相關容器。
  Pod其實有兩種型別:普通Pod和靜態Pod,後者比較特殊,它並不存在Kubernetes的etcd儲存中,而是存放在某個具體的Node上的一個具體檔案中,並且只在此Node上啟動。普通Pod一旦被建立,就會被放入etcd儲存中,隨後會被Kubernetes Master排程到摸個具體的Node上進行繫結,隨後該Pod被對應的Node上的kubelet程式例項化成一組相關的Docker容器冰啟動起來,在。在預設情況下,當Pod裡的某個容器停止時,Kubernetes會自動檢測到這個問起並且重啟這個Pod(重啟Pod裡的所有容器),如果Pod所在的Node當機,則會將這個Node上的所有Pod重新排程到其他節點上。
 
4.Replication Controller
  Replication Controller用來管理Pod的副本,保證叢集中存在指定數量的Pod副本。叢集中副本的數量大於指定數量,則會停止指定數量之外的多餘容器數量,反之,則會啟動少於指定數量個數的容器,保證數量不變。Replication Controller是實現彈性伸縮、動態擴容和滾動升級的核心。
 
5.Service
  Service定義了Pod的邏輯集合和訪問該集合的策略,是真實服務的抽象。Service提供了一個統一的服務訪問入口以及服務代理和發現機制,關聯多個相同Label的Pod,使用者不需要了解後臺Pod是如何執行。
外部系統訪問Service的問題
  首先需要弄明白Kubernetes的三種IP這個問題
    Node IP:Node節點的IP地址
    Pod IP: Pod的IP地址
    Cluster IP:Service的IP地址
  首先,Node IP是Kubernetes叢集中節點的物理網路卡IP地址,所有屬於這個網路的伺服器之間都能通過這個網路直接通訊。這也表明Kubernetes叢集之外的節點訪問Kubernetes叢集之內的某個節點或者TCP/IP服務的時候,必須通過Node IP進行通訊
  其次,Pod IP是每個Pod的IP地址,他是Docker Engine根據docker0網橋的IP地址段進行分配的,通常是一個虛擬的二層網路。
  最後Cluster IP是一個虛擬的IP,但更像是一個偽造的IP網路,原因有以下幾點
  • Cluster IP僅僅作用於Kubernetes Service這個物件,並由Kubernetes管理和分配P地址
  • Cluster IP無法被ping,他沒有一個“實體網路物件”來響應
  • Cluster IP只能結合Service Port組成一個具體的通訊埠,單獨的Cluster IP不具備通訊的基礎,並且他們屬於Kubernetes叢集這樣一個封閉的空間。
Kubernetes叢集之內,Node IP網、Pod IP網於Cluster IP網之間的通訊,採用的是Kubernetes自己設計的一種程式設計方式的特殊路由規則。
 
6.Label
 Kubernetes中的任意API物件都是通過Label進行標識,Label的實質是一系列的Key/Value鍵值對,其中key於value由使用者自己指定。Label可以附加在各種資源物件上,如Node、Pod、Service、RC等,一個資源物件可以定義任意數量的Label,同一個Label也可以被新增到任意數量的資源物件上去。Label是Replication Controller和Service執行的基礎,二者通過Label來進行關聯Node上執行的Pod。
我們可以通過給指定的資源物件捆綁一個或者多個不同的Label來實現多維度的資源分組管理功能,以便於靈活、方便的進行資源分配、排程、配置等管理工作。
一些常用的Label如下:
  • 版本標籤:"release":"stable","release":"canary"......
  • 環境標籤:"environment":"dev","environment":"qa","environment":"production"
  • 架構標籤:"tier":"frontend","tier":"backend","tier":"middleware"
  • 分割槽標籤:"partition":"customerA","partition":"customerB"
  • 質量管控標籤:"track":"daily","track":"weekly"
  Label相當於我們熟悉的標籤,給某個資源物件定義一個Label就相當於給它大了一個標籤,隨後可以通過Label Selector(標籤選擇器)查詢和篩選擁有某些Label的資源物件,Kubernetes通過這種方式實現了類似SQL的簡單又通用的物件查詢機制。
 
  Label Selector在Kubernetes中重要使用場景如下:
    •   kube-Controller程式通過資源物件RC上定義Label Selector來篩選要監控的Pod副本的數量,從而實現副本數量始終符合預期設定的全自動控制流程
    •   kube-proxy程式通過Service的Label Selector來選擇對應的Pod,自動建立起每個Service島對應Pod的請求轉發路由表,從而實現Service的智慧負載均衡
    •   通過對某些Node定義特定的Label,並且在Pod定義檔案中使用Nodeselector這種標籤排程策略,kuber-scheduler程式可以實現Pod”定向排程“的特性
 
Kubernetes架構和元件

  - 服務分組,小叢集,多叢集
  - 服務分組,大叢集,單叢集
 
•Kubernetes 元件:
  Kubernetes Master控制元件,排程管理整個系統(叢集),包含如下元件:
  1.Kubernetes API Server
    作為Kubernetes系統的入口,其封裝了核心物件的增刪改查操作,以RESTful API介面方式提供給外部客戶和內部元件呼叫。維護的REST物件持久化到Etcd中儲存。
  2.Kubernetes Scheduler
    為新建立的Pod進行節點(node)選擇(即分配機器),負責叢集的資源排程。元件抽離,可以方便替換成其他排程器。
  3.Kubernetes Controller
    負責執行各種控制器,目前已經提供了很多控制器來保證Kubernetes的正常執行。
  4. Replication Controller
    管理維護Replication Controller,關聯Replication Controller和Pod,保證Replication Controller定義的副本數量與實際執行Pod數量一致。
  5. Node Controller
    管理維護Node,定期檢查Node的健康狀態,標識出(失效|未失效)的Node節點。
  6. Namespace Controller
    管理維護Namespace,定期清理無效的Namespace,包括Namesapce下的API物件,比如Pod、Service等。
  7. Service Controller
    管理維護Service,提供負載以及服務代理。
  8.EndPoints Controller
    管理維護Endpoints,關聯Service和Pod,建立Endpoints為Service的後端,當Pod發生變化時,實時更新Endpoints。
  9. Service Account Controller
    管理維護Service Account,為每個Namespace建立預設的Service Account,同時為Service Account建立Service Account Secret。
  10. Persistent Volume Controller
    管理維護Persistent Volume和Persistent Volume Claim,為新的Persistent Volume Claim分配Persistent Volume進行繫結,為釋放的Persistent Volume執行清理回收。
  11. Daemon Set Controller
    管理維護Daemon Set,負責建立Daemon Pod,保證指定的Node上正常的執行Daemon Pod。
  12. Deployment Controller
    管理維護Deployment,關聯Deployment和Replication Controller,保證執行指定數量的Pod。當Deployment更新時,控制實現Replication Controller和 Pod的更新。
  13.Job Controller
    管理維護Job,為Jod建立一次性任務Pod,保證完成Job指定完成的任務數目
  14. Pod Autoscaler Controller
    實現Pod的自動伸縮,定時獲取監控資料,進行策略匹配,當滿足條件時執行Pod的伸縮動作。
 
•Kubernetes Node執行節點,執行管理業務容器,包含如下元件:
  1.Kubelet
    負責管控容器,Kubelet會從Kubernetes API Server接收Pod的建立請求,啟動和停止容器,監控容器執行狀態並彙報給Kubernetes API Server。
  2.Kubernetes Proxy
    負責為Pod建立代理服務,Kubernetes Proxy會從Kubernetes API Server獲取所有的Service資訊,並根據Service的資訊建立代理服務,實現Service到Pod的請求路由和轉發,從而實現Kubernetes層級的虛擬轉發網路。
  3.Docker
    Node上需要執行容器服務

二、基於kubernetes構建Docker叢集環境實戰

kubernetes是google公司基於docker所做的一個分散式叢集,有以下主件組成
  etcd: 高可用儲存共享配置和服務發現,作為與minion機器上的flannel配套使用,作用是使每臺 minion上執行的docker擁有不同的ip段,最終目的是使不同minion上正在執行的docker containner都有一個與別的任意一個containner(別的minion上執行的docker containner)不一樣的IP地址。
  flannel: 網路結構支援
  kube-apiserver: 不論通過kubectl還是使用remote api 直接控制,都要經過apiserver
  kube-controller-manager: 對replication controller, endpoints controller, namespace controller, and serviceaccounts controller的迴圈控制,與kube-apiserver互動,保證這些controller工作
  kube-scheduler: Kubernetes scheduler的作用就是根據特定的排程演算法將pod排程到指定的工作節點(minion)上,這一過程也叫繫結(bind)
  kubelet: Kubelet執行在Kubernetes Minion Node上. 它是container agent的邏輯繼任者
  kube-proxy: kube-proxy是kubernetes 裡執行在minion節點上的一個元件, 它起的作用是一個服務代理的角色
 
圖為GIT+Jenkins+Kubernetes+Docker+Etcd+confd+Nginx+Glusterfs架構
如下:

 

環境:
centos7系統機器三臺:
    10.0.0.81: 用來安裝kubernetes master
    10.0.0.82: 用作kubernetes minion (minion1)
    10.0.0.83: 用作kubbernetes minion (minion2)
 
一、關閉系統執行的防火牆及selinux
1。如果系統開啟了防火牆則按如下步驟關閉防火牆(所有機器)
# systemctl stop firewalld # systemctl disable firewalld

2.關閉selinux

#setenforce 0
#sed -i '/^SELINUX=/cSELINUX=disabled' /etc/sysconfig/selinux
二、MASTER安裝配置
1. 安裝並配置Kubernetes master(yum 方式)
# yum -y install etcd kubernetes

    

 配置etcd。確保列出的這些項都配置正確並且沒有被註釋掉,下面的配置都是如此 

1
2
3
4
5
6
#vim /etc/etcd/etcd.conf
  
ETCD_NAME=default
ETCD_DATA_DIR="/var/lib/etcd/default.etcd"
ETCD_LISTEN_CLIENT_URLS="http://0.0.0.0:2379"
ETCD_ADVERTISE_CLIENT_URLS="http://localhost:2379"

  配置kubernetes

1
2
3
4
5
6
7
8
vim /etc/kubernetes/apiserver
  
KUBE_API_ADDRESS="--address=0.0.0.0"KUBE_API_PORT="--port=8080"
KUBELET_PORT="--kubelet_port=10250"
KUBE_ETCD_SERVERS="--etcd_servers=http://127.0.0.1:2379"
KUBE_SERVICE_ADDRESSES="--service-cluster-ip-range=10.254.0.0/16"
KUBE_ADMISSION_CONTROL="--admission_control=NamespaceLifecycle,NamespaceExists,LimitRanger,SecurityContextDeny,ResourceQuota"
KUBE_API_ARGS=""

   

2. 啟動etcd, kube-apiserver, kube-controller-manager and kube-scheduler服務
1
# for SERVICES in etcd kube-apiserver kube-controller-manager kube-scheduler; do systemctl restart $SERVICES systemctl enable $SERVICES systemctl status $SERVICES done

3.設定etcd網路

1
#etcdctl -C 10.0.0.81:2379 set /atomic.io/network/config '{"Network":"10.1.0.0/16"}'
4. 至此master配置完成,執行kubectl get nodes可以檢視有多少minion在執行,以及其狀態。這裡我們的minion還都沒有開始安裝配置,所以執行之後結果為空
1
# kubectl get nodes NAME LABELS STATUS

   

三、MINION安裝配置(每臺minion機器都按如下安裝配置)
 
1. 環境安裝和配置
1
# yum -y install flannel kubernetes

  配置kubernetes連線的服務端IP

1
2
3
#vim /etc/kubernetes/config
KUBE_MASTER="--master=http://10.0.0.81:8080"
KUBE_ETCD_SERVERS="--etcd_servers=http://10.0.0.81:2379"

  配置kubernetes  ,(請使用每臺minion自己的IP地址比如10.0.0.81:代替下面的$LOCALIP)

 
1
2
3
4
5
#vim /etc/kubernetes/kubelet<br>KUBELET_ADDRESS="--address=0.0.0.0"
KUBELET_PORT="--port=10250"
# change the hostname to this host’s IP address KUBELET_HOSTNAME="--hostname_override=$LOCALIP"
KUBELET_API_SERVER="--api_servers=http://10.0.0.81:8080"
KUBELET_ARGS=""

  

2. 準備啟動服務(如果本來機器上已經執行過docker的請看過來,沒有執行過的請忽略此步驟)
    執行ifconfig,檢視機器的網路配置情況(有docker0)
1
2
3
4
5
# ifconfig docker0
Link encap:Ethernet HWaddr 02:42:B2:75:2E:67 inet addr:172.17.0.1 Bcast:0.0.0.0 Mask:255.255.0.0 UP
BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0
errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

  warning:在執行過docker的機器上可以看到有docker0,這裡在啟動服務之前需要刪掉docker0配置,在命令列執行:sudo ip link delete docker0

3.配置flannel網路

1
2
3
#vim /etc/sysconfig/flanneld
FLANNEL_ETCD_ENDPOINTS="http://10.0.0.81:2379"
FLANNEL_ETCD_PREFIX="/atomic.io/network"  
PS:其中atomic.io與上面etcd中的Network對應
 
4. 啟動服務
1
# for SERVICES in flanneld kube-proxy kubelet docker; do systemctl restart $SERVICES systemctl enable $SERVICES systemctl status $SERVICES done

 

四、配置完成驗證安裝
    確定兩臺minion(10.0.0.82和10.0.0.83)和一臺master(10.0.0.81)都已經成功的安裝配置並且服務都已經啟動了。
    切換到master機器上,執行命令kubectl get nodes 
1
2
3
4
# kubectl get nodes
NAME STATUS AGE
10.0.0.82 Ready 1m
10.0.0.83 Ready 1m

  可以看到配置的兩臺minion已經在master的node列表中了。如果想要更多的node,只需要按照minion的配置,配置更多的機器就可以了。

三、Kubernetes之深入瞭解Pod

 
1、yaml格式的Pod配置檔案內容及註解
  深入Pod之前,首先我們來了解下Pod的yaml整體檔案內容及功能註解。
如下:

 

# yaml格式的pod定義檔案完整內容:
apiVersion: v1       #必選,版本號,例如v1
kind: Pod       #必選,Pod
metadata:       #必選,後設資料
  name: string       #必選,Pod名稱
  namespace: string    #必選,Pod所屬的名稱空間
  labels:      #自定義標籤
    - name: string     #自定義標籤名字
  annotations:       #自定義註釋列表
    - name: string
spec:         #必選,Pod中容器的詳細定義
  containers:      #必選,Pod中容器列表
  - name: string     #必選,容器名稱
    image: string    #必選,容器的映象名稱
    imagePullPolicy: [Always | Never | IfNotPresent] #獲取映象的策略 Alawys表示下載映象 IfnotPresent表示優先使用本地映象,否則下載映象,Nerver表示僅使用本地映象
    command: [string]    #容器的啟動命令列表,如不指定,使用打包時使用的啟動命令
    args: [string]     #容器的啟動命令引數列表
    workingDir: string     #容器的工作目錄
    volumeMounts:    #掛載到容器內部的儲存卷配置
    - name: string     #引用pod定義的共享儲存卷的名稱,需用volumes[]部分定義的的卷名
      mountPath: string    #儲存卷在容器內mount的絕對路徑,應少於512字元
      readOnly: boolean    #是否為只讀模式
    ports:       #需要暴露的埠庫號列表
    - name: string     #埠號名稱
      containerPort: int   #容器需要監聽的埠號
      hostPort: int    #容器所在主機需要監聽的埠號,預設與Container相同
      protocol: string     #埠協議,支援TCP和UDP,預設TCP
    env:       #容器執行前需設定的環境變數列表
    - name: string     #環境變數名稱
      value: string    #環境變數的值
    resources:       #資源限制和請求的設定
      limits:      #資源限制的設定
        cpu: string    #Cpu的限制,單位為core數,將用於docker run --cpu-shares引數
        memory: string     #記憶體限制,單位可以為Mib/Gib,將用於docker run --memory引數
      requests:      #資源請求的設定
        cpu: string    #Cpu請求,容器啟動的初始可用數量
        memory: string     #記憶體清楚,容器啟動的初始可用數量
    livenessProbe:     #對Pod內個容器健康檢查的設定,當探測無響應幾次後將自動重啟該容器,檢查方法有exec、httpGet和tcpSocket,對一個容器只需設定其中一種方法即可
      exec:      #對Pod容器內檢查方式設定為exec方式
        command: [string]  #exec方式需要制定的命令或指令碼
      httpGet:       #對Pod內個容器健康檢查方法設定為HttpGet,需要制定Path、port
        path: string
        port: number
        host: string
        scheme: string
        HttpHeaders:
        - name: string
          value: string
      tcpSocket:     #對Pod內個容器健康檢查方式設定為tcpSocket方式
         port: number
       initialDelaySeconds: 0  #容器啟動完成後首次探測的時間,單位為秒
       timeoutSeconds: 0   #對容器健康檢查探測等待響應的超時時間,單位秒,預設1秒
       periodSeconds: 0    #對容器監控檢查的定期探測時間設定,單位秒,預設10秒一次
       successThreshold: 0
       failureThreshold: 0
       securityContext:
         privileged:false
    restartPolicy: [Always | Never | OnFailure]#Pod的重啟策略,Always表示一旦不管以何種方式終止執行,kubelet都將重啟,OnFailure表示只有Pod以非0退出碼退出才重啟,Nerver表示不再重啟該Pod
    nodeSelector: obeject  #設定NodeSelector表示將該Pod排程到包含這個label的node上,以key:value的格式指定
    imagePullSecrets:    #Pull映象時使用的secret名稱,以key:secretkey格式指定
    - name: string
    hostNetwork:false      #是否使用主機網路模式,預設為false,如果設定為true,表示使用宿主機網路
    volumes:       #在該pod上定義共享儲存卷列表
    - name: string     #共享儲存卷名稱 (volumes型別有很多種)
      emptyDir: {}     #型別為emtyDir的儲存卷,與Pod同生命週期的一個臨時目錄。為空值
      hostPath: string     #型別為hostPath的儲存卷,表示掛載Pod所在宿主機的目錄
        path: string     #Pod所在宿主機的目錄,將被用於同期中mount的目錄
      secret:      #型別為secret的儲存卷,掛載叢集與定義的secre物件到容器內部
        scretname: string  
        items:     
        - key: string
          path: string
      configMap:     #型別為configMap的儲存卷,掛載預定義的configMap物件到容器內部
        name: string
        items:
        - key: string
          path: string    

2、Pod基本用法:
  在使用docker時,我們可以使用docker run命令建立並啟動一個容器,而在Kubernetes系統中對長時間執行的容器要求是:其主程式需要一直在前臺執行。如果我們建立的docker映象的啟動命令是後臺執行程式,例如Linux指令碼:
  nohup ./startup.sh &
  則kubelet建立包含這個容器的pod後執行完該命令,即認為Pod執行結束,之後根據RC中定義的pod的replicas副本數量生產一個新的pod,而一旦建立出新的pod,將在執行完命令後陷入無限迴圈的過程中,這就是Kubernetes需要我們建立的docker映象以一個前臺命令作為啟動命令的原因。
  對於無法改造為前臺執行的應用,也可以使用開源工具supervisor輔助進行前臺執行的功能。
****Pod可以由一個或多個容器組合而成
例如:兩個容器應用的前端frontend和redis為緊耦合的關係,應該組合成一個整體對外提供服務,則應該將這兩個打包為一個pod.
配置檔案frontend-localredis-pod.yaml如下:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
apiVersion:v1
kind: Pod
metadata:
  name: redis-php
  label:
    name: redis-php
spec:
  containers:
  - name: frontend
    image: kubeguide/guestbook-php-frontend:localredis
    ports:
    - containersPort: 80
  - name: redis-php
    image:kubeguide/redis-master
    ports:
    - containersPort: 6379

  

  屬於一個Pod的多個容器應用之間相互訪問只需要通過localhost就可以通訊,這一組容器被繫結在一個環境中。
  使用kubectl create建立該Pod後,get Pod資訊可以看到如下圖:
1
2
3
#kubectl get gods
NAME READY STATUS RESTATS AGE
redis-php 2/2Running 0 10m

  可以看到READY資訊為2/2,表示Pod中的兩個容器都成功執行了.

  檢視pod的詳細資訊,可以看到兩個容器的定義和建立過程。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
[root@kubernetes-master ~]# kubectl describe redis-php
the server doesn't have a resourcetype "redis-php"
[root@kubernetes-master ~]# kubectl describe pod redis-php
Name: redis-php
Namespace: default
Node: kubernetes-minion/10.0.0.23
Start Time: Wed, 12 Apr 2017 09:14:58 +0800
Labels: name=redis-php
Status: Running
IP: 10.1.24.2
Controllers: <none>
Containers:
nginx:
Container ID: docker://d05b743c200dff7cf3b60b7373a45666be2ebb48b7b8b31ce0ece9be4546ce77
Image: nginx
Image ID: docker-pullable://docker.io/nginx@sha256:e6693c20186f837fc393390135d8a598a96a833917917789d63766cab6c59582
Port: 80/TCP
State: Running
Started: Wed, 12 Apr 2017 09:19:31 +0800

  

3、靜態Pod
  靜態pod是由kubelet進行管理的僅存在於特定Node的Pod上,他們不能通過API Server進行管理,無法與ReplicationController、Deployment或者DaemonSet進行關聯,並且kubelet無法對他們進行健康檢查。靜態Pod總是由kubelet進行建立,並且總是在kubelet所在的Node上執行。
建立靜態Pod有兩種方式:配置檔案或者HTTP方式
1)配置檔案方式
  首先,需要設定kubelet的啟動引數"--config",指定kubelet需要監控的配置檔案所在的目錄,kubelet會定期掃描該目錄,冰根據目錄中的 .yaml或 .json檔案進行建立操作
假設配置目錄為/etc/kubelet.d/配置啟動引數:--config=/etc/kubelet.d/,然後重啟kubelet服務後,再宿主機受用docker ps或者在Kubernetes Master上都可以看到指定的容器在列表中
由於靜態pod無法通過API Server直接管理,所以在master節點嘗試刪除該pod,會將其變為pending狀態,也不會被刪除
1
2
3
4
5
#kubetctl delete pod static-web-node1
pod "static-web-node1"deleted
#kubectl get pods
NAME READY STATUS RESTARTS AGE
static-web-node1 0/1Pending 0 1s

  

  要刪除該pod的操作只能在其所在的Node上操作,將其定義的.yaml檔案從/etc/kubelet.d/目錄下刪除
1
2
#rm -f /etc/kubelet.d/static-web.yaml
#docker ps

  

4、Pod容器共享Volume
  Volume型別包括:emtyDir、hostPath、gcePersistentDisk、awsElasticBlockStore、gitRepo、secret、nfs、scsi、glusterfs、persistentVolumeClaim、rbd、flexVolume、cinder、cephfs、flocker、downwardAPI、fc、azureFile、configMap、vsphereVolume等等,可以定義多個Volume,每個Volume的name保持唯一。在同一個pod中的多個容器能夠共享pod級別的儲存卷Volume。Volume可以定義為各種型別,多個容器各自進行掛載操作,講一個Volume掛載為容器內需要的目錄。
如下圖:

 

  如上圖中的Pod中包含兩個容器:tomcat和busybox,在pod級別設定Volume “app-logs”,用於tomcat想其中寫日誌檔案,busybox讀日誌檔案。
配置檔案如下:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
apiVersion:v1
kind: Pod
metadata:
  name: redis-php
  label:
    name: volume-pod
spec:
  containers:
  - name: tomcat
    image: tomcat
    ports:
    - containersPort: 8080
    volumeMounts:
    - name: app-logs
      mountPath:/usr/local/tomcat/logs
  - name: busybox
    image:busybox
    command: ["sh","-C","tail -f /logs/catalina*.log"]
  volumes:
  - name: app-logs
    emptyDir:{}
busybox容器可以通過kubectl logs檢視輸出內容
1
#kubectl logs volume-pod -c busybox 
tomcat容器生成的日誌檔案可以登入容器檢視
1
#kubectl exec -ti volume-pod -c tomcat -- ls /usr/local/tomcat/logs
5.Pod的配置管理
  應用部署的一個最佳實踐是將應用所需的配置資訊於程式進行分離,這樣可以使得應用程式被更好的複用,通過不用配置檔案也能實現更靈活的功能。將應用打包為容器映象後,可以通過環境變數或外掛檔案的方式在建立容器時進行配置注入。ConfigMap是Kubernetes v1.2版本開始提供的一種統一叢集配置管理方案。
  5.1 ConfigMap:容器應用的配置管理
  容器使用ConfigMap的典型用法如下:
  (1)生產為容器的環境變數。
  (2)設定容器啟動命令的啟動引數(需設定為環境變數)。
  (3)以Volume的形式掛載為容器內部的檔案或目錄。
  ConfigMap以一個或多個key:value的形式儲存在Kubernetes系統中共應用使用,既可以用於表示一個變數的值,也可以表示一個完整的配置檔案內容。
通過yuaml配置檔案或者直接使用kubelet create configmap 命令的方式來建立ConfigMap
  5.2 ConfigMap的建立
   舉個小例子cm-appvars.yaml來描述將幾個應用所需的變數定義為ConfigMap的用法:
 
1
2
3
4
5
6
7
8
# vim cm-appvars.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: cm-appvars
data:
  apploglevel: info
  appdatadir:/var/data

 

  執行kubectl create命令建立該ConfigMap
1
2
#kubectl create -f cm-appvars.yaml
configmap "cm-appvars.yaml"created
  檢視建立好的ConfigMap:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
#kubectl get configmap
NAME DATA AGE
cm-appvars 2 3s
[root@kubernetes-master ~]# kubectl describe configmap cm-appvars
Name: cm-appvars
Namespace: default
Labels: <none>
Annotations: <none>
  
Data
====
appdatadir: 9 bytes
apploglevel: 4 bytes
[root@kubernetes-master ~]# kubectl get configmap cm-appvars -o yaml
apiVersion: v1
data:
appdatadir: /var/data
apploglevel: info
kind: ConfigMap
metadata:
creationTimestamp: 2017-04-14T06:03:36Z
name: cm-appvars
namespace: default
resourceVersion:"571221"
selfLink: /api/v1/namespaces/default/configmaps/cm-appvars
uid: 190323cb-20d8-11e7-94ec-000c29ac8d83 
 
  另:建立一個cm-appconfigfile.yaml描述將兩個配置檔案server.xml和logging.properties定義為configmap的用法,設定key為配置檔案的別名,value則是配置檔案的文字內容:
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
apiVersion: v1
kind: ConfigMap
metadata:
  name: cm-appvars
data:
  key-serverxml:
    <?xml Version='1.0'encoding='utf-8'?>
    <Server port="8005"shutdown="SHUTDOWN">
    .....
      </service>
    </Server>
  key-loggingproperties:
    "handlers=lcatalina.org.apache.juli.FileHandler,
    ...."
  在pod "cm-test-app"定義中,將configmap "cm-appconfigfile"中的內容以檔案形式mount到容器內部configfiles目錄中。
Pod配置檔案cm-test-app.yaml內容如下:
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
#vim cm-test-app.yaml
apiVersion: v1
kind: Pod
metadata:
  name: cm-test-app
spec:
  containers:
  - name: cm-test-app
    image: tomcat-app:v1
    ports:
    - containerPort: 8080
    volumeMounts:
    - name: serverxml                          #引用volume名
      mountPath:/configfiles                       #掛載到容器內部目錄
        configMap:
          name: cm-test-appconfigfile                  #使用configmap定義的的cm-appconfigfile
          items:
          - key: key-serverxml                     #將key=key-serverxml
            path: server.xml                           #value將server.xml檔名進行掛載
          - key: key-loggingproperties                 #將key=key-loggingproperties    
            path: logging.properties                   #value將logging.properties檔名進行掛載 
  建立該Pod:
1
2
#kubectl create -f cm-test-app.yaml
Pod "cm-test-app"created  
  登入容器檢視configfiles目錄下的server.xml和logging.properties檔案,他們的內容就是configmap “cm-appconfigfile”中定義的兩個key的內容
1
2
3
#kubectl exec -ti cm-test-app -- bash
root@cm-rest-app:/# cat /configfiles/server.xml
root@cm-rest-app:/# cat /configfiles/logging.properties

 

  5.3使用ConfigMap的條件限制
  使用configmap的限制條件如下:
    • configmap必須在pod之間建立
    • configmap也可以定義為屬於某個Namespace,只有處於相同namespaces中的pod可以引用
    • configmap中配額管理還未能實現
    • kubelet只支援被api server管理的pod使用configmap,靜態pod無法引用
    • 在pod對configmap進行掛載操作時,容器內部職能掛載為目錄,無法掛載檔案。
6.Pod生命週期和重啟策略
  Pod在整個生命週期過程中被定義為各種狀態,熟悉Pod的各種狀態有助於理解如何設定Pod的排程策略、重啟策略
  Pod的狀態包含以下幾種,如圖:
  
  Pod的重啟策略(RestartPolicy)應用於Pod內所有的容器,並且僅在Pod所處的Node上由kubelet進行判斷和重啟操作。當某哥容器異常退出或者健康檢查石柏師,kubelet將根據RestartPolicy的設定進行相應的操作
  Pod的重啟策略包括Always、OnFailure及Nerver,預設值為Always。
  kubelet重啟失效容器的時間間隔以sync-frequency乘以2n來計算,例如1、2、4、8倍等,最長延時5分鐘,並且成功重啟後的10分鐘後重置該事件。
  Pod的重啟策略和控制方式息息相關,當前可用於管理Pod的控制器寶庫ReplicationController、Job、DaemonSet及直接通過kubelet管理(靜態Pod),每種控制器對Pod的重啟策略要求如下:
    • RC和DaemonSet:必須設定為Always,需要保證該容器持續執行
    • Job:OnFailure或Nerver,確保容器執行完成後不再重啟
    • kubelet:在Pod失效時重啟他,不論RestartPolicy設定什麼值,並且也不會對Pod進行健康檢查
 
7、Pod健康檢查
  對Pod的健康檢查可以通過兩類探針來檢查:LivenessProbe和ReadinessProbe
    • LivenessProbe探針:用於判斷容器是否存活(running狀態),如果LivenessProbe探針探測到容器不健康,則kubelet殺掉該容器,並根據容器的重啟策略做響應處理
    • ReadinessProbe探針:用於判斷容器是否啟動完成(ready狀態),可以接受請求。如果ReadinessProbe探針探測失敗,則Pod的狀態被修改。Endpoint Controller將從service的Endpoint中刪除包含該容器所在的Pod的Endpoint。
  kubelet定製執行LivenessProbe探針來診斷容器的健康狀況。LivenessProbe有三種事項方式。
 
(1)ExecAction:在容器內部執行一個命令,如果該命令的返回值為0,則表示容器健康
例:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
apiVersion:v1
kind: Pod
metadata:
  name: liveness-exec
  label:
    name: liveness
spec:
  containers:
  - name: tomcat
    image: grc.io/google_containers/tomcat
    args:
    -/bin/sh
    - -c
    -echo ok >/tmp.health;sleep10; rm -fr /tmp/health;sleep600
    livenessProbe:
      exec:
        command:
        -cat
        -/tmp/health
      initianDelaySeconds:15
      timeoutSeconds:1 
(2)TCPSocketAction:通過容器ip地址和埠號執行TCP檢查,如果能夠建立tcp連線表明容器健康
例:
1
2
3
4
5
6
7
8
9
10
11
12
kind: Pod
metadata:
  name: pod-with-healthcheck
spec:
  containers:
  - name: nginx
    image: nginx
    livenessProbe:
      tcpSocket:
        port: 80
      initianDelaySeconds:30
      timeoutSeconds:1
(3)HTTPGetAction:通過容器Ip地址、埠號及路徑呼叫http get方法,如果響應的狀態嗎大於200且小於400,則認為容器健康
例:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
apiVersion:v1
kind: Pod
metadata:
  name: pod-with-healthcheck
spec:
  containers:
  - name: nginx
    image: nginx
    livenessProbe:
      httpGet:
        path:/_status/healthz
        port: 80
      initianDelaySeconds:30
      timeoutSeconds:1

  

對於每種探針方式,都需要設定initialDelaySeconds和timeoutSeconds兩個引數,它們含義如下:
  • initialDelaySeconds:啟動容器後首次監控檢查的等待時間,單位秒
  • timeouSeconds:健康檢查傳送請求後等待響應的超時時間,單位秒。當發生超時就被認為容器無法提供服務無,該容器將被重啟
 
8.玩轉Pod排程
  在Kubernetes系統中,Pod在大部分場景下都只是容器的載體而已,通常需要通過RC、Deployment、DaemonSet、Job等物件來完成Pod的排程和自動控制功能。
  8.1 RC、Deployment:全自動排程
  RC的主要功能之一就是自動部署容器應用的多份副本,以及持續監控副本的數量,在叢集內始終維護使用者指定的副本數量。
在排程策略上,除了使用系統內建的排程演算法選擇合適的Node進行排程,也可以在Pod的定義中使用NodeSelector或NodeAffinity來指定滿足條件的Node進行排程。
  1)NodeSelector:定向排程
  Kubernetes Master上的scheduler服務(kube-Scheduler程式)負責實現Pod的排程,整個過程通過一系列複雜的演算法,最終為每個Pod計算出一個最佳的目標節點,通常我們無法知道Pod最終會被排程到哪個節點上。實際情況中,我們需要將Pod排程到我們指定的節點上,可以通過Node的標籤和pod的nodeSelector屬性相匹配來達到目的。
  (1)首先通過kubectl label命令給目標Node打上標籤
kubectl label nodes <node-name> <label-key>=<label-value>
例:
1
#kubectllabel nodes k8s-node-1 zonenorth
  (2)然後在Pod定義中加上nodeSelector的設定
例:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
apiVersion:v1
kind: Pod
metadata:
  name: redis-master
  label:
    name: redis-master
spec:
  replicas: 1
  selector:
    name: redis-master
    template:
      metadata:
        labels:
          name: redis-master
      spec:
        containers:
        - name: redis-master
          images: kubeguide/redis-master
          ports:
          - containerPort: 6379
        nodeSelector:
          zone: north 
執行kubectl create -f命令建立Pod,scheduler就會將該Pod排程到擁有zone=north標籤的Node上。 如果多個Node擁有該標籤,則會根據排程演算法在該組Node上選一個可用的進行Pod排程。
需要注意的是:如果叢集中沒有擁有該標籤的Node,則這個Pod也無法被成功排程。
 
  2)NodeAffinity:親和性排程
該排程策略是將來替換NodeSelector的新一代排程策略。由於NodeSelector通過Node的Label進行精確匹配,所有NodeAffinity增加了In、NotIn、Exists、DoesNotexist、Gt、Lt等操作符來選擇Node。排程側露更加靈活。
 
  8.2 DaemonSet:特定場景排程
DaemonSet用於管理叢集中每個Node上僅執行一份Pod的副本例項,如圖

 

這種用法適合一些有下列需求的應用:
  • 在每個Node上執行個以GlusterFS儲存或者ceph儲存的daemon程式
  • 在每個Node上執行一個日誌採集程式,例如fluentd或者logstach
  • 在每個Node上執行一個健康程式,採集Node的效能資料。
DaemonSet的Pod排程策略類似於RC,除了使用系統內建的演算法在每臺Node上進行排程,也可以在Pod的定義中使用NodeSelector或NodeAffinity來指定滿足條件的Node範圍來進行排程。
 
  8.3 批處理排程
 
9.Pod的擴容和縮榮
  在實際生產環境中,我們經常遇到某個服務需要擴容的場景,也有可能因為資源精確需要縮減資源而需要減少服務例項數量,此時我們可以Kubernetes中RC提供scale機制來完成這些工作。
以redis-slave RC為例,已定義的最初副本數量為2,通過kubectl scale命令可以將Pod副本數量重新調整
1
2
3
4
5
6
7
#kubectl scale rc redis-slave --replicas=3
ReplicationController"redis-slave" scaled
#kubectl get pods
NAME READY STATUS RESTARTS AGE
redis-slave-1sf23 1/1Running 0 1h
redis-slave-54wfk 1/1Running 0 1h
redis-slave-3da5y 1/1Running 0 1h 
  除了可以手工通過kubectl scale命令完成Pod的擴容和縮容操作以外,新版本新增加了Horizontal Podautoscaler(HPA)的控制器,用於實現基於CPU使用路進行啟動Pod擴容縮容的功能。該控制器基於Mastger的kube-controller-manager服務啟動引數 --horizontal-pod-autoscler-sync-period定義的時長(預設30秒),週期性監控目標Pod的Cpu使用率並在滿足條件時對ReplicationController或Deployment中的Pod副本數量進行調整,以符合使用者定義的平均Pod Cpu使用率,Pod Cpu使用率來源於heapster元件,所以需預先安裝好heapster。
 
10.Pod的滾動升級
  當叢集中的某個服務需要升級時,我們需要停止目前與該服務相關的所有Pod,然後重新拉取映象並啟動。如果叢集規模較大,因服務全部停止後升級的方式將導致長時間的服務不可用。由此,Kubernetes提供了rolling-update(滾動升級)功能來解決該問題。
滾動升級通過執行kubectl rolling-update命令一鍵完成,該命令建立一個新的RC,然後自動控制舊版本的Pod數量逐漸減少到0,同時新的RC中的Pod副本數量從0逐步增加到目標值,最終實現Pod的升級。需要注意的是,系統要求新的RC需要與舊的RC在相同的Namespace內,即不能把別人的資產轉到到自家名下。
  例:將redis-master從1.0版本升級到2.0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
apiVersion: v1
kind: replicationController
metadata:
  name: redis-master-v2
  labels:
    name: redis-master
    Version: v2
spec:
  replicas: 1
  selector:
    name: redis-master
    Version: v2
  template:
    labels:
      name: redis-master
      Version: v2
    spec:
      containers:
      - name: master
        images: kubeguide/redis-master:2.0
        ports:
        - containerPort: 6379

  需要注意的點:

  (1)RC的name不能與舊的RC名字相同
  (2)在sele中應至少有一個label與舊的RC的label不同,以標識為新的RC。本例中新增了一個名為version的label與舊的RC區分
  執行kubectl rolling-update來完成Pod的滾動升級:
1
#kubectl rolling-update redis-master -f redis-master-controller-v2.yaml 
  另一種方法就是不使用配置檔案,直接用kubectl rolling-update加上--image引數指定新版映象名來完成Pod的滾動升級
1
#kubectl rolling-update redis-master --image=redis-master:2.0
  與使用配置檔案的方式不同的是,執行的結果是舊的RC被刪除,新的RC仍然使用就的RC的名字。
  如果在更新過程總髮現配置有誤,則使用者可以中斷更新操作,並通過執行kubectl rolling-update-rollback完成Pod版本的回滾。


原文地址:https://blog.csdn.net/real_myth/article/details/78719244

 


相關文章