Kubernetes 110:第一次部署
【編者的話】學習Kubernetes從動手開始，跟隨本文動手建立Pod和Deployment吧。
如果閱讀過 ofollow,noindex" target="_blank">這篇Kubernetes介紹 ，那麼你應該已經很好地理解了組成Kubernetes的基礎元件。如果你和我一樣的話，那麼不真正動手用用Kubernetes，其實無法徹底地理解它的理念。這是本系列文章的第一篇，會實際在雲上部署一個服務。本文還會介紹如何使用Google Kubernetes Engine來部署Gitea，一個開源的git託管服務。
其實Gitea沒有什麼特別之處，但是在雲上實際部署一個開源應用程式能夠幫助我們獲得Kubernetes的實際操作經驗。另外，部署完成之後你還可以使用這個很好的可以自服務的服務來託管你以後的專案！
搭建叢集
kubectl和gcloud
搭建Kubernetes環境所需的最重要工具是kubectl命令。該命令讓使用者可以和Kubernetes API互動。可以用來建立，更新以及刪除Kubernetes資源，比如pod，deployment和負載均衡器。
但是注意：kubectl不能直接用來預配負責pod執行的節點或者叢集。這是因為Kubernetes設計目標是平臺無關。Kubernetes不知道也不關心自己在哪裡執行，因此沒有內建任何方法和使用者所選擇的雲供應商通訊，去代替使用者租用節點。因為本文使用的是Google Kubernetes Engine，我們需要使用gcloud命令來完成節點建立的工作。
簡單來說，gcloud用來預配列在 Kubernetes 101文章 裡介紹的“Hardware”下面的資源，kubectl用來管理“Software”下的資源。
本文假定使用者系統裡已經安裝了kubectl和gcloud。如果你完全是從零開始的，請先檢視 Google Kubernetes Engine Quickstart 裡的第一部分，先註冊一個GCP使用者，建立一個專案，啟用賬單，並且安裝命令列工具。
當環境準備好之後，可以使用如下命令建立一個叢集：
# create the cluster # by default, 3 standard nodes are created for our cluster gcloud container clusters create my-cluster --zone us-west1-a # get the credentials so we can manage it locally through kubectl # creating a cluster can take a few minutes to complete gcloud container clusters get-credentials my-cluster \ --zone us-west1-a
除了使用gcloud命令列工具，還可以通過Google Cloud Console來管理資源。執行完上述命令後，可以看到叢集出現 在GKE下 面。還應該能在 GCE下 面看到預配為節點的VM列表。注意雖然GCE UI允許使用者從這裡刪除VM，但是它們是由叢集管理的，當叢集發現VM消失了就會重新建立VM。當完成本文試驗之後，想要永久刪除VM的話，可以通過刪除叢集從而移除叢集裡的所有資源。
部署應用
YAML：宣告式基礎架構
叢集已經準備好，現在可以開始工作了。有兩種方式可以向Kubernetes上新增資源：使用 kubectl add 命令互動式新增，或者通過定義資源的 YAML 檔案。
雖然使用 kubectl add 命令互動式新增很適合用來做實驗，但是YAML是想要構建可維護的資源的方式。通過將所有Kubernetes資源寫到YAML檔案裡，可以在一系列便於維護的檔案裡記錄下叢集的整個狀態，然後做版本控制來加以管理。這樣，託管服務所需的所有指令都可以和程式碼本身一起儲存管理。
新增Pod
我們通過往叢集裡新增一個Pod來演示Kubernetes YAML檔案。建立一個新的名為gitea.yaml的檔案，內容如下：
apiVersion: v1 kind: Pod metadata: name: gitea-pod spec: containers: - name: gitea-container image: gitea/gitea:1.4
這個Pod很基本，第2行宣告資源的型別是pod；第1行說明該資源是用Kubernetes API v1定義的。第3-8行描述pod的屬性。這裡，pod命名為“gitea-pod”，並且它包含一個名為“gitea-container”的容器。
第8行是最有意思的部分。這一行定義了想要執行的容器映象；這裡，映象是gitea/gitea repository裡的1.4版本。
Kubernetes會告訴內建的容器執行時去找到所要求的容器映象，並且pull到pod裡。因為預設容器執行時是Docker，它會去找Dockerhub上的gitea repository，並且將需要的映象pull下來。
現在我們寫好了YAML檔案，將其apply到叢集上：
kubectl apply -f gitea.yaml
該命令會讓Kubernetes讀取YAML檔案，並且相應更新叢集裡的資源。要看到新建立的pod，可以執行 kubectl get pods 。你應該能看到pod已經在運行了。
$ kubectl get pods NAMEREADYSTATUSRESTARTSAGE gitea-pod1/1Running09m
如果需要更多資訊，可以使用如下命令檢視容器的標準輸出：
$ kubectl logs -f gitea-pod Generating /data/ssh/ssh_host_ed25519_key... Feb 13 21:22:00 syslogd started: BusyBox v1.27.2 Generating /data/ssh/ssh_host_rsa_key... Generating /data/ssh/ssh_host_dsa_key... Generating /data/ssh/ssh_host_ecdsa_key... /etc/ssh/sshd_config line 32: Deprecated option UsePrivilegeSeparation Feb 13 21:22:01 sshd[12]: Server listening on :: port 22. Feb 13 21:22:01 sshd[12]: Server listening on 0.0.0.0 port 22. 2018/02/13 21:22:01 [T] AppPath: /app/gitea/gitea 2018/02/13 21:22:01 [T] AppWorkPath: /app/gitea 2018/02/13 21:22:01 [T] Custom path: /data/gitea 2018/02/13 21:22:01 [T] Log path: /data/gitea/log 2018/02/13 21:22:01 [I] Gitea v1.4.0+rc1-1-gf61ef28 built with: bindata, sqlite 2018/02/13 21:22:01 [I] Log Mode: Console(Info) 2018/02/13 21:22:01 [I] XORM Log Mode: Console(Info) 2018/02/13 21:22:01 [I] Cache Service Enabled 2018/02/13 21:22:01 [I] Session Service Enabled 2018/02/13 21:22:01 [I] SQLite3 Supported 2018/02/13 21:22:01 [I] Run Mode: Development 2018/02/13 21:22:01 Serving [::]:3000 with pid 14 2018/02/13 21:22:01 [I] Listen: http://0.0.0.0:3000
可以看到，叢集的容器裡有一個伺服器在運行了！不幸的是，除非我們開啟ingress通道（以後的文章會介紹），否則還沒有辦法訪問它。
Deployment
在Kubernetes 101裡介紹過，通常pod並不直接執行在Kubernetes上。相反，我們應該定義一個Deployment來管理pod。
首先，刪除掉正在執行的Pod：
kubectl delete -f gitea.yaml
該命令會從叢集裡移除掉定義在YAML檔案裡的所有資源。修改YAML檔案如下：
apiVersion: extensions/v1beta1 kind: Deployment metadata: name: gitea-deployment spec: replicas: 1 selector: matchLabels: app: gitea template: metadata: labels: app: gitea spec: containers: - name: gitea-container image: gitea/gitea:1.4
這個檔案看上去比之前稍微複雜了一點。這是因為這裡實際定義了兩個不同的物件：deployment（第1-9行），以及它管理的pod模板（第10-17行）。
第6行是deployment的最重要部分。它定義了想要執行的pod的副本數量。本例僅僅要求一個副本，因為Gitea並非為多個pod而設計的。
這裡有另外一個新概念：label和selector。label就是使用者定義的和Kubernetes資源關聯的鍵值對。Selector用來取回和給定label查詢匹配的資源。本例中，第13行將這個deployment建立的所有pod的label設定為“app=gitea”。如果deployment一旦需要取回它建立的所有pod列表（比如，為了確保pod都是健康的），它就可以使用第8-9行定義的selector。這樣，deployment能夠通過搜尋哪些pod被指派了“app=gitea”的label來隨時跟蹤它所管理的pod。
大多數情況下，label是使用者定義的。上例中，“app”並不代表任何對於Kubernetes來說特別的東西，僅僅是一種能讓我們更方便地管理系統的方式。必須注意，確實有一些label是 Kubernetes自動指定的 ，包含系統的資訊。
YAML檔案建立好了，可以重新apply到叢集裡去了：
kubectl apply -f gitea.yaml
至此，如果執行 kubectl get pods ，我們就可以看到deployment裡指定的新pod在運行了，如下：
$ kubectl get pods NAMEREADYSTATUSRESTARTS gitea-deployment-8944989b8-5kmn20/1Running0
也可以檢視deployment本身的資訊：
$ kubectl get deployments NAMEDESIREDCURRENTUP-TO-DATEAVAILABLEAGE gitea-deployment11114m
要想驗證一切工作正常，可以嘗試用命令 kubectl delete pod <pod_name> 刪除pod。應該能夠看到一個新的pod迅速地被重新建立了。這正是deployment的神奇之處！
你也可能注意到了新pod有點奇怪，名字的一部分是隨機生成的字串。這是因為pod是deployment批量建立的，生命週期是短暫的。當在deployment裡面時， pod應該被當成cattle而不是pet 。
後續預告
現在叢集裡已經有Gitea軟體在運行了，但是我們必須找到能夠通過瀏覽器與之互動的方式。本系列下一篇文章會介紹Kubernetes網路的基本特性。本系列的後續文章還會介紹持久化儲存，環境變數等等。
原文連結： Kubernetes 110: Your First Deployment （翻譯：崔婧雯 校對：）＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
譯者介紹
崔婧雯，現就職於IBM，高階軟體工程師，負責IBM WebSphere業務流程管理軟體的系統測試工作。曾就職於VMware從事桌面虛擬化產品的質量保證工作。對虛擬化，中介軟體技術，業務流程管理有濃厚的興趣。