共計(jì) 5529 個(gè)字符，預(yù)計(jì)需要花費(fèi) 14 分鐘才能閱讀完成。

這篇文章給大家介紹如何實(shí)現(xiàn)靈活的 K8S 基礎(chǔ)架構(gòu)，內(nèi)容非常詳細(xì)，感興趣的小伙伴們可以參考借鑒，希望對(duì)大家能有所幫助。

Kubernetes 是當(dāng)前最為流行的開源容器編排平臺(tái)，成為眾多企業(yè)構(gòu)建基礎(chǔ)架構(gòu)的首選。在本文中，我們將探討針對(duì)你的用例構(gòu)建基礎(chǔ)設(shè)施的最佳方式，以及你可能要根據(jù)各種限制條件做出的各種決定。

架構(gòu)設(shè)計(jì)

你的架構(gòu)應(yīng)該在很大程度上圍繞你的用例來設(shè)計(jì)，因此在設(shè)計(jì)過程中你需要非常仔細(xì)以確保該基礎(chǔ)架構(gòu)能夠支撐你的用例，在必要的時(shí)候也可以尋求外部專業(yè)團(tuán)隊(duì)的幫助。在架構(gòu)設(shè)計(jì)的開始保證方向正確十分重要，但是這并不意味著不會(huì)發(fā)生錯(cuò)誤，而且隨著每天都有新的技術(shù)或研究橫空出世，你可以看到變革已經(jīng)成為常態(tài)，并且你的架構(gòu)設(shè)計(jì)思維有可能過時(shí)。

這就是為什么我強(qiáng)烈建議你采用 Architect for Chang 的原則，讓你的架構(gòu)成為一個(gè)模塊化的架構(gòu)以便在未來有需要的時(shí)候你可以靈活地在內(nèi)部進(jìn)行改變。

讓我們看看在考慮 client-server 模型的情況下如何實(shí)現(xiàn)系統(tǒng)架構(gòu)的目標(biāo)。

切入點(diǎn)：DNS

在任何典型的基礎(chǔ)架構(gòu)中（無論是否是云原生架構(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）

在某些情況下，你可能需要盡可能地以最小的延遲為用戶提供服務(wù)，同時(shí)減少服務(wù)器的負(fù)載。這就是內(nèi)容分發(fā)網(wǎng)絡(luò)（CDN）發(fā)揮重要作用的地方。Client 是否經(jīng)常從服務(wù)器上請(qǐng)求一組靜態(tài)資產(chǎn)？你是否希望提高向用戶交付內(nèi)容的速度，同時(shí)減少服務(wù)器的負(fù)載？在這種情況下，采用邊緣的 CDN 為一組靜態(tài)資產(chǎn)提供服務(wù)，實(shí)際上可能有助于降低用戶的延遲和服務(wù)器的負(fù)載。

你所有的內(nèi)容都是動(dòng)態(tài)的嗎？你是否可以在一定程度上為用戶提供延遲的內(nèi)容，以減少?gòu)?fù)雜性？或者你的應(yīng)用程序接收很低的流量嗎？在這種情況下，使用 CDN 可能沒有太大的意義，你可以將所有的流量直接發(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ù)載均衡器來管理內(nèi)部流量。

除了路由和代理流量到合適的后端服務(wù)，負(fù)載均衡還能夠承擔(dān) SSL 終止、與 CDN 集成，甚至管理網(wǎng)絡(luò)流量的某些方面等職責(zé)。

雖然存在硬件負(fù)載均衡器，但軟件負(fù)載均衡器提供了強(qiáng)大的靈活性、減少了成本開支以及彈性伸縮性。

與 CDN 類似，你的云提供程序應(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 來接收流量，其他功能如 CDN、SSL 重定向等也可以通過配置你的 ingress 來設(shè)置，訪問以下鏈接查看詳情：

https://cloud.google.com/kubernetes-engine/docs/how-to/ingress-features

雖然一開始總是從小開始，但是負(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)。

通過設(shè)置正確的網(wǎng)絡(luò)來保護(hù)你的基礎(chǔ)設(shè)施通常還涉及到使用正確規(guī)則和限制條件設(shè)置的防火墻，以便限制來自各后端服務(wù)的流量的進(jìn)出，包括入站和出站。

在很多情況下，可以通過設(shè)置堡壘主機(jī)并通過隧道進(jìn)行集群中的所有操作來保護(hù)這些私有集群，因?yàn)槟阈枰蚬簿W(wǎng)絡(luò)公開的就是堡壘（又稱 Jump host），通常是在與集群相同的網(wǎng)絡(luò)中設(shè)置。

一些云提供商在實(shí)現(xiàn)零信任安全的方法上也提供了定制化的解決方案。例如，GCP 為其用戶提供身份意識(shí)代理（IAP），可用于代替典型的 VPN 實(shí)現(xiàn)。

所有都處理好之后，下一步是根據(jù)你的用例在集群本身內(nèi)設(shè)置網(wǎng)絡(luò)。這牽涉到以下任務(wù)：

設(shè)置集群內(nèi)的服務(wù)發(fā)現(xiàn)（可由 CoreDNS 處理）

如果需要的話，設(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ù)類型暴露服務(wù)

使用 GRPC、Thrift 或 HTTP 等協(xié)議和工具，設(shè)置不同服務(wù)之間的服務(wù)間通信

設(shè)置 A / B 測(cè)試，如果你使用像 Istio 或 Linkerd 這樣的服務(wù)網(wǎng)格，實(shí)現(xiàn)起來可以更容易

如果你想看一些示例實(shí)現(xiàn)，我建議你看看這個(gè) repo（https://github.com/terraform-google-modules/cloud-foundation-fabric），它可以幫助用戶在 GCP 中設(shè)置所有這些不同的網(wǎng)絡(luò)模型，包括通過 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í)踐，我建議你訪問下方網(wǎng)頁(yè)，同樣的概念也適用于你加入的任何云提供商：

https://cloud.google.com/solutions/best-practices-vpc-design

Kubernetes

如果你使用的是 GKE、EKS、AKS 這樣的托管集群，Kubernetes 是自動(dòng)管理的，從而降低了用戶操作的復(fù)雜程度。

如果你自己管理 Kubernetes，你需要處理很多事情，比如，備份和加密 etcd 存儲(chǔ)，在集群中的各個(gè)節(jié)點(diǎn)之間建立網(wǎng)絡(luò)，定期為你的節(jié)點(diǎn)打上最新版本的操作系統(tǒng)補(bǔ)丁，管理集群升級(jí)以與上游的 Kubernetes 版本保持一致?；诖?，只有當(dāng)你擁有一個(gè)專門的團(tuán)隊(duì)來維護(hù)這些事情的時(shí)候，才建議這樣做。

Site Reliability Engineering (SRE)

當(dāng)你維護(hù)一個(gè)復(fù)雜的基礎(chǔ)設(shè)施時(shí)，擁有合適的可觀察性堆棧是非常重要的，這樣你就可以在用戶注意到錯(cuò)誤之前就檢測(cè)到錯(cuò)誤以及預(yù)測(cè)可能的變化，進(jìn)而識(shí)別異常，并有余力深入鉆研問題到底在哪里。

現(xiàn)在，這就需要你有代理，將指標(biāo)暴露為特定的工具或應(yīng)用來收集分析（可以遵循 pull 或 push 機(jī)制）。而如果你使用的是帶有 sidecars 的服務(wù)網(wǎng)格，它們往往會(huì)自帶指標(biāo)，而不需要自定義配置。

在任意場(chǎng)景下，都可以使用 Prometheus 這樣的工具作為時(shí)序數(shù)據(jù)庫(kù)，為你收集所有的指標(biāo)，以及借助類似于 OpenTelemetry 的工具，使用內(nèi)置的 exporter 從應(yīng)用程序和各種工具中公開指標(biāo)。借助 Alertmanager 之類的工具可以向多個(gè)渠道發(fā)送通知和告警，Grafana 將提供可視化儀表板，給用戶提供整個(gè)基礎(chǔ)設(shè)施的完整可見性。

綜上，這就是 Prometheus 的可觀察性的解決方案： 來源：https://prometheus.io/docs/introduction/overview/

擁有這樣復(fù)雜的系統(tǒng)，還需要使用日志聚合系統(tǒng)，這樣所有的日志就可以流到一個(gè)地方，便于調(diào)試。大部分企業(yè)傾向于使用 ELK 或 EFK 堆棧，Logstash 或 FluentD 根據(jù)你的限制條件為你做日志聚合和過濾。但日志領(lǐng)域也有新的玩家，比如 Loki 和 Promtail。

下圖說明了類似 FluentD 的日志聚合系統(tǒng)如何簡(jiǎn)化你的架構(gòu)： 來源：https://www.fluentd.org/architecture

但是，如果要追蹤跨越多個(gè)微服務(wù)和工具的請(qǐng)求呢？這是分布式跟蹤開始發(fā)揮作用的地方，特別是考慮到微服務(wù)的復(fù)雜性。像 Zipkin 和 Jaeger 這樣的工具一直是這個(gè)領(lǐng)域的先驅(qū)，最近進(jìn)入這個(gè)領(lǐng)域的新興工具是 Tempo。

雖然日志聚合會(huì)給出各種來源的信息，但它不一定能給出請(qǐng)求的上下文，這才是做跟蹤真正有幫助的地方。但是請(qǐng)記住，在你的堆棧中添加跟蹤會(huì)給你的請(qǐng)求增加很大的開銷，因?yàn)樯舷挛谋仨毢驼?qǐng)求一起在服務(wù)之間傳播。

下圖是一個(gè)典型的分布式跟蹤架構(gòu)： 來源：https://www.jaegertracing.io/docs/1.21/architecture/

但是，網(wǎng)站的可靠性并不僅僅止于監(jiān)控、可視化和告警。你必須準(zhǔn)備好處理系統(tǒng)任何部分的任何故障，并定期進(jìn)行備份和故障切換，這樣至少可以將數(shù)據(jù)損失的程度降到最低。你可以借助類似 Velero 的工具實(shí)現(xiàn)。

Velero 通過利用你使用的相同 Kubernetes 架構(gòu)，幫助你維護(hù)集群中各種組件的定期備份，包括你的工作負(fù)載、存儲(chǔ)等。Velero 的架構(gòu)如下： 正如你所觀察到的，有一個(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)，通常可以支持各種 volume 插件： 來源：https://kubernetes.io/blog/2018/08/02/dynamically-expand-volume-with-csi-and-kubernetes/

分布式存儲(chǔ)帶來的集群、擴(kuò)展等各種問題怎么辦？這時(shí) Ceph 這樣的文件系統(tǒng)已經(jīng)證明了自己的能力，不過考慮到 Ceph 并不是以 Kubernetes 為中心構(gòu)建的，部署和管理起來存在一些難度，此時(shí)可以考慮 Rook 這樣的項(xiàng)目。

雖然 Rook 沒有和 Ceph 耦合，也支持其他文件系統(tǒng)，比如 EdgeFS、NFS 等，但 Rook 與 Ceph CSI 就像是天作之合。Rook 與 Ceph 的架構(gòu)如下： 來源：https://rook.io/docs/rook/v1.5/ceph-storage.html

如你所見，Rook 承擔(dān)了 Kubernetes 集群中的 Ceph 安裝、配置和管理的功能。根據(jù)用戶的喜好，自動(dòng)分配下面的存儲(chǔ)。這一切的發(fā)生，都不會(huì)讓應(yīng)用暴露在任何復(fù)雜的情況下。

鏡像倉(cāng)庫(kù)

鏡像倉(cāng)庫(kù)為你提供了一個(gè)用戶界面，你可以在這里管理各種用戶賬戶、推送 / 拉取鏡像、管理配額、通過 webhook 獲得事件通知、進(jìn)行漏洞掃描、簽署推送的鏡像，還可以處理鏡像或在多個(gè)鏡像倉(cāng)庫(kù)中復(fù)制鏡像等操作。

如果你使用的是云提供商，他們很有可能已經(jīng)提供了鏡像倉(cāng)庫(kù)作為一項(xiàng)服務(wù)（例如 GCR、ECR、ACR 等），這就消除了很多復(fù)雜性。如果你的云提供商沒有提供，你也可以選擇第三方的鏡像倉(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)如下： 來源：https://goharbor.io/docs/1.10/install-config/harbor-ha-helm/

Harbor 是一個(gè)符合 OCI 的鏡像倉(cāng)庫(kù)，由各種開源組件組成，包括 Docker 鏡像倉(cāng)庫(kù) V2、Harbor UI、Clair 和 Notary。

CI/CD 架構(gòu)

Kubernetes 可以在任何規(guī)模下托管所有的工作負(fù)載，但這也需要一個(gè)標(biāo)準(zhǔn)的方式來部署應(yīng)用程序，并采用精簡(jiǎn)的 CI/CD 工作流程。下圖為典型的 CI/CD 流水線：

一些第三方服務(wù)如 Travis CI、Circle CI、Gitlab CI 或 Github Actions 都包含了自己的 CI 運(yùn)行器。你只需定義你要構(gòu)建的流水線中的步驟。這通常包括：構(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ù)。

我們已經(jīng)介紹了基于 Kubernetes 的云原生基礎(chǔ)設(shè)施的架構(gòu)。正如我們上面所看到的，各種工具解決了基礎(chǔ)設(shè)施的不同問題。它們就像樂高積木一樣，每一個(gè)都專注于當(dāng)前的一個(gè)特定問題，為你抽象掉了很多復(fù)雜的東西。

這使得用戶可以以漸進(jìn)的方式逐漸上手 Kubernetes。并且你可以根據(jù)你的用例，只使用整個(gè)堆棧中你需要的工具。

關(guān)于如何實(shí)現(xiàn)靈活的 K8S 基礎(chǔ)架構(gòu)就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，可以學(xué)到更多知識(shí)。如果覺得文章不錯(cuò)，可以把它分享出去讓更多的人看到。