如何實現(xiàn)靈活的K8S基礎(chǔ)架構(gòu)

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

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

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

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

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

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

切入點：DNS

在任何典型的基礎(chǔ)架構(gòu)中（無論是否是云原生架構(gòu)），一個消息請求必須先由DNS服務(wù)器解析，并返回服務(wù)器的IP地址。設(shè)置你的DNS應(yīng)該基于你所需要的可用性。如果你需要更高的可用性，你可能想要將你的服務(wù)器分布到多個區(qū)域或者云提供程序上，具體的實現(xiàn)要基于你想要達(dá)到的可用性等級。

內(nèi)容分發(fā)網(wǎng)絡(luò)（CDN）

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

你所有的內(nèi)容都是動態(tài)的嗎？你是否可以在一定程度上為用戶提供延遲的內(nèi)容，以減少復(fù)雜性？或者你的應(yīng)用程序接收很低的流量嗎？在這種情況下，使用CDN可能沒有太大的意義，你可以將所有的流量直接發(fā)送到全局負(fù)載均衡器。但要注意的是，擁有CDN也確實有分配流量的優(yōu)勢，這在你的服務(wù)器受到DDOS攻擊時是很有幫助的。

CDN提供程序包括Cloudfare CDN、Fastly、Akamai CDN、Stackpath，此外你的云提供商也有可能會提供CDN服務(wù)，比如谷歌云平臺的Cloud CDN、AWS的CloudFront、微軟Azure的Azure CDN等。

Load Balancer

如果有一個請求不能被你的CDN服務(wù)，這個請求下一步會傳送到你的負(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)該也能夠為你提供一個負(fù)載均衡器（如GCP的GLB、AWS的ELB、Azure的ALB等），但更有趣的是你可以直接從Kubernetes中調(diào)配這些負(fù)載均衡器。例如，在GKE中創(chuàng)建一個Ingress也會在后端為你創(chuàng)建一個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ò)。如果你想要提高安全性，你可能需要一個私有集群。在那里，你可以調(diào)節(jié)入站和出站流量，在NATs后面屏蔽IP地址，在多個VPC上隔離多個子網(wǎng)的網(wǎng)絡(luò)等。

如何設(shè)置網(wǎng)絡(luò)通常取決于你所追求的靈活性程度以及如何實現(xiàn)它。設(shè)置正確的網(wǎng)絡(luò)就是要盡可能地減少攻擊面，同時還能保持正常的運(yùn)轉(zhuǎn)。

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

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

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

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

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

如果需要的話，設(shè)置一個服務(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測試，如果你使用像Istio或Linkerd這樣的服務(wù)網(wǎng)格，實現(xiàn)起來可以更容易

如果你想看一些示例實現(xiàn)，我建議你看看這個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。 而云計算中網(wǎng)絡(luò)的有趣之處在于，它不局限于你所在地區(qū)的云服務(wù)商，而是可以根據(jù)需要跨越多個地區(qū)的多個服務(wù)商。這就是Kubefed或Crossplane這樣的項目可以提供幫助的地方。

如果你想探索更多關(guān)于設(shè)置VPC、子網(wǎng)和整體網(wǎng)絡(luò)時的一些最佳實踐，我建議你訪問下方網(wǎng)頁，同樣的概念也適用于你加入的任何云提供商：

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

Kubernetes

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

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

Site Reliability Engineering (SRE)

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

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

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

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

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

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

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

雖然日志聚合會給出各種來源的信息，但它不一定能給出請求的上下文，這才是做跟蹤真正有幫助的地方。但是請記住，在你的堆棧中添加跟蹤會給你的請求增加很大的開銷，因為上下文必須和請求一起在服務(wù)之間傳播。

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

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

Velero通過利用你使用的相同Kubernetes架構(gòu)，幫助你維護(hù)集群中各種組件的定期備份，包括你的工作負(fù)載、存儲等。Velero的架構(gòu)如下： 正如你所觀察到的，有一個備份controller，它定期對對象進(jìn)行備份，根據(jù)你設(shè)置的計劃將它們推送到特定的目的地，其頻率是基于你設(shè)置的計劃。這可以用于故障轉(zhuǎn)移和遷移，因為幾乎所有的對象都有備份。

存 儲

有許多不同的存儲程序和文件系統(tǒng)可用，這在云提供程序之間可能存在很大的不同。這就需要像容器存儲接口（CSI）這樣的標(biāo)準(zhǔn)，該標(biāo)準(zhǔn)可以幫助大部分volume的外置插件，從而使其易于維護(hù)和發(fā)展而不會成為核心瓶頸。

下圖是CSI架構(gòu)，通?？梢灾С指鞣Nvolume插件： 來源：https://kubernetes.io/blog/2018/08/02/dynamically-expand-volume-with-csi-and-kubernetes/

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

雖然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ù)用戶的喜好，自動分配下面的存儲。這一切的發(fā)生，都不會讓應(yīng)用暴露在任何復(fù)雜的情況下。

鏡像倉庫

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

如果你使用的是云提供商，他們很有可能已經(jīng)提供了鏡像倉庫作為一項服務(wù)（例如GCR、ECR、ACR等），這就消除了很多復(fù)雜性。如果你的云提供商沒有提供，你也可以選擇第三方的鏡像倉庫，比如Docker Hub、Quay等。

但如果你想托管自己的鏡像倉庫呢？

如果你想在企業(yè)內(nèi)部部署鏡像倉庫，想對其本身有更多的控制權(quán)，或者想降低漏洞掃描等操作的相關(guān)成本，那么可能需要進(jìn)行托管。

如果是這種情況，那么選擇像Harbor這樣的私有鏡像倉庫會對你有所幫助。Harbor架構(gòu)如下： 來源：https://goharbor.io/docs/1.10/install-config/harbor-ha-helm/

Harbor是一個符合OCI的鏡像倉庫，由各種開源組件組成，包括Docker鏡像倉庫V2、Harbor UI、Clair和Notary。

CI/CD架構(gòu)

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

一些第三方服務(wù)如Travis CI、Circle CI、Gitlab CI或Github Actions都包含了自己的CI運(yùn)行器。你只需定義你要構(gòu)建的流水線中的步驟。這通常包括：構(gòu)建鏡像，掃描鏡像以查找可能的漏洞，運(yùn)行測試并將其推送到鏡像倉庫，在某些情況下還需要提供一個預(yù)覽環(huán)境以進(jìn)行審批。

現(xiàn)在，雖然如果你管理自己的CI運(yùn)行器，步驟通常保持不變，但你需要將它們配置為在集群內(nèi)部或外部設(shè)置，并具有適當(dāng)?shù)臋?quán)限，以便將資產(chǎn)推送到鏡像倉庫。

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

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

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