当前位置：首页 > news >正文

【容器】资源平台初探 - K8s核心资源全解析：从Pod到StatefulSet

news 2025/7/16 1:42:31

一、pod

1、什么是pod

2、pod的上下文环境怎么理解？

二、Namespace & ResourceQuota

1、命名空间

2、ResourceQuota

三、Replication controller/ReplicaSet

1、replication controller是什么？

四、Service

1、service是什么？

2、service的代理

五、Endpoint

六、Ingress / Ingress Controller

七、Label / Selector

八、Configmap / Secret

九、Deployment

十、DaemonSet

十一、PV / PVC

1、PV

2、PVC

十二、StorageClass

十三、StatefulSet

开始本章内容之前，先讲解一下k8s对资源的定义：k8s将所有的内容都抽象为资源(例如：pod、service等)，在k8s中运行的是对已经定义的资源的实例化实体(例如一个提供后端java服务的pod)，所有内容均通过YAML/JSON文件描述。下面对k8s中的常用资源做一个简单的简介。

一、pod

1、什么是pod

K8s最基本的管理调度单元，逻辑上相当于一组共享上下文环境的托管应用。Pod模型在容器环境里表示为指定应用的逻辑主机。Pod可以包含一个或多个紧耦合的应用容器。

2、pod的上下文环境怎么理解？

pod的上下文环境可以理解为多个Linux namespace的连接体，包括：

1) PID namespace(pod里的应用可以感知彼此的进程)

2) Network namespace(pod里的应用可以同一IP和端口空间)

3) IPC namespace(pod里的应用可以用SystemV IPC 信号量、消息队列和共享内存，POSIX信息队列)

4) UTS namespace(pod里的应用可以共享主机名)

pod的生命周期是相对短暂的，pod在node上被部署管理，直到被终止删除。当node节点无响应时，node上的pod将被删除，在node上的pod不会被迁移到其他node上，而是通过replicationSet被其它node上的pod所取代。

但是在生产环境中，一般一个pod只部署一个服务，方便管理。

二、Namespace & ResourceQuota

1、命名空间

1）namespace是k8s集群中的虚拟化集群。在一个k8s集群中可以拥有多个命名空间，他们在逻辑上彼此隔离。

2）大多数的k8s集群会有一个叫default的默认namespace，实际上k8s会有三个：

default：用户的service和app会默认创建在这个空间；

kube-system：k8s系统组件使用；

kube-public：公共资源使用，但实际上现在并不常用。

2、ResourceQuota

1) 按类型限制命名空间下所创建对象的数量

2) 限制所消耗计算资源的总量

三、Replication controller/ReplicaSet

1、replication controller是什么？

1) replication controller是pod的复制抽象，用于解决pod的扩容缩容问题。通常，分布式应用为了性能或高可用性的考虑，需要复制多分资源，并且根据负载情况动态伸缩。

2) 通过replicaitonController，我们可以指定一个应用需要几份复制，k8s将为每份复制创建一个pod，并且保证实际运行pod数量总是跟复制数量相等，当某一个pod宕机时，自动创建新的pod来替换。

注：最新版本的k8s已经用replicaSet来代替replicationController，使用方式没有改变，只是增加了支持集合式的selector。

Selector:

matchLabels：

Tier：frontend

matchExpresions：

-{key: tier, operator:In, values:[frontend]}

四、Service

1、service是什么？

Service：是pod的路由代理抽象，用于解决pod之间的服务发现问题。因为pod的运行状态可动态变化(比如切换机器了、缩容过程中被终止了等)，所以访问端不能以写死IP的方式去访问该pod提供的服务。service的引入旨在保证pod的动态变化对访问端保持透明，访问端只需要知道service的地址，由service来提供代理。

2、service的代理

Kube-proxy从API Server获取服务及端点的对象状态。每个服务都会在本地节点打开一个端口。任何访问该端口的连接都会被代理到后端pod的相应端口上。

五、Endpoint

K8s会根据service关联到pod的PodIP信息，组合成endpoint(PODIP + PODPort),若service定义中没有selector字段，service被创建时，也不会自动创建endpoint。

六、Ingress / Ingress Controller

1、Ingress

Service是后端真实服务的抽象，一个Service可以代表多个相同的后端服务。

Ingress是反向代理规则，用来规定HTTP/S请求应该被转发到哪个Service上，比如根据请求中不同的Host和url路径让请求落到不同的Sevice上。

2、Ingress Controller

Ingress Controller就是一个反向代理程序，它负责解析Ingress的反向代理规则，如果Ingress有增删改的变动，所有的Ingress Controller都会及时更新自己相应的转发规则，当Ingress Controller收到请求后就会根据这些规则将请求转发到对应的Service。

七、Label / Selector

service和replicationController是建立在pod之上的抽象，那么它们如何跟pod联系起来呢？

这里使用了label的概念，label很好理解，就是为pod加上可用于搜索关联的一组key/value标签，而service和replicationController正是通过label selector机制来和pod关联的。

比如：现在有三个的pod的label为“app = backend”，创建service和replicationController时可以指定同样的label：“app = backend”，这样就将他们就与这三个pod关联起来了。当有其他frontend pod访问该service时，自动会转发到其中一个backend pod中。

八、Configmap / Secret

K8s集群中的应用使用configmap资源或者Secret资源管理配置文件。Configmap资源主要管理通用配置文件，Secret资源解决了密码、token、密钥等敏感数据的配置问题。

Configmap使用方式：

1）设置环境变量的值

2）在容器里设置命令行参数

3）在数据卷里面创建config文件(volume)

Secret使用方式：

1）以Volume方式

2）以环境变量方式

九、Deployment

deployment是构建于ReplicaSet资源之上，主要管理无状态应用。

1）deployment借助ReplicaSet管理pod资源，其大部分管理操作于ReplicaSet相同。

2）相比ReplicaSet具有的高级功能，主要为自动滚动更新以及回滚的功能。

十、DaemonSet

在每个Worker Node上都创建相同的POD

与deployment的不同之处：daemonSet每个node上最多只能运行一个副本；deployment部署的pod分布在各个node上，每个node都可能运行好几个副本。

十一、PV / PVC

1、PV

PV是集群中已由管理员配置的存储(网络、本地)。集群中的资源就像一个节点是一个集群资源。PV是诸如卷之类的卷插件，但是具有独立于使用PV的任何单个pod的生命周期。

2、PVC

PVC是用户存储的请求。它类似于pod。Pod消耗节点资源，PVC消耗存储资源。pod可以请求特定级别的资源(CPU和内存)。权限要求可以请求特定的大小和访问模式。

十二、StorageClass

K8s集群管理员通过提供不同的存储类，可以满足用户不同的服务质量级别、备份策略和任意策略要求的存储需求。动态存储卷供应使用StorageClass进行实现，其允许存储卷按需被创建。如果没有动态存储供应，k8s集群的管理员将不得不通过手工的方式创建新的存储卷。K8s将能够按照用户的需要，自动创建其需要的存储。