K8S概念理解（一）

深绯

已于 2025-07-20 16:31:51 修改

阅读量794

点赞数 22

CC 4.0 BY-SA版权

文章标签： kubernetes 容器云原生

于 2025-07-06 22:03:43 首次发布

本文链接：https://blog.youkuaiyun.com/sf5191/article/details/147806826

K8S理解（一）

本篇会优先讲述k8s的概念k8s集权的核心组件，并且优先讲解部署一个springboot会用到的k8s对象。下一篇会在讲解后续的存储，配置等部分示例截图取自上一篇博客尝试VMWare部署k8s集群并部署一个springboot应用。简单速通K8S

概念

k8s是一个开源的容器编排平台。说到容器编排，很多人会想到了docker-compose。确实docker-compose本身只针对与单主机的容器编排。而k8s是针对管理多主机上的容器。所以K8S通常伴随着容器化应用的集群环境的使用。

为什么要使用K8S

自我修复
滚动更新与回滚
弹性扩缩容
服务发现与负载均衡
存储编排
配置与密钥管理
批量执行

Node（节点）

k8s的工作单元，负责运行容器话应用。分为Master Node（主节点/控制平面节点），Worker Node(工作节点)，节点可以是物理机也可以是虚拟机
Master Node：管理集权状态，调度pod、处理Api请求。master worker 控制pod运行再哪个woker node 上。提供集群的入口（API Server）和配置存储（etcd）。
Worker Node：实际运行pod的机器，接收来自master worker的指令管理pod的生命周期。

Pod

pod是可以在 Kubernetes 中创建和管理的、最小的可部署的计算调度单元，运行在工作节点上。一个pod可以是一组（一个或多个）容器。由于pod是k8s最小的调度单元，pod扩缩容等也是针对pod来进行，所以一个pod里面包含了多个处理业务的容器就会导致扩缩容会多个业务的容器同时扩容。所以一般会设计成一个pod一个容器或者说一个pod一个处理业务的容器，包含多个容器大部分情况下可能是一个处理业务容器+一个非业务容器比如专门做日志收集的容器。

K8S集群核心组件

以下是一个k8s集群，下面将介绍以下k8s集群的核心组件（以下说明大部分来着官方文档）

在这里插入图片描述

master节点

kube api server：集群的“入口”，提供 REST API，所有资源操作的唯一访问点
etcd：分布式键值数据库，存储集群的所有状态和配置数据（如 Pod、Node、Secret 等）
kube-scheduler：负责调度 Pod 到合适的 Worker 节点（基于资源需求、亲和性等策略）
kube-controller-manager：运行各种控制器（如 Deployment、Node、ReplicaSet 控制器），确保集群状态符合预期

woker节点

kubelet：节点上的“代理”，负责与 Master 通信，管理 Pod 生命周期（创建、销毁、监控）
kube-proxy：维护节点上的网络规则（如 iptables/IPVS），实现 Service 的负载均衡和网络转发
Pod：这里pod概念如上面pod一样。代表我们部署的pod

下面用一个示例来帮助我们理解上面这些核心组件。以下是一个k8s Deployment的YAML 配置文件，用于部署一个 Spring Boot 应用程序。后面会介绍。在这里可以先理解这个配置文件是用来部署你想部署应用的pod。我们执行 kubectl apply -f deployment.yaml k8s就会帮我们部署好pod这里执行这个部署指令k8s会做什么事情。我们可以通过这个来理解以下我们k8s集群的组件

apiVersion: apps/v1
kind: Deployment
metadata:
  name: springboot-cpu-test
spec:
  replicas: 1
  selector:
    matchLabels:
      app: springboot-cpu-test
  template:
    metadata:
      labels:
        app: springboot-cpu-test
    spec:
      containers:
      - name: springboot-app
        image: springboot-cpu-test:1.0
        imagePullPolicy: Never
        ports:
        - containerPort: 8081
        resources:
          limits:
            cpu: "1"
            memory: "512Mi"
          requests:
            cpu: "500m"
            memory: "256Mi"
        livenessProbe:
          httpGet:
            path: /actuator/health
            port: 8081
          initialDelaySeconds: 30
          periodSeconds: 10
        readinessProbe:
          httpGet:
            path: /actuator/health
            port: 8081
          initialDelaySeconds: 20
          periodSeconds: 5

kubectl apply -f deployment.yaml执行后。
kubectl会把yaml内容转成请求参数发送给api server。api server在做完认证鉴权准入控制等操作后，会把这个deployment对象的元数据写入到 etcd 数据库。

接着Deployment Controller通过api server 监听到etcd中新增了deployment对象，根据deployment对象的 replicas: 1 创建对应的ReplicaSet对象，并通过api server 存入etcd。

接着ReplicaSet Controller 通过api server 监听到etcd中有新的ReplicaSet对象。根据ReplicaSet创建的Pod 定义在经过api server 存入etcd，注意这里这是Pod的定义Pod还没真正的创建成功。

接着kube-scheduler会通过api server 监听到etcd中存在phase: Pending 且 nodeName 为空的Pod也就是未被分配到工作节点上创建的Pod，然后根据Pod的定义。如需要多少cpu、内存等等这些选择合适的Worker Node工作节点，将Pod和节点关绑定，并通过api server 写入etcd

然后我们的工作节点上的kubelet 通过api server 监听到当前工作节点上有新的Pod绑定到当前节点，并且当前节点未创建Pod到当前的工作节点，就会执行创建节点的操作，根据Pod定义的template等等信息，拉去镜像，运行容器等操作运行起来Pod，至此我们的Pod就成功运行起来了。接着kubelet 会通过api server 把这个Pod 运行成功也就是状态设置为Running存入etcd

然后kube-proxy监听到新 Pod 的 IP，更新节点的 iptables/IPVS 规则（为后续可能的 Service 流量路由做准备）

以上就是我们执行kubectl apply -f deployment.yaml之后k8s集群会做的事情，对此也可以大致了解一下上面这些组件的概念已经作用。从中我们可以看到所有组件之间的资源的互相调用都是需要经过api server，即是所有资源操作的唯一访问点。

上面我们执行kubectl apply -f deployment.yaml 其实是让K8S创建了一个Deployment资源，为什么我们要创建Deployment 而不是去部署我们的容器组Pod呢？下面来给大家一一讲解。首先我们的容器组Pod他只是一个容器组，并不具备自动恢复，滚动更新等这些功能，这些功能是k8s其他基于一些其他控制器去控制管理我们的Pod资源来实现的。所以我们并不是直接部署Pod，而是部署能够去自动帮我们管理，声明Pod的资源，就是我们的Deployment。
为什么是Deployment?
从上面kubectl apply -f deployment.yaml 执行过程我们可以了解到了Deployment，ReplicaSet这个几个东西。接下来了解一些这几个东西。就知道我们是我们要选择Deployment。

ReplicaSet：是K8S用来确保在任何给定的时刻都在运行指定数量的 Pod 副本的，也就是你选择某一个Pod，副本数量为3，ReplicaSet就会帮你创建3个Pod，如果Pod的状态出现异常，ReplicaSet会主动去删除并重新创建新的 Pod。这就是我们K8S的自愈能力。ReplicaSet本身不直接监控到Pod，而是通过api server来监控etcd数据库的Pod状态，这个状态是由工作节点的kubelet监控对应节点上的Pod状态并通过api server 保存到etcd的。
Deployment：Deployment是在ReplicaSet的基础上再做了一层封装，ReplicaSet只实现了自动管理Pod副本实现的K8S自我修复。还有我们的滚动更新与回滚，就是我们的Deployment来做的，Deployment是在ReplicaSet的基础再做了一层封装。当我们使用Deployemt去做滚动更新时，Deployment会给我们创建一个新的ReplicatSet，让ReplicatSet来帮我们创建新的Pod，等待新的Pod创建完成后，就回去删除旧的Pod，但是旧的这个ReplicaSet还会存在，只是他管理的Pod副本数量会变成0，当我们执行回滚则会让旧的ReplicaSet管理的Pod副本数量会恢复然后让回滚前的ReplicaSet管理的Pod副本数量变为0
-
HorizontalPodAutoscaler：HorizontalPodAutoscaler也就是我们的HPA，自动更新工作负载资源，也就是我们的自动扩缩容，HPA的核心作用是监控指标（如 CPU/内存利用率、自定义指标等），并根据预设的阈值动态调整目标资源的副本数。也就是监控到到达了需要扩缩容的阈值HPA会堆Deployment或者是ReplicaSet的Pod的副本数进行调整。
Service：Service在K8S中负责服务发现和负载均衡，我们上面的部署Deployment的方式可能会存在多个Pod，并且可能出现异常Pod会被删除重新创建。因此Pod的IP是会变化的，这时候就需要一个东西来为Pod提供通信入口，Service会将请求自动分发到一组健康的Pod上（负载均衡）（默认策略）避免单点压力，这里就需要讲到另一个东西EndPoint，endpoint记录了这个 Service 实际对应的Pod IP + Port 列表，比如我的我部署了一个Springboot，这个Springboot的Deployment的ReplicaSet为5，即这个Springboot应用会运行起来3个pod，我们通过直接Service就可以访问到对应的pod，这是因为EndPoint记录这个Service Selector匹配到的pod对应的IP 和 port。访问Service会找到对的Endpoint，最终把请求转发到对应的pod上。如下图
Ingress：是允许入站连接到达后端定义的端点的规则集合。 Ingress 可以配置为向服务提供外部可访问的 URL、负载均衡流量、终止 SSL、提供基于名称的虚拟主机等。本质上是一个反向代理和负载均衡器。类似于我们常用的nginx，能够将外部的HTTP/HTTPS请求转发到内部的Service。由于我这里是再本地虚拟机搭建的环境没有正式的域名做演示。所以这里只简单部署一个ingress尝试。后续会尝试去使用阿里云的ACK去深入使用云服务商的K8S的时候会使用证书的域名尝试的。这里目前只是本地做了一个测试域名和再本机上host配置的方式去做的。如下
探针：K8S用来判断容器是否存在异常、是否需要重启，是否准备好接收外部流量。（以下三种探针说明来自K8S官方文档 K8S官方文档配置 Liveness、Readiness 和 Startup Probes）
存活探针（LivenessProbe） 用来确定什么时候要重启容器。例如，存活探针可以探测到应用死锁（应用在运行，但是无法继续执行后面的步骤）情况。重启这种状态下的容器有助于提高应用的可用性，即使其中存在缺陷。
存活探针的常见模式是为就绪探针使用相同的低成本 HTTP 端点，但具有更高的 failureThreshold。这样可以确保在硬性终止 Pod 之前，将观察到 Pod 在一段时间内处于非就绪状态。
就绪探针（ReadinessProbe） 用可以知道容器何时准备好接受请求流量。这种信号的一个用途就是控制哪个 Pod 作为 Service 的后端。当 Pod 的 Ready 状况为 true 时，Pod 被认为是就绪的。若 Pod 未就绪，会被从 Service 的负载均衡器中剔除。当 Pod 所在节点的 Ready 状况不为 true 时、当 Pod 的某个 readinessGates 为 false 时，或者当 Pod 中有任何一个容器未就绪时，Pod 的 Ready 状况为 false。
启动探针（StartupProbe） 用来了解应用容器何时启动。如果配置了这类探针，存活探针和就绪探针在启动探针成功之前不会启动，从而确保存活探针或就绪探针不会影响应用的启动。启动探针可以用于对慢启动容器进行存活性检测，避免它们在启动运行之前就被杀掉。
探测方式：K8S官方文档说明了探针的几种探测方式
1、定义活动命令：通过命令的方式去探测，如官方示例定义LivenessProbe了命令cat /tmp/healthy 的方式去探测，则kubelet就间隔时间的执行cat /tmp/healthy命令。如果命令成功，则返回 0，并且 kubelet 认为容器处于活动状态且运行状况良好。如果命令返回非零值，则 kubelet 会终止容器并重新启动它。
2、定义活动状态 HTTP 请求：是我们springboot应用最常见的一种方式，我们会在springboot中定义一个健康检查接口，给kubelet调用，来判断。就像我们上面的deployment.yaml中定义了的探针就是http的方式，通过httpget的方式访问端口号8081的/actuator/health的http请求。根据请求返回内容来判断容器是否处于活动状态且运行状况良好。
3、定义 TCP 活动情况探测：使用此配置，kubelet 将尝试在指定端口上打开容器的套接字。如果它可以建立连接，则认为容器运行状况良好，如果不能，则认为容器失败。
4、定义 gRPC 活动情况探测：如果您的应用程序实现了 gRPC 运行状况检查协议，此示例说明如何配置 Kubernetes 以将其用于应用程序活动性检查。同样，您可以配置 readiness 和 startup probes