原創(chuàng)文檔編寫不易,未經(jīng)許可請勿轉(zhuǎn)載。文檔中有疑問的可以郵件聯(lián)系我。 郵箱:yinwanit@163.com
說明
文章記錄了本人學習yaml文件編寫過程中的一些經(jīng)驗分享。
在k8s學習過程中yaml文件的編寫無疑是比較讓人頭痛的,尤其是最開始學習的時候。作者結(jié)合自己學習過程總結(jié)了以下幾點編寫yaml文件時遇到的問題,或者說困惑更貼切:
- 哪些資源歸屬哪些apiVersion?
- yaml文件的基礎(chǔ)格式和行文規(guī)定是怎么樣的?
- 一個yaml文件基本格式包含哪些內(nèi)容?
- 一個參數(shù)項后是否包含子參數(shù)項?
- 什么時候該用 - 橫線什么時候不該用橫線?
針對以上問題,第一點和第二點文章不再累述可在我往期的文章中找到答案(https://www.cnblogs.com/Pigs-Will-Fly/p/17602022.html),本文僅對第3、4、5三點進行經(jīng)驗分享。
全文歸納:
- 通過kubectl explain 命令可查看資源參數(shù)配置項。
- 通過kubectl explain命令查看到的參數(shù)類型為"[]"時,他的下級參數(shù)每個元組首行需要加中橫線。
- 通過kubectl explain命令查看到的參數(shù)類型為"map"時,他的下級參數(shù)每個元組以鍵值對出現(xiàn)不用遵守駝峰寫法。
- 通過kubectl explain命令查看到的子參數(shù)類型后包含"-required-"時,表示這個子參數(shù)對于他歸屬的父參數(shù)而言為必須的不可省略。
一、yaml文件基礎(chǔ)組成
k8s中yaml文件結(jié)尾需以.yml或.yaml結(jié)尾。文件放置位置不做限定。
每一個yaml文件中至少要包含四個元素:apiVersion、kind、metadata、spec,這四個元素均處于最頂層層級就是說書寫時這四個元素前不需要用空格。
書寫yaml文件時可首先把四個元素寫入到y(tǒng)aml文件中。
apiVersion: ******
kind: ******
metadata:
******
******
spec:
******
******
參數(shù)解釋
apiVersion: 置于首行,標注該yaml文件使用的版本。不同資源版本中資源使用方式和配置參數(shù)存在一定的差異。
kind: 一般置于第二行,緊跟apiVersion行后。標注該yaml文件中使用的資源類型。
metadata: 一般處于第三行yaml文件的元數(shù)據(jù),如名稱、標簽、屬于哪個命名空間、文件作者信息等。
spec:? 定義具體的資源配置參數(shù)信息。如pod、pv、svc、deployments等資源的具體參數(shù)配置。
(apiVersion、kind、metadata這行的配置方法對于k8s中所有類型資源參數(shù)基本通用,所以需要付出一點點汗水把常用的項記下來,如metadata中的name、namespace等)。
對于spec中的內(nèi)容有一點映像就行不用死記硬背,不太清楚的可以上官網(wǎng)查看,也可以通過kubectl explain命令查看具體配置。
二、kubectl explain命令基礎(chǔ)用法
在編寫yaml文件時知道了資源類型即kind行處填寫的值,本章節(jié)以pod資源舉例展示kubectl explain命令使用方法及如何把explain的結(jié)果置入到y(tǒng)aml文件中。
通過kubectl explain? <資源類型> 的方法可以獲取到該資源下有哪些參數(shù)配置。
candidate@node01:~$ kubectl explain pod. KIND: Pod VERSION: v1 DESCRIPTION: Pod is a collection of containers that can run on a host. This resource is created by clients and scheduled onto hosts. FIELDS: apiVersion <string> APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources kind <string> Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds metadata <ObjectMeta> Standard object's metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata spec <PodSpec> Specification of the desired behavior of the pod. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status status <PodStatus> Most recently observed status of the pod. This data may not be up to date. Populated by the system. Read-only. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status candidate@node01:~$
通過kubectl explain pod 命令可以看到pod這個資源對應的第一層(頂層)參數(shù)5個,最后一個status這個在我們編寫yaml時可以省略不寫,只對前四個進行定義編寫。
如果想看到下一層級有哪些參數(shù),只需繼續(xù)執(zhí)行?kubectl explain 命令加上你想要參看的參數(shù)名(每個層級間用半角 點 隔開),以spec為例 kubectl explain pod.spec.
在輸出結(jié)果中的FIELDS: 行以下就是pod這個資源spec參數(shù)下可設(shè)置的參數(shù)名。如果還想繼續(xù)查看同理繼續(xù)執(zhí)行? kubectl explain xx.xxx.xxx就行了。
?文章來源地址http://www.zghlxwxcb.cn/news/detail-760221.html
三、選項前是否需要加-橫線
通過第二章,基本上可以找到資源各個層級的對應關(guān)系,但是這些內(nèi)容怎么體現(xiàn)在yaml中,如經(jīng)常能看到y(tǒng)aml文件中,有的參數(shù)名后直接跟的參數(shù)值,有的參數(shù)名前有橫線,還有些沒有按照駝峰格式來書寫。
本章節(jié)通過一個簡單的yaml文件來進行輔助說明。
yaml文件描述:使用nginx鏡像創(chuàng)建一個名為web-server的pod,容器和pod同名,必須運行在標簽為 cpu=amd的node節(jié)點。容器中提供一個名為http的TCP協(xié)議80端口服務(wù)。同時在容器的/v1目錄掛載一個名為test1的emptydir類型的卷,/v2目錄下掛載另外一個名為test2的emptydir卷。
apiVersion: v1 kind: Pod metadata: labels: run: web-server name: web-server spec: containers: - image: nginx imagePullPolicy: IfNotPresent name: web-server ports: - name: http containerPort: 80 protocol: TCP volumeMounts: - name: test1 mountPath: /v1 - name: test2 mountPath: /v2 restartPolicy: Always volumes: - name: test1 emptyDir: {} - name: test2 emptyDir: {} nodeSelector: cpu: amd
3.1 何時用橫線
當你的父級參數(shù)是列表格式時,該父級參數(shù)下的第一行子參數(shù)前需要加上橫線。metadata、spec這兩個參數(shù)下的第一級子參數(shù)首行都不用加橫線。
以pod的spec下的containers參數(shù)為例,執(zhí)行kubectl explain? pod.spec.containers.?
?紅圈處為containers參數(shù)的類型,中括號表示他是一個列表類型的數(shù)據(jù),即containers下的第一級子參數(shù)第一行必須要加上“-” 橫線。
FIELDS行下的橙圈處表示containers下子參數(shù)的格式,如果要換行書寫,歸屬他們的第一級子第一行也必須加上“-”橫線。
?再看yaml文件中的ports參數(shù),也用kubectl explain? pod.spec.containers.ports. 命令來查看一下。
?通過kubectl explain? pod.spec.containers.ports. 命令查看得知 ports這個參數(shù)也是一個列表,同理可得它的下一層首行也必須要加上中橫線。
?為了更一步確認找一個不是沒加橫線的看看,如 pod.spec.containers.name.這個參數(shù),執(zhí)行命令
?從執(zhí)行結(jié)果看name沒有下一級,同時它的格式時在name同行中跟參數(shù)即 name: xxxxx。
總結(jié):在執(zhí)行 kubectl explain 命令時你所要使用的參數(shù)父一級類型是列表( [] )那么,你需要加橫線在該父級參數(shù)每個元組的第一行。
?
3.2 何時不用駝峰寫法
kubectl explain命令查看到指定資源的類型為map時,該資源的下級資源即為鍵值對填寫不用遵守駝峰寫法。
如演示yaml中的nodeSelector參數(shù),它作為pod.spec的子參數(shù)他的格式是?<map[string]string>,可直接在同行跟參數(shù),也可換行后指定參數(shù)。
?map格式的下一層參數(shù)不用適用于駝峰寫法。
?
3.3 哪些參數(shù)不能省略
kubectl explain結(jié)果輸出中帶有“-required-”字眼的參數(shù)不能省略。如pod.spec.containers.ports中的containerPort參數(shù)。
pod.spec.volumes.中的name參數(shù)一樣不能審閱,如果yaml文件中存在pod.spec.volumes那么volumes的下層參數(shù)必須要有name這個參數(shù)。
文章來源:http://www.zghlxwxcb.cn/news/detail-760221.html
?
到了這里,關(guān)于k8s學習筆記-07(借助kubectl explain編寫yaml文件)的文章就介紹完了。如果您還想了解更多內(nèi)容,請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章,希望大家以后多多支持TOY模板網(wǎng)!