我以前是做技術的，現在是我司雲平臺部門的產品經理，我的建議如下：

樓主的題目是：向非技術人員解釋kubernetes。

我認為不能從kubernetes的使用層面（pod，deployment, ingress）來解釋這個問題，而應該從kubernetes的業務層面來解釋，什麼是業務層面呢？就是kubernetes解決了什麼問題？沒有它之前的現狀是什麼？有了它之後變成什麼樣的了，類似這樣的。然後根據非技術人員的訴求，再做深入的擴充套件。思路可能是這樣的：

首先kubernetes是PaaS平臺。

以前大家要部署一個web應用（比如網站），需要：1. 購買一個伺服器，或者虛擬主機2. 購買獨立域名，並把域名繫結到伺服器3. 在伺服器上部署web應用IAAS的出現，解決了1和2的問題，也就是web應用執行所需的硬體環境的問題。並透過資源調配，實現了資源的節約。而PAAS解決的是web應用的開發和執行環境的問題。你的web應用，需要和別的web應用保持隔離吧，需要暴露到公網咖，需要彈性伸縮容吧，需要負載均衡吧，需要資料庫吧，需要快取服務吧，需要檔案儲存服務吧。如果這些都靠你自己去實現（事實上沒有kubernetes之前，我們都是得自己做的），那需要花費很多的人力和物力，也影響產品的最終上市。而kubernetes所做的事情就是把這些服務整合好，網際網路應用可以按需取用，不僅降低了運維成本，也最大限度降低了風險。

總結來看，kubernetes有點像超級巨輪，而執行在上面的app有點像一個一個的集裝箱。

由於有了這個超級巨輪做載體，集裝箱變的很單純，那就是儲存自己的貨物；同樣的道理，有了kubernetes這個平臺，執行在上面的web app也變的很單純，那就是隻需要負責實現自己的業務邏輯即可，不用再管理和負責其他不相干的功能和服務了。

最後，照顧下懂技術的朋友，附上一張kuebernetes的架構圖：

以上就是我的解釋。

這個問題既然是向非技術人員介紹kubernetes。這裡第一個想到的就是比喻法。畢竟kubernetes涉及到很多作業系統，網路的知識，想一點相關知識不捎帶又介紹清楚kubernetes，著實有些難。

先拋一張kubernetes架構圖，參照這個咱們分解來說。見下圖。

我理解中的Kubernetes，可以看作一個公交樞紐站(不是普通的公交站喲)。其作用是統一的排程管理各路公交車的運營。

叢集：一個公交樞紐站可以看做是一個kubernetes叢集

Master：作為kubernetes的大腦，負責整個kubernetes叢集的管理。其中有三個核心元件，既三個核心部門。

apiserver：作為總控，相當於樞紐站的總控制檯。可以理解為管理樞紐站的方方面面。比如門衛室，廣播站，購票大廳等等。

controller-manager：在kubernetes中提供多種控制器，管理叢集各個資源。既公交樞紐站的具體職權部門。比如一路里應該有幾個公交車等

Scheduler:kubernetes負責資源排程。既具體的排程部門，比如這個樞紐站中，某個分站臺需要維修，需要把這個站臺上停靠的車輛調到其他站臺。這就是它做的事。當然不止這些。

Node：kubernetes中各個子節點，各資源項會具體的部署在各節點上。這裡包括幾個關鍵概念：

Kubelet：各節點在叢集中與apiserver通訊的出入口，處理master下發到本節點的任務，並定期向master彙報節點的情況。在這個樞紐站中。類似於每個分站臺的控制檯。只關注自己分站臺的情況，並與總控保持聯絡。

Kubeproxy：這是一個提供負載均衡和服務發現的元件。其功能多與service繫結。可以理解為，對每路公車傳送的資訊。由它制定分發規則進行傳送。新加入的公車。由它負責註冊到service中。

Pod：每一輛公交車可以看做一個pod，這是kubernetes中的基本資源單位。每一個乘客可以看做是一個容器。一輛車上可以有多個乘客。但不管有幾個乘客，都必須有一個司機，既pause容器。

Deployment:每一路公車都會之前有一輛公車，如789路。一定不值一輛車，這些車都運行同樣的路線，完成同樣的功能。就如同deployment，可以部署一類例項多個副本。

Service：這是kubernetes中一個抽象概念。可以這樣比喻。本來某一路下所有的公車副本，應該都停靠在一個分站臺下。但由於站臺位置有限，有一部分車停在了其他分站臺。這時候，總控臺需要對這一路下的所有車進行管理。該怎麼辦呢？總控臺將這一路車定義為一個service，並建立一個通訊的頻道。透過這個頻道，實現對這一路車的負載均衡，排程管理。車該往哪停，車與車之間通訊，都可以透過這個service。

作為開源的容器編排平臺，Kubernetes看起來正在成為事實標準。2017年是Kubernetes的一年。但是，如果你沒有參與雲工作負載的日常管理和運維，那麼對Kubernetes這樣的總結存有不解，也不用大驚小怪。

Kubernetes是相對年輕的技術。它的第一個開原始碼於2014年釋出。但在大約三年後，Kubernetes才真正開始。僅在2017年，包括微軟，OpenStack，Cloud Foundry，IBM，Oracle，思科，Mesosphere和Docker在內的數十家企業和組織相繼釋出了與Kubernetes相關的內容。而Kubernetes的合作伙伴現在有超過150家正在合作或支援該專案的公司。

那麼作為企業的IT管理者，你應該知道Kubernetes？為什麼這項技術很重要，它如何影響日常的IT運營？那麼讓我們來了解下，Kubernetes及其在企業IT中的現在和未來角色。

Kubernetes將自己描述為“生產級容器編排”解決方案。這意味著為了理解Kubernetes，需要了解容器和編排。

編排實際上只是自動化的一個詞彙。Kubernetes負責自動化容器的部署，擴充套件和管理。這意味著使用者可以告訴系統建立五個容器或擴充套件一些容器，而Kubernetes處理所有的細節以實現這一點。

Google雲平臺曾解釋了Kubernetes的起源。本質上，Google建立了一個名為Borg的叢集管理系統，幫助管理執行Google搜尋，Gmail，YouTube和其他服務的伺服器。當容器出現時，Google團隊希望將他們透過Borg獲得的知識應用於容器管理，於是一個名為Seven of Nine的內部專案誕生了。

但是，當Seven of Nine後面的團隊表示他們想讓這個專案開源時，它最初遇到了一些阻力。但最終，在2014年Kubernetes第一個程式碼放在了GitHub上。隨後，Kubernetes 1.0在2015年7月推出。之後由Linux基金會成立的獨立組織CNCF接手管理工作Kubernetes的未來發展。

雖然它沒有歷史積澱，但Kubernetes很快取得了令人印象深刻的市場份額。451 Research進行的200家企業IT決策者的調查中，71％的受訪者表示他們正在使用Kubernetes。使用該專案的知名企業包括Box，eBay，維基媒體，高盛，紐約時報，SAP等等。

許多科技巨頭也紛紛支援Kubernetes，其中不少加入了CNCF的計劃。在CNCF的白金成員中包括阿里雲，AWS，思科，CoreOS，戴爾，富士通，谷歌雲，華為，IBM，英特爾，甲骨文，紅帽，SAP和VMware的辦公等。

Kubernetes不是容器編排的唯一選擇。其他兩個開源專案Apache Mesos和Docker Swarm提供了很多相同的功能。不久之前，這些其他專案中的一個可能成為主導。畢竟，Mesos有更長的歷史，而Swarm得到了領先的容器技術Docker的支援。

但在過去的幾個月裡，Mesos和Swarm似乎都承認了失敗。Mesos的最大的支持者之一是Mesos DC/OS，於2017年9月宣佈支援Kubernetes。而在10月，Docker宣佈它將整合Kubernetes的支援。

Kubernetes的獨特之處在於它可能是目前企業中最難，但最需要的軟體，而且這種情況並不常見。當一個軟體具有像Kubernetes一樣的學習曲線時，興趣決定選擇，但這與目前的情況完全不同。

挑戰並沒有削弱人們對Kubernetes的興趣。相反，它已經刺激了包括領先的公有云平臺在內的許多供應商提供Kubernetes版本或承諾平臺對其使用者更加友好的服務。

雖然很多供應商最初支援技術競爭，但現在所有領先的公有云服務現在都與Kubernetes合作。

AWS提供Amazon EKS，為一種託管服務，可讓你輕鬆在AWS上執行Kubernetes，而無需安裝和執行自己的Kubernetes群集。

微軟Azure提供Azure容器服務（AKS），簡化Kubernetes的部署，管理和操作。

Google是Kubernetes的發明者，為Google雲平臺提供Kubernetes引擎。

IBM在其IBM Cloud Container Service中包含Kubernetes支援。

在2017年所有與Kubernetes相關的釋出中，Docker對該技術的支援可能是最重要的。Docker是容器化技術目前的領導者。在RightScale 2017年雲狀態報告中，Docker是各企業使用的最常見的DevOps工具。

儘管Docker計劃繼續支援其自己的Swarm技術，但該公司計劃將Kubernetes整合到Docker的社群版和企業版中的計劃可能會導致更多的Kubernetes使用。預測認為Kubernetes的使用可能會比Docker的使用更為廣泛，或者由於Kubernetes和其他開源容器專案發展勢頭迅猛，Docker將變得無關緊要。

這不僅僅是雲供應商和Dockers正在搭上Kubernetes的發展潮流。許多其他供應商提供基於Kubernetes的產品和服務。如：

CloudFoundry Container Runtime

CoreOS Tectonic

Heptio

Kublr

Mesosphere DC/OS

Mirantis Cloud Platform

Pivotal Container Service

Platform9

Rancher

Red Hat OpenShift

SUSE CaaS Platform

儘管你可以在任何地方執行Kubernetes，但它真的能夠在混合雲和多雲環境中發揮作用。在451 Research調查中，受訪者表示，他們使用容器和Kubernetes的主要驅動因素是混合雲/跨雲集成和效率。另外，90％的人表示他們認為Kubernetes可以取代私有云和平臺即服務（PaaS）。

現在大多數公司都在使用多個雲供應商，並且在可預見的將來，大多數公司都會繼續在公有云和本地執行工作負載。 對於這些企業來說，Kubernetes提供了一種有吸引力的方式來簡化非常複雜的環境管理。

眾多專家預測，由於Kubernetes廣泛的採用和支援，Kubernetes似乎正在成為技術行業內的標準。然而，值得注意的是，Kubernetes還有很長的路要走，雖然大多數公司可能在內部調研容器和Kubernetes的採用，但大多數公司還沒有投入。

Kubernetes的未來看起來很光明，這就是為什麼許多分析師和顧問建議企業現在就開始學習和嘗試Kubernetes的原因。對Kubernetes有很多瞭解的人常常將其縮寫為K8s，（即K+8個字元+s）。

如果將Docker容器比作公交車

Docker映象就是製作公交車的藍圖，負責Docker容器如何使用

Docker Registry(docker hub)就是公交車生產廠家，負責Docker映象的儲存管理

Docker Network就是公交線路

Docker Compose就是單個公交車站，負責Docker容器之間的編排

Docker Swarm就是整個城市的公交車站網，負責Docker之間的叢集管理

Kubernetes就是更為強大、複雜的城市公交車站網，負責叢集管理編排（相比Swarm，Kubernetes使用起來較為複雜）

其中 Kubernetes裡包括：

Pod可以看作是一組公交車（包含兩個以上的Docker容器）

Controller就是公交排程員

Deployment就是將若干組公交車部署到公交車站

Service就是對公眾開通公交線路

DaemonSet就是每個公交站點部署一個公交車站管理人員

Job可以理解為臨時公交車