腾讯云-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 的方式，来对存储资源进行控制。