Kubernetes 架构原理与集群环境部署

Kubernetes 是谷歌以 Borg 为前身，基于谷歌 15 年的生产环境经验开源的一个项目。Kubernetes是一个开源的，用于管理云平台中多个主机上的容器化的应用，Kubernetes 致力于提供跨主机集群的自动部署、扩展、高可用以及运行应用程序容器的平台,其遵循主从式架构设计、组件可以分为工作节点(Node组件，和控制平面组件。Kubernetes Master 是集群的主要控制单元，用于管理工作负载并指导整个系统的通信。Kubernetes 控制平面由各自的进程组成，没个组件都可以在单个节点上运行，也可以在支持高可用集群的多个节点上运行。

一：为什么需要kubernetes

很多人会有疑问，有了 Docker 为什么还用 Kubernetes?

在业务开始进行容器化时，前期需要容器化的项目可能并不多，涉及的容器也并不多，此时基于Docker 容器直接部署至宿主机也能实现基本的需求。但是随着项目越来越多，管理的容器也会越来越多,此时使用"裸容器"部署的方式管理起来就显得很吃力，并且随着业务量的增加，会明显体会到"裸容器的不足。比如:

宿主机宕机造成该宿主机上的容器不可用，且无法自动恢复。

容器明明在运行，接口就是不通(健康检查做得不到位)

应用程序部署、回滚、扩缩容困难。

成百上千的容器和涉及的端口难以维护。

上面的问题知识做一个简单的罗列，真正使用时还有很多其他的问题。大家也可能使用过Docker-compose、Docker-swarm 等编排工具，但是这些工具的功能和 Kubernetes 比起来还是相差很多的。所以注定 Kubernetes 编排工具将成为主流的容器编排工具。

1:对于开发人员

对比维度	使用 Kubernetes 之前	使用 Kubernetes 之后	改进点
日志查看	需手动定位机器和容器，操作繁琐。	通过 Dashboard 直接定位 Namespace 和容器，一键查看日志。	操作时间大幅减少，无需运维介入。
环境隔离	多环境（开发、测试、预生产）物理隔离，资源利用率低。	多环境通过 Namespace 隔离，共享集群资源，成本优化。	资源利用率提高，成本降低。
发布与回滚	手动操作，易出错，流程复杂。	通过 Jenkins/Git 实现自动化发布、回滚，支持蓝绿/金丝雀发布。	发布效率提升，减少人为错误。
环境一致性	各环境配置差异大，易出现"开发正常，测试失败"问题。	一次构建多环境部署，通过参数/变量/配置区分环境。	提升环境一致性，减少部署问题。
服务网络功能	需在代码中实现网络逻辑（如负载均衡、限流）。	由服务网格（如 Istio）自动处理，开发仅关注业务逻辑。	代码复杂度降低，网络功能标准化。
测试环境创建	依赖运维手动搭建或审批，耗时长。	开发人员通过 Jenkins 自助创建临时环境，秒级完成。	测试效率提升，减少运维负担。
资源成本	非生产环境独立占用资源，浪费严重。	多环境共享集群资源，按需分配。	硬件成本显著降低。
故障排查	需登录服务器查看日志和状态，依赖经验。	集成监控工具（如 Prometheus+Grafana），实时可视化排查。	故障定位速度加快。

2：对于运维人员

运维场景	传统架构下的痛点	Kubernetes 解决方案	核心改进
环境部署	需手动安装系统、依赖、配置网络，耗时长且易遗漏。	通过 Helm/Operator 一键部署完整环境，开发人员可自助操作（Jenkins/平台）。	部署时间从小时级降至分钟级，减少人为错误。
故障恢复	依赖人工排查和修复，响应慢；服务器宕机需手动迁移。	自动健康检查（Liveness/Readiness），故障节点自愈或重启；Pod 自动漂移。	故障恢复时间从小时级缩短至秒级，运维被动告警减少。
扩缩容	需采购服务器、上架、部署依赖，流程复杂且资源浪费。	基于 HPA（Horizontal Pod Autoscaler）自动扩缩容，无需人工干预。	资源利用率提升 50%+，弹性响应业务峰值。
负载均衡	需手动配置 Nginx/LVS 规则，添加节点需同步更新配置。	Service + Ingress 自动管理流量，动态适配后端节点变化。	配置复杂度降低 90%，支持自动 SSL 和路径重写等高级功能。
高可用	需搭建 Keepalived、检测脚本等工具，维护成本高。	内置高可用机制（多副本调度、节点亲和性），进程/接口级自动恢复。	彻底免去高可用工具维护，服务可用性达 99.9%+。
中间件管理	手动部署集群（如 Redis、ZK），扩容需停机，易配置错误。	StatefulSet + Operator 实现中间件集群一键部署、动态扩缩容。	中间件部署时间从天级降至分钟级，支持无损扩容。
端口与网络	需人工分配端口，处理冲突；防火墙规则复杂。	Service 统一暴露端口，ClusterIP 内部通信，无需关心端口冲突。	网络配置标准化，彻底解决端口冲突问题。
配置管理	配置文件分散在多台服务器，易不一致。	ConfigMap + Secret 集中管理配置，支持动态注入和版本回滚。	配置变更可追溯，环境一致性保障。
监控与日志	需手动搭建 ELK/Prometheus，日志分散难聚合。	集成 Prometheus-Operator、EFK 等方案，提供开箱即用的监控和日志收集。	运维可快速定位问题，监控覆盖率提升至 100%。

二：kubernetes带来的挑战

挑战类别	具体问题描述	影响范围	应对策略
学习曲线陡峭	概念复杂（如 Pod、Service、Ingress、CRD 等），知识面广（网络、存储、调度等）。	新手运维/开发人员	- 分阶段学习：先掌握核心概念（Deployment、Service），再逐步深入。 - 使用 MiniKube/Kind 快速搭建实验环境。
技术能力要求高	需具备 DevOps 技能（CI/CD、监控、日志），甚至需理解业务代码和编译发布流程。	传统运维转型人员	- 组织内部培训，建立知识共享体系。 - 引入自动化工具（Helm、Kustomize）降低配置复杂度。
集群管理复杂度	生产级集群搭建和维护困难（高可用、证书管理、版本升级）。	运维团队	- 使用托管 Kubernetes 服务（如 EKS、ACK）减少底层维护。 - 采用 GitOps 管理集群状态（如 ArgoCD）。
调试与排障困难	分布式系统问题定位复杂（网络策略、存储卷故障、调度失败等）。	开发/运维团队	- 集成可视化工具（Lens、K9s）。 - 完善监控告警体系（Prometheus + Grafana + Alertmanager）。
安全风险	配置不当可能导致安全漏洞（如 RBAC 权限过宽、Secret 未加密）。	安全/运维团队	- 遵循最小权限原则。 - 定期扫描镜像漏洞（Trivy）和配置审计（OPA/Gatekeeper）。
资源成本控制	过度分配资源（CPU/内存）或未充分利用节点资源。	财务/运维团队	- 设置 Requests/Limits 并启用 HPA。 - 使用 VPA（Vertical Pod Autoscaler）优化资源分配。
跨团队协作压力	开发、运维、测试需共同适应声明式 API 和容器化流程，沟通成本增加。	整个技术团队	- 制定标准化模板（Helm Charts）和文档。 - 建立 CI/CD 流水线统一流程。

三：kubernetes架构解析

首先我们来看一下 Kubernetes 的架构图:

由图可知，Kubernetes 架构可以简单分为主(master)节点,从(worker/node)节点和数据库 ETCD其中主节点为集群的控制单元，一般不会运行业务应用程序，主要包含的组件Kube-APIServer、Kube-ControllerManager、Kube-Scheduler。从节点为工作节点，也就是部署应用程序容器的节点,主要包含的组件有 Kubelet、Kube-Proxy，当然如果 master 节点也要部署容器，也会包含这两个组件。

同时，可以看出一个集群中可以有多个 node 节点，用于保证集群容器的分布式部署，以保证业务的高可用性，也可以有很多的 master 节点，之后通过一个负载均衡保证集群控制节点的高可用。负载均衡可以使用软件负载均衡 Nginx、LVS、Haproxy+Keepalived 或者硬件负载均衡 F5 等，通过负载均衡对Kube-APIServer 提供的 VIP 即可实现 master 节点的高可用，其他组件通过该 VIP 连接至Kube-APIServer。ETCD 集群可以和 master 节点部署在同一个宿主机，也可以单独部署，生产环境建议部署大于3的奇数台 ETCD 节点用于实现 ETCD 集群的高可用。etcd 的 Leader 选举和数据写入都需要半数以上的成员投票通过确认，因此，集群最好由奇数个成员组成，以确保集群内部一定能够产生多数投票通过的场景。这也就是为什么 etcd 集群至少需要 3 个以上的成员。

1：master节点的组件

master 节点是 Kubernetes 集群的控制节点，在生产环境中不建议部署集群核心组件外的任何容器(在 kubeadm 安装方式下，系统组件以容器方式运行在 master 节点的宿主机上;二进制安装方式下，系统组件以守护进程的方式运行，master 节点可以不运行任何容器)，公司业务程序的容器是不建议部署在 master节点上，以免升级或者维护时对业务在成影响。

（1）Master 节点核心组件功能对比表

组件	核心功能	关键特性	与其他组件的交互
API Server	- 集群的网关和控制中枢 - 提供 RESTful API 供客户端访问（kubectl/UI） - 数据持久化到 etcd	- 支持水平扩展 - 认证/授权/准入控制（RBAC） - 唯一直接与 etcd 交互的组件	- 所有组件（如 Scheduler、Controller Manager）通过 API Server 获取集群状态
Scheduler	- 将 Pod 调度到合适的 Node - 基于资源请求、亲和性等策略选择节点	- 支持自定义调度器 - 实时监控未调度 Pod	- 监听 API Server 的 Pod 创建事件 - 通过 API Server 更新 Pod 的 Node 绑定信息
Controller Manager	- 维护集群状态（如副本数、节点状态） - 运行多种控制器（Deployment、DaemonSet 等）	- 多控制器合并为单一进程 - 持续调和实际状态与期望状态	- 通过 API Server 监听资源变更 - 触发自动化操作（如扩容、故障恢复）
etcd	- 存储集群所有配置和状态数据 - 提供分布式键值存储和高可用性	- 基于 Raft 协议实现一致性 - 要求奇数节点（最少 3 个） - 数据持久化	- 仅 API Server 可直接读写 etcd - 其他组件通过 API Server 间接访问 etcd 数据

（2）etcd 集群设计原则总结表

设计原则	原因说明	生产环境建议
奇数节点数量	- Raft 协议要求多数投票（N/2+1） - 3 节点容错 1 节点，5 节点容错 2 节点	- 最少 3 节点（测试环境可单节点） - 大规模集群建议 5/7 节点
避免偶数节点	- 偶数节点可能引发选举僵局（如 2 节点分裂时无法达成多数） - 容错能力与 N-1 相同	- 永远选择奇数节点（如 3 而非 4）
高可用部署	- 节点分散在不同可用区（AZ） - 避免单点故障	- 跨 AZ 部署 etcd - 与 Master 节点分离（降低资源竞争）
性能优化	- 写操作需多数节点确认 - 磁盘 I/O 影响性能	- 使用 SSD 磁盘 - 限制 etcd 数据量（定期压缩历史数据）
安全配置	- 存储敏感数据（如 Secrets）	- 启用 TLS 双向认证 - 定期备份 etcd 数据

2：Node节点包含的组件

Node 节点也被成为 worker 节点，是主要负责部署容器的主机，集群中的每个节点都必须具备容器的Runtime(运行时)，比如docker

kubelet 作为守护进程运行在 Node 节点上，负责监听该节点上所有的 pod，同时负责上报该节点上所有 pod 的运行状态，确保节点上的所有容器都能正常运行。当 Node 节点宕机或故障时，该节点上运行的 pod 会被自动转移到其他节点上。

组件	核心功能	关键特性	与其他组件的交互
kube-proxy	- 实现 Service 的负载均衡和网络代理 - 维护节点上的 iptables/IPVS 规则 - 提供集群内部服务发现	- 支持三种代理模式：userspace/iptables/IPVS - 确保 Pod 的 IP 可路由	- 监听 API Server 的 Service/Endpoint 变更 - 与容器网络插件（CNI）协同工作
kubelet	- 管理节点上 Pod 的生命周期（创建/销毁） - 监控容器健康状态并上报 - 挂载存储卷（CVI）和网络（CNI）	- 唯一直接与容器运行时交互的组件 - 执行 PodSpec 中定义的配置	- 从 API Server 接收 Pod 调度指令 - 向 API Server 报告节点和 Pod 状态
容器运行时	- 拉取镜像并运行容器（如 Docker/containerd） - 管理容器生命周期（启动/停止）	- 通过 CRI（Container Runtime Interface）与 kubelet 交互 - 支持 OCI 标准镜像	- 由 kubelet 通过 CRI 调用 - 依赖底层操作系统内核功能（如 cgroups/namespaces）

核心组件协作流程

kube-proxy 工作模式对比

模式	原理	性能	适用场景
userspace	代理转发（低效）	差	历史遗留（已淘汰）
iptables	内核级规则匹配（默认）	中	中小规模集群
IPVS	基于内核哈希表（高性能负载均衡）	高	大规模集群/高并发场景

3：kubernetes网络插件

特性	Flannel	Calico	适用场景
网络模型	Overlay（默认 VXLAN）	Underlay（BGP 路由）	- Flannel：简单场景 - Calico：高性能/安全敏感场景
性能	- 中等（VXLAN 封装开销） - UDP 模式性能较差	- 高（无封装，直接路由）	Calico 适合高吞吐低延迟业务（如金融交易）
配置复杂度	- 简单，默认配置即可工作	- 中等，需配置 BGP 或 IPIP 隧道	Flannel 适合快速 PoC 验证
依赖条件	- VXLAN 需 Linux 内核 ≥3.7 - host-gateway 需二层互通	- BGP 需路由器支持或配置 Route Reflector	老旧内核优先选 Flannel
网络策略	❌ 不支持	✅ 支持（需启用 `calico-network-policy`）	需网络隔离时必选 Calico
服务网格集成	❌ 无原生支持	✅ 深度集成 Istio（可视化流量拓扑）	微服务架构推荐 Calico
IPAM	- 简单 IP 分配（节点子网）	- 灵活 IP 池管理	大规模集群优选 Calico
典型后端	- VXLAN（推荐） - UDP（测试用） - host-gateway（需二层网络）	- BGP（生产首选） - IPIP（跨子网隧道）	云环境优先 VXLAN/BGP
适用规模	≤100 节点	≥100 节点	超大规模集群可考虑 Cilium
安全能力	❌ 仅基础通信	✅ 支持 NetworkPolicy（基于标签的微隔离）	多租户集群必选 Calico

四:Kubeadm 快速安装 Kubernetes 集群

1.本节实验环境

本节采用 Kubeadm 方式来安装 Kubernetes 集群,实验环境包括一台 master 节点,两台 node 节

点。

主机名	IP 地址	操作系统	硬件配置	主要软件组件	角色
k8s-master	192.168.10.101	Euler24	2核 CPU 4G 内存	- Docker CE - Kube-apiserver - Kube-controller-manager - Kube-scheduler - Kubelet - Etcd - Kube-proxy	Master 节点（控制平面）
k8s-node01	192.168.10.102	Euler24	2核 CPU 2G 内存	- Docker CE - Kubectl - Kube-proxy - Calico	Worker 节点（计算节点）
k8s-node02	192.168.10.103	Euler24	2核 CPU 2G 内存	- Docker CE - Kubectl - Kube-proxy - Calico	Worker 节点（计算节点）

备注:

依据案例环境为三台主机配置 P 地址、网关、DNS 等基础信息，确保可连接互联网，推荐虚拟机使用 NAT 模式。k8s-master 主机最小建议配置为 2核 46，k8s-node 节点最小建议配置为2 核 2G。

Kubernetes v1.23 支持高达 5000 节点。更准备地说，在使用 Kubernetes 时，应当遵循以下所有准则:

每个节点不要超过 110个Pod,

集群不要超过 5000 节点，

集群不要超过150000个Pod,

不要超过 300000个Container。

2.实验要求

本节的实验要求:通过 Kubeadm 实现快速部署 Kubernetes 集群

3.实现思路

本节实验的实现思路如下:

(1)部署三台主机的基础环境。

(2)部署三台主机的 Docker 环境。

(3)通过 Kubeadm 快速部署 Kubernetes 集群。

4:基础环境准备(此步骤在三个节点都执行)

正式开始部署 kubernetes 集群之前，先要进行如下准备工作。基础环境相关配置操作在三台主机k8s-master、k8s-node01、k8s-node02上都需要执行，下面以 k8s-master 主机为例进行操作演示。

5:部署 docker 环境

完成基础环境准备之后，在三台主机上分别部署 Docker 环境，因为 Kubernetes 对容器的编排需要 Docker 的支持。以 k8s-master 主机为例进行操作演示，首先安装一些 Docker 的依赖包，然后将Docker 的 YUM 源设置成国内地址，最后通过 YUM 方式安装 Docker 并启动。

(1)关闭防火墙

复制代码

systemctl stop firewalld
systemctl disable firewalld

(2)禁用 SELinux

复制代码

sed -i/^SELINUX=/s/enforcing/disabled/' /etc/selinux/config
setenforce 0

(3)安装docker(已有 Docker 环境的忽略此步骤)

步骤 1:关闭系统防火墙

复制代码

systemctl stop firewalld

systemctl disable firewalld

setenforce 0
sed -i's/=enforcing/=disabled/'/etc/selinux/config

步骤 2:下载 Docker 的 repo 文件

复制代码

cur1 -o /etc/yum.repos.d/docker-ce.repohttps://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo

步骤 3:替换仓库地址

复制代码

sed -i's/$releasever/8/g"/etc/yum.repos.d/docker-ce.repo
sed -i 's/$basearch/x86 64/g"/etc/yum.repos.d/docker-ce.repo

步骤 4:更新索引文件井安装 Docker

复制代码

dnf clean all
dnf makecache
dnf -y install docker-ce

步骤 5:添加国内镜像站

由于工信部网络政策调整，docker.io、gcr.io 等国际镜像站的访问受限，无法使用这些国外的镜像站拉取镜像，因此我们需要设置国内的镜像站。

bash 复制代码

mkdir /etc/docker/
cat>/etc/docker/daemon.json<<EOF
{
"exec-opts": ["native.cgroupdriver=systemd"],
"registry-mirrors":[
"https://docker.m.daocloud.io",
"https://docker.imgdb.de",
"https://docker-0.unsee.tech",
"https://docker.hlmirror.com'
]
}
EOF

步骤 6:开启 Docker 服务

bash 复制代码

systemctl daemon-reload
systemctl restart docker
systemctl enable docker
docker version

步骤 7:优化内核参数

bash 复制代码

cat>>/etc/sysctl.conf <<EOF
net.ipv4.ip forward=1
net.bridge.bridge-nf-call-ip6tables =1
net.bridge.bridge-nf-call-iptables =1
EOF


sysctl -p

备注:问题分析:

docker 的 cgroup 驱动程序默认设置为 Cgroupfs。默认情况下Kubernetes cgroup 驱动为 systemd.

我们需要更改 Docker cgroup 驱动。

Kubernetes 的默认驱动和 docker 的驱动是一致的。因为多数 Linux 发行版的 cgroup 的驱动为systemd，所以当再选择 cgroupfs 作为驱动时，会致使操作系统中存在两个 cgroup 驱动，会带来不稳定的影响。所以在系统已经使用 systemd 的基础上，配置不推荐使用 cgroupfs，直接使用 systemd 即可。

**修改方法:**在 daemon.json 中添加"exec-opts":["native.cgroupdriver=systemd"]

cgroup 全称是 control groups

control groups:控制组，被整合在了 1inux内核当中，把进程(tasks)放到组里面，对组设置权限,对进程进行控制。可以理解为用户和组的概念，用户会继承它所在组的权限。cgroups是 1inux 内核中的机制，这种机制可以根据特定的行为把一系列的任务，子任务整合或者分离,按照资源划分的等级的不同，从而实现资源统一控制的框架，cgroup 可以控制、限制、隔离进程所需要的物理资源，包括 cpu、内存、IO，为容器虚拟化提供了最基本的保证，是构建 docker 一系列虚拟化的管理工具