[Podcast 分享] Kubernetes Origin, with Joe Beda

鏈結 Google Kubernetes Podcast: Kubernetes Origins, with Joe Beda Link 前言 聽 Podcast 是我通勤時候最常做的事情,也是讓我可以練習聽力(但是沒練到說?) 的好機會. 這篇是我今天聽到覺得很有趣的事情,本來只想貼到臉書講個幾句,但是想到大家都不想很忙,所以決定幫大家把重點全部摘錄出來.順便介紹一些重要的角色. 聽完這篇才知道 Heptio 真是個很強大的公司,難怪 Dave Cheney 要離開 Atlassian 去那邊 來賓 - Joe Beda Joe Beda, Craig McLuckie 跟 Brendan Burns 是 Kubernetes 當初的三位發起者. 而 Joe Beda 原本更是在 Google 工作過. 曾在微軟 IE 工程師出身的他,後來到了 Google 後就在 Google Talk 與 GCE 的部門開發相關服務. 後來在 Google 期間推動了 Kubernetes 的開源活動.之後離開了 Google 跟 Craig McLuckie 一起創立了 Heptio 一間專門幫忙企業來建置 Kubernetes 服務並且開源了許多有用的 Kubernetes 工具的公司. 話說 Kubernetes 三個發起者到頭來都不是 Google 的人. Joe Beda 原本是 GCE 工程師,後來離開變成 Heptio CTO Craig McLuckie 原本是 Google Group PM 後來變成 Heptio CEO Brendan Burns 很久之前就離開 Google 並且在微軟成為傑出工程師 關於 Heptio 的開源工具 ksonnet: 一個方便部署 Kubernetes 服務的工具 Heptio Ark: 幫助你備份 Kubernetes 與做災難復原的工具 sonobuoy: 一個幫助你檢定你安裝的 Kubernetes 網路設定與基礎設定是否符合基本標準. (後來被 Kubernetes Conformance 大量採用) contour: 一個 Kubernetes ingress controller 用在 Lyft’s Envoy proxy. 這是我們大家熟悉的 Dave Cheney 的主要工作 gimbal: gimbal 是 ingress load balancing platform 可以在多個 Kubernetes 或是 openstack 上面使用 演講內文 這裡我會挑出幾個有趣的問題,將他解釋清楚一點. 為何請到 Joe Beda Kubernetes 在近期剛好歡慶四週年,他們就想找當初的發起人來談談到底為何會有 Kubernetes 這個產品....
繼續閱讀

[TIL] 關於 Omnigraffle 一些相關資源

要做投影片的時候,需要有一個方便畫流程圖的軟體,於是買了 Omnigraffle .希望可以找到許多的已經畫好的框架幫助自己在做投影片的時候有所幫助. 找到一些資料列出如下: Omnigraffle Stencils StencilTown 是一個使用者預先準備好的圖形樣板,可以直接下載後套入使用 AWS Stencils GCP Stencils DevOps Stencils Google Cloud Official Icons 參考這個網站,提供各種格式的 Google Cloud Platform Icons (PPT, Google Slide, Draw.io 甚至是 PNG)
繼續閱讀

[TIL][vgo] (part2) 開始實戰 vgo

目錄: 對於 Version and Go 相關詳解(part1) 開始實戰 vgo (part2) 摘要: vgo 是 Golang 將在 1.11 提出的新功能.提供著套件的管理與版本的控制.上面解釋過相關功能後,這篇文章我們將透過 vgo 實際建立一個簡單的專案.並且解釋相關操作. 資料存放地點 govender/dep/godep 原本套件管理系統,不論是 govendor, dep 或是 godep 都是透過 go 1.5 vendor experimental 裡面的管理方式, 將你的套件存放在 vendor 目錄底下. 存放的方式就是跟 GOPATH 一樣的擺放方式,只是 Golang system 會先搜尋 vendor 目錄底下的原始碼,再去搜尋 GOPATH. 也就是說全部人都是使用同一個套件下面的原始碼. 聽起來或許很美好.但是那是第一層的狀況下,也就是說如果你第二層的套件要去找相關的 source code 仍然會去你的 GOPATH 來尋找,當然你也可以全部包在最上面套件管理系統內. vgo vgo 存放的方式跟一般的套件管理系統不同,由於他不是使用 舊有的 golang vendor 的管理方式,而是將套件分別存放在每個人的系統裡,目錄結構為 $GOPATH/src/v/cache (壓縮過的版本) 別且透過不同的版本與版號來將原始碼 壓縮過後保存起來 . 如同上面保存的類似,這邊 $GOPATH/src/v (Sourecode 版本) 此外,也會在另外一個地方放上 source code 的版本(未壓縮過的版本),這個地方是存放透過 vgo 所下載的部分. 值得注意的是這邊存放的位置也都會根據版好的資訊來分開資料夾,如果沒有特定版號 tag 的話,就會使用 {package_name}@v0.0.0-{date}-{commit_id} 的方式來存放. (e. g. [email protected]) 版號的控管方式 vgo 使用的版號控制是透過 git tag ,而關於他的格式就是依照目前 github 對於 release 的版號規格: 必須為三碼 v0.0.0,第四碼出現會 vgo 抓不到 第一個 v 必須為小寫,大寫一樣會抓不到 後面不能加上其他的敘述,必須為單純的三碼 v0.0.0 . v1.0.0_20180702 就抓不到 可以透過 vgo list -t 套件名稱 來查詢套件的版號 開始透過抓取你的專案 你可以透過兩種方式開始使用 vgo 不論是套用在舊的專案上,或是開啟一個全新的專案. 開啟全新專案 vgo 讓你可以不需要在 gopath下面建立你的專案,但是你需要打上以下資訊. pakcage main // import "github.com/yourname/yourproj" ... 對..你必須要打上一個 build tag // import 某個 remote path 才能讓 vgo 正確抓到資料,正確開始跑. 然後再 touch go.mod 再來開始 import 你需要的版號,就可以. 套用在舊的專案上 將 vgo 套用在已經 Production 的專案上其實也不會有危險,因為他跟 govendor, glide 跟 dep 都是可以共存的....
繼續閱讀

[Golang] Golang buffered/unbuffer channel and pipeline

前提 如何說明一個人 Golang 寫得夠不夠熟練,我大部分都是問 “ 可以請你解釋一下 buffered 跟 unbuffered channel 的差異?” 往往這樣的題目都會問倒一堆人.不是大家對這個語言不熟悉,而是一般人在學習 golang 的 goroutine 的時候,原本就已經很少使用 channel 來管理,更別說使用 buffered channel . 這篇文章,我會稍微提一下 buffered/unbuffered channel 的差異.並且透過最近遇到 pipeline 的問題來討論一下. Buffered/Unbuffered Channel Unbuffered Channel 先講 unbuffered channel ,也就是最基本大家使用的 channel ch := make(chan bool) go func() { ch <- true }() // keep waiting after goroutine run <-ch 這邊是一個最簡單的 unbuffered channel 的案例,這邊需要注意的相關事情. 由於 unbuffered channel 只有一個位置,所以當你已經存入之後. (e.g. ch <- true) 第二個要存入也會卡住(直到第一個 pop 出來) <-ch 會造成 STW(Stop The World) ,才會驅動 goroutine 驅動.也才能導致 ch <- true 才能跑得到.不然會卡死.這也是如果你想在同一個 goroutine 跑 chan push 跟 pop 會沒有作用的原因. Buffered Channel Buffered Channel 顧名思義就是具有多個的 channel,參考一下: ch := make(chan int, 3) //建立大小為 3 的 buffered channel go func() { ch <- 1 ch <- 2 ch <- 3 }() fmt.Println(<-ch) //1 fmt.Println(<-ch) //2 fmt.Println(<-ch) //3 這是一個很簡單的例子,既然 channel 為一個 slice ,當然也可以 iterate 。 ch := make(chan int, 3) //建立大小為 3 的 buffered channel go func() { ch <- 1 ch <- 2 ch...
繼續閱讀

[TIL][Kubernetes] 開發一個 Kubernetes Secret 相關應用筆記

前提: 通常在 Kubernetes 裡面要將設定檔寫入的方式有兩種: 當資料不敏感(具有保密資料) 的時候,我們會使用 ConfigMap ,當你要儲存比較敏感的資料 (service account, password, 私密資料) 就要使用 Secret 簡單介紹 Kubernetes Secret: Kubernetes secret introduction from Evan Lin 不囉唆,看之前整理好的投影片. 不分類小筆記: Secret 設定相關: Kubenetes Secret 無法在 Entrypoint 就讀取到,必須等到 POD 跑起來後執行. 如果要透過 Secret 來讀取 Kubernetes service account 的相關設定,建議跑在 Command, Args 裡面設定. Kubernetes 執行 Commands 與 Args: Kubernetes yaml 的 ARGs 主要拿來跑參數用,如果想要作為 command 跑 sh 的內容,要使用 && 就不能分散在 Args 之中. 如何透過 Secret 處理敏感資料 (密碼, Key, Kubenetes 設定文件) 如果要將敏感的 json data (configuration, service accoutn, password config) 寫入 secret volume 可以透過 base64 來 encode 透過 base64 encode 的 Secret 資料,不需要再跑 decode .可以直接在 Pod 裡面讀取.
繼續閱讀

[TIL][makefile] make file 進階用法 (Secondary Expansion)

問題敘述 我有下列的服務要透過 make file 來編譯 Dockerfile ,由於那些服務有版本的區別,而且不同的版本都需要同時存在. 也就是說 app:v1 跟 app:v2 必需要同時能存在,並且要能夠讓 make file 能夠支援新的版本 app:v3 的產生. 舉例來說,我之後只要輸入 make build-images 就要能夠自動跑出 app1-v1, app1-v2, app2-v1 並且能夠根據這些 build target 自動 build 相關的 docker image build app1 v1 Dockerfile v2 Dockerfile app2 v1 Dockerfile 如何得到 build target 首先我們要能搜集所有的 build targets ,透過一系列的 build target 再來跑相關的 make process. BUILD_DOCKERFILES := $(sort $(wildcard build/*/*/Dockerfile)) 這一段是找到所有具有 Dockerfile 的檔案.. 在這裡會找出… build/app1/v1/Dockerfile build/app1/v2/Dockerfile build/app2/v1/Dockerfile 這時候我們要做一點小處理,要去除 Dockerfile 這個不需要的檔案名稱.這個要透過上一篇提過的 % 來處理. 快速講解一下,下面的例子是說,不論何種字串只要是 xxxx/Dockerfile 都會被取代成 xxxx BUILD_DIRS := $(patsubst %/Dockerfile,%,$(BUILD_DOCKERFILES)) 這時候 BUILD_DIRS 就會轉換為: build/app1/v1 build/app1/v2 build/app2/v1 再來,我們要整理成 build-app-v1 的格式,這個可以透過 subst 來替代 BUILD_APP_VER := $(subst /,-,$(BUILD_DIRS)) 這樣就會得到: build-app1-v1 build-app1-v2 build-app2-v1 最後,我們要其轉換成 app1-v1, app1-v2 … 一樣透過 % 來替換 BUILD_NAMES := $(patsubst build-%,%,$(BUILD_APP_VER)) 最後我們要得到 build target 希望是 build-app1-v1, build-app1-v2… BUILD_TARGETS := $(addprefix notebook-image-,$(BUILD_NAMES)) 這樣就可以得到我們要的結果. 最後整理一下… BUILD_DOCKERFILES := $(sort $(wildcard build/*/*/Dockerfile)) BUILD_DIRS := $(patsubst %/Dockerfile,%,$(BUILD_DOCKERFILES)) BUILD_APP_VER := $(subst /,-,$(BUILD_DIRS)) BUILD_NAMES := $(patsubst build-%,%,$(BUILD_APP_VER)) BUILD_TARGETS := $(addprefix notebook-image-,$(BUILD_TARGETS)) 開始撰寫 build target 本體要做的事情 這時候因為我們得到 build-app1-v1, build-app1-v2 跟 build-app2-v1....
繼續閱讀