[TIL] Summarize about Mesos and Kubernetes
A slide to summarized some features comparison about Mesos and Kubernetes.
這篇投影片整理了 mesos 與 Kubernetes 的一些比較． 內容有包含:
- 這兩年的發展
- 基本架構圖
- 整理最久的就是近兩年的版本功能發表的時間軸
希望能幫助一些人
Blog E
Attitude is everything
A slide to summarized some features comparison about Mesos and Kubernetes.
這篇投影片整理了 mesos 與 Kubernetes 的一些比較． 內容有包含:
希望能幫助一些人
Kubernetes 在設計上有著相當程度的擴充性，在當初有 plugin 的架構就可以看出來． 比如說: Network Plugin 讓 CNI 可以輕鬆地整合． 1.8 版剛開放 alpha 的新功能 “Device Plugin” 更強，可以讓 GPU, 高效能網卡, FPGAs 甚至是 InfiniBand 輕鬆的整合在 Kubernetes 之中
原本在 Kubernetes 內預設只能抓取到 CPU 與 Memory 的狀態（不然，就得很辛苦.. 你懂的) 但是透過了 Device Plugin 你就做以下的事情:
有興趣的可以再看看 Kubernetes 文件: https://kubernetes.io/docs/concepts/cluster-administration/device-plugins/
本來就想把 Deep Learning 學一下， 因緣際會下看到這一篇 Coursera 學習心得 試讀了七天，除了提供 Jupyter Notebook 之外，作業也都相當有趣，就開始繼續學了． 目前進度到 Week2 相當推薦有程式設計一點點基礎就可以來學．裡面的數學應該還好． 學習的過程中還可以學會 Python 裡面的 numpy 如何使用，因為裡面主要就是要教導你如何使用 numpy 來兜出 Neural Network ．
我必須得說，最後這個 Jupyter Notebook 真的太有趣了…
由於這次課程不會用到比較複雜的 NN (Neural Network) 套件，而是直接使用 numpy 來打造一個 NN ，這裡有不少的 numpy 教學部份．有提到一些類似於:
import numpy as np
a=np.random.randn(5) 產生出來不是一個具有 transporm matrix 的 array 而是一個 a.shape = (5,)
a=np.random.randn(5,1)assert(a.shape==(5,1)) 作為檢查，確認沒有漏打．import math
def basic_sigmoid(x):
sig = 1 / (1 + math.e ** -x)
return sig
由於 math 不能直接處理 array ，要改成 numpy
import numpy as np
def np_sigmoid(x):
sig = 1 / (1 + np.exp(-x))
return sig
x_norm = np.linalg.norm(x, axis=1, keepdims=True)
normalize_x = x/x_norm
def softmax(x):
exp_x = np.exp(x)
sum = np.sum(exp_x, axis=1, keepdims=True)
s = exp_x/sum
return s
針對 vector 比較大量的時候，其實 numpy 的效能反而比起直接透過 for-loop 來運算快得多．並且整個代碼都清楚多了．
def l1(yhat, y):
loss= np.sum(np.abs(y-yhat))
return loss
def l2(yhat, y):
loss2= np.sum(np.dot(y-yhat, y-yhat))
return loss2
記住 np.dot 是將兩個矩陣相乘，所有要求平方就是自己跟自己相乘．
# GRADED FUNCTION: propagate
def propagate(w, b, X, Y):
m = X.shape[1]
A = sigmoid( np.dot(np.transpose(w),X) + b ) # compute activation
cost = -1 / m * np.sum( np.multiply(Y, np.log(A)) + np.multiply(1-Y, np.log(1-A)))
dw = 1/m * np.dot(X, np.transpose(A-Y))
db = 1/m * np.sum(A-Y)
assert(dw.shape == w.shape)
assert(db.dtype == float)
cost = np.squeeze(cost)
assert(cost.shape == ())
grads = {"dw": dw,
"db": db}
return grads, cost
Pieter Abbeel 是處理 Deep Reinforcement Learning 的專家，這篇有提到他如何進行相關研究．
最近看的文章之中，這篇文章相當適合推薦給大家．不論你已經是軟體架構師，或是你正想將你的專業領域網軟體架構師來邁進，都建議來看一下．
其中的許多部分加入了我個人的經驗與觀點，請觀看時斟酌思考，如果有錯誤的部分，歡迎提供任何意見．
身為一個軟體架構師，最重要的兩個能力如下:
以下開始解釋這兩種能力的細節，以及為何需要這兩種能力．
裡面建議在勾勒出整個軟體架構的時候必須要有的幾個面向為:
以下開始逐一解釋每個細項的部分
這裡解釋一下，所謂的”非功能面需求” (non-functional requirements) 一般指的就是跟功能本身無關的需求，比如說： 系統的反應速度，系統容納上限，是否有 HA 與 Fault-tolerance? ．
要針對功能面向來定義與管理比較容易，要有相當的經驗的人才能了解 non-functional requirements 的重要．
在設計軟體架構的第一個面向應該馬上將功能面以外的需求加以管理，並且確認清楚，不要讓該需求無限擴張． 比如說你的系統如果不需要 24x7 的營運保證，或許就可以讓他有系統更新與修改的時間與機會．或是可以釐清究竟需要多少的連線速度．
當你透過管理而清楚地條列出非功能性需求後，你對於整個系統的效能與容錯率有了一個定義與概念．
接下來就是要定義出你的軟體架構，不論是透過將原先已經有的軟體架構加以修改，或是重新定義出一個軟體架構．
如何選擇你的架構，主要有以下的考量點:
每一個係項都是需要好好思考的問題，你思考的越多在技術的選擇上就會有更多的考量，自然之後就更不容易有遺漏的地方．
關於評估(evaluation)，這裡有兩個面向:
不論是功能性的需求或是非功能性的需求(Non-Functional Requirement)對於系統架構的建置評估上，都是具有相當風險．
再評估系統架構上，我們可以透過各種的分別的服務壓力測試來給予我們足夠的信心來評估我們的系統架構． 比如說，在決定 Message Queue 系統架構時，可以考量 Kafka, Redis, 或是其他 MQ 給予的壓力測試數據，加上該系統可以裝載的資訊類別來評估是否符合你的系統設計．
所以根據前面的範例，在設計上我們都會先“假設” Kafka 能夠符合你的系統設計需求再來查看 Kafka 的可以乘載的資料類別與限制，加上他的壓力測試數據．來”證明“系統架構上是可行的．
一個好的服務架構往往需要跨組織，跨區域性的合作．很多時候需要許多系統內部甚至是外部的參與者的合作才能造就整個系統的穩定與完整． 比如說：
所以，這時候良好的文件與溝通就無法省略．雖然不容易，但是這是一個很軟體架構師重要的工作職責，確認讓所有的合作夥伴能夠無縫的溝通與合作．
如何能夠將軟體架構交付出來的部分，也有列出以下幾個所需要的能力：
這幾個項目其實在這幾年的專案管理過程中，不斷的有運用到所以相當推薦這些項目給軟體架構師．
身為一個好的軟體架構師，你的軟體架構要能夠被交付出來．這時候，你需要：
這兩個部分相當的重要，舉例而言： 如果你要打造一個反應速度相當迅速的電商平台，那麼團隊中的夥伴們都要能夠清楚的體認這個大方向的概念，才能避免在一些細節上做出會讓整體效能延遲的決定．
在軟體專案進行的時候，身為軟體架構師也要能夠適時地展現你的領導能力．需要透過參與實際的專案運作，了解每個成員目前的狀況，開發是否有任何困難．並且適度的扛起責任，當團隊成員有任何疑慮或是需要抉擇的時候做出許多的決定．
在軟體開發流程上教導與指導雖然是有些過度干涉的成分，但是身為軟體架構師要能夠在架構的討論上，對於團隊有足夠的教導與指導．不是針對團隊面對的程式邏輯的問題，要能夠處理系統相關與設計架構上可能造成的效率取捨．對於架構流程上的教導，並且指導團隊方向引領到正確的設計方向．
不論是哪一種完美的軟體架構都有可能因為交付的品質而毀於一旦，品質的確保就相當的重要．這裡分享以往在軟體開發的經驗，就是要能夠仔細地將足夠的測試資源投資在正確的地方．比如說： 你的系統是電商系統，那麼你就必須要有足夠的安全性測試，然後再投資到使用者的使用流程．
你是一個親自參與(hand-on)的軟體架構師嗎？ 許多公司不會讓軟體架構師參與整個開發的流程，因為他們太珍貴．在作者的建議裡面，這不是一個好的態度．一個好的軟體架構師必須要能親自動手做，要能夠在團隊裡面了解相關的程序，做出必要的貢獻．
然後親自參與也不是要軟體架構是必須要把所有的時間都花在代碼的編寫上．親自下來參與並且了解整個專案建置的流程也是很重要的．
軟體架構師不是一個就達成的職業，他需要不斷的參與軟體的開發流程，並且具有實際動手做的能力與毅力． 要能檢視自己是不是足夠的軟體架構師，就要能不斷的檢視自己的每個實作的能力與對於系統的透徹程度．
之前在網路上有個有趣的討論，究竟前端工程師需不需要了解演算法．這就讓我思考到，一個好的專案管理人員與一個好的軟體架構師到底需不需要自己下來動手做？ 答案當然是肯定的，不斷的參與專案的開發流程，並且適度的參與是軟體開發人員必備的能力．
Keep coding….
(Image: Coolshell)
接續前文， Bloom Filter 深入討論
Bloom Filter 快速的搜尋索引結構，具有以下優點:
缺點:
為了要解決刪除節點需要重新建立整個 Bloom Filter 的缺點， Counting Filter 就因為這樣而產生．
原先 Couting Filter 藉由增加一個資料欄位來讓 Bloom Filter 無法刪除資料點的限制去除．但是卻又因為每個節點需要增加一個資料欄位而讓空間使用上變得相當沒有效率．
空間的利用率上，根據這篇論文提到． 你可能需要使用到 3~4 倍的空間使用率來維持相同的 False Positive Rate ．
主要是因為要能夠符合 dynamic deletion 這個條件限制，所以在插入資料的時候會選擇 \(k\) 的個數來插入你的資料． （也就是一份資料 duplicate 到 \(k\) 份）
原因如下：
在這裡列出一些符號如下:
之前的 Bloom Filter 對於 \(k, m, n\) 的限制: \(k ≤ (ln2)m/n\) ，所以式子可以改成:
\[P( (max)_i c(i) >= j) <= m ((e ln 2)^j/ j)\]所以如果 counter \(i\) 是 4 個，那麼 \(j\) 就得 16 才能滿足以上的式子．
透過這樣的方式來計算，大概需要 3~4 倍的空間複雜度，來滿足原先 Bloom Filter 的條件．
在提到更多的 implement 的過程中，我們先來查看整個 cuckoo filter 的優點．
(image from paper “Cuckoo Filter: Practically Better Than Bloom”)
這一張列表清楚列出 Cuckoo Filter 的優點．可以看得出來， 以下稍微做個條列式:
Cuckoo Filter 的原理相當簡單:
footprint 來計算每個資料的特徵值（作為插入節點用得值），再次要注意一下， footprint 的存在使得 Cuckoo Filter 的 loopup 效能相當的快．還是有一些缺點，可以分享一下：
footprint 在 filter 內當作該數值的特徵值，雖然有一些好處．但是也多了另外一個方面的碰撞機會而造成 false positive
It will happen on “kubeadm” but not happen in “minikube”.
Check iptable rule.
sudo iptables-save
-A INPUT -j KUBE-FIREWALL
-A FORWARD -j DOCKER-ISOLATION
-A FORWARD -o docker0 -j DOCKER
-A FORWARD -o docker0 -m conntrack --ctstate RELATED,ESTABLISHED -
j ACCEPT
-A FORWARD -i docker0 ! -o docker0 -j DROP
-A FORWARD -i docker0 -o docker0 -j DROP
-A OUTPUT -j KUBE-FIREWALL
-A DOCKER-ISOLATION -j RETURN
As you could observe “A FORWARD -i docker0 ! -o docker0 -j DROP”
Refer to moby issue 40182 (still not resolve until kubernetes 1.8)
sudo iptables -P FORWARD ACCEPTdocker --iptables=false (not easy when you use kubernetes)