去年年底，俄羅斯 PostgreSQL 社群又舉辦了一場直播 其間，其聯合創始人 Nikolai Samokhvalov 與 Flant 技術總監 Dmitry Stolyarov 討論了 Kubernetes 背景下的 DBMS。
我們正在發布本次討論主要部分的記錄，並在 完整影片已發布：
資料庫和 Kubernetes
NS：我們今天不討論 VACUUM 和 CHECKPOINT。 我們想談談 Kubernetes。 我知道你有多年的經驗。 我觀看了您的視頻，甚至重新觀看了其中一些視頻...讓我們開門見山：為什麼在 K8s 中使用 Postgres 或 MySQL？
ДС: 這個問題沒有也不可能有明確的答案。 但總的來說，這是簡單和方便......潛力。 每個人都想要託管服務。
NS: 怎樣 ，只在家？
ДС：是的：像 RDS 一樣，可以在任何地方。
NS: 「任何地方」都是一個很好的觀點。 在大公司中，一切都位於不同的地方。 那麼，如果是一家大公司，為什麼不採用現成的解決方案呢？ 例如，Nutanix 有自己的開發，其他公司（VMware...）也有相同的「RDS，僅限國內」。
ДС：但我們正在討論一個單獨的實現，它僅在某些條件下起作用。 如果我們談論 Kubernetes，那麼就有各種各樣的基礎設施（可以在 K8s 中）。 本質上，這是雲端 API 的標準...
NS: 還是免費的！
ДС: 沒那麼重要。 對於不是很大的市場部分來說，自由度很重要。 還有一些重要的事情......你可能還記得這份報告““？
NS： 是的。
ДС: 我意識到收到的訊息非常含糊。 有些人認為我是說：“夥計們，讓我們將所有資料庫放入 Kubernetes 中！”，而其他人則認為這些都是糟糕的自行車。 但我想說的是完全不同的話：「看看正在發生什麼，有什麼問題以及如何解決它們。 我們現在應該使用 Kubernetes 資料庫嗎？ 生產？ 好吧，只要你喜歡…做某些事。 但對於開發者來說，我可以說我推薦它。 對於開發人員來說，創建/刪除環境的活力非常重要。”
NS：您所說的開發環境是指所有非生產環境嗎？ 分期、品質檢查...
ДС：如果我們談論的是性能支架，那麼可能不會，因為那裡的要求是特定的。 如果我們談論的是需要非常大的資料庫來進行暫存的特殊情況，那麼可能不會......如果這是一個靜態的、長期存在的環境，那麼將資料庫位於 K8s 中有什麼好處？
NS： 沒有任何。 但是我們在哪裡可以看到靜態環境呢？ 靜態環境明天就會過時。
ДС：分期可以是靜態的。 我們有客戶...
NS: 是的，我也有一個。 如果您有 10 TB 資料庫和 200 GB 暫存，這就是一個大問題...
ДС: 我有一個非常酷的案例！ 在登台時，有一個可以進行更改的產品資料庫。 還有一個按鈕：「推出到生產環境」。 這些變更 - 增量 - 在生產中添加（似乎它們只是透過 API 同步）。 這是一個非常奇特的選擇。
NS：我見過矽谷的新創公司使用 RDS 甚至 Heroku - 這些都是 2-3 年前的故事 - 他們將轉儲下載到他們的筆記型電腦上。 因為資料庫仍然只有80 GB，而且筆記型電腦上還有空間。 然後他們為每個人購買額外的磁碟，這樣他們就有3個資料庫來進行不同的開發。 事情也是這樣發生的。 我還看到他們並不害怕將產品複製到舞台中——這很大程度上取決於公司。 但我也看到他們很害怕，而且往往沒有足夠的時間和手。 但在我們繼續這個主題之前，我想聽聽 Kubernetes。 我是否正確理解尚未有人使用產品？
ДС：我們的產品中有小型資料庫。 我們正在談論數十 GB 的容量和非關鍵服務，我們懶得為其製作副本（並且沒有這種需求）。 且前提是Kubernetes下有正常的儲存。 此資料庫在虛擬機器中運作 - 有條件地在儲存系統之上的 VMware 中。 我們把它放在 現在我們可以將其從一台機器轉移到另一台機器。
NS：這種大小的資料庫（最大 100 GB）可以在幾分鐘內在良好的磁碟和良好的網路上推出，對吧？ 每秒 1 GB 的速度不再是奇特的東西。
ДС：是的，對於線性運算來說這不是問題。
NS: 好吧，我們只需要考慮產品。 如果我們考慮將 Kubernetes 用於非生產環境，我們應該做什麼？ 我在扎蘭多看到了 ，脆脆的 ，還有一些其他選項。 並且有 - 這是我們來自西班牙的好朋友阿爾瓦羅：他們所做的本質上不僅僅是 ，以及整個分佈（），除了 Postgres 本身之外，他們還決定添加一個備份，即 Envoy 代理程式...
ДС: 使者做什麼？ 專門平衡 Postgres 流量？
NS： 是的。 也就是說，他們認為：如果你採用 Linux 發行版和內核，那麼常規 PostgreSQL 就是內核，他們希望製作一個雲端友好且在 Kubernetes 上運行的發行版。 他們將組件（備份等）放在一起並進行調試，以便它們正常工作。
ДС： 很酷！ 本質上，這是創建您自己的託管 Postgres 的軟體。
NS：Linux發行版有一個永恆的問題：如何製作驅動程式以便支援所有硬體。 他們有在 Kubernetes 中工作的想法。 我知道，在 Zalando 運營商中，我們最近看到了與 AWS 的連接，但這不再很好了。 不應該與特定的基礎設施有連結──那還有什麼意義呢？
ДС：我不知道 Zalando 到底遇到了什麼情況，但在 Kubernetes 儲存中，現在的儲存方式是不可能使用通用方法進行磁碟備份的。 最近處於標準狀態 - 最新版本 — 我們讓快照成為可能，但它是在哪裡實現的呢？ 老實說，一切都還很原始……我們正在 AWS、GCE、Azure、vSphere 之上嘗試 CSI，但是一旦你開始使用它，你就會發現它還沒有準備好。
NS：這就是為什麼我們有時必須依賴基礎設施。 我認為這仍然是一個早期階段——成長的煩惱。 問題：對於想要在 K8s 中嘗試 PgSQL 的新手，您有什麼建議？ 也許是什麼運營商？
ДС：問題是 Postgres 對我們來說是 3%。 我們在 Kubernetes 中還有一個非常大的不同軟體列表，我甚至不會列出所有內容。 例如，彈性搜尋。 運營商有很多：有些正在積極開發，有些則沒有。 我們給自己訂了要求，經營者應該具備什麼，讓我們認真看待。 在專門針對 Kubernetes 的操作符中 - 而不是在“在亞馬遜條件下做某事的操作符”中......事實上，我們相當廣泛（=幾乎所有客戶端）使用單一操作符 - （我們很快就會發表一篇關於他的文章）.
NS: 也不適合 MySQL 嗎？ 我知道 Percona...因為他們現在正在研究 MySQL、MongoDB 和 Postgres，所以他們必須創建某種通用解決方案：針對所有資料庫、針對所有雲端提供者。
ДС：我們沒有時間查看 MySQL 的運算子。 這不是我們現在的主要關注點。 MySQL 在獨立環境下運作良好。 如果您可以啟動資料庫，為什麼還要使用運算元...您可以使用 Postrges 啟動 Docker 容器，也可以以簡單的方式啟動它。
NS: 也有這個問題。 根本就沒有運營商嗎？
ДС：是的，我們 100% 的人都在沒有操作員的情況下執行 PostgreSQL。 到目前為止。 我們積極使用 Prometheus 和 Redis 的操作符。 我們計劃為 Elasticsearch 尋找一個 Operator——它是最「火」的一個，因為我們希望在 100% 的情況下將它安裝在 Kubernetes 中。 正如我們要確保 MongoDB 也始終安裝在 Kubernetes 中一樣。 這裡出現了某些願望 - 有一種感覺，在這些情況下可以做一些事情。 我們甚至沒有看過 Postgres。 當然，我們知道有不同的選擇，但實際上我們有一個獨立的選擇。
用於在 Kubernetes 中進行測試的資料庫
NS: 讓我們繼續討論測試的話題。 如何從 DevOps 的角度推出資料庫的變更。 有微服務、許多資料庫，某些地方一直在改變。 如何確保CI/CD的正常進行，讓DBMS層級一切井然有序。 你的方法是什麼？
ДС: 不可能有一個答案。 有幾種選擇。 第一個是我們想要推出的底座的大小。 您自己提到，公司對於在開發和階段擁有產品資料庫副本有不同的態度。
NS：在GDPR的條件下，我認為他們越來越小心......我可以說在歐洲他們已經開始徵收罰款。
ДС：但通常您可以編寫從生產中獲取轉儲並對其進行混淆的軟體。 取得生產資料（快照、轉儲、二進位副本...），但它是匿名的。 相反，可以有產生腳本：這些可以是固定裝置，也可以只是產生大型資料庫的腳本。 問題是：建立一個基礎鏡像需要多長時間？ 部署到所需環境需要多長時間？
我們得出一個方案：如果客戶端有固定的資料集（最小版本的資料庫），那麼我們預設使用它們。 如果我們談論審查環境，當我們建立分支時，我們部署了應用程式的一個實例 - 我們在那裡推出了一個小型資料庫。 但結果很好 ，當我們每天（晚上）從生產中獲取一次轉儲，並使用 PostgreSQL 和 MySQL 建立一個 Docker 容器，並基於此載入資料。 如果您需要將此圖像擴展資料庫 50 倍，則可以非常簡單且快速地完成。
NS: 簡單的複製？
ДС：資料直接儲存在Docker映像中。 那些。 我們有一個現成的鏡像，儘管有 100 GB。 感謝 Docker 中的層，我們可以根據需要多次快速部署此映像。 這個方法雖然笨，但是效果很好。
NS：那麼，當你測試時，它就在 Docker 內部發生了變化，對嗎？ Docker 內部的寫時複製 - 扔掉它並重新開始，一切都很好。 班級！ 您已經充分利用它了嗎？
ДС： 許久。
NS: 我們做的事情非常相似。 只是我們不使用 Docker 的寫時複製，而是使用其他一種。
ДС: 這不是通用的。 Docker 無所不在。
NS: 理論上是的。 但我們也有模組，您可以製作不同的模組並使用不同的檔案系統。 這是多麼美好的一刻。 從 Postgres 的角度來看，我們以不同的方式看待這一切。 現在我從 Docker 方面來看，發現一切都適合你。 但如果資料庫很大，例如1TB，那麼這一切都需要很長時間：晚上操作，把所有東西都塞進Docker……而如果5TB塞進Docker……或者一切都好嗎？
ДС：有什麼區別：這些是 blob，只是位元和位元組。
NS：差別在於：你是透過dump和restore來做到的嗎？
ДС: 完全沒有必要。 生成該圖像的方法可以不同。
NS：對於某些客戶，我們不是定期產生基礎映像，而是不斷更新它。 它本質上是一個副本，但它不是直接從主伺服器接收數據，而是透過存檔接收數據。 一個二進位存檔，每天都會下載 WAL，並進行備份...然後這些 WAL 會稍微延遲（實際上是 1-2 秒）到達基礎映像。 我們以任何方式從它克隆 - 現在我們預設有 ZFS。
ДС：但是對於 ZFS，您只能使用一個節點。
NS： 是的。 不過ZFS還有一個神奇的地方 ：有了它，您可以發送快照，甚至（我還沒有真正測試過這一點，但是......）您可以發送兩個之間的增量 PGDATA。 事實上，我們還有另一個工具，我們還沒有真正考慮過用於此類任務。 PostgreSQL 有 ，它的工作原理就像一個“智能”rsync，跳過很多你不必觀看的內容，因為那裡沒有任何改變。 我們可以在兩個伺服器之間進行快速同步並以相同的方式倒回。
因此，從 DBA 的角度來看，我們正在嘗試創建一種工具，使我們能夠執行您所說的相同操作：我們有一個資料庫，但我們想要幾乎同時測試某些內容 50 次。
ДС：50次表示您需要訂購50個Spot實例。
NS：不，我們在一台機器上完成所有工作。
ДС：但是，如果這個資料庫達到 TB 級，您將如何擴展 50 倍。 她很可能需要有條件的 256 GB RAM？
NS：是的，有時您需要大量內存 - 這很正常。 但這是生活中的例子。 量產機有96核、600GB。 同時，資料庫使用 32 個核心（現在有時甚至是 16 個核心）和 100-120 GB 記憶體。
ДС： 那裡可以放 50 份嗎？
NS：所以只有一份副本，然後寫時複製（ZFS）就可以了……我會更詳細地告訴你。
例如，我們有一個 10 TB 的資料庫。 他們為它製作了一個磁碟，ZFS 還將其大小壓縮了 30-40%。 由於我們不進行負載測試，因此確切的響應時間對我們來說並不重要：讓它慢 2 倍 - 沒關係。
我們為程式設計師、QA、DBA 等提供機會。 在 1-2 個執行緒中執行測試。 例如，他們可能會進行某種遷移。 它不需要同時使用 10 個核心 - 它需要 1 個 Postgres 後端，1 個核心。 遷移將會開始——也許 仍然會啟動，然後將使用第二個核心。 我們分配了16-32個核心，所以10個人可以同時工作，沒問題。
因為身體上 PGDATA 同樣，事實證明我們實際上是在欺騙Postgres。 技巧是這樣的：例如，同時啟動 10 個 Postgres。 通常是什麼問題？ 他們把 ，比方說 25%。 因此，這是 200 GB。 您將無法啟動超過三個，因為記憶體將耗盡。
但在某些時候我們意識到這是沒有必要的：我們將shared_buffers設定為2GB。 PostgreSQL 有 ，實際上它是唯一影響的 。 我們將其設定為 0,5 TB。 即使它們實際上不存在也沒關係：他制定計劃就好像它們存在一樣。
因此，當我們測試某種遷移時，我們可以收集所有計劃 - 我們將看到它在生產中如何發生。 秒數會有所不同（更慢），但我們實際讀取的數據以及計劃本身（那裡有什麼 JOIN 等）結果與生產中完全相同。 您可以在一台機器上並行運行許多此類檢查。
ДС: 你不覺得這裡有一些問題嗎？ 第一個是僅適用於 PostgreSQL 的解決方案。 這種方法是非常私人的，不是通用的。 第二個是 Kubernetes（以及雲端技術現在發展的一切）涉及許多節點，而這些節點是短暫的。 在您的情況下，它是一個有狀態的持久節點。 這些事情讓我很矛盾。
NS：首先，我同意，這純粹是 Postgres 的故事。 我認為如果我們有某種直接 IO 和幾乎所有記憶體的緩衝池，這種方法將不起作用 - 計劃會有所不同。 但目前我們只與 Postgres 合作，我們不考慮其他。
關於 Kubernetes。 您自己到處告訴我們，我們有一個持久資料庫。 如果實例失敗，主要是保住磁碟。 在這裡，我們在 Kubernetes 中也擁有整個平台，並且 Postgres 的組件是獨立的（儘管有一天它會在那裡）。 因此，一切都是這樣的：實例倒下了，但我們保存了它的PV並簡單地將它連接到另一個（新的）實例，就好像什麼也沒發生一樣。
ДС：從我的角度來看，我們在 Kubernetes 中建立 Pod。 K8s - 鬆緊帶：依需求訂購結。 任務是簡單地建立一個 pod 並說它需要 X 數量的資源，然後 K8s 會自行計算出來。 但 Kubernetes 中的儲存支援仍然不穩定： 在 （此版本已發布 本週 之前）這些功能僅成為測試版。
六個月到一年將會過去——它會變得或多或少穩定，或至少會如此聲明。 那麼快照和調整大小的可能性就可以完全解決您的問題。 因為你有底線。 是的，它可能不會很快，但速度取決於「幕後」的內容，因為某些實作可以在磁碟子系統層級進行複製和寫入時複製。
NS：所有引擎（亞馬遜、Google...）也有必要開始支援這個版本 - 這也需要一些時間。
ДС: 我們還沒有使用它們。 我們用我們的。
Kubernetes 本地開發
NS: 當你需要把所有的pod都安裝到一台機器上，做這麼一個小測試的時候，你有沒有遇過這樣的願望。 要快速獲得概念證明，請查看應用程式在 Kubernetes 中運行，而無需為其專門使用一堆機器。 有Minikube，對吧？
ДС：在我看來，這個案例（部署在一個節點上）完全與本地開發有關。 或是這種模式的一些表現形式。 吃 ， 有 , 。 我們正在努力在 Docker 中使用 Kubernetes。 現在我們開始用它來測試。
NS：我曾經認為這是一種將所有 Pod 包裝在一個 Docker 映像中的嘗試。 但事實證明，這是完全不同的事。 無論如何，有單獨的容器、單獨的 Pod——就在 Docker 中。
ДС： 是的。 還有一個相當有趣的模仿，但意思是這樣的...我們有一個用於部署的實用程式 - 。 我們想讓它成為條件模式 werf up：“給我本地 Kubernetes。” 然後在那裡運行條件 werf follow。 然後，開發人員將能夠編輯 IDE，系統中將啟動一個進程來查看變更並重建映像，將它們重新部署到本機 K8s。 這就是我們想要嘗試解決當地發展問題的方式。
K8s現實中的快照和資料庫克隆
NS：如果我們回到寫時複製。 我注意到雲端也有快照。 他們的工作方式不同。 例如，在 GCP 中：您在美國東海岸有一個多 TB 的實例。 您定期拍攝快照。 您從快照中獲取西海岸磁碟的副本 - 幾分鐘內一切都準備就緒，它運行得非常快，只需將快取填充到內存中即可。 但這些克隆（快照）是為了「提供」新磁碟區。 當您需要創建大量實例時，這很酷。
但對於測試，在我看來，快照，你在 Docker 中談論的，或者我在 ZFS、btrfs 甚至 LVM 中談論的...... - 它們允許你不在一台機器上創建真正的新資料。 在雲端中，您每次仍然需要為它們付費，並且等待的不是幾秒鐘，而是幾分鐘（在這種情況下 ，可能是手錶）。
相反，您可以在一兩秒鐘內獲取這些數據，運行測試並將其丟棄。 這些快照解決不同的問題。 在第一種情況下 - 擴展並獲取新的副本，在第二種情況下 - 用於測試。
ДС: 我不同意。 讓卷克隆正常工作是雲的任務。 我沒有看過他們的實現，但我知道我們如何在硬體上做到這一點。 我們有 Ceph，它允許任何物理卷（） 說 克隆 並在幾十毫秒內獲得具有相同特徵的第二卷， '阿米等你需要明白，裡面有一個棘手的寫時複製。 為什麼雲端不應該做同樣的事情？ 我確信他們正在嘗試以某種方式做到這一點。
NS：但是他們仍然需要幾秒鐘、幾十秒鐘來啟動一個實例，將 Docker 引入那裡，等等。
ДС：為什麼需要引發整個實例？ 我們有一個具有 32 個核心、16 個核心的實例，它可以容納其中 - 例如，四個。 當我們訂購第五個時，該實例已被提升，然後它將被刪除。
NS：是的，有趣的是，Kubernetes 卻是一個不同的故事。 我們的資料庫不是K8s，我們只有一個實例。 但克隆一個多 TB 的資料庫只需要不超過兩秒的時間。
ДС： 這很棒。 但我最初的觀點是，這不是一個通用的解決方案。 是的，這很酷，但它僅適用於 Postgres，並且僅適用於一個節點。
NS：它不僅適用於 Postgres：如我所描述的，這些計劃僅適用於 Postgres。 但如果我們不關心計劃，只需要所有資料進行功能測試，那麼這適用於任何 DBMS。
ДС：很多年前我們對 LVM 快照做了類似的事情。 這是一個經典。 這種方法被非常積極地使用。 有狀態節點只是一種痛苦。 因為你不應該丟棄它們，你應該永遠記住它們......
NS：您認為這裡有混合動力的可能性嗎？ 假設有狀態是某種 Pod，它適用於多個人（許多測試人員）。 我們只有一個卷，但由於檔案系統的原因，克隆是本地的。 如果 Pod 掉落，但磁碟仍然存在，則 Pod 會升起，計算有關所有克隆的信息，再次拾起所有內容並說：“這是在這些連接埠上運行的克隆，請繼續使用它們。”
ДС：從技術上講，這意味著在 Kubernetes 中，它是一個 pod，我們在其中運行許多 Postgres。
NS： 是的。 他有一個限制：假設同時與他一起工作的人不超過 10 人。 如果您需要 20 個，我們將啟動第二個此類吊艙。 我們將完全克隆它，收到第二個完整捲後，它將具有相同的 10 個“薄”克隆。 難道你沒有看到這個機會嗎？
ДС：我們需要在這裡新增安全性問題。 這種類型的組織意味著這個pod 具有很高的權限（能力），因為它可以對檔案系統執行非標準操作...但我重複一遍：我相信在Kubernetes 的中期，他們將修復存儲，在雲，他們將用體積來修復整個故事 - 一切都會“正常”。 將會調整大小、克隆…有一個卷 - 我們說：“在此基礎上創建一個新卷”，一分半鐘後我們就得到了我們需要的東西。
NS：我不相信一秒半秒就能處理很多 TB 資料。 在 Ceph 上，你自己做，但你談論雲。 轉到雲端，在 EC2 上克隆一個多 TB 的 EBS 卷，然後看看效能如何。 不會需要幾秒鐘。 我對他們什麼時候能達到這個水準非常感興趣。 我明白你在說什麼，但我不敢苟同。
ДС：好的，但我說的是中期，不是短期。 幾年來。
關於 Zalando 的 PostgreSQL 運算符
在這次會議中，來自 Zalando 的前開發人員 Alexey Klyukin 也加入並談到了 PostgreSQL 算子的歷史：
很高興這個主題得到了廣泛的討論：Postgres 和 Kubernetes。 當我們在 2017 年開始在 Zalando 做這件事時，這是一個每個人都想做但沒有人做的話題。 每個人都已經有了 Kubernetes，但是當他們問如何使用資料庫時，甚至有人喜歡 宣揚K8s的人是這樣說的：
「前往託管服務並使用它們，不要在 Kubernetes 中執行資料庫。 否則，你的 K8 會決定，例如昇級，關閉所有節點，你的數據就會飛得很遠很遠。”
我們決定建立一個操作符，與此建議相反，它將在 Kubernetes 中啟動 Postgres 資料庫。 我們有一個很好的理由 - 。 這是 PostgreSQL 的自動故障轉移，正確完成，即使用etcd、consul或ZooKeeper作為叢集資訊的儲存。 這樣一個儲存庫將為每個詢問當前領導者是誰的人提供相同的資訊 - 儘管事實上我們已經分發了所有內容 - 因此不存在裂腦。 另外我們還有 為了他。
整體而言，公司從內部硬體資料中心遷移到雲端後，就出現了自動故障轉移的需求。 雲端基於專有的 PaaS（平台即服務）解決方案。 它是開源的，但需要做很多工作才能啟動和運行。 它被稱為 .
最初，沒有 Kubernetes。 更準確地說，當我們部署自己的解決方案時，K8s已經存在，但它非常粗糙，不適合生產。 在我看來，那是2015年或2016年。 到了 2017 年，Kubernetes 已經或多或少變得成熟了——需要遷移到那裡。
我們已經有了一個 Docker 容器。 有一個使用 Docker 的 PaaS。 為什麼不嘗試 K8s？ 為什麼不寫自己的運算子呢？ 從阿維托來到我們這裡的穆拉特·卡比洛夫 (Murat Kabilov) 主動開始了這個計畫——「玩」——然後這個計畫就「起飛了」。
但總的來說，我想談談 AWS。 為什麼歷史上有AWS相關代碼......
當您在 Kubernetes 中運行某些東西時，您需要了解 K8s 是一項正在進行中的工作。 它不斷地發展、完善，甚至時不時地崩潰。 你需要密切關注 Kubernetes 中的所有變化，你需要準備好在發生事情時深入研究它並詳細了解它是如何工作的——也許比你想要的更多。 原則上，這適用於運行資料庫的任何平台...
因此，當我們執行該語句時，我們讓 Postgres 在外部磁碟區上運作（本例中為 EBS，因為我們在 AWS 上工作）。 資料庫成長了，在某些時候需要調整它的大小：例如，EBS 的初始大小是 100 TB，資料庫成長到這個大小，現在我們想讓 EBS 達到 200 TB。 如何？ 假設您可以在新實例上進行轉儲/恢復，但這將花費很長時間並涉及停機時間。
因此，我想要調整大小以擴大 EBS 分割區，然後告訴檔案系統使用新空間。 我們做到了，但當時 Kubernetes 沒有任何用於調整大小操作的 API。 由於我們在 AWS 上工作，因此我們為其 API 編寫了程式碼。
沒有人會阻止您在其他平台上做同樣的事情。 聲明中沒有暗示它只能在AWS上運行，並且不適用於其他一切。 總的來說，這是一個開源專案：如果有人想加速新 API 的使用，歡迎您。 吃 、拉取請求 - Zalando 團隊嘗試快速回應這些請求並提升操作員。 據我所知，該項目 Google Summer of Code 和其他一些類似的計劃。 Zalando 正在積極致力於此。
PS獎金！
如果您對 PostgreSQL 和 Kubernetes 主題感興趣，那麼請注意，下一個 Postgres Tuesday 是在上週舉行的，我在那裡與 Nikolai 進行了交談 亞歷山大·庫庫甚金（來自 Zalando）。 其視頻可用 .
聚苯硫醚
另請閱讀我們的博客：
- «“;
- «“;
- «“;
- «“。
來源： www.habr.com