一通百通，一文实现灵活的 K8S 基础架构( 三 ) _K8S

但是，网站的可靠性并不仅仅止于监控、可视化和告警。你必须准备好处理系统任何部分的任何故障，并定期进行备份和故障切换，这样至少可以将数据损失的程度降到最低。你可以借助类似 Velero 的工具实现。
Velero 通过利用你使用的相同 Kubernetes 架构，帮助你维护集群中各种组件的定期备份，包括你的工作负载、存储等。Velero 的架构如下：
正如你所观察到的，有一个备份 controller，它定期对对象进行备份，根据你设置的计划将它们推送到特定的目的地，其频率是基于你设置的计划。这可以用于故障转移和迁移，因为几乎所有的对象都有备份。
存储有许多不同的存储程序和文件系统可用，这在云提供程序之间可能存在很大的不同。这就需要像容器存储接口（CSI）这样的标准，该标准可以帮助大部分 volume 的外置插件，从而使其易于维护和发展而不会成为核心瓶颈。
下图是 CSI 架构，通常可以支持各种 volume 插件：

文章插图

来源：https://kubernetes.io/blog/2018/08/02/dynamically-expand-volume-with-csi-and-kubernetes/

分布式存储带来的集群、扩展等各种问题怎么办？

这时 Ceph 这样的文件系统已经证明了自己的能力，不过考虑到 Ceph 并不是以 Kubernetes 为中心构建的，部署和管理起来存在一些难度，此时可以考虑 Rook 这样的项目。
虽然 Rook 没有和 Ceph 耦合，也支持其他文件系统，比如 EdgeFS、NFS 等，但 Rook 与 Ceph CSI 就像是天作之合。Rook 与 Ceph 的架构如下：

文章插图

来源：https://rook.io/docs/rook/v1.5/ceph-storage.html

如你所见，Rook 承担了 Kubernetes 集群中的 Ceph 安装、配置和管理的功能。根据用户的喜好，自动分配下面的存储。这一切的发生，都不会让应用暴露在任何复杂的情况下。
镜像仓库镜像仓库为你提供了一个用户界面，你可以在这里管理各种用户账户、推送/拉取镜像、管理配额、通过 webhook 获得事件通知、进行漏洞扫描、签署推送的镜像，还可以处理镜像或在多个镜像仓库中复制镜像等操作。
如果你使用的是云提供商，他们很有可能已经提供了镜像仓库作为一项服务（例如 GCR、ECR、ACR 等），这就消除了很多复杂性。如果你的云提供商没有提供，你也可以选择第三方的镜像仓库，比如 Docker Hub、Quay 等。

但如果你想托管自己的镜像仓库呢？

如果你想在企业内部部署镜像仓库，想对其本身有更多的控制权，或者想降低漏洞扫描等操作的相关成本，那么可能需要进行托管。
如果是这种情况，那么选择像 Harbor 这样的私有镜像仓库会对你有所帮助。
Harbor 架构如下：

文章插图

来源：https://goharbor.io/docs/1.10/install-config/harbor-ha-helm/
Harbor 是一个符合 OCI 的镜像仓库，由各种开源组件组成，包括 Docker 镜像仓库 V2、Harbor UI、Clair 和 Notary 。
CI/CD 架构Kubernetes 可以在任何规模下托管所有的工作负载，但这也需要一个标准的方式来部署应用程序，并采用精简的 CI/CD 工作流程。下图为典型的 CI/CD 流水线：

文章插图

一些第三方服务如 Travis CI、Circle CI、Gitlab CI 或 Github Actions 都包含了自己的 CI 运行器。你只需定义你要构建的流水线中的步骤。这通常包括：构建镜像，扫描镜像以查找可能的漏洞，运行测试并将其推送到镜像仓库，在某些情况下还需要提供一个预览环境以进行审批。
现在，虽然如果你管理自己的 CI 运行器，步骤通常保持不变，但你需要将它们配置为在集群内部或外部设置，并具有适当的权限，以便将资产推送到镜像仓库。
总结我们已经介绍了基于 Kubernetes 的云原生基础设施的架构。正如我们上面所看到的，各种工具解决了基础设施的不同问题。它们就像乐高积木一样，每一个都专注于当前的一个特定问题，为你抽象掉了很多复杂的东西。
这使得用户可以以渐进的方式逐渐上手 Kubernetes 。并且你可以根据你的用例，只使用整个堆栈中你需要的工具。