# CNCF章程
CNCF(云原生計算基金會)是Linux基金會旗下的一個基金會,加入CNCF等于同時加入Linux基金會(也意味著你還要交Linux基金會的份子錢),對于想加入CNCF基金會的企業或者組織首先要做的事情就是要了解CNCF的章程(charter),就像是作為一個國家的公民,必須遵守該國家的憲法一樣。CNCF之所以能在短短三年的時間內發展壯大到如此規模,很大程度上是與它出色的社區治理和運作模式有關。了解該章程可以幫助我們理解CNCF是如何運作的,也可以當我們自己進行開源項目治理時派上用場。
該章程最后更新于2018年5月15日,詳見<https://www.cncf.io/about/charter/>。下文中關于CNCF章程的介紹部分引用自[CNCF 是如何工作的](http://www.ocselected.org/posts/foundation_introduce/how_cncf_works/),有改動。
下圖是我根據CNCF章程繪制的組織架構圖。

## 1. CNCF的使命
CNCF 沒有偏離自己的主題,核心是解決技術問題:基金會的使命是創建并推動采用新的計算模式,該模式針對現代分布式系統環境進行了優化,能夠擴展至數萬個自愈式多租戶節點。
所謂的云原生系統須具備下面這些屬性:
- **應用容器化**:將軟件容器中的應用程序和進程作為獨立的應用程序部署單元運行,并作為實現高級別資源隔離的機制。從總體上改進開發者的體驗、促進代碼和組件重用,而且要為云原生應用簡化運維工作。
- **動態管理**:由中心化的編排來進行活躍的調度和頻繁的管理,從根本上提高機器效率和資源利用率,同時降低與運維相關的成本。
- **面向微服務**:與顯式描述的依賴性松散耦合(例如通過服務端點),可以提高應用程序的整體敏捷性和可維護性。CNCF 將塑造技術的發展,推動應用管理的先進技術發展,并通過可靠的接口使技術無處不在,并且易于使用。
## 2. CNCF扮演的角色
CNCF 其實是在開源社區的基礎上發揮著作用,應負責:
a) 項目管理
- 確保技術可用于社區并且沒有雜七雜八的影響
- 確保技術的品牌(商標和標識)得到社區成員的關注和使用,特別強調統一的用戶體驗和高水平的應用程序兼容性
b) 促進生態系統的發展和演進
- 評估哪些技術可以納入云原生計算應用的愿景,鼓勵社區交付這樣的技術,以及集成它們,且要積極的推進總結進度。
- 提供一種方法來培養各個部分的通用技術標準
c) 推廣底層技術和應用定義和管理方法,途徑包括:活動和會議、營銷(SEM、直接營銷)、培訓課程和開發人員認證。
d) 通過使技術可訪問和可靠來為社區服務
- 旨在通過對參考架構進行明確定義的節奏,為每個組成部分提供完全集成和合格的構建。
## 3. CNCF的價值觀
CNCF 會極力遵循以下一些原則:
1. **快速勝過磨嘰**,基金會的初衷之一就是讓項目快速的發展,從而支持用戶能夠積極的使用。
2. **開放!** CNCF 是以開放和高度透明為最高準則的,而且是獨立于任何的其它團體進行運作的。CNCF根據貢獻的內容和優點接受所有的貢獻者,且遵循開源的價值觀,CNCF輸出的技術是可以讓所有人使用和受益的,技術社區及其決策應保持高度透明。
3. **公平**:CNCF 會極力避免那些不好的影響、不良行為、以及“按需付費”的決策。
4. **強大的技術身份**:CNCF 會實現并保持高度的自身技術認同,并將之同步到所有的共享項目中。
5. **清晰的邊界**:CNCF 制定明確的目標,并在某些情況下,要確定什么不是基金會的目標,并會幫助整個生態系統的運轉,讓人們理解新創新的重點所在。
6. **可擴展**:能夠支持從小型開發人員中心環境到企業和服務提供商規模的所有部署規模。這意味著在某些部署中可能不會部署某些可選組件,但總體設計和體系結構仍應適用。
7. **平臺中立**:CNCF 所開發的項目并不針對某個特定平臺,而是旨在支持各種體系結構和操作系統。
## 4. 會員制
CNCF中的會員包括白金、金牌、銀牌、最終用戶、學術和非贏利成員等級別,不同級別的會員在理事會中的投票權不同。
a) **白金會員**:在CNCF理事會中任命1名代表,在理事會的每個次級委員會和活動中任命1名有投票權的代表,在網站可以突出顯示;如果也是終端用戶成員將繼承終端用戶成員的所有權利
b) **金牌會員**:基金會中每有5個金牌會員,該級別的會員就可以任命1名代表,最多任命3個;如果也是終端用戶成員將繼承終端用戶成員的所有權利
c) **銀牌會員**:基金會中每有10個銀牌會員,該級別的會員就可以任命1名代表,最多任命3個;如果也是終端用戶成員將繼承終端用戶成員的所有權利
d) **終端用戶**:參加終端用戶咨詢社區;向終端用戶技術咨詢委員會中提名1名代表
e) **學術和非贏利會員**:學術和非營利會員分別限于學術和非營利機構,需要理事會批準。學術成員和非營利成員有權將其組織認定為支持CNCF使命的成員以及理事會確定的任何其他權利或利益。
## 5. 理事會
a) CNCF理事會負責市場營銷、業務監督和預算審批,不負責技術方面,除了與TOC配合確定CNCF工作范圍、完成時間表a)、更新CNCF網站
b) 負責日常事務
1. 與TOC協商CNCF的整體范圍
2. 商標和版權保護
3. 市場營銷、布道和生態系統建設
4. 創建和執行品牌承諾項目,如果需要的話
5. 監督運營,業務發展;
6. 募資和財務管理
c) 理事會投票成員由會員代表和社區代表組成:
1. 成員代表包括:
- 每名白金會員任命1名代表
- 黃金和銀牌成員當選代表
2. 技術社區代表包括:
- 技術監督委員會主席
- 根據當時在任的理事會批準的程序從CNCF項目中選出兩名提交者。
3. 理事會可能會以白金會員比例的價格擴展白金會員資格,對年收入低于5000萬美元的創業公司進行長達5年的逐年審計,這些公司被視為理事會的戰略技術貢獻者。
4. 只有來自一組**關聯公司**的人員可以擔任會員代表。只有來自一組**關聯公司**的人員可以擔任技術社區代表。
d) 職責
1. 批準預算,指導將所有收入來源籌集的資金用于技術、市場或社區投資,以推動 CNCF 基金的使命;
2. 選舉理事會主席主持會議,批準預算批準的支出并管理日常運作;
3. 對理事會的決定或事項進行投票;
4. 界定和執行基金會的知識產權(版權,專利或商標)政策;
5. 通過活動、新聞和分析師宣傳、網絡、社交媒體以及其他營銷活動進行直接營銷和布道;
6. 監督運營,業務發展;
7. 建立并監督為推動CNCF的使命而創建的任何委員會;
8. 根據CNCF要求(可能包括認證測試)建立并執行品牌合規計劃(如有),以使用TOC建立的品牌標志;
9. 采用商標使用準則或政策;
10. 提供整體財務管理。
e) 基金會的收入用途
1. 市場營銷,用戶擴展CNCF中的項目的采用
2. 關鍵設施建設、運行和管理項目的基礎設施
3. 促進基于容器的計算使用CNCF中的項目實現
## 6. 技術監督委員會(TOC)
### a) 要求
CNCF 技術監督委員會,為了保持中立,則達成了以下共識:
1. 定義和維護CNCF的技術愿景。
2. 批準由理事會制定的CNCF范圍內的新項目,并為項目創建一個概念架構。
3. 糾正項目的發展方向,決策刪除或存檔項目。
4. 接受最終用戶委員會的反饋并反映在項目中。
5. 在科學管理的情況下調整組件的接口(在代碼標準化之前實現參考)
6. 定義在CNCF項目中實施的常用做法(如果有的話)。
### b) 技術監督委員會的構成
1. TOC最多由9名成員組成。
2. 選出的TOC成員將涵蓋關鍵的技術領域:容器技術、操作系統、技術運維、分布式系統、用戶級應用程序設計等。
3. 理事會將選舉6名TOC成員,最終用戶TAB將選出1名TOC成員,最初的7名TOC成員應另選兩名TOC成員。
4. 如果超過兩名TOC成員來自同一組關聯公司,無論是在選舉時還是來自后來的工作變更,他們將共同決定誰應該下臺,或如果沒有協商的依據,則應抽簽決定。
### c) 運營模式
1. TOC 會選舉出TOC的主席來,此角色主要負責 TOC 的議程和召集會議。
2. TOC 每個季度會面對面討論重要的熱點問題。
3. TOC 可能會根據需要開會討論新出現的問題。 TOC審核可能會提出以下問題:
- 任何的 TOC 成員
- 任何的理事會成員
- 建立的CNCF項目的維護者或頂級項目負責人
- CNCF 執行董事
- 最終用戶技術咨詢委員會獲得多數票
4. 保持透明:TOC會議、郵件列表、以及會議記錄等均是公開可訪問的。
5. 簡單的TOC問題可以通過簡短的討論和簡單的多數表決來解決。TOC討論可通過電子郵件或TOC會議進行。
6. 在對意見和可選虛擬討論/辯論選項進行審查后,尋求共識并在必要時進行投票。
7. 目的是讓TOC在TOC和社區內尋找達成共識的途徑。滿足法定人數要求的會議的TOC決定應以超過TOC成員出席率的50%的方式通過。
8. TOC會議需要TOC總人數的三分之二法定人數進行表決或作出任何決定。如果TOC會議未能達到法定人數要求,可以進行討論,但不應有任何投票或決定。
9. TOC決定可以在沒有會議的情況下以電子方式提出,但要通過表決則需要多少票數才能達到會議法定人數。在電子投票中,如果任何兩名TOC成員要求召開會議討論決定,則電子投票結束時無效,并且在會議結束后可以啟動新的投票,以討論決定已經完成。
### d) 提名標準
獲得 TOC 提名的開源貢獻者應該具備下面條件:
1. 承諾有足夠的可用可用時間參與CNCF TOC的活動,包括在CNCF成立時相當早期的投入,然后需持續投入時間,而且在季度的 TOC 會議之前要進行充分的準備和審查事宜。
2. 在CNCF范圍內展示了高水準的專業經驗。
3. 證明其有資格能夠獲得額外的工作人員或社區成員協助其在 TOC 的工作。
4. 在討論中保持中立,并提出CNCF的目標和成功與公司目標或CNCF中的任何特定項目保持平衡。
### e) TOC成員提名和選舉程序
1. TOC由9位TOC成員組成:由理事會選出的6位,由最終用戶TAB選出的1位和由最初的7位TOC成員選出的2位。
2. 提名:每個有資格提名TOC成員的個人(實體或成員)可以提名至多2名技術代表(來自供應商、最終用戶或任何其他領域),其中至多一個可能來自其各自公司。被提名者必須提前同意加入到候選人名單中。
- 最初的7名TOC成員(理事會選出的6名成員加上由最終用戶TAB選出的1名成員)應使用提名程序提名并選舉2名TOC成員。
- 提名者需要提供最多一頁紙的介紹,其中包括被提名者的姓名,聯系信息和支持性陳述,確定了在CNCF領域提名的經驗。
- 理事會、最終用戶TAB和TOC應確定提名、投票和關于TOC選舉提名和選舉過程的任何其他細節的時間表和日期。
- 評估期間最少保留14個日歷日,TOC 提名者可以聯系和/或評估候選人。
3. 選舉:評估期結束后,理事會、最終用戶標簽和最初的7位TOC成員應分別對每位被候選人進行表決。有效投票需要滿足會議法定人數所需的選票數量。每名被候選人均需要支持超過50%的投票人數,以確認被提名者符合資格標準。以多數票通過的候選人應為合格的 TOC 成員。
4. 如果合格的被提名者的人數等于或少于可選 TOC 席位的數量,則此被提名者應在提名期結束后獲得批準。如果有更多的合格被候選人比理事會,最終用戶TAB或TOC可選的開放TOC席位多,那么該組應通過Condorcet投票選出TOC成員。Condorcet投票應通過康奈爾在線服務(<http://civs.cs.cornell.edu/>)使用Condorcet-IRV方法運行。
5. 如果理事會,最終用戶TAB或TOC可供選舉的公開TOC席位的合格被候選人數較少,該小組將啟動另一輪提名,每名成員或個人有資格提名至多提名1名候選人。
### f) 約束條件
1. TOC 的成員任期為兩年,來自理事會選舉的最初六名當選TOC成員的任期為3年。由最終用戶TAB和TOC選出的TOC成員的初始任期為2年。
2. TOC成員可能會被其他TOC成員的三分之二投票撤除,受影響的個人不能參加投票。
3. 任何TOC成員連續3次連續會議都將被自動暫停投票資格,直至連續參加兩次會議。為避免疑義,暫停的TOC成員有資格在連續第二次會議中投票。
4. TOC章程、模式、方法、組成等可以由整個理事會的三分之二票通過修改。
5. TOC議程將由TOC制定。但是,預計最初的TOC討論和決定將包括:
- 評估包含在CNCF中的技術
- 確定新技術納入CNCF的接受標準
- 定義批準作為標準API的貢獻技術的流程
- 找出需要進一步調查的直接差距
## 7. 最終用戶社區
a) CNCF的最終用戶成員有權協調和推動CNCF用戶作為CNCF設計的消費者的重要活動。任何作為最終用戶的成員或非成員,每個“最終用戶參與者”均可被邀請參加。最終用戶參與者將幫助向技術咨詢委員會和CNCF社區就與用戶有關的主題提供意見。
b) 最終用戶技術咨詢委員會是由最終用戶社區成員選舉所產生。
c) 最終用戶社區成員將獲得CNCF執行董事的批準,或者 CNCF 執行董事缺席的話,則由 Linux 基金會執行董事來批準。
## 8. 最終用戶技術咨詢委員會(“最終用戶 TAB”)
a) 構成:最終用戶TAB應由來自最終用戶參與者的7名代表加上TOC的1名成員組成,以便于從最終用戶TAB到TOC的晉級。
b) 選舉:為了鼓勵最終用戶參與CNCF,前7名最終用戶會員可以委任1名代表參加初始最終用戶TAB,并將CNCF董事分配給任何最終用戶參與者的任何剩余席位。在第一年之后,所有最終用戶參與者可以提名1名代表并且最終用戶社區應該投票選擇使用當前最終用戶 TAB 批準流程的最終用戶TAB成員。
c) 經過三分之二投票通過后最終用戶 TAB 可以更改最終用戶社區的大小,前提是至少有7名可能的代表。
d) 最終用戶代表應當基于業務和技術敏銳度提名。候選人應該具備建設和運營體現CNCF原則的基礎設施和應用方面的重要實踐經驗。
e) 最終用戶 TAB 將討論和推進主題,重點是找出TOC和CNCF開發者社區的差距并提出優先事項。
f) 也會側重于主動推進最終用戶關心的話題,促進CNCF的市場采用,為最終用戶舉辦會議或向理事會提供咨詢。
g) 如果最終用戶 TAB 有意愿的話,它可以批準小組委員會特別興趣小組 (“SIG”)來解決行業或專業話題。
h) 最終用戶 TAB 是技術監督委員會的主要輸入方,應與技術監督委員會的其他輸入方和反饋一起作出決策和計劃。這些建議只是建議性的,在任何時候,最終用戶TAB的建議都不能用于命令或指導任何TOC或項目參與者采取任何行動或結果。
i) 為促進與TOC的雙邊互動,最終用戶技術咨詢委員會應選出1名TOC代表。最終用戶 TAB 可邀請任何人參加最終用戶會議、SIG或其他討論。
## 9. CNCF項目
通常情況下,是由CNCF的成員公司、開源社區的成員將項目先是帶到CNCF 的技術監督委員會來進行討論,然后決定是否被CNCF接納。要貢獻給CNCF的項目必須是經過技術監督委員會制定的標準的,之后當然還要經過理事會的批準。CNCF 的目標是希望捐贈給CNCF的項目和CNCF已有的項目在一定程度上是有關聯的,而且是可集成的。
和CNCF 關聯起來有以下三種方法:
1. 已經在CNCF的納管之下,畢竟CNCF是中立的,致力于成為大家的協作的歸屬地。
a) 項目的方方面面都交由CNCF來打理
b) 項目是由CNCF 來進行市場推廣的
c) 項目是解決云原生計算問題的核心組件,如Kubernetes、Mesos、etcd等等
2. 通過API或規范與CNCF相關聯XM
a) 包括CNCF可能提供或啟用多個選項的組件
b) 該項目被稱為CNCF集成的一個組成部分,而不是由CNCF主辦的項目
c) 集成和合規性由API或規范定義
d) 項目或組件的開發是由上游社區所開發,而且保持一定的活躍度
3. CNCF 使用到的
a) 項目或組件完全根據OSI批準的開源許可證進行授權,并且管理良好,并在CNCF中被用作組件。
b) 項目并沒有由CNCF 來進行市場推廣
c) 項目或組件的開發是由上游社區所開發,而且保持一定的活躍度
現有的開源項目應該繼續保持其現有的技術治理結構,以保持凝聚力和速度。但是由技術監督委員會批準之后,則會適當的進行一些適應。
應根據個人的水平和貢獻期限在項目間建立一個達到提交者地位的標準協議。因為提交者是維護者的選拔人才池,有了一定程度的貢獻,且經過同行們的認可,提交者就可晉升為維護者。
CNCF啟動的新開源項目應完成TOC采納的項目建議模板,并由TOC批準納入CNCF。TOC成員應有充足的時間討論和審查新的項目建議書。新的項目建議書應包括項目中的角色細節,為項目提出的治理,并確定與CNCF的角色和價值觀保持一致。
## 10. 市場委員會
a) 構成,市場委員會將向所有成員開放參與,應選舉市場委員會主席制定會議議程,進行一般的討論,并幫助委員會實現其目標。市場委員會應盡可能尋求共識。在市場委員會中無法達成共識的任何問題應提交給理事會。
b) 職責,市場委員會代表理事會負責設計,開發和執行相關的市場工作。
c) 如果市場委員會變得太大而無法有效運作,市場委員會可以選擇選舉市場董事,并將決策權委托給市場董事。
## 11. 知識產權政策
a) 任何加入到CNCF的項目都必須將其擁有的商標和徽標資產轉讓給Linux基金會的所有權。
b) 每個項目應確定是否需要使用經批準的CNCF CLA。對于選擇使用CLA的項目,所有代碼貢獻者將承擔Apache貢獻者許可協議中規定的義務,只有在必要時才作出修改,以確定CNCF是捐贈的接受者,并且應由理事會批準。請參閱 <https://github.com/cncf/cla> 上提供的CNCF參與者許可協議。
c) 所有向CNCF提交的新入站代碼應當(i)附有開發者原始證書簽名(<http://developercertificate.org>和(ii)根據Apache許可證2.0版(可從<http://developercertificate.org>和<http://www.apache.org/licenses/LICENSE-2.0> 獲得)該許可證除了并且不得取代根據上文(b)規定的供款許可協議所承擔的義務。
d) 所有出站代碼將在Apache許可證2.0版下提供。
e) 所有評估納入CNCF的項目都必須獲得OSI批準的開源許可證的完全許可,如果CNCF中包含的項目的許可證不是Apache許可證2.0版,則需要獲得理事會的批準。
f) 所有文檔將由CNCF根據知識共享署名4.0國際許可證來提供。
g) 如果需要替代入站或出站許可證以符合杠桿式開放源代碼項目的許可證或為實現CNCF的使命而需要其他許可證,理事會可以批準使用替代許可證 對于例外情況下的接受或提供的項目捐贈。
## 12. 反托拉斯指南
a) 所有成員均應遵守<http://www.linuxfoundation.org/antitrust-policy>上提供的Linux基金會反托拉斯政策中規定的Linux基金會的要求。
b) 所有成員都應鼓勵任何能夠滿足成員要求的組織的公開參與,而不論其競爭利益如何。換言之,理事會不應根據除用于所有成員的標準,要求或原因之外的任何標準,要求或理由尋求排除成員。
## 13. 行為準則
所有參與者都須同意遵守?[Linux基金會行為準則](http://events.linuxfoundation.org/code-of-conduct)。 TSC可以投票通過自己的CNCF行為準則。
## 14. 關聯公司
a) 定義:
1. “子公司”是指會員直接或間接擁有所涉實體超過百分之五十有投票權的證券或會員權益的任何實體;
2. “關聯公司”是指任何控制或由成員控制的實體,或者與成員一起受第三方共同控制的實體,在所有情況下,直接或間接擁有多于所有權的控制權;
3. “關聯公司”是指各成員的關聯公司。
b) 只有執行了參與協議的法人實體及其子公司才有權享有該會員的權利和特權;但條件是該成員及其子公司應作為單一成員共同對待。
c) 只有一名屬于一組關聯公司的成員有權一次性任命或提名理事會代表參加類別選舉。
d) 如果會員本身是會員或贊助商的基金會,聯盟,開源項目,會員組織,用戶組或其他實體,那么授予該成員的權利和特權只能擴展到該成員的員工代表,而不能擴展到其成員或發起人,除非理事會不時在特定情況下另行批準。
e) 會員資格不得轉讓,不可轉讓、也不能轉讓,除非現有會員將其現有的會員利益和義務轉讓給其大部分業務和/或資產的繼任者,無論是通過合并,出售還是其他方式;只要受讓人同意遵守 CNCF 的章程以及Linux Foundation成員所需的章程和政策。
## 15. 預算
a) 理事會應批準年度預算,絕不會承諾超出籌集的資金。預算應與Linux基金會的非營利性使命相一致。
b) Linux基金會應定期報告預算支出。
## 16. 常規和管理費用
a) Linux基金會應保管任何費用,資金和其他現金收據。
b) 一般和行政(G&A)費用將用于籌集資金以支付財務、會計和運營費用。 G&A費用應等于CNCF首期總收入1,000,000美元的9%以及CNCF總收入超過1,000,000美元的6%。
## 17. 一般規則和操作
參與CNCF 應做到:
a) 展示與開源項目開發人員社區進行協調的計劃和方法,包括關于代表社區的品牌、徽標和其它標志性的主題;
b) 以專業的方式體現維持社區的凝聚力為目標,同時還要保持Linux基金會在開放源代碼軟件社區的善意和尊重;
c) 尊重所有商標所有人的權利,包括任何品牌和使用準則;
d) 參與Linux基金會的所有新聞和分析師關系活動;
e) 根據要求,向Linux基金會提供關于項目參與的信息,包括參加項目贊助活動的信息;
f) 直接參與到基金會旗下的任何站點。
g) 根據理事會批準的規則和程序進行運營,前提是這些規則和程序不得與Linux基金會的宗旨和政策不一致,并且不得損害Linux基金會。
## 18. 修正案
本章程可以通過所有理事會成員的三分之二票數(不包括棄權)進行修改,前提是任何此類修改不得與Linux基金會的目的或政策不一致,并且不得對Linux基金會產生不利影響。
## 時間表A:提出CNCF范圍愿景
CNCF背后的首要目標是支持和加速“云原生計算”的采用。以下內容是初步范圍,旨在闡明CNCF將努力實施的“云原生計算”的核心概念。該初始范圍應成為發布在CNCF網站上的文檔。
CNCF社區堅信云原生計算包含三個核心屬性:
- 容器化包裝和分發
- 動態調度
- 面向微服務
**注**:關于云原生的定義正在重新設定中,已經與上述不同了。
云原生計算系統支持基于這些核心屬性的計算,并包含以下理想:
- 開放性和可擴展性
- 在標準化子系統的邊界處定義良好的API
- 應用程序生命周期管理的最小障礙

因為上述時間表已經有些過時了,CNCF成立已經有三年時間了,正在規劃新的方案。
## 參考
- [CNCF 是如何工作的](http://www.ocselected.org/posts/foundation_introduce/how_cncf_works/)
- https://www.cncf.io/about/charter/
- 序言
- 云原生
- 云原生(Cloud Native)的定義
- CNCF - 云原生計算基金會簡介
- CNCF章程
- 云原生的設計哲學
- Play with Kubernetes
- 快速部署一個云原生本地實驗環境
- Kubernetes與云原生應用概覽
- 云原生應用之路——從Kubernetes到Cloud Native
- 云原生編程語言
- 云原生編程語言Ballerina
- 云原生編程語言Pulumi
- 云原生的未來
- Kubernetes架構
- 設計理念
- Etcd解析
- 開放接口
- CRI - Container Runtime Interface(容器運行時接口)
- CNI - Container Network Interface(容器網絡接口)
- CSI - Container Storage Interface(容器存儲接口)
- Kubernetes中的網絡
- Kubernetes中的網絡解析——以flannel為例
- Kubernetes中的網絡解析——以calico為例
- 具備API感知的網絡和安全性管理開源軟件Cilium
- Cilium架構設計與概念解析
- 資源對象與基本概念解析
- Pod狀態與生命周期管理
- Pod概覽
- Pod解析
- Init容器
- Pause容器
- Pod安全策略
- Pod的生命周期
- Pod Hook
- Pod Preset
- Pod中斷與PDB(Pod中斷預算)
- 集群資源管理
- Node
- Namespace
- Label
- Annotation
- Taint和Toleration(污點和容忍)
- 垃圾收集
- 控制器
- Deployment
- StatefulSet
- DaemonSet
- ReplicationController和ReplicaSet
- Job
- CronJob
- Horizontal Pod Autoscaling
- 自定義指標HPA
- 準入控制器(Admission Controller)
- 服務發現
- Service
- Ingress
- Traefik Ingress Controller
- 身份與權限控制
- ServiceAccount
- RBAC——基于角色的訪問控制
- NetworkPolicy
- 存儲
- Secret
- ConfigMap
- ConfigMap的熱更新
- Volume
- Persistent Volume(持久化卷)
- Storage Class
- 本地持久化存儲
- 集群擴展
- 使用自定義資源擴展API
- 使用CRD擴展Kubernetes API
- Aggregated API Server
- APIService
- Service Catalog
- 資源調度
- QoS(服務質量等級)
- 用戶指南
- 資源對象配置
- 配置Pod的liveness和readiness探針
- 配置Pod的Service Account
- Secret配置
- 管理namespace中的資源配額
- 命令使用
- Docker用戶過度到kubectl命令行指南
- kubectl命令概覽
- kubectl命令技巧大全
- 使用etcdctl訪問kubernetes數據
- 集群安全性管理
- 管理集群中的TLS
- kubelet的認證授權
- TLS bootstrap
- 創建用戶認證授權的kubeconfig文件
- IP偽裝代理
- 使用kubeconfig或token進行用戶身份認證
- Kubernetes中的用戶與身份認證授權
- Kubernetes集群安全性配置最佳實踐
- 訪問Kubernetes集群
- 訪問集群
- 使用kubeconfig文件配置跨集群認證
- 通過端口轉發訪問集群中的應用程序
- 使用service訪問群集中的應用程序
- 從外部訪問Kubernetes中的Pod
- Cabin - Kubernetes手機客戶端
- Kubernetic - Kubernetes桌面客戶端
- Kubernator - 更底層的Kubernetes UI
- 在Kubernetes中開發部署應用
- 適用于kubernetes的應用開發部署流程
- 遷移傳統應用到Kubernetes中——以Hadoop YARN為例
- 最佳實踐概覽
- 在CentOS上部署Kubernetes集群
- 創建TLS證書和秘鑰
- 創建kubeconfig文件
- 創建高可用etcd集群
- 安裝kubectl命令行工具
- 部署master節點
- 安裝flannel網絡插件
- 部署node節點
- 安裝kubedns插件
- 安裝dashboard插件
- 安裝heapster插件
- 安裝EFK插件
- 生產級的Kubernetes簡化管理工具kubeadm
- 使用kubeadm在Ubuntu Server 16.04上快速構建測試集群
- 服務發現與負載均衡
- 安裝Traefik ingress
- 分布式負載測試
- 網絡和集群性能測試
- 邊緣節點配置
- 安裝Nginx ingress
- 安裝配置DNS
- 安裝配置Kube-dns
- 安裝配置CoreDNS
- 運維管理
- Master節點高可用
- 服務滾動升級
- 應用日志收集
- 配置最佳實踐
- 集群及應用監控
- 數據持久化問題
- 管理容器的計算資源
- 集群聯邦
- 存儲管理
- GlusterFS
- 使用GlusterFS做持久化存儲
- 使用Heketi作為Kubernetes的持久存儲GlusterFS的external provisioner
- 在OpenShift中使用GlusterFS做持久化存儲
- GlusterD-2.0
- Ceph
- 用Helm托管安裝Ceph集群并提供后端存儲
- 使用Ceph做持久化存儲
- 使用rbd-provisioner提供rbd持久化存儲
- OpenEBS
- 使用OpenEBS做持久化存儲
- Rook
- NFS
- 利用NFS動態提供Kubernetes后端存儲卷
- 集群與應用監控
- Heapster
- 使用Heapster獲取集群和對象的metric數據
- Prometheus
- 使用Prometheus監控kubernetes集群
- Prometheus查詢語言PromQL使用說明
- 使用Vistio監控Istio服務網格中的流量
- 分布式跟蹤
- OpenTracing
- 服務編排管理
- 使用Helm管理Kubernetes應用
- 構建私有Chart倉庫
- 持續集成與發布
- 使用Jenkins進行持續集成與發布
- 使用Drone進行持續集成與發布
- 更新與升級
- 手動升級Kubernetes集群
- 升級dashboard
- 領域應用概覽
- 微服務架構
- 微服務中的服務發現
- 使用Java構建微服務并發布到Kubernetes平臺
- Spring Boot快速開始指南
- Service Mesh 服務網格
- 企業級服務網格架構
- Service Mesh基礎
- Service Mesh技術對比
- 采納和演進
- 定制和集成
- 總結
- Istio
- 安裝并試用Istio service mesh
- 配置請求的路由規則
- 安裝和拓展Istio service mesh
- 集成虛擬機
- Istio中sidecar的注入規范及示例
- 如何參與Istio社區及注意事項
- Istio教程
- Istio免費學習資源匯總
- 深入理解Istio Service Mesh中的Envoy Sidecar注入與流量劫持
- 深入理解Istio Service Mesh中的Envoy Sidecar代理的路由轉發
- Linkerd
- Linkerd 使用指南
- Conduit
- Condiut概覽
- 安裝Conduit
- Envoy
- Envoy的架構與基本術語
- Envoy作為前端代理
- Envoy mesh教程
- SOFAMesh
- SOFAMesh中的Dubbo on x-protocol
- SOFAMosn
- 使用 SOFAMosn 構建 SOFAMesh
- 大數據
- Spark standalone on Kubernetes
- 運行支持Kubernetes原生調度的Spark程序
- Serverless架構
- 理解Serverless
- FaaS-函數即服務
- OpenFaaS快速入門指南
- 邊緣計算
- 人工智能