介绍
在本实验中，你将使用 Minikube 探索一个本地 Kubernetes 集群。你将启动集群，验证其设置，并检查基本的集群资源，如 Pod 和 Deployment。这种动手实践将帮助你理解 Kubernetes 环境的基本组件和命令，为进一步的探索和开发奠定基础。
你将首先在本地机器上设置一个 Minikube 集群，确保集群正在运行并准备就绪。然后，你将使用基本的 kubectl 命令（如 kubectl cluster-info 和 kubectl get nodes）验证集群的配置和健康状况。最后，你将检查基本的集群资源，包括 Pod 和 Deployment，以熟悉 Kubernetes 对象模型和集群的整体状态。
启动本地 Kubernetes 集群
在这一步中，你将使用 Minikube 启动并验证一个本地 Kubernetes 集群。Minikube 提供了一种简单的方式来设置单节点的 Kubernetes 环境，适用于学习和开发。
首先，导航到项目目录：
cd ~/project
启动 Minikube 集群：
注意：免费用户无法连接到互联网，因此 Minikube 已预先启动。你可以跳到下面的代码部分来验证集群状态。升级为专业用户 以练习自行启动集群。
minikube start
示例输出：
😄 minikube v1.29.0 on Ubuntu 22.04
✨ Automatically selected the docker driver
📌 Using Docker driver with root permissions
🔥 Creating kubernetes in kubernetes cluster
🔄 Restarting existing kubernetes cluster
🐳 Preparing Kubernetes v1.26.1 on Docker 20.10.23 ...
🚀 Launching Kubernetes ...
🌟 Enabling addons: storage-provisioner, default-storageclass
🏄 Done! kubectl is now configured to use "minikube" cluster and "default" namespace
使用多个命令验证集群状态：
minikube status
示例输出：
minikube
type: Control Plane
host: Running
kubelet: Running
apiserver: Running
kubeconfig: Configured
检查集群节点：
kubectl get nodes
示例输出：
NAME STATUS ROLES AGE VERSION
minikube Ready control-plane 1m v1.26.1
这些命令确认了以下几点：
- Minikube 已成功启动
- 本地 Kubernetes 集群正在运行
- 集群已准备就绪
- 你拥有一个具备控制平面功能的单节点集群
Minikube 集群在你的本地机器上提供了一个完整的 Kubernetes 环境，使你无需完整的多节点集群即可开发和测试应用程序。
Kubernetes 架构概述
Kubernetes 采用客户端 - 服务器模型运行，其中集中式的控制平面（Control Plane）负责管理集群的状态，而一组工作节点（Worker Nodes）则运行工作负载。从高层次来看，用户（通常是开发者）通过命令行工具或 API 与 Kubernetes 集群交互。控制平面决定哪些工作负载应该运行在哪些节点上，监控集群的健康状态，并确保达到期望的状态。工作节点以 Pod（一组一个或多个容器）的形式托管你的应用程序，并提供运行这些应用程序所需的计算和存储资源。
控制平面（Control Plane）
这是集群的“大脑”，由多个组件组成，共同协作以管理整个系统：
- **kube-apiserver (API)**：作为集群的前门。所有管理命令和资源请求都通过它传递。
- **etcd (Key Value Store)**：存储所有配置数据和集群的当前状态。如果丢失 etcd 数据，集群的状态也会丢失。
- **kube-scheduler (SCH)**：根据资源需求、约束和策略将 Pod 分配到节点。
- **kube-controller-manager (CTLM)**：运行多种控制器，持续调整集群状态，确保实际状态与部署和配置中定义的期望状态一致。
节点（工作机器）
节点是工作负载运行的地方。每个节点包含：
- **kubelet (KLT)**：节点级别的代理，与控制平面通信。它确保 Pod 正在运行，并将其状态报告回控制平面。
- 容器运行时（Container Runtime, CR）：运行和管理容器的软件（例如 Docker 或 containerd）。它在 Pod 中创建和管理容器化应用程序。
Pod
Pod 是 Kubernetes 中最小的可部署单元，通常代表一个正在运行的应用程序实例。Pod 可以包含一个或多个容器，这些容器共享相同的网络命名空间和存储卷。
服务（Service）
服务是一种抽象，定义了一组逻辑 Pod 以及访问它们的策略。服务提供稳定的 IP 地址、DNS 名称和负载均衡，确保外部消费者和其他集群组件能够可靠地连接到你的应用程序——即使 Pod 在节点之间移动或在扩展或滚动更新期间被替换。
与集群交互
- 开发者和管理员通过 kube-apiserver 与集群交互，通常使用
kubectl或其他 Kubernetes 客户端。 - 当部署新应用程序时，控制平面组件（调度器、控制器）会将 Pod 分配到适当的节点。
- 每个节点上的 kubelet 确保 Pod 健康并按指令运行。
- 服务将流量路由到正确的 Pod，使客户端能够访问应用程序，而无需跟踪 Pod 位置的变化。
flowchart TB
%% 用户与集群交互
User((开发者))
User -->|kubectl CLI| API[kube-apiserver]
%% 控制平面组件
subgraph ControlPlane[Control Plane]
API
ETCD[etcd - Key Value Store]
SCH[kube-scheduler]
CTLM[kube-controller-manager]
API --> ETCD
API --> SCH
API --> CTLM
end
%% 工作节点 1
subgraph Node1[Worker Node]
KLT1[kubelet]
CR1[Container Runtime]
subgraph Pods1[Pods]
P1[Pod]
P2[Pod]
end
KLT1 --> CR1
CR1 --> P1
CR1 --> P2
end
%% 工作节点 2
subgraph Node2[Worker Node]
KLT2[kubelet]
CR2[Container Runtime]
subgraph Pods2[Pods]
P3[Pod]
P4[Pod]
end
KLT2 --> CR2
CR2 --> P3
CR2 --> P4
end
%% 控制平面与节点之间的连接
API --> KLT1
API --> KLT2
%% 服务连接到不同节点上的 Pod
Service[Service]
Service --> P1
Service --> P2
Service --> P3
Service --> P4
在图中：
- 开发者通过 CLI 工具（如
kubectl）与kube-apiserver(API) 交互。 - 控制平面组件（API、etcd、调度器、控制器管理器）管理集群状态并编排工作负载。
- 每个工作节点运行一个 kubelet 和一个容器运行时，托管多个 Pod。
- 服务将外部或内部流量路由到正确的 Pod，提供一个稳定的端点，抽象了 Pod 生命周期和 IP 变化的复杂性。
这种心智模型帮助你理解在检查集群状态、检查节点健康、列出 Pod 和查询服务时所看到的内容——这些概念将在你继续使用 kubectl 命令探索 Kubernetes 时得到应用。
验证集群设置
在这一步中，你将学习如何使用基本的 kubectl 命令来验证 Kubernetes 集群的配置和健康状况。这些命令将帮助你了解集群的当前状态和连接性。
首先，检查集群信息：
kubectl cluster-info
示例输出：
Kubernetes control plane is running at https://192.168.49.2:8443
CoreDNS is running at https://192.168.49.2:8443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy
To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'
该命令提供了 Kubernetes 控制平面和核心服务（如 CoreDNS）的详细信息。
接下来，获取集群节点的详细视图：
kubectl get nodes -o wide
示例输出：
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION
minikube Ready control-plane 15m v1.26.1 192.168.49.2 <none> Ubuntu 22.04 LTS 5.15.0-72-generic
让我们更全面地检查节点详细信息：
kubectl describe node minikube
示例输出（部分）：
Name: minikube
Roles: control-plane
Labels: beta.kubernetes.io/arch=amd64
beta.kubernetes.io/os=linux
kubernetes.io/arch=amd64
kubernetes.io/hostname=minikube
kubernetes.io/os=linux
minikube.k8s.io/commit=86a3b7e45a9a35cdcf8f4c80a4c6a46d20dda00f
Annotations: node.alpha.kubernetes.io/ttl: 0
volumes.kubernetes.io/controller-managed-attach-detach: true
CreationTimestamp: [Current Timestamp]
Capacity:
cpu: 2
ephemeral-storage: 17784212Ki
memory: 1947748Ki
pods: 110
Allocatable:
cpu: 2
ephemeral-storage: 16388876Ki
memory: 1845348Ki
pods: 110
通过这些命令获得的关键信息：
- 验证集群控制平面是否正在运行
- 检查节点状态（Ready/NotReady）
- 了解节点资源和配置
- 确认 Kubernetes 版本和节点详细信息
检查基本集群资源
在这一步中，你将检查 Kubernetes 的基本资源——例如 Pod、Deployment 和 Service——跨所有命名空间（namespace）。通过使用 -A（或 --all-namespaces）标志，你将看到资源在整个集群中的组织方式。这是介绍和理解 Kubernetes 中命名空间（Namespace）概念的绝佳机会。
命名空间：资源隔离
命名空间是 Kubernetes 集群中的逻辑分区，用于帮助组织和管理资源。它们提供了一种将相关对象分组并在细粒度级别应用策略、访问控制和资源配额的方式。通过将资源分离到不同的命名空间中，你可以：
- 提高组织性：将相关的工作负载分组（例如按项目、团队或环境——如开发、测试和生产）。
- 增强安全性和访问控制：限制哪些用户或服务账户可以查看或修改特定命名空间中的资源。
- 简化资源管理：更有效地应用资源限制、网络策略和其他集群范围的配置。
当你使用 -A（或 --all-namespaces）标志列出资源时，你会注意到属于 Kubernetes 系统的组件位于 kube-system 命名空间中，该命名空间专用于集群级基础设施。用户创建的应用程序通常位于 default 命名空间或你定义的其他自定义命名空间中。
命名空间和资源
flowchart LR
%% 用户通过 kube-apiserver 与集群交互
User((开发者))
User -->|kubectl get pods -A| API[kube-apiserver]
%% 控制平面子图
subgraph ControlPlane[Control Plane]
API
ETCD[etcd]
SCH[kube-scheduler]
CTLM[kube-controller-manager]
end
API --> ETCD
API --> SCH
API --> CTLM
%% kube-system 命名空间
subgraph kube-system[Namespace: kube-system]
SysDeployment[Deployment: coredns]
SysPod1[Pod: coredns-xxx]
SysService[Service: kube-dns]
SysDeployment --> SysPod1
SysService --> SysPod1
end
%% default 命名空间（重命名以避免解析问题）
subgraph defaultNs[Namespace: default]
DefDeployment[Deployment: my-app]
DefPod1[Pod: my-app-pod1]
DefPod2[Pod: my-app-pod2]
DefService[Service: my-app-service]
DefDeployment --> DefPod1
DefDeployment --> DefPod2
DefService --> DefPod1
DefService --> DefPod2
end
%% dev 命名空间
subgraph dev[Namespace: dev]
DevDeployment[Deployment: dev-app]
DevPod[Pod: dev-app-pod]
DevService[Service: dev-app-service]
DevDeployment --> DevPod
DevService --> DevPod
end
%% 通信演示
API --> kube-system
API --> defaultNs
API --> dev
在图中：
- 控制平面管理整个集群，与节点通信并控制工作负载。
- 命名空间（如
kube-system、default和dev）在集群内逻辑上分离资源。kube-system包含系统级组件，如 CoreDNS 和 kube-dns。default通常用于一般工作负载，这里以my-app部署为代表。dev可能代表开发环境，与生产工作负载隔离。
通过查看所有命名空间中的资源，你可以全面了解这些逻辑分区如何帮助维护一个组织良好且安全的集群。
示例：
列出所有命名空间中的所有 Pod：
kubectl get pods -A
示例输出：
NAMESPACE NAME READY STATUS RESTARTS AGE
kube-system coredns-787d4945fb-j8rhx 1/1 Running 0 20m
kube-system etcd-minikube 1/1 Running 0 20m
kube-system kube-apiserver-minikube 1/1 Running 0 20m
kube-system kube-controller-manager-minikube 1/1 Running 0 20m
kube-system kube-proxy-xb9rz 1/1 Running 0 20m
kube-system kube-scheduler-minikube 1/1 Running 0 20m
kube-system storage-provisioner 1/1 Running 1 (20m ago) 20m
在这里，你可以看到所有与系统相关的 Pod 运行在 kube-system 命名空间中。如果你在其他命名空间中有其他部署或服务，它们也会出现在此列表中，每个资源都清楚地由其命名空间限定。
列出所有命名空间中的所有 Deployment：
kubectl get deployments -A
示例输出：
NAMESPACE NAME READY UP-TO-DATE AVAILABLE AGE
kube-system coredns 1/1 1 1 20m
coredns 部署位于 kube-system 命名空间中。
获取所有命名空间中所有资源的综合视图：
kubectl get all -A
该命令显示不同命名空间中的 Pod、服务和部署的概览，帮助你了解这些资源在集群中的分布情况。
关键要点：
- 命名空间在 Kubernetes 集群中提供逻辑隔离和组织。
- 不同的 Kubernetes 组件和资源被组织到特定的命名空间中（例如，
kube-system用于核心服务，default用于一般工作负载，以及你创建的其他命名空间）。 - 通过使用
-A查看所有命名空间中的资源，你可以深入了解集群的结构以及命名空间如何作为资源组织和访问控制的边界。
通过理解命名空间如何作为逻辑环境运行，你可以更好地导航、隔离和管理你的工作负载及相关集群资源，尤其是在扩展部署并向 Kubernetes 环境引入更多复杂性时。
总结
在本实验中，你使用 Minikube 启动并验证了一个本地 Kubernetes 集群，Minikube 提供了一种简单的方式来设置单节点的 Kubernetes 环境，适用于学习和开发。你确认了 Minikube 集群已成功启动，本地 Kubernetes 集群正在运行，集群已准备就绪，并且你拥有一个具备控制平面功能的单节点集群。你还学习了如何使用基本的 kubectl 命令（如 kubectl cluster-info 和 kubectl get nodes）来验证 Kubernetes 集群的配置和健康状况，这些命令帮助你了解了集群的当前状态和连接性。
