什么是Kubernetes架构？

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

什么是 Kubernetes 架构组件？

Kubernetes 集群的主要组件包括：

• 节点： 节点是托管容器化应用程序的虚拟机或物理服务器。集群中的每个节点都可以运行一个或多个应用程序实例。可能只有一个节点，但是，一个典型的 Kubernetes 集群将有多个节点（具有数百或更多节点的部署并不少见）。
• Image Registry：容器镜像保存在注册表中，并由控制平面传输到节点，以便在容器 pod 中执行。
• Pods：Pods 是容器化应用程序运行的地方。它们可以包含一个或多个容器，并且是 Kubernetes 集群中应用程序的最小部署单元。

什么是 Kubernetes 控制平面架构？

Kubernetes 控制平面是 Kubernetes 集群的控制平面。其组成部分包括：

• kube-apiserver。顾名思义，API 服务器公开了作为通信中心的 Kubernetes API。通过命令行界面 (CLI) 或其他用户界面 (UI) 的外部通信传递到 kube-apiserver，所有控制平面到节点的通信也通过 API 服务器。
• etcd：存储与集群相关的所有数据的键值存储。etcd 具有高可用性和一致性，因为对 etcd 的所有访问都是通过 API 服务器进行的。etcd 中的信息通常以人类可读的 YAML 格式（代表递归的“YAML Ain't Markup Language”）。
• kube-scheduler：创建新 Pod 时，该组件会根据资源需求、策略和关于地理位置和与其他工作负载干扰的“亲和性”规范将其分配给节点执行。
• kube-controller-manager：虽然 Kubernetes 集群有多个控制器功能，但它们都被编译成一个名为 kube-controller-manager 的二进制文件。

此过程中包含的控制器功能包括：

• 复制控制器：确保集群中运行的每个复制 pod 存在正确数量的 pod
• 节点控制器：监控每个节点的健康状况，并在节点上线或无响应时通知集群
• Endpoints 控制器：连接 Pod 和服务以填充 Endpoints 对象
• 服务帐户和令牌控制器：将 API 访问令牌和默认帐户分配给集群中的新命名空间
• cloud-controller-manager：如果集群部分或全部基于云，云控制器管理器会将集群链接到云提供商的 API。只有那些特定于云提供商的控件才会运行。云控制器管理器不存在于完全在本地的集群上。可以在集群中运行多个云控制器管理器以实现 容错 或提高整体云性能。

云控制器管理器的元素包括：

• 节点控制器：确定已停止响应的基于云的节点的状态，即是否已被删除
• 路由控制器：在云提供商基础设施中建立路由
• 服务控制器：管理云提供商的负载均衡器

什么是 Kubernetes 节点架构？

节点是 Kubernetes 放置 Pod 执行的机器，无论是虚拟机还是物理服务器。节点组件包括：

• kubelet：每个节点都有一个名为 kubelet 的代理。它确保 PodSpecs 中描述的容器已启动并正常运行。
• kube-proxy：每个节点上的网络代理，它维护网络节点，允许从 Pod 到网络会话的通信，无论是在集群内部还是外部，如果可用的话，使用操作系统 (OS) 数据包过滤。
• 容器运行时：负责运行容器化应用程序的软件。尽管 Docker 是最流行的，但 Kubernetes 支持任何遵循 Kubernetes CRI（容器运行时接口）的运行时。

其他 Kubernetes 基础设施组件是什么？

• Pods：通过封装一个（或多个）应用程序容器，Pods 是 Kubernetes 应用程序最基本的执行单元。每个 Pod 都包含执行所需的代码和存储资源，并拥有自己的 IP 地址。Pod 也包含配置选项。通常，一个 Pod 包含一个或几个容器，这些容器耦合到一个应用程序或业务功能中，并共享一组资源和数据。
• Deployments：一种部署容器化应用程序 Pod 的方法。Deployment 中描述的期望状态将导致控制器更改集群的实际状态，以有序地实现该状态。了解有关 Kubernetes 部署的更多信息。
• ReplicaSet：确保指定数量的相同 Pod 在任何给定时间点运行。
• Cluster DNS：提供运行 Kubernetes 服务所需的 DNS 记录。
• 容器资源监控：在中央数据库中捕获和记录容器指标。

Kubernetes 架构最佳实践和设计原则是什么？

Gartner 的容器最佳实践提出了一种平台战略，该战略考虑了安全、治理、监控、存储、网络、容器生命周期管理和编排，如 Kubernetes。以下是构建 Kubernetes 集群的一些最佳实践：

• 确保您已更新到 最新的 Kubernetes 版本 （撰写本文时为 1.18）。
• 预先投资 于开发人员和运营团队的培训。
• 在企业范围内建立治理 。确保工具和供应商与 Kubernetes 编排保持一致并集成。
• 通过将图像扫描流程集成 为 CI/CD 流程的一部分、在构建和运行阶段进行扫描来增强安全性。从 Github 存储库中提取的开源代码应始终被视为可疑代码。
• 在集群中采用基于角色的访问控制 (RBAC)。最小特权、零信任模型应该是标准。
• 通过仅使用非 root 用户 并使 文件系统只读来进一步保护容器 。
• 避免使用默认值，因为简单的声明更不容易出错并且更清楚地展示意图。
• 使用基本 Docker Hub 映像时要小心，这些映像可能包含恶意软件或包含不必要的代码。从精简、干净的代码开始，然后从那里构建包。小图像构建速度更快，在磁盘上更小，图像拉取也更快。
• 保持容器简单。每个容器一个进程将让编排器报告该进程是否健康。
• 当有疑问时，崩溃。Kubernetes 会重启一个失败的容器，所以不要在失败时重启。
• 详细一点。描述性标签可以帮助当前的开发人员，并且对于开发人员追随他们的脚步非常宝贵。
• 不要对微服务过于细化。并非逻辑代码组件中的每个功能都需要自己的微服务。
• 自动化，在有意义的地方。自动化 CI/CD 管道可以让您完全避免手动 Kubernetes 部署。
• 使用 livenessProbe 和 readinessProbe 来帮助管理 Pod 生命周期，否则 pod 可能会在初始化时终止，或者在它们准备好之前开始接收用户请求。

Kubernetes 架构 简单直观。控制平面和节点之间的松散耦合允许几乎无限的灵活性，并且应用程序能够几乎即时横向扩展以满足不断变化的需求，将用户迁移到新版本，并支持从本地迁移到基于云的节点或在多个云之间利用每个云提供商的所需功能。