kubernetes資源極速快三網站出租組織、管理介紹

如果已經 極速快三網站出租haozbbs.com Q1446595067在kubenetes中部署了應用，並通過service的形式將它 暴露出去。接下來呢？kubenetes提供了大量工具幫助使用者管理應用的部署、彈性伸縮、升級等。

組織資源配置檔案

很多應用要求同時建立多個資源，比如deployment與service等。管理多個相關資源的一種簡單的方法是將它們簡單的組織在一個檔案中（在YAML格式的檔案中通過 — 分隔），如下例：

1. #　https://github.com/kubernetes/website/blob/master/content/en/docs/concepts/cluster-administration/nginx-app.yaml

2. apiVersion: v1

3. kind: Service

4. metadata:

5. name: my-nginx-svc

6. labels:

7. app: nginx

8. spec:

9. type: LoadBalancer

10. ports:

11. - port: 80

12. selector:

13. app: nginx

14. ---

15. apiVersion: apps/v1

16. kind: Deployment

17. metadata:

18. name: my-nginx

19. labels:

20. app: nginx

21. spec:

22. replicas: 3

23. selector:

24. matchLabels:

25. app: nginx

26. template:

27. metadata:

28. labels:

29. app: nginx

30. spec:

31. containers:

32. - name: nginx

33. image: nginx:1.7.9

34. ports:

35. - containerPort: 80

建立方式與單個資源相同，只需執行一次建立命令即可：

1. $ kubectl create -f https://k8s.io/docs/concepts/cluster-administration/nginx-app.yaml

2. service "my-nginx-svc" created

3. deployment "my-nginx" created

資源會依在配置檔案中出現的順序依次建立，因此，最好首先指定需要建立的service，因為這將確保排程程式能夠將與服務相關聯的pod展開，因為它們是由控制器建立的，比如deployment。

kubectl create命令支援多個-f選項，如：

$ kubectl create -f https://k8s.io/docs/concepts/cluster-administration/nginx/nginx-svc.yaml -f https://k8s.io/docs/concepts/cluster-administration/nginx/nginx-deployment.yaml

也可指定目錄：

$ kubectl create -f https://k8s.io/docs/concepts/cluster-administration/nginx/

kubectl命令會讀取目錄下所有字尾為.yaml, .yml, or .json的檔案。

鼓勵實踐將相同微服務或者是同層應用的所有配置檔案集中放置在一個檔案中，或者是將緊密相關的檔案放入到同一個目錄之下。如果同層應用是通過DNS彼此繫結，那麼就可以簡單將堆疊中的所以元件一起部署。

***　還是應該將資源的定義分隔成單獨的檔案，然後再將相關的檔案通過目錄的形式組織在一起，避免單個檔案內容過大過於複雜。

kubectl批量操作

資源建立並非kubectl命令能實現的唯一批量操作。它也可以從資源配置檔案中提取出資源名稱實現其它操作，特別是刪除指建立的資源：

1. $ kubectl delete -f https://k8s.io/docs/concepts/cluster-administration/nginx-app.yaml

2. deployment "my-nginx" deleted

3. service "my-nginx-svc" deleted

因為只有兩個資源，所以直接使用命令列，通過resource/name也很容易實現：

$ kubectl delete deployments/my-nginx services/my-nginx-svc

對於更大的資源數量，可以很容易的通過為命令列指定標籤查詢選擇器過慮出需要操作的資源，如使用-l –selector等選項：

1. $ kubectl delete deployment,services -l app=nginx

2. deployment "my-nginx" deleted

3. service "my-nginx-svc" deleted

因為這種方式是通過標籤選擇器過慮出符合條件的資源，所以要求嚴格規範標籤的使用，否則容易發生誤操作。

kubectl命令執行時需要資源名稱，與命令執行後輸出的資源名稱語法相同，因此很容易利用管道、$()、xargs等技術將之個命令組合在一起，例如：

1. $ kubectl get $(kubectl create -f docs/concepts/cluster-administration/nginx/ -o name | grep service)

2. NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE

3. my-nginx-svc 10.0.0.208 <pending> 80/TCP 0s

上述命令，首先執行kubectl create建立docs/concepts/cluster-administration/nginx/目錄下指定的資源，因為指定了-o name選項，輸出結果的格式被設定為“resource/name”格式，再通過管理將輸出傳遞給grep命令，將其中的service資源檢出，結果作為kubectl get的引數。

也可以通過多層目錄組織資源，執行命令時指定–recursive、-R與–filename、-f選項，則命令遍歷整個目錄，實現對所有資源的批處理。假設存在著如下目錄：

1. project/k8s/development

2. ├── configmap

3. │ └── my-configmap.yaml

4. ├── deployment

5. │ └── my-deployment.yaml

6. └── pvc

7. └── my-pvc.yaml

當執行如一命令時會報錯，原因是預設情況下只處理目錄的第一次，不會深入處理目錄下的子目錄：

1. $ kubectl create -f project/k8s/development

2. error: you must provide one or more resources by argument or filename (.json|.yaml|.yml|stdin)

指定–recursive 或者 -R，則會遍歷目錄及其下的所有子目錄：

1. $ kubectl create -f project/k8s/development --recursive

2. configmap "my-config" created

3. deployment "my-deployment" created

4. persistentvolumeclaim "my-pvc" created

高效使用標籤

在現實的使用場景中，一個資源往往需要加入多個標籤，以便從不同的維度上將資源劃歸到不同的集合中。例如gustbook中前端：

1. labels:

2. app: guestbook

3. tier: frontend

兩個標籤分別標識資源的app各類與所屬的層級。

Redis中的master：

1. labels:

2. app: guestbook

3. tier: backend

4. role: master

Redis中的slave：

1. labels:

2. app: guestbook

3. tier: backend

4. role: slave

用“role”標籤區分master與slave角色。

通過指定標籤從不同的維度組織資源：

1. $ kubectl create -f examples/guestbook/all-in-one/guestbook-all-in-one.yaml

2. $ kubectl get pods -Lapp -Ltier -Lrole

3. NAME READY STATUS RESTARTS AGE APP TIER ROLE

4. guestbook-fe-4nlpb 1/1 Running 0 1m guestbook frontend <none>

5. guestbook-fe-ght6d 1/1 Running 0 1m guestbook frontend <none>

6. guestbook-fe-jpy62 1/1 Running 0 1m guestbook frontend <none>

7. guestbook-redis-master-5pg3b 1/1 Running 0 1m guestbook backend master

8. guestbook-redis-slave-2q2yf 1/1 Running 0 1m guestbook backend slave

9. guestbook-redis-slave-qgazl 1/1 Running 0 1m guestbook backend slave

10. my-nginx-divi2 1/1 Running 0 29m nginx <none> <none>

11. my-nginx-o0ef1 1/1 Running 0 29m nginx <none> <none>

12. $ kubectl get pods -lapp=guestbook,role=slave

13. NAME READY STATUS RESTARTS AGE

14. guestbook-redis-slave-2q2yf 1/1 Running 0 3m

15. guestbook-redis-slave-qgazl 1/1 Running 0 3m

金絲雀部署

標籤的一個使用場景是區分同一個元件的不同釋出版本或者配置版本，常見的實踐是用標籤實現金絲雀部署。例如，使用“track”標籤標識同一元件的不同版本。對於主力、穩定版本，“track”標籤的值為“stable”。

1. name: frontend

2. replicas: 3

3. ...

4. labels:

5. app: guestbook

6. tier: frontend

7. track: stable

8. ...

9. image: gb-frontend:v3

對於新發布版本，“track”標籤的值為“canary”。

1. name: frontend-canary

2. replicas: 1

3. ...

4. labels:

5. app: guestbook

6. tier: frontend

7. track: canary

8. ...

9. image: gb-frontend:v4

這樣，同一個元件的兩種版本同時存在，使用的image不同，不同版本的例項通過“track”標籤的值加以區分。前端服務的選擇器通過指定兩種版本的共有標籤從麵包含元件的不同版本，如下：

1. selector:

2. app: guestbook

3. tier: frontend

可以調整穩定版與測試版副本的資料，從而決定兩者所處理的流量比例。經過一定時間的測試後，如果沒有問題。則可以將所有“track”為“stable”的例項升級成最新版本，並將“track”為“canary”的例項刪除，從而完成版本升級。如果出現問題，只需將“canary”版本的例項刪除即可。

更新標籤

用kubectl label命令對已經存在的Pod或者其它資源重新打標籤，如下：

1. $ kubectl label pods -l app=nginx tier=fe

2. pod "my-nginx-2035384211-j5fhi" labeled

3. pod "my-nginx-2035384211-u2c7e" labeled

4. pod "my-nginx-2035384211-u3t6x" labeled

以上命令中-l app=nginx表示過濾條件，檢出系統中所有app為nginx的元件，後邊的tier=fe表示對檢出的資源重新打上標籤。確認結果：

1. $ kubectl get pods -l app=nginx -L tier

2. NAME READY STATUS RESTARTS AGE TIER

3. my-nginx-2035384211-j5fhi 1/1 Running 0 23m fe

4. my-nginx-2035384211-u2c7e 1/1 Running 0 23m fe

5. my-nginx-2035384211-u3t6x 1/1 Running 0 23m fe

以上命令輸出所有符合“app=nginx”條件的Pod，-L tier指示在輸出結果中新增額外的列顯示tier標籤內容。

更新註解

註解屬於註釋性、非標識性的後設資料，對已存在的資源追加註解的方式如下：

1. $ kubectl annotate pods my-nginx-v4-9gw19 description=`my frontend running nginx`

2. $ kubectl get pods my-nginx-v4-9gw19 -o yaml

3. apiversion: v1

4. kind: pod

5. metadata:

6. annotations:

7. description: my frontend running nginx

8. ...

應用伸縮

通過kubectl scale調整例項個數，將nginx例項的副本資料從3減少到1：

1. $ kubectl scale deployment/my-nginx --replicas=1

2. deployment "my-nginx" scaled

目前只有一個nginx的Pod例項：

1. $ kubectl get pods -l app=nginx

2. NAME READY STATUS RESTARTS AGE

3. my-nginx-2035384211-j5fhi 1/1 Running 0 30m

kubenetes支援設定副本數量的最小值與最大值，系統根據例項的負載情況，在最大值與最小值之間動態動態調整副本數量實現自動伸縮。

1. $ kubectl autoscale deployment/my-nginx --min=1 --max=3

2. deployment "my-nginx" autoscaled

就地更新資源

有時候，對於已經建立的資源，需要進行精確的、無破壞性的更新。解釋：前文中所涉及的更新方法，屬於kubectl管理物件三種方法中的“祈使物件配置”，在有些情況下，這種更新方式會產生破壞性。

推薦的管理配置檔案的方式是與版本控制系統整合，與GIT，然後通過kubectl apply將GIT中的配置檔案應用到叢集中，從而實現配置檔案與叢集中實時配置的版本控制。kubectl apply命令本質上是計算配置檔案與系統中實時物件配置的差值，再通過補丁的形式將這種差值應用到系統中，而不是從整體上替換掉系統中的配置，這樣不會丟失那麼獨立於配置的屬性從而避免破壞性更新。

1. $ kubectl apply -f docs/concepts/cluster-administration/nginx/nginx-deployment.yaml

2. deployment "my-nginx" configured

注意，kubectl apply管理資源的方法稱為“宣告物件配置”，其在系統中的實時物件，在其註解中會儲存一份歷史配置。當對這個物件更新時，系統參考配置檔案、實時物件註解、實時物件在系統中的實際配置三個方面的計算，最後決定如何更新物件。

前文涉及到的資源通過kubectl create -f形式建立，這種方法稱為“祈使物件配置”，系統中的實時物件沒有包含歷史配置的註解，需要通過一定的方法將資源的管理從“祈使物件配置”遷移到“宣告物件配置”，推薦方法：

$ kubectl edit deployment/my-nginx

或者：

1. $ kubectl get deployment my-nginx -o yaml > /tmp/nginx.yaml

2. $ vi /tmp/nginx.yaml

3. # do some edit, and then save the file

4. $ kubectl apply -f /tmp/nginx.yaml

5. deployment "my-nginx" configured

6. $ rm /tmp/nginx.yaml

破壞性更新

系統中實時物件的某些屬性獨立於配置檔案變化，破壞性更新的本質是忽略掉這些屬性的變更，首先將實時物件的配置從系統中刪然後再將新的配置檔案應用到系統中，如下：

1. $ kubectl replace -f docs/concepts/cluster-administration/nginx/nginx-deployment.yaml --force

2. deployment "my-nginx" deleted

3. deployment "my-nginx" replaced

更新應用時不中斷服務

例如首先執行如下命令：

1. $ kubectl run my-nginx --image=nginx:1.7.9 --replicas=3

2. deployment "my-nginx" created

kubectl run命令屬於kubectl管理物件三種方式中的“祈使命令”方式。以上命令會建立一個deploment型別的Pod，副本資料為３，例項映象為nginx:1.7.9。如果打算將nginx版本從１.７.９升級到1.9.1，執行如下命令：

$ kubectl edit deployment/my-nginx

在編輯器中將.spec.template.spec.containers[0].image的值由nginx:1.7.9改成nginx:1.１.１即可。kubenetes系統檢測到配置變化後會逐升級副本，始終有可用的例項從而保證服務不中斷。

本文轉自開源中國-kubernetes資源 極速快三網站出租組織、管理介紹