第一次部署Kubernetes

如果閱讀過這篇《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[1]裡的第一部分，先註冊一個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下[2]面。還應該能在GCE下[3]面看到預配為節點的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

NAME        READY     STATUS    RESTARTS   AGE
gitea-pod   1/1       Running   0          9m

如果需要更多資訊，可以使用如下命令檢視容器的標準輸出：

$ 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

NAME                               READY     STATUS     RESTARTS
gitea-deployment-8944989b8-5kmn2   0/1       Running    0

也可以檢視Deployment本身的資訊：

$ kubectl get deployments

NAME               DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
gitea-deployment   1         1         1            1           4m

要想驗證一切工作正常，可以嘗試用命令kubectl delete pod 刪除Pod。應該能夠看到一個新的Pod迅速地被重新建立了。這正是Deployment的神奇之處！

你也可能註意到了新Pod有點奇怪，名字的一部分是隨機生成的字串。這是因為Pod是Deployment批次建立的，生命週期是短暫的。當在Deployment裡面時，Pod應該被當成cattle而不是pet。

後續預告

現在集群裡已經有Gitea軟體在運行了，但是我們必須找到能夠透過瀏覽器與之互動的方式。本系列下一篇文章會介紹Kubernetes網路的基本特性。本系列的後續文章還會介紹持久化儲存，環境變數等等。

相關連結：

1. https://cloud.google.com/kubernetes-engine/docs/quickstart

2. https://console.cloud.google.com/kubernetes

3. https://console.cloud.google.com/compute

原文連結：https://medium.com/google-cloud/kubernetes-110-your-first-deployment-bf123c1d3f8

Kubernetes應用實戰培訓

Kubernetes應用實戰培訓將於2018年10月19日在上海開課，3天時間帶你係統學習Kubernetes。本次培訓包括：容器特性、映象、網路；Docker特性、架構、元件、概念、Runtime；Docker安全；Docker實踐；Kubernetes架構、核心元件、基本功能；Kubernetes設計理念、架構設計、基本功能、常用物件、設計原則；Kubernetes的實踐、執行時、網路、外掛已經落地經驗；微服務架構、DevOps等，點選下方圖片檢視詳情。