kubernetes建立資源的兩種方式

1、建立方式分類：

命令 vs 配置文件

Kubernetes 支持兩種方式建立資源：

1.用 kubectl 命令行的方式直接建立，好比：

kubectl run httpd-app --image=reg.yunwei.edu/learn/httpd:latest --replicas=2

刪除

kubectl delete deployment httpd-app

在命令行中經過參數指定資源的屬性。

2.經過配置文件和 kubectl apply （就是編排文件，咱們能夠把建立這個應用的過程寫到編排文件裏，而後讓文件幫我建立應用）建立，要完成前面一樣的工做，可執行命令：

kubectl apply -f httpd.yml

編排文件以下圖，它通常都是以.yml爲結尾的。

 

httpd.yml 的內容爲：

資源的屬性寫在配置文件中，文件格式爲 YAML。

apiVersion: extensions/v1beta1 #API版本 kind: Deployment #啓動應用的類型 metadata: #對該資源的元數據的描述，就是說針對於Deployment他的元數據是什麼 name: httpd-deployment #元數據裏面最少要有一個name參數 spec: #對這個應用規格的描述 replicas: 2 #副本數（我啓動這個應用他幫我編排幾份） template: #模板（最少包含metadata、labels、name） metadata: #元數據，這是關於規格的元數據 labels: #標籤 name: httpd spec: #這是容器的規格 containers: #容器 - name: httpd-app #容器的名字 image: reg.yunwei.edu/learn/httpd:latest  #容器應用的鏡像

下面對這兩種方式進行比較。

基於命令行的方式：

簡單直觀快捷，上手快。

適合臨時測試或實驗。

基於配置文件的方式：

配置文件描述了建立應用的過程，即應用最終要達到的狀態。

配置文件提供了建立資源的模板，可以重複部署。

能夠像管理代碼同樣管理部署。

適合正式的、跨環境的、規模化部署。

這種方式要求熟悉配置文件的語法，有必定難度。

後面咱們都將採用配置文件的方式，你們須要儘快熟悉和掌握。

kubectl apply 不但可以建立 Kubernetes 資源，也能對資源進行更新，很是方便。不過 Kubernets 還提供了幾個相似的命令，例如 kubectl create（他只是一個簡單的建立過程）、kubectl replace、kubectl edit 和 kubectl patch。

爲避免形成沒必要要的困擾，咱們會盡可能只使用 kubectl apply（由於它能夠對資源進行更新），此命令已經可以應對超過 90% 的場景，事半功倍。

二： 讀懂 Deployment YAML

Deployment 的配置格式

分析一個 Deployment 的配置文件。 其餘 Controller（好比 DaemonSet）很是相似。

 

① apiVersion 是當前配置格式的版本。

② kind 是要建立的資源類型，這裏是 Deployment。

③ metadata 是該資源的元數據，name 是必需的元數據項。

④ spec 部分是該 Deployment 的規格說明。

⑤ replicas 指明副本數量，默認爲 1。

⑥ template 定義 Pod 的模板，這是配置文件的重要部分。

⑦ metadata 定義 Pod 的元數據，至少要定義一個 label。label 的 key 和 value 能夠任意指定。

⑧ spec 描述 Pod 的規格，此部分定義 Pod 中每個容器的屬性，name 和 image 是必需的。

運行yaml配置文件：

執行以下命令：

#運行pod 
kubectl apply -f httpd.yml #刪除pod 
kubectl delete -f http.yml

（1）伸縮（Scale Up/Down）: 是指在線增長或減小 Pod 的副本數。直接寫改yaml配置文件的replicas: 參數便可

出於安全考慮，默認配置下 Kubernetes 不會將 Pod 調度到 Master 節點。

演示：

編排文件以下

 

如今咱們經過編排文件啓動一下這個應用

kubectl apply –f httpd.yml

而後咱們獲取一下pod

kubectl get pod

 

咱們在查看一下pod的詳細信息

kubectl get pod –o wide

 

　　如今是每一個節點都有一個pod，由於咱們設置的3副本，假如說有一天我172.16.254.23節點宕機了，那麼他節點上的兩個pod就不能正常工做了，那麼怎麼辦麼？它會把這兩個pod遷移到172.16.254.22這個節點上，在22節點運行了3個副本，這就是彈性伸縮。

你還能夠直接從三副本設置成1副本

vim httpd.yml replicas： 1 kubectl apply –f httpd.yml

 

（2）節點故障（Failover）: 好比Kubernetes 檢查到 k8s-node3 不可用，將 k8s-node3 上的 Pod 標記爲 Unknown 狀態，並在 k8s-node2 上新建立兩個 Pod，維持總副本數爲原指定副本數 3。

當 k8s-node3恢復後，Unknown 的 Pod 會被刪除，不過已經運行的 Pod 不會從新調度回 k8s-node3。

（3）用 label 控制 Pod 的位置： 默認配置下，Scheduler 會將 Pod 調度到全部可用的 Node。不過有些狀況咱們但願將 Pod 部署到指定的 Node，好比將有大量磁盤 I/O 的 Pod 部署到配置了 SSD 的 Node；或者 Pod 須要 GPU，須要運行在配置了 GPU 的節點上。（指定應用的啓動）

Kubernetes 是經過 label 來實現這個功能的。label 是 key-value 對，各類資源均可以設置 label，靈活添加各類自定義屬性。

演示：

咱們先查看默認的node的標記（label）方式

kubectl get node --show-labels

 

如今的每一個節點的labels都是同樣的，都是公平的，如今咱們給23升個級，給它打個別的標記。

好比執行以下命令標註 k8s-node3 是配置了 SSD 的節點。

 #這是先給要想啓動到的節點打個標記

kubectl label node 172.16.254.23 disktype=ssd

而後咱們在看一下各個node的標記

kubectl get node --show-labels

 

disktype=ssd 已經成功添加到 k8s-node3，除了 disktype，Node 還有幾個 Kubernetes 本身維護的 label。

有了 disktype 這個自定義 label，接下來就能夠指定將 Pod 部署到 k8s-node3。編輯 httpd.yml：

 

　　在 Pod 模板的 spec 裏經過 nodeSelector （選擇）指定將此 Pod 部署到具備：label disktype=ssd 的 Node 上。咱們將副本數調爲3，看看是否pod都起在了標有disktype=ssd 的labels上。

執行編排文件

kubectl apply –f http.yml

獲取pod詳細信息

kubectl get pod –o wide

 

要刪除 label disktype，執行以下命令：

kubectl label node k8s-node1 disktype-

即刪除。 不過此時 Pod 並不會從新部署，依然在原來的node上運行。

 

kubectl get node --show-labels

除非在 nginx.yml 中刪除 nodeSelector 設置，而後經過 kubectl apply 從新部署。 Kubernetes 會刪除以前的 Pod 並調度和運行新的 Pod。

 

Kubernetes 會刪除以前的 Pod 並調度和運行新的 Pod。

3、DaemonSet：

DeamonSet應用

Deployment 部署的副本 Pod 會分佈在各個 Node 上，每一個 Node 均可能運行好幾個副本。DaemonSet 的不一樣之處在於：每一個 Node 上最多隻能運行一個副本。

DaemonSet 的典型應用場景有：

在集羣的每一個節點上運行存儲 Daemon，好比 glusterd 或 ceph。

在每一個節點上運行日誌收集 Daemon，好比 flunentd 或 logstash。

在每一個節點上運行監控 Daemon，好比 Prometheus Node Exporter 或 collectd。

其實 Kubernetes 本身就在用 DaemonSet 運行系統組件。執行以下命令：

kubectl get daemonset --namespace=kube-system

 

DaemonSet calico-node（網絡組件）分別負責在每一個節點上運行 calico-node 組件。

kubectl get daemonset –n kube-system –o wide

 

　　由於 calico-node 屬於系統組件，須要在命令行中經過 --namespace=kube-system 指定 namespace kube-system。若是不指定則只返回默認 namespace default 中的資源。

calico的編排文件以下：