歡迎光臨
每天分享高質量文章

第一次部署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等,點擊下方圖片查看詳情。

赞(0)

分享創造快樂