（一）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 的方式，來對存儲資源進行控制。