從零開始入門 K8s | K8s 的應用編排與管理

集合類資源的控制器會創建對應的歸屬資源。比如：replicaset 控制器在操作中會創建 Pod，被創建 Pod 的 Ownereference 就指向了創建 Pod 的 replicaset，Ownereference 使得用戶可以方便地查找一個創建資源的對象，另外，還可以用來實現級聯刪除的效果。

二、操作演示

1. 查看 Pod，現在沒有任何的一個 Pod；

• kubectl get pods

1. 然后用事先準備好的一個 Pod 的 yaml，創建一個 Pod 出來；

• kubectl apply -f pod1.yaml
• kubectl apply -f pod2.yaml

1. 現在查看一下 Pod 打的標簽，我們用 --show-labels 這個選項，可以看到這兩個 Pod 都打上了一個部署環境和層級的標簽；

• kubectl get pods —show-labels

1. 我們也可以通過另外一種方式來查看具體的資源信息。首先查看 nginx1 第一個 Pod 的一個信息，用 -o  yaml 的方式輸出，可以看到這個 Pod 元數據里面包括了一個 lables 的字段，里面有兩個 lable；

• kubectl get pods nginx1 -o yaml | less

1. 現在再想一下，怎么樣對 Pod 已有的 lable 進行修改？我們先把它的部署環境，從開發環境改成測試環境，然后指定 Pod 名字，在環境再加上它的一個值 test ，看一下能不能成功。 這里報了一個錯誤，可以看到，它其實是說現在這個 label 已經有值了；

• kubectl label pods nginx1 env=test

1. 如果想覆蓋掉它的話，得額外再加上一個覆蓋的選項。加上之后呢，我們應該可以看到這個打標已經成功了；

• kubectl label pods nginx1 env=test —overwrite

1. 我們再看一下現在集群的 lable 設置情況，首先可以看到 nginx1 的確已經加上了一個部署環境 test 標簽；

• kubectl get pods —show-labels

1. 如果想要對 Pod 去掉一個標簽，也是跟打標簽一樣的操作，但是 env 后就不是等號了。只加上 label 名字，后面不加等號，改成用減號表示去除 label 的 k:v；

• kubectl label pods nginx tie-

1. 可以看到這個 label，去標已經完全成功；

• kubectl get pods —show-labels

1. 下面來看一下配置的 label 值，的確能看到 nginx1 的這個 Pod 少了一個 tie=front 的標簽。有了這個 Pod 標簽之后，可以看一下怎樣用 label Selector 進行匹配？首先 label Selector 是通過 -l 這個選項來進行指定的 ，指定的時候，先試一下用相等型的一個 label 來篩選，所以我們指定的是部署環境等于測試的一個 Pod，我們可以看到能夠篩選出一臺；

• kubectl get pods —show-labels -l env=test

1. 假如說有多個相等的條件需要指定的，實際上這是一個與的關系，假如說 env 再等于 dev，我們實際上是一個 Pod 都拿不到的；

• kubectl get pods —show-labels -l env=test,env=dev

1. 然后假如說 env=dev，但是 tie=front，我們能夠匹配到第二個 Pod，也就是 nginx2；

• kubectl get pods —show-labels -l env=dev,tie=front

1. 我們還可以再試一下怎么樣用集合型的 label Selector 來進行篩選。這一次我們還是想要匹配出所有部署環境是 test 或者是 dev 的一個 Pod，所以在這里加上一個引號，然后在括號里面指定所有部署環境的一個集合。這次能把兩個創建的 Pod 都篩選出來；

• kubectl get pods —show-labels -l ’env in (dev,test)’

1. 我們再試一下怎樣對 Pod 增加一個注解，注解的話，跟打標是一樣的操作，但是把 label 命令改成 annotate 命令；然后，一樣指定類型和對應的名字。后面就不是加上 label 的 k:v 了，而是加上 annotation 的 k:v。這里我們可以指定一個任意的字符串，比如說加上空格、加上逗號都可以；

• kubectl annotate pods nginx1 my-annotate=‘my annotate,ok’

1. 然后，我們再看一下這個 Pod 的一些元數據，我們這邊能夠看到這個 Pod 的元數據里面 annotations，這是有一個 my-annotate 這個 Annotations；

• kubectl get pods nging1 -o yaml | less

1. 然后我們再演示一下看 Pod 的 Ownereference 是怎么出來的。原來的 Pod 都是直接通過創建 Pod 這個資源方式來創建的，這次換一種方式來創建：通過創建一個 ReplicaSet 對象來創建 Pod 。首先創建一個 ReplicaSet 對象，這個 ReplicaSet 對象可以具體查看一下；

• kubectl apply -f rs.yaml
• kubectl get replicasets  nginx-replicasets -o yaml |less

1. 我們可以關注一下這個 ReplicaSet 里面 spec 里面，提到會創建兩個 Pod，然后 selector 通過匹配部署環境是 product 生產環境的這個標簽來進行匹配。所以我們可以看一下，現在集群中的 Pod 情況；

• kubectl get pods

1. 將會發現多了兩個 Pod，仔細查看這兩個 Pod，可以看到 ReplicaSet 創建出來的 Pod 有一個特點，即它會帶有 Ownereference，然后 Ownereference 里面指向了是一個 replicasets 類型，名字就叫做 nginx-replicasets；

• kubectl get pods nginx-replicasets-rhd68 -o yaml | less

四、控制器模式總結

• 命令 API 最大的一個問題在于錯誤處理；

• 實際上許多命令式的交互系統后臺往往還會做一個巡檢的系統，用來修正命令處理超時、重試等一些場景造成數據不一致的問題；

• 最后，命令式 API 在處理多并發訪問時，也很容易出現問題；

• 相對的，聲明式 API 系統里天然地記錄了系統現在和最終的狀態。

1. Kubernetes 所采用的控制器模式，是由聲明式 API 驅動的。確切來說，是基于對 Kubernetes 資源對象的修改來驅動的；
2. Kubernetes 資源之后，是關注該資源的控制器。這些控制器將異步的控制系統向設置的終態驅近；
3. 這些控制器是自主運行的，使得系統的自動化和無人值守成為可能；
4. 因為 Kubernetes 的控制器和資源都是可以自定義的，因此可以方便的擴展控制器模式。特別是對于有狀態應用，我們往往通過自定義資源和控制器的方式，來自動化運維操作。這個也就是后續會介紹的 operator 的場景。

• Kubernetes 資源對象中的元數據部分，主要包括了用來識別資源的標簽：Labels， 用來描述資源的注解；Annotations， 用來描述多個資源之間相互關系的 OwnerReference。這些元數據在 K8s 運行中有非常重要的作用；

• 控制型模式中最核心的就是控制循環的概念；

• 兩種 API 設計方法：聲明式 API 和命令式 API ；Kubernetes 所采用的控制器模式，是由聲明式 API 驅動的。