寫在前面

在前?的課程中，我們在安裝 kubernetes 集群的時候使?了?些 YAML ?件來創(chuàng)建相關的資源，但大家對 YAML ?件還是?常陌?。所以我們先來簡單看?看 YAML ?件是如何?作的，并使? YAML ?件來定義?個 k8s pod，然后再定義?個 k8s deployment吧。

YAML基礎

它的基本語法規(guī)則如下：

• ??寫敏感
• 使?縮進表示層級關系
• 縮進時不允許使?Tab鍵，只允許使?空格。
• 縮進的空格數(shù)?不重要，只要相同層級的元素左側(cè)對?即可
• #表示注釋，從這個字符?直到?尾，都會被解析器忽略。

在我們的 kubernetes 中，你只需要兩種結構類型就?了：

• Lists
• Maps

也就是說，你可能會遇到 Lists 的 Maps 和 Maps 的 Lists，等等。不過不?擔?，你只要掌握了這兩 種結構也就可以了，其他更加復雜的我們暫不討論。

Maps

?先我們來看看 Maps，我們都知道 Map 是字典，就是?個 key:value 的鍵值對，Maps 可以讓我們 更加?便的去書寫配置信息，例如：

--- 
apiVersion: v1 
kind: Pod

第??的 - - - 是分隔符，是可選的，在單??件中，可?連續(xù)三個連字號 --- 區(qū)分多個?件。這?我 們可以看到，我們有兩個鍵： kind 和 apiVersion ，他們對應的值分別是：v1 和Pod。上?的 YAML ?件轉(zhuǎn)換成 JSON 格式的話，你肯定就容易明?了：

{ 
"apiVersion": "v1",
 "kind": "pod" 
 }

我們在創(chuàng)建?個相對復雜?點的 YAML ?件，創(chuàng)建?個 KEY 對應的值不是字符串?是?個 Maps：

--- 
apiVersion: v1
kind: Pod 
metadata: 
name: kube100-site 
labels: 
app: web 

上?的 YAML ?件，metadata 這個 KEY 對應的值就是?個 Maps 了，?且嵌套的 labels 這個 KEY 的值?是?個 Map，你可以根據(jù)你??的情況進?多層嵌套。

上?我們也提到了 YAML ?件的語法規(guī)則，YAML 處理器是根據(jù)?縮進來知道內(nèi)容之間的嗯關聯(lián)性 的。?如我們上?的 YAML ?件，我?了兩個空格作為縮進，空格的數(shù)量并不重要，但是你得保持? 致，并且?少要求?個空格（什么意思？就是你別?會縮進兩個空格，?會縮進4個空格）。

我們可以看到 name 和 labels 是相同級別的縮進，所以 YAML 處理器就知道了他們屬于同?個 MAP，? app 是 labels 的值是因為 app 的縮進更?。

注意：在 YAML ?件中絕對不要使? tab 鍵。

同樣的，我們可以將上?的 YAML ?件轉(zhuǎn)換成 JSON ?件：

{ 
"apiVersion": "v1", 
"kind": "Pod", 
"metadata": { 
"name": "kube100-site", 
"labels": { 
"app": "web" 
} 
} 
} 

或許你對上?的 JSON ?件更熟悉，但是你不得不承認 YAML ?件的語義化程度更?吧？

Lists

Lists 就是列表，說?了就是數(shù)組，在 YAML ?件中我們可以這樣定義：

args
- Cat 
- Dog 
- Fish

你可以有任何數(shù)量的項在列表中，每個項的定義以破折號（-）開頭的，與?元素直接可以縮進?個空 格。對應的 JSON 格式如下：

{ 
"args": [ 'Cat', 'Dog', 'Fish' ] 
}

當然，list 的?項也可以是 Maps，Maps 的?項也可以是list如下所示：

--- 
apiVersion: v1 
kind: Pod 
metadata: 
name: kube100-site 
labels: 
app: web 
spec: 
containers: 
- name: front-end 
image: nginx 
ports: 
- containerPort: 80 
- name: flaskapp-demo 
image: jcdemo/flaskapp 
ports: 
- containerPort: 5000 

?如這個 YAML ?件，我們定義了?個叫 containers 的 List 對象，每個?項都由 name、image、 ports 組成，每個 ports 都有?個 key 為 containerPort 的 Map 組成，同樣的，我們可以轉(zhuǎn)成如下 JSON 格式?件：

{ 
"apiVersion": "v1", 
"kind": "Pod", 
"metadata": { 
"name": "kube100-site", 
"labels": { 
"app": web" 
} 
},
"spec": { 
"containers": [{ 
"name": "front-end", 
"image": "nginx", 
"ports": [{ 
"containerPort": "80" 
}] 
}, {
"name": "flaskapp-demo", 
"image": "jcdemo/flaskapp", 
"ports": [{ 
"containerPort": "5000" 
}] 
}] 
} 
} 

是不是覺得? JSON 格式的話?件明顯? YAML ?件更復雜了呢?

使? YAML 創(chuàng)建 Pod

現(xiàn)在我們已經(jīng)對 YAML ?件有了?概的了解了，我相信你應該沒有之前那么懵逼了吧？我們還是來使? YAML ?件來創(chuàng)建?個 Deployment 吧。

API 說明：https://kubernetes.io/docs/reference/generated/kubernetes−api/v1.10/\color{#00C5CD}{https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.10/ }https://kubernetes.io/docs/reference/generated/kubernetes−api/v1.10/

創(chuàng)建 Pod

--- 
apiVersion: v1 
kind: Pod 
metadata: 
name: kube100-site 
labels: 
app: web 
spec: 
containers: 
- name: front-end 
image: nginx 
ports: 
- containerPort: 80 
- name: flaskapp-demo 
image: jcdemo/flaskapp 
ports: 
- containerPort: 5000 

這是我們上?定義的?個普通的 POD ?件，我們先來簡單分析下?件內(nèi)容：

• apiVersion，這?它的值是 v1，這個版本號需要根據(jù)我們安裝的 kubernetes 版本和資源類型進? 變化的，記住不是寫死的
• kind，這?我們創(chuàng)建的是?個 Pod，當然根據(jù)你的實際情況，這?資源類型可以是 Deployment、 Job、Ingress、Service 等待。
• metadata：包含了我們定義的 Pod 的?些 meta 信息，?如名稱、namespace、標簽等等信息。
• spec：包括?些 containers，storage，volumes，或者其他 Kubernetes 需要知道的參數(shù)，以及諸 如是否在容器失敗時重新啟動容器的屬性。你可以在特定 Kubernetes API 找到完整的 Kubernetes Pod 的屬性。

讓我們來看?個典型的容器的定義：

…spec: 
containers: 
- name: front-end 
image: nginx 
ports: 
- containerPort: 80 
… 

在這個例?中，這是?個簡單的最?定義：?個名字（front-end），基于 nginx 的鏡像，以及容器將會監(jiān)聽的?個端?（80）。在這些當中，只有名字是?常需要的，你也可以指定?個更加復雜的屬性，例如在容器啟動時運?的命令，應使?的參數(shù)，?作?錄，或每次實例化時是否拉取映像的新副本。以下是?些容器可選的設置屬性：

• name

• image
• command
• args
• workingDir
• ports
• env
• resources
• volumeMounts
• livenessProbe
• readinessProbe
• livecycle
• terminationMessagePath
• imagePullPolicy
• securityContext
• stdin
• stdinOnce
• tty

明?了 POD 的定義后，我們將上?創(chuàng)建 POD 的 YAML ?件保存成 pod.yaml，然后使? kubectl 創(chuàng)建 POD：

$ kubectl create -f pod.yaml 
pod "kube100-site" created 

然后我們就可以使?我們前??較熟悉的 kubectl 命令來查看 POD 的狀態(tài)了：

$ kubectl get pods 
NAME READY STATUS RESTARTS AGE 
kube100-site 2/2 Running 0 1m 

到這?我們的 POD 就創(chuàng)建成功了，如果你在創(chuàng)建過程中有任何問題，我們同樣可以使?前?的 kubectl describe 進?排查。我們先刪除上?創(chuàng)建的POD：

$ kubectl delete -f pod.yaml 
pod "kube100-site" deleted

創(chuàng)建 Deployment

現(xiàn)在我們可以來創(chuàng)建?個真正的 Deployment。在上?的例?中，我們只是單純的創(chuàng)建了?個 POD 實 例，但是如果這個 POD 出現(xiàn)了故障的話，我們的服務也就掛掉了，所以 k8s 提供了? 個 Deployment 的概念，可以讓 kubernetes 去管理?組 POD 的副本，也就是副本集，這樣就可以保 證?定數(shù)量的副本?直可?的，不會因為?個 POD 掛掉導致整個服務掛掉。我們可以這樣定義?個 Deployment：

--- 
apiVersion: extensions/v1beta1 
kind: Deployment 
metadata: 
name: kube100-site
spec: 
replicas: 2 

注意這? apiVersion 對應的值是 extensions/v1beta1 ，當然 kind 要指定為 Deployment，因為這 就是我們需要的，然后我們可以指定?些 meta 信息，?如名字，或者標簽之類的。最后，最重要的 是 spec 配置選項，這?我們定義需要兩個副本，當然還有很多可以設置的屬性，?如?個 Pod 在沒 有任何錯誤變成準備的情況下必須達到的最?秒數(shù)。 我們可以在Kubernetes v1beta1 API參考中找到 ?個完整的 Depolyment 可指定的參數(shù)列表。 現(xiàn)在我們來定義?個完整的 Deployment 的 YAML ?件：

--- 
apiVersion: extensions/v1beta1 
kind: Deployment 
metadata: 
name: kube100-site 
spec: 
replicas: 2 
template: 
metadata: 
labels: 
app: web 
spec: 
containers: 
- name: front-end 
image: nginx 
ports: 
- containerPort: 80 
- name: flaskapp-demo 
image: jcdemo/flaskapp 
ports: 
- containerPort: 5000 

看起來是不是和我們上?的 pod.yaml 很類似啊，注意其中的 template，其實就是對 POD 對象的定義。將上?的 YAML ?件保存為 deployment.yaml，然后創(chuàng)建 Deployment：

$ kubectl create -f deployment.yaml 
deployment "kube100-site" created 
```同樣的，想要查看它的狀態(tài)，我們可以檢查 Deployment的列表：
```go
$ kubectl get deployments 
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE 
kube100-site 2 2 2 2 2m 

我們可以看到所有的 Pods 都已經(jīng)正常運?了。 到這?我們就完成了使? YAML ?件創(chuàng)建 Kubernetes Deployment 的過程，在了解了 YAML ?件的基礎后，定義 YAML ?件其實已經(jīng)很簡單了，最主要的是要根據(jù)實際情況去定義 YAML ?件，所以查閱 Kubernetes ?檔很重要。

可以使?http://www.yamllint.com/去檢驗 YAML ?件的合法性

以上就是云原生系列Kubernetes深度解析YAML文件使用的詳細內(nèi)容，更多關于Kubernetes解析YAML文件的資料請關注腳本之家其它相關文章！

最新評論