第一章：Kubernetes基础入门

1.1 从物理机到容器：Kubernetes 为什么诞生？

说实话，我入行那会儿，部署应用还是件挺「原始」的事。

一台物理机，装好操作系统，手动配好环境，然后把 jar 包扔进去。要是机器挂了，运维就得半夜爬起来重新部署。后来有了虚拟机，隔离性好了不少，但每台虚拟机都自带一个完整的操作系统，资源浪费严重。

再后来，Docker 出现了。容器技术让应用和它的依赖打包在一起，轻量、快速、可移植。但问题也随之而来——容器多了，你怎么管理？

举个例子，我在一个项目中同时跑了 50 个容器，它们分布在 3 台机器上。某台机器宕机了，上面的容器怎么办？流量怎么切？谁来重新调度？

这就是 Kubernetes 要解决的核心问题：容器的自动化部署、扩缩容、以及运维管理。

1.2 发展史：从 Borg 到 Kubernetes

Kubernetes 的源头，其实是 Google 内部用了十几年的集群管理系统——Borg。

Google 的工程师们每天要调度数十亿个容器，他们积累了大量的经验。2014 年，Google 把这些经验开源出来，就是 Kubernetes。名字来自希腊语，意为「舵手」或「领航员」。

我印象很深，Kubernetes 1.0 发布时，社区还很小。但到了 1.6 版本左右，它已经成了容器编排的事实标准。为什么？

• 2015 年：Kubernetes 1.0 发布，Google 联合 Linux 基金会成立 CNCF。
• 2017 年：Docker 宣布支持 Kubernetes，容器编排大战基本结束。
• 2018 年：Kubernetes 成为 CNCF 首个毕业项目。
• 现在：几乎所有云厂商都提供托管的 Kubernetes 服务，比如 AKS、EKS、GKE。

我个人习惯把 Kubernetes 的发展分为三个阶段：

1. 探索期（2014-2016）：大家都在试，文档少，踩坑多。
2. 成熟期（2017-2019）：API 稳定，生态丰富，生产环境开始大规模使用。
3. 普及期（2020 至今）：Kubernetes 成了云原生的「操作系统」。

1.3 核心概念：Pod、Service、Deployment

这三个概念，是 Kubernetes 的基石。你搞懂了它们，Kubernetes 就算入门了。

1.3.1 Pod：最小的调度单元

Pod 是 Kubernetes 中你可以创建和管理的最小计算单元。一个 Pod 可以包含一个或多个容器。

你可能会问：为什么不用单个容器，非要包一层 Pod？

嗯，这里要注意。Pod 里的容器共享网络和存储。比如，一个容器写日志，另一个容器收集日志，它们放在同一个 Pod 里就非常方便。我在项目中经常用这种模式——主业务容器 + 日志 sidecar 容器。

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: nginx
    image: nginx:1.21
  - name: log-collector
    image: fluentd:latest

1.3.2 Service：稳定的网络入口

Pod 是动态的。它可能因为故障被销毁，也可能因为扩缩容被重建。每次重建，Pod 的 IP 都会变。

那问题来了：客户端怎么访问它？

Service 就是来解决这个问题的。它提供了一组 Pod 的稳定访问入口，不管 Pod 怎么变，Service 的 IP 和端口不变。

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: nginx
  ports:
  - protocol: TCP
    port: 80
    targetPort: 8080

说白了，Service 就是一个「负载均衡器」，把流量分发到后端的 Pod 上。我建议你记住三种常见的 Service 类型：

类型	说明	使用场景
ClusterIP	集群内部可访问	内部服务调用
NodePort	通过节点 IP + 端口访问	开发测试环境
LoadBalancer	云厂商提供公网入口	生产环境对外暴露

1.3.3 Deployment：声明式的应用管理

Deployment 是 Kubernetes 最常用的工作负载控制器。你告诉它「我要跑 3 个 nginx 副本」，它就会帮你维持这个状态。

我记得有一次，线上某个 Pod 挂了，Deployment 自动创建了一个新的。整个过程我完全没干预。这就是声明式的好处——你只管描述「想要什么」，Kubernetes 负责「怎么实现」。

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

Deployment 还支持滚动更新。你更新镜像版本，它会逐步替换旧 Pod，保证服务不中断。我曾经用这个功能在白天直接升级了线上服务，用户完全无感知。

1.4 架构组件详解

Kubernetes 集群分为两部分：控制平面（Control Plane）和工作节点（Worker Node）。

1.4.1 控制平面组件

• kube-apiserver：所有操作的入口。你用的 kubectl，本质上就是在调它的 API。
• etcd：集群的「数据库」。所有状态都存这里。我建议你定期备份 etcd，否则集群挂了很难恢复。
• kube-scheduler：负责把 Pod 调度到合适的节点上。它会考虑资源、亲和性、污点等因素。
• kube-controller-manager：运行各种控制器，比如 Deployment 控制器、Node 控制器等。

1.4.2 工作节点组件

• kubelet：每个节点上的「代理」。它负责接收控制平面的指令，管理 Pod 的生命周期。
• kube-proxy：负责实现 Service 的网络规则。说白了，就是做负载均衡和流量转发。
• 容器运行时：比如 Docker、containerd。Kubernetes 本身不运行容器，它通过容器运行时来操作。

1.5 本章小结

这一章我们聊了 Kubernetes 的来龙去脉，也拆解了 Pod、Service、Deployment 这三个核心概念，最后看了架构组件。

你可能会觉得信息量有点大。没关系，Kubernetes 的学习曲线确实陡。我的建议是：先动手搭一个单节点集群，用 kubectl 创建几个 Pod 和 Deployment，感受一下「声明式」的魅力。

下一章，我们会深入 Pod 的细节，聊聊资源限制、健康检查、以及生命周期管理。到时候见。

---

公众号:蓝海资料掘金营，微信deep3321