kubernetes, sdn, linux,devops

在前篇文章有跟大家分享過實際部屬上遇到的 DNS 問題，並且透過實驗佐證去觀察結果, 本篇文章則是透過另外一種觀點來觀察結果,透過閱讀原始碼的方式來觀察到底 kubernetes 再創建相關的 Pod 時會如何去處理 DNS 相關的設定，由於整個過程牽扯到 kubernetes 以及 CRI(Container Runtime Interface)的操作，而我們預設使用的則是 Docker 作為底層容器的操作. 本篇文章會針對後半部分，也就是所謂的 docker(dockerd) 本身再創建容器的時候，會如何處理其 DNS 相關的設定，透過閱讀 docker-ce 以及 libnetwork 相關的原始碼，不但能夠更清楚的釐清全部的運作原理，也能夠學習到 docker 底層實踐的過程與精神

在前篇文章有跟大家分享過實際部屬上遇到的 DNS 問題，並且透過實驗佐證去觀察結果, 本篇文章則是透過另外一種觀點來觀察結果,透過閱讀原始碼的方式來觀察到底 kubernetes 再創建相關的 Pod 時會如何去處理 DNS 相關的設定，由於整個過程牽扯到 kubernetes 以及 CRI(Container Runtime Interface)的操作，而我們預設使用的則是 Docker 作為底層容器的操作. 由於篇幅過長，所以本文會著重於 kubernetes 原始碼的部分，而 Docker 相關的部分則會餘下篇文章來研究.

本文跟大家分享一個在實際部屬上遇到的問題，在不同的環境下，採用 dnsPolicy:Default 設定的 Kubernetes Pod 裡面所設定的 DNS Server 卻是完全不同的. 根據實際研究與觀察後，發現這個數字並不是單單的依靠 kubernetes 去處理，實際上也跟 Docker 本身如何去設定容器的 dns 也有關係，這部分就包含了宿主機的 /etc/resolv.conf 以及宿主機上 Docker 運行時的參數. 本文會先介紹這個問題，並且分享解決問題的思路以致於最後可以得到這個結論。

本文用來記錄 Costco 去骨雞腿排的營養組成，對於有需要進行飲食追蹤的人能夠提供一個基本的概念到底每一餐吃進去的營養成分分別多少

DNS 在傳統的網路架構中一直扮演很重要的角色，可以讓用戶端透過 FQDN 的方式去存取目標的伺服器端，不需要去寫死對方的 IP 地址。然而在 kubernetes 的架構中, kubernetes 預設就會建立一套 DNS server 讓所有創建的 Pod 來使用。對於一般的使用者來說，只要能夠存取外面網路以及 Kubernetes Service 相關即可,然而在某些特殊的應用情境下，譬如目前喊行之有年的 NFV 架構中，我們的服務(Pod)本身可能會需要更複雜的網路架構，譬如同時存在 Data Network/Control Network. 這情況下，我們的 Pod 會需要特別去處理自己裡面服務所使用的 DNS Server 。 本文主要針對 Pod 裡面關於 DNS 相關的設定進行介紹，並且透過實際部屬 Yaml 的方式來看看到底如何使用。

在管理 Kubernetes 集群方面，大部分的玩家及管理者一開始最在意的一定會是自己的服務能不能夠順利運行起來，同時能不能藉由 kubernetes 的諸多特性，如 service/configmap/deployment/daemonset 等各式各樣的資源來加強自身的服務能力。然而對於一個真正運行產品的集群來說是完全不夠的，除了服務的功能以及穩定外，還有諸多相關的議題都需要一併考慮並且處理。在此議題下特別重要的就是 Security 的處理， Security 處理的不當，可能會造成使用者的資料被竊取，更嚴重甚至整個集權的管理權限都被外人取得。因此這次特別分享一篇 "11 Ways Not to Get Hacked" 的文章，針對裡面提出的 11 個保護好你 kubernetes 集群的方向進行研究，並且配上自己的心得與整理。

在管理 Kubernetes 集群方面，大部分的玩家及管理者一開始最在意的一定會是自己的服務能不能夠順利運行起來，同時能不能藉由 kubernetes 的諸多特性，如 service/configmap/deployment/daemonset 等各式各樣的資源來加強自身的服務能力。然而對於一個真正運行產品的集群來說是完全不夠的，除了服務的功能以及穩定外，還有諸多相關的議題都需要一併考慮並且處理。在此議題下特別重要的就是 Security 的處理， Security 處理的不當，可能會造成使用者的資料被竊取，更嚴重甚至整個集權的管理權限都被外人取得。因此這次特別分享一篇 "11 Ways Not to Get Hacked" 的文章，針對裡面提出的 11 個保護好你 kubernetes 集群的方向進行研究，並且配上自己的心得與整理。

This post is used to record all my presentations from 2017

這篇文章的主軸其實非常簡單，目標是希望為開發者的 Kubernetes 應用程式提供更強健的自動化測試流程，確保該應用程式在開發上能夠與 Kubernetes 緊密結合。為了確保程式品質，我們都會在開發的過程中撰寫一些單元測試/整合測試來確保開發的功能能夠正常運作。 特別是當有新功能的開發或是臭蟲修復時不會對舊有的功能造成損毀。 這個理念看起來非常合理，但是當應用程式一旦與 Kubernetes 結合的時候，這個理念到底好不好實現?

過去所謂的 GPU 運算幾乎都是個人主機的市場，任何人都可以很輕鬆的購買顯卡回家並且安裝起來使用，不論是玩遊戲所需要，或是需要 GPU 運算，這部分的生態早就存在已久。 隨者 AI 市場的蓬勃發展， GPU 資源的需求量上升，個人家用所擁有的數量在部分應用情境下所需要的時間太長了，因此就有了公有雲與 GPU 結合的需求出現。使用者可以根據自身的需求去評估需要多少張 GPU 卡，然後在對應的公有雲上去申請對應的資源來使用。本文基於這種概念的情況下，跟大家分享一下在 Google Kubernetes Engine 上若要使用 GPU 的話，大致上有哪些步驟需要執行，並且分享一些背後的安裝原理。