共计 5529 个字符，预计需要花费 14 分钟才能阅读完成。
这篇文章给大家介绍如何实现灵活的 K8S 基础架构，内容非常详细，感兴趣的小伙伴们可以参考借鉴，希望对大家能有所帮助。
Kubernetes 是当前最为流行的开源容器编排平台，成为众多企业构建基础架构的首选。在本文中，我们将探讨针对你的用例构建基础设施的最佳方式，以及你可能要根据各种限制条件做出的各种决定。
架构设计
你的架构应该在很大程度上围绕你的用例来设计，因此在设计过程中你需要非常仔细以确保该基础架构能够支撑你的用例，在必要的时候也可以寻求外部专业团队的帮助。在架构设计的开始保证方向正确十分重要，但是这并不意味着不会发生错误，而且随着每天都有新的技术或研究横空出世，你可以看到变革已经成为常态，并且你的架构设计思维有可能过时。
这就是为什么我强烈建议你采用 Architect for Chang 的原则，让你的架构成为一个模块化的架构以便在未来有需要的时候你可以灵活地在内部进行改变。
让我们看看在考虑 client-server 模型的情况下如何实现系统架构的目标。
切入点：DNS
在任何典型的基础架构中（无论是否是云原生架构），一个消息请求必须先由 DNS 服务器解析，并返回服务器的 IP 地址。设置你的 DNS 应该基于你所需要的可用性。如果你需要更高的可用性，你可能想要将你的服务器分布到多个区域或者云提供程序上，具体的实现要基于你想要达到的可用性等级。
内容分发网络（CDN）
在某些情况下，你可能需要尽可能地以最小的延迟为用户提供服务，同时减少服务器的负载。这就是内容分发网络（CDN）发挥重要作用的地方。Client 是否经常从服务器上请求一组静态资产？你是否希望提高向用户交付内容的速度，同时减少服务器的负载？在这种情况下，采用边缘的 CDN 为一组静态资产提供服务，实际上可能有助于降低用户的延迟和服务器的负载。
你所有的内容都是动态的吗？你是否可以在一定程度上为用户提供延迟的内容，以减少复杂性？或者你的应用程序接收很低的流量吗？在这种情况下，使用 CDN 可能没有太大的意义，你可以将所有的流量直接发送到全局负载均衡器。但要注意的是，拥有 CDN 也确实有分配流量的优势，这在你的服务器受到 DDOS 攻击时是很有帮助的。
CDN 提供程序包括 Cloudfare CDN、Fastly、Akamai CDN、Stackpath，此外你的云提供商也有可能会提供 CDN 服务，比如谷歌云平台的 Cloud CDN、AWS 的 CloudFront、微软 Azure 的 Azure CDN 等。
Load Balancer
如果有一个请求不能被你的 CDN 服务，这个请求下一步会传送到你的负载均衡器上。而这些可以是区域性的 IP，也可以是全局性的 Anycast IP。在某些情况下，你也可以使用负载均衡器来管理内部流量。
除了路由和代理流量到合适的后端服务，负载均衡还能够承担 SSL 终止、与 CDN 集成，甚至管理网络流量的某些方面等职责。
虽然存在硬件负载均衡器，但软件负载均衡器提供了强大的灵活性、减少了成本开支以及弹性伸缩性。
与 CDN 类似，你的云提供程序应该也能够为你提供一个负载均衡器（如 GCP 的 GLB、AWS 的 ELB、Azure 的 ALB 等），但更有趣的是你可以直接从 Kubernetes 中调配这些负载均衡器。例如，在 GKE 中创建一个 Ingress 也会在后端为你创建一个 GLB 来接收流量，其他功能如 CDN、SSL 重定向等也可以通过配置你的 ingress 来设置，访问以下链接查看详情：
https://cloud.google.com/kubernetes-engine/docs/how-to/ingress-features
虽然一开始总是从小开始，但是负载均衡器可以让你逐步扩展至具有以下规模的架构：
网络及安全架构
下一件需要关注的事情是网络。如果你想要提高安全性，你可能需要一个私有集群。在那里，你可以调节入站和出站流量，在 NATs 后面屏蔽 IP 地址，在多个 VPC 上隔离多个子网的网络等。
如何设置网络通常取决于你所追求的灵活性程度以及如何实现它。设置正确的网络就是要尽可能地减少攻击面，同时还能保持正常的运转。
通过设置正确的网络来保护你的基础设施通常还涉及到使用正确规则和限制条件设置的防火墙，以便限制来自各后端服务的流量的进出，包括入站和出站。
在很多情况下，可以通过设置堡垒主机并通过隧道进行集群中的所有操作来保护这些私有集群，因为你需要向公共网络公开的就是堡垒（又称 Jump host），通常是在与集群相同的网络中设置。
一些云提供商在实现零信任安全的方法上也提供了定制化的解决方案。例如，GCP 为其用户提供身份意识代理（IAP），可用于代替典型的 VPN 实现。
所有都处理好之后，下一步是根据你的用例在集群本身内设置网络。这牵涉到以下任务：
设置集群内的服务发现（可由 CoreDNS 处理）
如果需要的话，设置一个服务网格（如 LinkerD、Istio、Consul 等）
设置 Ingress controller 和 API 网关（例如：Nginx、Ambassador、Kong、Gloo 等）
设置使用 CNI 的网络插件，方便集群内的联网
设置网络策略，调节服务间的通信，并根据需要使用各种服务类型暴露服务
使用 GRPC、Thrift 或 HTTP 等协议和工具，设置不同服务之间的服务间通信
设置 A / B 测试，如果你使用像 Istio 或 Linkerd 这样的服务网格，实现起来可以更容易
如果你想看一些示例实现，我建议你看看这个 repo（https://github.com/terraform-google-modules/cloud-foundation-fabric），它可以帮助用户在 GCP 中设置所有这些不同的网络模型，包括通过 VPN 的 hub 和 spoke、用于内部的 DNS 和 Google Private Access、支持 GKE 的共享 VPC 等等，所有这些都使用 Terraform。而云计算中网络的有趣之处在于，它不局限于你所在地区的云服务商，而是可以根据需要跨越多个地区的多个服务商。这就是 Kubefed 或 Crossplane 这样的项目可以提供帮助的地方。
如果你想探索更多关于设置 VPC、子网和整体网络时的一些最佳实践，我建议你访问下方网页，同样的概念也适用于你加入的任何云提供商：
https://cloud.google.com/solutions/best-practices-vpc-design
Kubernetes
如果你使用的是 GKE、EKS、AKS 这样的托管集群，Kubernetes 是自动管理的，从而降低了用户操作的复杂程度。
如果你自己管理 Kubernetes，你需要处理很多事情，比如，备份和加密 etcd 存储，在集群中的各个节点之间建立网络，定期为你的节点打上最新版本的操作系统补丁，管理集群升级以与上游的 Kubernetes 版本保持一致。基于此，只有当你拥有一个专门的团队来维护这些事情的时候，才建议这样做。
Site Reliability Engineering (SRE)
当你维护一个复杂的基础设施时，拥有合适的可观察性堆栈是非常重要的，这样你就可以在用户注意到错误之前就检测到错误以及预测可能的变化，进而识别异常，并有余力深入钻研问题到底在哪里。
现在，这就需要你有代理，将指标暴露为特定的工具或应用来收集分析（可以遵循 pull 或 push 机制）。而如果你使用的是带有 sidecars 的服务网格，它们往往会自带指标，而不需要自定义配置。
在任意场景下，都可以使用 Prometheus 这样的工具作为时序数据库，为你收集所有的指标，以及借助类似于 OpenTelemetry 的工具，使用内置的 exporter 从应用程序和各种工具中公开指标。借助 Alertmanager 之类的工具可以向多个渠道发送通知和告警，Grafana 将提供可视化仪表板，给用户提供整个基础设施的完整可见性。
综上，这就是 Prometheus 的可观察性的解决方案：
来源：https://prometheus.io/docs/introduction/overview/
拥有这样复杂的系统，还需要使用日志聚合系统，这样所有的日志就可以流到一个地方，便于调试。大部分企业倾向于使用 ELK 或 EFK 堆栈，Logstash 或 FluentD 根据你的限制条件为你做日志聚合和过滤。但日志领域也有新的玩家，比如 Loki 和 Promtail。
下图说明了类似 FluentD 的日志聚合系统如何简化你的架构：
来源：https://www.fluentd.org/architecture
但是，如果要追踪跨越多个微服务和工具的请求呢？这是分布式跟踪开始发挥作用的地方，特别是考虑到微服务的复杂性。像 Zipkin 和 Jaeger 这样的工具一直是这个领域的先驱，最近进入这个领域的新兴工具是 Tempo。
虽然日志聚合会给出各种来源的信息，但它不一定能给出请求的上下文，这才是做跟踪真正有帮助的地方。但是请记住，在你的堆栈中添加跟踪会给你的请求增加很大的开销，因为上下文必须和请求一起在服务之间传播。
下图是一个典型的分布式跟踪架构：
来源：https://www.jaegertracing.io/docs/1.21/architecture/
但是，网站的可靠性并不仅仅止于监控、可视化和告警。你必须准备好处理系统任何部分的任何故障，并定期进行备份和故障切换，这样至少可以将数据损失的程度降到最低。你可以借助类似 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。并且你可以根据你的用例，只使用整个堆栈中你需要的工具。
关于如何实现灵活的 K8S 基础架构就分享到这里了，希望以上内容可以对大家有一定的帮助，可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到。
