Skip to main content

89 docs tagged with "iThome"

View All Tags

Device Plugin - Introduction

除了三大標準 CRI, CNI, CSI 之外， kubernetes 本身也有自行時做一些方式來擴充整個叢集的功能，而本文要介紹的就是 Device Plugin 這個擴充功能，這個功能最著名的使用方式我想就是 GPU運算了，透過 Device Plugin, 可以讓不同 GPU 廠商都能夠自行實作相關的方式把 GPU 跟運算資源結合並且透過 kubernetes內建的 scheduler 等有效地使用這些資源。

CNI - Flannel - IP 管理篇

本篇文章針對 flannel 如何管理 IP 地址的事情進行探討與研究，許多人初次使用 kubeadm 安裝 flannel 的時候都曾經因為忘記加上 --pod-net-cidr 等參數導致安裝失敗，而這篇文章就會來探討這個參數的意義，為什麼需要這個參數，同時搭配前述已經分享過的 IPAM 管理，來重新仔細觀察 flannel 的運作過程

CNI - Flannel - VXLAN 封包運作篇

本篇文章作為 CNI - Flannel 的最後一篇探討，藉由研究 VXLAN 的運作原理來研究到底 flannel 是如何透過 vxlan 來讓不同節點上並且擁有私有 IP 的 Pod 可以互相溝通溝通的。

CNI - Flannel - 安裝設定篇

CNI 的選擇一直以來都是個探討的議題，各式各樣的 CNI 有者不同的特色與效果，使用者要怎麼選擇往往不知所措。老實說對於大部分的使用情況來說，其實 CNI 的選擇影響也不太大，畢竟很多情境只是要求網路可以通暢即可，沒有其他的需求。 而本文則針對一個常見的 CNI, Flannel 進行探討，來研究該 CNI 到底怎麼安裝的，安裝的過程怎麼處理設定檔案的問題。

CNI 閒談

本文作為網路分享的最後一篇，針對各式各樣的 CNI 相關議題進行討論，並且分享個人自身看法，沒有太深的技術研究與分析

Container Network Interface 介紹

本文作為網路系列文章的第一篇，將從 Container Network Interface 下手，相對於 Container Runtime Interface, CNI 以是個類似的架構，但是主打網路能力為主，至於網路能力這個字眼其實很模糊，畢竟不同情境，不同需求都會有不同的實現方式，很難用一個通用的說法來函索有可能力。本文會跟大家介紹 CNI 的相關資訊，包括標準的內容，相關設定，最後也會透過一些比較跟大家介紹不同 Container 實現方式其最後底層去操作 CNI 的方式也截然不同

Container Runtime - CRI-O

本文要特別介紹基於 Kubernetes 所開發的 CRI 解決方案 CRI-O, CRI-O 所有的功能都是為了 kubernetes 而設計，不多不少剛剛好，完全最佳化於 kubernetes。此外由於不需要倚賴太多第三方的元件，譬如 docker, containerd 等，使用 CRI-O 可以減少元件之間 IPC 溝通的次數進而提升整體的效率。 本文主要會介紹 CRI-O 的概念並且透過實際安裝的方式介紹如何幫 kubernetes 抽換 runtime 成 CRI-O

Container Runtime - Security Container

有鑒於 CRI 的標準架構，各式各樣的針對不同目標的專案都能夠整合到 Kubernetes 中，而本文要介紹的兩個專案分別是 gVisor 以及 kata-container, 這兩個專案都是基於安全性考量而開發的 OCI Runtine，與其相同地位的就是最知名的 OCI Runtime, runc。 本文會介紹這兩個專案的概念以及目標，並且討論其實作架構來比較這兩種不同的方式是如何達到安全的效果

Container Runtime - Virtual Machine

本文作為 CRI 系列文章的最後一篇文章，要來跟大家分享一個比較少見的用法，透過 kubernetes 管理 Pod 的方式來管理 Virtual Machine，底層所有運行的服務都是基於 Virtual Machine 去跑，但是對於 Kubernetes 來說完全不知情，依然認為是一個 Pod 的形式。 這部分依賴重新撰寫一個符合 CRI 標準應用程式來對接 kubelet, 並且底下所有的運作都使用 virtual machine 來操作，因此這個範例就完全不會有 OCI 的存在，因為是真正的 virtual machine, 而非 container.

Container Storage Interface 基本介紹

本文開始又是嶄新的一篇，開始探討也是非常重要的儲存資源，儲存方面也有相關的標準再發展，其目的與 CRI 以及 CNI 一致，都是希望透過標準化接口能夠使得第三方的解決方案開發更加活絡且流暢，本文會開始來介紹儲存方面的基本概念以及為什麼需要 Container Storage Interface

Container Storage Interface 標準介紹

本文針對 Container Storage Interface 的標準進行介紹，探討 CSI 本身標準涵蓋的範圍與流程，以及部署上的一些常見做法，包含多種服務器各自的角色與地位。

Container Storage Interface 與 kubernetes

本篇文章著重於 Kubernetes 本身與 CSI 的關係，一直以來 kubernetes 甚至到 1.16 來說， CSI 都不是一個必需的設定，反而是依賴大量 in-tree 的整合程式碼來處理各式各樣的儲存後端，這雖然使用方便但是對於後續的擴充性，維護性，彈性都帶來的很大的危害。也因此 CSI 才有誕生的機會，所以對於長期使用 in-tree 的管理人員來說，勢必有一天要轉移到 CSI才有機會想到新的功能以及相關功能的修復

Container Storage Interface(CSI) - NFS 初體驗

前述分享了關於不少 Container Storage Interface 的事情，接下來我們直接使用 NFS 作為範例，來看看要如何透過 CSI 的架構來掛載 NFS 到 kubernetes cluster 中供運算資源使用

CSI 雜談

本篇文章作為 Storage 的最後一塊，就沒有特別針對主題探討，反而是聊聊閒聊一些 Storage 方面的議題，順便聊聊 Mount 這個東西除了常見的功能之外，還有什麼參數可以使用，並且有什麼樣的效果。

Device Plugin - Implementation

本篇文章會就 device plugin 本身的架構來探討如何實做一個 device plugin 的解決方案，從其溝通介面到運作流程進行探討，透過這些理解與討論會對 device plugin 有更多的了解

Kubernetes - Device Plugin - RDMA

這篇要來跟大家介紹什麼是 Remote Directly Memory Access(RDMA)，從這個裝置的概念介紹來學習該裝置的使用情境，並且套用到 kubernetes device plugin 的框架中可以怎麼使用。

Kubernetes - Device Plugin - SRIOV

這篇要來跟大家介紹什麼是 Single Root Input Output Virtualization (SR-IOV)，作為一個 OpenStack 世界中就大量被使用的裝置，到底其提供什麼樣的功能，以及為什麼 kubernetes 中會需要這個裝置，並且什麼情境下需要使用這個裝置。

Kubernetes - Operator Pattern 介紹

Operator 從 2018 年開始串紅，愈來愈多的服務都宣稱支援 Operator 的運作模式，所以本篇文章就來探討到底什麼是 Operator 以及使用這種運作模式可以帶來什麼樣的好處及壞處。

Kubernetes & CRI (I)

本篇文章會開始探討 kubernetes Container Runtime Interface 的概念與設計，並且討論其餘 OCI 的關係，最後介紹了 Docker/Containerd 這些不的 Container 解決方案是如何於 Kubernetes 共存的

Kubernetes & CRI (II) - containerd

本文介紹了 `containerd 的概念，並且嘗試建置一個基於 containerd 的 kubernetes cluster, 讓大家體驗看看佈樁 docker 也可以運行 kubernetes 的使用方式，同時也可以學習到是如何透過設定來改變 kubernetes 這一連串的行為的。

Kubernetes Container Security 探討

Seucirty 一直以來都無法忽視的問題，平常不理他可能相安無事，一旦出事情必定人仰馬翻。然而對於 kubernetes 這樣的容器管理平台來說，安全這個概念涵蓋的範圍很大，從底層架構的部署，到 kubernetes 平台的搭建，容器本身的創建以及應用程式的撰寫，每個環節都有安全的問題需要考量。本章節會針對容器相關的一些權限部分進行探討，並且從 kubernetes pod 的格式中去學習有什麼相關的權限設定可以用

kubernetes 與 CNI 的互動

Container Network Interface 的標準制定後，接下來要探討 kubernetes 本身與 CNI 的整合，這部分就如同 Contaienr Runtime Interface 一樣，可以透過 kubelet 的方式告知 kubernetes cluster 該啟用什麼樣的設定來設定 cluster 的網路，同時系統上也有相關的參數用來設定 CNI 相關的檔案，譬如執行檔以及設定檔，同時要注意的是 CNI 是基於節點為單位，所以設定的時候是每台機器都要設定。

Service Catalog

Service Catalog 是一套基於 Open Service Broker API 的資源創建解決方案，這邊的資源指得是一些並非 kubernetes 內建，但是常常被使用的資源，譬如資料庫等。透過 Service Catalog 的框架，使用者也可以透過 kubernetes yaml 的方式來創建與管理這些外部資源，並且使用 kubernetes secret 來保管相關的資訊檔案。

使用 golang 開發第一個 CNI 程式

本篇文章算是一個手把手實作的文章，主要會介紹如何使用 golang 開發一個基於 Linux Bridge 的 CNI 應用程式，並且介紹如何搭配設定檔來使用這個 CNI 操作 Linux Network Namespace, 藉由這篇文章的過程理解到一個 CNI 的運作及開發，對於往後研究其他 CNI 都會有一些幫助，特別是城市的框架跟概念。 最後本篇開發的 CNI 應用程式其實是可以直接套用到 Kubernetes 裡面使用，就因為都遵循 CNI 的規則

初探 CNI 的 IP 分配問題 (IPAM)

IP Address Management 作為 CNI 本身可提供的一個重要功能之一，更是 kubernetes 本身不可或缺的能力，透過 IPAM 的管理可以讓每個 Pod 都獲得一個 IPv4 或是 IPv6 的地址，至於 Pod 本身能不能上網，那就是 CNI 本身要處理的問題，根據不同需求來建議不同的網路環境提供 Pod 上網能力。本篇文章主要是探討 IPAM 的部分，針對三個由官方維護作為參考用的 IPAM，分別介紹他們的用途以及使用方式，來深入了解 IPAM 設計需要思考的部分以及相關議題

淺談 Container 實現原理, 以 Docker 為例(I)

本文針對 Container 的概念進行探討，特別是其相關標準 Open Container Initiative (OCI), OCI 中定義了兩項規格，分別是 Runtime specification 以及 Image specification. 本文粗略地介紹一下彼此的概念以及各自負責的功能

淺談 Container 實現原理, 以 Docker 為例(II)

本文延續前篇文章關於 Open Container Initiatives 的討論，前篇文章討論了關於 OCI 內的兩大標準，分別是 Runtime 以及 Image 這兩項關於 Container 的標準，而本篇文章則是會介紹如了相關的標準之外，目前有什麼相關的解決方案與工具與這兩個標準息息相關，同時對於 Docker 本身會怎麼利用這些標準來完成 COntainer 的運行

淺談 Container 實現原理, 以 Docker 為例(III)

本篇文章作為 Container 介紹的最後一篇，簡單的透過 namespace 的操作讓大家看看 network 以及 storage 本身的運行模式，接下來到 CNI 以及 CSI 相關的章節的時候會再仔細介紹 kubernetes 中是怎麼處理 network 與 storage 這兩大重要資源。

淺談 Kubernetes 設計原理

為了跟大家分享 kubernetes 內部的幾個重要設計，如 CRI, CSI 以及 CNI, 本篇文章先簡單介紹了一下 kubernetes 內部相關的設計理念，透過理解這些理念更可以理解為什麼會有各式各樣的介面被設計出來。