如果你没有看过上篇的话，推荐阅读完 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。

作者：HoPGoldy
链接：https://www.jianshu.com/p/116ce601a60f
来源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。