什么是 Kubernetes 体系架构?
Kubernetes 是一种为跨集群的服务发现提供松耦合机制的体系架构。一个 Kubernetes 集群中有一个或多个控制平面,以及一个或多个计算节点。总体而言,控制平面负责管理整个集群,公开应用程序接口 (API),并根据所需的配置安排计算节点的启动和关闭。每个计算节点都运行一个容器运行时(如 Docker)以及一个与控制平面通信的代理 - kubelet。每个节点可以是裸机服务器、本地部署虚拟机或云端虚拟机 (VM)。

vSphere with Tanzu 基础知识 - vSphere 管理员入门指导

为何选择将 VMware 虚拟化用于 Kubernetes 和容器
Kubernetes 体系架构包括哪些组件?
Kubernetes 集群的主要组件包括:
节点:节点是托管容器化应用的虚拟机或物理服务器。集群中的每个节点都可以运行一个或多个应用实例。尽管 Kubernetes 集群可以少到只有一个节点,但通常会有多个节点(具有数百甚至更多个节点的部署并不少见)。
映像注册表:容器映像保留在注册表中,并通过控制平面传输到节点,以在容器 Pod 中执行。
Pod:Pod 是运行容器化应用的地方。它们可以包含一个或多个容器,是 Kubernetes 集群中应用的最小部署单元。
什么是 Kubernetes 控制平面体系架构?
Kubernetes 控制平面是 Kubernetes 集群的控制平面。其组件包括:
- kube-apiserver。从它的名字就可以看出,API 服务器公开 Kubernetes API,后者是通信中心。外部通信通过命令行界面 (CLI) 或其他用户界面 (UI) 传递到 kube-apiserver,而所有控制平面到节点的通信也通过 API 服务器。
- etcd:键值存储区,其中存储了与集群相关的所有数据。etcd 高度可用且一致,对于 etcd 的所有访问都通过 API 服务器。etcd 中的信息通常采用人类可读的 YAML 格式,YAML 表示“YAML Ain’t Markup Language”(YAML 不是标记语言)的递归缩写。
- kube-scheduler:当创建一个新的 Pod 时,该组件会根据资源要求、策略、有关地理位置的“关联性”规范以及对其他工作负载的干扰情况,将其分配给一个节点以便执行。
- kube-controller-manager:尽管一个 Kubernetes 集群具有多个控制器功能,但它们都被编译为一个名为 kube-controller-manager 的二进制文件。
此流程中包含的控制器功能包括:
- 复制控制器:确保集群中运行的每个复制 Pod 中存在正确数量的 Pod
- 节点控制器:监控每个节点的运行状况,当节点联机或是无响应时通知集群
- 端点控制器:连接 Pod 和服务以填充端点对象
- 服务帐户和令牌控制器:将 API 访问令牌和默认帐户分配给集群中新的 Namespace
- cloud-controller-manager:如果集群部分或全部基于云部署,则云控制器管理器将集群链接到云服务提供商的 API。只有特定于该云服务提供商的控件才会运行。云控制器管理器不位于完全基于本地部署的集群中。一个集群中可以运行多个云控制器管理器,以确保容错或提高整体云性能。
云控制器管理器的要素包括:
- 节点控制器:判断停止响应的云端节点的状态,例如,是否已被移除
- 路由控制器:在云服务提供商基础架构中建立路由
- 服务控制器:管理云服务提供商的负载均衡器
什么是 Kubernetes 节点体系架构?
节点是 Kubernetes 放置 Pod 以便执行的机器(虚拟机或物理服务器)。节点组件包括:
kubelet:每个节点都有一个名为 kubelet 的代理,用来确保 PodSpec 中描述的容器启动并正常运行。
kube-proxy:这是每个节点上用于维护网络节点的网络代理,它允许使用操作系统 (OS) 数据包筛选功能(如果可用)筛选从 Pod 到网络会话的通信,不管是在集群内部还是外部。
容器运行时:负责运行容器化应用的软件。尽管 Docker 很流行,但 Kubernetes 支持任何符合 Kubernetes CRI(容器运行时接口)标准的运行时。
还有哪些其他的 Kubernetes 基础架构组件?
Pod:通过封装一个(或多个)应用容器,Pod 成为 Kubernetes 应用的最基本的执行单元。每个 Pod 都包含执行所需的代码和存储资源,并有自身的 IP 地址。Pod 还包括配置选项。通常,一个 Pod 包含一个或几个与应用或业务功能耦合并共享一组资源和数据的容器。
部署:一种部署容器化应用 Pod 的方法。部署中描述的预期状态会导致控制器更改集群的实际状态,以便有序地实现预期状态。敬请详细了解 Kubernetes 部署。
ReplicaSet:确保在任何给定时间点运行指定数量的相同 Pod。
集群 DNS:提供运行 Kubernetes 服务所需的 DNS 记录。
容器资源监控:捕获容器指标并在中央数据库中记录。
Kubernetes 体系架构的最佳实践和设计原则是什么?
Gartner 的容器最佳实践提出了一种平台战略建议,该战略考虑了安全性、监管、监控、存储、网络连接、容器生命周期管理和编排(如 Kubernetes)等方面。
以下是构建 Kubernetes 集群的一些最佳实践:
- 确保更新到最新的 Kubernetes 版本(截至到撰写本文时为 1.18)。
- 针对开发人员和运维团队培训进行前期投资。
- 在企业范围内建立监管机制。确保工具和供应商与 Kubernetes 编排协调一致。
- 通过将映像扫描流程集成到 CI/CD 流程中来增强安全性,并在构建和运行阶段进行扫描。始终对从 Github 存储库中获取的开源代码保持怀疑态度。
- 在整个集群中采用基于角色的访问控制 (RBAC)。最低权限、零信任模式应成为标准。
- 通过仅使用非 root 用户并将文件系统设置为只读来进一步保护容器。
- 避免使用默认值,因为简单的声明不容易出错,而且能更清楚地表明意图。
- 使用基本 Docker Hub 映像时要小心,其中可能包含恶意软件或者不需要的代码。先从精简、干净的代码开始,然后再构建软件包。小映像的构建速度更快,占磁盘空间更小,映像提取速度也更快。
- 保持容器简单。一个容器一个进程,以便于 Orchestrator 报告进程状态是否正常。
- 如果不正常,则崩溃。Kubernetes 会重启故障容器,无需用户重启。
- 详细一点。描述性标签既对当前开发人员有帮助,也对跟进其工作的开发人员大有裨益。
- 不需要太精细的微服务。在一个逻辑代码组件中,不是每个功能都需要微服务。
- 如果自动化有意义,则自动化。自动化 CI/CD 流水线让您可以完全避免手动部署 Kubernetes。
- 使用 livenessProbe 和 readinessProbe 来帮助管理 Pod 生命周期,否则 Pod 可能会在初始化时终止,或者尚未准备就绪就开始接收用户请求。
Kubernetes 体系架构简单而直观。控制平面和节点之间的松耦合带来几乎无限的灵活性,使应用能够近乎即时地横向扩展,来满足不断变化的需求,同时,还可以将用户迁移到新版本,并支持从本地部署到云端节点的迁移或多个云之间的迁移,以充分利用每个云服务提供商的预期功能特性。
相关解决方案和产品
采用 Kubernetes 进行应用现代化改造
使您能够同时运行传统和现代应用。
Horizon Cloud on Microsoft Azure
云原生虚拟桌面平台