K8s实验专有名词+核心原理全解（零基础版）

一、先搞懂所有关键专有名词（按出现顺序）

1. 核心基础概念

名词	大白话解释	类比
Kubernetes(K8s)	一个自动化管理容器的平台，负责容器的部署、调度、扩容、故障恢复等	一个大型工厂的"总调度系统"，管理所有工人(容器)的工作
容器	把应用和它的所有依赖打包在一起的轻量级运行环境	一个"集装箱"，里面装着你的应用和所有需要的工具，走到哪都能直接运行
镜像	容器的"模板"，是只读的，一个镜像可以创建无数个相同的容器	工厂里的"模具"，用同一个模具可以生产出无数个相同的产品
镜像仓库	存储镜像的地方，类似代码的GitHub	“集装箱仓库”，存放各种不同的集装箱模板

2. K8s集群架构组件

名词	大白话解释	类比
控制节点(Master)	集群的"大脑"，负责管理整个集群	工厂的"厂长办公室"，制定生产计划、调度工人、监控生产
工作节点(Worker/Node)	集群的"干活的"，负责实际运行容器	工厂的"车间"，所有的生产任务都在这里执行
kubeadm	官方提供的快速搭建K8s集群的工具	“工厂搭建工具包”，一键帮你建好厂房、办公室、生产线
kubelet	运行在每个节点上的代理，负责管理本节点上的容器	每个车间的"车间主任"，执行厂长的命令，管理本车间的工人
kubectl	K8s的命令行工具，用户通过它和集群交互	“厂长的对讲机”，你通过它给集群下达各种命令
etcd	K8s集群的数据库，存储集群的所有状态信息	工厂的"档案室"，保存所有生产计划、工人信息、设备状态
kube-apiserver	集群的唯一入口，所有请求都必须经过它	工厂的"传达室"，所有人的请求都要先到这里，再转交给相应部门
kube-controller-manager	负责管理集群的各种控制器，确保集群状态符合预期	工厂的"生产总监"，监督生产进度，确保任务按时完成
kube-scheduler	负责调度Pod到合适的工作节点上运行	工厂的"调度员"，根据各个车间的负载情况，分配生产任务
kube-proxy	运行在每个节点上，负责实现Service的网络功能	工厂的"前台接待"，负责把外部请求转发给对应的工人

3. 网络相关概念

名词	大白话解释	类比
Pod	K8s中最小的部署单位，一个Pod可以包含一个或多个容器	工厂里的"工人小组"，通常一个小组只有一个工人(容器)，特殊情况会有多个
Service	为一组Pod提供固定的访问入口和负载均衡	工厂的"部门前台"，外部人员不用知道具体哪个工人在干活，只需要找前台就行
CNI(容器网络接口)	K8s定义的一套网络标准，第三方网络插件都要遵循它	工厂的"网络布线标准"，所有网络设备都要按照这个标准来布线
Calico	一个流行的K8s网络插件，实现Pod之间的通信和网络策略	工厂的"网络工程师"，负责搭建整个工厂的内部网络
CoreDNS	K8s集群内部的DNS服务器，负责解析Service名称到IP地址	工厂的"电话簿"，你只要知道部门名称，就能查到对应的电话号码
IPVS	Linux内核中的一个高性能负载均衡模块，kube-proxy可以用它来实现Service	工厂的"高级交换机"，比普通交换机(iptables)速度更快、性能更好
iptables	Linux内核中的一个防火墙和网络地址转换模块，kube-proxy默认用它	工厂的"普通交换机"，功能简单，适合小规模场景

4. 其他重要概念

名词	大白话解释	类比
containerd	一个轻量级的容器运行时，负责管理容器的生命周期	工厂里的"工人管理系统"，负责工人的招聘、上岗、下岗
Docker	一个完整的容器平台，包含镜像构建、容器运行等功能	一个"全能工人管理系统"，但K8s现在只需要它的容器运行时部分
cgroup	Linux内核中的一个功能，用于限制进程的资源使用(CPU、内存等)	工厂的"资源分配器"，给每个工人分配固定的工作台和工具
证书	用于K8s集群内部组件之间的身份验证和加密通信	工厂的"工作证"，只有持有有效工作证的人才能进入工厂和各个部门
污点(Taint)	给节点打上的一个标记，阻止Pod调度到该节点上	工厂里的"特殊车间"，只有特定的工人才能进入工作
标签(Label)	给K8s资源打上的键值对标记，用于筛选和分类	工厂里的"工牌"，上面写着工人的部门、工种、技能等信息

二、整个实验的核心原理

1. 实验整体目标

搭建一个3节点的K8s集群(1个控制节点+2个工作节点)，实现：

• 容器的自动化部署和管理
• Pod之间的跨节点通信
• Pod到外部网络的通信
• 内部Service的DNS解析

2. 实验步骤拆解及原理

阶段1：环境准备（所有节点执行）

这一步是给K8s运行创造一个合适的操作系统环境，就像建工厂之前要先平整土地、通水电。

步骤	为什么要这么做？	原理
安装基础包	安装K8s和containerd运行需要的依赖工具	就像建工厂需要先准备好水泥、钢筋、电线等材料
关闭SELinux	SELinux是Linux的安全机制，会限制容器的访问权限	相当于先把工厂的"严格安检"暂时关掉，避免工人无法正常工作
配置主机名和hosts	让集群中的节点能够通过主机名互相访问	就像给每个车间起个名字，大家不用记复杂的IP地址
关闭交换分区(swap)	K8s强制要求关闭交换分区，否则会导致性能严重下降和不稳定	工厂要求工人必须用自己的工作台(物理内存)，不能用临时桌子(交换分区)，否则会影响工作效率
修改内核参数	启用Linux的网桥和IP转发功能，这是容器网络通信的基础	相当于给工厂安装好网络交换机和路由器，让各个车间之间能够通信
关闭防火墙	避免防火墙阻止K8s组件之间的通信	相当于先把工厂的"大门"打开，让各个部门之间能够自由往来
配置时间同步	K8s集群中的所有节点时间必须一致，否则证书验证会失败	就像工厂里所有的钟表都要对准北京时间，否则上下班时间会混乱

阶段2：安装容器运行时containerd

K8s本身不直接运行容器，它需要一个容器运行时来管理容器的生命周期。从K8s 1.24版本开始，官方默认使用containerd作为容器运行时，不再支持Docker。

为什么用containerd不用Docker？

• containerd更轻量，性能更好，资源占用更少
• containerd直接实现了K8s的CRI(容器运行时接口)标准，不需要额外的转换层
• Docker其实底层也是用的containerd

这一步的原理就是：安装containerd，配置好镜像加速，让它能够快速拉取和运行容器镜像。

阶段3：安装K8s组件

在所有节点上安装kubeadm、kubelet和kubectl：

• kubeadm：用来初始化集群和加入节点
• kubelet：运行在每个节点上，管理本节点的容器
• kubectl：用来和集群交互的命令行工具

安装完成后，kubelet会被设置为开机自启，但此时它还没有加入集群，处于等待状态。

阶段4：初始化控制节点

在控制节点上执行kubeadm init命令，这是整个实验最核心的一步。

kubeadm init到底做了什么？

1. 预检查：检查系统是否满足K8s运行的要求
2. 生成证书：生成集群内部所有组件通信需要的证书
3. 生成配置文件：生成kubelet、kube-proxy等组件的配置文件
4. 启动控制平面组件：以Pod的形式启动apiserver、controller-manager、scheduler和etcd
5. 生成加入命令：生成工作节点加入集群需要的token和命令
6. 安装CoreDNS：安装集群内部的DNS服务器

初始化完成后，你会得到一个kubeadm join命令，这个命令就是工作节点加入集群的"入场券"。

阶段5：加入工作节点

在工作节点上执行kubeadm join命令，工作节点就会加入集群。

kubeadm join到底做了什么？

1. 和控制节点的apiserver建立连接，进行身份验证
2. 下载并安装必要的组件
3. 启动本节点的kubelet和kube-proxy
4. 向控制节点注册自己，成为集群的一部分

加入完成后，你在控制节点上执行kubectl get nodes就能看到所有的节点了。

阶段6：安装网络插件Calico

这是非常关键的一步，如果不安装网络插件，K8s集群是无法正常工作的。

为什么必须安装网络插件？
K8s本身只定义了网络标准(CNI)，但不提供具体的网络实现。它需要第三方网络插件来实现：

• Pod之间的跨节点通信
• Pod和Service之间的通信
• Pod到外部网络的通信

Calico的工作原理：
Calico使用BGP协议和Linux内核路由来实现Pod之间的通信，不需要额外的封包和解包，性能非常高。它还支持网络策略，可以实现Pod之间的访问控制。

安装Calico后，所有节点上的Calico组件会自动配置网络路由，让整个集群的Pod网络连通起来。

阶段7：验证集群

最后一步是验证集群是否正常工作：

1. 执行kubectl get nodes，所有节点状态都应该是Ready
2. 执行kubectl get pods -n kube-system，所有系统Pod都应该是Running状态
3. 创建一个测试Pod，测试Pod到外部网络的连通性(ping www.baidu.com)
4. 测试CoreDNS的解析功能(nslookup kubernetes.default.svc.cluster.local)

如果所有测试都通过，说明你的K8s集群已经搭建成功了！

三、K8s集群的完整工作流程

现在你已经了解了所有组件和步骤，我们来梳理一下一个Pod从创建到运行的完整流程：

1. 用户通过kubectl run命令提交一个Pod创建请求
2. kubectl把请求发送给kube-apiserver
3. kube-apiserver验证请求的合法性，然后把Pod信息存储到etcd中
4. kube-scheduler发现有一个新的未调度的Pod
5. kube-scheduler根据调度算法，选择一个最合适的工作节点来运行这个Pod
6. kube-scheduler把调度结果更新到etcd中
7. 目标节点的kubelet从apiserver获取到这个Pod的信息
8. kubelet调用containerd创建并启动Pod中的容器
9. kube-proxy配置相应的网络规则，让这个Pod能够被访问到
10. Pod启动完成后，kubelet把Pod的状态更新到apiserver
11. 用户通过kubectl get pods命令就可以看到这个Pod已经在运行了

这就是K8s集群的核心工作原理，所有的操作都是围绕这个流程展开的。

开启k8s终端代码补全

1. 先装补全依赖（必须）

运行

yum install -y bash-completion

---

2. 临时生效（当前终端立刻能用）

运行

# 加载系统补全
source /etc/profile.d/bash_completion.sh

# 加载 kubectl 补全
source <(kubectl completion bash)

现在敲：

运行

kubectl g<Tab>

应该自动补成 get。

---

3. 永久生效（以后开终端自动有）

bash

运行

echo "source /etc/profile.d/bash_completion.sh" >> ~/.bashrc
echo "source <(kubectl completion bash)" >> ~/.bashrc

# 立刻让当前终端也永久生效
source ~/.bashrc