不要被新項目分心，而是專註於取得你的 Kubernetes 翻斗車駕駛執照。

-- Scott Mccarty（作者）

在本系列的前兩篇文章中，我解釋了為何 Kubernetes 像翻斗車 ，並且想要理解像 Kubernetes （和翻斗車，起重機等）這樣優雅、專業工具總是有 學習曲線 的。本文是下一步：學習如何駕駛。

最近，我在 Reddit 上看到了一個關於 重要的 Kubernetes 項目 的帖子。人們似乎很想知道他們應該學習如何開始使用 Kubernetes。「駕駛翻斗車的類比」有助於確保這個問題回到軌道上去。在這個帖子中的某個人提到，除非必要，你不應該運行自己的鏡像倉庫，所以人們開始逐漸接受駕馭 Kubernetes 而不是構建它的想法。

API 是 Kubernetes 的引擎和變速器。像翻斗車的方向盤、離合器、汽油和制動踏板一樣，用於構建應用程序的 YAML 或 JSON 文件是機器的主要介面。當你第一次學習 Kubernetes 時，這應該是你的主要關注點。了解你的控制部件。不要分心於最新和最大的那些項目。當你剛學會開車時，不要嘗試駕駛實驗性的翻斗車。相反，請專註於基礎知識。

定義狀態和實際狀態

首先，Kubernetes 遵循定義狀態和實際狀態的原則。

Defined state and actual state

人類（開發人員/系統管理員/運維人員）使用他們提交給 Kubernetes API 的 YAML/JSON 文件指定定義的狀態。然後，Kubernetes 使用控制器來分析 YAML/JSON 中定義的新狀態與集群中的實際狀態之間的差異。

在上面的例子中，Replication Controller 可以看到用戶指定的三個 pod 之間的差異，其中一個 pod 正在運行，並調度另外兩個 Pod。如果你登錄 Kubernetes 並手動殺死其中一個 Pod，它會不斷啟動另一個來替換它。在實際狀態與定義的狀態匹配之前，Kubernetes 不會停止。這是非常強大的。

原語

接下來，你需要了解可以在 Kubernetes 中指定的原語。

Kubernetes primitives

這些原語不僅僅有 Pod，還有 部署(Deployment)、 持久化卷聲明(Persistent Volume Claim)、 服務(Service)， 路由(route)等。使用支持 Kubernetes 的平台 OpenShift ，你可以添加 構建(build)和 BuildConfig。你大概需要一天左右的時間來了解這些原語。你可以在你的用例變得更加複雜時再深入了解。

將原生開發者映射到傳統 IT 環境

最後，考慮這該如何映射到你在傳統 IT 環境中的操作。

Mapping developer-native to traditional IT enviro

儘管是一個技術問題，但用戶一直在嘗試解決業務問題。從歷史上看，我們使用諸如 劇本(playbook)之類的東西將業務邏輯與單一語言的 IT 系統綁定起來。對於運維人員來說，這很不錯，但是當你嘗試將其擴展到開發人員時，它會變得更加繁瑣。

直到 Kubernete 出現之前，我們從未能夠以原生開發者的方式真正同時指定一組 IT 系統應如何表現和交互。如果你考慮一下，我們正在使用在 Kubernetes 中編寫的 YAML/JSON 文件以非常便攜和聲明的方式擴展了管理存儲、網路和計算資源的能力，但它們總會映射到某處的「真實」資源。我們不必以開發者身份擔心它。

因此，快放棄關注 Kubernetes 生態系統中的新項目，而是專註開始使用它。在下一篇文章中，我將分享一些可以幫助你使用 Kubernetes 的工具和工作流程。

via: https://opensource.com/article/19/6/kubernetes-basics

作者： Scott McCarty 選題： lujun9972 譯者： geekpi 校對： wxy

本文由 LCTT 原創編譯， Linux中國 榮譽推出

點擊「了解更多」可訪問文內鏈接

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！