[转帖]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 服务学习