需求層次理論是由心理學家艾伯特·馬斯洛設計的,它是一種解釋人類動機的心理學理論,它由多層次的人類需求模型組成,一般被描述成金字塔內的等級層次。馬斯洛使用諸如生理、安全、歸屬感和愛、尊重、自我實現和自我超越等來描述人類動機一般所經歷的階段。做爲人類,首先須要知足咱們的基本需求,而後是心理上的需求,只有這樣咱們才能想到自尊和實現所有的潛能:安全
馬斯洛需求層次服務器
1、Kubernetes能知足微服務的馬斯洛需求網絡
這種描述需求的方法很是重要,已經應用於許多其餘領域,如員工敬業度、雲計算、軟件開發、DevOps等等。因此對於微服務來講也一樣適用,爲了微服務的成功,清晰的需求列表必須知足。List以下:架構
微服務的需求層次結構分佈式
一旦列出了微服務的主要問題(對每一個人來講可能會有不一樣的順序),就會發現Kubernetes容器編排引擎確實可以很好地覆蓋這些需求中的很大一部分。我把Kubernetes也添加到圖中。ide
首先,對於基礎層,須要一些計算資源,而且理想的狀況下,擁有一個由基礎設施服務雲提供商管理的可伸縮的標準操做環境。其餘先決條件是,自動化的CI/CD流程和工件註冊表,Kubernetes能夠幫助咱們運行和管理。咱們仍然須要一些專門的軟件,好比構建的Jenkins,以及工件存儲庫,好比按需 Sonatype Nexus for Docker和Maven for Docker Hub。微服務
Kubernetes能夠幫助管理多個隔離環境(名稱空間)、管理資源(配額和限制)、存儲分配(持久卷)、執行部署和回滾(部署)、自動調度(調度)、服務發現和負載平衡(服務)、彈性和容錯(pod健康檢查)。工具
對於某些需求,咱們還須要一些額外的工具,如Docker或rkt用於容器實現,應用程序內的彈性庫(如Netflix的Hystrix)與Kubernetes彈性特性相結合。而後,Kubernetes能夠管理應用程序配置,並幫助運行最好的集中式日誌記錄、度量收集和跟蹤軟件,隨着服務數量的增長,這些也變得很是重要。ui
根據微服務的性質,企業有一些特定的需求。對於API驅動的微服務,須要專門的API管理解決方案,也能夠處理服務安全性(Kubernetes沒有提供)。可是Kubernetes能夠輕鬆地幫助企業運行有狀態的服務(有狀態的設置)、批處理做業(job)和調度做業(cron job)。雲計算
經過一個平臺提供的全部這些特性,用戶能夠執行一些更智能的活動,如應用程序和基礎設施自動伸縮和自修復,經過自動放置、自動重啓、自動複製、自動伸縮。
對於Kubernetes所知足的全部這些需求,團隊所剩下的就是精簡開發流程,擁抱DevOps文化以實現快速交付,並在組織層面達到反脆弱性。
2、關於Kubernetes你須要知道的8件事
這是《計算機週刊》與 Carlos Sanchez 的問答環節,Sanchez 是 CloudBees 的工程師,CloudBees是持續交付和集成軟件服務的提供商。其中開源持續集成工具Jenkins,是CloudBees服務的重點。
《計算機週刊》的開源內部人士(Computer Weekly Open Source Insider,簡稱:CWOSI)提出了8個與Kubernetes最相關的問題,試圖揭開這個問題的核心,由於2017年Kubernetes經歷了知名度的大幅提高。
CWOSI #1:對於那些不瞭解Kubernetes的人,你如何總結和定義這項技術?
Sanchez: Kubernetes是一個開源平臺,旨在自動化容器的部署、縮放和操做。它是一種容許在大規模集羣上運行容器的技術。它支持跨大型數據中心的隔離應用程序的執行。
CWOSI #2:爲何Kubernetes會在你的觀點中出現——爲何咱們須要它?
Sanchez: Docker確實成功地製造了容器。事實上,谷歌已經運行了不少年幾十億的容器。Kubernetes從谷歌的經驗中得出了這種規模的容器運行,致使谷歌將這項技術引入開源世界,從而使其餘人更容易地管理容器。
至於爲何咱們須要Kubernetes,這是由於對於大型和小型的組織來講,容器變得愈來愈重要,受權開發團隊在大規模的分佈式環境中運行,以便在DevOps和持續交付實踐中更快地交付軟件。在這種狀況下,任何可以簡化容器的有效操做和管理的東西都將受到企業的熱烈歡迎。
CWOSI #3:Kubernetes本質上是開源的,可是有多少開發人員在爲一項本質上是基礎設施的技術貢獻代碼呢?
Sanchez:總的來講,有超過1400名貢獻者。谷歌、紅帽和微軟都被包括在其中。最近,亞馬遜和阿里巴巴已經成爲參與這項技術的幾家最大的公司。CNCF管理整個技術。
CWOSI #4:容器化技術是否最終意味着每一個單獨的組件在驗證其目的和最終交付特定的產出或功能的方面更負責?
Sanchez:容器一般與微服務體系架構相關聯。每一個組件都指望完成一個特定的協議。這些組件有一個目的,它們有由這個協議和API標記的輸入和輸出。他們必須可以履行他們的職責。它們應該是獨立的,並在體系結構中發揮特定的做用,其中有成百上千種服務共存。
CWOSI # 5:何時不須要Kubernetes…當企業不須要大規模或跨多個機器的時候嗎?
Sanchez:Kubernetes是一個複雜的系統。若是企業有規模來證實部署的合理性,那麼採用這種技術是有意義的。例如,若是隻使用一兩臺虛擬機,或者沒有任何更高的要求,企業可能不須要Kubernetes ,Docker本身就足夠了。也就是說,谷歌或Azure提供的當前雲服務讓咱們很容易從Kubernetes和大規模開始。
CWOSI #6:能給咱們解釋一下Kubernetes pod嗎?
Sanchez:Kubernetes pod其實是一組在同一個主機上運行的容器。這些容器具備必定的特色。例如,它們共享相同的網絡空間和資源。真正的Kubernetes pod是由須要共存的容器組成的。
CWOSI #7:讓Kubernetes出錯,並把錯誤的實施組合在一塊兒有多容易?
Sanchez:這又回到了安裝上——這是一個複雜的軟件,須要專門的專業知識。這就是人們使用谷歌Kubernetes引擎或Azure容器服務的緣由。
也就是說,有愈來愈多的工具,不管是開源的仍是商業的,好比kops、kube-aws或者kubeadm均可以幫助執行正確的安裝。若是您不使用其中一個安裝程序來簡化安裝,那麼在此過程當中可能會犯錯誤。
CWOSI #8:在你看來,Kubernetes在接下來的幾年中會如何發展?
Sanchez:將會有愈來愈多的Kubernetes產品從不一樣的供應商進入市場,不只僅是雲提供商,還有操做系統提供商。Kubernetes將成爲集羣的實際操做系統。另外,Kubernetes將會發展成爲一套標準API,容許企業運行集羣架構。
咱們看到雲提供商正在破壞基礎設施,這樣企業就能夠運行Kubernetes,而無需運行服務器。所以,咱們將看到供應商提供Kubernetes做爲服務,企業將可以在雲中運行容器,而沒必要擔憂機器。AWS已經宣佈了提供這一服務的意向,這一趨勢將繼續在其餘供應商中施行。
原文連接:
一、Kubernetes and theMicroservices Hierarchy of Needs
https://thenewstack.io/introd...
二、CloudBees:9 things you need to know about Kubernetes
http://www.computerweekly.com...