📄️ Automatically Renew Your Certificated in kubernetes by Cert-Manager
在這個資訊安全意識稍微抬頭的世代，網站配有 HTTPS 可說是個基本標配。同時因為 Let's Encrypt 的出現，讓 TLS 憑證的申請變得簡單且容易上手。然而使用 Let's Encrypt 本身還是有一些限制要處理，譬如需要定期更新憑證，以及如何驗證申請者目標網域的擁有者，這部分的操作都有對應的腳本來處理。然而在 Kubernetes 叢集之中，除了手動去運行這些腳本之外，有沒有更方便的方式可以整合這一切。本文要介紹一個叫做 `Cert-Manager` 的解決方案，透過其原理的理解，以及實際操作的步驟來學習如何更方便的在 kubernetes 叢集內管理憑證
📄️ 常見 CNI (Container Network Interface) Plugin 介紹
作為一個 Kubernetes 使用者，可能都有聽過 CNI/CRI/CSI 等眾多的介面。而 CNI 作為一個掌管整個 Kubernetes 叢集網路的核心元件，負責提供各式各樣的網路功能。目前為數眾多的開源 CNI 專案們，到底各別擁有什麼樣的特性與效果，作為一個管理者在選擇 CNI 的時候應該怎麼考慮。本文針對常見的 CNI 專案們進行了一個簡單的分析與介紹，讓讀者能夠更加得清楚自己需要的功能及應用是什麼，才能夠更聰明的選擇所要的 CNI
📄️ CNI 常見問題整理
本篇文章紀錄了作者這陣子以來與大家討論 CNI 時常常被問到的問題，透過對這些問題的理解可以更加深入的去學習什麼是 CNI, 以及 CNI 本身能夠能夠觸擊的功能與範圍。同時也附上一些相關的資源讓大家可以從不同角度更深入的去研究 CNI 的領域。
📄️ Install GPU in GKE(Google Kubernetes Engine)
過去所謂的 GPU 運算幾乎都是個人主機的市場，任何人都可以很輕鬆的購買顯卡回家並且安裝起來使用，不論是玩遊戲所需要，或是需要 GPU 運算，這部分的生態早就存在已久。 隨者 AI 市場的蓬勃發展， GPU 資源的需求量上升，個人家用所擁有的數量在部分應用情境下所需要的時間太長了，因此就有了公有雲與 GPU 結合的需求出現。使用者可以根據自身的需求去評估需要多少張 GPU 卡，然後在對應的公有雲上去申請對應的資源來使用。本文基於這種概念的情況下，跟大家分享一下在 Google Kubernetes Engine 上若要使用 GPU 的話，大致上有哪些步驟需要執行，並且分享一些背後的安裝原理。
📄️ [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.
📄️ 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 集群的方向進行研究，並且配上自己的心得與整理。
📄️ [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] 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 的方式來看看到底如何使用。
📄️ 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.
📄️ [Kubernetes] What Is Service?
於 kubernetes 叢集中，我們會部屬大量的容器應用程式,而這些應用程式有些是面向使用者,也有些是彼此容器間互相溝通使用的.舉例來說,管理人員可能會在叢集中佈署了相關的資料庫容器服務,而其他的應用服務就必須要透過網路連線的方式來存取該資料庫.為了要透過網路的方式存取,就意味要使用 IP 地址的方式來存取對應的容器服務,然而在 kubernetes 的叢集中,這些 Pod 重啟後預設情況下都會拿到不相同的 IP 地址， 這意味我們的客戶端應用程式就沒有辦法寫死這些 IP 地址來存取,必須要有更動態的方式讓客戶端應用程式可以取得當前目標容器(資料庫)的最新 IP 地址. 為了解決這個問題, 我們可以透過 kubernetes service 的架構來達成上述的目的。本文會跟大家介紹什麼是 kubernetes service 以及透過實際範例介紹該如何使用
📄️ [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 X Storage (I)
Kubernetes 的架構中，對於 Network/Storage/Device/Container 都有高度的抽象化，透過這些抽象化讓 Kubernetes 能夠更專心的發展自身平台與介面，讓更多的廠商與第三方專案專心開發發展自己的特色並且透過共通介面與 Kubernetes 協同合作。於儲存系統方面，最廣為人知的就是 PersistentVolume(PV), PersistentVolumeClaim(PVC) 以及 StorageClass, 這三者到底在 Kubernetes 叢集中扮演什麼樣的角色，彼此如何互相合作以及彼此各自有什麼樣的限制與應用，都會在本文中跟大家詳細介紹，希望能夠透過這篇文章讓大家更瞭解 PV/PVC/SC 的概念
📄️ NFS 於 Kubernetes 內的各種應用
Network FileSystem(NFS) 是一個普遍常用且方便的檔案系統, Kubernetes 本身也有支援 NFS 的使用，然而 NFS 本身的諸多限制以及常見的用法要如何跟 Kubernetes 完美的整合，各種 ExportPath 以及對應的 UNIX 檔案權限，甚至是 Kubernetes 所提供的容量限制，存取模式限制等。本文會針對 NFS 常見的使用方式介紹使用，並且介紹上述等常見功能如果要與 Kubernetes 整合會遇到的各種問題。此外本文也會介紹如何透過第三方的專案來提供 StorageClass 此動態分配的方式與 NFS 結合，提供另外一種使用情境。
📄️ [Golang] aggregate in mongo
本篇文章首先跟大家分享一個常見的 Schema 設計，在此情境下，為了讀取一連串的資料，我們有不同種方式可以辦到。其中一種就是本文的主角, Aggregate 的概念。為了解釋 Aggregate 如何運作以及如何實現，本文採用 Golang 作為基本的程式語言，並且使用 mgo 作為與 mongo 進行處理的第三方函式庫。此外也採用了最原始的讀取方式，並且將此方式從撰寫方式以及效能兩方面直接與 Aggregate 進行比較。
📄️ [netfilter] Introduction to ebtables
本文是 iptables/ebtables 系列分享文的第一篇，會先著重於 iptables/ebtables 本身的架構，更準確的是 netfilter 的架構介紹，從 User-Space 到 Kernel-Space 的組成元件，並且簡單敘述一下整體的運作流程。最後開始介紹 ebtables 這個存在但是較少人知道的工具，不同於 iptables, ebtables 更專注於基於 MAC 地址的 Layer2 轉發。 文章最後介紹了 ebtables 的規則組成，並且將 ebtables 規則的處理順序以圖表的方式呈現，讓大家更容易理解在 Layer2 轉發時，該怎麼透過 `ebtables` 去設定相關的規則來處理封包。
📄️ [netfilter] Introduction to iptables
透過瞭解 iptables 規則的四大組成 Table/Chian/Match/Target 來學習 iptables 的規則含義，同時透過圖表的方式來釐清封包在 Linux Kernel 傳輸過程中受到 iptables 規則的處理順序。最後會將 iptables 以及 ebtables 兩者的流程圖整合在一起，構建出一個更全面的封包轉送流程圖，於此流程圖中可以觀察到封包在 Routing/Bridging 不同過程中，是如何通過不同的 ebtables/iptables 規則的處理。 擁有這些資訊能夠讓你對系統上的 iptables/ebtables 有更全面性的理解其功用以及發生時機
📄️ [netfilter] Dig Into Docker Bridge Network By iptables/ebtables
本文透過對 iptables/ebtables 來設定相對應的規則，藉由這些規則來觀察在 Docker Bridge Network 的網路設定下，不同情境的網路傳遞實際上會受到哪些 iptables/ebtables 規則的影響。這些情境包含了常見的用法，譬如容器與容器之間同網段的傳輸，宿主機透過容器IP位址直接連線，甚至是外部網路透過 docker run -p xxx.xxx 的規則來接觸到內部容器。這些不同情境的網路連線牽扯到關於 Layer3 路由，Layer2 橋接 等不同方式的處理，因此在 iptables/ebtables 都會有不同的走向。只要能夠更佳的熟悉 iptables/ebtables 的用法與規則，未來有需要親自設定相關規則時，都能夠更精準且安全的去達到想要的目的，減少盲目猜測的時間與花費。
📄️ [論文導讀] - Towards Zero Copy Dataflows using RDMA
本文屬於論文導讀系列，這次針對的是高速網路(RDMA)的應用，來源是 SICCOM 2017 會議上。這篇文章有趣的地方在於他不是單純的介紹架構，而是透過一個實際的應用程式來闡述當該應用程式搭配上 RDMA 後獲得了 Zero Copy 的特色，在此特色加持下，原先應用程式的效能提升了多少。本文的標題是 Towards Zero Copy Dataflows using RDMA, 其內容跟 AI 的訓練過程有關，採用了由 Google 開源的訓練框架， Ternsorflow, 並且分析了在原先分散式的訓練模型中，資料不論在 CPU/GPU UserSpace/KernelSpace 甚至節點間都有大量的資料複製行為。透過 RDMA 的幫忙減少了這些行為最後證明了整體分散式訓練的時間大幅度縮短，是個非常有趣的短文.
📄️ NCurses Disk Usage(ncdu)
NCurses Disk Usage(ncdu) is a powerful tool to view file sizes across different directories in a simple and friendly GUI. Besides, you can also do some operation but read, such as delete file/directory. In this post, I will introduce what is ncdu and how to use it to replace the legacy command du.
📄️ 使用 Travis CI 為你的 Kubernetes 應用程式打造自動化測試
這篇文章的主軸其實非常簡單，目標是希望為開發者的 Kubernetes 應用程式提供更強健的自動化測試流程，確保該應用程式在開發上能夠與 Kubernetes 緊密結合。為了確保程式品質，我們都會在開發的過程中撰寫一些單元測試/整合測試來確保開發的功能能夠正常運作。 特別是當有新功能的開發或是臭蟲修復時不會對舊有的功能造成損毀。 這個理念看起來非常合理，但是當應用程式一旦與 Kubernetes 結合的時候，這個理念到底好不好實現?
📄️ [DevOps] Travis CI - Step/Job/Stage
這次要跟大家分享的是一些關於 TravisCI 的使用心得，相信有在 Github 上面維護專案的人應該都對各式各樣的 CI 系統不陌生，不論是 公有服務的 TravisCI 或是 CircleCI 或是自己透過 Jenkins 來處理。本篇想要跟大家分享的重點是在 TravisCI 上關於 Build Stage 的概念，透過 Build Stage，我們可以更有架構的去設計該專案的 CI/CD 流程。