点击关注公众号，“技术干货” 及时达！

前言

最近在采用Jenkins实现前端项目自动化部署功能，其中有一个步骤用到了k8s, 这一块知识令我感到比较陌生，看不懂配置文件里的语句含义，以及如何被外部的bash指令串联起来，刚好假期有时间，决定学习一下k8s。学完目标是学完之后要了解k8s常用的操作。现在我们进入今天的主题:

一、Kubernetes 简介

Kubernetes（简称 K8s）是一个用于「自动部署、扩展和管理容器化应用程序」的开源系统。下图展示了Kubernetes集群的架构及其与外部系统的交互方式：

1.1 外部系统（External Systems）

kubectl: 这是Kubernetes的命令行工具，用户可以通过它与Kubernetes API服务器进行交互，执行各种操作如创建、删除和更新资源。

CI/CD Systems: 持续集成/持续部署系统可以使用Kubernetes API来自动化应用的部署和管理。

Apps Use SDK to connect to API server: 应用程序可以使用SDK连接到Kubernetes API服务器，以实现更复杂的集成和自动化。

1.2 Kubernetes 集群（Kubernetes Cluster）

Kubernetes集群采用的是「主从架构（Master-Slave Architecture）」 ，主要由两个角色组成：

「控制平面（Control Plane）」 ：负责集群的整体管理和调度。

「工作节点（Worker Node）」 ：负责实际运行应用容器。

1.2.1 控制平面（Control Plane）

控制平面是 Kubernetes 的“大脑”，主要负责接收用户指令、调度任务、监控运行状态。它包含以下组件：

所有这些组件通常运行在 Master 节点上。在生产环境中，控制平面可以做高可用部署（即多个 Master 节点）：

保证 apiserver 的可用性（通过负载均衡）

保证 etcd 的数据冗余与高一致性（通常部署 3 个及以上节点）

避免单点故障，增强容灾能力

1.2.2 工作节点（Worker Node）

每个 Node 是实际运行容器的机器（虚拟机或物理机），其核心组件包括：

1.2.3 云提供商APIs

Kubernetes可以通过云提供商APIs与云服务进行集成，例如负载均衡器、存储卷和身份认证等。这使得Kubernetes能够利用云平台提供的各种服务来增强其功能。

1.3 k8s和docker的关系?

k8s和docker的用途都含有容器管理，初学者一般都搞不清楚两者之间的关系。可以理解为：「Docker 负责造车，Kubernetes 负责调度车队跑起来并保持秩序」。

「Docker 管理单个容器，Kubernetes 管理容器的集群」；它们各司其职，共同构成了现代云原生应用的基石。

1.4 工作流程

开发者通过 kubectl 提交 YAML 清单到 apiserver。

apiserver 验证请求，并将信息存储到 etcd。

scheduler 监听到新 Pod 创建请求，并根据调度算法分配到合适的 Node。

对应 Node 上的 kubelet 接收到任务，调用 Container Runtime 启动容器。

kube-proxy 设置好服务发现和访问规则，确保内部通信正常。

二、搭建 Kubernetes 环境

根据使用场景不同,k8s有三种搭建方式。三种搭建方式的优缺点如下：

由于篇幅所限，本文只演示一下第一种搭建k8s环境的方式（以 macOS / Linux 为例）:

2.1 安装 kubectl（Kubernetes 命令行工具）

curl -LO "https://dl.k8s.io/release/$(curl -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"chmod +x kubectlsudo mv kubectl /usr/local/bin/kubectl version --client

2.2 安装 Minikube

curl -LO https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64sudo install minikube-linux-amd64 /usr/local/bin/minikube

2.3 启动 Minikube 集群

minikube start

2.4 查看集群节点状态

kubectl get nodes

三、常用资源对象介绍

Kubernetes 中资源种类很多，常见的有：

3.1 Pod：最小部署单元

3.1.1 什么是Pod？

Pod 是 K8s 中最小的可调度单元。一个 Pod 包含一个或多个 「容器（通常是 Docker 容器）」 ，这些容器共享：

网络（IP 和端口空间）

存储（Volume 卷）

生命周期（被视为一个整体）

Pod 的典型用途是运行一个应用或服务的一个实例。一个 Pod 运行一个容器（最常见场景）：

apiVersion: v1kind:Podmetadata:name:nginx-podspec:containers:    -name:nginx      image:nginx:1.24      ports:        -containerPort:80

这个 Pod 会启动一个 Nginx 容器，并暴露 80 端口。

3.1.2 Pod 生命周期

Pod 的状态包括：

Pending

: 等待调度资源

Running

: 正在运行

Succeeded

: 运行成功后退出

Failed

: 运行失败

Unknown

: 状态无法获取

3.1.3 Pod的创建，查看与删除

# 创建kubectl apply -f nginx-pod.yaml# 查看所有podkubectl get pods# 查看某个podkubectl describe pod nginx-pod# 删除kubectl delete pod nginx-pod

上面给出的都是独立的pod的创建与管理方式，虽然你可以手动管理 Pod，但 「更推荐使用 Deployment 控制器」 ，创建Pod，自动管理 Pod 的副本数量、自愈能力和升级策略。

3.2 Deployment：无状态应用的部署控制器

Deployment 是 Kubernetes 中最常用的控制器之一，专门用于管理 「无状态应用的生命周期」。它确保你的 Pod 副本在集群中始终按预期运行，并具备以下功能：

保证指定数量的 Pod 始终处于运行状态（副本控制）

支持应用的滚动升级和回滚

支持 declarative 式的配置和更新

自动重建失败的 Pod（具备自愈能力）

3.2.1 典型 Deployment 示例

说明：

replicas

: 设置运行的 Pod 数量为 3

selector

: 用于匹配管理哪些 Pod

template

: 定义 Pod 的内容（镜像、端口等）

apiVersion: apps/v1kind:Deploymentmetadata:name:my-nginxspec:replicas:3selector:    matchLabels:      app:nginxtemplate:    metadata:      labels:        app:nginx    spec:      containers:        -name:nginx          image:nginx:1.24          ports:            -containerPort:80

3.2.2 Deployment 的工作逻辑

寻找所有标签匹配 
selector.matchLabels
 的 Pod

如果数量不足 
replicas
，则新建 Pod

如果数量过多，则删除多余的 Pod

如果标签相同但镜像等配置不同，则更新 Pod

Deployment 不直接控制 Pod，而是通过创建一个 ReplicaSet，再由 ReplicaSet 具体去创建 Pod，维护副本数量，做滚动更新。

3.2.3 Deployment操作命令

# 创建 Deploymentkubectl apply -f nginx-deploy.yaml# 查看状态kubectl get deploymentskubectl describe deployment nginx-deploy# 查看管理的 Podkubectl get pods -l app=nginx

修改镜像并滚动升级，将nginx从1.24升级到1.25

spec:  containers:    - name: nginx      image: nginx:1.25

# 升级kubectl apply -f nginx-deploy.yaml# 查看历史记录kubectl rollout history deployment nginx-deploy# 回滚kubectl rollout undo deployment nginx-deploy

3.3  Service：服务发现与负载均衡

在 Kubernetes 中，「Pod 是会变化的」 —— 当 Deployment 滚动更新、Pod 重启时，Pod 的 IP 会变。所以不能依赖 Pod 的 IP 地址来通信。

这就是 Service 出场的原因，它为一组 Pod 提供了一个 「稳定的网络访问入口」，实现了：

「服务发现」（Pod 动态变动也能找到）

「负载均衡」（多个 Pod 间自动分流请求）

3.3.1 Service实例

实例：为 nginx Pod 暴露一个 Service

apiVersion: v1kind:Servicemetadata:name:nginx-servicespec:selector:    app:nginx# 匹配被管理的 Pod（Deployment 创建的）ports:    -protocol:TCP      port:80          # Service 对外暴露的端口      targetPort:80    # Pod 内部容器监听的端口type:ClusterIP       # 集群内访问（默认）

常见 Service 类型：

3.3.2 Service 如何做服务发现？

Kubernetes 内置 「DNS 服务」，会为每个 Service 分配一个 DNS 名称： 例如

http://nginx-service.default.svc.cluster.local

容器中的其他 Pod 只需用这个 DNS 名称就能访问 nginx 服务，完全不需要关心 Pod IP。

3.3.3 创建并访问 Service 示例

# 创建 Deploymentkubectl apply -f nginx-deployment.yaml# 创建 Servicekubectl apply -f nginx-service.yaml# 查看 Service IP 和端口：kubectl get svc# 在集群中访问 Service：curl http://nginx-service

3.4 Ingress

在 Kubernetes 中，Ingress是一种 API 对象，用于管理外部用户如何通过 HTTP 或 HTTPS 访问集群内的服务（Service） 。简而言之，Ingress 提供了一种统一的方式，将域名或路径映射到集群中的服务上，并支持负载均衡、SSL 终端和基于路径/主机的路由。

3.4.1 为什么需要 Ingress？

在没有 Ingress 的情况下，集群外部访问服务只能通过：

「NodePort」：每个 Service 暴露一个端口，访问地址为 
NodeIP:Port
，难管理。

「LoadBalancer」：为每个服务申请一个云负载均衡器，成本高。

「Port-forward / kubectl proxy」：临时调试用，不适合生产。

而 Ingress 通过一个统一的入口，根据域名或路径来转发请求，成本低、配置灵活、可维护性强。Ingress 功能点如下:

3.4.2 组成结构

Ingress 本身不直接处理请求，它依赖 「Ingress Controller」 来工作。常见 Ingress Controller:

下面这张图展示了 Ingress 在 Kubernetes 中进行流量转发的完整架构流程

用户访问 
example.com/web
；
Ingress 中定义了 
/web
 路径指向 
my-web
 Service；

Ingress Controller（如 nginx-ingress）读取 Ingress 规则；

Ingress Controller 接收到请求后，将其转发给 
my-web
 Service；
Service 查找符合条件的 Pod（例如标签为 
app=web
）；

请求最终到达 Pod，得到业务响应。

   +--------------+   |   Internet   |   +------+-------+          |  +-------v--------+  | Ingress        |  ← 配置路由规则的资源  | (定义规则)     |  +-------+--------+          | +--------v---------+ | Ingress Controller| ← 实际负责转发流量 | (如 Nginx, Traefik)| +--------+---------+          |    +-----v------+    | Kubernetes |    |  Services  |    +-----+------+          |       +--v--+       | Pod |       +-----+

3.4.3 配置一个简单的 Ingress

apiVersion: v1kind:Servicemetadata:name:my-webspec:selector:    app:webports:    -port:80      targetPort:8080

service.yaml对应的my-web-deployment.yaml配置如下:

apiVersion: apps/v1kind:Deploymentmetadata:name:my-webspec:replicas:2selector:    matchLabels:      app:webtemplate:    metadata:      labels:        app:web    spec:      containers:        -name:web          image:nginx:1.24          ports:            -containerPort:8080

这个 Service 将流量从端口 80 转发到选中 Pod 的 8080 端口。Ingress 配置如下：

apiVersion: networking.k8s.io/v1kind:Ingressmetadata:name:web-ingressspec:rules:    -host:example.com      http:        paths:          -path:/web            pathType:Prefix            backend:              service:                name:my-web        # 指向 Service 的名字                port:                  number:80        # 指向 Service 的 port 字段

❝

当用户访问 

http://example.com/web

 时：

请求被 Ingress Controller 捕获；

根据 
/web
 路径匹配到规则；
将请求转发到 
my-web
 Service；
Service 根据 selector 找到对应的 Pod（如 
app=web
）；
将请求转发给这些 Pod 的 
targetPort: 8080
。

❞

3.4.4 配置 HTTPS Ingress

kubectl create secret tls tls-secret \  --cert=example.com.crt \  --key=example.com.key \  -n default

在Ingress 配置启用 HTTPS

apiVersion: networking.k8s.io/v1kind:Ingressmetadata:name:web-ingressannotations:    nginx.ingress.kubernetes.io/rewrite-target:/spec:tls:    -hosts:        -example.com      secretName:tls-secret# 指向我们预先创建的 TLS Secretrules:    -host:example.com      http:        paths:          -path:/            pathType:Prefix            backend:              service:                name:my-web                port:                  number:80

效果验证：

本地配置 DNS：

echo "INGRESS_IP  example.com" | sudo tee -a /etc/hosts

INGRESS_IP

 是你的 Ingress Controller 的外网 IP 地址。

浏览器访问：

https://example.com/

若配置无误，将自动跳转并看到你部署的 nginx 页面。

3.5 ConfigMap 与 Secret

在 Kubernetes 中，「ConfigMap 和 Secret」 是用于「配置管理」的两种核心资源类型，它们用于将配置和敏感数据（如密码、API 密钥）与容器解耦，让你的应用部署更加灵活、安全。

3.5.1 ConfigMap：存储非敏感配置

创建 ConfigMap 的方式

kubectl create configmap my-config --from-literal=color=blue --from-literal=lang=zh

方法 2：使用 YAML 创建

apiVersion: v1kind: ConfigMapmetadata:  name: my-configdata:  color: blue  lang: zh

使用 ConfigMap 的方式

方法 1：作为环境变量注入容器

env:  - name: COLOR    valueFrom:      configMapKeyRef:        name: my-config        key: color

方法 2：挂载为文件

volumeMounts:  - name: config-volume    mountPath: /etc/configvolumes:  - name: config-volume    configMap:      name: my-config

3.5.2 Secret：存储敏感配置

Secret 的数据会以 Base64 编码存储（可以结合加密存储后端实现更高安全性）。

创建 Secret 的方式

方法 1：命令行直接创建

kubectl create secret generic my-secret --from-literal=password=123456

方法 2：YAML 文件创建（注意 Base64 编码）

apiVersion: v1kind: Secretmetadata:  name: my-secrettype: Opaquedata:  password: MTIzNDU2  # Base64 编码后的 "123456"

可以用如下命令手动编码：

echo -n "123456" | base64

使用 Secret 的方式

方法 1：作为环境变量注入

env:  - name: DB_PASSWORD    valueFrom:      secretKeyRef:        name: my-secret        key: password

方法 2：挂载为文件

volumeMounts:  - name: secret-volume    mountPath: /etc/secretvolumes:  - name: secret-volume    secret:      secretName: my-secret

3.6 PersistentVolumeClaim

PersistentVolumeClaim（PVC） 是一种资源对象，用于申请持久化存储空间（PersistentVolume，PV） 。简单来说，它是 Pod 与底层存储之间的桥梁，用户通过 PVC 来请求磁盘，而不是直接绑定硬盘资源。

3.6.1 什么是 PersistentVolume 与 PersistentVolumeClaim？

「PersistentVolume（PV）」 ：由管理员创建或自动创建的「存储资源」，类似“硬盘”。

「PersistentVolumeClaim（PVC）」 ：用户申请使用 PV 的方式，类似“租用硬盘”。

❝

🧩 类比理解：

「PV = 房东提供的房子」

「PVC = 租客发出的租房申请」

Kubernetes 匹配 PVC 与 PV，实现租房动作

❞

为什么需要 PVC？在容器运行时，容器内的数据是「临时的（临时存储）」 ，容器重启或迁移后会丢失。如果需要保存数据库、文件上传等数据，就必须使用 PVC 来绑定到稳定的硬盘。

3.6.2 PVC 使用流程

管理员配置 StorageClass 或 PV

开发者在 Pod 中声明 PVC

系统自动匹配合适的 PV 给 PVC

Pod 使用 PVC 提供的存储挂载路径

3.6.3 PVC 使用示例

Step1：定义 PVC

申请一个 1Gi 的存储空间

apiVersion: v1kind:PersistentVolumeClaimmetadata:name:my-pvcspec:accessModes:    -ReadWriteOnce      # 只允许一个 Pod 挂载读写resources:    requests:      storage:1Gi        # 请求 1Gi 存储空间

访问模式说明：

Step 2：Pod 中使用 PVC

apiVersion: v1kind:Podmetadata:name:nginx-with-pvcspec:containers:    -name:nginx      image:nginx      volumeMounts:        -mountPath:"/usr/share/nginx/html"          name:web-datavolumes:    -name:web-data      persistentVolumeClaim:        claimName:my-pvc

3.7 Namespace

「Namespace（命名空间）」 是一种用于对集群中的资源进行「逻辑隔离和分组管理」的机制。可以把它理解为集群中的「虚拟子集群」，用于将资源划分为多个相互独立的空间。并非所有的资源都可以用命名空间进行隔离。

顺便说一下Node和Pod的区别：

通俗理解「Node 是宿舍楼」，里面住着多个 「Pod（宿舍间）」 一个 Node 可以运行多个 Pod，但 Pod 不能脱离 Node 独立存在。

3.7.1 Namespace 有什么用？

1. 「资源隔离」

每个 Namespace 里的资源彼此隔离，互不干扰。

比如你在 
dev
 和 
prod
 中分别部署了两个 
nginx
，它们不会冲突，因为在各自的命名空间中是唯一的。

2. 「权限控制（RBAC）」

可以基于 Namespace 分配不同的权限，比如：

张三

 只能管理 

dev

 命名空间；

李四

 只能查看 

prod

 命名

便于企业多团队协作时的权限边界管理。

3. 「资源配额限制（ResourceQuota）」

可以为不同 Namespace 设置资源配额限制，比如：

dev

 Namespace 最多使用 4 个 CPU、8G 内存；

prod

 Namespace 可以使用更多资源；

这样可以避免某个项目“吃光”整个集群资源。

4. 「便于环境分离」

常见实践：按环境划分 Namespace：

dev

：开发环境

test

：测试环境

prod

：生产环境

在一个集群中部署多套系统而互不干扰。此外Kubernetes 默认提供了几个内置命名空间：

3.7.2 创建命名空间并部署资源示例

# 创建命名空间kubectl create namespace dev# 在 dev 命名空间部署 nginxkubectl run nginx --image=nginx -n dev# 查看 dev 命名空间下的 Podkubectl get pods -n dev

命名空间的逻辑隔离:

+------------------------+|     Kubernetes 集群     ||                        || +--------+  +--------+ || | dev    |  | prod   | || |        |  |        | || | nginx  |  | nginx  | || | redis  |  | mysql  | || +--------+  +--------+ |+------------------------+

3.8 RBAC

「RBAC（基于角色的访问控制，Role-Based Access Control）」 是一种权限管理机制，用来控制「谁可以对哪些资源执行哪些操作」。RBAC 就像公司中的权限系统：不同的岗位（角色）有不同的权限，不同的员工（用户）只能做他们被授权的事情。

3.8.1 RBAC 的核心组件

RBAC 一共由 4 个关键对象组成：

常见的操作：

3.8.2 创建一个只读角色

创建 Role：只能查看 Pod 和 Service

apiVersion: rbac.authorization.k8s.io/v1kind:Rolemetadata:name:pod-readernamespace:devrules:-apiGroups:[""]    resources:["pods","services"]    verbs:["get","list","watch"]

创建 RoleBinding：把这个权限绑定给某个用户

apiVersion: rbac.authorization.k8s.io/v1kind:RoleBindingmetadata:name:read-pods-bindingnamespace:devsubjects:-kind:User    name:alice    apiGroup:rbac.authorization.k8s.ioroleRef:kind:Rolename:pod-readerapiGroup:rbac.authorization.k8s.io

常用命令:

# 查看所有 ClusterRolekubectl get clusterroles# 查看绑定关系kubectl get rolebindings -n dev# 授予某用户集群管理员权限（示例）kubectl create clusterrolebinding admin-binding \  --clusterrole=cluster-admin \  --user=alice@example.com

3.9 CronJob

配置字段说明：

示例：每天午夜运行一次任务

apiVersion: batch/v1kind:CronJobmetadata:name:hello-cronjobspec:schedule:"0 0 * * *"# crontab 格式：每天0点jobTemplate:    spec:      template:        spec:          containers:            -name:hello              image:busybox              args:                -/bin/sh                --c                -echo"Hello from CronJob at $(date)"          restartPolicy:OnFailure

分 时 日 月 星期

CronJob 的执行过程：

时间触发器 (schedule)        ↓   +-----------+   |  CronJob  | ← 负责按照 schedule 触发 Job   +-----------+        ↓   +-----------+   |   Job     | ← 一次性任务（控制器）   +-----------+        ↓   +-----------+   |   Pod     | ← 实际执行任务的容器   +-----------+

常用命令：

# 获取集群中所有CronJob资源的列表kubectl get cronjob# 查看名为 hello-cronjob 的 CronJob 资源的详细信息kubectl describe cronjob hello-cronjob# 列出所有的 Job 资源kubectl get jobs# 查看与指定 Job 相关的 Pod 的日志kubectl logs <job-created-pod-name>

四、自动伸缩（HPA）

「HPA（Horizontal Pod Autoscaler，水平 Pod 自动扩缩容）」 是一个控制器，它会根据CPU、内存或自定义指标，自动调整 Pod 的副本数量，确保应用在不同负载情况下都能平稳运行。

4.1 HPA 的工作原理

HPA 监测目标 Pod 资源使用情况（默认监测 CPU）。

如果 CPU 或其他指标高于设定阈值，就自动「增加」 Pod 副本数。

如果 CPU 或其他指标低于设定阈值，就自动「减少」 Pod 副本数。

4.2 如何使用 HPA？

4.2.1 确保 Metrics Server 已安装

kubectl get apiservices | grep metrics

kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml

4.2.2 创建一个 Deployment

apiVersion: apps/v1kind:Deploymentmetadata:name:php-apachespec:replicas:1selector:    matchLabels:      app:php-apachetemplate:    metadata:      labels:        app:php-apache    spec:      containers:        -name:php-apache          image:k8s.gcr.io/hpa-example          ports:            -containerPort:80          resources:            requests:              cpu:200m            limits:              cpu:500m

4.2.3 创建 HPA 规则（基于 CPU 自动扩缩）

apiVersion: autoscaling/v2kind:HorizontalPodAutoscalermetadata:name:php-apache-hpaspec:scaleTargetRef:    apiVersion:apps/v1    kind:Deployment    name:php-apache   # 关联的 DeploymentminReplicas:1        # 最少 1 个副本maxReplicas:10       # 最多 10 个副本metrics:    -type:Resource      resource:        name:cpu        target:          type:Utilization          averageUtilization:50# CPU 使用率超过 50% 时扩容

4.2.4 应用与查看 HPA 规则

kubectl apply -f hpa.yamlkubectl get hpa

示例输出：

NAME            REFERENCE            TARGETS   MINPODS   MAXPODS   REPLICAS   AGEphp-apache-hpa  Deployment/php-apache  60%/50%  1         10        3         5m

TARGETS 60%/50%

：当前 CPU 使用率 60%，HPA 目标是 50%。

REPLICAS 3

：HPA 自动扩展了 3 个 Pod。

4.2.5 模拟高负载（测试 HPA）

kubectl run -i --tty busybox --image=busybox -- sh# 在 BusyBox 终端里执行while true; do wget -q -O- http://php-apache; done

观察 HPA 变化：

kubectl get hpa -w

4.2.6 进阶-基于自定义指标扩缩容

HPA 也可以基于「内存使用量」或「Prometheus 自定义指标」进行扩缩容，例如：

metrics:  - type: Resource    resource:      name: memory      target:        type: Utilization        averageUtilization: 70  # 当内存使用率超过 70% 时扩容

或者基于 「Prometheus 监控指标」 进行扩容：

metrics:  -type:External    external:      metric:        name:requests_per_second      target:        type:AverageValue        averageValue:1000# 每秒请求超过1000次扩容

4.3 怎么解决资源不足问题？

HPA 扩展的 Pod 所需的硬件资源，来自集群中已有的 Node（节点）资源池。如果 Node上没有足够资源容纳新的 Pod，Pod 会「处于 Pending 状态」，直到有资源调度。举例说明：

集群中有 3 个 Node，每个 Node 有 2 核 CPU 和 4G 内存。

每个 Pod 要求 
cpu: 500m
。

初始状态运行了 6 个 Pod，正好占满资源(理论上最多能运行 「12 个 Pod」，但我们说「6 个 Pod 就占满资源」，是因为现实中不能这么理想化计算，系统组件也占资源，再预留一些 buffer 来应对波动、调度策略等，6~8 个 Pod 就可能接近极限了)。

负载升高，HPA 触发扩容为 8 个 Pod。

结果：新创建的 2 个 Pod 会 「Pending（等待）」 ，因为没有 Node 有足够资源运行它们。

怎么解决资源不足问题？有两种方式：

4.3.1 手动添加节点（扩容集群）

如果你使用的是物理机或虚拟机搭建的集群，可以手动加入更多 Node。

# 添加新节点后，kubelet 会将其注册进集群kubectl get nodes

4.3.2 使用 Cluster Autoscaler（集群自动扩容）

❝

Cluster Autoscaler 是 Kubernetes 官方提供的「自动添加/移除 Node 的组件」。

❞

当 Pod 无法调度时，Cluster Autoscaler 会自动向云服务申请添加 Node。

当某些 Node 上没有运行任何 Pod 并维持一段时间，自动释放这些 Node。

支持的云平台：

GKE（Google）

EKS（AWS）

AKS（Azure）

阿里云、腾讯云等也有类似组件

4.3.3 最佳方案

最佳实践：HPA + Cluster Autoscaler 联用 是生产环境最常见做法：

HPA 根据 CPU/内存/自定义指标自动调整 Pod 数量。

如果资源不足，Cluster Autoscaler 自动申请节点，保障 Pod 正常运行。

结语

肚子有点饿，今天先写到这里，下篇明天再续写。

关注更多AI编程资讯请去AI Coding专区：https://juejin.cn/aicoding

点击"阅读原文"了解详情~