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

來自我的博客小站 Level Up

當(dāng)我最開始了解到 Kubernetes 的時(shí)候（大概一年半以前？），我真的找不出需要關(guān)注它的理由。

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

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

我不會(huì)去討論如“我是否應(yīng)該把 Kubernetes 應(yīng)用到生產(chǎn)環(huán)境中？”這種不是一兩句話能說明的問題（因?yàn)椤笆欠裼糜谏a(chǎn)環(huán)境”完全取決于你做的是什么）。

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

Kamal：用 Kubernetes 你只需要簡(jiǎn)單的一個(gè)命令就能啟動(dòng)一個(gè)新服務(wù)

Julia：這怎么可能？

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

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

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

Julia：估計(jì)這里面有不少坑吧。

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

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

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

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

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

從 etcd 中讀取狀態(tài)，比如：1 號(hào)節(jié)點(diǎn)中的應(yīng)用清單

改變狀態(tài)，比如：在 1 號(hào)節(jié)點(diǎn)中啟動(dòng)一個(gè)應(yīng)用 A

更新 etcd 中的狀態(tài)，比如：將應(yīng)用 A 的狀態(tài)設(shè)置為“運(yùn)行中”

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

這同時(shí)也意味著，你能夠通過一個(gè)簡(jiǎn)單的方式，控制所有 Kubernetes 中運(yùn)行的東西。只要你愿意，你可以這樣做：

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

在將一個(gè)分支提交到 Github 后，自動(dòng)啟動(dòng)一個(gè) webserver

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

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

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

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

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

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

所有程序都照常在運(yùn)行

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

當(dāng)所有問題都修復(fù)后，集群會(huì)重新搜集之前丟失的信息

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

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

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

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

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

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

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

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

關(guān)于 state 我就不再多說什么了，我認(rèn)為你唯一需要解決的備份／恢復(fù)問題就只有 etcd（除非你應(yīng)用都是寫入到永久存儲(chǔ)器上的）。我認(rèn)為，這讓 Kubernetes 的操作變得簡(jiǎn)單了很多。

假設(shè)你想部署一個(gè)新發(fā)布的定時(shí)任務(wù)系統(tǒng)！用其他方式做的話，這將是成噸的工作量。但是，在 Kubernetes 上部署一個(gè)新的發(fā)布的定時(shí)任務(wù)系統(tǒng)卻相當(dāng)簡(jiǎn)單?。ㄋ匀恢皇且粋€(gè)發(fā)布系統(tǒng)）

最開始我讀 Kubernetes 定時(shí)任務(wù)控制器代碼的時(shí)候，我真的很開心，因?yàn)樗a很簡(jiǎn)單。點(diǎn)擊這里閱讀cronjob_controller.go，主要邏輯代碼也就 400 多行的 go 代碼。

定時(shí)任務(wù)管理器的主要工作是：

每 10 秒：

列出存在的定時(shí)任務(wù)

檢查每一個(gè)任務(wù)，看是否需要運(yùn)行

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

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

重復(fù)

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

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

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

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

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

另外我寫了一篇 2000 字的博文，講了在配置 Kubernetes CA 中，所有必須學(xué)習(xí)的、關(guān)于 Kubernetes 證書認(rèn)證的不同配置項(xiàng)的知識(shí)。

我認(rèn)為一些 Kubernetes 系統(tǒng)管理軟件，比如 GKE (google’s kubernetes product)，可能會(huì)簡(jiǎn)單一點(diǎn)，因?yàn)樗麨橛脩糇隽舜罅磕J(rèn)的設(shè)置，但我并沒有嘗試過任何一種。