-
介绍
-
什么是 Kubernetes?
-
Kubernetes 架构和组件
-
Master Node - 控制节点
- API Server
- Key-Value Store (etcd)
- Controller 控制器
- Scheduler
-
Worker Node-工作节点
- kubelet
- Container Runtime
- Kube代理
- Pod
-
Kubernetes Services
- Kubernetes 服务如何工作?
-
什么是容器部署?
- 传统部署
- 虚拟化部署
- 容器部署
-
结论
介绍
本教程是重点介绍 Kubernetes 和容器部署概念的系列文章中的第一篇。Kubernetes 是一种用于管理容器化应用程序集群的工具, 这个过程通常称为编排。
Kubernetes 协调许多微服务,这些微服务一起形成一个有用的应用程序。Kubernetes 自动且永久地监控集群并对其组件进行调整。了解 Kubernetes 架构对于部署和维护容器化应用程序至关重要。
什么是 Kubernetes?
Kubernetes,简称k8s,是一个自动化应用程序部署的系统。现代应用程序分散在云、虚拟机和服务器中。手动管理应用程序不再是一个可行的选择。
K8s 将虚拟机和物理机转变为统一的 API 界面。然后,开发人员可以使用 Kubernetes API 来部署、扩展和管理容器化应用程序。
其架构还为分布式系统提供了灵活的框架。K8s 自动为您的应用程序协调扩展和故障转移,并提供部署模式。
它有助于管理运行应用程序的容器,并确保生产环境中不会出现停机。例如,如果一个容器出现故障,另一个容器会自动取代它的位置,而最终用户却不会注意到。
Kubernetes 不仅仅是一个编排系统。它是一组独立的、相互联系的控制过程。它的作用是持续处理当前状态并将流程朝着所需的方向移动。
如果您想了解有关容器编排的更多信息,请查看我们关于什么是 Kubernetes 的文章。
Kubernetes 架构和组件
Kubernetes 具有分散式架构,不按顺序处理任务。它基于声明性模型运行并实现“期望状态”的概念。这些步骤说明了基本的 Kubernetes 流程:
现在,我们将探索标准 Kubernetes 集群的各个组件,以更详细地了解该过程。
Master Node - 控制节点
Kubernetes Master(主节点)通过 API 从 CLI(命令行界面)或 UI(用户界面)接收输入。这些是您提供给 Kubernetes 的命令。
您可以定义希望 Kubernetes 维护的 Pod、副本集和服务。例如,要使用哪个容器映像、要公开哪些端口以及要运行多少个 Pod 副本。
您还可以为该集群中运行的应用程序提供所需状态的参数。
API Server
API Server是控制平面的前端,也是控制平面中唯一与我们直接交互的组件。内部系统组件以及外部用户组件都通过相同的 API 进行通信。
Key-Value Store (etcd)
键值存储,也称为etcd,是 Kubernetes 用于备份所有集群数据的数据库。它存储集群的整个配置和状态。主节点查询etcd以检索节点、pod 和容器状态的参数。
Controller 控制器
Controller的作用是从API Server获取所需的状态。它检查其任务控制的节点的当前状态,并确定是否存在任何差异,并解决它们(如果有)。
Scheduler
调度程序监视来自 API 服务器的新请求并将它们分配给健康的节点。它对节点进行排名并将 Pod 部署到最适合的节点上。如果没有合适的节点,Pod 将处于挂起状态,直到出现这样的节点。
Worker Node-工作节点
Worker节点监听API Server以获取新的工作;他们执行工作,然后将结果报告回 Kubernetes 主节点。
kubelet
kubelet运行在集群中的每个节点上。它是主要的 Kubernetes 代理。通过安装 kubelet,节点的 CPU、RAM 和存储成为更广泛集群的一部分。它监视从 API Server 发送的任务,执行任务,并向 Master 报告。它还监视 Pod,并在 Pod 未完全正常工作时向控制面板报告。根据该信息,Master 可以决定如何分配任务和资源以达到所需的状态。
Container Runtime
容器运行环境从容器映像注册表中提取映像并启动和停止容器。第三方软件或插件(例如 Docker, PodMan)通常执行此功能。
Kube代理
kube -proxy确保每个节点获取其 IP 地址,实现本地iptables和规则来处理路由和流量负载平衡。
Pod
Pod是 Kubernetes中最小的调度元素。没有它,容器就不能成为集群的一部分。如果您需要扩展应用程序,则只能通过添加或删除 Pod 来实现。
Pod 充当具有应用程序代码的单个容器的“包装器”。Master根据资源的可用性,将pod调度到特定的节点上,并与容器运行环境协调来启动容器。
如果 Pod 意外无法执行其任务,Kubernetes 不会尝试修复它们。相反,它会在其位置创建并启动一个新的 Pod。这个新的Kubernetes Pod是一个副本,除了 DNS 和 IP 地址之外。此功能对开发人员设计应用程序的方式产生了深远的影响。
由于 Kubernetes 架构的灵活性,应用程序不再需要绑定到 Pod 的特定实例。相反,需要设计应用程序,以便在集群内任何位置创建的全新 Pod 可以无缝取代它。为了协助完成此过程,Kubernetes 使用services。
Kubernetes Services
Pod 不是恒定的。Kubernetes 提供的最佳功能之一是,无法运行的 pod 会自动被新的 pod 替换。
但是,这些新 Pod 具有一组不同的 IP。它可能会导致一些问题,并且由于 IP 不再匹配而导致 IP 流失。如果无人看管,这个特性将使 Pod 变得非常不可靠。
引入服务的目的是通过为不稳定的 Pod 世界带来稳定的 IP 地址和 DNS 名称来提供可靠的网络。
通过控制进出 Pod 的流量,Kubernetes 服务提供了稳定的网络端点——固定的 IP、DNS 和端口。通过服务,可以添加或删除任何 Pod,而不必担心基本网络信息会发生任何变化。
Kubernetes 服务如何工作?
Pod 通过称为标签和选择器的键值对与服务关联。服务会自动发现具有与选择器匹配的标签的新 Pod。
此过程将新的 Pod 无缝添加到服务中,同时从集群中删除已终止的 Pod。
例如,如果所需状态包括pod 的三个副本,并且运行一个副本的节点失败,则当前状态将减少为两个 pod。Kubernetes 观察者认为理想的状态是三个 Pod。然后,它会安排一个新副本来代替发生故障的 Pod,并将其分配给集群中的另一个节点。
通过添加或删除 Pod 来更新或扩展应用程序时,同样适用。一旦我们更新了所需的状态,Kubernetes 就会注意到差异并添加或删除 pod 以匹配清单文件。Kubernetes 控制面记录、实施和运行后台协调,不断检查环境是否符合用户定义的要求。
什么是容器部署?
为了充分理解 Kubernetes 编排的方式和内容,我们需要探索容器部署的概念。
传统部署
最初,开发人员将应用程序部署在单独的物理服务器上。这种类型的部署带来了一些挑战。物理资源的共享意味着一个应用程序可能会占用大部分处理能力,从而限制同一台计算机上其他应用程序的性能。
硬件扩容需要很长时间,进而增加成本。为了解决硬件限制,组织开始虚拟化物理机。
虚拟化部署
虚拟化部署允许您在单个物理服务器上创建隔离的虚拟环境、虚拟机 (VM) 。该解决方案隔离虚拟机内的应用程序、限制资源的使用并提高安全性。应用程序无法再自由访问另一个应用程序处理的信息。
虚拟化部署使您能够快速扩展并分散单个物理服务器的资源、随意更新并控制硬件成本。每个虚拟机都有自己的操作系统,并且可以在虚拟化硬件之上运行所有必要的系统。
容器部署
容器部署是推动创建更灵活、更高效模型的下一步。与虚拟机非常相似,容器拥有单独的内存、系统文件和处理空间。然而,严格隔离已不再是限制因素。
多个应用程序现在可以共享相同的底层操作系统。此功能使容器比成熟的虚拟机更加高效。它们可以跨云、不同设备和几乎任何操作系统发行版移植。
容器结构还允许应用程序作为更小的独立部分运行。然后可以在多台计算机上动态部署和管理这些部分。复杂的结构和任务的细分过于复杂,无法手动管理。
需要一个自动化解决方案(例如 Kubernetes)来有效管理此过程中涉及的所有移动部件。
结论
Kubernetes 使用非常简单的模型运行。我们输入我们希望系统如何运行——Kubernetes 将所需状态与集群内的当前状态进行比较。然后,它的服务将协调这两个状态,实现并维持所需的状态。