3. Kubernetes入门：K8s架构、核心组件、Pod与Deployment

好，咱们进入Kubernetes的世界。说实话，K8s这玩意儿刚接触时确实有点懵。我当年第一次部署集群，光看架构图就看了三天。但别怕，咱们一步步拆解。

3.1 K8s整体架构：控制平面与工作节点

Kubernetes本质上是一个集群操作系统。它把一堆服务器虚拟成一个巨大的资源池。你只管告诉它“我要跑3个Nginx”，它自己会搞定调度、部署、健康检查。

整个集群分两大部分：

• 控制平面（Master节点）：集群的大脑，负责决策
• 工作节点（Worker节点）：真正跑容器的地方

我习惯把Master比作公司的CEO，Worker就是一线员工。CEO做决策，员工执行任务。CEO挂了，公司就瘫痪了——所以生产环境至少3个Master节点做高可用。

3.2 核心组件详解

3.2.1 控制平面组件

组件	职责	我的经验
kube-apiserver	所有操作的入口，提供REST API	这是集群的“大门”，所有组件都通过它通信
etcd	分布式键值存储，保存集群状态	etcd挂了集群就废了，一定要做备份
kube-scheduler	决定Pod调度到哪个节点	默认调度策略够用，但复杂场景要写自定义调度器
kube-controller-manager	运行各种控制器，确保集群状态符合预期	Deployment、Node、Namespace等控制器都在这里

3.2.2 工作节点组件

• kubelet：节点上的“管家”，负责管理Pod和容器
• kube-proxy：维护网络规则，实现服务发现和负载均衡
• 容器运行时：比如Docker、containerd，真正跑容器

我曾经遇到过一个诡异问题：Pod一直处于Pending状态。查了半天，发现是kubelet没启动。你想想看，节点上的管家都不在，谁来干活？

3.3 Pod：K8s的最小调度单元

Pod是K8s里最基础的概念。说白了，Pod就是一个或多个容器的“组合包”。这些容器共享网络栈、存储卷，运行在同一台机器上。

为什么要有Pod？直接跑容器不行吗？

嗯，这里要注意：有些场景下，两个容器需要紧密协作。比如一个容器写日志，另一个容器收集日志。它们需要共享网络和存储。Pod就是为这种场景设计的。

3.3.1 创建一个简单的Pod

apiVersion: v1
kind: Pod
metadata:
  name: my-nginx
  labels:
    app: nginx
spec:
  containers:
  - name: nginx
    image: nginx:1.21
    ports:
    - containerPort: 80

保存为 pod.yaml，然后执行：

kubectl apply -f pod.yaml
kubectl get pods
kubectl describe pod my-nginx

我个人习惯用 kubectl describe 查看Pod的详细信息。它能告诉你Pod的完整生命周期，包括调度到哪个节点、拉取镜像的过程、启动日志等。

3.4 Deployment：声明式应用管理

Deployment是K8s里最常用的工作负载控制器。它帮你管理Pod的“生老病死”。你只需要声明“我要3个副本”，Deployment会保证始终有3个Pod在运行。

3.4.1 Deployment的核心能力

• 滚动更新：逐步替换旧版本Pod，保证服务不中断
• 回滚：新版本出问题，一键回到旧版本
• 扩缩容：根据负载动态调整副本数
• 自愈：Pod挂了自动重建

3.4.2 创建Deployment

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

应用这个YAML：

kubectl apply -f deployment.yaml
kubectl get deployments
kubectl get pods -l app=nginx

你会看到3个Pod，名字后面跟着随机字符串。这就是Deployment自动创建的。

3.4.3 滚动更新实战

假设我要把Nginx从1.21升级到1.22：

kubectl set image deployment/nginx-deployment nginx=nginx:1.22
kubectl rollout status deployment/nginx-deployment

K8s会逐个替换Pod。先启动一个新Pod，等它Ready了，再干掉一个旧Pod。整个过程服务不中断。

我记得有一次升级后业务报错，赶紧回滚：

kubectl rollout undo deployment/nginx-deployment

10秒内就恢复了。这就是声明式管理的威力——你不需要手动操作每个Pod。

3.5 从Pod到Deployment的演进

为什么我们不直接用Pod？

你想想看，如果直接管理Pod：

• Pod挂了，你得手动重建
• 要升级版本，你得一个个删了重建
• 流量大了，你得手动加Pod

用Deployment，这些全自动了。我刚开始学K8s时，也是先玩Pod，后来发现Deployment才是生产环境的主角。

3.6 本章小结

这一章我们聊了：

• K8s架构：控制平面+工作节点，各司其职
• 核心组件：apiserver是入口，etcd存状态，kubelet管节点
• Pod：最小调度单元，共享网络和存储
• Deployment：声明式管理，自动扩缩容、滚动更新、自愈

下一章我们会深入Service和Ingress，看看Pod之间怎么通信，外部怎么访问集群。嗯，到时候再聊。