软件测试 | K8S 管理命令
接下来讲解一下 K8S 的标准命令行 kubectl 的使用。 在 K8S 集群安装的章节中已经介绍了如何获取 kubeconfig 文件并复制到对应的位置。 这里要注意如果你希望让某个用户拥有操作 kubectl 的权限，就 需要将 kubeconfig 文件拷贝到该用户的家目录下。 否则该用户是无法与 K8S 建立通信的。 讲解 kubectl 命令之前需要先介绍一下 K8S 中对于资源的概念。 在 K8S 中一切皆资源， 之前介绍过的 POD 就是一种资源，同样 job 也是一种资源。 你可以理解为在 K8S 中资源是用来描述容器的行为的， 所有的资源都是在某个维度控制如何运行容器。 比如 POD 描述的是容器之间如何连接在一起， config map 是用来将外部的配置文件挂载到容器中为应用程序提供配置管理的，后面要讲解的 Service 是用来 接管容器网络的，Role，RoleBinding 和 Service account 是用来控制容器的角色和权限的。 一切资源对 象都是为了提供更加强大的容器编排能力而诞生的，所以在 K8S 中一切皆资源－－重要的事情需要重 复声明一遍。 所以对于 kubectl 命令来说它也就有了固定的模式。
比如需要查看当前集群中所有节点的时候运行的命令如下：
在这个命令中 get 就是动作而 node 就是资源。那再看另一个命令：
这个命令是删除在名称空间 test 中的一个名字叫 jenkins 的 POD。 你可以看到它依然遵循刚才的命令 模式。 delete 是删除这个动作而 POD 是资源对象，只不过这里需要指定额外的 options， 第一个是指 定 POD 的名字来表明到底要删除哪一个 POD。 -n 这个参数表明这个 POD 是属于哪个名称空间的， 这里接触到了 K8S 的另一个资源－－名称空间（namespace）。 名称空间是 K8S 的一个逻辑概念，它 并不具备实体，你看不见摸不着，它主要的作用是为其他资源进行分类并方便管理。 可以把名称空间类 比为文件夹一样的东西，而 K8S 中大部分的资源类型都是一个个的文件，文件是放置到某个文件夹下 的。 这样就拥有了更高维度的管理能力。 比如可以只查看某个名称空间下的 POD。 比如 K8S 中所有 的关键服务都是放到 kube-system 这个名称空间下的，一般这里面的 POD 直接影响着整个集群的运行 状态。 在集群出现故障的时候经常会去看这个名称空间下的 POD 是否都运行正常。这个时候使用的命 令就是：
同时名称空间也可以有更强的控制能力， 比如可以给某个名称空间添加资源配额， 这又涉及到了 K8S 的资源管理模块了。 在这里可以不用深入的了解，只需要知道可以为某个名称空间申请特定数量的资源 （CPU, 内存，GPU）这样 K8S 会为这个名称空间预留相应数量的资源，保证这些资源不会被其他服务 抢占。 同时也可以限制某个名称空间资源的最大用量， 这样保证这个名称空间内的所有服务所使用的资源总量不超过某个值。 一般来说这种资源配额的机制常常用来实现资源的管理和超卖能力。事实上只 有特定的一些资源类型是可以不用放到名称空间内的， 比如 clusterrole，这是集群级别的角色对象，作 用域更大不限于某个名称空间，所以不依附于某个名称空间。而与之对应的 role 就属于某个名称空间内 生效的角色。回到当才的命令上， 如果在命令行里增加一个额外的 options -o wide 你会发现不一样的 效果。
可以看到增加了-o wide 后 输出的信息变多了。 -o 也是一个常用的 options，代表着 output， 作用是 针对输出的信息进行格式化。 可以看到命令依然保持着 kubectl {动作} {资源} {options}这个特定的模 式。所以 K8S 的命令行其实非常容易掌握， 只要理解了这样一个模式就可以在不看任何文档的情况下 完成大部分的日常工作，不论你面对的是哪种资源类型。 几个常用的动作：
get：查询某个资源列表。
delete：删除某个资源。
edit：实时编辑某个资源的配置文件，这个动作非常有用，用户可以使用它动态编辑一个 POD 的配 置文件，它会为用户提供一个 vi 编辑窗口，当你修改并保存后，k8s 会根据最新的配置更新这个 POD
describe：查看某个资源对象的详情。
logs： 查看某个 POD 中的日志，专门针对 POD，所以命令中可以不带资源类型。eg. kubectl logs -f {Pod 名称} -c {容器名称} 如果不使用-c 则会查看第一个容器的日志
exec: 让某个 POD 中的容器执行特定的命令。 一般使用这个指定登录到某个容器中。eg. kubectl exec -it {Pod 名称} -c {容器名称} bash t
aint: 给某个 Node 增加或者删除污点。 eg. kubectl taint nodes k8s http://noderole.kubernetes.io/master:NoSchedule
create -f：根据某个配置文件创建资源对象。 eg. kubectl create -f {文件路径}
apply -f： 根据某个配置文件更新资源对象。 eg. kubectl apply -f {文件路径}
delete -f: 根据某个配置文件删除资源对象。 eg. kubectl delete -f {文件路径}
上面列举的命令基本上可以满足在工作中 99%的场景了，其他还有类似 label，cp 等等，不过都不太常 用所以我就不详细介绍了。这里强调一下 kubectl create/apply/delete -f {文件路径} 这个命令。 它不再是操作某个资源对象的而是操作某一组保存在 yaml 或 json 格式的文件下的多个资源的。 这也是日常最常用的创建和删除资源的方式，一般习惯把所有的配置都保存在这样的一个或多个文件里 并对他们进行管理。比如在之前的章节里提到的定时任务：
把上述配置文件保存为一个 yaml 文件，然后运行 kubectl create -f {文件路径} ， 这样就可以立 刻创建出这个 CronJob 了。 而如果修改了这个配置文件后比如修改了这个定时任务的 cron 表达式，希 望他在别的时间点触发任务，那么也只需要运行 kubectl apply -f {文件路径} 即可。 K8S 会为自 动的对比当前资源和更新的请求之间在配置上不同的地方并进行更新。 这是 K8S 声明式 API 的强大之 处。用户只需要在配置文件中声明期望的样子，K8S 会自动读取并保证用户期望的运行方式一定会发 生。 接下来再看一下几个常用的 options，首先就是之前看到过的-o，用来对输出信息进行格式化。它 有很多的值但最常用的只有 3 种，分别是：json|yaml|wide 。 其中 wide 已经看过了它会输出很多额外 的信息，包括 POD 的 ip 地址和 POD 调度到了哪一个节点上。 而 json 和 yaml 则会保证你查看的资 源对象信息可以用对应格式打印在屏幕上。 比如要查看某个 POD 的信息：
通过这样的命令就把查看到的信息以 yaml 格式打印在屏幕上了， 如果需要可以通过 > 符号把内容保 存到标准 yaml 文件中待后续处理， 实际上一些测试或运维工具就是这么做的。 另外再介绍一个常用 的 options 就是--all-namespaces。 知道大多数的资源类型都是属于某个名称空间的，但是有些时候在操 作对象的时候希望能够操作整个集群所有名称空间下的资源。 这个时候就轮到 --all-namespaces 出场 了。
最后一个常用的 options 是 -l， 它是一种标签（label）选择器。 这里又涉及到了 K8S 中的标签管理 了，这是 K8S 中一种主要的调度策略。 通过在特定的资源对象上打上对应的 label，后续可以通过 label 来进行管理和调度。 比如给某个 Node 上打了一个 ssd=true 的标签，代表着在这个 Node 上存在 SSD 磁盘。 而在创建 POD 的时候可以显示的使用 nodeSelector 来指定我的 POD 必须调度到打了 ssd 标签的 Node 上。 这是 K8S 的一种调度策略。在 K8S 中任何对象都可以打上 label，包括 POD。而 其他资源对象就可以通过 label 找到对应的 pod 集合。 比如后面要讲的 Service 就是通过指定对应的 label 来觉得都接管哪些 POD 的网络并做负载均衡策略。同样的命令行中也可以通过 -l 来指定只查询 拥有对应的 label 的资源对象：
搜索微信公众号：TestingStudio 霍格沃兹的干货都很硬核
社区：ceshiren.com 微信：ceshiren2023 2022-08-29 加入
微信公众号：霍格沃兹测试开发 提供性能测试、自动化测试、测试开发等资料、实事更新一线互联网大厂测试岗位内推需求，共享测试行业动态及资讯，更可零距离接触众多业内大佬
评论