TKE中Kuberntes集群已经部署完成后,现在我们需要了解哪些东西,为后续选型使用呢?
Deployment为Pod和ReplicaSet提供一个声明式定义(declarative)[1],用来替代以前的ReplicationController来方便的管理应用。
典型的应用场景包括;
DaemonSet确保全部(或者一些)Node上运行一个Pod的副本。当有Node加入集群时,也会为他们新增一个Pod。当有Node从集群移除时,这些Pod也会被回收。删除DaemonSet将会删除它创建的所有Pod
使用DamonSet的一些典型用法:
gmond
StatefulSet作为Controller为Pod提供唯一的标识。它可以保证部署和scale的顺序;
StatefulSet是为了解决有状态服务的问题(对应Deployment和ReplicaSet是为无状态服务而设计),其应用场景包括:
Job负责批处理任务,即仅执行一次的任务,它保证批处理任务的一个或多个Pod成功结束。
CronJob管理基于时间的Job,即:
使用前提条件:当前使用的Kubernetes集群,版本>=1.8(对CronJob),对于先前版本的集群,版本<1,8,启动PI Server时,通过传递选项 --runtime-config=batch/v2alpha1=true
可以开启batch/v2alpha1API
典型的用法如下所示:
Kubernetes Service
定义了这样一种抽象:一个pod
的逻辑分组,一种可以访问它们的策略——通常称为微服务。这一组Pod
能够被Service
访问到,通常是通过 Label Selector
。
Service在 Kubernetes 中有以下四种类型:
ClusterIP主要在每个 node节点使用 iptables/ipvs,将发向 clusterIP对应端口的数据,转发到 kube-proxy中。然后 kube-proxy 自己内部实现有负载均衡的方法,并可以查询到这个 service 下对应 pod 的地址和端口,进而把数据转发给对应的 pod的地址和端口。
有时不需要或不想要负载均衡,以及单独的Service IP。遇到这种情况,可以通过指定 Cluster IP(spec.clusterIP)的值为“None”来创建Headless Service。这类Service 并不会分配Cluster IP,kube-proxy 不会处理它们,而且平台也不会为它们进行负载均衡和路由。<无头服务>
nodePort 的原理在于在 node 上开了一个端口,将向该端口的流量导入到 kube-proxy,然后由 kube-proxy 进一步到给对应的 pod。
loadBalancer 和 nodePort 其实是同一种方式。区别在于loadBalancer 比 nodePort 多了一步,就是可以调用 cloud provider 去创建 LB 来向节点导流。
Service 能够提供负载均衡的能力,但是在使用上有以下限制:
对于控制器的选择:
对于Service的选择:
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。