按標籤瀏覽

是什麼 eBPF（延伸柏克萊封包篩選器）是一種允許小型沙盒程式或腳本在 Linux 系統核心空間執行的技術，不需要修改核心原始碼載入 Linux 核心模組。 Linux 系統有兩個空間：核心空間和使用者空間。 核心空間是作業系統的核心，也是唯一可以無限制存取硬體的部分。 應用程式會停留在使用者空間，當它們需要更高權限時，就會向核心發送要求。 對於需要更彈性的應用程式，像是直接存取硬體，核心可以透過所謂的「Linux 核心模組」進行擴充。 這種方式擴充了核心的預設功能，允許應用程式更深度地存取底層元件。 不過，這種方法也會帶來安全風險，因此 eBPF 成為更有吸引力的替代方案。 解決的問題 通常狀況下，應用程式在使用者空間執行，如果應用程式需要核心的某些權限（E.g. 存取某些硬體）， 會透過「系統呼叫」向核心提出請求。 在大多數情況下，這種方法都能正常執行。不過，在某些情況下，開發人員需要更靈活的低階系統存取方式。 可觀察性、安全性和網路功能就是很好的範例。 為此，我們可以使用 Linux 核心模組，在不修改核心原始碼的情況下延伸核心基礎。 雖然使用 Linux 核心模組有很多好處，但也會帶來安全風險。 由於 Linux 核心模組在核心空間內執行，它們可能會導致核心崩潰，而核心一旦崩潰，整個機器也會當機。 此外，核心模組擁有更高的權限，可以直接存取系統資源。如果沒有適當的安全保護，攻擊者就會利用這些漏洞。 如何幫助我們 eBPF 提供比 Linux 核心模組更可控的環境，以執行使用者自訂的程式。 它在核心的沙盒環境中執行，提供隔離並降低風險。 如果漏洞或缺失在 eBPF 程式中被利用，其影響通常僅限於沙盒環境。 此外，在 eBPF 程式開始在核心中執行之前，它必須通過一些驗證。 驗證器元件會檢查 eBPF 程式是否存在潛藏的安全違規行為， 像是違規存取記憶體、無窮迴圈和未經授權的核心函式。 這樣它就能確保程式不會進入無窮迴圈並導致核心崩潰。 與 Linux 核心模組相比，這些安全控制措施使 eBPF 成為在 Linux 核心中執行應用程式更安全的選擇。..

歡迎 歡迎使用雲端原生 Glossary 的貢獻指南，感謝您的關注。 您可以透過以下方式參與貢獻，我們將在此進行詳細說明： 在現有議題上進行工作 提出新術語 更新現有術語 幫助本地化 Glossary CNCF Glossary 概述 該 Glossary 的目標是簡化複雜的雲端原生領域，使其更容易被人們理解和使用。 雲端原生 Glossary 的內容存儲在此 GitHub 存儲庫中， 您可以在那裡找到有關 Glossary 的議題、拉取請求(PRs)和 討論。 誰可以貢獻？ 您如何參與此專案取決於您的雲端原生專業知識水準。 簡化複雜的概念需要對該主題有深入的了解。 因此，要貢獻新術語，您必須精通該主題。 貢獻者通常是在這些技術上工作了一段時間的工程師或專注於雲端原生的學者。 專業知識是必需的，因為用簡單的話語解釋複雜的概念 真的 很難。而且，儘管易於理解的結果可能看起來很簡單，但達到所需的簡單性需要雲端原生專家之間的努力和協作。 如果您尚未成為雲端原生專家但仍想貢獻，我們建議與專家合作。 一旦專家確信術語準確描述概念，您就可以做出第一個 Glossary 貢獻。 本地化工作是精通另一種語言的初學者可以為 Glossary 做出寶貴貢獻的地方。 借助現有的可靠英語定義，經驗不足的貢獻者可以將術語本地化為目標語言。您可以加入現有的本地化團隊或創建新的本地化團隊。 請閱讀本指南中幫助本地化 Glossary 章節，了解如何開始。 開始之前 在開始您的 Glossary 貢獻之前，請確認完成以下步驟： 建立 GitHub 帳號，如果您還沒有的話。 簽署貢獻者授權協議(Contributor License Agreement) (CLA)。 驗證您的提交簽名。 啟用 vigilant mode 在您的 GitHub 帳戶上，以顯示 “Verified” 狀態在您的提交上。 最佳實踐 為了方便審核過程，請使用 semantic line breaks（例如，每句話一行）。 我們建議查看這份 markdown cheat sheet 以正確地在 GitHub 中格式化 Markdown 文本（例如，超連結、粗體、斜體）。 並且在命名 ...

以下的風格指南旨在幫助你了解雲端原生 Glossary 的定義結構，並在整個過程中保持一致的風格。 雲端原生詞彙遵循位於 CNCF 資源庫中的預設風格指南。 此外，它還遵循以下規則： 使用簡單、易懂的語言，避免技術術語和流行語 避免使用俚語 使用字面和具體的語言 省略縮略語 少用被動語態 力求以積極的形式表述 引號外不加感歎號 不要誇大其詞 避免重複 要簡明扼要 受眾 本 Glossary 是針對技術和非技術人員編寫的。 請使用簡單的術語來解釋定義並不要假定技術知識。有關定義的更多細節請參閱下面的定義部分。 最小可行定義 我們的目標是讓任何人都能夠輕鬆理解雲端原生術語。 因此，我們專注於簡潔明瞭。 請使用清晰簡單的語言，並提供任何使用技術的人都可以理解的示例，同時提供一個最小可行定義，至少從技術角度上來說。 我們不希望省略上下文和示例 — 畢竟，這些東西可以幫助讀者理解概念 — 但如果技術細節不需要理解它，我們就會跳過它。 目標不是讓事情變得過於複雜。一旦讀者了解了基本概念，其他資源將有助於他們進一步深入挖掘。 這部分超出了本 Glossary 的範圍。 定義樣板 每個 Glossary 術語都存儲在一個 markdown 文件中，並遵循這個樣板： — title: status: category: — ## 是什麼 對該技術或概念的快速總結。 ## 解決的問題 關於它所解決的問題的幾句話。 ## 如何幫助我們 用幾句話說明這個東西是如何解決問題的。 標題 title label 將始終位於定義布局的頂部，其值應使用標題大小寫。 — title: 定義樣板 狀態 status label 將出現在 title label 之後。這個 label 代表著這個定義距離完成還有多遠。..

是什麼 容器協調指的是在動態的環境中自動管理容器化應用程式的生命週期。 這通過一個容器協調器 (大多是 Kubernetes) 來執行如部署、(自動)擴展、自我修復和監控。 協調是一個隱喻用詞: 協調工具就如同樂隊指揮一樣指揮管理眾多容器，確保每個容器(或樂手)各執其職。 解決的問題 手動管理大規模的微服務、安全性和網路通訊以及常見的分散式系統 雖然困難但並非不可能。 而容器協調能讓用戶自動化所有這些管理任務。 如何幫助我們 容器協調工作允許使用決定系統的狀態。 首先，這些工具會宣告系統應具備的狀態 (例如 x 個容器、 y 個 Pod 等等)。 接著容器協調工具將會自動監控基礎建設並且在其狀態與宣告狀態不一致時自動修正 (例如當一個容器壞掉不能運行時，則啟動一個全新的容器)。 這種自動化的操作簡化了許多工程團隊手動與複雜的維運工作，例如 服務開通、部署、自動擴展、網路、負載平衡和其他活動。..

<p>嗨！👋 感謝您對貢獻 CNCF 雲端原生 Glossary 專案感到興趣。 無論您貢獻新術語、協助本地化 Glossary 成為您的母語， 或者想要幫助他人入門，都有很多方式成為此社群的活躍成員。 本文檔概述了專案中的不同貢獻者角色以及隨之而來的職責和權限。</p> <ol> <li>貢獻者 Glossary 歡迎所有人參與。任何人只要有貢獻都可以成為 Glossary 的貢獻者。所有貢獻者都應遵守 CNCF 行為準則。 有多種方式可以貢獻此專案，包括： 內容貢獻者：改進現有術語或新增術語的所有人， 本地化貢獻者：協助將 Glossary 翻譯成另一種語言的人， 幫助者：在 GitHub、Slack 或其他社群成員需要支援時協助他人的人， 大使：幫忙傳達訊息、教育社群如何貢獻，以及為什麼他們應該這麼做的任何人。 貢獻者可以擔任多個角色或僅專注於一個領域。 所有這些貢獻同等重要和有助於促進繁榮的社群。 有關內容和本地化貢獻，請參閱如何貢獻和風格指南。</li> <li>審核者 審核者提供 PR 的回饋並核准他們。任何活躍的貢獻者都可以成為審核者（參見成為審核者）。 Glossary 區分兩種審核者：（1）英文 Glossary 的審核者和（2）本地化團隊的審核者。 Glossary 審核者應該： 審核 PR 的技術準確性， 分配貢獻者議題並適當地標記他們， 為貢獻者提供反饋並在需要時指導他們， 校對和編輯提交。 如果審核者不再感興趣或無法執行上述職責，他們應讓維護人員知道並下台。 英文 Glossary 審核者 有三種類型的審核者： 1）擁有強大技術背景的審核者， 2）具有扎實的寫作能力的審核者， 3）精通兩者的審核者。 技術審核者：具有強大技術背景的人可以成為審核者，而不必具備扎實的英文寫作能力。但是，如果他們基於技術的優點核准了 PR，則必須確保經由一位（編輯）審核者進行了審核。 編輯者：編輯人員校對術語並確保其根據樣式指南用簡單的語言解釋。如果術語被大量編輯，編輯人員必須要求技術審核者再次審核，以確保含義未被更改。 本地化審核者 Glossary 還有本地化審核者。這些是本地化團隊（翻譯 Glossary 的團隊）之一的審核者。 本地化審核者僅允許為其自己的團隊執行核准任務，並有能力將 PR 合併到其專屬的開發分支。 任何本地化審核者都可以成為英文 Glossary 的審核者，如果符合要求的話。</li> </ol> ..

雲端原生 Glossary 雲端原生 Glossary 主要目標在使人們更容易理解，將以複雜而聞名雲端原生領域變得更簡單好懂，不僅限於技術人士，也同樣適用於商業人士。 為了實現這一目標，我們注重簡潔（例如：使用簡單用語描述且不包含流行用語、使用任何技術的人都可以通用的範例、省略不必要的細節）。 Glossary 是由 CNCF 商業價值小組（Business Value Subcommittee; BVS）領導的專案。 貢獻 歡迎所有人對雲端原生 Glossary 提出更改、補充和改進。 我們採用由 CNCF 管理的社群驅動的流程來開發和改進這個共享 Glossary 。 Glossary 提供了一個所有參與者使用且供應商保持中立的平台，以組織雲端原生技術的共享詞彙。 歡迎所有遵守本專案宗旨和章程的參與者做出貢獻。 任何希望貢獻的人都可以提交 GitHub 議題或創建拉取請求。 請確保您遵循風格指南，閱讀如何參與貢獻文件，加入 CNCF Slack工作區，並加入 #glossary頻道。 也有一個 #glossary-localizations頻道，提供想將 Glossary 翻譯為其本地化語言的人們使用。 致謝 雲端原生 Glossary 由 CNCF 行銷委員會 (CNCF Marketing Committee)（商業價值小組委員會）發起，包括來自 Catherine Paganini、 Chris Aniszczyk、 Daniel Jones、 Jason Morgan、 Katelin Ramer、 Mike Foster和許多的貢獻者。 如果想獲得完整的貢獻者名單，請參考此 GitHub page。 Glossary 主要維護由 Seokho Son、 Noah Ispas、 Jihoon Seo、 Nate W. 和 Jorge Castro。..

是什麼 邊緣運算是個分散式系統，它將一些儲存和運算資源從主要資料中心轉移到資料來源。 收集到的資料在本地端（例如：工廠、商店或整座城市）進行計算，而不是傳送到集中式資料中心進行處理和分析。 這些本地端處理單元或裝置代表系統的邊緣，而資料中心則代表系統的中心。 邊緣計算出的結果會被送回主要資料中心做進一步處理。 邊緣運算的例子包括手腕上的小配件或分析交通流量的電腦。 解決的問題 過去十年中，我們可以看到越來越多的邊緣裝置（例如：手機、智慧型手錶、感測器）。 在某些情況下，即時資料處理不僅是一個不錯的選擇，而且極其重要。 想想自動駕駛的汽車。 現在想像一下，汽車感測器的資料必須先傳送到資料中心進行處理，然後再送回汽車，這樣汽車才能作出適當的反應。 如此產生的網路延遲會是致命的。 雖然這是一個極端的例子，但大多數使用者都不願意使用無法即時反應的智慧設備。 如何幫助我們 如上所述，要使邊緣設備發揮作用，它們必須至少在本地端完成部分處理和分析工作，以便於對使用者提供接近即時的回饋。 要做到這點，就必須將資料中心的部分儲存和處理資源轉移到資料生產地：邊緣設備。 已處理和未處理的資料隨後發送到資料中心做進一步處理和儲存。 簡而言之，效率和速度是邊緣運算的主要驅動力。..