kubernetes, sdn, linux

此篇文章是 Kubernetes Pod-DNS 系列文章最後一篇
此系列文會從使用者的用法到一些問題的發掘，最後透過閱讀程式碼的方式去分析這些問題

相關的文章連結如下

• [Kubernetes] DNS setting in your Pod
• [Kubernetes] DNS Setting with Dockerd
• [Kubernetes] DNS Setting with Dockerd(原始碼分析上)

正文

再上篇文章 - [Kubernetes] DNS Setting with Dockerd(原始碼分析上) 中，我們透過閱讀 kubernetes 原始碼的方式已經理解到 kubernetes 本身是怎麼去處理 DNS 的設定。 但是卻留下了一個謎團就是 dockerd 到底如何處理每個容器本身的 DNS 設定?

重新複習一次之前觀察到的結果

node\dockerd	有設定 DNS	沒設定 DNS
有數值	node	node
沒有數值	dockerd	8.8.8.8

這邊直接開門見山的說明結論
當每次創建容器時，大抵上都會遵循下列邏輯

1. 先根據參數resolveConf 來讀取當前 DNS 的全部設定
2. 如果使用者有自行設定 DNS 的參數，就會全面使用這邊的設定，完全忽略(1)載入的設定
3. 如果使用者沒有自行設定 DNS 的話，就會針對 (1) 載入的設定進行一次過濾
   • 針對 127.0.0.1/8 之類的進行過濾
   • 過濾後若發現是空的，則補上 8.8.8.8/8.8.4.4

接下來我們就會透過直接閱讀 docker-ce 原始碼的方式來理解這個問題

此篇文章是 Kubernetes Pod-DNS 系列文章第三篇
此系列文會從使用者的用法到一些問題的發掘，最後透過閱讀程式碼的方式去分析這些問題

相關的文章連結如下

• [Kubernetes] DNS setting in your Pod
• [Kubernetes] DNS Setting with Dockerd
• [Kubernetes] DNS Setting with Dockerd(原始碼分析下)

正文

在前篇文章
[Kubernetes] DNS Setting with Dockerd 中已經詳細介紹了整個問題的流程以及觀察結果。

再次重申一次結論
kubernetes 會先嘗試使用節點上 /etc/resolv.conf 的資料，但是若發現 /etc/resolv.conf 是空的，這時候就會去依賴 dockerd 幫忙產生的 /etc/resolv.conf

本篇會直接從 kubernetes 以及 docker 的原始碼來研究這個問題，並且佐證上篇文章的觀察結果。

此篇文章是 Kubernetes Pod-DNS 系列文章第二篇
此系列文會從使用者的用法到一些問題的發掘，最後透過閱讀程式碼的方式去分析這些問題

相關的文章連結如下

• [Kubernetes] DNS setting in your Pod
• [Kubernetes] DNS Setting with Dockerd(原始碼分析上)
• [Kubernetes] DNS Setting with Dockerd(原始碼分析下)

正文

在前篇文章
[Kubernetes] DNS setting in your Pod 中已經詳細介紹了如何針對 Pod 去設定自己想要的 DNS 規則。

但是最近遇到一個有趣的狀況，當 Pod 內設定其 dnsPolicy 為 Default 時，則 Pod 內 /etc/resolv.conf 的數值卻會因為系統上面不同的設定而有不同的結果。

根據研究與實驗觀察後，這些東西最後會跟兩個東西有很密切的關係，分別是運行節點上 /etc/resolv.conf 內的資料以及該機器上 dockerd 運行的參數有關

直接先講結論
kubernetes 會先嘗試使用節點上 /etc/resolv.conf 的資料，但是若發現 /etc/resolv.conf 是空的，這時候就會去依賴 dockerd 幫忙產生的 /etc/resolv.conf

針對這個問題接下來會分成兩篇文章來解釋
其中本篇是上篇，主軸在於介紹問題，並且透過實驗觀察結果進行歸納。
之後會有下篇，比較硬派一點，直接透過觀察原始碼的方式來驗證本篇的觀察結果

本身算是 Costco 愛好者，每個禮拜的蛋白質基本上都是從 Costco 取得

常買的有

1. 雞胸肉
2. 雞腿排
3. 牛奶
4. 蛋白丁
5. 蝦仁
6. 鮭魚

這篇文章主要用來記錄雞腿排的資訊，包含來源，熱量等資訊

此篇文章是 Kubernetes Pod-DNS 系列文章第一篇
此系列文會從使用者的用法到一些問題的發掘，最後透過閱讀程式碼的方式去分析這些問題

相關的文章連結如下

• [Kubernetes] DNS Setting with Dockerd
• [Kubernetes] DNS Setting with Dockerd(原始碼分析上)
• [Kubernetes] DNS Setting with Dockerd(原始碼分析下)

正文

在Kubernetes 裡面看到 DNS 這個字眼，實際上可以想到非常多相關的元件與功能，
譬如用來提供 kubernetes 集群內服務的 kube-DNS, 或是透過 kubernetes service 產生之獨一無二的 FQDN 名稱，最後就是本篇文章想要分享的一個元件， Pod 內的 DNS 設定。

在大部分的使用情境之下，通常不會去關心這個部分，直接套用 kubernetes 預設的設定幫忙把相關的給處理完畢，然而隨者 kubernetes 愈來愈熱門，使用的情境愈來愈多。
譬如跟 NFV(Network Function Virtualization) 有關的應用中，我們所運行的任何應用程式 (Pod) 可能就會有 DNS 相關的需求。

接下來我們使用下面這張架構圖來說明可能的使用情境

本篇文章的原文為 11 Ways Not to Get Hacked

本文作者將這 11 個技巧與觀念分成三大部分來
分別是

1. The Control Plane
2. Workloads
3. The Future

本篇文章延續 11個保護你 Kubernetes 集群的技巧與觀念(上)

繼續探討原文作者後半部分的概念

本篇文章的原文為 11 Ways Not to Get Hacked

本文作者將這 11 個技巧與觀念分成三大部分來
分別是

1. The Control Plane
2. Workloads
3. The Future

每個部分除了文章內容的敘述外，其實也都補充了不少相關的資源與補充。
所以接下來我會使用兩篇文章的方式來記錄這 11 個觀念/技巧並且加上我個人的看法

本篇文章後續 11個保護你 Kubernetes 集群的技巧與觀念(下)

This post is used to record all my presentations from 2017

這篇文章的主軸其實非常簡單，目標是希望為開發者的 Kubernetes 應用程式提供更強健的自動化測試流程，確保該應用程式在開發上能夠與 Kubernetes 緊密結合。

為了確保程式品質，我們都會在開發的過程中撰寫一些單元測試/整合測試來確保開發的功能能夠正常運作。
特別是當有新功能的開發或是臭蟲修復時不會對舊有的功能造成損毀。

這個理念看起來非常合理，但是當應用程式一旦與 Kubernetes 結合的時候，這個理念到底好不好實現?

大部分的應用程式基本上不太在意是否有 kubernetes 的存在，只要確保本身的功能正常運作即可，譬如 MongoDB 等應用程式。

但是有些應用程式本身會對 kubernetes 集群進行操作，這類型的應用程式的功能都要存在一個 kubernetes 集群來互動，確保功能正常

而本篇文章存在的目的就是要提供一種解決方案給後者的應用程式，讓你的應用程式能夠更容易地與 Kubernetes 結合來進行測試。

最近嘗試要再 GKE 上面開啟 GPU 的服務，然後實際上卻遇到了一些問題，因此用本篇文章來記錄遇到問題並且遇到問題的解決思路。

一開始有個需求時，很直覺的再 Google 上面直接用 GKE GPU 進行搜尋，的確也可以找到不少文章在講 GPU 與 Kubernetes 相關。

第一個搜尋結果則是 Google 官方的文章 Kubernetes Engine, GPUs

直接整理該文章中的重點流程.

1. 從 GCP 的管理面板中去取得 GPU 資源
2. 創造 GPU Node Pool 供 GKE ㄐ
3. 透過 kubernetes DaemonSet 的方式安裝 NVIDIA Drivers 到所有 GPU Node 上
4. 接下來創造 Pod 即可正常使用 NVIDIA GPU 資源