Skip to main content

147 docs tagged with "Kubernetes"

View All Tags

Device Plugin - Introduction

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

[Container Network Interface] Bridge Network In Docker

The most import feature of the container is the resource isolation, including the mount, network, user, UTC and PID. that's the reason why we can't see those resources status of the host. The resources isolation are supported by the Linux Kernel and we will demostrate the networking part by the network namespace and also show you how does the docekr use the network namespace and Linux Bridge to proivde the network connectivity for each container.

[Container Network Interface] CNI Introduction

Container Network Interface (CNI) as a Network Interface between the network soluition and the container mechanism. Without the CNI, the network solution developer should implement his/her plugin for every container environment and it must be a disaster. Fortunately, with the help of the CNI, the developer can only focus on one interface and it should work for every container mechanism. In this post, we will see why we need the CNI, what is CNI and how kubernetes use the CNI to provide the network connectiviy for the computing unit, so called Pod.

[Container Network Interface] Implement Your CNI In Golang

As we know, the kubernetes use the CNI to provide the network connectivity for its Pod unit and the cluster administrator can choose what kind of the CNI should be installed in the cluster. For example, if the only requirement is the overlay network, you can choose the flannel CNI and choose the calico CNI if you have the requirement of the BGP. In this post, we will learn how to write your own CNI in golang language. Actually, You can implement it with any language as you like.

[DevOps] 基於 Kubernetes 的自動部屬流程 - Keel

本文介紹一種基於 Kubernetes 開發的 Continuous Deployment 解決方案 keel, Keel 透過部署相關應用於 Kubernetes 內並且直接針對 Container Registry 中的 Container Image 去讀取相關的資訊，同時搭配 Semantic Versioning 2.0.0 的格式來確保印象檔的新舊，並且針對新版來進行運行資源 (Pod/Deployment..etc) 的更新

[Kubernetes] DNS setting in your Pod

DNS 在傳統的網路架構中一直扮演很重要的角色，可以讓用戶端透過 FQDN 的方式去存取目標的伺服器端，不需要去寫死對方的 IP 地址。然而在 kubernetes 的架構中, kubernetes 預設就會建立一套 DNS server 讓所有創建的 Pod 來使用。對於一般的使用者來說，只要能夠存取外面網路以及 Kubernetes Service 相關即可,然而在某些特殊的應用情境下，譬如目前喊行之有年的 NFV 架構中，我們的服務(Pod)本身可能會需要更複雜的網路架構，譬如同時存在 Data Network/Control Network. 這情況下，我們的 Pod 會需要特別去處理自己裡面服務所使用的 DNS Server 。 本文主要針對 Pod 裡面關於 DNS 相關的設定進行介紹，並且透過實際部屬 Yaml 的方式來看看到底如何使用。

[Kubernetes] DNS Setting When DnsPolicy Is Default

本文跟大家分享一個在實際部屬上遇到的問題，在不同的環境下，採用 dnsPolicy:Default 設定的 Kubernetes Pod 裡面所設定的 DNS Server 卻是完全不同的. 根據實際研究與觀察後，發現這個數字並不是單單的依靠 kubernetes 去處理，實際上也跟 Docker 本身如何去設定容器的 dns 也有關係，這部分就包含了宿主機的 /etc/resolv.conf 以及宿主機上 Docker 運行時的參數. 本文會先介紹這個問題，並且分享解決問題的思路以致於最後可以得到這個結論。

[Kubernetes] DNS Setting with Dockerd(原始碼分析上)

在前篇文章有跟大家分享過實際部屬上遇到的 DNS 問題，並且透過實驗佐證去觀察結果, 本篇文章則是透過另外一種觀點來觀察結果,透過閱讀原始碼的方式來觀察到底 kubernetes 再創建相關的 Pod 時會如何去處理 DNS 相關的設定，由於整個過程牽扯到 kubernetes 以及 CRI(Container Runtime Interface)的操作，而我們預設使用的則是 Docker 作為底層容器的操作. 由於篇幅過長，所以本文會著重於 kubernetes 原始碼的部分，而 Docker 相關的部分則會餘下篇文章來研究.

[Kubernetes] DNS Setting with Dockerd(原始碼分析下)

在前篇文章有跟大家分享過實際部屬上遇到的 DNS 問題，並且透過實驗佐證去觀察結果, 本篇文章則是透過另外一種觀點來觀察結果,透過閱讀原始碼的方式來觀察到底 kubernetes 再創建相關的 Pod 時會如何去處理 DNS 相關的設定，由於整個過程牽扯到 kubernetes 以及 CRI(Container Runtime Interface)的操作，而我們預設使用的則是 Docker 作為底層容器的操作. 本篇文章會針對後半部分，也就是所謂的 docker(dockerd) 本身再創建容器的時候，會如何處理其 DNS 相關的設定，透過閱讀 docker-ce 以及 libnetwork 相關的原始碼，不但能夠更清楚的釐清全部的運作原理，也能夠學習到 docker 底層實踐的過程與精神

[Kubernetes] How to Implement Kubernetes Service - ClusterIP

在前述中我們已經學過了什麼是 kubernetes service, 一般情況下都會採用 ClusterIP 的形態幫特定的容器應用程式提供 Service 的服務. 本文會針對 ClusterIP 的概念進行更深入的探討,並且嘗試從系統層面的設計與應用來研究到底 ClusterIP 底層是怎麼實作的,這部分的實作包含了1) ClusterIP 到底在那裡？ 2) 如果有多個 Endpoints 的話, 是如何選擇當前連線的最終目標. 這些研究的內容包含了常見了網路概念，如 NAT(Network Address Translation) 以及 iptables 本身的設計及使用，如 table/chian 等概念有初步的認知,這樣對於本文的探討會更明白與瞭解.

[Kubernetes] How to Implement Kubernetes Service - NodePort

在前述中我們已經學過了什麼是 kubernetes service 以及如何實現 ClusterIP 這種類型的 service. 透過對 iptables 的探討與研究, 我們可以理解到 ClusterIP 本身會提供一個虛擬的 IP 地址,接下來只要跟這個地址有關的封包,都會透過 DNAT 的方式進行轉換找到最後的 Endpoint IP. 至於如何選擇的部分,則是透過機率的方式去尋找. 接下來我們要來探討另外一個也是很常使用的 kubernetes service 類型, 也就是 NodePort. NodePort 本身包含了 ClusterIP 的所有功能, 此外也額外開啟了一個新的存取方式. 透過直接存取節點的 IP 地址配上一個設定好的 Port, 也可以將該封包直接送到最後面的容器應用程式. 因此本文也要延續上一篇的思路,繼續研究 iptables 的規則來探討 NodePort 到底是如何實現的

[Kubernetes] How to Implement Kubernetes Service - SessionAffinity

在前述中我們已經學過了什麼是 kubernetes service 以及如何實現 ClusterIP/NodePort 等 service 類型. 透過對 iptables 的探討與研究. 接下來要研究的則是 Service 裡面的一個參數, 叫做 SessionAffinity, 所謂的連線親和力, 透過該參數的設定,希望能夠讓符合特定條件的連線最後都會選用到相同的後端應用程式,目前有支援的選項是 ClinetIP, 這意味者只要連線的來源 IP 地址是相同的,最後都會被導向到相同的容器應用程式. 然而這部分到底是如何實現的, 本文會先介紹什麼叫做 Connection. 並且介紹 SessionAffinity 的使用方式以及使用後的結果. 最後一樣透過相同的思路, 藉由研究 iptables 的規則來學習到 SessionAffinity 要如何完成, 同時也可以學習到 iptables 衆多靈活的使用方式.

[Kubernetes] Static Pod 介紹

本文主要跟大家分享如何透過 Static Pod 的方式來滿足用 Kubernetes 管理 API-Server/Controller/Scheduler 這些 Kubernetes 的基礎元件，其中 Static Pod 更是 Kubeadm 的架設原理，透過這個方式我們也可以更加了解 Kubeadm 的安裝方式

[Kubernetes] What Is Service?

於 kubernetes 叢集中，我們會部屬大量的容器應用程式,而這些應用程式有些是面向使用者,也有些是彼此容器間互相溝通使用的.舉例來說,管理人員可能會在叢集中佈署了相關的資料庫容器服務,而其他的應用服務就必須要透過網路連線的方式來存取該資料庫.為了要透過網路的方式存取,就意味要使用 IP 地址的方式來存取對應的容器服務,然而在 kubernetes 的叢集中,這些 Pod 重啟後預設情況下都會拿到不相同的 IP 地址， 這意味我們的客戶端應用程式就沒有辦法寫死這些 IP 地址來存取,必須要有更動態的方式讓客戶端應用程式可以取得當前目標容器(資料庫)的最新 IP 地址. 為了解決這個問題, 我們可以透過 kubernetes service 的架構來達成上述的目的。本文會跟大家介紹什麼是 kubernetes service 以及透過實際範例介紹該如何使用

[書本導讀]- GitOps實作上的挑戰

本文為電子書本[GitOps: What You Need to Know Now](https://info.container-solutions.com/gitops-what-you-need-to-know-now) 的心得第五篇。已獲得作者授權同意

[書本導讀]-GitOps工具的選擇

本文為電子書本[GitOps: What You Need to Know Now](https://info.container-solutions.com/gitops-what-you-need-to-know-now) 的心得第四篇。已獲得作者授權同意

[書本導讀]-GitOps後續

本文為電子書本[GitOps: What You Need to Know Now](https://info.container-solutions.com/gitops-what-you-need-to-know-now) 的心得第六篇。已獲得作者授權同意

[書本導讀]-什麼是GitOps

本文為電子書本[GitOps: What You Need to Know Now](https://info.container-solutions.com/gitops-what-you-need-to-know-now) 的心得第二篇。已獲得作者授權同意

[書本導讀]-淺談GitOps過往

本文為電子書本[GitOps: What You Need to Know Now](https://info.container-solutions.com/gitops-what-you-need-to-know-now) 的心得第三篇。已獲得作者授權同意

11個保護你 Kubernetes 集群的技巧與觀念(上)

在管理 Kubernetes 集群方面，大部分的玩家及管理者一開始最在意的一定會是自己的服務能不能夠順利運行起來，同時能不能藉由 kubernetes 的諸多特性，如 service/configmap/deployment/daemonset 等各式各樣的資源來加強自身的服務能力。然而對於一個真正運行產品的集群來說是完全不夠的，除了服務的功能以及穩定外，還有諸多相關的議題都需要一併考慮並且處理。在此議題下特別重要的就是 Security 的處理， Security 處理的不當，可能會造成使用者的資料被竊取，更嚴重甚至整個集權的管理權限都被外人取得。因此這次特別分享一篇 "11 Ways Not to Get Hacked" 的文章，針對裡面提出的 11 個保護好你 kubernetes 集群的方向進行研究，並且配上自己的心得與整理。

11個保護你 Kubernetes 集群的技巧與觀念(下)

在管理 Kubernetes 集群方面，大部分的玩家及管理者一開始最在意的一定會是自己的服務能不能夠順利運行起來，同時能不能藉由 kubernetes 的諸多特性，如 service/configmap/deployment/daemonset 等各式各樣的資源來加強自身的服務能力。然而對於一個真正運行產品的集群來說是完全不夠的，除了服務的功能以及穩定外，還有諸多相關的議題都需要一併考慮並且處理。在此議題下特別重要的就是 Security 的處理， Security 處理的不當，可能會造成使用者的資料被竊取，更嚴重甚至整個集權的管理權限都被外人取得。因此這次特別分享一篇 "11 Ways Not to Get Hacked" 的文章，針對裡面提出的 11 個保護好你 kubernetes 集群的方向進行研究，並且配上自己的心得與整理。

Automatically Renew Your Certificated in kubernetes by Cert-Manager

在這個資訊安全意識稍微抬頭的世代，網站配有 HTTPS 可說是個基本標配。同時因為 Let's Encrypt 的出現，讓 TLS 憑證的申請變得簡單且容易上手。然而使用 Let's Encrypt 本身還是有一些限制要處理，譬如需要定期更新憑證，以及如何驗證申請者目標網域的擁有者，這部分的操作都有對應的腳本來處理。然而在 Kubernetes 叢集之中，除了手動去運行這些腳本之外，有沒有更方便的方式可以整合這一切。本文要介紹一個叫做 `Cert-Manager` 的解決方案，透過其原理的理解，以及實際操作的步驟來學習如何更方便的在 kubernetes 叢集內管理憑證

Azure Kubernetes Service (AKS) - CNI (I)

除了自行架設 Kubernetes 之外，採用公有雲廠商所提供的 Kubernetes Service 也是一個方便的選擇，然而這種情況下有許多的設定跟功能都會依賴該公有雲廠商自行實作，大部分的功能都會與公有雲本身的架構進行高度整合以提供更方便的使用與操作。本文針對 Container Network Interface (CNI) 於 Azure 中的實現與使用進行了討論，藉此了解公有雲的 CNI 有什麼特別的設計與使用方式

CNCF Continuous Delivery 使用者調查報告

本篇文章節錄自 CNCF End User Technology Radar 關於 Continuous Delivery 的報告，擷取相關重點並加上個人心得來跟大家分享現在 CNCF 社群是怎麼選擇自己適合的 CD 工具

CNCF MultiCluster 使用者調查報告

本篇文章節錄自 CNCF End User Technology Radar 關於 MultipCluster 的報告，擷取相關重點並加上個人心得來跟大家分享現在 CNCF 社群是怎麼處理多個 Cluster 的

CNCF Observability 使用者調查報告

本篇文章節錄自 CNCF End User Technology Radar 關於 Observability 的報告，擷取相關重點並加上個人心得來跟大家分享現在 CNCF 社群是怎麼選擇自己適合的 CD 工具

CNCF Secrets 使用者調查報告

本篇文章節錄自 CNCF End User Technology Radar 關於 Secret的報告，擷取相關重點並加上個人心得來跟大家分享現在 CNCF 社群是怎麼選擇自己適合的 Secret 管理工具

CNCF Storage 使用者調查報告

本篇文章節錄自 CNCF End User Technology Radar 關於 Storage 的報告，擷取相關重點並加上個人心得來跟大家分享現在 CNCF 社群是怎麼選擇自己適合的 Storage 解決方案

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 時常常被問到的問題，透過對這些問題的理解可以更加深入的去學習什麼是 CNI, 以及 CNI 本身能夠能夠觸擊的功能與範圍。同時也附上一些相關的資源讓大家可以從不同角度更深入的去研究 CNI 的領域。

CNI 閒談

本文作為網路分享的最後一篇，針對各式各樣的 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 - 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 有更多的了解

Docker Network - 網路模型

本篇文章從入門的概念來介紹 Docker 的網路模型，透過對其使用上的瞭解，可以幫助我們去理解容器之間網路的使用，對於未來學習 Kubernetes 時會得心應手

GitOps 帶來的痛點與反思

本文翻譯自 Container-Solutions 的文章，探討 GitOps 實際操作上可能帶來的痛點與複雜度，最後作者帶出自己認為好的架構及設計以及推薦不同的思路來處理

Install GPU in GKE(Google Kubernetes Engine)

過去所謂的 GPU 運算幾乎都是個人主機的市場，任何人都可以很輕鬆的購買顯卡回家並且安裝起來使用，不論是玩遊戲所需要，或是需要 GPU 運算，這部分的生態早就存在已久。 隨者 AI 市場的蓬勃發展， GPU 資源的需求量上升，個人家用所擁有的數量在部分應用情境下所需要的時間太長了，因此就有了公有雲與 GPU 結合的需求出現。使用者可以根據自身的需求去評估需要多少張 GPU 卡，然後在對應的公有雲上去申請對應的資源來使用。本文基於這種概念的情況下，跟大家分享一下在 Google Kubernetes Engine 上若要使用 GPU 的話，大致上有哪些步驟需要執行，並且分享一些背後的安裝原理。

Install the kubernetes as single node in Fedora 28

To setup a kubernetes, there're so many approaches, including what infrstructure(VM/Container/Native) about the kubernetes and what tooles(kubeadm,kubespray,minikube). I choose use the kubeadm to install a native kubernetes in my laptop(Fedora) and you will see the whole setps to install all requirements, including the docker/kubernetes.

Introduction to Kubernetes Ingress (Nginx)

Kubernetes 本身提供了非常多好用且方便的資源，其中專於網路存取的部分除了 Service 是常用元件以外， Ingress 也是一個熱門且重度發展的項目。本文詳細的介紹了 Kubernetes Ingress 的架構並且實際以 Nginx Ingress Controller 作為一個範例去架設測試環境。該測試環計中會實驗基於 Host 與 Path 等不同方式的路由設定，並且解釋該測試環境的運作原理，讓讀者更能夠直接瞭解到 Ingress 的運作方式。

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 - IP 重複奇遇記

本文探討一種備份復原過程中可能會發生的 IP 重複問題，文章開頭先用簡單的模擬方式來模擬如何產生 IP 重複問題，接下來針對 CNI 的運作來探討其運作流程。

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 X Storage (I)

Kubernetes 的架構中，對於 Network/Storage/Device/Container 都有高度的抽象化，透過這些抽象化讓 Kubernetes 能夠更專心的發展自身平台與介面，讓更多的廠商與第三方專案專心開發發展自己的特色並且透過共通介面與 Kubernetes 協同合作。於儲存系統方面，最廣為人知的就是 PersistentVolume(PV), PersistentVolumeClaim(PVC) 以及 StorageClass, 這三者到底在 Kubernetes 叢集中扮演什麼樣的角色，彼此如何互相合作以及彼此各自有什麼樣的限制與應用，都會在本文中跟大家詳細介紹，希望能夠透過這篇文章讓大家更瞭解 PV/PVC/SC 的概念

kubernetes 與 CNI 的互動

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

NFS 於 Kubernetes 內的各種應用

Network FileSystem(NFS) 是一個普遍常用且方便的檔案系統, Kubernetes 本身也有支援 NFS 的使用，然而 NFS 本身的諸多限制以及常見的用法要如何跟 Kubernetes 完美的整合，各種 ExportPath 以及對應的 UNIX 檔案權限，甚至是 Kubernetes 所提供的容量限制，存取模式限制等。本文會針對 NFS 常見的使用方式介紹使用，並且介紹上述等常見功能如果要與 Kubernetes 整合會遇到的各種問題。此外本文也會介紹如何透過第三方的專案來提供 StorageClass 此動態分配的方式與 NFS 結合，提供另外一種使用情境。

Service Catalog

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

你到底知不知道什麼是 Kubernetes?

Kubernetes 的蓬勃發展以及其人氣帶來廣泛地使用，然而就現實中，其實出現了不少關於 kubernetes 不太正確的想像與理解，愈來愈多的人因應 kubernetes 的發展就將 kubernetes 視為一個完美的解藥，能夠解決所有營運部署的所有困難與需求。最後發現現實與理想沒有辦法妥協時就會露出失望與無奈的表情。其實問題就出在一開始沒有理解到底 kubernetes 能夠帶來什麼樣的優勢以及本身有什麼樣的能力與限制。本文針對一些常見的三大資源，儲存/網路/運算 介紹了一下筆者自己觀察以及理解的概念去描述到底 kubernetes 能夠做什麼，不能夠做什麼

使用 golang 開發第一個 CNI 程式

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

使用 Travis CI 為你的 Kubernetes 應用程式打造自動化測試

這篇文章的主軸其實非常簡單，目標是希望為開發者的 Kubernetes 應用程式提供更強健的自動化測試流程，確保該應用程式在開發上能夠與 Kubernetes 緊密結合。為了確保程式品質，我們都會在開發的過程中撰寫一些單元測試/整合測試來確保開發的功能能夠正常運作。 特別是當有新功能的開發或是臭蟲修復時不會對舊有的功能造成損毀。 這個理念看起來非常合理，但是當應用程式一旦與 Kubernetes 結合的時候，這個理念到底好不好實現?

常見 CNI (Container Network Interface) Plugin 介紹

作為一個 Kubernetes 使用者，可能都有聽過 CNI/CRI/CSI 等眾多的介面。而 CNI 作為一個掌管整個 Kubernetes 叢集網路的核心元件，負責提供各式各樣的網路功能。目前為數眾多的開源 CNI 專案們，到底各別擁有什麼樣的特性與效果，作為一個管理者在選擇 CNI 的時候應該怎麼考慮。本文針對常見的 CNI 專案們進行了一個簡單的分析與介紹，讓讀者能夠更加得清楚自己需要的功能及應用是什麼，才能夠更聰明的選擇所要的 CNI

淺談 GitOps 的概念

本篇文章主要跟大家介紹這幾年伴隨者 Kubernetes 出現的一個名詞 `GitOps`, 內容主要會包含1)GitOps 概念介紹 2)相關開源專案介紹

淺談 Kubernetes 設計原理

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