中文前言: 在使用 Kubernetes 的時候，可以選擇透過 Job 的方式來跑一次性的工作．但是如果希望你的工作在特定時間內一定得結束來釋放資源， 就得透過這個方式． 最近在研究這個的時候，發現有些使用上的小技巧，紀錄一下． Preface: If you want to force to terminate your kubernetes jobs if it exceed specific time. (e.g.: run a job no longer than 2 mins). In this case you can use a watcher to monitor this Kubernetes jobs and terminate it if exceed specific time. Or you can refer K8S Doc:”Job Termination and Cleanup” use activeDeadlineSeconds to force terminare your jobs. How to use activeDeadlineSeconds: It is very easy to setup activeDeadlineSeconds in spec. apiVersion: batch/v1 kind: Job metadata: name: myjob spec: backoffLimit: 5 activeDeadlineSeconds: 100 template: spec: containers: - name: myjob image: busybox command: ["sleep", "300"] restartPolicy: Never In this example, this job will be terminated after 100 seconds (if it works well :p ) Before you use activeDeadlineSeconds If you ever run a job with activeDeadlineSeconds, you will need delete job before you run the same job again. The job...

由於之前”台北開放資料”中的流浪動物資料忽然無法連上，造成之前寫的 Line Bot: 台北流浪動物需要你” 無法正常運作． 只好去找找政府的資料，”動物認領養” 開放資料． (https://data.gov.tw/dataset/9842#r0) 修改好了，希望大家繼續愛用． 如果有過年需要人陪的，可以玩玩看，年後去領養可愛的小毛球家人． 簡單說明: 打任意字會隨機出現動物 打”狗” 或是 “貓” 會出現相關動物領養資料

原文 Scaling Kubernetes to 2,500 Nodes 緣起 最近比較忙碌，都只能夜深人靜才能好好的來閱讀一些文章來充實自己．(公司牛人多到像牧場，只好不斷努力 lol ) OpenAI 最近有一篇技術文章，相當的值得一讀．就是他們分享他們如何管理超過 2500 個節點． 當然我們都知道， Kubernetes 自從 1.6 之後就號稱可以乘載 5000 個節點以上，但是從 數十台到 2500 台的路上，難道不會遇到一些問題嗎? 這篇文章分享了他們遇到的問題，試著要解決與懷疑的地方，最後找到真正的問題．這篇文章適合所有 DevOp 好好的熟讀． 遇到的問題與解決方式 第一次遇到問題: 1 ~ 500 個節點之後 問題徵兆: kubectl 有時候會發生 timeout. (p.s. `kubectl -v=6 可以顯示所有API 細節指令) 嘗試解決方式: 一開始以為是 kube-apiserver 服務器過分忙碌，試著增加 proxy 來做 replica 來幫忙 load balance 但是超過 10 個備份 master 的時候，他們發現問題一定不是因為 kube-apiserver 無法承受．因為 GKE 透過一台 32-core VM 就可以乘載 500台 原因: 扣除掉這些原因，開始要懷疑 master 上剩下的幾個服務． (etcd, kube-proxy) 於是開始試試看來調整 etcd 透過使用 datadog 來調查 etcd 的吞吐量，發現有異常延遲 (latency spiking ~100 ms) 透過 Fio 工具來做效能評估，發現只用到了 10% 的IOPS(Input/Output Per Second) ， 由於寫入延遲 (write latency 2ms)，造成整個效能被拖累． 試著把 SSD 從網路硬碟變成每台機器有個 local temp drive (依舊是 SSD) 結果從 ~100ms —> 200us 第二次遇到問題: ~1000 個節點的時候 問題徵兆: 發現 kube-apiserver 每秒需要從 etcd 上面讀取 500Mb 嘗試解決方式: 透過 Prometheus (一種廣泛用於 Kubernetes 上面作為 Container 資料搜集與監控工具) 來查看每個 container 之間的網路流量 原因: 發現 Fluentd (一個作為資料與 log 轉發的工具) 與 Datadog ，太頻繁來抓取每個節點上面的資料． 調低這兩個服務的抓取頻率，網路效率馬上就從 500 Mb/s 到幾乎沒有… etcd 小技巧: 透過 --etcd-servers-overrides 可以將 Kubernetes Event 的資料寫入作為切割，分不同機器處理．範例為 : --etcd-servers-overrides=/events#https://0.example.com:2381;https://1.example.com:2381;https://2.example.com:2381...

論文原文: The Case for Learned Index Structures Morning Paper Reading: part1, par2 參考文章: arXiv: The Case for Learned Index Structures Morning paper: The case for learned index structures – part I Morning paper: The case for learned index structures – part II

論文原文: The Case for Learned Index Structures Morning Paper Reading: part1, par2 緣起： 剛好最近有幾次機會可以去工研院開會的路上，在高鐵的路途上可以好好的來欣賞這篇文章． 這篇文章是由 Google Brain 的大神 Jeff Dean 連署的論文之一．講的是透過 NN 的方式來讓大家熟知的 B-Tree, Hashing table 甚至是 Bloom Filter 更有效率… 2018 年第一篇好好閱讀的論文，當然要獻給有深度而且相當有趣的這篇文章．The Case for Learned Index Structures ．主要的原因有以下: 這篇是講解一個新的機器學習的新領域（至少是相當有趣的觀點） 雖然有些限制跟品質的降低，但是讓我們對於 AI/Deep Learning 有了一個新領域的想法… 這篇是被稱為世界上最聰明的人 Google Brain 的主持人 - Jeff Dean 的論文( 編按: 這篇 Quora 有許多關於 Jeff Dean 的敘述文，相當的有趣 XD) Jeff Dean 是誰? 快來看他的 Quorahttps://www.quora.com/What-are-all-the-Jeff-Dean-facts - 他看得懂, 也寫 Binary code - 他的 PIN code 是 Pi 末四碼 先講講 B-Tree B-Tree 是大家相當熟知的資料結構，在此僅列出幾個需要知道的． 時間複雜度 \(O(log n)\) (Balanced B-Tree) 需要空間(cache) 代表存多少資訊在 B-Tree ．當資料不在 cache 中，代表需要重新跑一次 re-balanced B-Tree traversal 無法分散式處理 (透過 GPU 來加速) 再來談 Learning Index Tree 回過來講 B-Tree Index 你可以把一個數值輸入 B-Tree ，透過搜尋過後可以傳回一個 Index (可能有 re-balanced)． 換個角度，如過透過 NN (Neural Networking) model 的學習將一個數值輸入後，來預測 (predict) 它可能的索引位置 (index) ．那麼我們就稱這個為 Learned Index 這邊有一些你需要知道關於 Learned Index 的部分: 由於直接運算，所以時間複雜度相當的低: \(O(1)\) 由於透過 NN 來運算，可以很輕易透過 GPU 來加速運算 空間要求相當的少 不像 B-Tree Index 需要一定的空間來儲存目前已知的數值來加速． （根據文章: cache size 128 是最快的) 關於 CDF (Cumulative Distribution Function) B-Tree...

Kubernetes 相當好用，但是要維運的時候最痛苦的事情，就是要打 kubectl 雖然我超愛 Golang ，而且其實我基本的 IDE 都是使用 VSCode ，但是我一定要跟各位好好推薦這個好工具． Vikube.vim 不論你透過 alias 設定成 kc 甚至是 k 還是得要記憶一堆指令 ex: kubectl get pod 其實就算你不是 vim 的愛用者 (畢竟學習曲線太高了) 我還是很推薦你使用這個工具． :VikubeContextList 可以開啟你所有連接過的 K8S 集群，透過 s 來切換你的集群． :VikubeNodeList 可以開啟所有的節點清單，l 可以看到 結點上面的 logs, 可以幫助你除錯（如果有問題) :VikubePodList 可以開啟 pod 清單，當然也可以透過 l 來看 POD 是否有出現問題． :VikubeTop 可以開啟 top 來看各個 POD 的使用量 真的很好用… 再也不用擔心打 kubectl 或是忘記相關指令了 :p