Kubernetes服务之StatefulSets简介
来源:互联网 发布:网络客服招聘 编辑:程序博客网 时间:2024/06/03 18:45
StatefulSets在v1.5时还是个beta特性,它取代了v1.4的PetSets特性。PetSets的用户可以参考v1.5的升级指导,将正在运行的PeetSets升级到StatefulSets。
StatefulSet是一个给Pod提供唯一标志的控制器,它可以保证部署和扩展的顺序。
使用StatefulSet
当应用有以下任意要求时,StatefulSet的价值就体现出来了。
● 稳定的、唯一的网络标识。
● 稳定的、持久化的存储。
● 有序的、优雅的部署和扩展。
● 有序的、优雅的删除和停止。
上面提到的点中,在Pod调度时,稳定性和持久化是同一个意思。如果一个应用不需要任何稳定的标识或顺序的部署、删除和扩展,那么你应该使用提供无状态备份的控制器来部署你的应用。诸如Deployment或者ReplicaSet可能更适合你的无状态服务需求。
限制
● StatefulSet还是beta版本,Kubernetes v1.5之前不可用。
● 和所有的alpha/beta资源一样,可以将–runtime-config选项传递给apiserver,来禁止StatefulSet。
● 给定Pod的存储必须是:基于请求存储等级(Storage Class)的PersistentVolume Provisioner,或者是由管理员预先配置。
● 删除和(或)减少StatefulSet副本,不会删除StatefulSet相关的卷。这样做是为了保证数据安全,比自动的清除StatefulSet相关资源更有价值。
● 当前StatefulSet需要Headless服务来负责Pod的网络一致性。你需要创建该服务。
● 当前,更新已经存在的StatefulSet需要手动执行。
组件
下面的示例演示了StatefulSet的组件。
● 一个Headless服务,名为nginx,用来控制网络域。
● StatefulSet,名为web,在同一个Pod中起3个nginx容器的副本。
● volumeClaimTemplates使用PV供应商的PV来提供稳定的存储。
---apiVersion: v1kind: Servicemetadata: name: nginx labels: app: nginxspec: ports: - port: 80 name: web clusterIP: None selector: app: nginx---apiVersion: apps/v1beta1kind: StatefulSetmetadata: name: webspec: serviceName: "nginx" replicas: 3 template: metadata: labels: app: nginx spec: terminationGracePeriodSeconds: 10 containers: - name: nginx image: gcr.io/google_containers/nginx-slim:0.8 ports: - containerPort: 80 name: web volumeMounts: - name: www mountPath: /usr/share/nginx/html volumeClaimTemplates: - metadata: name: www annotations: volume.beta.kubernetes.io/storage-class: anything spec: accessModes: [ "ReadWriteOnce" ] resources: requests: storage: 1Gi
Pod一致性
StatefulSet Pod有着唯一的一致性,该一致性包含次序(启动和停止次序)、稳定的网络一致性,和稳定的网络。该一致性和Pod紧密相关,无论Pod被调度到哪个node节点上。
次序索引
对于有N个副本的StatefulSet,StatefulSet的每个Pod都被分配了一个数字序号,序号在[0,N)的范围内,并且在Set中是唯一的。
稳定的网络ID
StatefulSet中每个Pod都从StatefulSet的名称和Pod的序号派生其主机名。组成的hostname的模式为$(statefulset名称)-$(序号)
。上面的例子会创建名为web-0,web-1,web-2
。StatefulSet可以以使用Headless服务来控制Pod的域,这个域使用的格式为:$(service name).$(namespace).svc.cluster.local
,其中,“cluster.local”指的是集群域。Pod被创建后,每个Pod都会得到一个匹配的DNS子域,格式为$(podname).$(governing service domain)
,其中的“governing service”是在StatefulSet中通过serviceName
字段来定义的。
这里有几个示例,可以展示StatefulSet的Pod的DNS组成。
注意:除非另外的配置,集群域就会被设置为cluster.local
。
稳定的存储
Kubernetes为每个VolumeClaimTemplate创建一个PV。在上面的nginx例子中,每个Pod会得到一个PV,该PV的存储等级(storagee class)为anything
,大小为1Gb。当Pod被调度到其他node节点上时,volumeMounts
会重新映射对应的PVC。注意,当Pod或者StatefulSet被删除时,对应的PV和PVC不会被删除,这个删除操作必须手动来执行。
部署和扩展
● 对于拥有N个拷贝的StatefulSet,当部署Pod时,它们会被顺序地创建(从0到N-1)。
● 当Pod被删除时,它们被终止的顺序是从N-1到0。
● 当对Pod执行扩展操作时,它前面的Pod必须都处于Running和Ready
状态。
● 当Pod被终止时,它所有的successors都必须被完全地关闭。
不应该将StatefulSet的pod.Spec.TerminationGracePeriodSeconds
值设置为0,因为该操作不安全,强烈不建议使用。若需要更深层次的解释,请参考强制删除StatefulSet Pod。
当创建了上面的nginx示例后,会按顺序部署三个Pod,名字依次为web-0、web-1和web-2。web–1在web-0变为Running and Ready之后才会再部署,同理,web-2也会等web-1变为Running and Ready状态后才部署。如果在web-1变为Running and Ready之后,但web-2还没有启动之前,此时web-0运行失败了,那么直到web-0再次成功启动并变为Running and Ready之前,web-2都不会启动。
如果用户希望改变上面例子中Pod的个数,比如修改replicas=1
,那么web-2首先被终止。直到web-2完全被关闭和删除后,web-1才会被终止。如果在web-2被终止和完全关闭后,但web-1还没有被终止之前,此时web-0运行出错了,那么直到web-0再次变为Running and Ready状态之后,web-1才会被终止。
- Kubernetes服务之StatefulSets简介
- Kubernetes对象之StatefulSets(有状态系统服务设计)
- kubernetes 1.5 说说StatefulSets
- kubernetes+docker监控之简介
- kubernetes基础入门之-配置kubernetes skyDNS服务
- Kubernetes存储之Persistent Volumes简介
- Kubernetes存储之Persistent Volumes简介
- Kubernetes简介
- kubernetes简介
- kubernetes简介
- kubernetes简介
- kubernetes简介
- Kubernetes服务之“运行单实例的有状态服务”
- Kubernetes服务之“运行单实例的有状态服务”
- Kubernetes之健康检查与服务依赖处理
- 初试 Kubernetes 暴漏服务类型之 Nginx Ingress
- Kubernetes DNS服务配置
- kubernetes-外部服务管理
- AxonFramework,SpringBoot自动配置
- OC基础-静态类型,动态类型,编译检查,运行检查,父子类指针和对象互指17
- Element对象的firstchild和lastChild获取属性值的undefined问题
- JBDC+mysql Notes
- Window7旗舰64位SP1下安装MariaDB10.2.6
- Kubernetes服务之StatefulSets简介
- LEetCode(6)
- uwsgi+django+nginx+supervisor部署web应用(python)
- 关于为什么element对象的childNodes属性返回值有偏差的问题解释(知其所以然)
- kernel (I) basic learning
- Python设计模式-解释器模式
- ubuntu16.04 安装有道词典
- Python设计模式-中介者模式
- Python设计模式-备忘录模式