Kubernetes概念及使用

時間 2019-11-17

標籤 kubernetes 概念使用简体版

原文原文鏈接

1、Kubernetes系列之介紹篇

(k8s配置Ingress-nginx做爲服務發現)php

(服務網格lstio)html

(日誌和監控Helm+PrometheusGrafna看板)前端

(服務調度與編排Scheduler玩轉pod調度)node

(共享存儲PV/PVC/StorageClass)mysql

(Harbor Docker鏡像倉庫)linux

(k8s重點對象概念：Namespace、Resources、Label)nginx

轉自：https://blog.csdn.net/Real_Myth/article/details/78719244

•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上須要運行容器服務

2、基於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)

1、關閉系統運行的防火牆及selinux

1。若是系統開啓了防火牆則按以下步驟關閉防火牆（全部機器）

# systemctl stop firewalld # systemctl disable firewalld

2.關閉selinux

 
                #setenforce 0 
               
                #sed -i '/^SELINUX=/cSELINUX=disabled' /etc/sysconfig/selinux

2、MASTER安裝配置

1. 安裝並配置Kubernetes master(yum 方式)

 
                # yum -y install etcd kubernetes

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

 
                #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"

　　配置kubernetesweb

 
                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服務

 
                # for SERVICES in etcd kube-apiserver kube-controller-manager kube-scheduler; do systemctl restart $SERVICES systemctl enable $SERVICES systemctl status $SERVICES done

3.設置etcd網絡redis

 
                #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還都沒有開始安裝配置，因此運行以後結果爲空

 
                # kubectl get nodes NAME LABELS STATUS

3、MINION安裝配置(每臺minion機器都按以下安裝配置)

1. 環境安裝和配置

 
                # yum -y install flannel kubernetes

　　配置kubernetes鏈接的服務端IP

 
                #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）

 
                #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）

 
                # 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網絡

 
                #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. 啓動服務

 
                # for SERVICES in flanneld kube-proxy kubelet docker; do systemctl restart $SERVICES systemctl enable $SERVICES systemctl status $SERVICES done

4、配置完成驗證安裝

肯定兩臺minion(10.0.0.82和10.0.0.83)和一臺master（10.0.0.81）都已經成功的安裝配置而且服務都已經啓動了。

切換到master機器上，運行命令kubectl get nodes

 
                # kubectl get nodes 
               
                NAME STATUS AGE 
               
                10.0.0.82 Ready 1m 
               
                10.0.0.83 Ready 1m

　　能夠看到配置的兩臺minion已經在master的node列表中了。若是想要更多的node，只須要按照minion的配置，配置更多的機器就能夠了。

3、Kubernetes之深刻了解Pod

一、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

二、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以下：

 
              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信息能夠看到以下圖：

 
              #kubectl get gods 
             
              NAME READY STATUS RESTATS AGE 
             
              redis-php 2 
              /2 
              Running 0 10m

　　能夠看到READY信息爲2/2，表示Pod中的兩個容器都成功運行了.

　　查看pod的詳細信息，能夠看到兩個容器的定義和建立過程。

 
              [root@kubernetes-master ~] 
              # kubectl describe redis-php 
             
              the server doesn't have a resource 
              type  
              "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

三、靜態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狀態，也不會被刪除

 
              #kubetctl delete pod static-web-node1 
             
              pod  
              "static-web-node1" 
              deleted 
             
              #kubectl get pods 
             
              NAME READY STATUS RESTARTS AGE 
             
              static-web-node1 0 
              /1 
              Pending 0 1s

　　要刪除該pod的操做只能在其所在的Node上操做，將其定義的.yaml文件從/etc/kubelet.d/目錄下刪除

 
              #rm -f /etc/kubelet.d/static-web.yaml 
             
              #docker ps

四、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讀日誌文件。

配置文件以下：

 
              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查看輸出內容

 
              #kubectl logs volume-pod -c busybox

tomcat容器生成的日誌文件能夠登陸容器查看

 
              #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的用法：

 
              # vim cm-appvars.yaml 
             
              apiVersion: v1 
             
              kind: ConfigMap 
             
              metadata: 
             
              name: cm-appvars 
             
              data: 
             
              apploglevel: info 
             
              appdatadir: 
              /var/data

　　執行kubectl create命令建立該ConfigMap

 
               #kubectl create -f cm-appvars.yaml 
              
               configmap  
               "cm-appvars.yaml" 
               created

　　查看創建好的ConfigMap：

 
               #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則是配置文件的文本內容：

 
                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內容以下：

 
                #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：

 
                 #kubectl create -f cm-test-app.yaml 
                
                 Pod  
                 "cm-test-app" 
                 created

　　登陸容器查看configfiles目錄下的server.xml和logging.properties文件，他們的內容就是configmap 「cm-appconfigfile」中定義的兩個key的內容

 
                 #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來計算，例如一、二、四、8倍等，最長延時5分鐘，而且成功重啓後的10分鐘後重置該事件。

　　Pod的重啓策略和控制方式息息相關，當前可用於管理Pod的控制器寶庫ReplicationController、Job、DaemonSet及直接經過kubelet管理（靜態Pod），每種控制器對Pod的重啓策略要求以下：

- RC和DaemonSet：必須設置爲Always，須要保證該容器持續運行
- Job：OnFailure或Nerver，確保容器執行完成後再也不重啓
- kubelet：在Pod失效時重啓他，不論RestartPolicy設置什麼值，而且也不會對Pod進行健康檢查

七、Pod健康檢查

　　對Pod的健康檢查能夠經過兩類探針來檢查：LivenessProbe和ReadinessProbe

- LivenessProbe探針：用於判斷容器是否存活（running狀態），若是LivenessProbe探針探測到容器不健康，則kubelet殺掉該容器，並根據容器的重啓策略作響應處理
- ReadinessProbe探針：用於判斷容器是否啓動完成（ready狀態），能夠接受請求。若是ReadinessProbe探針探測失敗，則Pod的狀態被修改。Endpoint Controller將從service的Endpoint中刪除包含該容器所在的Pod的Endpoint。

　　kubelet定製執行LivenessProbe探針來診斷容器的健康情況。LivenessProbe有三種事項方式。

（1）ExecAction：在容器內部執行一個命令，若是該命令的返回值爲0，則表示容器健康

例：

 
              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; 
              sleep 
              10;  
              rm  
              -fr  
              /tmp/health 
              ; 
              sleep 
              600 
             
              livenessProbe: 
             
              exec 
              : 
             
              command 
              : 
             
              - 
              cat 
             
              - 
              /tmp/health 
             
              initianDelaySeconds:15 
             
              timeoutSeconds:1

（2）TCPSocketAction：經過容器ip地址和端口號執行TCP檢查，若是可以創建tcp鏈接代表容器健康

例：

 
              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，則認爲容器健康

例：

 
              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>

例：

 
              #kubectllabel nodes k8s-node-1 zonenorth

　　（2）而後在Pod定義中加上nodeSelector的設置

例：

 
              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副本數量從新調整

 
              #kubectl scale rc redis-slave --replicas=3 
             
              ReplicationController 
              "redis-slave"  
              scaled 
             
              #kubectl get pods 
             
              NAME READY STATUS RESTARTS AGE 
             
              redis-slave-1sf23 1 
              /1 
              Running 0 1h 
             
              redis-slave-54wfk 1 
              /1 
              Running 0 1h 
             
              redis-slave-3da5y 1 
              /1 
              Running 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

 
               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的滾動升級：

 
               #kubectl rolling-update redis-master -f redis-master-controller-v2.yaml

　　另外一種方法就是不使用配置文件，直接用kubectl rolling-update加上--image參數指定新版鏡像名來完成Pod的滾動升級

 
               #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

序言
沒等到風來，綿綿小雨，因此寫個隨筆，聊聊k8s的基本概念。

k8s是一個編排容器的工具，其實也是管理應用的全生命週期的一個工具，從建立應用，應用的部署，應用提供服務，擴容縮容應用，應用更新，都很是的方便，並且能夠作到故障自愈，例如一個服務器掛了，能夠自動將這個服務器上的服務調度到另一個主機上進行運行，無需進行人工干涉。那麼，問題來了，要運維何用？

k8s能夠更快的更新新版本，打包應用，更新的時候能夠作到不用中斷服務，服務器故障不用停機，從開發環境到測試環境到生產環境的遷移極其方便，一個配置文件搞定，一次生成image，處處運行。。。

k8s的全生命週期管理
在k8s進行管理應用的時候，基本步驟是：建立集羣，部署應用，發佈應用，擴展應用，更新應用。

一、建立集羣：爲何要使用集羣？

有一句古話叫作三個臭皮匠，勝過諸葛亮，這就是建立集羣的緣由。。。

使用集羣，create cluster是爲了掩蓋底層的無能，在各類環境中，底層的硬件各不相同，有的是各類低廉的服務器，有的各類雲環境，有的是各類vm，有的各類host machine，要想屏蔽底層的細節，加強可靠性和穩定性，從而須要建立集羣。

建立集羣的好處就是，統一對外提供接口，無須進行各類複雜的調用；提供更好的可靠性，服務器宕機那麼頻繁，物理磁盤那麼容易損壞，無須擔憂，集羣統一進行調配；提供更好的性能，組合集羣中各個機器的計算存儲網絡資源，提供更好的TPS和PS；提供橫向擴容的能力，在進行橫向擴容的時候，性能基本上能呈線性增加。

集羣看起來很牛，那麼建立起來很複雜麼？並不會，在k8s只要使用兩條指令就能夠建立一個集羣，一個是kubectl init進行初始化，建立一個master節點，第二條指令就是kubectl join xxx建立一個node節點，加入這個集羣。

在這邊能夠看到k8s在物理上進行劃分的時候，劃分了兩種類型的主機，一個master節點，主要用來調度，控制集羣的資源等功能；而node節點，主要是用來運行容器的節點，也就是運行服務的節點。

其實集羣都差很少，master用來控制，用來存儲各類元數據，node節點是一個工做節點，真正來幹活的；node節點定時與master進行通訊，經過kubelet進程來彙報信息。

建立了集羣，我要怎麼看信息？以下：

二、部署應用

使用集羣的主要目標是啥？用來提供服務，讓開發開發的應用程序能在集羣上運行，從而須要讓開發能運行一個應用來進行測試。

一條指令就能運行一個服務，有了image以後就是這麼簡單。因此，在開發完成程序以後，須要將程序打包成image，而後放到registry中，而後就可以運行應用了。

在部署完成應用以後，就能夠看到應用的名稱，指望狀態是運行一個pod，當前有一個pod，活動的也是一個，還有啓動的時間，那麼什麼是pod呢？

在k8s裏面，集羣調度的最小單元就是一個pod，一個pod能夠是一個容器，也能夠是多個容器，例如你運行一個程序，其中使用了nginx，使用mysql了，使用了jetty，那麼能夠將這三個使用在同一個pod中，對他們提供統一的調配能力，一個pod只能運行在一個主機上，而一個主機上能夠有多個pod。

那麼有人會問，爲何要使用pod，爲何不能直接使用容器呢？使用pod，至關與一個邏輯主機，還記得建立一個vm，在vm上運行幾個進程麼，其實道理是同樣的，pod的存在主要是讓幾個緊密鏈接的幾個容器之間共享資源，例如ip地址，共享存儲等信息。若是直接調度容器的話，那麼幾個容器可能運行在不一樣的主機上，這樣就增長了系統的複雜性。

三、發佈應用

發佈應用主要就是對外提供服務，可能會有人提出疑問，我都運行了服務，爲何還不能提供服務，這是由於在集羣當中，建立的ip地址等資源，只有在同一個集羣中才能訪問，每一個pod也有獨一的ip地址，當有多個pod提供相同的服務的時候，就須要有負載均衡的能力，從而這裏就涉及到一個概念就是service，專門用來提供服務的。

服務主要是用來提供外界訪問的接口，服務能夠關聯一組pod，這些pod的ip地址各不相同，而service至關於一個複雜均衡的vip，用來指向各個pod，當pod的ip地址發生改變以後，也能作到自動進行負載均衡，在關聯的時候，service和pod之間主要經過label來關聯，也就是標籤（-l表示爲label）。

從而外界就能夠訪問此應用了，以下：

四、擴容縮容

在業務上線以後，碰到了雙十一怎麼辦？擴容。。。萬劍歸宗，只要有一個pod，那麼就能夠產生無數個pod。。。。

過了雙十一怎麼辦，縮容。。。

橫向擴展的能力。。每次擴容縮容的時候，這種會不會以爲很方便，一句話的事兒。。不用建立vm，不用去部署中間件，不用去各類修改配置，這就是自動化。。。

五、更新

有新版本了，我要發佈。。。那麼。。。

滾動更新。。。根據新的image建立一個pod，分配各類資源，而後自動負載均衡，刪除老的pod，而後繼續更新。。。。不會中斷服務。。。

更新錯了怎麼辦，不慫，不會影響生產業務，回滾就行了。。。幾秒鐘的事兒。。。

後話
k8s的基本入門，其實算是一種用戶視角，只是用來演示如何使用k8s，怎麼提升了生產力而已。

在給客戶演示的時候，爲啥要選擇k8s？主要就是如何提升了發佈的效率，更新版本的效率，更方便更快捷的上線新版本。

可是在運維關注的視角下，這些遠遠不夠。。。master？存儲了哪些元數據，存儲在etcd中？如何來進行監控？在不少不少系統狀況下，怎麼來部署k8s，是一個項目一個k8s仍是一個k8s多個項目？等等一系列的問題。。。

原文：https://blog.csdn.net/TM6zNf87MDG7Bo/article/details/79621510

Kubernetes解決的問題：
1. 調度 - 容器應該在哪一個機器上運行
2. 生命週期和健康情況 - 容器在無錯的條件下運行
3. 服務發現 - 容器在哪，怎樣與它通訊
4. 監控 - 容器是否運行正常
5. 認證 - 誰能訪問容器
6. 容器聚合 - 如何將多個容器合併成一個工程

Kubernetes組件組成：
1. kubectl
客戶端命令行工具，將接受的命令格式化後發送給kube-apiserver，做爲整個系統的操做入口。
2. kube-apiserver
做爲整個系統的控制入口，以REST API服務提供接口。
3. kube-controller-manager
用來執行整個系統中的後臺任務，包括節點狀態情況、Pod個數、Pods和Service的關聯等。
4. kube-scheduler
負責節點資源管理，接受來自kube-apiserver建立Pods任務，並分配到某個節點。
5. etcd
負責節點間的服務發現和配置共享。
6. kube-proxy
運行在每一個計算節點上，負責Pod網絡代理。定時從etcd獲取到service信息來作相應的策略。
7. kubelet
運行在每一個計算節點上，做爲agent，接受分配該節點的Pods任務及管理容器，週期性獲取容器狀態，反饋給kube-apiserver。
8. DNS
一個可選的DNS服務，用於爲每一個Service對象建立DNS記錄，這樣全部的Pod就能夠經過DNS訪問服務了。
---------------------

--------------------------------------------------------------------------------------------------

相關標籤/搜索

每日一句

每一个你不满意的现在，都有一个你没有努力的曾经。