本文主要是介绍Kubernetes入门-Kubernetes集群构成，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
目录
前言
控制面板节点与工作节点
控制面板节点
工作节点
被托管的Kubernetes
用kubectl命令行工具管理Kubernetes
前言
- 前面说过，Kubernetes是云的操作系统
- 顾名思义，它位于应用和基础设施之间
- Kubernetes运行在基础设施上，而应用运行在Kubernetes上，如下图所示
- 上图显示了在4种不同的基础设施平台上运行的4个Kubernetes装置
- 由于Kubernetes抽象了底层的基础设施，因此上图顶部的应用可以在任何一个Kubernetes装置上运行，也可以在不同的Kubernetes装置之间进行迁移
- 我们称一个Kubernetes装置为Kubernetes集群(cluster)
- 关于上图，还有两点需要说明一下
- 首先，一个Kubernetes集群跨越多种基础设施的情况并不常见
- 例如，你不可能看到单个Kubernetes集群跨多个云，也不太可能看到集群跨本地和公有云
- 这主要是受网络速度和可靠性的制约
- Kubernetes需要集群中的节点通过可靠的低延迟网络进行连接
- 其次，尽管Kubernetes可以在许多平台上运行，但容器有更严格的要求：
- Windows容器只能在有Windows节点的Kubernetes集群上运行
- Linux容器只能在有Linux节点的集群上运行
- 这同样适用于CPU架构——为ARM64架构构建的容器不会运行在Aarch64集群节点上
控制面板节点与工作节点
- 一个Kubernetes集群是一台或多台安装了Kubernetes的机器
- 这些机器可以是物理服务器、虚拟机(VM)、云实例、笔记本电脑、树莓派等
- 在这些机器上安装Kubernetes，并将它们连接在一起，就形成了一个Kubernetes集群
- 然后，就可以将应用部署到这个集群中
- 我们通常把Kubernetes集群中的机器称为节点(node)
- 说到节点，Kubernetes集群有两种类型的节点：
- 1-控制面板节点
- 2-工作节点
- 在一些旧文档中可能会将控制面板节点称为“主节点”
- 这个术语已被包容性命名倡议淘汰，这个倡议旨在避免在技术项目中使用可能有害的语言
- 控制面板节点托管着内部Kubernetes服务，而工作节点则是运行用户应用的地方
- 下图展示的是一个由6个节点组成的Kubernetes集群，它有3个控制面板节点和3个工作节点
- 推荐的做法是，所有的用户应用都只在工作节点上运行，让控制面板节点运行Kubernetes系统服务
控制面板节点
- 控制面板节点托管着内部Kubernetes系统服务，这些服务是确保Kubernetes正常运行不可或缺的，统称为控制面板
- 控制面板可能听起来太过专业，但它不过是一种花哨的说法，意思是Kubernetes的大脑
- 考虑到这一点，一种很好的做法是配多个控制面板节点来实现高可用性(high availability，HA)
- 这样一来，如果其中一个出现故障，集群仍然可以继续运行
- 在真实世界中，生产集群中通常有3或5个控制面板节点，并且它们分散在不同的故障域中
- 不要把它们放在同一个有故障的电源上的同一个漏水的空调装置下的同一块地砖上
- 下图是一个有3个节点的高可用控制面板，每个节点都在一个独立的故障域中，有独立的网络和电力基础设施等
- 控制面板节点运行以下服务，它们共同组成了控制面板（集群的大脑）：
- 1-API服务器
- 2-调度器
- 3-存储器
- 4-云控制器(cloud controller)
- ……
- API服务器是Kubernetes集群中你唯一能够直接交互的部分
- 例如，当你向集群发送的命令被送到API服务器时，你收到的响应也都来自API服务器
- 调度器选择在哪些工作节点上运行用户应用
- 存储器是存储集群和所有应用的状态的地方
- 云控制器允许Kubernetes与云服务（如存储和负载均衡器）集成
- 后面的实践案例会把云负载均衡器与部署到Kubernetes集群的应用整合在一起
工作节点
- 工作节点是运行用户应用的地方，可以是Linux工作节点，也可以是Windows工作节点
- 一个集群中可同时包含Linux工作节点和Windows工作节点，Linux应用运行在Linux工作节点上，而Windows应用运行在Windows工作节点上
- 如下图所示
- 所有工作节点都在运行下列服务，值得了解一下：
- 1-kubelet
- 2-容器运行时
- kubelet是主Kubernetes代理(agent)
- 它将工作节点加到集群中，并与控制面板进行通信，如接收任务和报告任务的状态
- 容器运行时负责启动和停止容器
- Kubernetes最初使用的容器运行时是Docker，但Kubernetes于2016年引入了容器运行时接口，让这一层变成可插拔的
- 因此，可供选择的容器运行时有很多
- Containerd是简化版的Docker，是当今Kubernetes集群最流行的容器运行时
- Containerd全面支持Docker创建的容器镜像
被托管的Kubernetes
- 被托管的Kubernetes是一种消费模型，指云提供商向你出租一个Kubernetes集群，有时我们称其为Kubernetes即服务
- 被托管的Kubernetes是获得Kubernetes最简单的方法之一
- 在托管模式下，云提供商构建了Kubernetes集群，拥有控制面板，并负责以下所有事项：
- 1-控制面板的性能
- 2-控制面板的可用性
- 3-控制面板的更新
- 而用户通常要负责以下事项：
- 1-工作节点
- 2-用户应用
- 3-支付费用
- 被托管的Kubernetes的基本架构如下图所示
- 大多数云提供商都有托管的Kubernetes服务
用kubectl命令行工具管理Kubernetes
- Kubernetes集群的大部分日常管理可以通过Kubernetes命令行工具kubectl完成
- 管理任务包括部署和管理应用，检查集群和应用的健康状况，以及执行对集群和应用的更新
- 你可以获得适用于Linux、macOS、Windows和各种ARM/ Raspberry Pi相关的操作系统的kubectl
- 在后面会看到如何安装这个工具
- 下面的kubectl命令列出了集群中的所有节点
这篇关于Kubernetes入门-Kubernetes集群构成的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
