K8S 资源对象简介及 kubectl 命令 | 学习笔记

开发者学堂课程【Kubernetes 入门实战演练2020版：K8S 资源对象简介及 kubectl 命令】学习笔记，与课程紧密连接，让用户快速学习知识。

课程地址：https://developer.aliyun.com/learning/course/656/detail/10863

K8S 资源对象简介及 kubectl 命令

内容介绍：

一、k8s 资源管理概念

二、K8s 命令使用

三、k8s 的牛鼻子—API（重点）

一、k8s 资源管理概念

（一）k8s 的设计理念——分层架构

http://docs.kubernetes.org.cn/251.html

此图需结合上节课 Kubeadm 初始化流程简介及 dashboard v2.2.2-rc6 部署的知识进行理解，此图分为几个层次，底层包括供应商和一些接口或者可以理解为给容器提供接口的规范，

以 CRI（Container Runtime Interface） 为例，可以使用 Docker，Podman，PUSH，等容器运行技术来创建容器，容器网络接口 CNI 在容器中通过四组机上任网或者跨四组机访问容器，在 pod 中分装 CNI 接口可以实现一个规范，通过符合网络规范的插件来实现，具体之后细讲。

接下来讲关于容器存储接口 CSI，定义容器调用存储，需符合规范。镜像仓库又称为 Harbor ，云供应商主要供应云比较多，国外占大多数，比如 AWS ，适用于 Kubemetes  的兼容性,身份供应商或者用于第三方服务商的身份验证，云服务商在国内常见的有阿里云，华为云等，它们会进行对 Kubemetes 二次开发，直接提供 Kubemetes 的一系列服务进行运行，较为方便。

底层均为硬件，或者是一种虚拟化环境，如阿里云，一般会有虚拟化的管理端和虚拟化的客户端等进行管理。它拥有的底层网络在使用供应端无法勘察。在理解这些的基础上，可深入到 Kubemetes 的核心层。

核心层： Kubemetes 最核心的功能是对外提供提供 API 构建

高层的应用，对内提供插件式应用执行环境。

通过命令或者带式报到与访问 API 一致，带式报到的登录：

root@kubeadm-master 1:~#

root@kubeadm-master 1:~#

root@kubeadm-master 1:~#

root@kubeadm-master 1:~#

root@kubeadm-master 1:~#  kubectʅ  get pod^C

root@kubeadm-master 1:~#  kubectʅ  get secret

NAME                 TYPE                               DATA    AGE

defauʅt-token-9czqd       kubernetes . io/service-account-token    3        2d17h

root@kubeadm-master 1:~#kubectʅ  get secret-A

执行得下图：

因此得出结论可知，带式报到通过 API 进行操作。

应用层：部署（无状态应用、有状态应用、批处理任务、集群应

用等）和路由（服务发现、 DNS 解析等）。

无状态应用没有角色关系，开一个或者两个影响不大，但是有状态应用不同，在对它们进行管理时，它们的主机有角色状态，存在依赖关系。

一般无状态应用居多常见较为简单。有状态应用、批处理任务、集群任务管理比较繁琐，对数据的管理，对容器的数据备份与恢复比虚拟机物理机复杂。服务发现推送和 DNS 解析做内部的系统解析。

管理层：

系统设置（如基础设施、容器和网络的度量），自动化（如自动扩展、动态 Provision 等）以及策略管理 （RBAC、Quota、PSP、NetworkPolicy 等）。

接口层： kubectl 命令行工具、客户端 SDK 以及集群联邦。

生态系统：在接口层之上的庞大容器集群管理调度的生态系统，可以划分为两个范畴：

1.Kubemetes 外部：日志、监控、配置管理、 CI、CD、Workflow、

FaaS、OTS 应用、ChatOps等。

2.Kubemetes 内部： CRI、CNI、CVI、 镜像仓库、 Cloud Provider、

集群自身的配置和管理等。

顶层的云原生生态系统是类似于 CNCF 基金会的整个全景图，在全景图中对每一层都有相关的定义或者有相关的组件能实现。具体到组件：要确定公司业务或者个人需求，第二确定公司开发擅长哪方面，选择擅长的方面。

（二） k8s 的设计理念—API设计原则

API设计原则：对于云计算系统，系统API实际上处于系统设计的统领地位，k8s集群系统每支持一项新功能，引入引入一项新技术，一定会新引入对应的API对象，支持对该功能的管理操作，理解掌握的 API ，就好比抓住了牛鼻子， k8s 系统 API 的设计有以下几条原则：

①所有 API 应该是声明式的。声明式的操作，相对于命令式操作，对于重复操作的效果是稳定的，这对于容易出现数据丢失或重复的分布式环境来说很重要的。

另外，声明式操作更容易被用户使用，可以使系统向用户隐藏实现的细节，同时，也保留系统未来持续优化的可能性，此外，声明式的 API ，同事隐含了所有的 API对象都是名词性质的，列如： Serivce、Volume 这些 API 都是名词，描述了用户所期望得到的一个目标分布式对象。（命名式：例如写脚本做数据的备份，首先 cd 路径，然后进行打包或者 mysqldump x x 。声明式：创建 pod 或者数据备份，内部自动完成，只需编写操作对象和数目）

② API 对象是彼此互补而且可组合的。实际上是鼓励 API 对象尽量实现面向对象设计时的要求，即“高内聚，松耦合”，对业务相关的概念有一个合适的分解，提高分解出来的对象的可重用性。 k8s 的分布式系统管理平台（或一种业务系统），业务仅负责调度和管理容器服务。

③高层 API 以操作意图为基础设计。要设计好API与面向对象的方法设计好应用系统有想通的地方，高层设计一定是从业务出发，而不是过早从技术实现出发。因此，针对 k8s 的高层 API 设计，一定以 k8s    的业务为基础出发，也就是以系统调度管理容器的操作意图为基础设计。

④底层 API 根据高层 API的控制需要设计。设计实现底层 API 的目的，为了被高层 API 使用，考虑减少冗余，提高重用性的目的，底层API的设计也要以需求为基础，要尽量抵抗受技术实现影响的诱惑。

⑤尽量避免简单封装，不要有在外部 API无法显示知道的内部隐藏机制。简单的封装，实际没有提供新的功能，反而增加了对所封装API的依赖性，内部隐藏的机制也是非常不利于系统维护的设计方式，例如 PetSet 和 ReplicaSet ， 本来就是两种 Pod 集合，那么 k8s 就用不同 API 对象来定义它们，不是只用同一个 ReplicaSet ，内部通过特殊的算法再来区分这个 ReplicaSet 是有状态的还是无状态。

⑥API操作复杂度与对象数量成正比。从系统性能角度考虑，要保证整个系统随着系统规模的扩大，性能不会迅速变慢到无法使用，则最低的限定是 API 的操作复杂度不能超过 O(N)，N 是对象的数量，否则系统就不具备水平伸缩性。

⑦ API对象状态不能依赖于网络连接状态。在分布式环境下，网络连接断开是经常发生的事，因此要保证 API 对象状态能应对网络的不稳定， API 对象的状态不能依赖于网络的连接状态。（跨主机是需要网络的，在 master 中有一个特殊端口，如下图）

⑧尽量避免让操作机制依赖于全局状态，因为在分布式系统中要保证全局状态的同步是非常困难的。（ pod 在全局管理中由于网络会产生延迟，操作量大，异常 pod 不会影响其他正常的 pod。）

AIP 对象——k8s 集群中的管理操作单元

通过某个 IP 地址去访问 API ，关键在于 API 的对象，明确告诉k8s对象及数量。

如下图：

通常需要操作的 API 种类：

这种情况取决于你编写的文件：

Secret  一般通过某些算法用于账户的信息或者公司文件的加密，并不是所有情况都使用， ConfigMap 一种文件的配置方式，更方便的为 pod 提供配置，一个 ConfigMap 可以配置多个 pod 。

二、k8s 命令使用

Kubectl 是一个命令行接口，用于对 Kubemetes 集群运行命令。Kubectl 在 SHOME/.Kube 目录中寻找一个名为 config 的文件，你可以通过设置环境变量 KUBECONFIG 或设置—— kubeconfig 参数指定其他的 kubeconfig 文件。(一定要在当前目录中建立一个文件，文件配置必须正确，否则无法执行，文件会指定认证信息包括访问的 IP 地址等，认证信息正确可以改变 IP 等，若认证信息挂错，则不可以更改 IP 等信息。)

命令种类如下：

基础命令：对 k8s 中的 pod 或者 k8s 中资源对象的增删改查。其中包括创建（标准输入的方式创建文件，如何创建即 kubectl create -f ./pod.json 来创建，通过 json 来输出，如图：）

-f：指定一个文件名或者是路径来创建一个或者一个 url ，即文件不在本地，它可以帮助你下载然后进行创建，之前讲到创建 flannel 中有一个示例：

For Kubemetes v1.7 + kubectl apply -f http://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml 这个文件可以放到互联网，只是能被当前 kubectl 访问就可以， kubectl 类似于亚模样，kubectl 也可以下载文件帮助你创建，通常是 -f 来指定文件。可以创建如上图的种类文件。

这些命令一般不通过 kubectl 直接创建，通过 yaml 文件 + kubectl 文件进行创建，直接输入过程繁琐。

通常把被创建的文件放在外门文件中，以 namespace 为例直接输入， crate a namespace with the specified name 或者通过标称终端来进行输入： kubectl create namespace 名称—— help（查看帮助信息），显示 crate a namespace with the specified name  ，显示提示信息，通常以 -f 的形式居于文件的形式创建，若要通过命令行来进行创建，

如下：

root@kubeadm-master1: ~# kubectl  create namespace my- namespace ^C

root@kubeadm-master1: ~# kubectl  get namespace

NAME                  STATUS   AGE

Default                 Active    2d18h

Kube-node-lease         Active    2d18h

Kube-public             Active    2d18h

Kube-system            Active    2d18h

Kubernetes-dashboard    Active    2d16h

root@kubeadm-master1: ~# kubectl  create namespace my- namespace

namespace/my- namespace created

root@kubeadm-master1: ~# kubectl  get namespace

NAME                  STATUS   AGE

Default                 Active    2d18h

Kube-node-lease         Active    2d18h

Kube-public             Active    2d18h

Kube-system            Active    2d18h

Kubernetes-dashboard    Active    2d16h

my- namespace         Active     2s

公司中的 k8s 集群中会进行各种业务，这些业务进行创建时利用namespace 进行隔离各个业务的 pod ，使他们相互可见。假设存在一个 Linux39 项目，其中存在多种服务， APP1、APP2、APP3、APP4 为 Linux39 中的服务，通常一个项目存在20到30个小服务，至少保证一个服务一个 pod ，为保证服务的性能一个服务可能需要多个 pod ，其他项目同理。

逻辑上它们互不干扰，各自执行，物理上是均在 kubernetes 集群中工作。

为了实现资源的隔离，这个 kubernetes 集群可以是多个物理机，不同项目的硬件在不同的物理机上进行工作，物理机使用在同一套 kubernetes master 管理端。

运维通过命令或者api  等调用 kubernetes master 对 pod 进行增删改查（如图）

若想删除文件则编码：root@kubeadm-master1: ~# kubectl delete --help , 与 create相类似，执行给出示例，如何删除上文示例 namespace ，root@kubeadm-master1: ~# kubectl delete namespace my-namespace

root@kubeadm-master1: ~# kubectl  get namespace

NAME                  STATUS   AGE

Default                 Active    2d18h

Kube-node-lease         Active    2d18h

Kube-public             Active    2d18h

Kube-system            Active    2d18h

Kubernetes-dashboard    Active    2d16h

编辑（edit）的用法：

root@kubeadm-master1: ~# kubectl  edit  net-test1-5fcc69db59-f7rgf

error: the server doesn’t have a resource type “net-test1-5fcc69db59-f7rgf”

root@kubeadm-master1: ~# kubectl  edit--help

root@kubeadm-master 1:~#kubectl   get service

NAME              TYPE    CLUSTER-IP   EXTERNAL-IP  PORT(S)   AGE

kubernetes             ClusterIP    192.168.0.1              443/TCP    2d18h

magedu-nginx-service    NodePort   192.168.12.18          80:30004/TCP  2d15h

magedu-tomcat-service    NodePort   192.168.2.183            80:31061/TCP  2d15h

root@kubeadm-master 1:~#kubectl  edit  magedu-nginx-service

error: the server doesn't have a resource type "magedu-nginx-serque"

root@kubeadm-master 1:~#kubectl  edit  service magedu-nginx-service

三、k8s 的牛鼻子—API（重点）

Get就是查看资源的某些信息：

root@kubeadm-master 1:~#kubectl   get--help执行命令可查看当前所有信息，

此状态下可以出现特殊选项:

[（-o|--output=）json|yaml|wide|custom-columns=...|custom-columns-file=...|

go-template-file=...|jsonpath=...|jsonpath-file=...|]

(TYPE[.VERSION][.GROUP][NAME|-llabel]|TYPE[.VERSION][.GROUP]/NAME...)[flags]

[options]

举例：

上图是json模式下执行的命令。

describe 用于 pod 或者 service 没有创建不成功的状态下，不成功一般是由于编码错误， pod 的外部存储没有提前准备好，则无法创建成功，包括镜像无法拉取，没有资源对象等等原因都会使 pod 无法启用。

若要确定 pod 无法启用的原因则需：

root@kubeadm-master 1:~#kubectl describe pod/service (describe后输入要查看的资源对象)若 pod 是 default 则查找时不加 -n 若没有则需加 -n 用来指定 pod 所在的 service 。Events 指事件，若 pod 没有执行成功，事件通常会出现提示。若在 describe 中未发现异常，则需到宿主机查看详细的信息。到 none1 ，或 none2 的服务器中看日志的最后会比

Describe 更详细

具体步骤为：

1、kubectl  describe pod nginx-deployment-66fc88798-9x28m -n default

2、到宿主机看系统日志。（更详细）

root@kubeadm-master1: ~# kubectl  describe namespace  kubernetes-dashboard

Name:        kubernetes -dashboard

Labels:      

Annotations :  kubectl. kubernetes . io/last-applied- configuration :

(“apiVerision”:“v1”,“kind”:"Namespace”,“metadata”:{“ annotations ":{},"name":" kubernetes -dashboard”}}

Status:       Active

No  resource   quota.

No  LimitRange  resource.

root@kubeadm-master 1:~#kubectl  get  service

NAME                 TYPE     CLUSTER-IP  EXTERNAL-IP  PORT(S)  AGE

Kubernetes           clusterIP    192.168.0.1        443/TCP  2d18h

Magedu-nginx-service  nodeport  192.168.12.18    80:30004/TCP 2d16h

Magedu-tomcat-service nodeport  192.168.2.183    80:31061/TCP 2d15h

root@kubeadm-master1: ~# kubectl  describe service

上图为 service 的具体信息。 Logs 的作用是查看日志。假设需要查看日志，root@kubeadm-master1: ~# kubectl  logs，执行显示日志，可具体查看，查找问题。

Exec 类似于进入指定 pod 执行命令，可进入当前k8s 的所有 pod 中。

如图，可进行检查异常部分。 scale 作用是伸缩，在之后的课程进行详细讲解。Explain 是对资源命令的介绍和使用方法的说明。

图中的 Explain 显示当前 kubectl 版本的 API ，如图的pod 命名为 v1 ， pod .APIVersion 用 “.’’隔开执行显示 v1 ，或者查看其他信息。

可以使 pod 指定运行，设定 hostname 定义值。 Deployment （控制器）所要编写的较为主要，如下：

root@kubeadm-master 1:~#kubectl  explain deployment

KIND:      Deployment

VERSION:  app/v1

DESCRIPTION :

Deployment  enables  declarative  updates for Pods and Replica Sets.

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/commonity/contributors/devel/sig-architecture/api-conventions.md #resources

kind

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   <0bject>

Standard object metadata.

Spec       <0bject>

Specification  of the desired behavior of the  Deployment .

Status      <0bject>

Most recently observed status of the  Deployment .

root@kubeadm-master 1:~#kubectl explain  deployment .

在其中定义参数容器 （container） 要考虑其镜像如何定义，找到 container 的 image 值。

镜像编写：

创建 docker 镜像并将其推送到仓库，然后在 kubernetes pod 中引用它。容器的 image 属性支持与 docker命令相同的语法，包括私有仓库和标签。

配置命令中的 Label: 给指定 node 标记 label，实现亲 pod 与 node 亲和性，root@kubeadm-master 1:~#kubectl label--help执行后会说明如何编写，给资源对象打标记。执行如图：

要查看 label node ，先输入 root@kubeadm-master 1:~#kubectl  get nodes 查找 nodes 节点，具体查看某标签则输入 root@kubeadm-master 1:~#kubectl get nodes +某节点是名称执行命令进行查看。

要查看 label 的 node 的节点通过 root@kubeadm-master 1:~#kubectl describe 某节点是名称。

若要打标签： kubectl label node 192.168.7.110 project= Linux36 node /192.168.7.110 labeled ,通过此种方式把 pod 创建在只有这个名称的主机上。

如图所示：

编写root@kubeadm-master 1:~#kubectl label node 节点名称=Linux39再次

describe node 执行命令后显示 group=Linux39。apply 的功能与 create 相似，甚至替代 create ，apply 优于 create 的方面是拥有动态配置的功能，动态配置即创建完成资源后，若想修改资源， apply 可直接修改，支持对yaml文件多次修改和动态生效，修改完成之后重新执行 kubectl  apply -f file.tml， 文件中变化的地方会重新生效 比如做代码升级， image 值会发生改变，可能由 v1 变为 v2 ，v2变为 v3 等等， apply 支持回滚，历史版本记录。

create ：

单次创建资源，后期如果修改了 yaml 文件想生效，那么得删除之前的资源再重新 create kubectl delete -f file.yml,  改 yaml 文件。若更改完再删除，会出现比如 service 或者 pod 的名称更改，无法找到之前名称。