本文發表於一年多前。舊文章可能包含過時內容。請檢查頁面中的資訊自發布以來是否已變得不正確。

加入 SIG Scalability,以艱難的方式學習 Kubernetes

為SIG Scalability做貢獻是深入全面學習Kubernetes的好方法,團隊非常歡迎您加入成為貢獻者。我研究了“艱難之路”學習的價值,並採訪了當前的SIG主席,希望能讓您瞭解貢獻的感受。

“艱難之路”學習的價值

軟體開發社群中有一種信念,即學習新語言或系統應採用最嚴苛、最具挑戰性的方法。這些方法通常以“透過__的艱難之路學習”為名。例如:“透過艱難之路學習程式碼”、“透過艱難之路學習Python”,以及許多源自Zed Shaw在此主題上的課程。

雖然市面上有人提供“透過艱難之路學習Kubernetes”的體驗(最著名的是Kelsey Hightower),但任何“艱難之路”專案都應試圖涵蓋核心主題原則的各個方面。

因此,“透過艱難之路學習Kubernetes”的真正方法是加入CNCF並參與專案本身。只有一個SIG能夠真正提供Kubernetes的全棧學習體驗:SIG Scalability。

SIG Scalability背後的團隊負責檢測和處理Kubernetes叢集在節點數量達到上千個時出現的問題。Wojiciech Tyczynski,一位Google的資深軟體工程師,也是SIG Scalability的成員,表示該SIG的測試叢集標準規模超過5000個節點。

然而,這個SIG並非由擁有高度可擴充套件系統設計博士學位的專家組成。例如,許多與Tyczynski合作的人在加入SIG時對這類問題知之甚少,甚至對Kubernetes也知之甚少。

在SIG Scalability上工作就像跳入深水區學習游泳一樣,這個SIG天生就關注整個Kubernetes專案。SIG Scalability專注於Kubernetes作為一個整體在大規模下的功能。SIG Scalability團隊成員有動力學習每一個系統,並理解所有系統如何相互作用。

複雜而有意義的貢獻者體驗

雖然這聽起來很複雜(確實如此!),但這並不意味著它超出了普通開發人員、測試人員或管理員的能力範圍。Google軟體開發人員Matt Matejczyk自2019年初才加入團隊,從那時起,他一直是團隊中備受重視的成員,致力於發現bug。

“我是新來的,”Matejczyk說。“我於[2019年]1月加入團隊。在此之前,我在Google紐約的AdWords工作。我為什麼加入?我認識那裡的一些人,所以這是我做出這個決定的原因之一。我當時認為Kubernetes是一種獨特、尖端的技術。我認為能參與其中會很酷。”

Matejczyk對“酷”的判斷是正確的。“很酷,”他說。“所以,實際上,提高可擴充套件性並不容易。你需要理解很多東西。你需要非常瞭解Kubernetes。它可以使用Kubernetes的每個部分。在過去的8個月裡,我仍在努力適應。我想我可能花了3個月才達到像樣的速度。”

當Matejczyk談到這8個月裡他所做的工作時,他回答說:“一個有趣的例子是我最近一直在處理的一個迴歸問題。我們注意到Kubernetes控制平面在特定場景下整體變慢,但我們無法將其歸因於任何特定元件。最終,我們意識到一切都歸結於golang層面的記憶體分配。兩個完全獨立的程式碼片段(作為同一個二進位制檔案的一部分執行)僅因為其中一個分配記憶體過快而相互影響效能,這非常反直覺。但將所有線索串聯起來,找出這類迴歸問題的根源,會帶來極大的滿足感。”

Tyczynski 說:“這不僅是除錯迴歸問題,也是除錯和發現瓶頸。一般來說,這些可能是迴歸問題,但也可能是我們可以改進的地方。另一個重要領域是擴充套件我們希望向使用者保證的內容。擴充套件系統的SLA和SLO覆蓋範圍,以便使用者可以根據他們對系統性能和可擴充套件性的期望來信賴系統。Matt 在擴充套件我們的測試以使其更具代表性並涵蓋更多Kubernetes概念方面做了大量工作。”

嘗試加入SIG Scalability

SIG Scalability 團隊一直需要新成員,如果您是那種喜歡迎接新複雜挑戰,或許也喜歡“艱難之路”學習方式的開發人員或測試人員,請考慮加入這個 SIG。正如團隊指出的,將 Kubernetes 專業知識新增到您的簡歷中絕不是一個壞主意,而這是唯一一個可以從頭到尾學習所有知識的 SIG。

請參閱SIG 的文件,瞭解即將召開的會議、其章程等。您還可以加入#sig-scalability Slack 頻道,看看它的樣子。我們希望您能加入,利用這個絕佳的機會學習 Kubernetes 並同時做出貢獻。