目录
开头专业总结
一、先搞懂：K8s 到底是什么？能解决什么痛点？
1. K8s 的本质
2. 核心用处（解决的痛点）
二、K8s 核心知识点：组件与概念（标重点！）
（一）集群核心组件（K8s 的 “器官”）
（二）核心概念（K8s 的 “词汇表”）
三、实际应用场景：K8s 到底用在哪？
四、简单示例：用 K8s 部署一个 Nginx
1. 编写 Deployment YAML（定义 Nginx 应用）
2. 编写 Service YAML（给 Nginx 分配固定地址）
3. 执行命令部署并验证
五、K8s 常用使用方法（从安装到运维）
1. 集群安装（以 kubeadm 为例，最常用的方式）
2. 日常运维常用命令
六、常见问题及解决方法（排障必备）
1. 问题：Pod 一直处于 Pending 状态
2. 问题：Service 访问不到 Pod
3. 问题：节点处于 NotReady 状态
七、难点段子解读：让硬核概念变通俗
1. 难点：etcd 的 “一致性” 是什么意思？
2. 难点：Deployment 和 StatefulSet 的区别？
3. 难点：kube-proxy 的 “Service 转发” 怎么实现？
结尾专业总结
开头专业总结
Kubernetes（简称 K8s）是云原生时代的 “容器编排事实标准”，核心价值是解决大规模容器的部署、调度、运维自动化问题—— 它能让零散的容器像 “军队” 一样有序运行，避免人工管理的混乱与失误。无论是微服务架构落地、跨环境应用一致性保障，还是高可用集群搭建，K8s 都是底层核心支撑，目前已成为企业级云原生部署的 “标配工具”。
一、先搞懂：K8s 到底是什么？能解决什么痛点？
1. K8s 的本质
K8s 是 Google 基于 Borg（内部容器编排系统）开源的容器编排平台，简单说就是 “容器的管家”：你把容器交给它，它负责 “安排住宿（调度到节点）、看病（健康检查）、换班（滚动更新）、扩招（扩容）”，全程不用你手动干预。
2. 核心用处（解决的痛点）
- 痛点 1：容器太多管不过来
单机跑 10 个容器还行，跑 1000 个时，手动启停、监控、故障恢复会累死 ——K8s 能自动化管理所有容器，故障时自动重启，不用人盯。 - 痛点 2：应用要高可用，不能单节点挂了就跪
K8s 能把容器分散到多个节点（服务器），一个节点挂了，其他节点自动接管，应用不中断。 - 痛点 3：微服务部署复杂，服务间通信乱
K8s 的 Service、Ingress 等组件能统一管理服务访问，不管容器怎么动，外部访问地址不变，解决 “服务漂移” 问题。 - 痛点 4：环境不一致，开发测好生产崩
K8s 用 YAML 定义应用配置，一次编写可在开发、测试、生产环境复用，避免 “我这好的，到你那就崩了”。
二、K8s 核心知识点：组件与概念（标重点！）
（一）集群核心组件（K8s 的 “器官”）
1. 控制平面组件（Master 节点，集群 “大脑”）
- APIServer：★★★★★ 唯一入口！所有操作（如部署应用、查 Pod 状态）都通过它，像 “前台接待”，接收请求后交给其他组件处理。
- etcd：★★★★★ 集群 “数据库”！存储所有集群配置和状态（如 Pod 在哪、Service 地址），是 K8s 的 “记忆中枢”，必须高可用（多节点备份）。
- Scheduler：★★★★ 容器 “调度员”！根据节点资源（CPU、内存）、亲和性规则等，给新创建的 Pod 分配 “住宿节点”（比如 “内存剩得多的节点优先”）。
- Controller Manager：★★★★ 状态 “监控官”！负责维护集群状态，比如 Deployment 控制器确保 Pod 数量符合预期（少了就新建，多了就删除）、Node 控制器监控节点健康。
2. 节点组件（Worker 节点，集群 “手脚”）
- kubelet：★★★★★ 节点 “管家”！在每个 Worker 节点运行，确保容器按 Pod 定义的规则启动并正常运行，还会向 APIServer 汇报节点状态（比如 “我这 CPU 用了 80%”）。
- kube-proxy：★★★★ 网络 “路由器”！在每个节点运行，负责 Service 的网络转发（比如把外部请求转发到对应的 Pod），实现 “服务 IP 不变，Pod 可漂移”。
- 容器运行时（CRI）：★★★★ 容器 “发动机”！比如 Docker、containerd，负责实际创建和运行容器（K8s 本身不跑容器，靠它干活）。
（二）核心概念（K8s 的 “词汇表”）
- Pod：★★★★★ 最小部署单元！K8s 不直接管理容器，而是把 1 个或多个 “紧密关联” 的容器打包成 Pod（比如 “前端容器 + 日志收集容器”），Pod 里的容器共享网络和存储，像 “夫妻合租一间房，资源共用”。
- Deployment：★★★★★ 无状态应用 “部署模板”！最常用的控制器，负责创建 Pod、滚动更新（比如从 Nginx 1.20 更到 1.24，不中断服务）、回滚（更新崩了就切回旧版本）。适合无状态应用（如 Web 服务，不用保存数据）。
- StatefulSet：★★★★ 有状态应用 “专属控制器”！适合需要固定身份、存储的应用（如 MySQL、Redis 集群）—— 它给每个 Pod 分配固定名称和存储，即使 Pod 重建，身份和数据也不变（像 “学区房，房号固定，家具（数据）不丢”）。
- Service：★★★★ 服务 “固定地址”！Pod 会漂移（比如重建后 IP 变了），Service 给一组 Pod 分配一个固定虚拟 IP（ClusterIP），外部访问 Service 即可，不用管 Pod IP 怎么变。
- ConfigMap/Secret：★★★★ 配置管理工具！
- ConfigMap：存明文配置（如 Nginx 的 conf 文件、应用的环境变量），修改时不用改应用代码，直接更 ConfigMap。
- Secret：存敏感信息（如数据库密码、API 密钥），会把明文加密存储，比直接写在 YAML 里安全。
- Namespace：★★★ 资源 “隔离墙”！把集群分成多个 “虚拟空间”（如 dev、test、prod），避免不同环境的资源冲突（比如 dev 的 Nginx 和 prod 的 Nginx 不会重名）。
- Ingress：★★★★ 外部访问 “总入口”！Service 只能用 ClusterIP（集群内访问）或 NodePort（节点端口，端口范围有限），Ingress 可通过域名（如www.xxx.com）和路径（如 /nginx）转发请求到不同 Service，像 “小区大门保安，按访客目的地分配楼栋”。
三、实际应用场景：K8s 到底用在哪？
-
微服务架构落地
微服务拆分后有几十上百个服务（如用户服务、订单服务、支付服务），K8s 用 Deployment 部署每个服务，Service 实现服务间通信，Ingress 管理外部访问，轻松应对微服务的动态扩缩容。
▶ 例：电商平台，大促时订单服务压力大，K8s 自动把订单服务的 Pod 从 5 个扩到 20 个，大促后缩回 5 个，节省资源。 -
跨环境应用一致性
开发、测试、生产环境用相同的 K8s YAML 配置，避免 “开发测好，生产崩了”—— 比如开发写好 Nginx 的 Deployment YAML，测试环境用它部署，生产环境只改 ConfigMap 里的数据库地址，保证应用行为一致。 -
高可用集群搭建
K8s 控制平面多节点部署（比如 3 个 Master 节点），etcd 多节点备份，Worker 节点跨机房分布，即使某个机房断电，其他节点能继续运行，应用零中断。 -
CI/CD 流水线集成
结合 Jenkins、GitLab CI 等工具，实现 “代码提交→自动构建镜像→K8s 自动部署” 的全流程自动化（比如程序员提交代码后，不用手动传镜像到生产，K8s 自动拉取新镜像更新应用）。
四、简单示例：用 K8s 部署一个 Nginx
1. 编写 Deployment YAML（定义 Nginx 应用）
创建nginx-deploy.yaml文件，内容如下（关键配置已注释）：
yaml
apiVersion: apps/v1 # API版本
kind: Deployment # 资源类型（Deployment）
metadata:name: nginx-deploy # Deployment名称
spec:replicas: 2 # 要创建的Pod数量（2个，高可用）selector: # 匹配Pod的标签（找到要管理的Pod）matchLabels:app: nginxtemplate: # Pod模板（定义Pod里的容器）metadata:labels:app: nginx # Pod的标签（和上面selector对应）spec:containers:- name: nginx # 容器名称image: nginx:1.24 # 容器镜像（用Nginx 1.24版本）ports:- containerPort: 80 # 容器暴露的端口（Nginx默认80）resources: # 资源限制（避免容器占满节点资源）limits:cpu: "0.5" # 最大CPU（0.5核）memory: "512Mi" # 最大内存（512MB）requests:cpu: "0.2" # 最小CPU（0.2核）memory: "256Mi" # 最小内存（256MB）
2. 编写 Service YAML（给 Nginx 分配固定地址）
创建nginx-svc.yaml文件，内容如下：
yaml
apiVersion: v1
kind: Service
metadata:name: nginx-svc
spec:type: NodePort # 类型（NodePort：集群外可通过节点IP+端口访问）selector:app: nginx # 匹配标签为app:nginx的Podports:- port: 80 # Service的端口（集群内访问用）targetPort: 80 # 转发到Pod的端口（和容器暴露的端口一致）nodePort: 30080 # 节点暴露的端口（集群外访问用，范围30000-32767）
3. 执行命令部署并验证
# 1. 创建Deployment（启动2个Nginx Pod）
kubectl apply -f nginx-deploy.yaml# 2. 创建Service（分配访问地址）
kubectl apply -f nginx-svc.yaml# 3. 查看Pod状态（确保STATUS是Running）
kubectl get pods
# 输出类似：
# NAME READY STATUS RESTARTS AGE
# nginx-deploy-7f98d7c6b4-2xqzk 1/1 Running 0 2m
# nginx-deploy-7f98d7c6b4-5k87x 1/1 Running 0 2m# 4. 查看Service状态（获取NodePort）
kubectl get svc nginx-svc
# 输出类似：
# NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
# nginx-svc NodePort 10.96.123.45 <none> 80:30080/TCP 1m# 5. 集群外访问（用节点IP+30080端口）
curl http://节点IP:30080
# 输出Nginx默认页面，说明部署成功！
五、K8s 常用使用方法（从安装到运维）
1. 集群安装（以 kubeadm 为例，最常用的方式）
# 1. 准备3台服务器（1台Master，2台Worker，系统CentOS 7/8或Ubuntu 20.04+）
# 2. 每台服务器初始化（关闭防火墙、禁用Swap、配置主机名等）
systemctl stop firewalld && systemctl disable firewalld
swapoff -a && sed -i '/swap/s/^/#/' /etc/fstab# 3. 安装Docker/containerd（容器运行时）
yum install -y docker && systemctl start docker && systemctl enable docker# 4. 安装kubeadm、kubelet、kubectl（K8s工具集）
cat > /etc/yum.repos.d/kubernetes.repo << EOF
[kubernetes]
name=Kubernetes
baseurl=https://mirrors.aliyun.com/kubernetes/yum/repos/kubernetes-el7-x86_64/
enabled=1
gpgcheck=0
EOF
yum install -y kubelet-1.26.0 kubeadm-1.26.0 kubectl-1.26.0
systemctl start kubelet && systemctl enable kubelet# 5. 初始化Master节点（--pod-network-cidr是网络插件的网段，用calico就填192.168.0.0/16）
kubeadm init --image-repository registry.aliyuncs.com/google_containers --pod-network-cidr=192.168.0.0/16# 6. 配置kubectl（Master节点执行，让当前用户能操作集群）
mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config# 7. 安装网络插件（calico，必须装，否则Pod间不能通信）
kubectl apply -f https://docs.projectcalico.org/v3.25/manifests/calico.yaml# 8. Worker节点加入集群（Master初始化成功后会输出join命令，类似下面）
kubeadm join 192.168.1.100:6443 --token abcdef.0123456789abcdef \--discovery-token-ca-cert-hash sha256:1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef
2. 日常运维常用命令
| 命令 | 作用 |
|---|---|
kubectl get pods [-n 命名空间] | 查看 Pod 状态（加 - n 指定命名空间，如 - n dev） |
kubectl get deployments | 查看 Deployment 状态 |
kubectl get svc | 查看 Service 状态 |
kubectl describe pod <Pod名称> | 查看 Pod 详情（排障用，比如 Pod 启动失败原因） |
kubectl logs <Pod名称> [-c <容器名>] | 查看 Pod 日志（容器名可选，多容器时需要指定） |
kubectl scale deployment <Deployment名> --replicas=5 | 扩容 Pod 到 5 个 |
kubectl set image deployment <Deployment名> <容器名>=<新镜像> | 更新容器镜像（滚动更新） |
kubectl delete pod <Pod名称> | 删除 Pod（Deployment 会自动重建，用于测试自愈） |
六、常见问题及解决方法（排障必备）
1. 问题：Pod 一直处于 Pending 状态
- 原因 1：节点资源不足（CPU / 内存不够）
解决：用kubectl describe pod <Pod名>看 Events，若显示 “Insufficient cpu” 或 “Insufficient memory”，则扩容节点资源，或减少 Pod 的资源请求（修改 YAML 里的 resources.requests）。 - 原因 2：节点有污点（Taint），Pod 没有容忍（Toleration）
解决：查看节点污点kubectl describe node <节点名> | grep Taint，若有污点（如 node-role.kubernetes.io/master，Master 节点默认不让跑 Pod），则给 Pod 加容忍（在 YAML 的 spec 下加 tolerations 字段）。
2. 问题：Service 访问不到 Pod
- 原因 1：Service 的 selector 和 Pod 的 label 不匹配（“找错人了”）
解决：检查 Service 的 selector（kubectl get svc <Svc名> -o yaml）和 Pod 的 label（kubectl get pods <Pod名> -o yaml | grep labels），确保一致。 - 原因 2：Pod 没就绪（READY 状态是 0/1）
解决：用kubectl logs <Pod名>看容器日志，排查容器启动失败原因（比如配置错误、端口被占）。
3. 问题：节点处于 NotReady 状态
- 原因：网络插件没装或没启动（最常见）
解决：查看网络插件 Pod 状态kubectl get pods -n kube-system | grep calico（若用 calico），若没运行则重新安装网络插件；或检查节点网络是否通（Master 和 Worker 之间能 ping 通 6443 端口）。
七、难点段子解读：让硬核概念变通俗
1. 难点：etcd 的 “一致性” 是什么意思？
- 段子：小区选业委会，规定 “必须超过一半业主到场投票，且同意票超过一半才算通过”——etcd 就像小区投票系统，集群里的 etcd 节点（业主）要对 “Pod 状态更新”“Service 创建” 等操作投票，只有超过一半节点同意，操作才会生效，确保所有节点存储的数据一致（不会出现 “这个节点说 Pod 在 A 节点，那个节点说在 B 节点”）。
2. 难点：Deployment 和 StatefulSet 的区别？
- 段子：Deployment 管理的 Pod 是 “出租屋租客”—— 你租的房子没固定编号，今天住 301，明天房东让你搬 302，你无所谓（反正东西少，搬起来方便）；
StatefulSet 管理的 Pod 是 “学区房业主”—— 房子编号固定（比如 1 号楼 101），房产证（存储）和编号绑定，就算房子塌了重建，还是 1 号楼 101，你的家具（数据）还在（适合 MySQL 这种 “认地址” 的应用，换了地址数据库就连不上了）。
3. 难点：kube-proxy 的 “Service 转发” 怎么实现？
- 段子：小区里有个 “快递代收点”（Service），代收点的电话是固定的（ClusterIP），不管快递员（外部请求）找谁，只要报 “代收点电话”，代收点就会根据 “收件人名单”（selector 匹配 Pod）把快递送到对应的住户（Pod）手里 —— 哪怕住户换了房间（Pod IP 变了），只要收件人名单没改，代收点照样能送对。
结尾专业总结
K8s 的核心优势在于自动化、可扩展、高可用，它不仅是容器编排工具，更是云原生应用的 “操作系统”。对于初学者，建议先从 “核心概念（Pod、Deployment、Service）” 和 “简单部署示例” 入手，再逐步深入集群运维和高级特性（如 StatefulSet、Ingress、监控告警）。需注意：K8s 不是 “银弹”，小规模应用（如单机跑 1 个容器）用它反而增加复杂度，需根据业务规模决定是否引入。随着云原生技术的发展，K8s 会持续和 AI 运维、Serverless 等结合，成为更易用、更智能的底层平台。
