52 docs tagged with "Linux"

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) 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.

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.

這次要跟大家分享的是一些關於 TravisCI 的使用心得，相信有在 Github 上面維護專案的人應該都對各式各樣的 CI 系統不陌生，不論是 公有服務的 TravisCI 或是 CircleCI 或是自己透過 Jenkins 來處理。本篇想要跟大家分享的重點是在 TravisCI 上關於 Build Stage 的概念，透過 Build Stage，我們可以更有架構的去設計該專案的 CI/CD 流程。

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

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

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

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

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

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

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

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

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

本文透過對 iptables/ebtables 來設定相對應的規則，藉由這些規則來觀察在 Docker Bridge Network 的網路設定下，不同情境的網路傳遞實際上會受到哪些 iptables/ebtables 規則的影響。這些情境包含了常見的用法，譬如容器與容器之間同網段的傳輸，宿主機透過容器IP位址直接連線，甚至是外部網路透過 docker run -p xxx.xxx 的規則來接觸到內部容器。這些不同情境的網路連線牽扯到關於 Layer3 路由，Layer2 橋接 等不同方式的處理，因此在 iptables/ebtables 都會有不同的走向。只要能夠更佳的熟悉 iptables/ebtables 的用法與規則，未來有需要親自設定相關規則時，都能夠更精準且安全的去達到想要的目的，減少盲目猜測的時間與花費。

本文是 iptables/ebtables 系列分享文的第一篇，會先著重於 iptables/ebtables 本身的架構，更準確的是 netfilter 的架構介紹，從 User-Space 到 Kernel-Space 的組成元件，並且簡單敘述一下整體的運作流程。最後開始介紹 ebtables 這個存在但是較少人知道的工具，不同於 iptables, ebtables 更專注於基於 MAC 地址的 Layer2 轉發。 文章最後介紹了 ebtables 的規則組成，並且將 ebtables 規則的處理順序以圖表的方式呈現，讓大家更容易理解在 Layer2 轉發時，該怎麼透過 `ebtables` 去設定相關的規則來處理封包。

透過瞭解 iptables 規則的四大組成 Table/Chian/Match/Target 來學習 iptables 的規則含義，同時透過圖表的方式來釐清封包在 Linux Kernel 傳輸過程中受到 iptables 規則的處理順序。最後會將 iptables 以及 ebtables 兩者的流程圖整合在一起，構建出一個更全面的封包轉送流程圖，於此流程圖中可以觀察到封包在 Routing/Bridging 不同過程中，是如何通過不同的 ebtables/iptables 規則的處理。 擁有這些資訊能夠讓你對系統上的 iptables/ebtables 有更全面性的理解其功用以及發生時機

探討 Kernel 如何實作 SwitchDev (I)

探討 Kernel 如何實作 SwitchDev (II)

探討 SwitchDev 架構問題

本文屬於論文導讀系列，這次針對的是高速網路(RDMA)的應用，來源是 SICCOM 2017 會議上。這篇文章有趣的地方在於他不是單純的介紹架構，而是透過一個實際的應用程式來闡述當該應用程式搭配上 RDMA 後獲得了 Zero Copy 的特色，在此特色加持下，原先應用程式的效能提升了多少。本文的標題是 Towards Zero Copy Dataflows using RDMA, 其內容跟 AI 的訓練過程有關，採用了由 Google 開源的訓練框架， Ternsorflow, 並且分析了在原先分散式的訓練模型中，資料不論在 CPU/GPU UserSpace/KernelSpace 甚至節點間都有大量的資料複製行為。透過 RDMA 的幫忙減少了這些行為最後證明了整體分散式訓練的時間大幅度縮短，是個非常有趣的短文.

本篇文章是屬於論文導讀系列，這次的對象是Google所推出的Software Network Load Balancer, Meglev. 透過對該論文的研究後可以學習到Google對於一個 Network Load Balancer 的期許以及設計的思考脈絡，並且實際理解其架構來學習到如何設計一個通用(可運行在任意的 Linux Server上), 分散式且易於擴充的彈性架構以及高PPS(Packet Per Second)處理能力的軟體程式。最後透過論文中的實驗與效能評估來觀察實際上 Meglev 的效能以及是否有滿足Google對該軟體架構的期望。

簡述一下 Bash 中檔案導入的一些概念

Introduction

AsyncConnection 此物件代表整個 connection，裡面提供了收送(Write/Read)兩個主要介面供應用層(OSD/MON等)使用外，裡面也處理了整個 Ceph Node收送封包的邏輯處理，這部分比較像是一個 finite state machine(FSM)，當前狀態是什麼時候，收到的封包是什麼，就切換到什麼狀態來處理。

此篇文章主要研究目前很熱門的 scale out storage 軟體 ceph 的網路架構。

Async 希望在與底層kernel socket進行I/O處理時是以 Async 的方式去運行，而不是像 Simple 一樣每條 connetion 都要開兩個 threads 來負責處理 read 跟 write。

延續上篇文章 (Ceph Network Architecture 研究(一))[https://www.hwchiu.com/ceph-network-i.html#more]，本文將繼續探討 Async 這種網路類型底層真的架構與概念，所以本文章也不會有太硬的程式碼解讀，反而會比較偏向概念性的分析。

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.

本文作為 IPVS 系列文第一篇，主要跟大家粗略的介紹 IPVS 的概念以及相關用法，接下來會再仔細的探討一些更深層的概念，譬如實作細節以及一些使用技巧，最後再看看 Kubernetess 是如何與之互動的

本文作為 IPVS 系列文第三篇， 會從 Kernel 作為出發點，探討一下 IPVS 本身的模組概念，分享兩種不同的內建除錯方式，此外也會從原始碼的部分看一下 IPVS 初始化的過程做了哪些事情

本文作為 IPVS 系列文第二篇，主要是跟大家介紹 IPVS 與 Kubernetes 的互動，包含如何設定以及 IPVS 如何實踐 Kubernetes Service 的功能

本文作為 IPVS 系列文第四篇，主要是跟大家介紹 IPVS 於 Linux Kernel 內的架構設計，透過理解其設計更可以幫助我們去瞭解 IPVS 與 IPTABLES 的差異，面對諸如此類的探討文章更能夠有足夠的背景去思考與學習

簡述一下 Kubernets 中 HPA, VPA, CPA, CA 等相關技術的差異

談談 Kubernetes 的世界中如果想要用 tcpdump 抓封包可以怎麼做

本篇文章透過閱讀原始碼的方式來學習 MASQUERADE 的運作模式，而 MASQUERADE 則是被廣為使用的 SOURCE NAT 模組。作為一個 IPTABLES 的擴充模組，透過觀察原始碼的方式可以學習到是如何處理相關的參數甚至，選擇來源 IP 地址以及來源連接埠等相關行為

本篇文章透過修改 MASQUERADE Kernel Module 原始碼的方式來觀察系統的變化，專注於當 NAT 功能執行前後， conntrack 這個結構的改變。透過不同的實驗與環境來觀察 1)多重 IP 的情況下怎選擇 2)指定不同參數時，連接埠的變化。此外為了簡化整體操作過程，將整個實驗環境都透過 Vagrant 打包成為一個可重複執行的環境，並且也準備好可以編譯 Kernel Module 的環境與指令。

本文分享如何透過一些常見的方法或是別人撰寫好的工具來提供一個方便的管理工具，讓操作者可以更方便的再多個 AWS 帳號中進行切換

介紹 NAT Loopback 的概念

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.

探討 NFQUEUE + iptables 結合後丟棄 UDP 封包的問題

記錄一下當 Nginx 搭配 K8s headless 時會出現的 存取問題

本文介紹了一種將 Contaienr 創建於 OpenvSwitch 與 DPDK 整合的網路拓墣下所遇到的連線問題。開頭先闡述了拓墣架構以及相關的軟體版本，接者介紹是如何搭建起整個測試環境，並且在測試環境中遇到了網路連線的問題，眾多的測試組合中，卻只有一種組合能夠正常的在 Container 間建立起能夠傳輸的 TCP 連線。最後透過 AB 測試的方法歸納出一些會造成問題出現的環境。

本文延續前篇文章關於 Docker/OpenvSwitch/DPDK 整合遇到的連線問題，此文章會專注於這個連線問題，從問題發生的原因到如何解決，以及該問題為什麼會在上述的組合中發生都進行一些研究與分析，雖然最後還沒有找到真正造成封包損壞的原因，但是至少也把問題範圍給縮小到 OpenvSwitch/DPDK 上.

探討何謂 RDMA

OS:Linux

簡述一下 Kubernets 中 Descheduler 的概念與介紹

探討 ping 指令的不同實作方式

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

本文透過 IPTABLES/EBTABLES 的規則與 Docker Container 的環境來觀察不同情況下的封包流向，主要是幫線上議程進行的重點整理，主要內容都在影片中。

記錄一下將服務轉移到 Container 上時效能要注意的地方

從 KIND(Kubernetes IN Docker) 中學習到的一些網路小趣聞

簡述一下如何設定 Contaienr Image 讓其可以跳過 Kubelet Image GC 的處理