Kubernetes(K8S)核心概念与常用命令解析-CSDN博客

本文链接：https://blog.csdn.net/weixin_42281402/article/details/106480942

K8S是强大的容器编排系统，主要包括Pod、ReplicaSet/ReplicationController、Namespace、Service和Deployment等资源。Pod是最小运行单元，ReplicaSet保证副本数，Namespace实现资源隔离，Service提供服务发现和负载均衡，Deployment用于应用版本管理。常用命令包括get、describe、create等，理解其内部架构如API Server、Scheduler和Controller Manager有助于更好地使用K8S。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

K8S作为一个容器编排系统，功能非常强大，其概念很多，相应的，也会有很多命令。得益于K8S接口良好的一致性，我们无需特别记忆繁杂的指令，了解概念之后，只需知道一个公式即可掌握绝大多数命令，那就是：
kubuctl + 动作 + 资源类型 + 资源名 + 选项
下面我们分别来看一下什么是“资源”，什么是“动词”。

一、常见的资源

Pod

Pod 是K8S中最基本的单元，在整个应用的生命周期中，Pod可能随时被创建、删除。一个Pod提供一个独立的网络空间，容器的实体运行在Pod 中，一般一个Pod包含一个容器（多个也不是不可以）；而Pod运行于Node 中，一个Node可以有多个Pod。对于运行的容器来说，Pod就像一台宿主机，容器是感受不到区别的。Pod、Node与容器的关系如图所示：
在这里插入图片描述

ReplicaSet/ReplicationController

从字面意思就能看出，ReplicaSet或ReplicationController是负责管理（Pod）副本的，这很适用于微服务中的应用场景。假如原本有一个Pod，现在想水平扩展为三个，则只需对ReplicaSet说，我需要3个Pod副本，剩下的，ReplicaSet会自己完成。同样的，假如原本应该有三个Pod，由于不可预料的原因，挂掉了一个，那么此时ReplicaSet 会知道少了一个Pod，然后自动创建一个新Pod。如图所示：
在这里插入图片描述
ReplicationController可以视作跟ReplicaSet基本一样，在将来可能跟会被废弃。

NameSpace

这个概念很好理解，就是用于区分不同资源的命名空间，与Linux的namespace的概念类似。

Service

我们可以把Service理解为类似于nginx的负载均衡，即Service向外提供一个可访问的地址，后面负载了多个服务：
在这里插入图片描述

正如前文所说，每个Pod有独立的IP，当外部的客户端发起请求时，通过Service暴露的地址，从而得以把请求负载到每一个Pod。

Deployment

这时一个更高层级的概念，Deployment不管理Pod，而是通过管理ReplicaSet来控制Pod的行为：
在这里插入图片描述

在笔者看来，Deployment最主要的作用是用来解决应用版本的升级及回退问题。在不用Deployment的情况下，如果需要将Pod1和Pod2的应用从V1版本升级到V2，为保持服务的不中断，我们可能需要手动新建一个ReplicaSet，然后将Service的负载逐一从V1版本滚动升级为V2；同时在这个过程中，机器上存在双倍数量的Pod，资源消耗量也大增；如果要回退版本呢？可能更麻烦。但我们采用更高级的Deployment，只需要跟Deployment说，版本升级到V2，剩下的工作即会自动完成，无需我们手动干预更底层给的ReplicaSet和Pod。

二、动作

get ：获取某一类资源的整体状态。套用前文的公式，如 kubectl get pod，即返回目前所有的pod：

$ kubectl get pod
NAME                     READY   STATUS    RESTARTS   AGE
kubia-75974f96b5-m2ksh   1/1     Running   0          7h12m
kubia-75974f96b5-n6fqt   1/1     Running   0          7h16m
kubia-75974f96b5-tpkc2   1/1     Running   0          7h16m

decribe：获取某一个具体资源的详细信息，如我想查看名为"kubia-75974f96b5-m2ksh"的pod的详情，同样的，参照公式，则可用命令kubectl describe pod kubia-75974f96b5-m2ksh：

$ kubectl describe pod kubia-75974f96b5-m2ksh
Name:           kubia-75974f96b5-m2ksh
Namespace:      default
Priority:       0
Node:           minikube/192.168.1.3
...

create：用于创建各种资源。比如我们现在有个写好的ReplicationController的demo-rc.yaml文件，我们利用这个文件新建一个ReplicationController资源。由于资源类型已经在yaml文件中指定了，所以上面的公式中的“资源类型”可以去掉，但要指定文件输入，所以应该用命令kubectl create -f rc.yaml,-f选项表示指定文件：

$ kubectl create -f rc.yaml
replicationcontroller/demo created

还有很多其他的动词，如 logs、exec、delete、edit等等，基本上可以套用本文开头提到的公式。万一不知道怎么用，万能的-h将会显示详尽的帮助文档。

三、内部概念

要想用好K8S，理解其基本架构很有必要。我们来看一下K8S的简单架构：
在这里插入图片描述

K8S 客户端：我们命令中用到的kubectl其实就是命令行形式的客户端，作用是把命令发送给Master节点中的API Server，或接收API Server的返回结果。当然也有图形界面的客户端。
Master节点：顾名思义，是主节点，用来控制其他从属节点（Worker Node）。
Worker节点：即真正“干活的”，应用实际是部署在Worker节点；Worker和Master节点在不在同一台物理机器上并不重要。
API Server：这是K8S通信的核心。其他所有组件之间都不会直接通信，而是全部通过API Server，通信方式是HTTP 的REST形式。
Scheduler：调度器，负责检测硬件资源，按照一定的策略，做出Pod应该调度到哪一个节点的决策，调度器不参与Pod在Node中实际的创建，仅仅是”做出指示“。
Controller Manager：负责管理Pod，比如故障检测、自动恢复、水平扩展等；调度器做出的决定，也是由Controller Manager执行。
ectd：一个Linux的分布式数据库，K8S所有的信息均储存于此。
kubelet：负责Worker节点上众多事务，如监控Pod，启动容器、报告状态等，可以说是Worker节点的管家。
Container Runtime：很好理解，真正运行容器的，目前一般都是Docker。
proxy：与Service的负载均衡有关。