这是与Kubernetes相关的系列帖子中的第一篇。这篇介绍性文章将讨论 Kubernetes 是什么、为什么使用它、它的高级架构以及它的核心组件和概念是什么。

本系列后面的文章将是更多的动手教程,将详细介绍 Kubernetes 的工作、集群的设置、扩展部署、定义服务等。

Kubernetes、Mesos、Dockers 是少数几个彻底改变了我们部署和管理软件应用程序和服务的方式的开源项目。在过去的 10 年里,这个 DevOps 领域发生了很多变化。如果您有兴趣了解发生了什么变化,请查看我之前关于构建和部署大型 Web 应用程序的一篇博文。在这些开源项目中,Kubernetes 和 Dockers 肯定处于领先地位。 Kubernetes 简称也称为k8s(这里的8代表单词kubernetes中k到s个字符之间的字母数)。 2015 年,当谷歌将该项目开源时,它开始在软件开发人员和 DevOps 社区中获得关注。

什么是 Kubernetes?

Kubernetes 是一种分布式软件,可创建集群和可扩展的工作负载部署基础架构。它允许我们在物理(或虚拟)分布式计算机集群(在集群术语中也称为节点)上以自动化方式部署、服务、监控、负载平衡、横向扩展、横向扩展我们的容器化应用程序(工作负载) .

让我们看看我们如何使用 Kubernetes 使我们的工作负载具有高可用性和可扩展性,同时使部署过程变得顺畅和轻松。下图将帮助我们了解 Kubernetes 集群的整体架构及其关键组件和概念。

Kubernetes架构及关键组件

下面,我将简要介绍 Kubernetes](https://kubernetes.io/docs/concepts/overview/components/)的[主要组件,并解释它们的高级功能。

• Cluster:一般来说,cluster是指一个group。在计算中,cluster是指一组计算机。这些机器可以是物理(裸机)或虚拟计算机,它们作为统一的单一计算资源一起工作。

• Node:node是指集群中的单个计算机。同样,这可以是物理的或虚拟的。在 Kubernetes 中,有两种类型的nodes——主节点和工作节点。主节点是运行控制平面并在工作节点上部署、控制、管理、调度和监视工作负载的计算机。大多数关键的 Kubernetes 系统进程在主节点上运行为pod(解释如下)。

• Pod :在 Kubernetes 中,pod代表 Kubernetes 管理的最小部署单元。一个 pod 可能有一个或多个容器在其中运行,以及其他共享资源,例如网络命名空间和共享卷。在常规场景中,大多数 Pod 都是在其中创建单个容器的。 Kubernetes 创建了一些系统 pod,它们对其正常运行至关重要。大多数这些系统 pod 在主节点上运行,但在所有 Kubernetes 节点(主节点和每个工作节点)上运行的kubelet和kube-proxy除外。在 masternode上运行的系统pods如下:

*kube-apiserver(一般也称为API server)是一个系统进程,在master节点上作为pod运行,负责通过每个worker节点上运行的kubelet进程与worker节点进行通信。 API 服务器就像一个中枢神经系统,对于 Kubernetes 集群的正常工作至关重要。API server还作为kubectl命令行实用程序的服务器,通过它我们可以运行命令以在集群上执行特定操作。kubectl是作为客户端工作的命令行实用程序,可以安装在集群外的任何计算机上,以管理集群。通过kubectl,我们可以执行任何类型的集群操作,例如创建、列出和删除不同的集群对象,例如pod、deployment、service等。

*kube-scheduler是一个系统进程,在主节点上作为pod运行,负责在工作节点上调度工作负载(应用程序 pod)。它知道健康nodes上的可用资源,并且还维护要调度的pods的优先级队列。它确定应该在哪个node上部署哪个pod。它还可以根据需要在nodes上抢占、驱逐和移动pods,以优化集群节点内的资源利用率。

*kube-controller-manager是一个系统进程,在主节点上作为pod运行,负责监视集群的状态。它确保集群的当前状态始终保持接近所需状态。每当状态变化使集群偏离其所需状态时,控制器管理器就会通过其他系统 pod 采取行动,将集群状态恢复到所需状态。例如,如果我们想要一个应用程序的 5 个实例正在运行(期望状态)并且控制器管理器以某种方式注意到只有三个实例正在运行,它将确保另外两个实例(pod)启动以恢复到期望状态。

• Kubernetes 支持多个云提供商,允许我们在任何云环境中运行 Kubernetes 集群。云控制器管理器是一个系统进程,在主节点上作为pod运行,负责将云复杂性与 Kubernetes 隔离和解耦。例如,如果我们想在集群中添加一些托管在云中的新节点,云控制器管理器会使用云 API 来处理这些节点。云控制器管理器遵循插件架构,允许不同的云提供商添加不同的功能以在各自的云平台上支持 Kubernetes。

*etc是一个系统进程,在主节点上作为pod运行。它将集群的存储管理为键值存储。您可以在此处阅读有关etcd的更多详细信息。

*kubelet是一个系统进程,在每个集群节点上作为pod运行。它代表 API 服务器充当代理,管理和监视该工作节点上的pods。它确保它遵循来自 API 服务器的命令(根据 podspecs)来维护工作节点上分配的 pod。它还负责在 Kubernetes 集群中注册一个新节点。

*kube-proxy是一个系统进程,在每个集群节点上作为pod运行。它作为网络代理工作。它维护节点上的网络规则。这些网络规则允许从 Kubernetes 集群内部或外部的网络会话与pods进行网络通信。

• Container:Kubernetes 建立在容器理念之上。容器是一个封装的包,其中包含工作负载(应用程序)及其所有依赖项,以使应用程序从部署角度完全可移植。这意味着,如果您将应用程序打包为容器,那么您可以在 Windows、Linux 或 Mac 机器上部署和运行您的应用程序,前提是这些机器安装了可以运行容器的容器运行时软件。Docker是容器运行时引擎的一个例子,它是 Kubernetes 的默认容器运行时引擎。如果您是容器新手,我会要求您观看这个快速的视频,它讨论了容器和 VM 之间的差异。

• 部署:Kubernetes 中的术语deployment表示pods在其容器(ReplicaSet)中运行相同的应用程序/工作负载的逻辑分组。这些 pod 不必位于同一个node上。它们可以分布在集群节点上的任何位置。创建像deployment这样的逻辑分组的目的是轻松地跨节点横向扩展或缩减工作负载。为了理解它,让我给你一个实际的场景。让我们考虑一个管理客户及其订单的简单应用程序。如果我们根据领域驱动设计原则构建这个应用程序,我们将有两个有界上下文 - 一个用于客户,另一个用于订单。在微服务上下文中,这将是两个具有自己的数据库的独立服务。现在通过这个示例考虑一个用例,其中订单数量在节日期间突然达到峰值。为了处理这个用例,我们需要扩展我们的订单服务,但可能不会对我们的客户服务做同样的事情。 Kubernetes 中的deployment解决了这种扩展特定服务(一般工作负载)的特殊需求。在本系列的后续教程中,我们将通过动手示例了解它是如何完成的。

• Service:在 Kubernetes 中,service是一个概念,将相似的pods逻辑绑定并为其分配一个通用的网络身份(网络名称和网络 IP)。虽然名称相同,但不要将 Kubernetesservice与软件开发中的microservice混淆。它可能代表一个实际的microservice,或者它甚至可能代表一个可扩展的单体应用程序(取决于您如何设计应用程序)作为工作负载运行。在 Kubernetes 中定义service的目的是将运行工作负载的 pod 作为统一资源公开给其他内部(集群内)或外部工作负载消费者。由于service将虚拟网络 IP 和网络名称分配给pods集合,这允许使用service的虚拟 IP 或网络名称访问在这些 pod 中运行的工作负载,无需知道 IP 或各个 pod 的名称访问它们(无论如何从集群外部都是不可能的)。它还允许我们对运行工作负载的 pod 之间的流量进行负载平衡。

这就是 Kubernetes 的目的和更高级别的架构。我希望这篇文章能帮助您了解 Kubernetes 是什么,以及它的整体高级架构及其每个关键组件的功能。在下一篇文章中,我将介绍如何使用minikube在本地计算机上设置单节点集群。敬请期待。