本文永久鏈接: https://www.xtplayer.cn/kubernetes/k8s-infrastructure/
Kubernetes 是當(dāng)前最為流行的開(kāi)源容器編排平臺(tái)，成為眾多企業(yè)構(gòu)建基礎(chǔ)架構(gòu)的首選。在本文中，我們將探討針對(duì)你的用例構(gòu)建基礎(chǔ)設(shè)施的最佳方式，以及你可能要根據(jù)各種限制條件做出的各種決定。
架構(gòu)設(shè)計(jì)
你的架構(gòu)應(yīng)該在很大程度上圍繞你的用例來(lái)設(shè)計(jì)，因此在設(shè)計(jì)過(guò)程中你需要非常仔細(xì)以確保該基礎(chǔ)架構(gòu)能夠支撐你的用例，在必要的時(shí)候也可以尋求外部專(zhuān)業(yè)團(tuán)隊(duì)的幫助。在架構(gòu)設(shè)計(jì)的開(kāi)始保證方向正確十分重要，但是這并不意味著不會(huì)發(fā)生錯(cuò)誤，而且隨著每天都有新的技術(shù)或研究橫空出世，你可以看到變革已經(jīng)成為常態(tài)，并且你的架構(gòu)設(shè)計(jì)思維有可能過(guò)時(shí)。
這就是為什么我強(qiáng)烈建議你采用 Architect for Chang 的原則，讓你的架構(gòu)成為一個(gè)模塊化的架構(gòu)以便在未來(lái)有需要的時(shí)候你可以靈活地在內(nèi)部進(jìn)行改變。
讓我們看看再考慮 client-server 模型的情況下如何實(shí)現(xiàn)系統(tǒng)架構(gòu)的目標(biāo)。
切入點(diǎn)：DNS
在任何典型的基礎(chǔ)架構(gòu)中（無(wú)論是否是云原生架構(gòu)），一個(gè)消息請(qǐng)求必須先由 DNS 服務(wù)器解析，并返回服務(wù)器的 IP 地址。設(shè)置你的 DNS 應(yīng)該基于你所需要的可用性。如果你需要更高的可用性，你可能想要將你的服務(wù)器分布到多個(gè)區(qū)域或者云提供程序上，具體的實(shí)現(xiàn)要基于你想要達(dá)到的可用性等級(jí)。
內(nèi)容分發(fā)網(wǎng)絡(luò)（CDN）
在某些情況下，你可能需要盡可能地以最小的延遲為用戶(hù)提供服務(wù)，同時(shí)減少服務(wù)器的負(fù)載。這就是內(nèi)容分發(fā)網(wǎng)絡(luò)（CDN）發(fā)揮重要作用的地方。
Client 是否經(jīng)常從服務(wù)器上請(qǐng)求一組靜態(tài)資產(chǎn)？你是否希望提高向用戶(hù)交付內(nèi)容的速度，同時(shí)減少服務(wù)器的負(fù)載？在這種情況下，采用邊緣的 CDN 為一組靜態(tài)資產(chǎn)提供服務(wù)，實(shí)際上可能有助于降低用戶(hù)的延遲和服務(wù)器的負(fù)載。
你所有的內(nèi)容都是動(dòng)態(tài)的嗎？你是否可以在一定程度上為用戶(hù)提供延遲的內(nèi)容，以減少?gòu)?fù)雜性？或者你的應(yīng)用程序接收很低的流量嗎？在這種情況下，使用 CDN 可能沒(méi)有太大的意義，你可以將所有的流量直接發(fā)送到全局負(fù)載均衡器。但要注意的是，擁有 CDN 也確實(shí)有分配流量的優(yōu)勢(shì)，這在你的服務(wù)器受到 DDoS 攻擊時(shí)是很有幫助的。
CDN 提供程序包括 Cloudfare CDN、Fastly、Akamai CDN、Stackpath，此外你的云提供商也有可能會(huì)提供 CDN 服務(wù)，比如谷歌云平臺(tái)的 Cloud CDN、AWS 的 CloudFront、微軟 Azure 的 Azure CDN 等。
Load Balancer
如果有一個(gè)請(qǐng)求不能被你的 CDN 服務(wù)，這個(gè)請(qǐng)求下一步會(huì)傳送到你的負(fù)載均衡器上。而這些可以是區(qū)域性的 IP，也可以是全局性的 Anycast IP。在某些情況下，你也可以使用負(fù)載均衡器來(lái)管理內(nèi)部流量。
除了路由和代理流量到合適的后端服務(wù)，負(fù)載均衡還能夠承擔(dān) SSL 終止、與 CDN 集成，甚至管理網(wǎng)絡(luò)流量的某些方面等職責(zé)。
雖然存在硬件負(fù)載均衡器，但軟件負(fù)載均衡器提供了強(qiáng)大的靈活性、減少了成本開(kāi)支以及彈性伸縮性。
與 CDN 類(lèi)似，你的云提供程序應(yīng)該也能夠?yàn)槟闾峁┮粋€(gè)負(fù)載均衡器（如 GCP 的 GLB、AWS 的 ELB、Azure 的 ALB 等），但更有趣的是你可以直接從 Kubernetes 中調(diào)配這些負(fù)載均衡器。例如，在 GKE 中創(chuàng)建一個(gè) Ingress 也會(huì)在后端為你創(chuàng)建一個(gè) GLB 來(lái)接收流量，其他功能如 CDN、SSL 重定向等也可以通過(guò)配置你的 ingress 來(lái)設(shè)置，訪(fǎng)問(wèn)以下鏈接查看詳情：
https://cloud.google.com/kubernetes-engine/docs/how-to/ingress-features
雖然一開(kāi)始總是從小開(kāi)始，但是負(fù)載均衡器可以讓你逐步擴(kuò)展至具有以下規(guī)模的架構(gòu)：
網(wǎng)絡(luò)及安全架構(gòu)
下一件需要關(guān)注的事情是網(wǎng)絡(luò)。如果你想要提高安全性，你可能需要一個(gè)私有集群。在那里，你可以調(diào)節(jié)入站和出站流量，在 NATs 后面屏蔽 IP 地址，在多個(gè) VPC 上隔離多個(gè)子網(wǎng)的網(wǎng)絡(luò)等。
如何設(shè)置網(wǎng)絡(luò)通常取決于你所追求的靈活性程度以及如何實(shí)現(xiàn)它。設(shè)置正確的網(wǎng)絡(luò)就是要盡可能地減少攻擊面，同時(shí)還能保持正常的運(yùn)轉(zhuǎn)。
通過(guò)設(shè)置正確的網(wǎng)絡(luò)來(lái)保護(hù)你的基礎(chǔ)設(shè)施通常還涉及到使用正確規(guī)則和限制條件設(shè)置的防火墻，以便限制來(lái)自各后端服務(wù)的流量的進(jìn)出，包括入站和出站。
在很多情況下，可以通過(guò)設(shè)置堡壘主機(jī)并通過(guò)隧道進(jìn)行集群中的所有操作來(lái)保護(hù)這些私有集群，因?yàn)槟阈枰蚬簿W(wǎng)絡(luò)公開(kāi)的就是堡壘（又稱(chēng) Jump host），通常是在與集群相同的網(wǎng)絡(luò)中設(shè)置。
一些云提供商在實(shí)現(xiàn)零信任安全的方法上也提供了定制化的解決方案。例如，GCP 為其用戶(hù)提供身份意識(shí)代理（IAP），可用于代替典型的 VPN 實(shí)現(xiàn)。
所有都處理好之后，下一步是根據(jù)你的用例在集群本身內(nèi)設(shè)置網(wǎng)絡(luò)。
這牽涉到以下任務(wù)：
- 設(shè)置集群內(nèi)的服務(wù)發(fā)現(xiàn)（可由 CoreDNS 處理）
- 如果需要的話(huà)，設(shè)置一個(gè)服務(wù)網(wǎng)格（如 LinkerD、Istio、Consul 等）
- 設(shè)置 Ingress controller 和 API 網(wǎng)關(guān)（例如：Nginx、Ambassador、Kong、Gloo 等）
- 設(shè)置使用 CNI 的網(wǎng)絡(luò)插件，方便集群內(nèi)的聯(lián)網(wǎng)
- 設(shè)置網(wǎng)絡(luò)策略，調(diào)節(jié)服務(wù)間的通信，并根據(jù)需要使用各種服務(wù)類(lèi)型暴露服務(wù)
- 使用 GRPC、Thrift 或 HTTP 等協(xié)議和工具，設(shè)置不同服務(wù)之間的服務(wù)間通信
- 設(shè)置 A/B 測(cè)試，如果你使用像 Istio 或 Linkerd 這樣的服務(wù)網(wǎng)格，實(shí)現(xiàn)起來(lái)可以更容易
如果你想看一些示例實(shí)現(xiàn)，我建議你看看這個(gè) repo（https://github.com/terraform-google-modules/cloud-foundation-fabric），它可以幫助用戶(hù)在 GCP 中設(shè)置所有這些不同的網(wǎng)絡(luò)模型，包括通過(guò) VPN 的 hub 和 spoke、用于內(nèi)部的 DNS 和 Google Private Access、支持 GKE 的共享 VPC 等等，所有這些都使用 Terraform。
而云計(jì)算中網(wǎng)絡(luò)的有趣之處在于，它不局限于你所在地區(qū)的云服務(wù)商，而是可以根據(jù)需要跨越多個(gè)地區(qū)的多個(gè)服務(wù)商。這就是 Kubefed 或 Crossplane 這樣的項(xiàng)目可以提供幫助的地方。
如果你想探索更多關(guān)于設(shè)置 VPC、子網(wǎng)和整體網(wǎng)絡(luò)時(shí)的一些最佳實(shí)踐，我建議你訪(fǎng)問(wèn)下方網(wǎng)頁(yè)，同樣的概念也適用于你加入的任何云提供商：
https://cloud.google.com/solutions/best-practices-vpc-design
Kubernetes
如果你使用的是 GKE、EKS、AKS 這樣的托管集群，Kubernetes 是自動(dòng)管理的，從而降低了用戶(hù)操作的復(fù)雜程度。
如果你自己管理 Kubernetes，你需要處理很多事情，比如，備份和加密 etcd 存儲(chǔ)，在集群中的各個(gè)節(jié)點(diǎn)之間建立網(wǎng)絡(luò)，定期為你的節(jié)點(diǎn)打上最新版本的操作系統(tǒng)補(bǔ)丁，管理集群升級(jí)以與上游的 Kubernetes 版本保持一致?；诖?，只有當(dāng)你擁有一個(gè)專(zhuān)門(mén)的團(tuán)隊(duì)來(lái)維護(hù)這些事情的時(shí)候，才建議這樣做。
Site Reliability Engineering (SRE)
當(dāng)你維護(hù)一個(gè)復(fù)雜的基礎(chǔ)設(shè)施時(shí)，擁有合適的可觀(guān)察性堆棧是非常重要的，這樣你就可以在用戶(hù)注意到錯(cuò)誤之前就檢測(cè)到錯(cuò)誤以及預(yù)測(cè)可能的變化，進(jìn)而識(shí)別異常，并有余力深入鉆研問(wèn)題到底在哪里。
現(xiàn)在，這就需要你有代理，將指標(biāo)暴露為特定的工具或應(yīng)用來(lái)收集分析（可以遵循 pull 或 push 機(jī)制）。而如果你使用的是帶有 sidecars 的服務(wù)網(wǎng)格，它們往往會(huì)自帶指標(biāo)，而不需要自定義配置。
在任意場(chǎng)景下，都可以使用 Prometheus 這樣的工具作為時(shí)序數(shù)據(jù)庫(kù)，為你收集所有的指標(biāo)，以及借助類(lèi)似于 OpenTelemetry 的工具，使用內(nèi)置的 exporter 從應(yīng)用程序和各種工具中公開(kāi)指標(biāo)。借助 Alertmanager 之類(lèi)的工具可以向多個(gè)渠道發(fā)送通知和告警， Grafana 將提供可視化儀表板，給用戶(hù)提供整個(gè)基礎(chǔ)設(shè)施的完整可見(jiàn)性。
綜上，這就是 Prometheus 的可觀(guān)察性的解決方案：
來(lái)源：https://prometheus.io/docs/introduction/overview/
擁有這樣復(fù)雜的系統(tǒng)，還需要使用日志聚合系統(tǒng)，這樣所有的日志就可以流到一個(gè)地方，便于調(diào)試。大部分企業(yè)傾向于使用 ELK 或 EFK 堆棧，Logstash 或 FluentD 根據(jù)你的限制條件為你做日志聚合和過(guò)濾。但日志領(lǐng)域也有新的玩家，比如 Loki 和 Promtail。
下圖說(shuō)明了類(lèi)似 FluentD 的日志聚合系統(tǒng)如何簡(jiǎn)化你的架構(gòu)：
來(lái)源：https://www.fluentd.org/architecture
但是，如果要追蹤跨越多個(gè)微服務(wù)和工具的請(qǐng)求呢？這是分布式跟蹤開(kāi)始發(fā)揮作用的地方，特別是考慮到微服務(wù)的復(fù)雜性。像 Zipkin 和 Jaeger 這樣的工具一直是這個(gè)領(lǐng)域的先驅(qū)，最近進(jìn)入這個(gè)領(lǐng)域的新興工具是 Tempo。
雖然日志聚合會(huì)給出各種來(lái)源的信息，但它不一定能給出請(qǐng)求的上下文，這才是做跟蹤真正有幫助的地方。但是請(qǐng)記住，在你的堆棧中添加跟蹤會(huì)給你的請(qǐng)求增加很大的開(kāi)銷(xiāo)，因?yàn)樯舷挛谋仨毢驼?qǐng)求一起在服務(wù)之間傳播。
下圖是一個(gè)典型的分布式跟蹤架構(gòu)：
來(lái)源：https://www.jaegertracing.io/docs/1.21/architecture/
但是，網(wǎng)站的可靠性并不僅僅止于監(jiān)控、可視化和告警。你必須準(zhǔn)備好處理系統(tǒng)任何部分的任何故障，并定期進(jìn)行備份和故障切換，這樣至少可以將數(shù)據(jù)損失的程度降到最低。你可以借助類(lèi)似 Velero 的工具實(shí)現(xiàn)。
Velero 通過(guò)利用你使用的相同 Kubernetes 架構(gòu)，幫助你維護(hù)集群中各種組件的定期備份，包括你的工作負(fù)載、存儲(chǔ)等。Velero 的架構(gòu)如下：
正如你所觀(guān)察到的，有一個(gè)備份 controller，它定期對(duì)對(duì)象進(jìn)行備份，根據(jù)你設(shè)置的計(jì)劃將它們推送到特定的目的地，其頻率是基于你設(shè)置的計(jì)劃。這可以用于故障轉(zhuǎn)移和遷移，因?yàn)閹缀跛械膶?duì)象都有備份。
存 儲(chǔ)
有許多不同的存儲(chǔ)程序和文件系統(tǒng)可用，這在云提供程序之間可能存在很大的不同。這就需要像容器存儲(chǔ)接口（CSI）這樣的標(biāo)準(zhǔn)，該標(biāo)準(zhǔn)可以幫助大部分 volume 的外置插件，從而使其易于維護(hù)和發(fā)展而不會(huì)成為核心瓶頸。
下圖是 CSI 架構(gòu)，通?？梢灾С指鞣N volume 插件：
來(lái)源：https://kubernetes.io/blog/2018/08/02/dynamically-expand-volume-with-csi-and-kubernetes/
- 分布式存儲(chǔ)帶來(lái)的集群、擴(kuò)展等各種問(wèn)題怎么辦？
這時(shí) Ceph 這樣的文件系統(tǒng)已經(jīng)證明了自己的能力，不過(guò)考慮到 Ceph 并不是以 Kubernetes 為中心構(gòu)建的，部署和管理起來(lái)存在一些難度，此時(shí)可以考慮 Rook 這樣的項(xiàng)目。
雖然 Rook 沒(méi)有和 Ceph 耦合，也支持其他文件系統(tǒng)，比如 EdgeFS、NFS 等，但 Rook 與 Ceph CSI 就像是天作之合。Rook 與 Ceph 的架構(gòu)如下：
來(lái)源：https://rook.io/docs/rook/v1.5/ceph-storage.html
如你所見(jiàn)，Rook 承擔(dān)了 Kubernetes 集群中的 Ceph 安裝、配置和管理的功能。根據(jù)用戶(hù)的喜好，自動(dòng)分配下面的存儲(chǔ)。這一切的發(fā)生，都不會(huì)讓?xiě)?yīng)用暴露在任何復(fù)雜的情況下。
鏡像倉(cāng)庫(kù)
鏡像倉(cāng)庫(kù)為你提供了一個(gè)用戶(hù)界面，你可以在這里管理各種用戶(hù)賬戶(hù)、推送/拉取鏡像、管理配額、通過(guò) webhook 獲得事件通知、進(jìn)行漏洞掃描、簽署推送的鏡像，還可以處理鏡像或在多個(gè)鏡像倉(cāng)庫(kù)中復(fù)制鏡像等操作。
如果你使用的是云提供商，他們很有可能已經(jīng)提供了鏡像倉(cāng)庫(kù)作為一項(xiàng)服務(wù)（例如 GCR、ECR、ACR 等），這就消除了很多復(fù)雜性。如果你的云提供商沒(méi)有提供，你也可以選擇第三方的鏡像倉(cāng)庫(kù)，比如 Docker Hub、Quay 等。
- 但如果你想托管自己的鏡像倉(cāng)庫(kù)呢？
如果你想在企業(yè)內(nèi)部部署鏡像倉(cāng)庫(kù)，想對(duì)其本身有更多的控制權(quán)，或者想降低漏洞掃描等操作的相關(guān)成本，那么可能需要進(jìn)行托管。
如果是這種情況，那么選擇像 Harbor 這樣的私有鏡像倉(cāng)庫(kù)會(huì)對(duì)你有所幫助。
Harbor 架構(gòu)如下：
來(lái)源：https://goharbor.io/docs/1.10/install-config/harbor-ha-helm/
Harbor 是一個(gè)符合 OCI 的鏡像倉(cāng)庫(kù)，由各種開(kāi)源組件組成，包括 Docker 鏡像倉(cāng)庫(kù) V2、Harbor UI、Clair 和 Notary。
CI/CD 架構(gòu)
Kubernetes 可以在任何規(guī)模下托管所有的工作負(fù)載，但這也需要一個(gè)標(biāo)準(zhǔn)的方式來(lái)部署應(yīng)用程序，并采用精簡(jiǎn)的 CI/CD 工作流程。下圖為典型的 CI/CD 流水線(xiàn)：
一些第三方服務(wù)如 Travis CI、Circle CI、Gitlab CI 或 Github Actions 都包含了自己的 CI 運(yùn)行器。你只需定義你要構(gòu)建的流水線(xiàn)中的步驟。這通常包括：構(gòu)建鏡像，掃描鏡像以查找可能的漏洞，運(yùn)行測(cè)試并將其推送到鏡像倉(cāng)庫(kù)，在某些情況下還需要提供一個(gè)預(yù)覽環(huán)境以進(jìn)行審批。
現(xiàn)在，雖然如果你管理自己的 CI 運(yùn)行器，步驟通常保持不變，但你需要將它們配置為在集群內(nèi)部或外部設(shè)置，并具有適當(dāng)?shù)臋?quán)限，以便將資產(chǎn)推送到鏡像倉(cāng)庫(kù)。
總 結(jié)
我們已經(jīng)介紹了基于 Kubernetes 的云原生基礎(chǔ)設(shè)施的架構(gòu)。正如我們上面所看到的，各種工具解決了基礎(chǔ)設(shè)施的不同問(wèn)題。它們就像樂(lè)高積木一樣，每一個(gè)都專(zhuān)注于當(dāng)前的一個(gè)特定問(wèn)題，為你抽象掉了很多復(fù)雜的東西。
這使得用戶(hù)可以以漸進(jìn)的方式逐漸上手 Kubernetes。并且你可以根據(jù)你的用例，只使用整個(gè)堆棧中你需要的工具。
