k8s學習-運行應用

Deployment

Deployment是k8s最經常使用的controller，一般k8s不會直接建立pod，而是經過controller來管理POD的。Controller中定義了POD的部署特性，好比有幾個副本，在什麼樣的NODE上運行等，它能夠管理pod的多個副本，並確保pod按照指望的狀態運行。

運行Deployment

按照以下方式，運行一個Deployment

kubectl run nginx-deployment --image=nginx:1.7.9 --replicas=3

上面的命令將部署包含三個副本的Deployment nginx-deployment，容器的image爲nginx:1.7.9

以下所示：

經過kubectl get deployment能夠看到nginx-deployment的狀態

經過kubectl describe deployment瞭解更詳細的信息。

在NewreplicaSet，能夠看到建立了一個nginx-deployment-754846b88c的replicatset，說明deployment是經過replicaset來管理POD的。執行kubectl describe replicaset 查看詳細信息。

Controller By指明此ReplicaSet是由Deployment/nginx-deployment建立的。

執行kubectl get pod和kubectl describe pod查看更詳細的信息。

Controlled By指明瞭POD由誰建立，EVENT記錄了pod的啓動過程。

整個過程以下所示：

1.用戶經過 kubectl 建立 Deployment。

2.Deployment 建立 ReplicaSet。

3.ReplicaSet 建立 Pod。

對象命令的方式是」子對象的名字=父對象名字+隨機字符串或者數字"

配置文件

1. 用 kubectl 命令直接建立，好比：

kubectl run nginx-deployment --image=nginx:1.7.9 --replicas=2
在命令行中經過參數指定資源的屬性。

2. 經過配置文件和 kubectl apply 建立，要完成前面一樣的工做，可執行命令：

kubectl apply -f nginx.yml
nginx.yml 的內容爲：

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

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

基於命令的方式：

簡單直觀快捷，上手快。

適合臨時測試或實驗。

基於配置文件的方式：

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

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

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

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

這種方式要求熟悉配置文件的語法，有必定難度。
kubectl apply 不但可以建立k8s資源，也能對資源進行更新，k8s還提供了kubectl create,kubectl reploace,kubectl edit和kubeclt path命令。

配置文件

配置文件主要是yaml格式，其餘的controler跟deployment的配置文件方式相似

簡單的配置文件以下所示：

① apiVersion 是當前配置格式的版本。
② kind 是要建立的資源類型，這裏是 Deployment。
③ metadata 是該資源的元數據，name 是必需的元數據項。
④ spec 部分是該 Deployment 的規格說明。
⑤ replicas 指明副本數量，默認爲 1。
⑥ template 定義 Pod 的模板，這是配置文件的重要部分。
⑦ metadata 定義 Pod 的元數據，至少要定義一個 label。label 的 key 和 value 能夠任意指定。
⑧ spec 描述 Pod 的規格，此部分定義 Pod 中每個容器的屬性，name 和 image 是必需的

執行kubectl apply -f niginx.yml便可。
執行kubectl delete deploymet nginx-deployment或者kubectl delete -f nginx.yml進行刪除

伸縮

配置文件以下

伸縮是指在線增長或者減小Pod的副本數

初始是1個副本，以下所示：

如今修改new_nginx,yml文件，將副本修改爲5個。

再次執行kubectl -f apply，結果以下所示：

在dashboard上也能確認

用label控制pod的位置

默認狀況下,sxhedulet會將pod調度到全部可用的node上，不過有些狀況須要將pod部署到指定的node上，k8s使用label來實現這個功能的。
label是key-value對，各類資源均可以設置label,靈活添加各類自定義的屬性，以下所示，標註k8s-node1是配置了ssd的節點

kubectl label node docker-1 disktype=ssd

其餘的node還有k8s本身維護的label
有了disktype這個自定義的label,接下來就能夠指定將pod部署node-1上

在pod模板的spec裏經過nodeSelector指定將此pod部署到具備label disktype=ssd的node上。

DaemonSet

Deployment部署的副本pod會分佈在各個node上，每一個node均可以運行好幾個副本。
DaemonSet的不通之處在於每一個node上最多隻能運行一個副本。
它的典型應用場景有:
1.在集羣的每一個幾點上運行存儲deamon，好比glusterd後者ceph
2.在每一個節點上運行日誌收集deamon，好比flunentd或者logstash
3.在每一個幾點上運行監控daemon，好比prometheus node exploer

其實k8s本身就在用DaemonSet運行系統組件

kube-proxy的配置文件，以下所示：

① kind: DaemonSet 指定這是一個 DaemonSet 類型的資源。

② containers 定義了 kube-proxy 的容器。

③ status 是當前 DaemonSet 的運行時狀態，這個部分是 kubectl edit特有的。其實 Kubernetes 集羣中每一個當前運行的資源均可以經過 kubectl edit 查看其配置和運行狀態，好比 kubectl edit deployment nginx-deployment。

job

容器按照持續運行的時間可分爲兩類：服務類容器和工做類容器
服務類容器一般持續提供服務，須要一直運行，好比http server，daemon等，工做容器是一次性人物，好比批處理程序，完成後容器就退出
k8s的deployment,replicaSet和daemonset都用於管理服務類容器，對工做類容器，使用job
如下是個簡單的job配置文件

① batch/v1 是當前 Job 的 apiVersion。

② 指明當前資源的類型爲 Job。

③ restartPolicy 指定什麼狀況下須要重啓容器。對於 Job，只能設置爲 Never 或者 OnFailure。對於其餘 controller（好比 Deployment）能夠設置爲 Always 。

經過 kubectl apply -f myjob.yml 啓動 Job。

經過kubectl get job來查看job的狀態

經過kubectl get pod查看pod的狀態

由於Pod執行完畢後，容器已經退出，須要用--show all才能查看completed狀態的pod,經過kubectl logs能夠查看pod的標準輸出。

job的並行性

在同時運行多個pod，能夠提升job的執行效率，能夠經過parallelism設置。

將並行的pod數量設置爲2

定時job

linux中有cron程序定時執行任務，k8s的cronjob提供了相似的功能，能夠執行job,配置文件以下所示：

① batch/v2alpha1 是當前 CronJob 的 apiVersion。

② 指明當前資源的類型爲 CronJob。

③ schedule 指定何時運行 Job，其格式與 Linux cron 一致。這裏 /1 * 的含義是每一分鐘啓動一次。

④ jobTemplate 定義 Job 的模板，格式與前面 Job 一致。