如果你沒有看過上篇的話,推薦閱讀完 k8s 基本使用(上)后再閱讀本篇內(nèi)容匪凡。
kubectl create 創(chuàng)建資源劫乱!
k8s 中的所有東西都可以通過kubectl create
命令創(chuàng)建织中,無論你是想創(chuàng)建一個 pod 還是一個大型的滾動升級服務(wù)deployment
锥涕,create
命令都可以做到。使用create
生成一個資源主要有兩種常用方法狭吼,從yaml
配置文件創(chuàng)建 和 簡易創(chuàng)建:
從yaml
配置文件創(chuàng)建
如果你想讓 k8s 生成一個和你想象中一模一樣的資源层坠,那你就要充分而詳細(xì)的描述這個資源,k8s 就提供了這么一個方法刁笙,你可以使用yaml
格式創(chuàng)建一個文件破花,按照 k8s 指定好的結(jié)構(gòu)定義一個對象,然后使用如下方法將該文件傳遞給 k8s采盒。它就可以按照你的描述進(jìn)行生成了:
kubectl create -f <配置文件名.yaml>
例如旧乞,使用下面的配置文件就可以創(chuàng)建一個最簡單的 pod:
kubia-manual.yaml
apiVersion: v1
kind: Pod
metadata:
name: kubia-manual
spec:
containers:
- image: luksa/kubia
name: kubia
ports:
- containerPort: 8080
protocol: TCP
然后使用kubectl create -f kubia-manual.yaml
即可創(chuàng)建
root@master1:~/k8s-yaml# k create -f kubia-manual.yaml
pod/kubia-manual created
如果你的配置文件有問題的話那么 k8s 就會報(bào)錯,如下磅氨,錯誤一般都是拼寫導(dǎo)致的,比如下面這個就是Pod.spec.containers[0].ports[0]
中存在一個無法識別的名稱contaienrPort
:
root@master1:~/k8s-yaml# k create -f kubia-manual.yaml
error: error validating "kubia-manual.yaml":
error validating data: [ValidationError(Pod.spec.containers[0].ports[0]): unknown field "contaienrPort" in io.k8s.api.core.v1.ContainerPort,
ValidationError(Pod.spec.containers[0].ports[0]): missing required field "containerPort" in io.k8s.api.core.v1.ContainerPort];
if you choose to ignore these errors, turn validation off with --validate=false
這時(shí)你可能會問了嫡纠,這配置文件里一大堆名字我看不懂啊烦租,不要著急,下一條命令就會解答這個疑惑除盏,但是在此之前叉橱,我們先來看一下更簡單的 簡易創(chuàng)建 模式。
簡易創(chuàng)建
k8s 為一些常用的資源提供了簡易創(chuàng)建的方法者蠕,比如說service
窃祝、namespace
、deployment
等踱侣,這些方法可以使用kubectl create <資源類型> <資源名>
的方式創(chuàng)建粪小。例如我想創(chuàng)建一個名叫hello-world
的命名空間,直接使用下面命令即可:
kubectl create namespace hello-world
這樣就不用再跟大而全的配置文件打交道了抡句,如果你想了解都有哪些資源可以快速生成的話探膊,使用kubectl create -h
命令查看。
小結(jié)
kubectl create
可以通過指定-f <配置文件名.yaml>
參數(shù)來從一個yaml
文件生成資源待榔,也可用使用kubectl create <資源類型> <資源名>
來快速生成一個資源逞壁。
kubectl explain 解釋配置!
從上一小節(jié)中我們可以知道锐锣,k8s 可以通過配置文件來生成資源腌闯,而為了盡可能詳細(xì)的描述資源的模樣,k8s 提供了數(shù)量龐大的配置項(xiàng)雕憔,那么有沒有一種方式可以快速的了解到某個配置項(xiàng)的作用呢姿骏?有,那就是explain
(解釋)命令橘茉。
kubectl explain <配置名>
咱們來實(shí)踐一下工腋,翻到上一小節(jié)里提到的生成 pod 的配置文件姨丈。首先,我想要了解創(chuàng)建 pod 的哪些基本屬性都是干什么的擅腰,輸入kubectl explain pod
即可:
root@master1:~/k8s-yaml# 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/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/api-conventions.md#types-kinds
metadata <Object>
Standard object's metadata. More info:
https://git.k8s.io/community/contributors/devel/api-conventions.md#metadata
spec <Object>
Specification of the desired behavior of the pod. More info:
https://git.k8s.io/community/contributors/devel/api-conventions.md#spec-and-status
status <Object>
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/api-conventions.md#spec-and-status
可以看到蟋恬,給出的解釋非常詳細(xì),并且每個解釋的最后都附帶了一條鏈接趁冈,便于更加深入的進(jìn)行了解歼争,好了,那我想要了解matedata
(元數(shù)據(jù))字段都有哪些配置項(xiàng)怎么辦呢渗勘?
kubectl explain pod.matedata
root@master1:~/k8s-yaml# kubectl explain pod.metadata
KIND: Pod
VERSION: v1
RESOURCE: metadata <Object>
DESCRIPTION:
Standard object's metadata. More info:
https://git.k8s.io/community/contributors/devel/api-conventions.md#metadata
ObjectMeta is metadata that all persisted resources must have, which
includes all objects users must create.
FIELDS:
annotations <map[string]string>
Annotations is an unstructured key value map stored with a resource that
may be set by external tools to store and retrieve arbitrary metadata. They
are not queryable and should be preserved when modifying objects. More
info: http://kubernetes.io/docs/user-guide/annotations
clusterName <string>
The name of the cluster which the object belongs to. This is used to
distinguish resources with same name and namespace in different clusters.
This field is not set anywhere right now and apiserver is going to ignore
it if set in create or update request.
...
又是一排十分詳細(xì)的解釋沐绒,通過這種方式,我們可以了解到每一個資源的每一個配置項(xiàng)旺坠。想了解某個屬性的子屬性乔遮,就加個.
繼續(xù)查。不要說看不懂取刃,我覺得 谷歌翻譯 這種東西已經(jīng)挺常見了蹋肮。
kubectl delete 刪除一切!
delete
命令的使用非常簡單璧疗,如下:
kubectl delete <資源類型> <資源名>
比如說你想刪除一個名為kubia-4n2tg
的 pod坯辩。就可以這么寫:
kubectl delete pod kubia-4n2tg
如果你想刪除所有的 pod,就可以這么寫:
kubectl delete pod --all
如果你想刪除一切崩侠!那就這么寫:
kubectl delete all --all
注意漆魔!執(zhí)行刪除一切命令沒有二次驗(yàn)證,所有資源均會被直接刪除却音,在執(zhí)行前先考慮下跑路成本改抡。
kubectl edit 修改配置!
如果在日常維護(hù)過程中僧家,因?yàn)槟承┰蛭覀冃枰兏恍┓?wù)的設(shè)置該怎么辦呢雀摘?從創(chuàng)建新資源小節(jié)我們可以了解到,每個資源都是通過一個yaml
配置文件生成的八拱,哪怕是簡易創(chuàng)建的資源阵赠,也是 k8s 從一個默認(rèn)的配置文件創(chuàng)建而來的。
我們可以在get
命令后附加-o yaml
文件查看某個現(xiàn)有資源的配置項(xiàng)肌稻。例如清蚀,查看 pod kubia-manual
的配置項(xiàng):
kubectl get pod kubia-manual -o yaml
執(zhí)行之后就可以看到一個很長的配置列表,你也可以試一下自己創(chuàng)建的 pod 的配置項(xiàng)爹谭,你會發(fā)現(xiàn)同樣很長枷邪,這就是因?yàn)?k8s 會讀取你提供的信息,并將必要但是你沒有提供的其他信息設(shè)為默認(rèn)值填寫進(jìn)去诺凡。而kubectl edit
就可以編輯剛才打開的這個列表东揣。例如践惑,編輯在create
小節(jié)中創(chuàng)建的 pod kubia-manual
。
kubectl edit pod kubia-manual
之后就會彈出系統(tǒng)設(shè)置的默認(rèn)編輯器嘶卧。這時(shí)我們就可以做任意修改尔觉,例如將名稱改為kubia-manual-v2
。首先定位到metadata.name
字段芥吟,然后修改他的值:
apiVersion: v1
kind: Pod
metadata:
creationTimestamp: "2019-07-07T07:31:11Z"
name: kubia-manual # > kubia-manual-v2
namespace: default
resourceVersion: "790349"
selfLink: /api/v1/namespaces/default/pods/kubia-manual
uid: 51eaa1e6-5749-4e79-aec9-12cf2a3e485d
spec:
...
修改完成后輸入:wq
保存侦铜,隨后你會發(fā)現(xiàn), k8s 居然報(bào)錯了
A copy of your changes has been stored to "/tmp/kubectl-edit-vj0ts.yaml"
error: At least one of apiVersion, kind and name was changed
不要著急钟鸵,這個是 k8s 做出的限制钉稍,你無法修改一個運(yùn)行中資源的名稱或類型。那我們就來修改一下他的其他屬性好了棺耍。例如將拉取鏡像的標(biāo)簽指定為latest
贡未。重新edit
配置文件,找到spec烈掠。containers.image
字段羞秤,然后在最后添加:latest
后保存。隨后 k8s 會彈出保存成功左敌,如下:
pod/kubia-manual edited
這時(shí)我們再kubectl describe pod kubia-manual
查看該 pod 的詳情,就可以發(fā)現(xiàn)對應(yīng)的字段已經(jīng)更新了:
Name: kubia-manual
Namespace: default
Priority: 0
Node: worker1/192.168.56.21
Start Time: Sun, 07 Jul 2019 07:31:11 +0000
Labels: <none>
Annotations: <none>
Status: Running
IP: 10.244.1.14
Containers:
kubia:
Container ID: docker://89617ffcc9b1455c514e5129a9b2694c43a2aff9b4c0449d5efc4aea1fe41db6
# 已經(jīng)顯式的應(yīng)用了 latest 標(biāo)簽
Image: luksa/kubia:latest
Image ID: docker-pullable://luksa/kubia@sha256:3f28e304dc0f63dc30f273a4202096f0fa0d08510bd2ee7e1032ce600616de24
Port: 8080/TCP
小節(jié)
kubectl edit <資源類型> <資源名>
可以編輯一個資源的具體配置項(xiàng)俐镐,更詳細(xì)的文檔請參考 k8s 中文網(wǎng) - kubectl edit 矫限。edit
命令在實(shí)際使用中更偏向于人工修改某個配置項(xiàng)來解決問題,例如修改鏡像地址解決拉取不到鏡像的問題佩抹。更常用的編輯命令請參見下一節(jié)kubectl apply
叼风。
kubectl apply 應(yīng)用配置!
上一節(jié)我們知道了一個簡單快捷的編輯配置方法kubectl edit
棍苹,但是如果我們想對資源進(jìn)行大范圍的修改呢无宿?總不能打開配置項(xiàng)一個一個手動修改吧。這時(shí)候就可以用到我們的kubectl apply
命令了枢里∧跫Γ基本用法如下:
kubectl apply -f <新配置文件名.yaml>
kubeclt apply
可以說是edit
命令的升級版,它和edit
最大的區(qū)別就是栏豺,apply
接受一個yaml
配置文件彬碱,而不是打開一個編輯器去修改。k8s 在接受到這個配置文件后奥洼,會根據(jù)metadata
中的元數(shù)據(jù)來查找目標(biāo)資源巷疼,如果沒有的話則直接新建,如果找到的話就依次比對配置文件之間有什么不同點(diǎn)灵奖,然后應(yīng)用不同的配置嚼沿。
這么做的好處有很多估盘,例如你通過kubectl apply -f https://some-network-site/resourse.yaml
命令從一個網(wǎng)站上部署了你的資源,這樣當(dāng)它的管理者更新了這個配置文件后骡尽,你只需要再次執(zhí)行這個命令就可以應(yīng)用更新后的內(nèi)容了遣妥,而且完全不用關(guān)心修改了哪些配置項(xiàng)。
除了修改手段不同以外爆阶,apply
命令的行為和edit
保持一致燥透,你可以訪問 k8s 中文網(wǎng) - kubectl apply 來查看更多用法。
總結(jié)
本本介紹了如何新建create
辨图、刪除delete
和修改edit
, apply
k8s 中的資源班套。閱讀完本文之后,相信你已經(jīng)對 k8s 不再陌生故河,并且在學(xué)習(xí) k8s 的重頭戲 不同資源的用法和特性 時(shí)能起到不小的幫助吱韭。接下來你可以通過 k8s 如何讓你的應(yīng)用活的更久 來了解 k8s 中的重要資源 - 副本控制器ReplicationController
和ReplicaSet
。