摘要：比如，現(xiàn)在我們集群中的控制器就有內(nèi)存泄漏的問題，調(diào)度器經(jīng)常崩潰。例如，你的控制管理組件有內(nèi)存泄漏的問題，由于控制管理組件是無狀態(tài)的，你能夠間歇的重啟它，比如每小時一次，并且完全不會產(chǎn)生其他不好的連鎖反應。

來自我的博客小站 Level Up

當我最開始了解到 Kubernetes 的時候（大概一年半以前？），我真的找不出需要關注它的理由。

滿打滿算，我已經(jīng)使用 Kubernetes 快三個月以上了。關于為什么我覺得它非常有用，有了一些想法，雖然我仍然還算是一個剛入門的，不過，幸運的是，本文依然能夠向您闡述一下，Kubernetes 究竟是怎么一回事。

我在向您解釋 Kubernetes 多么有趣的過程中，會盡量避免使用一些太專業(yè)的名詞，比如 Native Cloud、Orchestration、Container、Kubernetes 的一些專用語? 。我主要是從一個 Kubernetes 運維工程師的角度向你解釋，因為我當前的工作就是搭建并配置 Kubernetes 運行環(huán)境，并讓他正常運行。

我不會去討論如“我是否應該把 Kubernetes 應用到生產(chǎn)環(huán)境中？”這種不是一兩句話能說明的問題（因為“是否用于生產(chǎn)環(huán)境”完全取決于你做的是什么）。

我最開始接觸 Kubernetes 是源自于和我同事 Kamal 的對話：

Kamal：用 Kubernetes 你只需要簡單的一個命令就能啟動一個新服務

Julia：這怎么可能？

Kamal：比如，你只需要寫一份配置文件，然后應用它，然后你就有了一個運行在生產(chǎn)環(huán)境的
HTTP 服務

Julia：但是，當前如果我要新建一個 AWS（亞馬遜云服務）實例，需要寫一個
manifest，然后啟動服務發(fā)現(xiàn)，配置我的負載均衡，配置我們的開發(fā)軟件，還要保證 DNS 工作正常，就算這切都順利完成，也要至少 4 個小時的時間啊！

Kamal：Yeah。用 Kubernetes ，你就不再需要做這些事情了，你能夠在 5 分鐘內(nèi)啟動一個 HTTP 服務，并且他將自動運行。只要你集群有相應的空間容納這個服務，它就直接能用！

Julia：估計這里面有不少坑吧。

這里面的坑，應該要算配置 Kubernetes 了，確確實實不簡單（以我的經(jīng)驗來說），你可以查看這個Kubernetes The Hard Way。但至少目前來說，我們不用擔心這個事情。

吶，現(xiàn)在第一個酷的地方在于，Kubernetes 有巨大的潛力讓開發(fā)者輕松地部署服務到生產(chǎn)環(huán)境。這真的很酷，使用 Kubernetes 工作，你真的可以在 5 分鐘內(nèi)，用一個配置文件啟動一個新的 HTTP 服務（包括“啟動 5 個服務程序”、“配置負載均衡”、“配置 DNS”），值得了解一下。

在我看來，你在了解 Kubernetes 之前，必須要了解 etcd。那就讓我們先看看 etcd
是個什么！

想象一下，今天我問你“告訴我，生產(chǎn)環(huán)境中現(xiàn)在都運行了些什么應用？都運行在哪些主機上的？服務狀態(tài)正常嗎？是否有 DNS 綁定？”，我不清楚你的情況，我只知道，如果是我，我需要查看一大堆不同位置的服務器，花我一小會兒時間才能搞明白并回答這些問題，不可能通過一個 API 就能得到所有信息。

在 Kubernetes 上，你集群中所有的狀態(tài)：運行的應用、節(jié)點、DNS 名、定時任務等等，都存儲在一個統(tǒng)一的數(shù)據(jù)庫中，Kubernetes 所有的組建都是無狀態(tài)的，并且都是通過一下過程來運行的：

從 etcd 中讀取狀態(tài)，比如：1 號節(jié)點中的應用清單

改變狀態(tài)，比如：在 1 號節(jié)點中啟動一個應用 A

更新 etcd 中的狀態(tài)，比如：將應用 A 的狀態(tài)設置為“運行中”

這意味著，如果你想要回答一個問題“嘿，在可用區(qū)域中，有多少 nginx 在運行？”，你只需要查詢一個統(tǒng)一的 API（Kubernetes提供）即可，Kubernetes 中其他的組建也都能通過這種簡單的 API 方式使用。

這同時也意味著，你能夠通過一個簡單的方式，控制所有 Kubernetes 中運行的東西。只要你愿意，你可以這樣做：

執(zhí)行一個復雜的發(fā)布策略（部署 1 個任務，等待 5 分鐘，部署 5 個或更多，等待 3.7 分鐘等等）

在將一個分支提交到 Github 后，自動啟動一個 webserver

監(jiān)控所有運行中的應用，以確保他們每個都有一個合理的 cgroups 內(nèi)存上線

你所需要做的只是寫一個調(diào)用 Kubernetes API 的程序（控制器“controller”）

另一個比較酷的關于 Kubernetes API 的事情就是，你不用局限于 Kubernetes 所提供的一些管理方式，你可以自己編寫程序調(diào)用 Kubernetes API 實現(xiàn)自定義的 部署／新建／監(jiān)測任務。他讓你能做所有你需要的事情！

許多寫 Kubernetes 的博客一開始就保證的一件事是：“如果 Kubernetes 的 API 服務和其他組件都掛了，這沒什么事兒，你的程序將會繼續(xù)運行！”，我認為，這件事理論上聽起來很酷，但我并不敢確定這是真的。

使用了這么久，這的確是真的！

我經(jīng)歷了一些 etcd 掛掉的情況，但是：

所有程序都照常在運行

沒有其他新的連鎖事件發(fā)生（當然，你無法部署新的程序或者提交修改，定時任務也會停止運行）

當所有問題都修復后，集群會重新搜集之前丟失的信息

當然這也意味著，如果 etcd 掛了，然后某個運行中的程序崩潰了或者發(fā)生其他錯誤，在 etcd 重新啟動之前他將無法自動處理問題。

像其他軟件一樣，Kubernetes 也會有 bug。比如，現(xiàn)在我們集群中的控制器就有內(nèi)存泄漏的問題，調(diào)度器經(jīng)常崩潰。Bug 當然不是什么好東西，但是使用下來，我發(fā)現(xiàn) Kubernetes 的設計幫助其減少了很多在核心組件中潛在的 bug。

如果你重啟任何一個組建，將會發(fā)生：

從 etcd 中讀取所有相關的狀態(tài)數(shù)據(jù)

開始執(zhí)行一些基于當前狀態(tài)必要的操作（調(diào)度應用、垃圾回收、調(diào)度任務、部署守護進程等等）

因為所有的組建都不在內(nèi)存中保存其狀態(tài)，所以你能夠在任何時候重啟組件，這通常還能避免一些 bug 的發(fā)生。

例如，你的控制管理組件有內(nèi)存泄漏的問題，由于控制管理組件是無狀態(tài)的，你能夠間歇的重啟它，比如每小時一次，并且完全不會產(chǎn)生其他不好的連鎖反應。又比如，我們的調(diào)度器出了 bug，他有時會落下某些程序然后從不調(diào)度他們。你就可以通過每十分鐘重啟一次調(diào)度器來減少這個問題的發(fā)生。（我們沒這樣做，因為我們修復了這個 bug，但你可以這樣做啊? ）

因此我覺得，我能夠相信 Kubernetes 的設計，相信它能夠保證即使核心組件出了問題，也能夠保持集群狀態(tài)的連續(xù)性。并且一般來說，我認為軟件的質量是隨著時間慢慢提高的，現(xiàn)在有狀態(tài)的并且需要你操作的，就只有 etcd。

關于 state 我就不再多說什么了，我認為你唯一需要解決的備份／恢復問題就只有 etcd（除非你應用都是寫入到永久存儲器上的）。我認為，這讓 Kubernetes 的操作變得簡單了很多。

假設你想部署一個新發(fā)布的定時任務系統(tǒng)！用其他方式做的話，這將是成噸的工作量。但是，在 Kubernetes 上部署一個新的發(fā)布的定時任務系統(tǒng)卻相當簡單！（它仍然只是一個發(fā)布系統(tǒng)）

最開始我讀 Kubernetes 定時任務控制器代碼的時候，我真的很開心，因為他代碼很簡單。點擊這里閱讀cronjob_controller.go，主要邏輯代碼也就 400 多行的 go 代碼。

定時任務管理器的主要工作是：

每 10 秒：

列出存在的定時任務

檢查每一個任務，看是否需要運行

如果需要運行，新建一個需要調(diào)度的任務對象，然后被其他 Kubernetes 控制器組件執(zhí)行

清除已經(jīng)完成的任務

重復

Kubernetes 的模型挺限制的（他是這么一種模式：資源都定義在 etcd 中，控制器通過讀取這些資源然后更新 etcd），并且我認為這種相關的選項和限制性的模型會讓你在 Kubernetes 的框架中開發(fā)自己的發(fā)布系統(tǒng)更加簡單。

Kamal 給我傳遞了這么一種思想：“Kubernetes 是一個編寫你自己發(fā)布系統(tǒng)的好平臺”而不僅僅是 “Kubernetes 是一個你能使用的發(fā)布系統(tǒng)”，我認為這很有趣。他有一個原型放在 Github 上的 system to run an HTTP service for every branch you push to github。這花了他兩周的時間，好像只有 800 行的 go 代碼，這讓我眼前一亮！

我一開始就說 “Kubernetes 讓你做很多神奇的事情，你僅僅只需要用一個配置文件，就能串起大量的部件以及流程，這讓人難以置信”，當然這是真的！

為什么我說 “Kubernetes 并不是那么簡單”是因為 Kubernetes 有很多部件，要想學會如何配置一個高可用的 Kubernetes 集群需要大量的工作。比如我發(fā)現(xiàn)他給了我很多抽象的接口，我需要了解這些接口底層都是怎么實現(xiàn)的，才能讓我更快速的調(diào)試以及寫出更好的配置。我喜歡學習新事物，所以這并沒有讓我感到不開心或者其他什么的，我只是覺得，這個認識很重要！

一個更加實際的，關于“我不能僅僅依靠這些抽象的接口”的例子。我很掙扎地學習 linux 的網(wǎng)絡知識，才能讓我很自信的配置 Kubernetes 的網(wǎng)絡，肯定會比我完全不了解網(wǎng)絡更好。這會很有趣，但是也很耗時間。以后我或許會寫一些關于配置 Kubernetes 網(wǎng)絡的難與樂。

另外我寫了一篇 2000 字的博文，講了在配置 Kubernetes CA 中，所有必須學習的、關于 Kubernetes 證書認證的不同配置項的知識。

我認為一些 Kubernetes 系統(tǒng)管理軟件，比如 GKE (google’s kubernetes product)，可能會簡單一點，因為他為用戶做了大量默認的設置，但我并沒有嘗試過任何一種。