深入研究 Kubernetes 的基礎架構

在本文中，我們將探討構建基礎架構的最佳方法，並根據約束條件做出各種決策。

架構

首先，建議你的架構儘可能模塊化，以便在將來有需要時可以靈活地進行增量更改。

入口點：DNS

在任何典型的基礎架構中（無論是否爲雲原生），DNS 服務器都必須首先解析請求消息以返回服務器的 IP 地址。

設置 DNS 應該基於所需的可用性。如果你需要更高的可用性，則要根據可用性級別，將服務器分佈在多個雲提供商中。

內容分發網絡（CDN）

在某些情況下，你可能需要爲用戶提供儘可能短的延遲，並減少服務器上的負載。這是內容分發網絡（CDN）發揮主要作用的地方。

客戶端是否經常從服務器請求一組靜態資源？你是否需要提高向用戶交付內容的速度，同時減少服務器上的負載？在這種情況下，爲一組靜態資源提供服務的 CDN 有助於減少用戶的延遲和服務器上的負載。

你所有的內容都是動態的嗎？你是否需要以一定程度的延遲爲用戶提供內容以降低複雜性？還是你的應用流量很少？在這種情況下，使用 CDN 可能沒有太大意義，你可以將所有流量直接發送到 Global Load Balancer。

CDN 提供商包括 Cloudfare CDN, Fastly, Akamai CDN, Stackpath，以及雲提供商–Google 雲平臺的 Cloud CDN , 亞馬遜的 CloudFront , 微軟的 Azure CDN 等 。

負載均衡器

如果有你的 CDN 無法滿足的請求，則該請求將接下來到達你的負載均衡器。負載均衡器是具有區域性的 IP，也可以是全局性的 Anycast IP。在某些情況下，你還可以使用負載均衡器來管理內部流量。

除了將流量路由和代理到適當的後端服務之外，負載均衡器還可以負責 SSL 終止，與 CDN 集成甚至管理網絡流量的某些方面。

儘管確實存在硬件負載均衡器，但軟件負載均衡器提供了更大的靈活性，低成本和可伸縮性。與 CDN 相似，雲提供商也提供負載均衡（例如 GCP 的 GLB，AWS 的 ELB，Azure 的 ALB 等）。儘管你應該始終從小做起，但是負載均衡器將允許你逐步擴展：

網絡和安全架構

在你的體系結構中要注意的下一件重要事情是網絡本身。如果要提高安全性，則可能需要使用私有集羣。在那裏，你可以管理入站和出站流量，在 NAT 之後屏蔽 IP 地址，隔離跨 VPC 具有多個子網的網絡，等等。設置網絡的方式通常取決於你需要的靈活性程度以及實現方式。建立正確的網絡關係就是儘可能減少攻擊面，同時仍然允許常規操作。

使用網絡來保護你的基礎架構還涉及使用正確的規則和限制來設置防火牆，以便你僅允許進出各自後端服務的入站和出站流量。

在許多情況下，可以通過設置堡壘機來保護這些專用集羣，因爲你需要向公共網絡公開的只有堡壘機（通常是在與集羣相同的網絡）。一些雲提供商還提供了針對零信任安全性的定製解決方案。例如，GCP 爲用戶提供了身份識別代理（IAP），可以代替典型的 VPN。一旦處理完所有這些，聯網的下一步就是根據你的情況在集羣本身內設置聯網。

它可能涉及以下任務：

關於雲中網絡的有趣之處在於，還可以根據需要選擇跨多個地區的多個提供商，這就是 Kubefed 或 Crossplane 等項目可以提供幫助的地方。

如果你想在設置 VPC，子網和整個網絡時進一步探索一些最佳實踐，我建議你仔細閱讀本頁面，同樣的概念也適用於你所使用的任何雲提供商。

Kubernetes

如果你使用的是 GKE，EKS，AKS，AKS 等託管集羣，則 Kubernetes 會自動進行管理，從而使用戶擺脫了很多麻煩。

如果你自己管理 Kubernetes，則需要注意很多事情，例如備份和加密 etcd 存儲，在集羣中的各個節點之間建立網絡，定期爲節點打補丁，管理集羣升級。僅當你有足夠的能力進行此工作時，才建議這樣做。

站點可靠性工程（SRE）

當你維護複雜的基礎架構時，擁有正確的可觀察性非常重要，這樣你就可以提前發現錯誤，並預測可能的變化，識別異常，深入探究問題所在。

現在，這將需要你使用代理。這些代理公開應用程序的指標。如果你將服務網格與 Sidecar 一起使用，它們通常會附帶指標而無需你自己進行任何自定義開發。

在任何這種情況下，像 Prometheus 這樣的工具都可以充當時間序列數據庫來爲你收集所有指標，而像 OpenTelemetry 這樣的工具可以通過內置導出程序從應用程序和各種工具中獲取指標。Alertmanager 之類的工具可以將通知和警報發送到多個渠道，而 Grafana 將提供儀表板以在一處可視化所有內容，從而使用戶可以整體瞭解整個基礎架構。

總而言之，以下涉及 Prometheus 的可觀察性系統：

具有這樣的複雜系統還需要使用日誌聚合系統，以便將所有日誌都可以流式傳輸到單個位置，以便於調試。在這裏，人們傾向於將 ELK 或 EFK 堆棧與 Logstash 或 FluentD 一起使用，以根據你的約束爲你進行日誌聚合和過濾。在這個領域中也有新工具出現，例如 Loki 和 Promtail。

使用 FluentD 這樣的日誌聚合系統可以簡化我們的基礎架構：

但是如何跟蹤跨越多個微服務和工具的請求呢？在這裏，分佈式跟蹤也變得非常重要，特別是考慮到微服務所帶來的複雜性。Zipkin 和 Jaeger 等工具一直是該領域的先驅，最近進入該領域的是 Tempo。

雖然日誌聚合可以提供來自各種來源的信息，但不一定提供請求的上下文，這在進行跟蹤時真正有用。但是請記住，添加跟蹤會增加請求的開銷，因爲上下文必須與請求一起在服務之間傳播。

典型的分佈式跟蹤：

但是，站點的可靠性並不僅限於監視，可視化和警報。你必須準備好使用常規備份和故障轉移來處理系統任何部分中的任何故障，以便不丟失數據或將數據丟失的程度降至最低。這就是 Velero 等工具發揮主要作用的地方。

Velero 可以幫助你維護集羣中各個組件的定期備份，包括工作負載，存儲等。Velero 的架構如下所示：

如你所注意到的，有一個備份控制器定期備份對象，並根據你設置的時間表將它們推送到特定的目的地。由於幾乎所有對象都已備份，因此可以將其用於故障轉移。

存儲

有許多不同的存儲供應商和文件系統可用，而且在雲提供商之間可能有很大的不同。這就需要像容器存儲接口（CSI）這樣的標準，從而使大多數數據卷插件易於集成、維護和發展而不會成爲核心瓶頸。

CSI 支持各種存儲插件：

集羣存儲，擴展以及分佈式存儲附帶的其他各種問題，如何解決呢？

這就需要 Ceph 類的文件系統，但是考慮到 Ceph 並不是在考慮 Kubernetes 的情況下構建的，並且很難部署和管理，就需要使用 Rook 這樣的項目中也。儘管 Rook 沒有與 Ceph 耦合，並且還支持 EdgeFS，NFS 等其他文件系統，但是 Rook 與 Ceph CSI 就像是天作之合。

如你所見，Rook 負責在 Kubernetes 集羣中安裝，配置和管理 Ceph。根據用戶首選項，存儲空間自動分配。所有這一切都不會使應用程序面臨任何複雜性。

鏡像倉庫

鏡像倉庫爲你提供了一個用戶界面，你可以在其中管理各種用戶帳戶，推送 / 拉取鏡像，管理配額，通過 Webhooks 接收事件通知，進行漏洞掃描，對推送的鏡像進行簽名以及處理鏡像或鏡像複製等操作。多個鏡像倉庫。

如果你使用雲提供商，則很有可能他們已經將鏡像倉庫作爲一項服務（例如 GCR，ECR，ACR 等），這消除了很多複雜性。如果你的雲服務提供商不提供服務，那麼你也可以使用 Docker Hub，Quay 等第三方鏡像倉庫。

但是，如果你想託管自己的鏡像倉庫怎麼辦？

如果你要在本地部署鏡像倉庫，想要對鏡像倉庫本身進行更多控制，或者想減少與漏洞掃描等操作相關的成本，則可能需要使用像 Harbor 這樣的私有鏡像倉庫。

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

CI/CD 體系結構

Kubernetes 是一個很好的平臺，可以託管任何規模的各種類型的工作負載，但這也要求採用簡單便捷的持續集成 / 持續交付（CI/CD）工作流程來部署應用程序。

一些第三方服務（例如 Travis CI，Circle CI，Gitlab CI 或 Github Actions） 包括自己的 CI 運行程序。你只需定義要構建的流水線中的步驟。這通常涉及：構建鏡像，掃描鏡像以查找可能的漏洞，運行測試並將其推送到鏡像倉庫，在某些情況下還提供預覽功能。

結論

如上所述，各種工具可解決基礎架構的不同問題。它們就像樂高積木一樣，每個積木都着眼於特定的問題，爲你節省了很多複雜性。

這使用戶可以使用增量方式利用 Kubernetes，而不必一次全部使用，而僅使用整個系統中所需的工具，具體取決於你的需求。

文章來源：K8s 中文社區

翻譯：王延飛

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/--s9WV4aL75H9PKiAyJKlw

猜你喜歡