使用 Kubernetes，你可以快速、高效地滿足使用者以下的需求：

• 快速精準地部署應用程式
• 即時伸縮你的應用程式
• 無縫展現新特徵
• 限制硬體用量僅為所需資源

我們的目標是培育一個工具和元件的生態系統，以減緩在公有云或私有云中執行的程式的壓力。

Kubernetes 的優勢

•   可移動: 公有云、私有云、混合雲、多型雲
•   可擴充套件: 模組化、外掛化、可掛載、可組合
•   自修復: 自動部署、自動重啟、自動複製、自動伸縮

Google 公司於 2014 年啟動了 Kubernetes 專案。Kubernetes 是在 Google 的長達 15 年的成規模的產品級任務的經驗下構建的，結合了來自社群的最佳創意和實踐經驗。

容器優勢總結：

•   敏捷的應用建立與部署：相比虛擬機器映象，容器映象的建立更簡便、更高效。
•   持續的開發、整合，以及部署：在快速回滾下提供可靠、高頻的容器映象編譯和部署（基於映象的不可變性）。
•   開發與運營的關注點分離：由於容器映象是在編譯/釋出期建立的，因此整個過程與基礎架構解耦。
•   跨開發、測試、產品階段的環境穩定性：在膝上型電腦上的執行結果和在雲上完全一致。
•   在雲平臺與 OS 上分發的可轉移性：可以在 Ubuntu、RHEL、CoreOS、預置系統、Google 容器引擎，乃至其它各類平臺上執行。
•   以應用為核心的管理: 從在虛擬硬體上執行系統，到在利用邏輯資源的系統上執行程式，從而提升了系統的抽象層級。
•   鬆散耦聯、分散式、彈性、無拘束的微服務：整個應用被分散為更小、更獨立的模組，並且這些模組可以被動態地部署和管理，而不再是儲存在大型的單用途機器上的臃腫的單一應用棧。
•   資源隔離：增加程式表現的可預見性。
•   資源利用率：高效且密集。

為什麼我需要 Kubernetes，它能做什麼?

至少，Kubernetes 能在實體機或虛擬機器叢集上排程和執行程式容器。而且，Kubernetes 也能讓開發者斬斷聯絡著實體機或虛擬機器的“鎖鏈”，從以主機為中心的架構躍至以容器為中心的架構。該架構最終提供給開發者諸多內在的優勢和便利。Kubernetes 提供給基礎架構以真正的以容器為中心的開發環境。

Kubernetes 滿足了一系列產品內執行程式的普通需求，諸如：

以上兼具平臺即服務（PaaS）的簡化和基礎架構即服務（IaaS）的靈活，並促進了在平臺服務提供商之間的遷移。

Kubernetes 是一個什麼樣的平臺?

雖然 Kubernetes 提供了非常多的功能，總會有更多受益於新特性的新場景出現。針對特定應用的工作流程，能被流水線化以加速開發速度。特別的編排起初是可接受的，這往往需要擁有健壯的大規模自動化機制。這也是為什麼 Kubernetes 也被設計為一個構建元件和工具的生態系統的平臺，使其更容易地部署、縮放、管理應用程式。

標籤（label）可以讓使用者按照自己的喜好組織資源。 註釋（annotation）讓使用者在資源裡新增客戶資訊，以優化工作流程，為管理工具提供一個標示除錯狀態的簡單方法。

此外，Kubernetes 控制面板是由開發者和使用者均可使用的同樣的 API 構建的。使用者可以編寫自己的控制器，比如 排程器（scheduler），使用可以被通用的命令列工具識別的他們自己的 API。

這種設計讓大量的其它系統也能構建於 Kubernetes 之上。

Kubernetes 不是什麼？

Kubernetes 不是傳統的、全包容的平臺即服務（Paas）系統。它尊重使用者的選擇，這很重要。

Kubernetes：

•   並不限制支援的程式型別。它並不檢測程式的框架 (例如，Wildfly)，也不限制執行時支援的語言集合 (比如， Java、Python、Ruby)，也不僅僅迎合 12 因子應用程式，也不區分 應用 與 服務 。Kubernetes 旨在支援儘可能多種類的工作負載，包括無狀態的、有狀態的和處理資料的工作負載。如果某程式在容器內執行良好，它在 Kubernetes 上只可能執行地更好。
•   不提供中介軟體（例如訊息匯流排）、資料處理框架（例如 Spark）、資料庫（例如 mysql），也不把叢集儲存系統（例如 Ceph）作為內建服務。但是以上程式都可以在 Kubernetes 上執行。
•   沒有“點選即部署”這類的服務市場存在。
•   不部署原始碼，也不編譯程式。持續整合 (CI) 工作流程是不同的使用者和專案擁有其各自不同的需求和表現的地方。所以，Kubernetes 支援分層 CI 工作流程，卻並不監聽每層的工作狀態。
•   允許使用者自行選擇日誌、監控、預警系統。（ Kubernetes 提供一些整合工具以保證這一概念得到執行）
•   不提供也不管理一套完整的應用程式配置語言/系統（例如 jsonnet）。
•   不提供也不配合任何完整的機器配置、維護、管理、自我修復系統。

另一方面，大量的 PaaS 系統執行在 Kubernetes 上，諸如 Openshift、Deis，以及 Eldarion。你也可以開發你的自定義 PaaS，整合上你自選的 CI 系統，或者只在 Kubernetes 上部署容器映象。

因為 Kubernetes 運營在應用程式層面而不是在硬體層面，它提供了一些 PaaS 所通常提供的常見的適用功能，比如部署、伸縮、負載平衡、日誌和監控。然而，Kubernetes 並非鐵板一塊，這些預設的解決方案是可供選擇，可自行增加或刪除的。

而且， Kubernetes 不只是一個編排系統 。事實上，它滿足了編排的需求。 編排 的技術定義是，一個定義好的工作流程的執行：先做 A，再做 B，最後做 C。相反地， Kubernetes 囊括了一系列獨立、可組合的控制流程，它們持續驅動當前狀態向需求的狀態發展。從 A 到 C 的具體過程並不唯一。集中化控制也並不是必須的；這種方式更像是編舞。這將使系統更易用、更高效、更健壯、複用性、擴充套件性更強。

Kubernetes 這個單詞的含義？k8s？

Kubernetes 這個單詞來自於希臘語，含義是 舵手 或 領航員 。其詞根是 governor 和 cybernetic。 K8s 是它的縮寫，用 8 字替代了“ubernete”。

總結：

k8s是一個編排容器的工具，其實也是管理應用的全生命週期的一個工具，從建立應用，應用的部署，應用提供服務，擴容縮容應用，應用更新，都非常的方便，而且可以做到故障自愈，例如一個伺服器掛了，可以自動將這個伺服器上的服務排程到另外一個主機上進行執行，無需進行人工干涉。那麼，問題來了，要運維何用？

    k8s可以更快的更新新版本，打包應用，更新的時候可以做到不用中斷服務，伺服器故障不用停機，從開發環境到測試環境到生產環境的遷移極其方便，一個配置檔案搞定，一次生成image，到處執行。。。

k8s的全生命週期管理

    在k8s進行管理應用的時候，基本步驟是：建立叢集，部署應用，釋出應用，擴充套件應用，更新應用。

在k8s裡面，叢集排程的最小單元就是一個pod，一個pod可以是一個容器，也可以是多個容器，例如你執行一個程式，其中使用了nginx，使用mysql了，使用了jetty，那麼可以將這三個使用在同一個pod中，對他們提供統一的調配能力，一個pod只能執行在一個主機上，而一個主機上可以有多個pod。

那麼有人會問，為什麼要使用pod，為什麼不能直接使用容器呢？使用pod，相當與一個邏輯主機，還記得建立一個vm，在vm上執行幾個程序麼，其實道理是一樣的，pod的存在主要是讓幾個緊密連線的幾個容器之間共享資源，例如ip地址，共享儲存等資訊。如果直接排程容器的話，那麼幾個容器可能執行在不同的主機上，這樣就增加了系統的複雜性。