溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
這篇文章給大家介紹如何實現靈活的K8S基礎架構，內容非常詳細，感興趣的小伙伴們可以參考借鑒，希望對大家能有所幫助。
Kubernetes是當前最為流行的開源容器編排平臺，成為眾多企業構建基礎架構的首選。在本文中，我們將探討針對你的用例構建基礎設施的最佳方式，以及你可能要根據各種限制條件做出的各種決定。
你的架構應該在很大程度上圍繞你的用例來設計，因此在設計過程中你需要非常仔細以確保該基礎架構能夠支撐你的用例，在必要的時候也可以尋求外部專業團隊的幫助。在架構設計的開始保證方向正確十分重要，但是這并不意味著不會發生錯誤，而且隨著每天都有新的技術或研究橫空出世，你可以看到變革已經成為常態，并且你的架構設計思維有可能過時。
這就是為什么我強烈建議你采用Architect for Chang的原則，讓你的架構成為一個模塊化的架構以便在未來有需要的時候你可以靈活地在內部進行改變。
讓我們看看在考慮client-server模型的情況下如何實現系統架構的目標。
在任何典型的基礎架構中（無論是否是云原生架構），一個消息請求必須先由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等。 
如果有一個請求不能被你的CDN服務，這個請求下一步會傳送到你的負載均衡器上。而這些可以是區域性的IP，也可以是全局性的Anycast IP。在某些情況下，你也可以使用負載均衡器來管理內部流量。
除了路由和代理流量到合適的后端服務，負載均衡還能夠承擔SSL終止、與CDN集成，甚至管理網絡流量的某些方面等職責。
雖然存在硬件負載均衡器，但軟件負載均衡器提供了強大的靈活性、減少了成本開支以及彈性伸縮性。
與CDN類似，你的云提供程序應該也能夠為你提供一個負載均衡器（如GCP的GLB、AWS的ELB、Azure的ALB等），但更有趣的是你可以直接從Kubernetes中調配這些負載均衡器。例如，在GKE中創建一個Ingress也會在后端為你創建一個GLB來接收流量，其他功能如CDN、SSL重定向等也可以通過配置你的ingress來設置，訪問以下鏈接查看詳情：
https://cloud.google.com/kubernetes-engine/docs/how-to/ingress-features
雖然一開始總是從小開始，但是負載均衡器可以讓你逐步擴展至具有以下規模的架構： 
下一件需要關注的事情是網絡。如果你想要提高安全性，你可能需要一個私有集群。在那里，你可以調節入站和出站流量，在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-google-modules/cloud-foundation-fabric），它可以幫助用戶在GCP中設置所有這些不同的網絡模型，包括通過VPN的hub和spoke、用于內部的DNS和Google Private Access、支持GKE的共享VPC等等，所有這些都使用Terraform。 而云計算中網絡的有趣之處在于，它不局限于你所在地區的云服務商，而是可以根據需要跨越多個地區的多個服務商。這就是Kubefed或Crossplane這樣的項目可以提供幫助的地方。
如果你想探索更多關于設置VPC、子網和整體網絡時的一些最佳實踐，我建議你訪問下方網頁，同樣的概念也適用于你加入的任何云提供商：
https://cloud.google.com/solutions/best-practices-vpc-design
如果你使用的是GKE、EKS、AKS這樣的托管集群，Kubernetes是自動管理的，從而降低了用戶操作的復雜程度。
如果你自己管理Kubernetes，你需要處理很多事情，比如，備份和加密etcd存儲，在集群中的各個節點之間建立網絡，定期為你的節點打上最新版本的操作系統補丁，管理集群升級以與上游的Kubernetes版本保持一致。基于此，只有當你擁有一個專門的團隊來維護這些事情的時候，才建議這樣做。
當你維護一個復雜的基礎設施時，擁有合適的可觀察性堆棧是非常重要的，這樣你就可以在用戶注意到錯誤之前就檢測到錯誤以及預測可能的變化，進而識別異常，并有余力深入鉆研問題到底在哪里。
現在，這就需要你有代理，將指標暴露為特定的工具或應用來收集分析（可以遵循pull或push機制）。而如果你使用的是帶有sidecars的服務網格，它們往往會自帶指標，而不需要自定義配置。
在任意場景下，都可以使用Prometheus這樣的工具作為時序數據庫，為你收集所有的指標，以及借助類似于OpenTelemetry的工具，使用內置的exporter從應用程序和各種工具中公開指標。借助Alertmanager之類的工具可以向多個渠道發送通知和告警， Grafana將提供可視化儀表板，給用戶提供整個基礎設施的完整可見性。
綜上，這就是Prometheus的可觀察性的解決方案： 
來源：https://prometheus.io/docs/introduction/overview/
擁有這樣復雜的系統，還需要使用日志聚合系統，這樣所有的日志就可以流到一個地方，便于調試。大部分企業傾向于使用ELK或EFK堆棧，Logstash或FluentD根據你的限制條件為你做日志聚合和過濾。但日志領域也有新的玩家，比如Loki和Promtail。
下圖說明了類似FluentD的日志聚合系統如何簡化你的架構： 
來源：https://www.fluentd.org/architecture
但是，如果要追蹤跨越多個微服務和工具的請求呢？這是分布式跟蹤開始發揮作用的地方，特別是考慮到微服務的復雜性。像Zipkin和Jaeger這樣的工具一直是這個領域的先驅，最近進入這個領域的新興工具是Tempo。
雖然日志聚合會給出各種來源的信息，但它不一定能給出請求的上下文，這才是做跟蹤真正有幫助的地方。但是請記住，在你的堆棧中添加跟蹤會給你的請求增加很大的開銷，因為上下文必須和請求一起在服務之間傳播。
下圖是一個典型的分布式跟蹤架構： 
來源：https://www.jaegertracing.io/docs/1.21/architecture/
但是，網站的可靠性并不僅僅止于監控、可視化和告警。你必須準備好處理系統任何部分的任何故障，并定期進行備份和故障切換，這樣至少可以將數據損失的程度降到最低。你可以借助類似Velero的工具實現。
Velero通過利用你使用的相同Kubernetes架構，幫助你維護集群中各種組件的定期備份，包括你的工作負載、存儲等。Velero的架構如下： 
正如你所觀察到的，有一個備份controller，它定期對對象進行備份，根據你設置的計劃將它們推送到特定的目的地，其頻率是基于你設置的計劃。這可以用于故障轉移和遷移，因為幾乎所有的對象都有備份。
有許多不同的存儲程序和文件系統可用，這在云提供程序之間可能存在很大的不同。這就需要像容器存儲接口（CSI）這樣的標準，該標準可以幫助大部分volume的外置插件，從而使其易于維護和發展而不會成為核心瓶頸。
下圖是CSI架構，通常可以支持各種volume插件： 
來源：https://kubernetes.io/blog/2018/08/02/dynamically-expand-volume-with-csi-and-kubernetes/
分布式存儲帶來的集群、擴展等各種問題怎么辦？這時Ceph這樣的文件系統已經證明了自己的能力，不過考慮到Ceph并不是以Kubernetes為中心構建的，部署和管理起來存在一些難度，此時可以考慮Rook這樣的項目。
雖然Rook沒有和Ceph耦合，也支持其他文件系統，比如EdgeFS、NFS等，但Rook與Ceph CSI就像是天作之合。Rook與Ceph的架構如下： 
來源：https://rook.io/docs/rook/v1.5/ceph-storage.html
如你所見，Rook承擔了Kubernetes集群中的Ceph安裝、配置和管理的功能。根據用戶的喜好，自動分配下面的存儲。這一切的發生，都不會讓應用暴露在任何復雜的情況下。
鏡像倉庫為你提供了一個用戶界面，你可以在這里管理各種用戶賬戶、推送/拉取鏡像、管理配額、通過webhook獲得事件通知、進行漏洞掃描、簽署推送的鏡像，還可以處理鏡像或在多個鏡像倉庫中復制鏡像等操作。
如果你使用的是云提供商，他們很有可能已經提供了鏡像倉庫作為一項服務（例如GCR、ECR、ACR等），這就消除了很多復雜性。如果你的云提供商沒有提供，你也可以選擇第三方的鏡像倉庫，比如Docker Hub、Quay等。
但如果你想托管自己的鏡像倉庫呢？
如果你想在企業內部部署鏡像倉庫，想對其本身有更多的控制權，或者想降低漏洞掃描等操作的相關成本，那么可能需要進行托管。
如果是這種情況，那么選擇像Harbor這樣的私有鏡像倉庫會對你有所幫助。Harbor架構如下： 
來源：https://goharbor.io/docs/1.10/install-config/harbor-ha-helm/
Harbor是一個符合OCI的鏡像倉庫，由各種開源組件組成，包括Docker鏡像倉庫V2、Harbor UI、Clair和Notary。
Kubernetes可以在任何規模下托管所有的工作負載，但這也需要一個標準的方式來部署應用程序，并采用精簡的CI/CD工作流程。下圖為典型的CI/CD流水線：
一些第三方服務如Travis CI、Circle CI、Gitlab CI或Github Actions都包含了自己的CI運行器。你只需定義你要構建的流水線中的步驟。這通常包括：構建鏡像，掃描鏡像以查找可能的漏洞，運行測試并將其推送到鏡像倉庫，在某些情況下還需要提供一個預覽環境以進行審批。
現在，雖然如果你管理自己的CI運行器，步驟通常保持不變，但你需要將它們配置為在集群內部或外部設置，并具有適當的權限，以便將資產推送到鏡像倉庫。
我們已經介紹了基于Kubernetes的云原生基礎設施的架構。正如我們上面所看到的，各種工具解決了基礎設施的不同問題。它們就像樂高積木一樣，每一個都專注于當前的一個特定問題，為你抽象掉了很多復雜的東西。
這使得用戶可以以漸進的方式逐漸上手Kubernetes。并且你可以根據你的用例，只使用整個堆棧中你需要的工具。
關于如何實現靈活的K8S基礎架構就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
