有誰知道在 Kubernetes 集群上安裝 CloudSQL-Proxy（它允許我們安全地連接到 CloudSQL）作為服務而不是使其成為應用程式容器的邊車的利弊？
我知道它主要用作邊車。我已經將它用作兩者（在非生產環境中），但我不明白為什么邊車比服務更可取。有人可以啟發我嗎？
uj5u.com熱心網友回復：
Sidecar 模式是首選，因為它是最簡單和更安全的選擇。流向 Cloud SQL Auth 代理的流量未加密或經過身份驗證，并且依賴于用戶來限制對代理的訪問（通常是運行本地主機）。
當您運行 Cloud SQL 代理時，您實際上是在說“我是用戶 X，我有權連接到資料庫”。當您將它作為服務運行時，連接到該資料庫的任何人都被授權為“用戶 X”。
您可以在作為服務在 k8s 中運行的 Cloud SQL 代理示例中看到此警告，或者觀看有關從 Kubernetes 連接到 Cloud SQL 的視頻，該視頻也解釋了原因。
uj5u.com熱心網友回復：
Cloud SQL Auth 代理是連接到 Cloud SQL 的推薦方式，即使在使用私有 IP 時也是如此。這是因為 Cloud SQL Auth 代理使用 IAM 提供強大的加密和身份驗證，這有助于確保您的資料庫安全。
當您使用 Cloud SQL Auth 代理進行連接時，Cloud SQL Auth 代理會使用 sidecar 容器模式添加到您的 pod。Cloud SQL Auth 代理容器與您的應用程式位于同一 pod 中，這使應用程式能夠使用 localhost 連接到 Cloud SQL Auth 代理，從而提高安全性和性能。
由于 sidecar 是與應用程式容器在同一個 Pod 上運行的容器，因為它與主容器共享相同的卷和網路，它可以“幫助”或增強應用程式的運行方式。在 Kubernetes 中，Pod是一組具有共享存盤和網路的一個或多個容器。Sidecar 是 Pod 中的實用程式容器，它與主應用程式容器松散耦合。
Sidecar Pros：隨著 Pod 數量的增加，可無限擴展。可以自動注入。已被 serviceMeshes 使用。
Sidecar 缺點：有點難以采用，因為開發人員不能只部署他們的應用程式，而是在部署中部署整個堆疊。它消耗更多的資源并且更難保護，因為每個 Pod 都必須部署日志聚合器來將日志推送到資料庫或佇列中。
有關詳細資訊，請參閱檔案。
轉載請註明出處，本文鏈接：https://www.uj5u.com/net/445049.html