騰訊雲-TCE容器服務快速上手

（一）TKE簡介

　　騰訊雲容器服務（Tencent Kubernetes Engine，TKE）基於原生 kubernetes 提供以容器爲核心的、高度可擴展的高性能容器管理服務。騰訊雲容器服務徹底兼容原生 kubernetes API ，擴展了騰訊雲的雲硬盤、負載均衡等 kubernetes 插件，爲容器化的應用提供高效部署、資源調度、服務發現和動態伸縮等一系列完整功能，解決用戶開發、測試及運維過程的環境一致性問題，提升了大規模容器集羣管理的便捷性，幫助用戶下降成本，提升效率。容器服務提供無償使用，涉及的其餘雲產品(如CVM)另外單獨計費。

（二）建立TKE集羣

如今咱們來嘗試建立一個K8S集羣
1.登陸騰訊雲，進入容器服務-》集羣-》新建

2.輸入集羣相關信息
2.1集羣信息

容器網絡我選的是192網段的，操做系統選的Centos7.6
2.2選擇機型

Master節點選擇平臺託管（騰訊雲會自動建立集羣，獨立部署應該是要本身部署）
計費模式選擇按量付費（按小時付費，不足1小時好像是會按分鐘計費）
Work配置-》機型-》標準型-》所有實例類型（測試的話選一個便宜的便可，建議選1核2G）
3.雲服務器配置
登陸方式-》自動生成密碼（其餘的也能夠，主要是這個方便）
4.信息確認
確認建立便可，看一下個人最終配置

 在集羣狀態中查看進度。能夠看到，騰訊雲會自動部署相關的組件

達到如下狀態時，整個集羣纔算真正可用
集羣處於運行狀態

概述中的工做負載所有爲正常狀態，以下個人還有一個異常，須要再等一會，這個比較耗時，可能須要十分鐘甚至更久才能所有顯示正常（實際上我等了半小時仍是有這個異常，可是貌似不影響後續使用。。）

（三）部署服務

建立完集羣后，咱們能夠在集羣中搭建一個Nginx服務
1.點擊進入集羣-》工做負載-》Deployment-》新建

2.配置Deployment
輸入工做負載名

實例內容器
輸入名稱
選擇鏡像，docker hub鏡像,Nginx鏡像
選擇鏡像版本，latest便可
訪問設置
端口設置，容器端口和服務端口都選80
網絡那裏使用默認的公網訪問，其他默認便可
3.驗證Nginx服務
集羣-》服務與路由-》Service

 訪問該公網ip

（四）配置伸縮組

爲了防止集羣故障，咱們還能夠配置伸縮組。當master節點或node節點故障時，自動建立一臺新VM代替，做爲一個新的master節點或node節點
TKE有一個自動伸縮和伸縮組，我還不是搞得很明白。這裏簡單作一個記錄。按照個人理解，伸縮組應該是針對集羣裏的node節點，而自動伸縮則針對工做負載
集羣-》節點管理-》伸縮組-》新建伸縮組

輸入名稱，選擇競價付費實例類型，在標準型-》所有實例型裏選一個便宜的。至於伸縮組配置支持子網那裏我不是很懂，我是勾選了集羣所在的子網，節點數量範圍0~2

設置完成後，點擊全局配置右上角的編輯，啓用自動伸縮

自動伸縮配置以下，鎖絨配置那裏50%改成80%

 

移除咱們用來測試的集羣節點，點擊移出

騰訊雲就會自動建立出新節點代替這個故障節點

PS：實驗完畢，記得把伸縮組停用，不然刪除掉節點後，又會自動建立出新節點了

（五）持久化存儲

若是須要實現持久化存儲，可根據如下步驟操做：
1.購買一塊雲硬盤（按量計費方式），建議和K8S集羣在同一個區

 

 2.新建一個pv

 

 pv配置以下：
選擇新購買的雲硬盤

 

 3.更新pod配置

 

配置以下：
須要注意的是，要先配置好數據卷，實例內容器裏纔會顯示掛載點。自行配置便可，這裏只作簡單介紹

（六）名詞解釋

命名空間：
經過命名空間實現對不一樣項目的管理，各命名空間互不干擾，命名空間名詞惟一，但不一樣命名空間裏的資源命名能夠同名（只要不是同一個命名空間裏便可）
工做負載：
工做負載(也就是控制器)有多種類型：deployment，statefulset，deamonset，job，cronjob
Deployment：工做在ReplicaSet之上，用於管理無狀態應用，目前來講用得比較多的控制器。支持滾動升級和回滾應用以及擴容和縮容，還提供聲明式配置。
DaemonSet：用於確保集羣中的每個節點只運行特定的pod副本，一般用於實現系統級後臺任務。主要用於運行一個守護性的pod,好比ELK服務
Job：只要完成就當即退出，不須要重啓或重建。
Cronjob：週期性任務控制，不須要持續後臺運行，
StatefulSet：管理有狀態應用。和其餘控制器相比，StatefulSet支持固定的身份ID，經過這個ID，集羣中的成員能夠相互發現而且通訊，而Deployment每次重啓都會變動地址
ReplicaSet: 代用戶建立指定數量的pod副本數量，確保pod副本數量符合預期狀態，而且支持滾動式自動擴容和縮容功能。ReplicationController(RC)和ReplicaSet(RS)，新版本的k8s,Rs取代了Rc,RC與RS沒有本質不一樣，只是RS支持集合式的selecor,經過標籤label
Service：
用於用戶端發現pod服務，獲取pod地址，感知pod故障。
每一個 Pod 都有本身的 IP 地址。當 controller 用新 Pod 替代發生故障的 Pod 時，新 Pod 會分配到新的 IP 地址，從而致使客戶端沒法訪問到該服務，service則是用來解決這個問題的。
訪問service的請求來源有兩種：k8s集羣內部的程序（Pod）和 k8s集羣外部的程序。
採用微服務架構時，做爲服務全部者，除了實現業務邏輯之外，還須要考慮如何把服務發佈到k8s集羣或者集羣外部，使這些服務可以被k8s集羣內的應用、其餘k8s集羣的應用以及外部應用使用。所以k8s提供了靈活的服務發佈方式，用戶能夠經過ServiceType來指定如何來發布服務，類型有如下幾種：
ClusterIP：提供一個集羣內部的虛擬IP以供Pod訪問（service默認類型)。
NodePort:在每一個Node上打開一個端口以供外部訪問
LoadBalancer：經過外部的負載均衡器來訪問
Ingress：
暴露了service的三種方式ClusterIP、NodePort與LoadBalance，這幾種方式都是在service的維度提供的，service的做用體如今兩個方面，對集羣內部，它不斷跟蹤pod的變化，更新endpoint中對應pod的對象，提供了ip不斷變化的pod的服務發現機制，對集羣外部，他相似負載均衡器，能夠在集羣內外部對pod進行訪問。可是，單獨用service暴露服務的方式，在實際生產環境中不太合適：
ClusterIP的方式只能在集羣內部訪問。
NodePort方式的話，測試環境使用還行，當有幾十上百的服務在集羣中運行時，NodePort的端口管理是災難。
LoadBalance方式受限於雲平臺，且一般在雲平臺部署ELB還須要額外的費用。
所幸k8s還提供了一種集羣維度暴露服務的方式，也就是ingress。ingress能夠簡單理解爲service的service，他經過獨立的ingress對象來制定請求轉發的規則，把請求路由到一個或多個service中。這樣就把服務與請求規則解耦了，能夠從業務維度統一考慮業務的暴露，而不用爲每一個service單獨考慮。
PV/PVC:
PersistentVolume（pv）和PersistentVolumeClaim（pvc）是k8s提供的兩種API資源，用於抽象存儲細節。管理員關注於如何經過pv提供存儲功能而無需
關注用戶如何使用，一樣的用戶只須要掛載pvc到容器中而不須要關注存儲卷採用何種技術實現。pvc和pv的關係與pod和node關係相似，前者消耗後者的資源。pvc能夠向pv申請指定大小的存儲資源並設置訪問模式,這就能夠經過Provision -> Claim 的方式，來對存儲資源進行控制。

pvc和pv的關係與pod和node關係相似，前者消耗後者的資源。pvc能夠向pv申請指定大小的存儲資源並設置訪問模式,這就能夠經過Provision -> Claim 的方式，來對存儲資源進行控制。