A slide to summarized some features comparison about Mesos and Kubernetes. 這篇投影片整理了 mesos 與 Kubernetes 的一些比較． 內容有包含: 這兩年的發展 基本架構圖 整理最久的就是近兩年的版本功能發表的時間軸 希望能幫助一些人

NVIDIA 官方 REPO: Kubernetes Device Plugin 說明: Kubernetes 在設計上有著相當程度的擴充性，在當初有 plugin 的架構就可以看出來． 比如說: Network Plugin 讓 CNI 可以輕鬆地整合． 1.8 版剛開放 alpha 的新功能 “Device Plugin” 更強，可以讓 GPU, 高效能網卡, FPGAs 甚至是 InfiniBand 輕鬆的整合在 Kubernetes 之中 原本在 Kubernetes 內預設只能抓取到 CPU 與 Memory 的狀態（不然，就得很辛苦.. 你懂的) 但是透過了 Device Plugin 你就做以下的事情: 輕易的讓 Kubernetes 內所有的 container 可以存取該裝置 輕易抓取到 GPU (或是高效率網卡) 的訊息 透過 Kubernetes 的 Health check 來檢查裝置狀態 有興趣的可以再看看 Kubernetes 文件: https://kubernetes.io/docs/concepts/cluster-administration/device-plugins/

起源 本來就想把 Deep Learning 學一下， 因緣際會下看到這一篇 Coursera 學習心得 試讀了七天，除了提供 Jupyter Notebook 之外，作業也都相當有趣，就開始繼續學了． 目前進度到 Week2 相當推薦有程式設計一點點基礎就可以來學．裡面的數學應該還好． 學習的過程中還可以學會 Python 裡面的 numpy 如何使用，因為裡面主要就是要教導你如何使用 numpy 來兜出 Neural Network ． 課程鏈結: 這裡 學習鏈結: Week 1-2: Introduction to deep learning & Neural Networks Basics Week 3: Shallow neural networks Week 4: Deep Neural Networks 課程內容: 第一週: Introduction to deep learning 基本上就介紹 Machine Learning 與 Deep Learning 的基本常識． 比如說 (ReLU activation functionReLU activation function 介紹了近幾年 Deep Learning 會如此發展快速的原因 (計算速度的進展..) 最後有採訪 Geoffrey Everest Hinton (也就是將 Backpropagation 導入了 Deep learning 的人，並且發明了 Boltzmann machine ) ． 有不少有趣的事情，比如作者認為自己作出的 Boltzmann machine 很美麗，但是無法實作． 所以後來作者加上了一些限制後，衍生出 restricted Boltzmann machine ，該系統就被 Netflix 拿來使用． 第二週: Neural Networks Basics 從頭開始教，一開始就教導你什麼是 binary-classification ． 透過簡單的影像判斷是不是貓，來教導． 透過不同的資料（R, G, B) 來判斷是不是貓． 教導一些 Deep Learning 的基本: Logistic Regression Ligistic Regression Cost Function Gradient Descent Dervatives 透過一個 Jupyter Notebook 來教導你如何透過 numpy 來寫一個簡單的二元分類器 (classifier) 來分辨輸入的圖片是不是貓． 實際流程是: 先做一個 sigmoid function 再來實作 propagate function. 拿到 X 做出 forward propagate: 算出 A = sigmoid($$w^TX+b) 再來算出 cost function J...

原文: infoq: Are You a Software Architect? [你是一個合格的軟體架構師嗎?] 快速中文導讀.. 最近看的文章之中，這篇文章相當適合推薦給大家．不論你已經是軟體架構師，或是你正想將你的專業領域網軟體架構師來邁進，都建議來看一下． 其中的許多部分加入了我個人的經驗與觀點，請觀看時斟酌思考，如果有錯誤的部分，歡迎提供任何意見． 本文部分 身為一個軟體架構師，最重要的兩個能力如下: Definition of the software architecture Delivery of the software architecture 以下開始解釋這兩種能力的細節，以及為何需要這兩種能力． A. Definition of the software architecture (定義出軟體架構) 裡面建議在勾勒出整個軟體架構的時候必須要有的幾個面向為: Management of non-functional requirements Architecture definition Technology selection Architecture evaluation Architecture collaboration 以下開始逐一解釋每個細項的部分 1. Management of non-functional requirements (管理非功能面的需求) 這裡解釋一下，所謂的”非功能面需求” (non-functional requirements) 一般指的就是跟功能本身無關的需求，比如說： 系統的反應速度，系統容納上限，是否有 HA 與 Fault-tolerance? ． 要針對功能面向來定義與管理比較容易，要有相當的經驗的人才能了解 non-functional requirements 的重要． 在設計軟體架構的第一個面向應該馬上將功能面以外的需求加以管理，並且確認清楚，不要讓該需求無限擴張． 比如說你的系統如果不需要 24x7 的營運保證，或許就可以讓他有系統更新與修改的時間與機會．或是可以釐清究竟需要多少的連線速度． 2. Architecture definition (定義出軟體架構) 當你透過管理而清楚地條列出非功能性需求後，你對於整個系統的效能與容錯率有了一個定義與概念． 接下來就是要定義出你的軟體架構，不論是透過將原先已經有的軟體架構加以修改，或是重新定義出一個軟體架構． 3. Technology selection (技術的選擇) 如何選擇你的架構，主要有以下的考量點: 舊的技術有什麼缺點? 是否一定要使用新的技術? 每個服務之間是透過哪一種的 licensing 如果使用開源該社群活不活耀？ vendor 支援如何? 每一個係項都是需要好好思考的問題，你思考的越多在技術的選擇上就會有更多的考量，自然之後就更不容易有遺漏的地方． 4. Architecture evaluation (架構的評估) 關於評估(evaluation)，這裡有兩個面向: “假設”系統會如預期的運行 “證明”系統會如預期般的完美運行 不論是功能性的需求或是非功能性的需求(Non-Functional Requirement)對於系統架構的建置評估上，都是具有相當風險． 再評估系統架構上，我們可以透過各種的分別的服務壓力測試來給予我們足夠的信心來評估我們的系統架構． 比如說，在決定 Message Queue 系統架構時，可以考量 Kafka, Redis, 或是其他 MQ 給予的壓力測試數據，加上該系統可以裝載的資訊類別來評估是否符合你的系統設計． 所以根據前面的範例，在設計上我們都會先“假設” Kafka 能夠符合你的系統設計需求再來查看 Kafka 的可以乘載的資料類別與限制，加上他的壓力測試數據．來”證明“系統架構上是可行的． 5. Architecture collaboration (架構上的合作與溝通) 一個好的服務架構往往需要跨組織，跨區域性的合作．很多時候需要許多系統內部甚至是外部的參與者的合作才能造就整個系統的穩定與完整． 比如說： 外部資料提供者需要給予足夠文件的說明 外部服務提供者（或是需求者）能夠了解系統的架構與限制 所以，這時候良好的文件與溝通就無法省略．雖然不容易，但是這是一個很軟體架構師重要的工作職責，確認讓所有的合作夥伴能夠無縫的溝通與合作． B. Delivery of the software architecture (將定義出來的軟體架構交付出來） 如何能夠將軟體架構交付出來的部分，也有列出以下幾個所需要的能力： Ownership of the bigger picture Leadership Coaching and mentoring Quality assurance Design, development and testing 這幾個項目其實在這幾年的專案管理過程中，不斷的有運用到所以相當推薦這些項目給軟體架構師． 1. Ownership of the bigger picture...

(Image: Coolshell) [Cuckoo Filter: Practically Better Than Bloom] [slide] 接續前文， Bloom Filter 深入討論 複習一下 Bloom Filter 與 Counting Filter Bloom Filter 快速的搜尋索引結構，具有以下優點: 能夠在 \(O(1)\) 的時間複雜度下快速確認該物品有沒有存在（* 具有 False Positive) 缺點: 但是只支援新增節點卻無法刪除節點． (* 需要透過重新建立 Bloom Filter) False positive 的問題，需要透過增加節點(m)來減少，但是這樣又會造成空間複雜度的增加． 為了要解決刪除節點需要重新建立整個 Bloom Filter 的缺點， Counting Filter 就因為這樣而產生． Counting Filter 缺點 空間過大 原先 Couting Filter 藉由增加一個資料欄位來讓 Bloom Filter 無法刪除資料點的限制去除．但是卻又因為每個節點需要增加一個資料欄位而讓空間使用上變得相當沒有效率． 空間的利用率上，根據這篇論文提到． 你可能需要使用到 3~4 倍的空間使用率來維持相同的 False Positive Rate ． 為何使用 Couting Filter 的空間複雜度會增加 3~4 倍 主要是因為要能夠符合 dynamic deletion 這個條件限制，所以在插入資料的時候會選擇 \(k\) 的個數來插入你的資料． （也就是一份資料 duplicate 到 \(k\) 份） 原因如下： 由於需要符合 dynamic deletion ，雖然增加了一個數值單位來記錄總共有幾個．但是如果只有一份的話，再刪除的時候很容易刪除掉其他 hashing collision 的資料 避免這樣的問題，只好多複製幾分來做為 hashing collision 的解決方式． 細談增加 3~4 倍的原因 在這裡列出一些符號如下: 第 i 個 counting filter 被增加 j 次的機率 \(n\) 元素個數 \(k\) hashing 個數，也就是你需要複製幾份 \(m\) 為原來的 couter 的表現大小的個數． \[P(c(i) = j) = (^nk _j) (1/m)^j (1-1/m)^nk-j\] 之前的 Bloom Filter 對於 \(k, m, n\) 的限制: \(k ≤ (ln2)m/n\) ，所以式子可以改成: \[P( (max)_i c(i) >= j) <= m ((e ln 2)^j/ j)\] 所以如果 counter \(i\) 是 4 個，那麼...

Symptom: Service/Pod could create success, but could not connect to pod. Could not connect to another pod in another node (even in the same node) All kubectl status works well Your docker is newer than 1.13 (it works well if your docker version is 1.12) It will happen on “kubeadm” but not happen in “minikube”. Diagnosis: 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” Root cause: Refer to moby issue 40182 (still not resolve until kubernetes 1.8) Docker 1.13 changed the default iptables forwarding policy to DROP So all forward...