Kubernetes 概述与架构
了解 Kubernetes 的高层架构。
什么是 Kubernetes?
Kubernetes 是一组原语,使我们能够运行健壮的分布式应用程序。它负责应用的自动扩缩容和故障转移。此外,它还包含部署模式和 API,帮助我们自动化资源管理并支持新工作负载的部署。
简介
开发者面临的最大挑战之一,是将注意力集中在代码复杂性上,而非基础设施管理。解决这一问题的主要架构理念之一是无服务器(Serverless)架构。AWS Lambda、AWS Fargate、Azure Functions 等多种平台允许我们将应用程序以单个函数或容器的形式部署为无服务器应用。然而,这些托管平台存在一些局限性:
- 供应商锁定(Vendor lock-in)
- 应用程序二进制文件/构件大小受限
- 冷启动性能差
假设我们只能在私有数据中心运行应用,或者正在使用 Kubernetes。即便如此,我们仍希望利用无服务器架构的优势。为此,像 Knative 和 OpenFaaS 这样的开源平台和工具借助 Kubernetes 抽象底层基础设施,让开发者可以使用无服务器架构和模式来部署和管理应用。
架构与组件
Kubernetes 采用客户端-服务器架构。集群中有一个主控节点作为命令与控制中心,并作为通信枢纽。该主控节点由多个组件构成,包括 Kube-apiserver、etcd 存储、Kube-controller-manager、cloud-controller-manager、Kube-scheduler 以及为 Kubernetes 服务提供 DNS 的服务器。
Kubernetes 主要包含两个核心组件:
- 主控节点(Master node)
- 工作节点(Worker nodes)
主控节点组件
主控节点的主要组件如下:
-
etcd 集群:这是用于存储 Kubernetes 集群数据、服务发现信息和 API 对象的键值存储系统。
-
kube-apiserver:Kubernetes API 服务器是集群的核心管理实体,接收所有对集群状态的 REST 请求(如 Pod、Service、副本集/控制器等的变更),并作为集群的前端接口。它是唯一与 etcd 集群直接连接的组件,确保集群数据的一致性,以及已部署 Pod 的服务信息准确无误。
-
kube-controller-manager:该组件在后台运行多个独立的控制器进程,用于维护集群的状态并执行常规任务。
-
Kube-scheduler:该组件根据资源使用情况,决定将 Pod 调度到哪个节点。它会读取服务的运行需求,并将其安排在最合适的节点上。
工作节点组件
-
kubelet:这是节点上的核心服务,定期接收新的或更新后的 Pod 规范,确保 Pod 及其容器的健康运行。
-
kube-proxy:该代理服务运行在每个工作节点上,负责处理主机子网配置。它还将服务暴露给外部网络,并在集群内部的隔离网络之间转发请求至相应的 Pod 或容器。
kubectl
kubectl 是用于与 Kubernetes 集群交互的命令行工具。kubectl 支持两种操作方式:
- 声明式(Declarative):通过提供一个描述期望状态的清单文件(manifest),kubectl 将其提交到集群,由集群自行判断如何实现目标状态。
- 命令式(Imperative):通过直接输入具体的集群操作命令,明确指示 kubectl 执行特定任务。
在本课程中,我们将优先采用声明式方法来使用 Kubernetes。你会发现,当只需说明“我想要什么”,而无需关心“如何实现”时,整个过程变得简单得多。