Kubernetes入门：从零开始理解k8s – wiki基地

作者： /

Kubernetes入门：从零开始理解 k8s

在当今的软件开发领域，“云原生”、“容器化”和“微服务”等词汇已不再陌生。它们代表着一种现代化的应用构建和部署哲学，旨在提高软件的开发效率、部署速度、可伸缩性和韧性。而在这场技术变革浪潮中，Kubernetes（常简称为k8s）无疑是其中最核心、最引人瞩目的技术之一。

你可能已经听说过k8s的大名，知道它与容器（特别是Docker）紧密相关，并且在云端应用部署中扮演着重要角色。但对于一个完全的新手来说，k8s可能像一个庞大而复杂的黑箱，让人望而生畏。各种组件、概念、缩写（Pod, Service, Deployment, YAML…）扑面而来，不知道从何入手。

别担心！这篇文章正是为你准备的。我们将从最基础的概念出发，一步步揭开Kubernetes的神秘面纱，帮助你系统地理解它是什么、为什么需要它，以及它的核心组成部分和工作原理。我们的目标是让你不再害怕k8s，而是对它有一个清晰、扎实的认知，为你后续的深入学习和实践打下坚实的基础。

为什么我们需要 Kubernetes？理解它解决的问题

在深入k8s的技术细节之前，让我们先回到过去，看看软件部署和运维曾经面临的挑战，这将有助于我们理解k8s诞生的背景和它解决的根本问题。

传统的软件部署：痛苦与低效

想象一下，在没有容器和容器编排工具的时代，部署一个应用程序通常是这样的：

  1. 服务器准备： 购买或租用物理机或虚拟机。
  2. 环境配置： 在服务器上安装操作系统、运行时环境（如Java、Python）、数据库驱动、依赖库等。这是一个非常耗时且容易出错的过程，不同的应用可能需要不同的环境，配置冲突是家常便饭。
  3. 应用部署： 将编译好的应用程序代码或二进制文件上传到服务器的特定目录。
  4. 启动应用： 运行启动脚本，确保应用能够正确启动。
  5. 配置： 修改应用的配置文件，指向正确的数据库地址、端口等。
  6. 扩展： 当用户量增加，需要增加服务器时，必须重复以上所有步骤。
  7. 更新： 更新应用需要停掉旧版本，部署新版本，这期间服务不可用。回滚更是噩梦。
  8. 维护： 监控服务器资源、处理依赖冲突、修复兼容性问题、应对硬件故障等。

这种方式部署效率低下，环境一致性难以保证（“在我机器上好好的！”），扩展和更新困难，维护成本高昂。对于微服务架构来说，需要管理的独立服务数量成倍增加，传统方式更是捉襟见肘。

容器的出现：标准化与隔离

Docker等容器技术的兴起，为解决环境一致性问题带来了曙光。容器提供了一种标准化的打包方式，将应用程序及其所有依赖（代码、运行时、库、环境变量、配置文件等）都打包到一个独立的、可移植的“容器”中。

容器的优势：

  • 环境一致性： 容器在任何地方运行都使用相同的环境，大大减少了“环境问题”。
  • 隔离性： 容器之间相互隔离，互不影响。
  • 轻量级： 相比虚拟机，容器更加轻量、启动更快、资源消耗更少。
  • 可移植性： 打包好的容器镜像可以在任何支持容器运行的环境中运行。

容器极大地简化了应用的打包和分发，但在生产环境中，我们需要管理的往往不是一两个容器，而是成百上千个甚至更多。这时，新的问题出现了：

  • 如何自动部署大量容器？
  • 如何管理容器的生命周期（启动、停止、重启）？
  • 如何确保容器故障时能自动恢复？
  • 如何根据负载自动增加或减少容器实例？
  • 如何让容器之间相互发现和通信？
  • 如何管理容器的存储和配置？
  • 如何在不中断服务的情况下更新容器？

手动管理如此大量的、动态变化的容器集群是不可行的。这正是容器编排技术诞生的原因，而Kubernetes就是目前最流行、最强大的容器编排系统。

什么是 Kubernetes？

Kubernetes 是一个开源的容器编排平台，它自动化了容器化应用程序的部署、扩展和管理。简单来说，Kubernetes 就是一个用于管理容器化工作负载和服务的大型分布式系统。它可以帮助你：

  • 自动化部署： 根据你的需求，自动化地在集群中的机器上部署容器。
  • 服务发现与负载均衡： 为你的服务提供稳定的网络端点，并自动将流量分发到多个容器实例上。
  • 自动扩缩容： 根据CPU利用率或其他指标，自动增加或减少服务的容器实例数量。
  • 自我修复： 如果一个容器崩溃、节点宕机，Kubernetes 会自动重启、重新调度容器，确保服务的可用性。
  • 滚动更新与回滚： 平滑地更新应用到新版本，如果新版本有问题，可以轻松回滚到旧版本，对用户影响最小。
  • 配置管理与密钥管理： 安全地管理应用程序的配置信息和敏感数据。
  • 存储编排： 自动挂载存储系统，无论本地存储、云存储还是网络存储。

Kubernetes 不仅是一个工具，更是一个平台，它提供了一套丰富的API和原语（Primitives），让你能够以声明式的方式描述你想要达到的最终状态（Desired State），然后Kubernetes会负责让集群达到并维持这个状态。

你可以将Kubernetes集群看作一个巨大的、抽象的计算资源池。你不再需要关心每个应用运行在哪台具体的服务器上，而是告诉Kubernetes：“我需要运行5个我的应用的副本，它们需要访问这些配置和这些存储，并且对外提供服务”。Kubernetes则会负责在集群中找到合适的资源来满足你的需求，并在出现故障时自动进行调整。

Kubernetes 的核心架构与组件

理解Kubernetes的工作原理，首先要了解它的核心架构。一个Kubernetes集群通常由一组机器组成：

  1. 控制平面 (Control Plane / Master Nodes)： 负责集群的整体管理和控制。它接收用户的指令（通过API），维护集群的状态，并对集群进行调度和协调。为了高可用性，控制平面通常由多个节点组成。
  2. 工作节点 (Worker Nodes)： 负责运行实际的应用程序容器。每个工作节点上都有运行容器所需的组件，并与控制平面通信。

让我们详细看看控制平面和工作节点中的关键组件：

控制平面组件 (Control Plane Components)

控制平面是Kubernetes集群的大脑，它由一系列进程组成，通常运行在集群中的一个或多个特定节点上。

  • kube-apiserver (API Server): 这是Kubernetes控制平面的前端，也是整个集群的核心枢纽。所有其他的控制平面组件、工作节点以及外部用户（通过 kubectl 命令行工具）都通过API Server进行通信。它负责处理所有的REST请求，验证、授权并接收对象的状态，并将其存储到etcd中。它是集群状态的入口。
  • etcd: 是一个高可用、强一致性的分布式键值存储系统。它是Kubernetes集群的大脑和数据库，存储了集群的所有配置数据和状态，包括节点信息、Pod 信息、配置、Secrets 等。所有对集群状态的修改都通过API Server写入etcd。
  • kube-scheduler (Scheduler): 负责调度。它监听 API Server，查找新创建的、尚未分配到节点上的 Pod。根据预设的调度策略（考虑资源需求、节点限制、亲和性/反亲和性、数据本地性等），选择最合适的工作节点来运行该 Pod，并将 Pod 的绑定信息更新到 API Server。
  • kube-controller-manager (Controller Manager): 运行着各种控制器进程。控制器是Kubernetes的核心自动化力量。它们持续监听 API Server 中对象的状态，并将当前状态与期望状态进行对比。如果状态不符，控制器会采取行动来使其一致。常见的控制器包括：
    • Node Controller: 负责监测节点的状态，处理节点故障。
    • ReplicaSet Controller: 负责维护每个 ReplicaSet 定义的 Pod 副本数量，确保Pod数量符合期望。
    • Deployment Controller: 负责 Deployment 对象的管理，包括创建 ReplicaSet、处理滚动更新和回滚等。
    • Service Controller: 负责管理 Service，创建负载均衡器（如果运行在云环境中）。
    • Endpoint Controller: 负责维护 Service 和 Pod 之间的关联关系。
  • cloud-controller-manager (云控制器管理器，可选): 当Kubernetes运行在云平台上（如AWS、GCP、Azure）时，这个组件负责与云平台的基础设施进行集成，例如管理云平台的负载均衡器、存储卷等。

工作节点组件 (Worker Node Components)

工作节点是Kubernetes集群中真正运行应用程序容器的机器。每个工作节点上都运行着以下核心组件：

  • kubelet: 这是运行在每个工作节点上的主要代理。它负责与 API Server 通信，接收分配给它的 Pod 描述，并确保这些 Pod 中定义的容器按照期望的状态运行（创建、启动、停止、删除容器，执行健康检查等）。kubelet 不负责调度，它只执行 API Server 分配给它的任务。
  • kube-proxy: 这是运行在每个工作节点上的网络代理。它负责为 Service 提供网络功能。它维护节点上的网络规则（如 iptables、ipvs），以便能够将网络请求路由到正确的 Pod 上。它使得集群内部和外部能够访问 Service。
  • Container Runtime (容器运行时): 这是负责真正运行容器的软件。Kubernetes 支持多种容器运行时，最常见的是 Docker，但也支持 containerd、CRI-O 等符合 Kubernetes 容器运行时接口 (CRI) 的运行时。kubelet 通过 CRI 与容器运行时交互。

总结来说，控制平面负责“决策”和“指挥”（调度、维护状态、响应变化），工作节点负责“执行”（运行容器、提供网络、向控制平面报告状态）。它们通过API Server进行通信，etcd是集群状态的单一事实来源。

Kubernetes 的核心概念与对象 (Kubernetes Objects)

理解了架构，接下来就要理解Kubernetes中的“积木块”——各种资源对象。用户主要通过声明式的方式与Kubernetes交互，即创建、更新或删除这些对象，来描述他们期望的集群状态。Kubernetes 会持续工作，将实际状态驱动到期望状态。

我们通常使用 YAML 文件来定义这些 Kubernetes 对象，然后使用 kubectl 命令行工具与 API Server 交互，创建这些对象。

以下是一些最核心、最常用的Kubernetes对象：

1. Pod (豆荚)

  • 理解： Pod 是 Kubernetes 中最小的可部署计算单元。它不是直接部署单个容器，而是部署 Pod。一个 Pod 是一个或多个容器的集合，这些容器共享网络命名空间（IP 地址、网络端口）和存储卷。
  • 为什么是 Pod 而不是直接用容器？
    • 协同工作： 某些应用需要多个紧密协作的进程，比如一个主应用容器和一个日志收集/数据适配器容器。将它们放在同一个 Pod 中，它们可以通过 localhost 互相访问，共享存储，管理更方便。
    • 生命周期： 同一个 Pod 中的容器被视为一个逻辑实体，它们一起启动、一起停止。
    • 抽象层： Pod 提供了比单个容器更高一级的抽象，Kubernetes 调度的最小单位是 Pod，而不是容器。
  • 特点： Pod 是短暂的，它们会被创建、销毁、重启。Pod 有自己的 IP 地址。通常情况下，不应该直接创建裸露的 Pod（除了某些特殊情况或练习），而是通过更高级的控制器来管理 Pod 的生命周期和数量。

2. ReplicaSet (副本集)

  • 理解： ReplicaSet 的主要作用是保证在任何给定时间运行指定数量的 Pod 副本。它通过标签选择器 (Label Selector) 来识别其管理的 Pod，并监控 Pod 的数量。如果 Pod 数量少于期望值，它会创建新的 Pod；如果多于期望值，它会删除多余的 Pod。
  • 特点： ReplicaSet 是一个稳定态控制器。它关心的是 Pod 的数量，而不是 Pod 的版本。因此，直接使用 ReplicaSet 进行应用更新（比如滚动升级）是不方便的。ReplicaSet 通常由更高层级的对象（如 Deployment）来创建和管理。

3. Deployment (部署)

  • 理解： Deployment 是管理无状态应用的推荐方式。它在 ReplicaSet 的基础上提供了更高级的功能，用于声明式地定义 Pod 和 ReplicaSet。Deployment 最重要的功能是滚动更新和回滚。
  • 工作原理： 当你创建一个 Deployment 时，它会创建一个对应的 ReplicaSet 来启动指定数量的 Pod。当你更新 Deployment 的模板（例如，修改了容器镜像版本），Deployment 会创建一个 新的 ReplicaSet，并逐步增加新 ReplicaSet 的 Pod 数量，同时减少旧 ReplicaSet 的 Pod 数量，直到所有 Pod 都更新为新版本。如果更新过程中出现问题，Deployment 可以回滚到之前的版本。
  • 特点： 自动化应用的版本发布和回滚、水平扩缩容、自我修复（通过 ReplicaSet）。它是管理无状态服务的核心对象。

4. Service (服务)

  • 理解： Pod 是短暂的，它们的 IP 地址会随着 Pod 的创建和销毁而改变。如何在集群内部或外部以一个稳定、不变的方式访问一组 Pod 呢？这就是 Service 的作用。Service 定义了访问 Pod 的逻辑抽象和一组访问 Pod 的策略。它提供了一个稳定的虚拟 IP 地址和端口。
  • 工作原理： Service 使用标签选择器来识别一组提供相同功能的 Pod。当有请求发送到 Service 的 IP 和端口时，Service 会将请求负载均衡到它所关联的健康 Pod 中的某个实例。
  • Service 类型： Kubernetes 提供了几种类型的 Service：
    • ClusterIP (默认): 通过集群内部的 IP 地址暴露服务。只能在集群内部访问。
    • NodePort: 通过每个工作节点上的一个静态端口暴露服务。可以通过 <NodeIP>:<NodePort> 从外部访问服务。
    • LoadBalancer: 如果运行在支持的云平台上，会向云提供商申请一个外部负载均衡器，将流量导向 Service。提供外部可访问的 IP 地址。
    • ExternalName: 将服务映射到外部 DNS 名称，而不是内部 Service IP。
  • 特点： 提供稳定的网络访问入口、服务发现、负载均衡。它是实现微服务之间通信和外部访问内部服务的关键。

5. Namespace (命名空间)

  • 理解： Namespace 提供了逻辑上的隔离。它将集群中的资源（如 Pod、Deployment、Service 等）划分为不同的虚拟集群。这有助于在同一个物理集群中隔离不同的项目、团队或环境（如开发、测试、生产），避免资源命名冲突，并可以用于资源配额和访问控制。
  • 特点： 每个资源都属于一个 Namespace（除了少数集群级别的资源）。默认有 default、kube-system、kube-public 等 Namespace。在团队协作和大型集群管理中非常重要。

6. StatefulSet (有状态副本集)

  • 理解： StatefulSet 用于管理有状态应用，例如数据库、消息队列等。与无状态的 Deployment 不同，StatefulSet 确保 Pod 具有稳定的、唯一的网络标识符和持久化的存储。
  • 特点：
    • 稳定的网络标识： 每个 Pod 有一个唯一的、持久的主机名和网络ID。
    • 稳定的持久存储： 每个 Pod 可以关联一个持久卷 (PersistentVolume)，即使 Pod 被重新调度到不同的节点，也能访问到相同的数据。
    • 有序的部署和伸缩： 默认情况下，StatefulSet 的 Pod 是按顺序创建、更新和删除的（如 app-0, app-1, app-2…）。
  • 适用场景： 数据库（MySQL 集群、PostgreSQL）、分布式存储系统、消息队列（Kafka、RabbitMQ）等。

7. DaemonSet (守护进程集)

  • 理解： DaemonSet 确保集群中的所有（或一部分）节点上都运行一个 Pod 的副本。
  • 工作原理： 每当有一个新节点加入集群，DaemonSet 会自动在该节点上部署一个其管理的 Pod。当节点从集群中移除时，Pod 也会被垃圾回收。
  • 适用场景： 运行集群级别的日志收集代理（如 fluentd）、监控代理（如 Prometheus node_exporter）、存储守护进程等。

8. Volume (存储卷)

  • 理解： Volume 提供了 Pod 中容器可以访问的持久化存储，或者用于 Pod 中多个容器之间共享数据。Kubernetes Volume 的生命周期与 Pod 相同（但某些类型 Volume 的数据可以在 Pod 销毁后继续存在）。
  • 特点： Volume 是 Pod 级别而非容器级别的。同一个 Pod 内的所有容器都可以访问其定义的 Volume。Kubernetes 支持多种类型的 Volume，可以对接各种存储系统。
  • 与 Docker Volume 的区别： Kubernetes Volume 更加抽象和强大，它与 Pod 的生命周期关联，并且可以通过 PersistentVolume 和 PersistentVolumeClaim 实现更高级的存储管理。

9. PersistentVolume (PV) 和 PersistentVolumeClaim (PVC)

  • 理解： PV 是集群中由管理员配置或动态配置的一块独立存储资源。它不属于任何特定的 Pod 或 Namespace，是集群层面的资源。PVC 是用户对存储的请求。用户在 PVC 中指定所需的存储大小和访问模式（读写、只读等）。
  • 工作原理： 用户创建 PVC，Kubernetes 会找到或动态创建（通过 StorageClass）一个符合 PVC 要求的 PV，并将它们绑定。Pod 则通过引用 PVC 来使用存储，而不需要关心底层存储的具体实现细节。
  • 特点： PV 和 PVC 分离了存储的提供和使用，使得用户可以方便地请求存储而无需了解复杂的存储基础设施，也使得管理员能够更好地管理存储资源。

10. ConfigMap 和 Secret (配置映射和密钥)

  • 理解：
    • ConfigMap: 用于存储非敏感的配置信息，例如应用程序的配置文件、环境变量、命令行参数等。
    • Secret: 类似于 ConfigMap，但专门用于存储敏感信息，如密码、API 密钥、证书等。Secret 会以加密或其他安全的方式存储和分发。
  • 特点： 将配置信息从应用代码中分离，使得应用更具可移植性，配置管理更灵活。Pod 可以通过环境变量、命令行参数或挂载文件的方式使用 ConfigMap 和 Secret 中的数据。

Kubernetes 如何工作？声明式与控制循环

理解了Kubernetes的组件和对象，最后来看看它是如何协调工作的。Kubernetes 的核心是一个控制循环 (Control Loop)。

  1. 期望状态 (Desired State): 用户（或更高层级的控制器）通过 kubectl 或其他客户端，以 YAML/JSON 文件的形式向 API Server 提交创建、更新或删除对象的请求。这些文件描述了用户期望集群达到的状态（例如，“我想要运行 5 个 Nginx 的 Pod”）。API Server 接收请求后，将期望状态保存在 etcd 中。
  2. 当前状态 (Current State): 集群中的各种控制器（如 ReplicaSet Controller, Deployment Controller）、调度器 (Scheduler) 和每个节点上的 Kubelet 都持续监听 API Server，获取集群的当前状态信息。它们通过监控 Pods、Nodes、ReplicaSets 等对象的实际状态来了解当前集群的运行情况。
  3. 对比与协调 (Reconciliation): 各个控制器和 Kubelet 不断地将 etcd 中存储的期望状态与 API Server 反映的当前状态进行对比。
  4. 采取行动 (Action): 如果当前状态与期望状态不符，相应的控制器或 Kubelet 就会采取行动，使当前状态向期望状态靠拢。
    • 例如，ReplicaSet Controller 发现期望运行 5 个 Pod，但当前只有 3 个 Pod，它就会指示 API Server 创建 2 个新的 Pod。
    • Scheduler 发现有新创建的、未调度的 Pod，就会找到一个合适的节点，并将 Pod 绑定到该节点。
    • Kubelet 发现有绑定到它所在节点的 Pod，但容器尚未运行，就会指示容器运行时启动容器。
    • 如果一个 Pod 崩溃了，Kubelet 会向 API Server 报告其状态。ReplicaSet Controller 发现 Pod 数量不足，就会创建新的 Pod。

这个持续的对比和协调过程就是 Kubernetes 的控制循环。它使得 Kubernetes 具有强大的自我修复能力和自动化管理能力。用户只需要声明“我想要什么”，而无需关心“如何达到”或“如何维持”这个状态，Kubernetes 会自动处理这些细节和异常情况。这就是 Kubernetes 的声明式 API 的强大之处。

如何开始学习 Kubernetes？

理解了基本概念，接下来就是动手实践了。作为初学者，你不必一开始就搭建一个多节点的物理集群。有几种方便的方式可以在你的本地机器上运行一个单节点的 Kubernetes 集群进行学习：

  1. Minikube: 一个可以在本地轻松运行单节点 Kubernetes 集群的工具，支持多种驱动（Docker、VirtualBox、VMware等）。
  2. Kind (Kubernetes in Docker): 使用 Docker 容器作为节点来运行本地 Kubernetes 集群。启动速度通常比 Minikube 快。
  3. Docker Desktop: 如果你已经安装了 Docker Desktop (Windows 或 macOS)，它内置了一个选项可以直接开启 Kubernetes 集群。

选择其中一种方式搭建本地集群后，你需要学习使用 kubectl 命令行工具与集群交互。kubectl 是 Kubernetes 的官方命令行客户端，你可以用它来部署应用、查看集群状态、管理资源等。

一些基础的 kubectl 命令：

  • kubectl get <resource_type>: 查看资源对象列表（如 kubectl get pods, kubectl get deployments, kubectl get services）。
  • kubectl describe <resource_type> <resource_name>: 查看某个资源对象的详细信息。
  • kubectl apply -f <filename.yaml>: 根据 YAML 文件创建或更新资源。
  • kubectl delete -f <filename.yaml> 或 kubectl delete <resource_type> <resource_name>: 删除资源。
  • kubectl logs <pod_name>: 查看 Pod 中容器的日志。
  • kubectl exec -it <pod_name> -- <command>: 在 Pod 中的容器内执行命令。

通过编写简单的 Deployment 和 Service 的 YAML 文件，并在本地集群中部署它们，然后使用 kubectl 查看它们的状态、进行扩缩容、尝试更新和回滚，你将能够快速加深对核心概念的理解。

为什么选择 Kubernetes？它的优势何在？

总结一下 Kubernetes 的主要优势：

  • 自动化： 极大地减少了手动部署、管理和扩展容器化应用所需的工作。
  • 高可用与弹性： 通过自动化故障检测和恢复、自动扩缩容，提高了应用的可用性和应对流量变化的能力。
  • 效率： 标准化的部署流程和环境，加速了开发、测试和部署周期。
  • 资源利用率： 通过更高效的调度，可以更好地利用集群资源。
  • 可移植性： Kubernetes 可以在各种环境运行（物理机、虚拟机、私有云、公有云），减少了对特定基础设施的依赖。
  • 庞大的生态系统： 作为容器编排领域的领导者，Kubernetes 拥有一个活跃的社区和丰富的周边工具、服务和集成。

Kubernetes 的挑战

虽然强大，Kubernetes 也有其挑战：

  • 学习曲线陡峭： 概念众多，系统复杂，初学者需要投入时间和精力。
  • 运维复杂性： 搭建和维护高可用的生产级 Kubernetes 集群本身就需要专业的知识和经验。
  • 资源消耗： Kubernetes 控制平面本身也需要一定的计算资源。

正因为这些挑战，许多企业会选择使用云服务提供商提供的托管式 Kubernetes 服务（如 GKE, EKS, AKS），将底层集群的运维交给云厂商。

总结与展望

通过这篇文章，我们从传统的部署方式开始，理解了容器带来的变革，以及容器编排（特别是 Kubernetes）解决的核心问题。我们深入探讨了 Kubernetes 的核心架构、控制平面和工作节点的关键组件，以及 Pod、Deployment、Service 等最重要的资源对象。我们还了解了 Kubernetes 声明式 API 和控制循环的工作原理。

这只是 Kubernetes 世界的冰山一角。在你掌握了基础知识并开始实践后，你会接触到更多高级概念，如 Ingress、Helm、Operator、服务网格 (Service Mesh)、CI/CD 集成、监控与日志等。这些都构建在 Kubernetes 的基础之上，进一步提升了云原生应用的开发和管理能力。

从零开始理解 Kubernetes 可能看起来任务艰巨，但只要你循序渐进，结合理论学习和动手实践，一个一个地消化概念，你会发现它并非遥不可及。Kubernetes 已经成为云原生时代不可或缺的基础设施，掌握它将极大地提升你在现代软件开发和运维领域的竞争力。

现在，是时候选择一个本地 Kubernetes 工具，开始你的第一个 Pod 和 Deployment 之旅了！祝你在 Kubernetes 的世界里探索愉快！

发表评论

您的邮箱地址不会被公开。 必填项已用 * 标注

滚动至顶部