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则是云服务商提供的一种方案，由云服务商直接处理代理，内网外网环境均可选择；
