溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
怎樣實現靈活的 K8S 基礎架構，相信很多沒有經驗的人對此束手無策，為此本文總結了問題出現的原因和解決方法，通過這篇文章希望你能解決這個問題。
Kubernetes 是當前最為流行的開源容器編排平臺，成為眾多企業構建基礎架構的首選。在本文中，我們將探討針對你的用例構建基礎設施的最佳方式，以及你可能要根據各種限制條件做出的各種決定。
你的架構應該在很大程度上圍繞你的用例來設計，因此在設計過程中你需要非常仔細以確保該基礎架構能夠支撐你的用例，在必要的時候也可以尋求外部專業團隊的幫助。在架構設計的開始保證方向正確十分重要，但是這并不意味著不會發生錯誤，而且隨著每天都有新的技術或研究橫空出世，你可以看到變革已經成為常態，并且你的架構設計思維有可能過時。
這就是為什么我強烈建議你采用 Architect for Chang 的原則，讓你的架構成為一個模塊化的架構以便在未來有需要的時候你可以靈活地在內部進行改變。
讓我們看看在考慮 client-server 模型的情況下如何實現系統架構的目標。
在任何典型的基礎架構中（無論是否是云原生架構），一個消息請求必須先由 DNS 服務器解析，并返回服務器的 IP 地址。設置你的 DNS 應該基于你所需要的可用性。如果你需要更高的可用性，你可能想要將你的服務器分布到多個區域或者云提供程序上，具體的實現要基于你想要達到的可用性等級。
在某些情況下，你可能需要盡可能地以最小的延遲為用戶提供服務，同時減少服務器的負載。這就是內容分發網絡（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進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
