第六章 資源清單

簡介：在k8s中，通常使用yaml格式的文件來建立符合咱們預期指望的pod，這樣的yaml文件咱們通常稱爲資源清單

 

1、k8s中存在那些資源

 

名稱空間級別

 

①　工做負載型資源(workload)：Pod、ReplicaSet、Deployment、StatefulSet、DaemonSet、Job、CronJob(ReplicationController在v1.11版本被廢棄

 

②　服務發現及負載均衡型資源(ServiceDiscoveryLoadBalance):Service、Ingress、...

 

③　配置與存儲型資源：Volume(存儲卷)、CSI(容器存儲接口,能夠擴展各類各樣的第三方存儲卷)

 

④　特殊類型的存儲卷：ConfigMap(當配置中心來使用的資源類型)、Secret(保存敏感數據)、DownwardAPI(把外部環境中的信息輸出給容器)

 

集羣級資源

 

Namespace、Node、Role、ClusterRole、RoleBinding、ClusterRoleBinding

 

元數據型資源

 

HPA、PodTemplate（pod模板）、LimitRange（資源限制）

 

2、經常使用字段解釋

一、必須存在的屬性（必須寫）

 二、主要對象（有的可不寫，有默認值）

 

 

 

三、額外的參數項

 

4、字段配置格式

apiVersion <string> #表示字符串類型

metadata <Object> #表示須要嵌套多層字段

labels <map[string]string> #表示由k:v組成的映射

finalizers <[]string> #表示字串列表

ownerReferences <[]Object> #表示對象列表

hostPID <boolean> #布爾類型

priority <integer> #整型

name <string> -required- #若是類型後面接 -required-，表示爲必填字段

 

kubectl get pod xx.xx.xx -o yaml

<!--使用 -o 參數加 yaml，能夠將資源的配置以 yaml的格式輸出出來，也可使用json，輸出爲json格式-->

3、資源清單格式

一、註釋

apiVersion: group/apiversion # 若是沒有給定 group 名稱，那麼默認爲 core，可使用 kubectl
 api-versions # 獲取當前 k8s 版本上全部的 apiVersion 版本信息( 每一個版本可能不一樣 )
kind:       #資源類別
metadata： #資源元數據 
name 
namespace 
lables 
annotations # 主要目的是方便用戶閱讀查找
spec:  # 指望的狀態（disired state）
status： # 當前狀態，本字段有 Kubernetes 自身維護，用戶不能去定義

二、新建一個pod.舉例

vim  pod.yaml

例子：
apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
  labels:
    app: myapp
    version: v1
spec:
  containers:
  - name: app
    image: hub.lqz.com/library/nginx:latest

3、pod的基本用法

1、pod類型

u 自主式Pod：Pod退出了，此類型的pod不會被建立（可理解爲此pod沒有管理者，他的死亡不會被拉起）

u 控制器管理的Pod：在控制器的生命週期裏，始終要維持Pod的副本數目（通常爲此類型）

2、pod控制器類型

①　ReplicationController & ReplicaSet & Deployment

>HPA（HorizontalPodAutoScale）

②　StatefullSet

③　DaemonSet

④　Job，Cronjob

• ReplicationController 用來確保容器應用的副本數始終保持在用戶定義的副本數，即若是有容器異常退出，會自動建立新的Pod 來替代；而若是異常多出來的容器也會自動回收。在新版本的Kubernetes 中建議使用ReplicaSet 來取代ReplicationControlle
• ReplicaSet 跟ReplicationController 沒有本質的不一樣，只是名字不同，而且ReplicaSet 支持集合式的selector
• 雖然ReplicaSet 能夠獨立使用，但通常仍是建議使用Deployment 來自動管理ReplicaSet ，這樣就無需擔憂跟其餘機制的不兼容問題（好比ReplicaSet 不支持rolling-update 但Deployment 支持）
• Deployment 爲Pod 和ReplicaSet 提供了一個聲明式定義(declarative) 方法，用來替代之前的ReplicationController 來方便的管理應用。典型的應用場景包括：

1. *定義Deployment 來建立Pod 和ReplicaSet
2. *滾動升級和回滾應用
3. *擴容和縮容
4. *暫停和繼續Deployment

Horizontal Pod Autoscaling 僅適用於Deployment 和ReplicaSet ，在V1 版本中僅支持根據Pod 的CPU 利用率擴所容，在v1alpha 版本中，支持根據內存和用戶自定義的metric 擴縮容

 

StatefulSet是爲了解決有狀態服務的問題（對應Deployments 和ReplicaSets是爲無狀態服務而設計），其應用場景包括：

1. 穩定的持久化存儲，即Pod 從新調度後仍是能訪問到相同的持久化數據，基於PVC 來實現
2. 穩定的網絡標誌，即Pod 從新調度後其PodName和HostName不變，基於Headless Service （即沒有Cluster IP 的Service ）來實現
3. 有序部署，有序擴展，即Pod 是有順序的，在部署或者擴展的時候要依據定義的順序依次依次進行（即從0 到N-1，在下一個Pod 運行以前全部以前的Pod 必須都是Running 和Ready 狀態），基於init containers 來實現
4. 有序收縮，有序刪除（即從N-1 到0）

 

DaemonSet 確保所有（或者一些）Node 上運行一個Pod 的副本。當有Node 加入集羣時，也會爲他們新增一個Pod 。當有Node 從集羣移除時，這些Pod 也會被回收。刪除DaemonSet 將會刪除它建立的全部Pod使用DaemonSet 的一些典型用法：

1. 運行集羣存儲daemon，例如在每一個Node 上運行glusterd、ceph。
2. 在每一個Node 上運行日誌收集daemon，例如fluentd、logstash。
3. 在每一個Node 上運行監控daemon，例如Prometheus Node Exporter

 

Job 負責批處理任務，即僅執行一次的任務，它保證批處理任務的一個或多個Pod 成功結束Cron Job管理基於時間的Job，即：

• 在給定時間點只運行一次
• 週期性地在給定時間點運行

 4、網絡通信方式

1、網絡通信模式

Kubernetes 的網絡模型假定了全部Pod 都在一個能夠直接連通的扁平的網絡空間中，這在GCE（Google Compute Engine）裏面是現成的網絡模型，Kubernetes 假定這個網絡已經存在。而在私有云裏搭建Kubernetes 集羣，就不能假定這個網絡已經存在了。咱們須要本身實現這個網絡假設，將不一樣節點上的Docker 容器之間的互相訪問先打通，而後運行Kubernetes

• 同一個Pod 內的多個容器之間：lo
• 各Pod 之間的通信：Overlay Network
• Pod 與Service 之間的通信：各節點的Iptables 規則

2、網絡解決方案Kubernetes + Flannel -1

Flannel 是CoreOS 團隊針對Kubernetes 設計的一個網絡規劃服務，簡單來講，它的功能是讓集羣中的不一樣節點主機建立的Docker 容器都具備全集羣惟一的虛擬IP地址。並且它還能在這些IP 地址之間創建一個覆蓋網絡（Overlay Network），經過這個覆蓋網絡，將數據包原封不動地傳遞到目標容器內

ETCD 之 Flannel 提供說明：

> 存儲管理Flannel 可分配的IP 地址段資源

> 監控ETCD 中每一個 Pod 的實際地址，並在內存中創建維護 Pod 節點路由表

 

同一個Pod 內部通信：同一個Pod 共享同一個網絡命名空間，共享同一個Linux 協議棧

Pod1 至Pod2

> Pod1 與Pod2 不在同一臺主機，Pod的地址是與docker0在同一個網段的，但docker0網段與宿主機網卡是兩個徹底不一樣的IP網段，而且不一樣Node之間的通訊只能經過宿主機的物理網卡進行。將Pod的IP和所在Node的IP關聯起來，經過這個關聯讓Pod能夠互相訪問

> Pod1 與Pod2 在同一臺機器，由Docker0 網橋直接轉發請求至Pod2，不須要通過Flannel

Pod 至 Service的網絡：目前基於性能考慮，所有爲iptables 維護和轉發

Pod 到外網：Pod 向外網發送請求，查找路由表, 轉發數據包到宿主機的網卡，宿主網卡完成路由選擇後，iptables執行Masquerade，把源IP 更改成宿主網卡的IP，而後向外網服務器發送請求

外網訪問Pod：Service

三、編程方式

命令式編程：它側重於如何實現程序，就像咱們剛接觸編程的時候那樣，咱們須要把程序的實現過程按照邏輯結果一步步寫下來（ReplicaSet:creat）

聲明式編程：它側重於定義想要什麼，而後告訴計算機／引擎，讓他幫你去實現(Deployment:apply)

 

Deployment經過ReplicaSet來管理Pod

四、不一樣狀況下網絡通訊方式

 

 

 

kubectl explain pod：看pod模板有那些
kubectl explain pod.apiVersion:查看具體某一個模板

建立pod：kubectl apply -f pod.yaml
kubectl create -f pod.yaml

查看pod:kubectl get pod
        kubectl get pod -o wide 詳細信息
刪除pod:kubectl delete pod myapp-pod

訪問：curl 10.244.2.8

 

Kubectl describe pod myapp-pod     //查看描述信息

kubectl log myapp-pod -c text        //查看日誌

 

5、pod容器生命週期

1、init容器

1.一、定義

Pod可以具備多個容器，應用運行在容器裏面，可是它也可能有一個或多個先於應用容器啓動的Init容器

Init容器與普通的容器很是像，除了以下兩點：

• Init容器老是運行到成功完成爲止
• 每一個Init容器都必須在下一個Init容器啓動以前成功完成

 

若是Pod的Init容器失敗，Kubernetes會不斷地重啓該Pod，直到Init容器成功爲止。然而，若是Pod對應的restartPolicy爲Never，它不會從新啓動

1.2、init容器的做用

由於Init容器具備與應用程序容器分離的單獨鏡像，因此它們的啓動相關代碼具備以下優點：

①　它們能夠包含並運行實用工具，可是出於安全考慮，是不建議在應用程序容器鏡像中包含這些實用工具的

②　它們能夠包含使用工具和定製化代碼來安裝，可是不能出如今應用程序鏡像中。例如，建立鏡像不必FROM另外一個鏡像，只須要在安裝過程當中使用相似sed、awk、python或dig這樣的工具。

③　應用程序鏡像能夠分離出建立和部署的角色，而沒有必要聯合它們構建一個單獨的鏡像。

④　Init容器使用LinuxNamespace，因此相對應用程序容器來講具備不一樣的文件系統視圖。所以，它們可以具備訪問Secret的權限，而應用程序容器則不能。

⑤　它們必須在應用程序容器啓動以前運行完成，而應用程序容器是並行運行的，因此Init容器可以提供了一種簡單的阻塞或延遲應用容器的啓動的方法，直到知足了一組先決條件。

1.3、特殊說明

①　在Pod啓動過程當中，Init容器會按順序在網絡和數據卷初始化以後啓動。每一個容器必須在下一個容器啓動以前成功退出(網絡和數據卷初始化是在pause)

②　若是因爲運行時或失敗退出，將致使容器啓動失敗，它會根據Pod的restartPolicy指定的策略進行重試。然而，若是Pod的restartPolicy設置爲Always，Init容器失敗時會使用RestartPolicy策略

③　在全部的Init容器沒有成功以前，Pod將不會變成Ready狀態。Init容器的端口將不會在Service中進行彙集。正在初始化中的Pod處於Pending狀態，但應該會將Initializing狀態設置爲true

④　若是Pod重啓，全部Init容器必須從新執行

⑤　#對Init容器spec的修改被限制在容器image字段，修改其餘字段都不會生效。更改Init容器的image字段，等價於重啓該Pod

⑥　Init容器具備應用容器的全部字段。除了readinessProbe（就緒檢測），由於Init容器沒法定義不一樣於完成（completion）的就緒（readiness）以外的其餘狀態。這會在驗證過程當中強制執行

⑦　在Pod中的每一個app和Init容器的名稱必須惟一；與任何其它容器共享同一個名稱，會在驗證時拋出錯誤

2、容器探針

探針是由kubelet對容器執行的按期診斷。要執行診斷，kubelet調用由容器實現的Handler。有三種類型的處理程序：

• ExecAction：在容器內執行指定命令。若是命令退出時返回碼爲0則認爲診斷成功。
• TCPSocketAction：對指定端口上的容器的IP地址進行TCP檢查。若是端口打開，則診斷被認爲是成功的。
• HTTPGetAction：對指定的端口和路徑上的容器的IP地址執行HTTPGet請求。若是響應的狀態碼大於等於200且小於400，則診斷被認爲是成功的

每次探測都將得到如下三種結果之一：

• 成功：容器經過了診斷。
• 失敗：容器未經過診斷。
• 未知：診斷失敗，所以不會採起任何行動

探測方式

①　livenessProbe：指示容器是否正在運行。若是存活探測失敗，則kubelet會殺死容器，而且容器將受到其重啓策略的影響。若是容器不提供存活探針，則默認狀態爲Success（會隨着容器的生命週期一直存在）

②　readinessProbe：指示容器是否準備好服務請求。若是就緒探測失敗，端點控制器將從與Pod匹配的全部Service的端點中刪除該Pod的IP地址。初始延遲以前的就緒狀態默認爲Failure。若是容器不提供就緒探針，則默認狀態爲Success

 三、Pod hook

Podhook（鉤子）是由Kubernetes管理的kubelet發起的，當容器中的進程啓動前或者容器中的進程終止以前運行，這是包含在容器的生命週期之中。能夠同時爲Pod中的全部容器都配置hook

Hook的類型包括兩種：

• exec：執行一段命令
• HTTP：發送HTTP請求

四、重啓策略

PodSpec中有一個restartPolicy字段，可能的值爲Always、OnFailure和Never。默認爲Always。restartPolicy適用於Pod中的全部容器。restartPolicy僅指經過同一節點上的kubelet從新啓動容器。失敗的容器由kubelet以五分鐘爲上限的指數退避延遲（10秒，20秒，40秒...）從新啓動，並在成功執行十分鐘後重置。如Pod文檔中所述，一旦綁定到一個節點，Pod將永遠不會從新綁定到另外一個節點。

五、Podphase

• Pod的status字段是一個PodStatus對象，PodStatus中有一個phase字段。
• Pod的相位（phase）是Pod在其生命週期中的簡單宏觀概述。該階段並非對容器或Pod的綜合彙總，也不是爲了作爲綜合狀態機
• Pod相位的數量和含義是嚴格指定的。除了本文檔中列舉的狀態外，不該該再假定Pod有其餘的phase值

Podphase可能存在的值

①　掛起（Pending）：Pod已被Kubernetes系統接受，但有一個或者多個容器鏡像還沒有建立。等待時間包括調度Pod的時間和經過網絡下載鏡像的時間，這可能須要花點時間

②　運行中（Running）：該Pod已經綁定到了一個節點上，Pod中全部的容器都已被建立。至少有一個容器正在運行，或者正處於啓動或重啓狀態

③　成功（Succeeded）：Pod中的全部容器都被成功終止，而且不會再重啓

④　失敗（Failed）：Pod中的全部容器都已終止了，而且至少有一個容器是由於失敗終止。也就是說，容器以非0狀態退出或者被系統終止

⑤　未知（Unknown）：由於某些緣由沒法取得Pod的狀態，一般是由於與Pod所在主機通訊失敗

1、docker pull busybox
二、vim init-pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
  labels:
    app: myapp
spec:
  containers:
  - name: myapp-container
    image: busybox
    command: ['sh','-c','echo The app is running! && sleep 3600']
  initContainers:
  - name: init-myservice
    image: busybox
    command: ['sh','-c','until nslookup myservice; do echo waiting for myservice; sleep 2;done;']
  - name: init-mydb
    image: busybox
    command: ['sh','-c','until nslookup mydb; do echo waiting for mydb; sleep 2; done;']

3、service能夠簡稱svc
 建立service
kind: Service
apiVersion: v1
metadata:
  name: myservice
spec:
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376

kind: Service
apiVersion: v1
metadata:
  name: mydb
spec: 
ports: 
- protocol: TCP
port: 80 
targetPort: 9377

 

查看pod

kubectl delete deployment --all   刪除全部deployment

kubectl delete pod --all   刪除全部pod

版本最好不用latest;由於如今和之後的最新版本不同

查看具體pod信息

 

 連接：https://www.bilibili.com/video/av66617940/?p=17