在本博客中，我们将探讨构建基础架构的最佳方法，并根据约束条件做出各种决策。
架构
首先，建议你的架构尽可能模块化，以便在将来有需要时可以灵活地进行增量更改。
入口点：DNS
在任何典型的基础架构中（无论是否为云原生），DNS服务器都必须首先解析请求消息以返回服务器的IP地址。
设置DNS应该基于所需的可用性。如果你需要更高的可用性，则要根据可用性级别，将服务器分布在多个云提供商中。
内容分发网络（CDN）
在某些情况下，你可能需要为用户提供尽可能短的延迟，并减少服务器上的负载。这是内容分发网络（CDN）发挥主要作用的地方。
客户端是否经常从服务器请求一组静态资源？你是否需要提高向用户交付内容的速度，同时减少服务器上的负载？在这种情况下，为一组静态资源提供服务的CDN有助于减少用户的延迟和服务器上的负载。
你所有的内容都是动态的吗？你是否需要以一定程度的延迟为用户提供内容以降低复杂性？还是你的应用流量很少？在这种情况下，使用CDN可能没有太大意义，你可以将所有流量直接发送到Global Load Balancer。
CDN提供商包括 Cloudfare CDN, Fastly, Akamai CDN, Stackpath，以及云提供商–Google云平台的Cloud CDN ,亚马逊的 CloudFront , 微软的Azure CDN 等 。
负载均衡器
如果有你的CDN无法满足的请求，则该请求将接下来到达你的负载均衡器。负载均衡器是具有区域性的IP，也可以是全局性的Anycast IP。在某些情况下，你还可以使用负载均衡器来管理内部流量。
除了将流量路由和代理到适当的后端服务之外，负载均衡器还可以负责SSL终止，与CDN集成甚至管理网络流量的某些方面。
尽管确实存在硬件负载均衡器，但软件负载均衡器提供了更大的灵活性，低成本和可伸缩性。
与CDN相似，云提供商也提供负载均衡（例如GCP的GLB，AWS的ELB，Azure的ALB等）。
尽管你应该始终从小做起，但是负载均衡器将允许你逐步扩展：
网络和安全架构
在你的体系结构中要注意的下一件重要事情是网络本身。如果要提高安全性，则可能需要使用私有集群。在那里，你可以管理入站和出站流量，在NAT之后屏蔽IP地址，隔离跨VPC具有多个子网的网络，等等。
设置网络的方式通常取决于你需要的灵活性程度以及实现方式。建立正确的网络关系就是尽可能减少攻击面，同时仍然允许常规操作。
使用网络来保护你的基础架构还涉及使用正确的规则和限制来设置防火墙，以便你仅允许进出各自后端服务的入站和出站流量。
在许多情况下，可以通过设置堡垒机来保护这些专用集群，因为你需要向公共网络公开的只有堡垒机（通常是在与集群相同的网络）。
一些云提供商还提供了针对零信任安全性的定制解决方案。例如，GCP为用户提供了身份识别代理（IAP），可以代替典型的VPN。
一旦处理完所有这些，联网的下一步就是根据你的情况在集群本身内设置联网。
它可能涉及以下任务：
- 在集群内设置服务发现（可由CoreDNS处理）。
- 根据需要设置服务网格（例如LinkerD，Istio，Consul等）
- 设置入口控制器和API网关（例如Nginx，Ambassador，Kong，Gloo等）
- 使用CNI设置网络插件，以促进集群内的联网。
- 设置网络策略以简化服务间通信，并使用各种服务类型根据需要公开服务。
- 使用协议和工具（例如GRPC，Thrift或HTTP）在各种服务之间建立服务间通信。
- 设置A/B测试，如果你使用Istio或Linkerd之类的服务网格，则可以更加轻松。
关于云中网络的有趣之处在于，还可以根据需要选择跨多个地区的多个提供商，这就是Kubefed或 Crossplane等项目可以提供帮助的地方。
如果你想在设置VPC，子网和整个网络时进一步探索一些最佳实践，我建议你仔细阅读本页面，同样的概念也适用于你所使用的任何云提供商。
Kubernetes
如果你使用的是GKE，EKS，AKS，AKS等托管集群，则Kubernetes会自动进行管理，从而使用户摆脱了很多麻烦。
如果你自己管理Kubernetes，则需要注意很多事情，例如备份和加密etcd存储，在集群中的各个节点之间建立网络，定期为节点打补丁，管理集群升级。仅当你有足够的能力进行此工作时，才建议这样做。
站点可靠性工程（SRE）
当你维护复杂的基础架构时，拥有正确的可观察性非常重要，这样你就可以提前发现错误，并预测可能的变化，识别异常，深入探究问题所在。
现在，这将需要你使用代理。这些代理公开应用程序的指标。如果你将服务网格与Sidecar一起使用，它们通常会附带指标而无需你自己进行任何自定义开发。
在任何这种情况下，像Prometheus这样的工具都可以充当时间序列数据库来为你收集所有指标，而像OpenTelemetry这样的工具可以通过内置导出程序从应用程序和各种工具中获取指标。Alertmanager之类的工具可以将通知和警报发送到多个渠道，而Grafana将提供仪表板以在一处可视化所有内容，从而使用户可以整体了解整个基础架构。
总而言之，以下涉及Prometheus的可观察性系统：
具有这样的复杂系统还需要使用日志聚合系统，以便将所有日志都可以流式传输到单个位置，以便于调试。在这里，人们倾向于将ELK或EFK堆栈与Logstash或FluentD一起使用，以根据你的约束为你进行日志聚合和过滤。在这个领域中也有新工具出现，例如Loki和Promtail。
使用FluentD这样的日志聚合系统可以简化我们的基础架构：
但是如何跟踪跨越多个微服务和工具的请求呢？在这里，分布式跟踪也变得非常重要，特别是考虑到微服务所带来的复杂性。Zipkin和Jaeger等工具一直是该领域的先驱，最近进入该领域的是Tempo。
虽然日志聚合可以提供来自各种来源的信息，但不一定提供请求的上下文，这在进行跟踪时真正有用。但是请记住，添加跟踪会增加请求的开销，因为上下文必须与请求一起在服务之间传播。
典型的分布式跟踪：
但是，站点的可靠性并不仅限于监视，可视化和警报。你必须准备好使用常规备份和故障转移来处理系统任何部分中的任何故障，以便不丢失数据或将数据丢失的程度降至最低。这就是Velero等工具发挥主要作用的地方。
Velero可以帮助你维护集群中各个组件的定期备份，包括工作负载，存储等。Velero的架构如下所示：
如你所注意到的，有一个备份控制器定期备份对象，并根据你设置的时间表将它们推送到特定的目的地。由于几乎所有对象都已备份，因此可以将其用于故障转移。
存储
有许多不同的存储供应商和文件系统可用，而且在云提供商之间可能有很大的不同。这就需要像容器存储接口（CSI）这样的标准，从而使大多数数据卷插件易于集成、维护和发展而不会成为核心瓶颈。
CSI支持各种存储插件：
集群存储，扩展以及分布式存储附带的其他各种问题，如何解决呢？
这就需要Ceph类的文件系统，但是考虑到Ceph并不是在考虑Kubernetes的情况下构建的，并且很难部署和管理，就需要使用Rook这样的项目中也。
尽管Rook没有与Ceph耦合，并且还支持EdgeFS，NFS等其他文件系统，但是Rook与Ceph CSI就像是天作之合。
如你所见，Rook负责在Kubernetes集群中安装，配置和管理Ceph。根据用户首选项，存储空间自动分配。所有这一切都不会使应用程序面临任何复杂性。
镜像仓库
镜像仓库为你提供了一个用户界面，你可以在其中管理各种用户帐户，推送/拉取镜像，管理配额，通过Webhooks接收事件通知，进行漏洞扫描，对推送的镜像进行签名以及处理镜像或镜像复制等操作。多个镜像仓库。
如果你使用云提供商，则很有可能他们已经将镜像仓库作为一项服务（例如GCR，ECR，ACR等），这消除了很多复杂性。如果你的云服务提供商不提供服务，那么你也可以使用Docker Hub，Quay等第三方镜像仓库。
但是，如果你想托管自己的镜像仓库怎么办？
如果你要在本地部署镜像仓库，想要对镜像仓库本身进行更多控制，或者想减少与漏洞扫描等操作相关的成本，则可能需要使用像Harbor这样的私有镜像仓库。
Harbor是一个由OCI兼容的镜像仓库，由各种开源组件组成，包括Docker镜像仓库V2，Harbor UI，Clair和Notary。
CI/CD体系结构
Kubernetes是一个很好的平台，可以托管任何规模的各种类型的工作负载，但这也要求采用简单便捷的持续集成/持续交付（CI/CD）工作流程来部署应用程序。
一些第三方服务（例如Travis CI，Circle CI，Gitlab CI或Github Actions） 包括自己的CI运行程序。你只需定义要构建的流水线中的步骤。这通常涉及：构建镜像，扫描镜像以查找可能的漏洞，运行测试并将其推送到镜像仓库，在某些情况下还提供预览功能。
结论
如上所述，各种工具可解决基础架构的不同问题。它们就像乐高积木一样，每个积木都着眼于特定的问题，为你节省了很多复杂性。
这使用户可以使用增量方式利用Kubernetes，而不必一次全部使用，而仅使用整个系统中所需的工具，具体取决于你的需求。
译文链接: https://thenewstack.io/a-deep-dive-into-architecting-a-kubernetes-infrastructure/
