Kubernetes架构与原理详解
前言
上一篇文章我们学习了 Docker，知道了如何将应用打包成容器。但当容器数量变多、服务器变多时，手动管理就变得不现实了。这时候就需要一个"容器管家"来帮我们自动化管理，它就是 Kubernetes（简称 K8s）。本文将带你深入理解 K8s 的架构和工作原理。
🏠个人主页：你的主页
文章目录
一、为什么需要Kubernetes
1.1 手动管理容器的痛点
假设你是一个运维工程师，负责管理公司的服务器和应用。
场景一：应用挂了
凌晨 3 点，手机响了...
"喂？博客服务挂了？好，我马上处理..."
登录服务器 → 查看日志 → 重启服务 → 验证恢复
耗时：30 分钟
睡眠：没了场景二：流量暴涨
双十一活动，流量是平时的 10 倍...
登录服务器1 → 部署新实例
登录服务器2 → 部署新实例
登录服务器3 → 部署新实例
配置负载均衡...
耗时：2 小时
活动已经开始 1 小时了...场景三：服务器宕机
服务器 A 硬盘坏了，上面跑着 5 个服务...
找一台新服务器
把 5 个服务重新部署上去
更新 DNS 和负载均衡配置...
耗时：半天
用户投诉：无数1.2 我们需要什么
| 需求 | 描述 |
|---|---|
| 自动重启 | 服务挂了自动拉起来 |
| 自动扩缩容 | 流量大了自动加实例，流量小了自动减 |
| 自动迁移 | 服务器挂了自动把服务迁到其他服务器 |
| 统一管理 | 不用登录每台服务器，一个地方管理所有服务 |
| 声明式配置 | 写个配置文件，系统自动达到期望状态 |
Kubernetes 就是为了解决这些问题而生的。
二、Kubernetes是什么
2.1 一句话定义
Kubernetes（K8s）是一个容器编排引擎，用于自动化部署、扩缩容和管理容器化应用。
为什么叫 K8s？
Kubernetes 这个单词太长了（10 个字母），所以取首字母 K 和尾字母 s，中间 8 个字母用数字 8 代替，就成了 K8s。
2.2 K8s 的核心能力
| 能力 | 说明 |
|---|---|
| 服务发现和负载均衡 | 自动分配 IP，自动负载均衡 |
| 存储编排 | 自动挂载存储系统 |
| 自动部署和回滚 | 声明式更新，出问题自动回滚 |
| 自动装箱 | 根据资源需求自动调度到合适的节点 |
| 自我修复 | 容器挂了自动重启，节点挂了自动迁移 |
| 密钥和配置管理 | 安全管理敏感信息 |
2.3 K8s 的定位
┌─────────────────────────────────────────────────────────────┐
│ 应用部署演进 │
└─────────────────────────────────────────────────────────────┘
传统部署时代
├── 直接在物理机上部署应用
├── 无法定义资源边界
└── 应用之间相互影响
↓
虚拟化部署时代
├── 在虚拟机上部署应用
├── 资源隔离，安全性好
└── 但虚拟机太重，资源利用率低
↓
容器部署时代
├── 在容器中部署应用
├── 轻量、快速、资源利用率高
└── 但容器多了管理困难
↓
容器编排时代（K8s）
├── 自动化管理大量容器
├── 声明式配置，自动达到期望状态
└── 自我修复，高可用三、K8s整体架构
3.1 架构概览
K8s 集群由两部分组成：控制平面（Control Plane） 和 工作节点（Node）。
┌─────────────────────────────────────────────────────────────┐
│ Kubernetes 集群 │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 控制平面 (Control Plane) │ │
│ │ │ │
│ │ ┌───────────┐ ┌───────────┐ ┌───────────────────┐ │ │
│ │ │API Server │ │ Scheduler │ │Controller Manager │ │ │
│ │ └───────────┘ └───────────┘ └───────────────────┘ │ │
│ │ │ │
│ │ ┌─────────────────────────────────────────────┐ │ │
│ │ │ etcd │ │ │
│ │ │ (分布式存储) │ │ │
│ │ └─────────────────────────────────────────────┘ │ │
│ └─────────────────────────────────────────────────────┘ │
│ │ │
│ │ 管理 │
│ ▼ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 工作节点 (Node) │ │
│ │ │ │
│ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ │
│ │ │ Node1 │ │ Node2 │ │ Node3 │ │ │
│ │ │┌───────┐│ │┌───────┐│ │┌───────┐│ │ │
│ │ ││ Pod A ││ ││ Pod C ││ ││ Pod E ││ │ │
│ │ │└───────┘│ │└───────┘│ │└───────┘│ │ │
│ │ │┌───────┐│ │┌───────┐│ │┌───────┐│ │ │
│ │ ││ Pod B ││ ││ Pod D ││ ││ Pod F ││ │ │
│ │ │└───────┘│ │└───────┘│ │└───────┘│ │ │
│ │ └─────────┘ └─────────┘ └─────────┘ │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘打个比方：
- 控制平面 = 公司总部（决策层）
- Node = 各地分公司（执行层）
- Pod = 具体的员工（干活的）
3.2 控制平面 vs 工作节点
| 角色 | 职责 | 类比 |
|---|---|---|
| 控制平面 | 决策、调度、管理 | 老板 |
| 工作节点 | 运行容器、执行任务 | 打工人 |
四、控制平面组件详解
4.1 API Server
职责：K8s 的"前台接待"，所有操作都要通过它。
┌─────────────────────────────────────────────────────────────┐
│ API Server │
├─────────────────────────────────────────────────────────────┤
│ │
│ kubectl ──────────────┐ │
│ │ │
│ Dashboard ────────────┼──────► API Server ──────► etcd │
│ │ │ │
│ 其他客户端 ───────────┘ │ │
│ ▼ │
│ Scheduler / Controller │
│ │
└─────────────────────────────────────────────────────────────┘核心功能：
- 提供 RESTful API 接口
- 认证、授权、准入控制
- 数据校验
- 与 etcd 交互
4.2 etcd
职责：K8s 的"数据库"，存储所有集群数据。
存储内容：
- 集群配置信息
- 节点信息
- Pod 信息
- Service 信息
- Secret、ConfigMap 等
特点：
- 分布式键值存储
- 强一致性（Raft 协议）
- 高可用
4.3 Scheduler
职责：K8s 的"调度员"，决定 Pod 运行在哪个 Node 上。
调度流程：
新 Pod 创建请求
│
▼
Scheduler 获取 Pod 信息
│
▼
过滤不满足条件的 Node
├── 资源不足的 Node
├── 有污点的 Node
└── 不满足亲和性的 Node
│
▼
对剩余 Node 打分
├── 资源均衡度
├── 亲和性匹配度
└── 其他策略
│
▼
选择得分最高的 Node
│
▼
绑定 Pod 到 Node调度策略示例：
yaml
# 指定 Pod 只能调度到有 SSD 的节点
spec:
nodeSelector:
disk: ssd
# 指定 Pod 尽量和某些 Pod 在一起
spec:
affinity:
podAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 100
podAffinityTerm:
labelSelector:
matchLabels:
app: cache4.4 Controller Manager
职责：K8s 的"管理者"，确保集群状态符合期望。
包含多个控制器：
| 控制器 | 职责 |
|---|---|
| Deployment Controller | 管理 Deployment，确保 Pod 数量正确 |
| ReplicaSet Controller | 管理 ReplicaSet，维护 Pod 副本数 |
| Node Controller | 监控 Node 状态，处理节点故障 |
| Service Controller | 管理 Service，配置负载均衡 |
| Endpoint Controller | 管理 Endpoint，关联 Service 和 Pod |
控制循环（Reconcile Loop）：
┌─────────────────────────────────────────────────────────────┐
│ 控制器工作原理 │
└─────────────────────────────────────────────────────────────┘
┌──────────────────────────────────────┐
│ │
▼ │
┌───────────────┐ ┌───────────────┐ │
│ 期望状态 │ │ 当前状态 │ │
│ (Desired) │ │ (Current) │ │
│ │ │ │ │
│ 副本数: 3 │ │ 副本数: 2 │ │
└───────┬───────┘ └───────┬───────┘ │
│ │ │
└────────┬───────────┘ │
│ │
▼ │
┌───────────────┐ │
│ 比较差异 │ │
└───────┬───────┘ │
│ │
▼ │
┌───────────────┐ │
│ 执行操作 │ │
│ (创建1个Pod) │ │
└───────┬───────┘ │
│ │
└────────────────────────────┘
持续循环五、Node节点组件详解
5.1 kubelet
职责：Node 上的"代理人"，负责管理 Pod 生命周期。
核心功能：
-
接收 API Server 的指令
-
创建、启动、停止容器
-
监控 Pod 和容器状态
-
上报节点和 Pod 状态
┌─────────────────────────────────────────────────────────────┐
│ Node │
├─────────────────────────────────────────────────────────────┤
│ │
│ API Server ◄────────────────► kubelet │
│ │ │
│ │ 管理 │
│ ▼ │
│ Container Runtime │
│ (containerd/Docker) │
│ │ │
│ │ 创建 │
│ ▼ │
│ ┌─────────────────────────┐ │
│ │ Pod │ │
│ │ ┌─────┐ ┌─────┐ │ │
│ │ │容器A│ │容器B│ │ │
│ │ └─────┘ └─────┘ │ │
│ └─────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘
5.2 kube-proxy
职责：Node 上的"网络管家"，负责网络代理和负载均衡。
核心功能：
-
维护网络规则（iptables/ipvs）
-
实现 Service 的负载均衡
-
转发请求到正确的 Pod
外部请求
│
▼
┌─────────────────┐
│ Service IP │
│ 10.96.0.100 │
└────────┬────────┘
│
│ kube-proxy 转发
▼
┌─────────────────────────────────────┐
│ │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐
│ │ Pod A │ │ Pod B │ │ Pod C │
│ │10.1.1.1 │ │10.1.1.2 │ │10.1.1.3 │
│ └─────────┘ └─────────┘ └─────────┘
│ │
│ 负载均衡到其中一个 Pod │
└─────────────────────────────────────┘
5.3 Container Runtime
职责：实际运行容器的组件。
常见的容器运行时：
| 运行时 | 说明 |
|---|---|
| containerd | Docker 拆分出来的，K8s 默认推荐 |
| CRI-O | 专为 K8s 设计的轻量级运行时 |
| Docker | 早期默认，现在需要通过 dockershim |
注意：K8s 1.24 版本后移除了对 Docker 的直接支持，但 Docker 构建的镜像仍然可以在 K8s 中运行。
六、核心资源对象
6.1 Pod
Pod 是什么：K8s 中最小的调度单位，包含一个或多个容器。
为什么不直接调度容器？
因为有些场景需要多个容器紧密协作：
┌─────────────────────────────────────────────────────────────┐
│ Pod │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────┐ ┌─────────────────┐ │
│ │ 应用容器 │ │ 日志收集容器 │ │
│ │ (Java App) │ │ (Filebeat) │ │
│ │ │ │ │ │
│ │ 写日志到 │ │ 读取日志 │ │
│ │ /var/log/app ─┼──┼─ /var/log/app │ │
│ │ │ │ │ │
│ └─────────────────┘ └─────────────────┘ │
│ │
│ 共享网络命名空间（同一个 IP） │
│ 共享存储卷（可以访问同一个目录） │
│ │
└─────────────────────────────────────────────────────────────┘Pod 的特点：
- 同一 Pod 内的容器共享网络和存储
- Pod 是临时的，随时可能被销毁重建
- Pod 有唯一的 IP 地址
6.2 Deployment
Deployment 是什么：管理 Pod 的"上级"，负责 Pod 的创建、更新、回滚。
为什么需要 Deployment？
直接创建 Pod 的问题：
- Pod 挂了不会自动重建
- 无法方便地扩缩容
- 无法滚动更新
Deployment 的能力：
yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
spec:
replicas: 3 # 期望 3 个副本
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.20
ports:
- containerPort: 80Deployment 的工作：
Deployment (nginx-deployment)
│
│ 管理
▼
ReplicaSet (nginx-deployment-abc123)
│
│ 管理
▼
┌─────────┐ ┌─────────┐ ┌─────────┐
│ Pod 1 │ │ Pod 2 │ │ Pod 3 │
└─────────┘ └─────────┘ └─────────┘6.3 Service
Service 是什么：为 Pod 提供稳定的访问入口。
为什么需要 Service？
Pod 的 IP 是不固定的：
- Pod 重建后 IP 会变
- 多个 Pod 副本有多个 IP
- 调用方不知道该访问哪个 IP
Service 的作用：
┌─────────────────────────────────────────────────────────────┐
│ │
│ 调用方 │
│ │ │
│ │ 访问 Service IP: 10.96.0.100 │
│ ▼ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ Service │ │
│ │ (nginx-service) │ │
│ │ │ │
│ │ ClusterIP: 10.96.0.100 │ │
│ │ Port: 80 │ │
│ └──────────────────────┬──────────────────────────────┘ │
│ │ │
│ ┌─────────────┼─────────────┐ │
│ ▼ ▼ ▼ │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
│ │ Pod 1 │ │ Pod 2 │ │ Pod 3 │ │
│ │10.1.1.1 │ │10.1.1.2 │ │10.1.1.3 │ │
│ └─────────┘ └─────────┘ └─────────┘ │
│ │
│ Service 自动发现 Pod，负载均衡 │
│ │
└─────────────────────────────────────────────────────────────┘Service 类型：
| 类型 | 说明 | 使用场景 |
|---|---|---|
| ClusterIP | 集群内部访问 | 内部服务间调用 |
| NodePort | 通过节点端口暴露 | 开发测试 |
| LoadBalancer | 云厂商负载均衡器 | 生产环境对外暴露 |
| ExternalName | 映射外部服务 | 访问集群外服务 |
6.4 Ingress
Ingress 是什么：集群的"入口网关"，管理外部访问。
┌─────────────────────────────────────────────────────────────┐
│ │
│ 外部用户 │
│ │ │
│ │ https://api.example.com/users │
│ │ https://api.example.com/orders │
│ ▼ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ Ingress Controller │ │
│ │ (Nginx/Traefik) │ │
│ └──────────────────────┬──────────────────────────────┘ │
│ │ │
│ ┌───────────────┼───────────────┐ │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ /users │ │ /orders │ │ /products │ │
│ │ user-svc │ │ order-svc │ │ product-svc │ │
│ └─────────────┘ └─────────────┘ └─────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘6.5 ConfigMap 和 Secret
ConfigMap：存储非敏感配置信息
yaml
apiVersion: v1
kind: ConfigMap
metadata:
name: app-config
data:
database_host: "mysql.default.svc.cluster.local"
database_port: "3306"
log_level: "INFO"Secret：存储敏感信息（Base64 编码）
yaml
apiVersion: v1
kind: Secret
metadata:
name: db-secret
type: Opaque
data:
username: YWRtaW4= # admin
password: cGFzc3dvcmQ= # password6.6 资源对象关系图
┌─────────────────────────────────────────────────────────────┐
│ K8s 资源对象关系 │
└─────────────────────────────────────────────────────────────┘
Ingress
│
│ 路由到
▼
Service
│
│ 选择
▼
Deployment
│
│ 管理
▼
ReplicaSet
│
│ 管理
▼
Pod ◄──── ConfigMap / Secret
│
│ 包含
▼
Container七、K8s工作流程详解
7.1 部署应用的完整流程
┌─────────────────────────────────────────────────────────────┐
│ 部署应用流程 │
└─────────────────────────────────────────────────────────────┘
1. 用户执行 kubectl apply -f deployment.yaml
│
▼
2. kubectl 将请求发送给 API Server
│
▼
3. API Server 验证请求，存储到 etcd
│
▼
4. Controller Manager 检测到新的 Deployment
│
▼
5. Deployment Controller 创建 ReplicaSet
│
▼
6. ReplicaSet Controller 创建 Pod（状态：Pending）
│
▼
7. Scheduler 检测到未调度的 Pod
│
▼
8. Scheduler 选择合适的 Node，绑定 Pod
│
▼
9. 目标 Node 的 kubelet 检测到新 Pod
│
▼
10. kubelet 调用 Container Runtime 创建容器
│
▼
11. 容器启动，Pod 状态变为 Running
│
▼
12. kubelet 持续上报 Pod 状态给 API Server7.2 服务调用流程
┌─────────────────────────────────────────────────────────────┐
│ 服务调用流程 │
└─────────────────────────────────────────────────────────────┘
1. 外部用户访问 https://api.example.com/users
│
▼
2. 请求到达 Ingress Controller
│
▼
3. Ingress Controller 根据规则转发到 user-service
│
▼
4. kube-proxy 将请求负载均衡到某个 Pod
│
▼
5. Pod 中的容器处理请求
│
▼
6. 响应原路返回7.3 自动扩缩容流程
┌─────────────────────────────────────────────────────────────┐
│ 自动扩缩容流程 │
└─────────────────────────────────────────────────────────────┘
1. Metrics Server 收集 Pod 的 CPU/内存使用率
│
▼
2. HPA (Horizontal Pod Autoscaler) 获取指标
│
▼
3. HPA 发现 CPU 使用率 > 80%（超过阈值）
│
▼
4. HPA 计算需要的 Pod 数量（比如从 3 扩到 5）
│
▼
5. HPA 更新 Deployment 的 replicas 字段
│
▼
6. Deployment Controller 创建新的 Pod
│
▼
7. 新 Pod 被调度、启动
│
▼
8. 流量被分摊到更多 Pod，CPU 使用率下降7.4 故障自愈流程
┌─────────────────────────────────────────────────────────────┐
│ 故障自愈流程 │
└─────────────────────────────────────────────────────────────┘
场景：Node2 宕机，上面有 Pod-B 和 Pod-C
1. kubelet 停止上报心跳
│
▼
2. Node Controller 检测到 Node2 失联
│
▼
3. 等待超时后，标记 Node2 为 NotReady
│
▼
4. Pod-B 和 Pod-C 被标记为 Unknown
│
▼
5. ReplicaSet Controller 发现副本数不足
│
▼
6. 创建新的 Pod 替代
│
▼
7. Scheduler 将新 Pod 调度到其他健康 Node
│
▼
8. 服务恢复正常八、实战入门
8.1 安装 kubectl
bash
# macOS
brew install kubectl
# Linux
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"
chmod +x kubectl
sudo mv kubectl /usr/local/bin/
# 验证
kubectl version --client8.2 常用命令
集群信息：
bash
# 查看集群信息
kubectl cluster-info
# 查看节点
kubectl get nodes
# 查看所有命名空间
kubectl get namespacesPod 操作：
bash
# 查看 Pod
kubectl get pods
kubectl get pods -o wide # 显示更多信息
kubectl get pods -n kube-system # 指定命名空间
# 查看 Pod 详情
kubectl describe pod <pod-name>
# 查看 Pod 日志
kubectl logs <pod-name>
kubectl logs -f <pod-name> # 实时日志
# 进入 Pod
kubectl exec -it <pod-name> -- /bin/bash
# 删除 Pod
kubectl delete pod <pod-name>Deployment 操作：
bash
# 创建 Deployment
kubectl apply -f deployment.yaml
# 查看 Deployment
kubectl get deployments
# 扩缩容
kubectl scale deployment <name> --replicas=5
# 更新镜像
kubectl set image deployment/<name> <container>=<image>:<tag>
# 查看滚动更新状态
kubectl rollout status deployment/<name>
# 回滚
kubectl rollout undo deployment/<name>
# 查看历史版本
kubectl rollout history deployment/<name>Service 操作：
bash
# 查看 Service
kubectl get services
kubectl get svc
# 暴露 Deployment 为 Service
kubectl expose deployment <name> --port=80 --type=NodePort8.3 部署一个 Java 应用
步骤一：创建 Deployment
yaml
# java-app-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: java-app
labels:
app: java-app
spec:
replicas: 3
selector:
matchLabels:
app: java-app
template:
metadata:
labels:
app: java-app
spec:
containers:
- name: java-app
image: your-registry/java-app:v1
ports:
- containerPort: 8080
resources:
requests:
memory: "256Mi"
cpu: "250m"
limits:
memory: "512Mi"
cpu: "500m"
env:
- name: SPRING_PROFILES_ACTIVE
value: "prod"
- name: DB_HOST
valueFrom:
configMapKeyRef:
name: app-config
key: database_host
livenessProbe:
httpGet:
path: /actuator/health
port: 8080
initialDelaySeconds: 30
periodSeconds: 10
readinessProbe:
httpGet:
path: /actuator/health
port: 8080
initialDelaySeconds: 5
periodSeconds: 5步骤二：创建 Service
yaml
# java-app-service.yaml
apiVersion: v1
kind: Service
metadata:
name: java-app-service
spec:
selector:
app: java-app
ports:
- port: 80
targetPort: 8080
type: ClusterIP步骤三：创建 Ingress
yaml
# java-app-ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: java-app-ingress
annotations:
nginx.ingress.kubernetes.io/rewrite-target: /
spec:
rules:
- host: api.example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: java-app-service
port:
number: 80步骤四：部署
bash
kubectl apply -f java-app-deployment.yaml
kubectl apply -f java-app-service.yaml
kubectl apply -f java-app-ingress.yaml
# 查看状态
kubectl get pods -l app=java-app
kubectl get svc java-app-service
kubectl get ingress java-app-ingress九、总结
9.1 核心概念速查
| 概念 | 说明 |
|---|---|
| Cluster | K8s 集群，包含控制平面和工作节点 |
| Node | 工作节点，运行 Pod 的服务器 |
| Pod | 最小调度单位，包含一个或多个容器 |
| Deployment | 管理 Pod 的副本和更新 |
| Service | 为 Pod 提供稳定的访问入口 |
| Ingress | 集群入口网关，管理外部访问 |
| ConfigMap | 存储配置信息 |
| Secret | 存储敏感信息 |
9.2 控制平面组件
| 组件 | 职责 |
|---|---|
| API Server | 提供 API 接口，集群入口 |
| etcd | 存储集群数据 |
| Scheduler | 调度 Pod 到合适的 Node |
| Controller Manager | 确保集群状态符合期望 |
9.3 Node 组件
| 组件 | 职责 |
|---|---|
| kubelet | 管理 Pod 生命周期 |
| kube-proxy | 网络代理和负载均衡 |
| Container Runtime | 运行容器 |
9.4 K8s 的核心价值
| 能力 | 价值 |
|---|---|
| 自动化部署 | 一条命令部署整个应用 |
| 自动扩缩容 | 根据负载自动调整实例数 |
| 自我修复 | 故障自动恢复 |
| 滚动更新 | 零停机更新应用 |
| 服务发现 | 自动注册和发现服务 |
一句话总结：K8s 是容器时代的"操作系统"，让你用声明式的方式管理大规模容器化应用。
热门专栏推荐
- 服务器部署
- Agent小册
- Java基础合集
- Python基础合集
- Go基础合集
- 大数据合集
- 前端小册
- 数据库合集
- Redis 合集
- Spring 全家桶
- 微服务全家桶
- 数据结构与算法合集
- 设计模式小册
- 消息队列合集
等等等还有许多优秀的合集在主页等着大家的光顾，感谢大家的支持
文章到这里就结束了，如果有什么疑问的地方请指出，诸佬们一起来评论区一起讨论😊
希望能和诸佬们一起努力，今后我们一起观看感谢您的阅读🙏
如果帮助到您不妨3连支持一下，创造不易您们的支持是我的动力🌟