云原生系列Kubernetes深度解析YAML文件使用
寫在前面
在前?的課程中,我們?cè)诎惭b kubernetes 集群的時(shí)候使?了?些 YAML ?件來(lái)創(chuàng)建相關(guān)的資源,但大家對(duì) YAML ?件還是?常陌?。所以我們先來(lái)簡(jiǎn)單看?看 YAML ?件是如何?作的,并使? YAML ?件來(lái)定義?個(gè) k8s pod,然后再定義?個(gè) k8s deployment吧。
YAML基礎(chǔ)
它的基本語(yǔ)法規(guī)則如下:
- ??寫敏感
- 使?縮進(jìn)表示層級(jí)關(guān)系
- 縮進(jìn)時(shí)不允許使?Tab鍵,只允許使?空格。
- 縮進(jìn)的空格數(shù)?不重要,只要相同層級(jí)的元素左側(cè)對(duì)?即可
- #表示注釋,從這個(gè)字符?直到?尾,都會(huì)被解析器忽略。
在我們的 kubernetes 中,你只需要兩種結(jié)構(gòu)類型就?了:
- Lists
- Maps
也就是說(shuō),你可能會(huì)遇到 Lists 的 Maps 和 Maps 的 Lists,等等。不過(guò)不?擔(dān)?,你只要掌握了這兩 種結(jié)構(gòu)也就可以了,其他更加復(fù)雜的我們暫不討論。
Maps
?先我們來(lái)看看 Maps,我們都知道 Map 是字典,就是?個(gè) key:value 的鍵值對(duì),Maps 可以讓我們 更加?便的去書寫配置信息,例如:
--- apiVersion: v1 kind: Pod
第??的 - - - 是分隔符,是可選的,在單??件中,可?連續(xù)三個(gè)連字號(hào) --- 區(qū)分多個(gè)?件。這?我 們可以看到,我們有兩個(gè)鍵: kind 和 apiVersion ,他們對(duì)應(yīng)的值分別是:v1 和Pod。上?的 YAML ?件轉(zhuǎn)換成 JSON 格式的話,你肯定就容易明?了:
{ "apiVersion": "v1", "kind": "pod" }
我們?cè)趧?chuàng)建?個(gè)相對(duì)復(fù)雜?點(diǎn)的 YAML ?件,創(chuàng)建?個(gè) KEY 對(duì)應(yīng)的值不是字符串?是?個(gè) Maps:
--- apiVersion: v1 kind: Pod metadata: name: kube100-site labels: app: web
上?的 YAML ?件,metadata 這個(gè) KEY 對(duì)應(yīng)的值就是?個(gè) Maps 了,?且嵌套的 labels 這個(gè) KEY 的值?是?個(gè) Map,你可以根據(jù)你??的情況進(jìn)?多層嵌套。
上?我們也提到了 YAML ?件的語(yǔ)法規(guī)則,YAML 處理器是根據(jù)?縮進(jìn)來(lái)知道內(nèi)容之間的嗯關(guān)聯(lián)性 的。?如我們上?的 YAML ?件,我?了兩個(gè)空格作為縮進(jìn),空格的數(shù)量并不重要,但是你得保持? 致,并且?少要求?個(gè)空格(什么意思?就是你別?會(huì)縮進(jìn)兩個(gè)空格,?會(huì)縮進(jìn)4個(gè)空格)。
我們可以看到 name 和 labels 是相同級(jí)別的縮進(jìn),所以 YAML 處理器就知道了他們屬于同?個(gè) MAP,? app 是 labels 的值是因?yàn)?app 的縮進(jìn)更?。
注意:在 YAML ?件中絕對(duì)不要使? tab 鍵。
同樣的,我們可以將上?的 YAML ?件轉(zhuǎn)換成 JSON ?件:
{ "apiVersion": "v1", "kind": "Pod", "metadata": { "name": "kube100-site", "labels": { "app": "web" } } }
或許你對(duì)上?的 JSON ?件更熟悉,但是你不得不承認(rèn) YAML ?件的語(yǔ)義化程度更?吧?
Lists
Lists 就是列表,說(shuō)?了就是數(shù)組,在 YAML ?件中我們可以這樣定義:
args - Cat - Dog - Fish
你可以有任何數(shù)量的項(xiàng)在列表中,每個(gè)項(xiàng)的定義以破折號(hào)(-)開頭的,與?元素直接可以縮進(jìn)?個(gè)空 格。對(duì)應(yīng)的 JSON 格式如下:
{ "args": [ 'Cat', 'Dog', 'Fish' ] }
當(dāng)然,list 的?項(xiàng)也可以是 Maps,Maps 的?項(xiàng)也可以是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
?如這個(gè) YAML ?件,我們定義了?個(gè)叫 containers 的 List 對(duì)象,每個(gè)?項(xiàng)都由 name、image、 ports 組成,每個(gè) ports 都有?個(gè) 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" }] }] } }
是不是覺(jué)得? JSON 格式的話?件明顯? YAML ?件更復(fù)雜了呢?
使? YAML 創(chuàng)建 Pod
現(xiàn)在我們已經(jīng)對(duì) YAML ?件有了?概的了解了,我相信你應(yīng)該沒(méi)有之前那么懵逼了吧?我們還是來(lái)使? YAML ?件來(lái)創(chuàng)建?個(gè) Deployment 吧。
API 說(shuō)明: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
這是我們上?定義的?個(gè)普通的 POD ?件,我們先來(lái)簡(jiǎn)單分析下?件內(nèi)容:
- apiVersion,這?它的值是 v1,這個(gè)版本號(hào)需要根據(jù)我們安裝的 kubernetes 版本和資源類型進(jìn)? 變化的,記住不是寫死的
- kind,這?我們創(chuàng)建的是?個(gè) Pod,當(dāng)然根據(jù)你的實(shí)際情況,這?資源類型可以是 Deployment、 Job、Ingress、Service 等待。
- metadata:包含了我們定義的 Pod 的?些 meta 信息,?如名稱、namespace、標(biāo)簽等等信息。
- spec:包括?些 containers,storage,volumes,或者其他 Kubernetes 需要知道的參數(shù),以及諸 如是否在容器失敗時(shí)重新啟動(dòng)容器的屬性。你可以在特定 Kubernetes API 找到完整的 Kubernetes Pod 的屬性。
讓我們來(lái)看?個(gè)典型的容器的定義:
…spec: containers: - name: front-end image: nginx ports: - containerPort: 80 …
在這個(gè)例?中,這是?個(gè)簡(jiǎn)單的最?定義:?個(gè)名字(front-end),基于 nginx 的鏡像,以及容器將會(huì)監(jiān)聽的?個(gè)端?(80)。在這些當(dāng)中,只有名字是?常需要的,你也可以指定?個(gè)更加復(fù)雜的屬性,例如在容器啟動(dòng)時(shí)運(yùn)?的命令,應(yīng)使?的參數(shù),?作?錄,或每次實(shí)例化時(shí)是否拉取映像的新副本。以下是?些容器可選的設(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 命令來(lái)查看 POD 的狀態(tài)了:
$ kubectl get pods NAME READY STATUS RESTARTS AGE kube100-site 2/2 Running 0 1m
到這?我們的 POD 就創(chuàng)建成功了,如果你在創(chuàng)建過(guò)程中有任何問(wèn)題,我們同樣可以使?前?的 kubectl describe 進(jìn)?排查。我們先刪除上?創(chuàng)建的POD:
$ kubectl delete -f pod.yaml pod "kube100-site" deleted
創(chuàng)建 Deployment
現(xiàn)在我們可以來(lái)創(chuàng)建?個(gè)真正的 Deployment。在上?的例?中,我們只是單純的創(chuàng)建了?個(gè) POD 實(shí) 例,但是如果這個(gè) POD 出現(xiàn)了故障的話,我們的服務(wù)也就掛掉了,所以 k8s 提供了? 個(gè) Deployment 的概念,可以讓 kubernetes 去管理?組 POD 的副本,也就是副本集,這樣就可以保 證?定數(shù)量的副本?直可?的,不會(huì)因?yàn)?個(gè) POD 掛掉導(dǎo)致整個(gè)服務(wù)掛掉。我們可以這樣定義?個(gè) Deployment:
--- apiVersion: extensions/v1beta1 kind: Deployment metadata: name: kube100-site spec: replicas: 2
注意這? apiVersion 對(duì)應(yīng)的值是 extensions/v1beta1 ,當(dāng)然 kind 要指定為 Deployment,因?yàn)檫@ 就是我們需要的,然后我們可以指定?些 meta 信息,?如名字,或者標(biāo)簽之類的。最后,最重要的 是 spec 配置選項(xiàng),這?我們定義需要兩個(gè)副本,當(dāng)然還有很多可以設(shè)置的屬性,?如?個(gè) Pod 在沒(méi) 有任何錯(cuò)誤變成準(zhǔn)備的情況下必須達(dá)到的最?秒數(shù)。 我們可以在Kubernetes v1beta1 API參考中找到 ?個(gè)完整的 Depolyment 可指定的參數(shù)列表。 現(xiàn)在我們來(lái)定義?個(gè)完整的 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
看起來(lái)是不是和我們上?的 pod.yaml 很類似啊,注意其中的 template,其實(shí)就是對(duì) POD 對(duì)象的定義。將上?的 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)正常運(yùn)?了。 到這?我們就完成了使? YAML ?件創(chuàng)建 Kubernetes Deployment 的過(guò)程,在了解了 YAML ?件的基礎(chǔ)后,定義 YAML ?件其實(shí)已經(jīng)很簡(jiǎn)單了,最主要的是要根據(jù)實(shí)際情況去定義 YAML ?件,所以查閱 Kubernetes ?檔很重要。
可以使?http://www.yamllint.com/去檢驗(yàn) YAML ?件的合法性
以上就是云原生系列Kubernetes深度解析YAML文件使用的詳細(xì)內(nèi)容,更多關(guān)于Kubernetes解析YAML文件的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章!
相關(guān)文章
一文詳解基于Kubescape進(jìn)行Kubernetes安全加固
這篇文章主要為大家介紹了基于Kubescape進(jìn)行Kubernetes安全加固詳解,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進(jìn)步,早日升職加薪2023-02-02解決k8s namespace 一直處于 Terminating 狀態(tài)的問(wèn)題
這篇文章主要介紹了k8s namespace 一直處于 Terminating 狀態(tài)的解決方法,以下的 tool 為 Terminating 狀態(tài)的 namespace,下面相關(guān)的一些操作記得將 tool 修改成自己的 namespace 名稱,需要的朋友可以參考下2022-10-10k8s 中的 service 如何找到綁定的 Pod 及實(shí)現(xiàn) 
service 是一組具有相同 label pod 集合的抽象,集群內(nèi)外的各個(gè)服務(wù)可以通過(guò) service 進(jìn)行互相通信,這篇文章主要介紹了k8s 中的 service 如何找到綁定的 Pod 以及如何實(shí)現(xiàn) Pod 負(fù)載均衡,需要的朋友可以參考下2022-10-10k8s?pod和service網(wǎng)絡(luò)暴露詳解
這篇文章主要介紹了借助iptables的路由轉(zhuǎn)發(fā)功能,打通k8s集群內(nèi)的pod和service網(wǎng)絡(luò),與外部網(wǎng)絡(luò)聯(lián)通,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進(jìn)步,早日升職加薪2023-11-11