共计 5197 个字符，预计需要花费 13 分钟才能阅读完成。
作者简介
VIGNESH T.V.，Timecampus CEO、CTO 及创始人。
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/kube…
尽管一开始总是从小开始，然而负载均衡器能够让你逐渐扩大至具备以下规模的架构：
网络及平安架构
下一件须要关注的事件是网络。如果你想要进步安全性，你可能须要一个公有集群。在那里，你能够调节入站和出站流量，在 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-…），它能够帮忙用户在 GCP 中设置所有这些不同的网络模型，包含通过 VPN 的 hub 和 spoke、用于外部的 DNS 和 Google Private Access、反对 GKE 的共享 VPC 等等，所有这些都应用 Terraform。
而云计算中网络的乏味之处在于，它不局限于你所在地区的云服务商，而是能够依据须要逾越多个地区的多个服务商。这就是 Kubefed 或 Crossplane 这样的我的项目能够提供帮忙的中央。
如果你想摸索更多对于设置 VPC、子网和整体网络时的一些最佳实际，我倡议你拜访下方网页，同样的概念也实用于你退出的任何云提供商：
https://cloud.google.com/solu…
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/in…
领有这样简单的零碎，还须要应用日志聚合零碎，这样所有的日志就能够流到一个中央，便于调试。大部分企业偏向于应用 ELK 或 EFK 堆栈，Logstash 或 FluentD 依据你的限度条件为你做日志聚合和过滤。但日志畛域也有新的玩家，比方 Loki 和 Promtail。
下图阐明了相似 FluentD 的日志聚合零碎如何简化你的架构：
起源：https://www.fluentd.org/archi…
然而，如果要追踪逾越多个微服务和工具的申请呢？这是分布式跟踪开始发挥作用的中央，特地是思考到微服务的复杂性。像 Zipkin 和 Jaeger 这样的工具始终是这个畛域的先驱，最近进入这个畛域的新兴工具是 Tempo。
尽管日志聚合会给出各种起源的信息，但它不肯定能给出申请的上下文，这才是做跟踪真正有帮忙的中央。然而请记住，在你的堆栈中增加跟踪会给你的申请减少很大的开销，因为上下文必须和申请一起在服务之间流传。
下图是一个典型的分布式跟踪架构：
起源：https://www.jaegertracing.io/…
然而，网站的可靠性并不仅仅止于监控、可视化和告警。你必须筹备好解决零碎任何局部的任何故障，并定期进行备份和故障切换，这样至多能够将数据损失的水平降到最低。你能够借助相似 Velero 的工具实现。
Velero 通过利用你应用的雷同 Kubernetes 架构，帮忙你保护集群中各种组件的定期备份，包含你的工作负载、存储等。Velero 的架构如下：
正如你所察看到的，有一个备份 controller，它定期对对象进行备份，依据你设置的打算将它们推送到特定的目的地，其频率是基于你设置的打算。这能够用于故障转移和迁徙，因为简直所有的对象都有备份。
存 储
有许多不同的存储程序和文件系统可用，这在云提供程序之间可能存在很大的不同。这就须要像容器存储接口（CSI）这样的规范，该规范能够帮忙大部分 volume 的外置插件，从而使其易于保护和倒退而不会成为外围瓶颈。
下图是 CSI 架构，通常能够反对各种 volume 插件：
起源：https://kubernetes.io/blog/20…
分布式存储带来的集群、扩大等各种问题怎么办？这时 Ceph 这样的文件系统曾经证实了本人的能力，不过思考到 Ceph 并不是以 Kubernetes 为核心构建的，部署和治理起来存在一些难度，此时能够思考 Rook 这样的我的项目。
尽管 Rook 没有和 Ceph 耦合，也反对其余文件系统，比方 EdgeFS、NFS 等，但 Rook 与 Ceph CSI 就像是天作之合。Rook 与 Ceph 的架构如下：
起源：https://rook.io/docs/rook/v1….
如你所见，Rook 承当了 Kubernetes 集群中的 Ceph 装置、配置和治理的性能。依据用户的爱好，主动调配上面的存储。这所有的产生，都不会让利用裸露在任何简单的状况下。
镜像仓库
镜像仓库为你提供了一个用户界面，你能够在这里治理各种用户账户、推送 / 拉取镜像、治理配额、通过 webhook 取得事件告诉、进行破绽扫描、签订推送的镜像，还能够解决镜像或在多个镜像仓库中复制镜像等操作。
如果你应用的是云提供商，他们很有可能曾经提供了镜像仓库作为一项服务（例如 GCR、ECR、ACR 等），这就打消了很多复杂性。如果你的云提供商没有提供，你也能够抉择第三方的镜像仓库，比方 Docker Hub、Quay 等。
但如果你想托管本人的镜像仓库呢？
如果你想在企业外部部署镜像仓库，想对其自身有更多的控制权，或者想升高破绽扫描等操作的相干老本，那么可能须要进行托管。
如果是这种状况，那么抉择像 Harbor 这样的公有镜像仓库会对你有所帮忙。Harbor 架构如下：
起源：https://goharbor.io/docs/1.10…
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。并且你能够依据你的用例，只应用整个堆栈中你须要的工具。
