爲何 Kubernetes 變得如此流行(2020版)
在寫本文的時候,Kubernetes已經有6年左右的歷史了,在過去兩年中,Kubernetes的知名度不斷上升,成爲工程師最愛的平臺之一。今年,它被列爲最受歡迎的平臺的第三位。若是你還沒據說過Kubernetes的話,那麼它是一個容許你運行容器和協調容器負載的平臺。nginx
容器最初是做爲Linux內核進程隔離的產物,包含了2007就支持的cgroups和2002年就支持的命名空間。2008年,當LXC可用時,容器變得更加劇要了,Google開發了「Borg」 好城市 "在容器中運行一切 "的機制。很快來到2013年,Docker發佈了,完全普及了容器。在當時,Mesos是調度容器的主要工具,然而,它並無那麼普遍流行起來。Kubernetes於2015年發佈,並迅速成爲事實上的容器調度標準。git
爲了試圖理解Kubernetes的普及,讓咱們考慮一些問題。上一次開發者們可以就部署應用的方式達成一致是何時?你知道有多少開發人員按開箱即用的方式運行工具?如今有多少雲運維工程師不瞭解應用程序是如何工做的?咱們將在這篇文章中探討這些問題的答案。github
基礎設施使用YAML表達web
從Puppet和Chef的世界裏走出來,Kubernetes的一個重要轉變是,從以代碼爲基礎的基礎架構轉向了以數據爲基礎的基礎架構—具體來講,就是YAML。Kubernetes中的全部資源,包括Pod、Configurations、Deployments、Volumes等,均可以簡單地用YAML文件來表達。好比。api
apiVersion: v1 kind: Pod metadata: name: site labels: app: web spec: containers: - name: front-end image: nginx ports: - containerPort: 80
這種表示方式使DevOps或SRE工程師更容易徹底表達工做負載,而不須要在Python、Ruby或Javascript等語言中用代碼表示。安全
將基礎架構做爲數據的好處還包括。服務器
- GitOps或Git操做版本控制。使用這種方法,你能夠將全部的Kubernetes YAML文件都保存在git倉庫下,這樣你就能夠準確地知道什麼時候進行了更改,誰作了更改,以及具體更改了什麼。這使得整個組織的透明度更高,而且經過避免團隊成員弄不清楚去哪裏尋找配置,從而提升了效率。同時,只需合併一個拉動請求,就能夠更方便地自動化更改Kubernetes資源。
- 可擴展性。將資源定義爲YAML,使得集羣操做人員在Kubernetes資源中改變一兩個數字來擴容或者縮容集羣。Kubernetes有水平pod自動縮放器,能夠指定給定部署所須要的最小和最大pod數量,以便能自動縮容/擴容應對流量低谷/高峯。例如,若是你正在運行的部署可能由於流量突增而須要更多的容量,你能夠將maxReplicas從10個改成20個。
apiVersion: autoscaling/v2beta2 kind: HorizontalPodAutoscaler metadata: name: myapp namespace: default spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: myapp-deployment minReplicas: 1 maxReplicas: 20 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 50
* 安全和控制。YAML是驗證在Kubernetes中部署什麼和如何部署的好方法。例如,當涉及到安全問題時,一個重要的關注點就是你的工做負載是否以非root用戶的身份運行。咱們能夠利用像conftest這樣的工具(YAML/JSON驗證器),再加上Open Policy Agent這樣的策略驗證器,來檢查你的工做負載的SecurityContext是否不容許容器做爲root用戶運行。爲此,用戶可使用一個簡單的Open Policy Agent rego策略,以下。
package main架構
deny[msg] {
input.kind = "Deployment"
not input.spec.template.spec.securityContext.runAsNonRoot = true
msg = "Containers must not run as root"
}
app
* 雲供應商的整合。科技行業的主要趨勢之一就是在公有云供應商中運行工做負載。在雲供應商組件的幫助下,Kubernetes容許每一個集羣與它所運行的雲供應商進行集成。例如,若是用戶在AWS中的Kubernetes中運行某應用程序,並但願該應用程序能夠經過服務訪問,雲供應商會幫助自動建立一個LoadBalancer服務,該服務會自動提供一個Amazon Elastic Load Balancer來將流量轉發到應用程序的pods。 * 可擴展性 Kubernetes的可擴展性很強,開發者很喜歡這一點。Kubernetes已經內置了不少資源,如Pods、Deployments、StatefulSets、Secrets、ConfigMaps等。然而用戶和開發者能夠經過自定義資源定義的形式添加更多的資源。例如,若是咱們想定義一個CronTab資源,咱們能夠這樣作。
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
name: crontabs.my.org
spec:
group: my.org
versions:
框架
- name: v1
served: true
storage: true
Schema:
openAPIV3Schema:
type: object
properties:
spec:
type: object
properties:
cronSpec:
type: string
pattern: '^(\d+|*)(/\d+)?(\s+(\d+|*)(/\d+)?){4}$'
replicas:
type: integer
minimum: 1
maximum: 10
scope: Namespaced
names:
plural: crontabs
singular: crontab
kind: CronTab
shortNames: - ct
咱們之後能夠用以下的方式建立一個CronTab資源。
apiVersion: "my.org/v1"
kind: CronTab
metadata:
name: my-cron-object
spec:
cronSpec: " */5"
image: my-cron-image
replicas: 5
Kubernetes可擴展性的另外一種形式是開發者能夠編寫本身的Operator,這是一個在Kubernetes集羣中運行的特定進程,遵循控制循環模式。一個Operator容許用戶經過與Kubernetes API對話來自動管理CRD(自定義資源定義)。
社區有幾個工具,容許開發者建立本身的Operator。其中一個工具是Operator Framework及其Operator SDK。該SDK爲開發者提供了一個框架,讓他們能夠很是快速地開始建立Operator。例如,您能夠經過如下命令行開始建立Operator。
$ operator-sdk new my-operator --repo github.com/myuser/my-operator
這就爲你的Operator建立了包括YAML文件和Golang代碼在內的整個樣板。
. |____cmd | |____manager | | |____main.go |____go.mod |____deploy | |____role.yaml | |____role_binding.yaml | |____service_account.yaml | |____operator.yaml |____tools.go |____go.sum |____.gitignore |____version | |____version.go |____build | |____bin | | |____user_setup | | |____entrypoint | |____Dockerfile |____pkg | |____apis | | |____apis.go | |____controller | | |____controller.go
添加API和控制器的方式以下。
$ operator-sdk add api --api-version=myapp.com/v1alpha1 --kind=MyAppService $ operator-sdk add controller --api-version=myapp.com/v1alpha1 --kind=MyAppService
最後構建並推送Operator到你的容器註冊表中。
$ operator-sdk build your.container.registry/youruser/myapp-operator
若是開發者須要更多的控制權,他們能夠修改Golang文件中的樣板代碼。例如,要修改控制器的具體內容,他們能夠對controller.go文件進行修改。
另外一個項目,KUDO,只需使用聲明式的YAML文件就能夠建立Operator。例如,Apache Kafka的Operator就是這樣定義的,它容許用戶在Kubernetes上面安裝一個Kafka集羣,只須要幾條命令就能夠了。
$ kubectl kudo install zookeeper $ kubectl kudo install kafka
而後用另外一個命令來調整kafka參數。
$ kubectl kudo install kafka --instance=my-kafka-name \ -p ZOOKEEPER_URI=zk-zookeeper-0.zk-hs:2181 \ -p ZOOKEEPER_PATH=/my-path -p BROKER_CPUS=3000m \ -p BROKER_COUNT=5 -p BROKER_MEM=4096m \ -p DISK_SIZE=40Gi -p MIN_INSYNC_REPLICAS=3 \ -p NUM_NETWORK_THREADS=10 -p NUM_IO_THREADS=20
創新
在過去的幾年裏,Kubernetes每隔三四個月就會有一次大版本發佈,也就是說,每一年都會有三四個大的版本。新功能的引入速度並無放緩,上一次發佈的版本就有超過30種不一樣的新增功能和改進。此外,即便在困難時期,代碼貢獻也沒有放緩的跡象,正如Kubernetes項目Github的活動所示。
新功能讓集羣運維人員在面對各類不一樣的工做負載時有了更多的靈活性。軟件工程師也喜歡有更多的控制權,能夠直接將應用部署到生產環境中。
社區
Kubernetes受歡迎的另外一大方面是其強大的社區。對於初學者來講,Kubernetes在2015年進入1.0版本的時候,就被捐給了雲原生計算基金會(CNCF)。
此外,隨着項目的推動,還有大量的社區SIG(特殊興趣小組),它們針對Kubernetes的不一樣領域進行研究。他們不斷地添加新的功能,以方便其餘用戶使用。
雲原生基金會還組織了CloudNativeCon/KubeCon,截止到本文寫做時,它是有史以來最大的開源活動。該活動通常每一年舉辦三次,彙集了數千名相關技術專家和專業人士。
此外,雲原生基金會有一個技術監督委員會,該委員會和它的SIGs一塊兒研究基金會在雲原生生態系統中的新項目和現有項目。這些項目大多有助於提高Kubernetes的價值。
最後,我相信,若是沒有社區有意識地互相包容、歡迎任何新人的加入,Kubernetes就不會有今天的成功。
將來
開發人員在將來面臨的主要挑戰之一是如何更多地關注代碼的細節,而不是代碼運行的基礎設施。爲此,無服務器架構正在成爲解決這一挑戰的主要架構範式之一。已經有一些很是先進的框架,好比Knative和OpenFaas,使用Kubernetes將基礎架構從開發者那裏抽象出來。
在這篇文章中,咱們已經展現了Kubernetes的簡單介紹,但這只是冰山一角。用戶能夠利用更多的資源、功能和配置。咱們將繼續看到新的開源項目和技術來加強或發展Kubernetes,正如咱們提到的那樣,這些貢獻和社區無處不在。
原文連接:https://stackoverflow.blog/2020/05/29/why-kubernetes-getting-so-popular/
參考閱讀:
- 用代碼來講明,爲何須要面向擴展的設計
- code review 的幾條規則
- 整潔架構的正確之路
- 理想的DevOps流程怎麼作?看看Slack的代碼部署實踐
- 爲何我不同意在代碼中寫註釋:談寫註釋的幾種境界
- Pull Request 的藝術
本文由高可用架構翻譯,技術原創及架構實踐文章,歡迎經過公衆號菜單「聯繫咱們」進行投稿。
高可用架構
改變互聯網的構建方式
長按二維碼 關注「高可用架構」公衆號