[轉帖]k8s 基本使用（下）

k8s 基本使用（下）

https://www.jianshu.com/p/116ce601a60f

 

若是你沒有看過上篇的話，推薦閱讀完 k8s 基本使用（上）後再閱讀本篇內容。

kubectl create 建立資源！

k8s 中的全部東西均可以經過kubectl create命令建立，不管你是想建立一個 pod 仍是一個大型的滾動升級服務deployment，create命令均可以作到。使用create生成一個資源主要有兩種經常使用方法，從yaml配置文件建立 和 簡易建立：

從yaml配置文件建立

若是你想讓 k8s 生成一個和你想象中如出一轍的資源，那你就要充分而詳細的描述這個資源，k8s 就提供了這麼一個方法，你可使用yaml格式建立一個文件，按照 k8s 指定好的結構定義一個對象，而後使用以下方法將該文件傳遞給 k8s。它就能夠按照你的描述進行生成了：

kubectl create -f <配置文件名.yaml>

例如，使用下面的配置文件就能夠建立一個最簡單的 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便可建立

root@master1:~/k8s-yaml# k create -f kubia-manual.yaml pod/kubia-manual created 

若是你的配置文件有問題的話那麼 k8s 就會報錯，以下，錯誤通常都是拼寫致使的，好比下面這個就是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 

這時你可能會問了，這配置文件裏一大堆名字我看不懂啊，不要着急，下一條命令就會解答這個疑惑，可是在此以前，咱們先來看一下更簡單的 簡易建立 模式。

簡易建立

k8s 爲一些經常使用的資源提供了簡易建立的方法，好比說service、namespace、deployment等，這些方法可使用kubectl create <資源類型> <資源名>的方式建立。例如我想建立一個名叫hello-world的命名空間，直接使用下面命令便可：

kubectl create namespace hello-world 

這樣就不用再跟大而全的配置文件打交道了，若是你想了解都有哪些資源能夠快速生成的話，使用kubectl create -h命令查看。

小結

kubectl create能夠經過指定-f <配置文件名.yaml>參數來從一個yaml文件生成資源，也可用使用kubectl create <資源類型> <資源名>來快速生成一個資源。

kubectl explain 解釋配置！

從上一小節中咱們能夠知道，k8s 能夠經過配置文件來生成資源，而爲了儘量詳細的描述資源的模樣，k8s 提供了數量龐大的配置項，那麼有沒有一種方式能夠快速的瞭解到某個配置項的做用呢？有，那就是explain(解釋)命令。

kubectl explain <配置名> 

我們來實踐一下，翻到上一小節裏提到的生成 pod 的配置文件。首先，我想要了解建立 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 

能夠看到，給出的解釋很是詳細，而且每一個解釋的最後都附帶了一條連接，便於更加深刻的進行了解，好了，那我想要了解matedata(元數據)字段都有哪些配置項怎麼辦呢？

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. ... 

又是一排十分詳細的解釋，經過這種方式，咱們能夠了解到每個資源的每個配置項。想了解某個屬性的子屬性，就加個.繼續查。不要說看不懂，我以爲 谷歌翻譯 這種東西已經挺常見了。

kubectl delete 刪除一切！

delete命令的使用很是簡單，以下：

kubectl delete <資源類型> <資源名> 

好比說你想刪除一個名爲kubia-4n2tg的 pod。就能夠這麼寫：

kubectl delete pod kubia-4n2tg 

若是你想刪除全部的 pod，就能夠這麼寫：

kubectl delete pod --all 

若是你想刪除一切！那就這麼寫：

kubectl delete all --all 

注意！執行刪除一切命令沒有二次驗證，全部資源均會被直接刪除，在執行前先考慮下跑路成本。

kubectl edit 修改配置！

若是在平常維護過程當中，由於某些緣由咱們須要變動一些服務的設置該怎麼辦呢？從建立新資源小節咱們能夠了解到，每一個資源都是經過一個yaml配置文件生成的，哪怕是簡易建立的資源，也是 k8s 從一個默認的配置文件建立而來的。

咱們能夠在get命令後附加-o yaml文件查看某個現有資源的配置項。例如，查看 pod kubia-manual的配置項：

kubectl get pod kubia-manual -o yaml 

執行以後就能夠看到一個很長的配置列表，你也能夠試一下本身建立的 pod 的配置項，你會發現一樣很長，這就是由於 k8s 會讀取你提供的信息，並將必要可是你沒有提供的其餘信息設爲默認值填寫進去。而kubectl edit就能夠編輯剛纔打開的這個列表。例如，編輯在create小節中建立的 pod kubia-manual。

kubectl edit pod kubia-manual

以後就會彈出系統設置的默認編輯器。這時咱們就能夠作任意修改，例如將名稱改成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保存，隨後你會發現， k8s 竟然報錯了

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 作出的限制，你沒法修改一個運行中資源的名稱或類型。那咱們就來修改一下他的其餘屬性好了。例如將拉取鏡像的標籤指定爲latest。從新edit配置文件，找到spec。containers.image字段，而後在最後添加:latest後保存。隨後 k8s 會彈出保存成功，以下：

pod/kubia-manual edited

這時咱們再kubectl describe pod kubia-manual查看該 pod 的詳情，就能夠發現對應的字段已經更新了：

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 # 已經顯式的應用了 latest 標籤 Image: luksa/kubia:latest Image ID: docker-pullable://luksa/kubia@sha256:3f28e304dc0f63dc30f273a4202096f0fa0d08510bd2ee7e1032ce600616de24 Port: 8080/TCP 

小節

kubectl edit <資源類型> <資源名> 能夠編輯一個資源的具體配置項，更詳細的文檔請參考 k8s 中文網 - kubectl edit 。edit命令在實際使用中更偏向於人工修改某個配置項來解決問題，例如修改鏡像地址解決拉取不到鏡像的問題。更經常使用的編輯命令請參見下一節kubectl apply。

kubectl apply 應用配置！

上一節咱們知道了一個簡單快捷的編輯配置方法kubectl edit，可是若是咱們想對資源進行大範圍的修改呢？總不能打開配置項一個一個手動修改吧。這時候就能夠用到咱們的kubectl apply命令了。基本用法以下：

kubectl apply -f <新配置文件名.yaml>

kubeclt apply能夠說是edit命令的升級版，它和edit最大的區別就是，apply接受一個yaml配置文件，而不是打開一個編輯器去修改。k8s 在接受到這個配置文件後，會根據metadata中的元數據來查找目標資源，若是沒有的話則直接新建，若是找到的話就依次比對配置文件之間有什麼不一樣點，而後應用不一樣的配置。

這麼作的好處有不少，例如你經過kubectl apply -f https://some-network-site/resourse.yaml命令從一個網站上部署了你的資源，這樣當它的管理者更新了這個配置文件後，你只須要再次執行這個命令就能夠應用更新後的內容了，並且徹底不用關心修改了哪些配置項。

除了修改手段不一樣之外，apply命令的行爲和edit保持一致，你能夠訪問 k8s 中文網 - kubectl apply 來查看更多用法。

總結

本本介紹瞭如何新建create、刪除delete和修改edit, apply k8s 中的資源。閱讀完本文以後，相信你已經對 k8s 再也不陌生，而且在學習 k8s 的重頭戲 不一樣資源的用法和特性 時能起到不小的幫助。接下來你能夠經過 k8s 如何讓你的應用活的更久 來了解 k8s 中的重要資源 - 副本控制器ReplicationController和ReplicaSet。

 

 

4人點贊

 

k8s 服務學習