迫切需要使我们的复杂应用程序具有高可用性，可扩展性，可移植性以及可在小模块中独立部署，这导致了Kubernetes的诞生。
今天我们将介绍：
- 什么是Kubernetes?
- 为什么选择Kubernetes?
- Kubernetes体系结构
- Kubernetes的关键组件
什么是Kubernetes?
Kubernetes俗称K8！
K8s是Google开发的生产级开源容器编排工具，可帮助您管理支持多个部署环境(例如本地，云或虚拟机)的容器化/泊坞窗化应用程序。
k8s自动执行容器化映像的部署，并帮助其水平扩展以支持高水平的应用程序可用性。
为什么选择K8s
K8S解决了什么问题?
K8之所以如此受欢迎的主要原因之一是对企业不断增长的需求以支持其微服务驱动的架构需求。
微服务架构可帮助企业：
- 通过将它们分成小的可扩展模块，独立开发和部署其复杂的应用程序
- 帮助他们在支持单个应用程序模块的多个小型团队中工作，以所需的速度和敏捷性进行开发和部署
公司从传统的整体服务向微服务转移的愿望导致了大型容器化应用程序的创建。每个容器映像本身就是一个微服务，需要以较少的开销有效地进行管理和扩展，这种处理成千上万个容器的需求对于组织而言是一项繁琐的任务。这个问题导致K8演变为流行的容器编排工具之一。
该组织采用了诸如Kubernetes之类的容器编排工具，这具有以下主要优点：
K8s提供什么功能?
- 确保高可用性，零停机时间
- 高性能和可扩展性
- 可靠的基础架构可轻松支持数据恢复
既然我们已经了解了为什么必须使用K8，那么现在该对K8的基础体系结构进行解码了
Kubernetes集群的基本架构：
Kubernetes集群的最基本架构具有两个主要节点：
- 主节点
- 辅助节点或从属节点
如果遵循Kubernetes的官方文档，那么掌握它们的概念将变得非常压倒性的。因此，我们将尝试通过必要的简化来理解相同的内容。
首先，让我们了解K8中的工作程序节点或从属节点如何工作，以及工作程序节点的关键组成部分是什么
K8s集群中的工作节点：
图：2.0：K8s集群中的工作节点组件
作为开发人员或K8s管理员，大多数时候您将要处理工作节点，无论是必须部署容器化的应用程序还是必须对其进行自动伸缩，还是必须在生产级服务器上推出任何新的应用程序更新，通常会处理工作者节点。
由于此节点执行集群管理员或开发人员所需的实际工作，因此称为工作节点。工作节点可以具有一个或多个Pod，这些Pod是您对容器化应用程序的抽象。如图2.0所示，每个工作人员都运行这3个关键过程：
- 容器运行时
- kubelet
- Kube proxy
容器运行时：
您部署的每个微服务模块(micro-app)都打包到一个单独的容器中，该容器具有自己的容器运行时。需要将容器运行时安装到群集中的每个工作程序节点中，以便Pod可以在其中运行。
一些容器运行时示例是：
- containerd
- CRI-O
- Docker
kubelet：
kubelet是工作程序节点的主要节点代理，它与节点和给定工作程序节点中的容器交互。
该kubelet负责：
- 在本地系统上维护一组由一个或多个容器组成的Pod。
- 用于向Kubernetes集群注册节点，发送事件和Pod状态以及报告资源利用率。
在一个Kubernetes集群中，kubelet手表PodSpecs通过Kubernetes API服务器。
PodSpec是一个描述Pod的YAML或JSON对象。所述kubelet采用一组通过各种机制(主要是通过提供的PodSpecs的API服务器)，并确保在那些PodSpecs描述的容器正在运行和健康。
| Kubelet是Kubernetes中的主要也是最重要的控制器。它负责驱动容器执行层，通常是Docker。 |
Kube 代理：
K8集群可以有多个工作程序节点，并且每个节点有多个运行的Pod，因此，如果必须访问此Pod，则可以通过Kube-proxy进行访问。
| kube-proxy是一个网络代理，它在集群中的每个节点上运行，实现了Kubernetes Service概念的一部分。 |
为了通过k8s服务访问Pod，有一些网络策略允许从群集内部或外部的网络会话到Pod进行网络通信。这些规则是通过kube-proxy处理的
kube-proxy具有智能算法，可转发Pod访问所需的网络流量，从而最大程度地减少了开销，并使服务通信更加高效
到目前为止，我们已经看到这三个进程需要在您的工作程序节点中成功安装并运行，以便有效地管理您的容器化应用程序，但是更大的问题是
- 谁来管理这些工作程序节点，以确保它们始终处于运行状态?
- K8s集群如何知道应该安排哪些Pod，以及应该丢弃或重启哪些Pod?
- k8s集群如何知道每个容器应用程序的资源级别要求?
答案就在于“主节点”的概念，下面我们来探讨一下。
K8s集群中的主节点：
图：3.0 K8中的主节点进程
所述主节点也被称为一个控制平面，其负责有效地管理工人/从节点。他们与工作节点互动以
- 调度Pod
- 监视工作节点/窗格
- 启动/重启Pod
- 管理加入集群的新工作节点
主节点流程：
K8s集群中的每个主节点都运行以下关键过程：
- kube-apiserver
- kubectl：kube-controller-manager
- Kube Scheduler 调度器
- etcd
让我们详细研究每个流程。
kube-apiserver：
它是访问k8s集群并充当客户端级别身份验证的主要网守的主要网关，或者我们可以说kube-apiserve r是Kubernetes控制平面的前端。
所以只要你想：
- 部署任何新应用
- 调度任何Pod或
- 创建任何新服务
- 查询状态或工作节点的运行状况
您需要向主节点的API服务器发出请求，该服务器随后会在访问工作节点中的进程之前验证您的请求。
| kube-apiserver旨在水平扩展-即，它通过部署更多实例进行扩展。您可以运行kube-apiserver的多个实例并平衡这些实例之间的流量。 |
K8s主节点中的kube-scheduler：
每次作为K8s管理员/开发人员，如果您想在工作节点上安排新的Pod，您都需要将请求发送到主API服务器，该服务器随后将调用Kube-scheduler进程。此处的调度程序将智能地决定应将此Pod放置在哪个工作程序节点上。
因此，我们可以将kube-scheduler定义为：
| 关键的控制平面组件，用于监视没有分配工作节点的新创建的Pod，并选择一个工作节点以对其进行调度和运行。 |
基于每个节点的资源级别可用性，此决定应将新创建的Pod容纳在哪个工作节点上。调度程序进行资源级别查询并做出重要的调度决策。
调度程序级别决策的实际执行是由给定工作节点中的kubelet进程完成的
有关Pod调度的关键决定因素包括：
- 个体和集体资源需求
- 硬件/软件/政策约束
- 节点亲和力和反亲和力规范，
- 数据局部性，工作负载间的干扰和期限。
稍后我们将更详细地介绍k8，我们将了解上述限制和政策。
kube-controller-manager(Kubectl)：
它是监视任何工作节点级别故障状态的主节点中的关键过程之一。它会密切关注像这样的事件
工作节点中任何Pod的崩溃
并且，在检测到此类事件后，请求调度程序重新启动或重新计划任何已失效/失败的Pod。
- 主控制计划器的这些控制管理器组件具有以下类型的控制器：
- 节点控制器：负责在任何工作节点出现故障时做出响应
- 复制控制器：确保始终维护维护任何Pod部署的正确副本数的请求
- 端点控制器：填充“端点”对象。部署，服务和Pod
- 服务帐户和令牌控制器：为在工作程序节点中创建的新名称空间创建默认帐户和API访问令牌。
K8s主节点中的etcd：
主控平面中的etcd负责以键值对的形式存储各种集群级别的更改。
可以很容易地将其视为k8s集群的大脑，它记录着集群中发生的变化的每分钟细节。
例如，如果任何Pod在工作节点中崩溃，并且必须对其进行重新调度，则将其作为键值对存储在etcd中，并且节点上的Pod重新调度的事件也将记录在此处。
因此，数据与一些关键问题有关，例如：
- 节点中有哪些可用资源?
- 集群状态是否由于任何节点故障而改变?
- 集群健康可以吗?
实际存储在此处，以确保我们的k8s集群意识到这一点，并据此采取明智的行动
注意!
诸如DB之类的应用程序级别数据未存储在etcd中。
Kubernetes组件：
现在我们已经了解了K8s的体系结构过程，是时候研究K8s的一些关键组件了，这些组件可以帮助您进行产品级的容器编排。
我们将在这里列出这些组件，并在第二部分中详细介绍每个组件。
“第2部分：Kubernetes的关键组件和概念介绍了“
K8s的一些关键组件是：
- Pods：k8的最小单位，是容器应用程序的抽象
- 服务和入口：管理节点之间的外部通信和内部Pod级通信
- ConfigMaps：管理pod / DB所需的端点URL
- Secret：使用based64编码安全地保存应用程序级密码和机密密钥
- Volumn：用于永久数据存储
- 部署Deployment：部署创建副本并管理无状态应用
- Statefulsets：用于有状态的应用程序和数据库
下一步是什么?
我们将研究上面列出的每个组件的概念，并将进行一些小型动手练习，以了解每个概念的实现。
因此，来考虑一下这个想法：
“如果您知道如何将它们分解为较小的模块，那么任何复杂的系统都可以轻松理解，这种简化事物的艺术一直是复杂的微服务架构背后的核心思想。”
