k8s in 5 minutes for Windows 10

前一陣子看了 William 大的 k8s in 5 minutes 之後,才發現原來要在本機跑 Kubernetes 不用再裝 minikube 了,尤其是在 Windows 環境下,要玩 k8s 還得要有特別的安裝方法,這讓我們這些用 Windows 當成日常環境的人總有些不得其門而入的感覺,現在 docker for desktop (下載時可能會叫做 Docker for Windows) 原生支援 k8s (本機版)之後,對於想要很快的看看 k8s 是啥的 Windows 使用者算是個很好的入門磚。

其實 5 分鐘所有的步驟都和 William 大寫的差距很小,只有小部分 Windows 環境下該注意的事項,但小弟資質駑頓,記性太差,還是寫清楚些以便日後參考:

  1. 要先啟用你 Windows 下的 Hyper-V (對 Windows 家用版就別試了)
  2. Docker for Windows 版 (現在也沒有所謂的 Edge 版本了)
  3. 如果你之前有裝過 minikube 的話,記得把 Kubernetes 的環境從 minikube 改成 Docker for Windows
    01
    02
  4. 在我的機器上 kubectl.exe 看來沒有加到搜尋路徑下,請自行加入 (我的安裝路徑在 C:\Program Files\Docker\Docker\resources\bin),不然就切換到該目錄下:
    C:\> cd C:\Program Files\Docker\Docker\resources\bin
  5. 裝個 k8s dashboard (非必須)
    C:\> kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/master/src/deploy/recommended/kubernetes-dashboard.yaml
  6. 把 proxy 跑起來,跑起來之後不能關掉這個視窗,得另外開一個命令列視窗出來繼續,
    C:\> kubectl proxy
    Starting to serve on 127.0.0.1:8001
    ...

    跑起來之後你可以用瀏覽器開下列網址存取 dashboard 來:

    http://localhost:8001/api/v1/namespaces/kube-system/services/https:kubernetes-dashboard:/proxy/
  7. 開另外一個命令視窗把範例裡的 echo-server 裝起來:
    C:\> kubectl apply -f https://raw.githubusercontent.com/coder-society/kubernetes-with-telepresence/master/echo-server/echo-server.yaml
  8. 最後一個步驟和 William 大的不一樣,由於 telepresence 這個工具在 Windows 下執行會有問題,所以用瀏覽器透過 proxy 的方式來測試這個 echo-server (其實這裡我卡了很久… 因為第一次用 k8s,才發現 William 大用了這個 telepresence,而 Windows 下這東西目前又跑不起來)
    http://localhost:8001/api/v1/namespaces/default/services/http:echo-server:/proxy/

    由於我們沒有指定 echo-server 的 namespace,所以這個服務會被放在 default namespace 下,與剛剛的 kube-dashboard 的 namespace 不同,一開始我搞錯也是卡很久

  9. 這個 echo-server 的功能看起來很簡單,就是 show 出目前是從哪台 server (k8s 的術語叫 pod) 跑出來的,你每次 refresh 一次,就會換一台 pod 來跑
    03
  10. 也可以看一下 k8s-dashboard,網址在剛剛啟用 proxy 之後有 show:http://localhost:8001/api/v1/namespaces/kube-system/services/https:kubernetes-dashboard:/proxy/
    04

同事 J 問我說這個 Docker for Windows 是不是開一個 Windows node 出來,仔細看了一下應該不是,它會在你的 Hyper-V 下起一個 Linux VM,所以要試 Windows node 的還是得等等其他人的文章了

05

06

其實昨天剛好有和一位 Google 的業務員聊到天,她自己認為 k8s 改版的速度實在是太快了,有些舊東西淘汰了、新東西加進來之類的都沒人知道。例如這一本台灣有的翻譯書:Kubernetes 使用指南,用到的是 k8s 1.0,裡頭講到的 Replication Controller 在新版本裡都改用 Deployment 和 Replica Set 了,現在去 Google 開一個 k8s cluster 也預設是 1.9.7 了,照著書來做大概只會覺得常常都對不上台詞吧。就算去翻對岸的簡體紀念版:Kubernetes 权威指南(纪念版),出版時也只是 cover 到 1.6 版,更遑論 k8s 官方的網站上已經放了 1.12 版讓人下載了,所以要學這個除了得花時間之外,手腳還得快一點,現在(2018/11/07)拿著最新的簡體中文書可能還對得上環境,可能再過幾個月又得另外找書或文章來學了。

Project Honolulu 是個免錢又大碗的東西嗎?

前幾週聽了 Weithenn 大介紹的 Windows S2D 和 Docker 之後,對於他提到的微軟免費工具 – Project Honolulu 很感興趣,聽來是號稱 MS System Center 的免費版本,這立刻讓我腦海中想到了諸如自動化升級、VM服務自助化或是什麼工作流程自動化一類的,心裡想說微軟終於是佛心來著,便馬上填了些資料下載來玩。

下載和安裝本身並不複雜,雖然它有三種部署的方式,但由於我的目的只是看看這東西有什麼功能,所以變直接安裝在我的 Windows 10 NB 上,這部分的安裝過程沒什麼困難性,一下子也就完成了。

倒是準備要被 Project Honolulu 「管控」的機器還有些特殊需求,除了至少要是 Windows 2012 R2 以上的版本外,還得裝上 Windows Management Framework (WMF) 5.0 以上的版本(網站上給的安裝連結是 WMF 5.1),由於安裝完畢之後需要重開機,如果你的環境剛好沒有符合需求的機器,又不能輕易重開機的話,可能會跑不下去。安裝 WMF 5.1 的時候有個小插曲,就是我找了三台 Windows 2012 R2 ,每一台都告訴我這個安裝檔並不試用於我的環境,最後搞了老半天,原來我一直下載到的是一個叫做 W2K12-KB3191565-x64.msu 的安裝檔,但試用於 Windows 2012 R2 的安裝檔是叫做 Win8.1AndW2K12R2-KB3191564-x64.msu,這種蠢事我也是 Google 之後才發現的,顯然微軟這種命名方式騙到我這種蠢蛋了…

Project Honolulu 會在本機裡裝個小型的 Web server ,裝好之後直接點開始功能表就會把網頁給打開了,一打開來,我優先去點擊的這個功能:

01

嗯,Windows Update,怎麼這麼熟悉? 按下 Install Updates 按鈕之後跳到下個頁面:

02

嗯… 還是很熟悉的畫面… 什麼?! 這該不會就是 Project Honolulu 的功能吧? 完整的把本機上的系統管理功能、設定功能給搬到 Web 上讓我們可以「遠端 GUI」作業,真的是這樣子嗎?讓我再擷取幾個畫面看看:

03
這是我自己 NB 的監控畫面,這… 不就是工作管理員

04
看得出來可以管理四種標的,後面的 Faliover Cluster 和 Hyper-Converged Cluster 我目前沒有,選個 Server Manager 看看:

05
要檢視某一台 Server 之前,要先等系統跑一下子

06.jpg設定畫面,原本以為可以在這裡設定報警條件的,結果原來只能設定環境變數

07.jpgEvent viewer ?! 事件檢視器,一模一樣勒

08.jpg
防火牆設定,就是防火牆設定

09.jpg這個稍微有新意一點,Web 版本的遠端 Power Shell,有了這個就表示什麼功能都可以自己刻了吧?

10
放大絕了啦,Web 版的遠端桌面,Project Honolulu 還有什麼做不到的?

唯一的一點點小缺憾是目前沒有在 Project Honolulu 裡看到 IIS Management 的操作功能,不知道是還在製作中或是沒打算做(反正 Power Shell 都可以做到),除了 IIS 之外,其實還有許多 Windows Server 的管理功能沒有被實做上去,這篇 FAQ 裡有完整的支援/不支援清單。

所以簡單做個總結,Project Honolulu 像是個 Remote Desktop Manager + Computer Manager 的綜合升級版,其中一種部署方式是可以把 Server 部署在跳板機上,然後系統管理員便可以從真正的遠端透過瀏覽器進行系統管理。由於可以事先把受管理的 Server 清單建在系統上,機器多的時候要找也是方便了一點,所以要說是簡化了系統管理程序也未嘗不可啦,不過要說是像 System Center 一樣能簡化資料中心的管理嘛,倒是差了那麼一大截。唯一可以理解的是:Project Honolulu 所依賴的底層 WMP 5.1 應該已經可以含括到 Windows 系統管理的許多功能了,所以除了微軟自己的 System Center 之外,應該也可以期待會有 3rd party 開發出諸如自助化服務網站的功能出來,或是自己想辦法刻出來?

11.jpg
目前我使用的 TP 版本是 1711,雖然我也只是玩一玩試一試,但可以感覺得出來這東西並沒有明顯的狀況或當機之類的問題,應該可以算是很成熟的東西了,只是我之前對它的期望太高,試用之後不免有些空虛就是了。

比威而鋼還威的 TCP BBR

前一陣子從 iThome 看到了 Google 要把 TCP BBR 應用在 Google Cloud Platform 的新聞, 才發現原來這東西這麼神,2700 倍的傳輸率,佇列延遲減少 25 倍,隨手翻了下網路上的部落格,沒想到有那麼浮誇的說法證明:下載從 84K/s 變成 3.9M/s,這立刻引起我的好奇心,找到了 Google 自己的部落格說明,原來是長久以來使用的 TCP 壅塞控制演算法有點笨,遇到有 packet loss 的狀況時,就會以比較保守的方式來傳遞接下來的封包,而新的 TCP BBR 則用了比較聰明的方法來處理 packet loss 的問題,整個示意圖就如下所示:


* Source

文中也特別拿了幾個國家為例子,說明在應用了 TCP BBR 之後,YouTube 的表現情形,不看還好,一看之下,沒想到 Google 也這麼浮誇寫實,YouTube 到 ID 的 Max Round-Trip time 竟然可以改善到 50% 以上,這讓我突然想到以前公司在進行某個網路直播專案時,那個爛 4G 網路讓我們驗收時吃了很多苦頭,所以我也來做個浮誇的測試好了。不過因為一來我很懶,二來也沒那個預算搭建回當初專案的原始架構,所以以下浮誇的測試只在我的本機上實驗。

  • 實驗環境 (都在同一台機器裡):
NB: OBS Studio 19.0.3 --> NB: clumsy-0.2 --> VM: SRS 2.0.242 + CentOS 6.9 --> NB: flv.js in Chrome
  • 實驗方法:
  1. 先以 Kernel 2.6.32-696.6.3 直接測試,擷取螢幕看直播視訊延遲
  2. 以 clumsy 加上 inbound & outbound 各 50ms 的延遲,並隨機 drop 10% 的封包
  3. 等個幾秒,擷取螢幕看直播視訊延遲
  4. 停止 clumsy,等個幾秒,擷取螢幕看直播視訊延遲
  5. 升級 Kernel 為 4.13.0-0.rc1,重複步驟 1~4
    * 我拿了一個 Firefox 開時鐘來讓 OBS 擷取螢幕畫面,所以測試畫面中會看到 Firefox
  • 實驗結果:
  1. 沒 TCP BBR,不啟用 clumsy,延遲大概 3 秒
    Without BBR - normal network
  2. 沒 TCP BBR,啟用 clumsy,稍等一下,延遲變為 13 秒,實測時這個延遲會迅速擴大,最差的狀況是影像會停掉
    Without BBR - bad network
  3. 沒 TCP BBR,把 clumsy 關掉,稍等一下,延遲回到 5 秒左右
    Without BBR - normal network again
  4. 有 TCP BBR ,不啟用 clumsy,延遲大概 2-3 秒,其實和沒 BBR 時差不多,這畫面看起來延遲只有 2 秒應該只是個測試誤差
    With BBR - normal network
  5. 有 TCP BBR,啟用 clumsy,稍等一下,延遲變為 4 秒
    With BBR - bad network
  6. 不信邪,再等一等,有 TCP BBR,啟用 clumsy,延遲還是維持 4 秒左右
    With BBR - bad network-2
  7. 恢復原狀,有 TCP BBR,不啟用 clumsy,延遲還是維持 4 秒不動
    With BBR - normal network again

總結來看,這個 TCP BBR 還真的神,在高延遲且掉包的網路上,在我的測試環境 1 個 client 對 1 個 server 的情境下就能有這麼好的表現,安裝的方法我就不特別提了,網路上隨便 google 都一堆,不過還是要提醒大家一下,再好的東西還是得先測試才能上正式環境,免得哪個不小心你就踩了坑了都不知道。

BBR Summary

玩一下 Google Compute Engine 要花很多錢嗎?

雖然身為一個 IT 人,也知道這一行要與時俱進不然就被淘汰的道理,但是我個人對於「在雲端上花錢」這件事情的態度算是偏向保守的那一派,像是 LINE Pay 已經出來半年了,我是為了貪那繳稅的回饋金才去辦卡且綁定了我的 LINE 帳號,Google Play 上就算有需要綁定過信用卡,也是用完之後就移掉,不然我自己會想像被他亂收錢。

這次之所以會想要在 GCE 上花錢,是因為看了某個對岸網友的文章,發現 Google 竟然直接在他的 GCE 上提供 Anycast IP + Global Load Balancer + CDN 的服務,因為這實在是太狂了,所以我忍不住就打破了自己的的風險規則,跑去把我的信用卡放上去。

我測試的東西也就是 Anycast IP –> With CDN –> Load Balancer –> 一台台灣 VM + 一台新加坡 VM 這樣子的架構,測試之前先在我自己電腦上的 VM 跑了一次,並且把安裝與設定步驟記錄了下來,所以去 Google 上開機器時,除了幾個 Google 自己的設定需要實驗多花了點時間之外,大致上可以說是沒幾個小時就做完相關的設定工作,然後就開始測試了。之後就放那邊放了兩天,端午節之前把 Anycast IP, CDN, Load Balancer 及新加坡機器關掉,只留下台灣這台 VM 給同事測試用 (對,我實際上的需求並沒有一定得要用 Anycast IP,只是拿來試試看功能而已),這樣子我一共花了多少錢呢? 才 US$1.96

1

而且 Google 也提供了一個預算管制的功能,當所花的錢超過你設定的預算時,就會發警示信出來。因為我拿來玩 GCE 的帳號就是我平常在用的 Google 帳號,也綁了我的 Android 手機,所以這功能讓我很安心的繼續用下去。

2

前一陣子不知道是哪位臉書上的心得,說是微軟 Azure 要和 Amazon AWS 或 Google GCE 對打還是走得很辛苦的。對照一下這幾年來看到 Google 在做的事情:Google 自建海纜、GCE、Anycast IP on GCE、Google CDN (如果 Google 要把他們在世界各個 ISP 放的 Google Global Cache 也拿來做 CDN 加速的話,那就更恐怖了),可以看到 Google 要做而且已經快做到的是「世界」的 IT Infrastructure – 全世界的中華電信、全世界的 Hinet,這意思是什麼呢?如果你今天只想做台灣的網站也就算了,如果你是想搞跨國的網路應用(電子商務、遊戲、社群、直播…),以後你也不用多想了,就直接放 Google 上就好了,如同幾年前的台灣一樣,大家想搞網路、搞遊戲,機房鐵定要選中華電信、專線一定得拉 Hinet,因為全台灣的使用者幾乎都是用 Hinet,想不接 Hinet 線路就是要讓使用者 lag 爆。這種事情以後就會反過來,大家要在全球佈局的話首選就會是 Google,因為最簡單速度又最快。

所以,學學這些 Public Cloud 的使用經驗看來就是未來 IT 人的必備技能,而且搞不好還比去學什麼 Server 安裝或 Cisco 設備操作要來得基本且必要,要練習這些東西很花錢嗎?你要練 Server 安裝、系統管理之類的可能要去買台機器或借個環境才能操作,想練網路我看很多人會花個幾千塊去網路上買二手設備來練習,但是想練 Google Public Cloud? 以我這次的例子來說,只要 1.96 鎂就好,可能比很多人一天的通勤費用還便宜些,好東西,不買嗎?

在 Windows 上使用支援 edns client subnet 的工具 – dig 9.11

之前提到了說 BIND 會從 9.11 開始支援 EDNS client-subnet,所以若你的 BIND 已經開始使用 GeoDNS 的功能,恰好你的 end user 用的 DNS server 也支援 EDNS client-subnet 的話 (eg. Google DNS 就支援),那恭喜你,你的 GeoDNS 的效果應該會變得更加顯著。

但實際把功能丟上去之後,你就會發現有事沒事的你會遇到使用者抱怨他連你的網站速度太慢,原因是因為你的 GeoDNS 回給他的結果和你預期的不同,原本你想要 GeoDNS 丟個離日本最近的 IP 給他,但他拿到的卻是個英國的 IP。這時候我們就需要個可以快速驗證 GeoDNS 設定是否正確的工具了。

這工具其實也很簡單,因為就是隨著 BIND 9.11 一起更新的 dig 命令,只是以前我笨笨的,以為 BIND 只有出 source code,自己又沒種花時間去 Windows 下建立編譯的環境,所以都是去抓別人編譯好的執行檔,自己都覺得有點不是挺安全的,不過剛剛仔細一瞧,原來 ISC 自己的官方網站上就放了 BIND 的 Windows 版,只要下載之後安裝也就可以用了…

01

安裝的時候只要選擇「Tools Only」就好,我想大家也不想在自己的電腦裡裝個用不著的 BIND Server

02

裝好之後,如果你像我一樣對自己用的系統有一點潔癖的話,可以把目錄下的這些檔案(除 BINDInstall之外)拷貝到你喜歡的目錄,剩下的東西則可以全部移除。

03

dig + EDNS client-subnet 的使用方法也很簡單,就是

dig [domain name you want to query] @[DNS Server] +subnet=[addr]

http://www.google.com 為例,如果我是個位於美國的使用者,IP 是 128.32.203.137 (我隨便抓了個柏克萊大學的 IP 來測試),解析出來的會是 172.217.5.100

04

那如果我是個台大的學生,IP 是 140.112.8.116 的話,解析出來的會是 163.28.18.30 (左右…)

05

我自己現在用的是遠傳的網路,從 ping 的結果看來,Google 應該也是有應用 GeoDNS 來加快網站的速度(當然也用了 BGP anycast,但不在此文討論範圍)

06

最後,更笨的是,如果你什麼都不想裝,就用別人放在雲端上的服務就好了…

https://tools.keycdn.com/dig

 

OpenStack – Failed to connect to server (code: 1006) issue

最近在OpenStack的lab遇到了無法使用console的問題

情況如下,當環境中只架設一台controller node時,console 可以正常使用

不過當controller node增加到2台以上時,console就會無法使用

以下為錯誤畫面

Failed to connect to server (code: 1006)

2016-11-01_001459

後來問過Google大神才知道,當架設多台controller node時會因為每台controller node對instance的token都不同造成驗證失敗,使得console無法使用

解決的方法就是在nova.conf中設定memcache servers來存放token

設定如下:

[cache]

backend = oslo_cache.memcache_pool

enabled = true

memcache_servers = controller1IP:11211,controller2IP:11211,controller3IP:11211

3台controller node都設定完並重啟nova-consoleauth service,就可以正常使用console了

RAID Scrubbing / Data Scrubbing

最近因為追某個錯誤,追到了辦公室的 Synology NAS 上,才發現這個名詞:「RAID Scrubbing」,標準的叫法應該是「Data Scrubbing」,查了幾份文件 (1)(2) 之後,都說這是使用 RAID 時的必要的定期維護工作,還提到而家用硬碟建議每週都做一次,而資料中心用的 RAID 建議每月都做一次,不然可能會有資料遺失的風險?!

乍看之下我嚇了一跳,因為印象中我們從來沒做過這個動作,當時我立刻覺得公司的資料正陷入極高度的風險中,不過稍微看了一下 Wiki 上的介紹之後,發現 Dell 的 RAID card 本身就支援所謂的 patrol read 功能,效用等同於 Data Scrubbing,頓時讓我鬆了一口氣,但身為一個工程師, 就是要追根究底一下,不然還真不能百分百的放心,而且還可以藉此練一下肖喂:

  1. 關於 Dell 的 RAID card 部分:
    • 根據 Wiki 下方的註解,Dell PERC 6 或 PERC 6i 有個叫做 Patrol Read 的功能,效用相等於 Data Scrubbing
    • Dell 網站上也提到這功能預設是開啟的,而且每七天會跑一次
    • 對照一下正在使用的 Dell R720 (使用 PERC H710 RAID Card),在 BIOS 當中的確有這個選項,且預設值是 Auto,所以這裡算是可以安心了
      1
  2. 關於 Synology,還的確得要做 RAID Scrubbing,但是,這個動作要花費的時間真的非常久(不知道和 Soft RAID 有沒有直接關係),像我花了三天時間對一個 22TB 的 RAID 6 做,目前的進度也才 45.3%
    2

Dell 對於 Patrol Read 的說明上有個補充項目,意思是這功能不會對 SSD 執行,我猜想是 SSD 本身的控制器就已經自帶 error detection / error correction 的功能,所以就不用靠 Data scrubbing 這個動作來預防可能有硬碟壞軌或 RAID 寫入不完全的錯誤。