Kubernetes 集群架构详解与实践

介绍

在本实验中，我们将探索 Kubernetes 的架构，这是一个强大的容器编排平台。我们将研究构成 Kubernetes 集群的关键组件，并了解它们如何协同工作来管理容器化应用程序。本实验专为初学者设计，提供 Kubernetes 架构的实践入门。

探索控制平面组件

让我们从使用 Minikube 启动一个 Kubernetes 集群并检查控制平面组件开始。

首先，打开终端。默认情况下，你应该位于 /home/labex/project 目录中。如果不在，请导航到该目录：

cd ~/project

现在，使用以下命令启动 Minikube：

minikube start

此命令将在你的本地机器上初始化一个单节点的 Kubernetes 集群。完成此操作可能需要几分钟时间。如果你看到大量输出，请不要担心——这是正常现象。

Minikube 启动后，让我们探索控制平面组件。控制平面是 Kubernetes 的大脑，负责管理集群的整体状态。要检查这些组件的状态，请运行：

kubectl get componentstatuses

你应该会看到类似以下的输出：

NAME                 STATUS    MESSAGE             ERROR
scheduler            Healthy   ok
controller-manager   Healthy   ok
etcd-0               Healthy   {"health":"true"}

让我们分解一下每个组件的作用：

调度器（scheduler）：该组件监视新创建的未分配节点的 Pod，并为其选择一个节点运行。
控制器管理器（controller manager）：该组件运行控制器进程，用于调节系统的状态。例如，复制控制器确保运行正确数量的 Pod 副本。
etcd：这是一个分布式键值存储，作为 Kubernetes 所有集群数据的后备存储。

如果所有组件都显示为 "Healthy"，则你的控制平面运行正常。如果看到任何错误，可以尝试使用 minikube delete 删除集群，然后重新启动 Minikube：minikube start。

检查节点组件

现在我们已经了解了控制平面，接下来让我们检查节点组件。在 Kubernetes 中，节点是运行应用程序的工作机器。可以将它们视为集群的“肌肉”，负责运行容器的繁重工作。

要查看集群中的节点，请运行：

kubectl get nodes

你应该会看到类似以下的输出：

NAME       STATUS   ROLES    AGE   VERSION
minikube   Ready    control plane   10m   v1.20.0

此输出显示我们有一个名为 "minikube" 的节点，它既是主节点（控制平面）也是工作节点，因为我们使用的是单节点集群。在生产环境中，通常会有多个节点，主节点和工作节点是分开的。

"Ready" 状态表示节点健康并准备好接受 Pod。

要获取有关节点的更详细信息，请使用：

kubectl describe node minikube

此命令提供了有关节点的丰富信息。如果看起来信息量很大，请不要担心——让我们分解一些关键部分：

节点状态（Node Conditions）：这些显示了各种节点状态的状态（例如，Ready、DiskPressure、MemoryPressure）。
容量（Capacity）：这显示了节点上可用的总资源（CPU 和内存）。
可分配资源（Allocatable）：这显示了可供 Pod 使用的资源。
系统信息（System Info）：这提供了有关节点操作系统、内核版本和容器运行时的信息。

关键的节点组件（你不会直接看到，但它们正在节点上运行）包括：

kubelet：这是主要的节点代理。它监视分配给其节点的 Pod，并确保它们正在运行。
kube-proxy：这维护节点上的网络规则，允许从集群内部或外部与你的 Pod 进行网络通信。

创建并检查 Pod

在开始之前，让我们先了解 YAML 在 Kubernetes 中的工作原理：

graph TB
    A[YAML 配置文件] -->|声明期望状态| B[Kubernetes API]
    B -->|创建/管理| C[运行中的容器]
    D[kubectl CLI] -->|读取| A

Kubernetes 中的 YAML 文件充当“基础设施即代码”：

可以将其视为告诉 Kubernetes 你想要什么的“菜单”
以人类可读的格式描述你期望的系统状态
可以进行版本控制以支持团队协作

让我们创建第一个 YAML 文件。创建 simple-pod.yaml：

nano ~/project/simple-pod.yaml

添加以下内容：

## --- YAML 文件开头 ---
## 1. 告诉 Kubernetes 使用哪个 API 版本
apiVersion: v1
## 2. 声明我们要创建的资源类型
kind: Pod
## 3. 设置此资源的元数据
metadata:
  name: nginx-pod ## Pod 的名称
  labels: ## 标签帮助我们查找和组织 Pod
    app: nginx
## 4. 定义 Pod 应包含的内容
spec:
  containers: ## Pod 可以运行一个或多个容器
    - name: nginx ## 容器的名称
      image: nginx:latest ## 使用的容器镜像
      ports: ## 暴露的端口
        - containerPort: 80 ## Nginx 默认使用端口 80

YAML 文件的结构类似于树：

Pod (根)
├── metadata (分支)
│   ├── name (叶子)
│   └── labels (叶子)
└── spec (分支)
    └── containers (分支)
        └── - name, image, ports (叶子)

创建 Pod：

kubectl apply -f simple-pod.yaml ## -f 表示从文件读取

此命令将：

读取你的 YAML 文件
将其发送到 Kubernetes API
Kubernetes 将努力实现你描述的状态

验证 Pod 的创建：

kubectl get pods

你应该会看到：

NAME        READY   STATUS    RESTARTS   AGE
nginx-pod   1/1     Running   0          30s

READY 下的 "1/1" 表示 Pod 中的一个容器已准备就绪。STATUS 下的 "Running" 表示你的第一个 YAML 配置成功了！

💡 专业提示：

YAML 中的缩进至关重要——使用空格，而不是制表符

使用 kubectl explain pod 查看字段文档

始终添加注释以提高可维护性

要获取有关 Pod 的详细信息：

kubectl describe pod nginx-pod

此命令提供了大量信息，包括：

Pod 运行的节点
Pod 的 IP 地址
Pod 中的容器
与 Pod 相关的最新事件

这些信息对于调试和理解应用程序的状态至关重要。

创建 Service

现在我们已经有一个正在运行的 Pod，接下来让我们创建一个 Service 来暴露它。在 Kubernetes 中，Service 是一种抽象，定义了一组逻辑上的 Pod 以及访问它们的策略。可以将其视为将应用程序暴露到网络的一种方式，无论是在集群内部还是外部。

在项目目录中创建一个名为 nginx-service.yaml 的文件：

nano ~/project/nginx-service.yaml

向文件中添加以下内容：

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

让我们分解这个 YAML 文件：

selector：这决定了 Service 将流量发送到哪些 Pod。在本例中，它将选择带有标签 app: nginx 的任何 Pod。
ports：这指定了 Service 应使用的端口。
type: NodePort：这意味着 Service 将在集群中每个节点的端口上可访问。

保存文件并退出编辑器。

现在，通过运行以下命令创建 Service：

kubectl apply -f nginx-service.yaml

要检查 Service 的状态，请使用：

kubectl get services

你应该会看到类似以下的输出：

NAME            TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE
kubernetes      ClusterIP   10.96.0.1       <none>        443/TCP        1h
nginx-service   NodePort    10.110.126.65   <none>        80:30080/TCP   30s

nginx-service 行显示你的 Service 已创建。PORT(S) 下的 80:30080/TCP 表示集群内部的端口 80 映射到节点上的端口 30080。

要获取有关 Service 的更多详细信息，请使用：

kubectl describe service nginx-service

此命令提供了有关 Service 的类型、IP 地址、端口和端点的信息。端点是 Service 将流量发送到的 Pod 的 IP 地址。

访问应用程序

现在我们已经有一个运行应用程序的 Pod 和一个暴露它的 Service，接下来让我们访问该应用程序。此步骤将向你展示我们设置的所有组件如何协同工作以使你的应用程序可访问。

首先，我们需要找到 Minikube 为我们的 Service 分配的 URL：

minikube service nginx-service --url

此命令将输出一个 URL，类似于 http://192.168.64.2:30080。IP 地址在你的机器上可能会有所不同。

要访问应用程序，你可以使用 curl 命令后跟 URL：

curl $(minikube service nginx-service --url)

这应该会返回默认的 Nginx 欢迎页面 HTML。如果你看到以 <!DOCTYPE html> 开头的 HTML 输出，恭喜！你已成功访问了你的应用程序。

让我们分解一下刚刚发生的事情：

你的请求首先到达我们创建的 NodePort Service。
然后，Service 将请求转发到运行 Nginx 容器的 Pod。
Nginx 容器处理请求并返回默认的欢迎页面。

这展示了 Kubernetes 如何抽象底层基础设施，使你能够专注于应用程序，而无需担心它运行在哪个特定的机器上。

总结

在本实验中，我们通过检查 Kubernetes 的关键组件及其交互，探索了 Kubernetes 的架构。我们使用 Minikube 启动了一个 Kubernetes 集群，检查了控制平面和节点组件，创建了一个 Pod 来运行应用程序，使用 Service 暴露了应用程序，并最终访问了该应用程序。

graph TB
    subgraph Control Plane
        API[API Server]
        CM[Controller Manager]
        SCH[Scheduler]
        ETCD[etcd]
        API --> ETCD
        API --> CM
        API --> SCH
    end

    subgraph Worker Node
        KL[kubelet]
        KP[kube-proxy]
        CR[Container Runtime]

        subgraph Workloads
            POD1[Pod]
            POD2[Pod]
        end

        SVC[Service]

        KL --> CR
        POD1 --> CR
        POD2 --> CR
        KP --> SVC
        SVC --> POD1
        SVC --> POD2
    end

    API --> KL
    Client[External Client] --> SVC

我们学习了以下内容：

控制平面组件，如 API Server、调度器（Scheduler）和控制器管理器（Controller Manager）
节点组件，如 kubelet 和 kube-proxy
Pod 作为 Kubernetes 中最小的可部署单元
Service 作为暴露应用程序的一种方式

这种实践经验为理解 Kubernetes 架构提供了坚实的基础。请记住，Kubernetes 是一个复杂的系统，包含许多动态部分，如果你没有立即理解所有内容，这是正常的。随着你继续使用 Kubernetes，这些概念将变得更加熟悉和直观。

你 Kubernetes 学习之旅的下一步可能包括学习如何使用 Deployment 管理应用程序的多个副本、使用 ConfigMap 和 Secret 管理配置，以及使用 Persistent Volume 进行数据存储。继续探索，祝你 Kubernetes 之旅愉快！