企业官网建设流程全解析

简介：这份Kubernetes课件面向容器编排初学者与运维开发人员，系统梳理k8s核心知识体系，帮助读者建立从集群架构到应用管理的整体认知。内容涵盖k8s基本概念、集群架构与组件、监控与日志、应用程序生命周期管理、调度、存储及集群安全等模块，对kube-apiserver、kube-controller-manager、kube-scheduler、Etcd、kubelet、kube-proxy等核心组件，以及Pod、Controllers、Service、Label、NameSpaces等基础对象均有讲解，并延伸至kubectl常用命令、Metrics-server与cAdvisor监控、Deployment部署与回滚等实践要点。资源包共1个pptx文件，约1.25MB，以幻灯片形式组织章节，结构清晰，便于课堂讲授或自学翻阅。目前已有2191人学习下载，适合希望快速入门k8s、梳理知识框架并对照实践操作的技术人员参考。

1. Kubernetes 知识地图：从集群架构到应用生命周期的整体轮廓

很多人学 Kubernetes 的第一反应是去背kubectl命令，背完发现换个场景还是不会排查问题。梳理下来会发现，K8s 的知识点其实是一张有层次的图：最底层是集群架构与核心组件，往上是 Pod、Controller、Service、Label、Namespace 这些基本概念，再往上是监控日志、应用生命周期管理、调度、存储、集群安全这些运维与实战模块。这份课件分享的目录正好覆盖了这六块，从基本概念一路铺到集群安全，适合已经上手过容器、想系统补齐 K8s 体系的人，也适合正在复习备考、需要一份可查漏补缺清单的人。下面按模块把重点、难点和容易翻车的地方逐一梳理清楚。

2. 集群架构与核心组件：谁在管什么，别记混

2.1 控制平面四个组件的分工

K8s 集群架构最容易被问到的就是「某个组件挂了会怎样」。先把控制平面（Master 节点）的四个核心组件职责分清楚：

这里有个反直觉的点：kube-apiserver不是「可选入口」，而是唯一入口。任何组件想读写集群状态，都必须经过它，再由它提交给 Etcd。所以排查集群异常时，apiserver 的健康状态是第一优先级。

2.2 工作节点上的三个角色

Node 节点上跑的是真正干活的组件：

• kubelet：Master 在 Node 上的 Agent，管理本机容器生命周期，包括创建容器、Pod 挂载数据卷、下载 secret、获取容器和节点状态。它把每个 Pod 转换成一组容器。
• kube-proxy：在 Node 上实现 Pod 网络代理，维护网络规则和四层负载均衡。
• docker 或 rocket：容器引擎，负责运行容器。

梳理下来会发现，kubelet 和 kube-proxy 的职责边界经常被混淆：kubelet 管的是「容器和 Pod 的生命周期」，kube-proxy 管的是「网络规则和负载均衡」。一个 Pod 起不来，先看 kubelet；一个 Service 访问不通，先看 kube-proxy。

2.3 基本概念对象的定位

集群组件之上，是日常操作直接打交道的对象：

• Pod：最小部署单元，一组容器的集合，一个 Pod 中的容器共享命名网络空间，Pod 是短暂的。
• Controllers：Deployment（无状态应用部署）、StatefulSet（有状态应用部署）、DaemonSet（守护进程）、Job（一次性任务）、Cronjob（定时任务）。
• Service：防止 Pod 失联，定义一组 Pod 的访问策略。
• Label：标签，附加到某个资源上，用于关联对象、查询、筛选。
• Namespace：命名空间，将对象逻辑上分离。

提示：Pod 是短暂的这一点，决定了不能用「IP 不变」的思路去设计应用，Service 和 Label 就是为解决这个问题而存在的。

3. 监控与日志：集群状态怎么看，日志从哪捞

3.1 查看集群与资源状态

日常排查的第一步是确认集群整体状态和资源信息。课件里给出的命令覆盖了从集群到单个资源的查看路径：

# 查看集群整体状态 kubectl cluster-info # 查看更详细的集群信息 kubectl cluster-info dump # 查看某个资源的详细信息 kubectl describe <资源> <名称> # 持续监听某个 Pod 的状态变化 kubectl get pod <Pod名称> --watch

kubectl describe和kubectl get --watch的区别值得注意：describe 看的是某一时刻的详细快照，适合排查配置和事件；--watch是持续监听，适合观察 Pod 从 Pending 到 Running 的过程。很多人排查启动慢的问题时只用 describe，结果错过了状态流转的关键节点。

3.2 资源利用率监控

监控集群资源消耗依赖 Metrics-server + cAdvisor 这套组合。Metrics-server 提供资源指标，cAdvisor 负责采集容器数据。查看命令：

# 查看 Node 资源消耗 kubectl top node <node name> # 查看 Pod 资源消耗 kubectl top pod <pod name>

这里最容易踩的坑是：kubectl top命令报错时，第一反应往往是命令写错了，实际上更常见的原因是 Metrics-server 没有部署或没有正常运行。没有 Metrics-server，top 命令就没有数据来源。

3.3 组件日志与应用日志的区分

日志分两层，管理方式不同：

K8s 组件日志：

• 使用 systemd 管理：journalctl -u kubelet
• 使用容器管理：kubectl logs kube-proxy-btz4p -n kube-system
• 系统日志：/var/log/messages

K8s 应用日志：

# 查看容器标准输出日志 kubectl logs <Pod名称> # 实时跟踪日志 kubectl logs -f <Pod名称> # 查看指定容器的日志 kubectl logs -f <Pod名称> -c <容器名称>

应用日志还可以通过挂载方式持久化。课件里给出的 Pod 配置示例展示了如何把容器日志目录挂载到宿主机：

apiVersion: v1 kind: Pod metadata: name: my-pod spec: containers: - name: web image: lizhenliang/nginx-php volumeMounts: - name: logs mountPath: /usr/local/nginx/logs volumes: - name: data hostPath: path: /tmp/logs type: Directory

这段配置的关键在于volumeMounts把容器内的日志目录挂出来，volumes用 hostPath 落到宿主机/tmp/logs。注意type: Directory要求宿主机路径必须已存在，否则 Pod 会启动失败。这是日志持久化时最常见的翻车点之一。

4. 应用程序生命周期管理：部署、升级、回滚一条线

4.1 命令行部署与发布

从零部署一个应用，课件给出的路径是先用kubectl create deployment创建 Deployment，再用kubectl expose发布为 Service：

# 创建 Deployment kubectl create deployment web --image=lizhenliang/java-demo # 查看 Deployment 和 Pod kubectl get deploy,pods # 发布为 Service kubectl expose deployment web --port=80 --type=NodePort --target-port=80 --name=web # 查看 Service kubectl get service

--port是 Service 对外暴露的端口，--target-port是容器实际监听的端口，--type=NodePort表示通过节点端口对外访问。这三个参数写错任何一个，Service 都访问不通。

4.2 YAML 文件创建资源对象

命令行适合快速验证，生产环境更常用 YAML 文件。一个完整的 Deployment YAML 结构如下：

apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment namespace: default spec: replicas: 3 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.15 ports: - containerPort: 80

各字段含义需要记牢：apiVersion是 API 版本，kind是资源类型，metadata是资源元数据，spec是资源规格，replicas是副本数量，selector是标签选择器，template是 Pod 模板，template.metadata是 Pod 元数据，template.spec是 Pod 规格，containers是容器配置。

注意：selector.matchLabels必须和template.metadata.labels匹配，否则 Deployment 找不到自己管理的 Pod，创建会直接报错。这是 YAML 写错时最高频的问题。

4.3 升级、伸缩、回滚与删除

应用生命周期管理的核心操作可以串成一条线：

# 应用升级 kubectl set image deployment/web nginx=nginx:1.15 kubectl rollout status deployment/web # 弹性伸缩 kubectl scale deployment web --replicas=10 kubectl autoscale deployment web --min=10 --max=15 --cpu-percent=80 # 回滚 kubectl rollout history deployment/web kubectl rollout undo deployment/web kubectl rollout undo deployment/web --to-revision=2 # 删除 kubectl delete deploy/web kubectl delete svc/web

kubectl rollout status用来确认升级是否完成，kubectl rollout history查看历史版本，kubectl rollout undo回滚到上一版本或指定版本。这里有个血泪经验：回滚之前一定要先看 history，确认目标 revision 号，否则--to-revision写错会滚到更早的版本。

4.4 Pod 对象的设计细节

Pod 为什么存在？它是为亲密性应用而设计的。典型场景包括：两个应用之间发生文件交互、需要通过 127.0.0.1 或 socket 通信（如 nginx+php）、需要频繁调用。Pod 本身是逻辑概念，实现机制靠的是共享网络和共享存储：

• 共享网络：每个 Pod 先启动一个 infra container 小容器，其他容器加入这个网络命名空间，看到的网络设备、IP、Mac 地址完全一样。
• 共享存储：通过共享容器的挂载实现存储共享。

镜像拉取策略有三种：IfNotPresent（默认，宿主机不存在时才拉取）、Always（每次创建都重新拉取）、Never（永不主动拉取）。关键字是imagePullPolicy。

资源限制分两类：requests是申请配额，limits是限制配额（容器能使用的最大值）。配置示例：

apiVersion: v1 kind: Pod metadata: name: web spec: containers: - name: java image: lizhenliang/java-demo resources: requests: memory: "64Mi" cpu: "250m" limits: memory: "128Mi" cpu: "500m"

requests影响调度决策，limits影响运行时上限。只写 limits 不写 requests 时，调度器会按 limits 来算，可能导致节点资源被过度占用。

5. 调度、存储与集群安全：容易忽略的易错点

5.1 调度与存储的衔接

调度解决的是 Pod 落在哪个 Node 的问题，存储解决的是 Pod 数据往哪放的问题。两者在实战中经常联动：有状态应用（StatefulSet）对存储有强依赖，调度时需要考虑节点上是否有对应的存储资源。课件里调度和存储作为独立模块列出，复习时要把它们和 Controller 类型对应起来——Deployment 管无状态，StatefulSet 管有状态，DaemonSet 管守护进程，Job 和 Cronjob 管任务。

5.2 集群安全的复习重点

集群安全模块在课件目录中单独列出，复习时要抓住几个层面：API 访问控制、认证与授权、网络策略、Secret 管理。其中 Secret 的下载和使用在 kubelet 职责里已经提到，说明安全和组件行为是绑定的，不是孤立的知识点。

5.3 易漏点与易错点

易漏点一：Metrics-server 未部署就查 top为什么漏：以为kubectl top是内置命令，装上就能用。 怎么补：先确认kube-system命名空间下 Metrics-server 的 Pod 是否 Running，再执行 top。

易漏点二：selector 与 labels 不匹配为什么漏：YAML 里两处标签分开写，改了一处忘了另一处。 怎么补：写完 Deployment 后先kubectl apply --dry-run=client验证，再正式创建。

易漏点三：hostPath 的 type 写错导致 Pod 起不来为什么漏：只关注挂载路径，忽略了 type 约束。 怎么补：确认宿主机路径存在，type 按实际类型选 Directory 或 DirectoryOrCreate。

易漏点四：回滚时不看 history 直接 undo为什么漏：以为 undo 就是回到上一版，实际可能滚到更早版本。 怎么补：先kubectl rollout history确认 revision，再用--to-revision指定。

易漏点五：requests 和 limits 只写一个为什么漏：觉得写一个就够了，不知道两者作用不同。 怎么补：requests 用于调度，limits 用于运行时限制，生产环境建议都写。

6. 复习清单：从查漏补缺到形成习惯

复习 K8s 最有效的方式不是从头再背一遍，而是按模块做一次「能不能讲清楚」的自检。下面这份清单可以直接拿来用：

查漏补缺的具体做法：先合上课件，对着上面这张表逐行口述，讲不出来的行就是漏洞。讲不出来的模块，回到对应章节把命令和 YAML 重新敲一遍，不要只看。尤其是 YAML 字段，看十遍不如手写一遍，selector和labels的匹配关系、requests和limits的区别，都是手写一次就记住的东西。

从那以后我每次复习 K8s，都强制走一遍「架构组件 → 基本对象 → 监控日志 → 生命周期 → 调度存储安全」这条线，每个模块至少敲一条命令或写一段 YAML，不给自己只看不练的机会。希望帮到你。

本文还有配套的精品资源，点击获取