kubernetes, sdn, linux,devops

於 kubernetes 叢集中，我們會部屬大量的容器應用程式,而這些應用程式有些是面向使用者,也有些是彼此容器間互相溝通使用的.舉例來說,管理人員可能會在叢集中佈署了相關的資料庫容器服務,而其他的應用服務就必須要透過網路連線的方式來存取該資料庫.為了要透過網路的方式存取,就意味要使用 IP 地址的方式來存取對應的容器服務,然而在 kubernetes 的叢集中,這些 Pod 重啟後預設情況下都會拿到不相同的 IP 地址， 這意味我們的客戶端應用程式就沒有辦法寫死這些 IP 地址來存取,必須要有更動態的方式讓客戶端應用程式可以取得當前目標容器(資料庫)的最新 IP 地址. 為了解決這個問題, 我們可以透過 kubernetes service 的架構來達成上述的目的。本文會跟大家介紹什麼是 kubernetes service 以及透過實際範例介紹該如何使用

在前篇文章有跟大家分享過實際部屬上遇到的 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 結合的時候，這個理念到底好不好實現?