从无到有基于腾讯云TKE部署Kubernetes全流程（二）

TKE中Kuberntes集群已经部署完成后，现在我们需要了解哪些东西，为后续选型使用呢？

常用控制器类型

• Deployment
• DaemonSet
• StateFulSet
• Job/CronJob

Deployment

Deployment为Pod和ReplicaSet提供一个声明式定义（declarative）[1]，用来替代以前的ReplicationController来方便的管理应用。

典型的应用场景包括；

• 定义Deployment来创建Pod和ReplicaSet Deployment=>RS=>Pod
• 滚动升级和回滚应用
• 扩容和缩容
• 暂停和继续Deployment

DaemonSet

DaemonSet确保全部（或者一些）Node上运行一个Pod的副本。当有Node加入集群时，也会为他们新增一个Pod。当有Node从集群移除时，这些Pod也会被回收。删除DaemonSet将会删除它创建的所有Pod

使用DamonSet的一些典型用法：

• 运行集群存储daemon，例如在每个Node上运行glusterd、ceph
• 在每个Node上运行日志收集daemon，例如fluentd、logstash
• 在每个Node上运行监控daemon，例如Prometheus Node Exporter、collectd、Datadog代理、New Relic代理，或Ganglia gmond

StatefulSet

StatefulSet作为Controller为Pod提供唯一的标识。它可以保证部署和scale的顺序；

StatefulSet是为了解决有状态服务的问题（对应Deployment和ReplicaSet是为无状态服务而设计），其应用场景包括：

• 稳定的持久化存储，即Pod重新调度后还是能访问到相同的持久化数据，基于PVC来实现；
• 稳定的网络标志，即Pod重新调度后其PodName和HostName不变，基于Headless Service（即没有Cluster IP的Service）来实现；
• 有序部署，有序扩展，即Pod是有顺序的，在部署或者扩展的时候要依据定义的顺序依次进行（即从0到N-1，在下一个Pod运行之前的Pod必须都是Running和Ready状态），基于init containers来实现；
• 有序收缩，有序删除（即从N-1到0）。

Job

Job负责批处理任务，即仅执行一次的任务，它保证批处理任务的一个或多个Pod成功结束。

CronJob

CronJob管理基于时间的Job,即：

• 在给定时间点只运行一次；
• 周期性地在给定时间点运行。

使用前提条件：当前使用的Kubernetes集群，版本>=1.8（对CronJob）,对于先前版本的集群，版本<1,8，启动PI Server时，通过传递选项 --runtime-config=batch/v2alpha1=true 可以开启batch/v2alpha1API

典型的用法如下所示：

• 在给定的时间点调度Job运行；
• 创建周期性运行的Job，例如：数据库备份、发送邮件。

Service 的概念

Kubernetes Service 定义了这样一种抽象：一个pod的逻辑分组，一种可以访问它们的策略——通常称为微服务。这一组Pod能够被Service访问到，通常是通过 Label Selector。

Service 的类型

Service在 Kubernetes 中有以下四种类型：

• ClusterIP：默认类型，自动分配一个仅Cluster内部可以访问的虚拟IP；
• NodePort：在ClusterIP基础上为Service在每台机器上绑定一个端口，这样就可以通过<NodeIP>:<NodePort> 来访问服务；
• LoadBalancer：在NodePort的基础上，借助cloud provider 创建一个外部负载均衡器，并将请求转发到<NodeIP>:<NodePort>；
• ExternalName：把集群外部的服务引入到集群内部来，在集群内部直接使用。没有任何类型代理被创建，这只有Kubernetes1.7或更高版本的kube-dns才支持。

ClusterIP

ClusterIP主要在每个 node节点使用 iptables/ipvs，将发向 clusterIP对应端口的数据，转发到 kube-proxy中。然后 kube-proxy 自己内部实现有负载均衡的方法，并可以查询到这个 service 下对应 pod 的地址和端口，进而把数据转发给对应的 pod的地址和端口。

• apiserver 用户通过kubectl 命令向apiserver 发送创建service的命令，apiserver 接收到请求后将数据存储到etcd中；
• kube-proxy kubernetes 的每个节点中都有一个叫做 kube-proxy 的进程，这个进程负责感知service，pod的变化，并将变化的信息写入本地的iptables/ipvs规则中；
• iptables/ipvs 使用NAT等技术将 virtualIP 的流量转至 endpoint中。

Headless Service

有时不需要或不想要负载均衡，以及单独的Service IP。遇到这种情况，可以通过指定 Cluster IP（spec.clusterIP）的值为“None”来创建Headless Service。这类Service 并不会分配Cluster IP，kube-proxy 不会处理它们，而且平台也不会为它们进行负载均衡和路由。<无头服务>

NodePort

nodePort 的原理在于在 node 上开了一个端口，将向该端口的流量导入到 kube-proxy，然后由 kube-proxy 进一步到给对应的 pod。

LoadBalancer

loadBalancer 和 nodePort 其实是同一种方式。区别在于loadBalancer 比 nodePort 多了一步，就是可以调用 cloud provider 去创建 LB 来向节点导流。

Service 能够提供负载均衡的能力，但是在使用上有以下限制：

• 只提供4层工作负载均衡能力，而没有7层能力，但有时我们可能需要更多的匹配规则来转发请求，这点上4层负载均衡是不支持的，所以Kuberntes有另外一个东西 Ingress 来解决7层的代理策略。

总结：

对于控制器的选择：

• 无状态服务一般常用 Deployment；
• 有状态服务类型各种 DB采用 StatefulSet的方式，并且搭配不同的PV/PVC从而实现持久化

对于Service的选择：

• 无状态服务常用 ClusterIP，配合Ingress进行根据域名路径的匹配调度；
• 有状态服务则可以采用Headless Service的方式，直接解析出对于的Pod地址进行访问，免去调度环节；
• NodePort则是解决部分服务服务需要集群外部访问，而又不想通过Ingress，且不想使用LoadBalancer；
• LoadBalancer则是云服务商提供的一种方案，由云服务商直接处理代理，内网外网环境均可选择；