kubernetes之StatefulSet详解

概述

RC、Deployment、DaemonSetStatefulSet都是面向无状态的服务,它们所管理的Pod的IP、名字,启停顺序等都是随机的,而StatefulSet是什么?顾名思义,有状态的集合,管理所有有状态的服务,比如MySQL、MongoDB集群等。
StatefulSet本质上是Deployment的一种变体,它是t是为了解决有状态服务的问题,它所管理的Pod拥有固定的Pod名称,启停顺序,在StatefulSet中,Pod名字称为网络标识,还必须要用到共享存储,在v1.9版本中已成为GA版本。
在Deployment中,与之对应的服务是service,而在StatefulSet中与之对应的headless service,headless service,即无头服务,与service的区别就是它没有Cluster IP,解析它的名称时将返回该Headless Service对应的全部Pod的Endpoint列表。
除此之外,StatefulSet在Headless Service的基础上又为StatefulSet控制的每个Pod副本创建了一个DNS域名,这个域名的格式为:

$(podname).(headless server name)
FQDN: $(podname).(headless server name).namespace.svc.cluster.local

StatefulSet示例

接下来看一些示例,演示下上面所说的特性,以加深理解。

apiVersion: v1
kind: Service
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  ports:
  - port: 80
    name: web
  clusterIP: None
  selector:
    app: nginx
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web
spec:
  selector:
    matchLabels:
      app: nginx # has to match .spec.template.metadata.labels
  serviceName: "nginx"  #声明它属于哪个Headless Service.
  replicas: 3 # by default is 1
  template:
    metadata:
      labels:
        app: nginx # has to match .spec.selector.matchLabels
    spec:
      terminationGracePeriodSeconds: 10
      containers:
      - name: nginx
        image: k8s.gcr.io/nginx-slim:0.8
        ports:
        - containerPort: 80
          name: web
        volumeMounts:
        - name: www
          mountPath: /usr/share/nginx/html
  volumeClaimTemplates:   #可看作pvc的模板
  - metadata:
      name: www
    spec:
      accessModes: [ "ReadWriteOnce" ]
      storageClassName: "gluster-heketi"  #存储类名,改为集群中已存在的
      resources:
        requests:
          storage: 1Gi

通过该配置文件,可看出StatefulSet的组成部分:

  1. Headless Service,名为nginx,用来定义Pod网络标识( DNS domain)。
  2. StatefulSet,定义具体应的,名为Nginx,有三个Pod副本,并为每个Pod定义了一个域名。
  3. volumeClaimTemplates,名为www,pvc模板,指定pvc名称大小,将自动创建pvc,且pvc必须由存储类供应。
$ kubectl create -f nginx.yaml
service "nginx" created
statefulset "web" created

看下这三个Pod创建过程:

#第一个是创建web-0
$ kubectl get pod
web-0                     1/1       ContainerCreating   0          51s
#待web-0 running且ready时,创建web-1
$ kubectl get pod
web-0                     1/1       Running             0          51s
web-1                     0/1       ContainerCreating   0          42s

#待web-1 running且ready时,启动web-2
$ kubectl get pod
web-0                     1/1       Running             0          1m
web-1                     1/1       Running             0          45s
web-2                     1/1       ContainerCreating   0          36s

#最后三个Pod全部running且ready
$ kubectl get pod
NAME                      READY     STATUS    RESTARTS   AGE
web-0                     1/1       Running   0          4m
web-1                     1/1       Running   0          3m
web-2                     1/1       Running   0          1m

Statefulset 名称:web 三个副本
创建出来的Pod: web-0,web-1,web-2
volumeClaimTemplates名称为:www,那么自动创建出来的PVC名称为www-web[0-2],为每个Pod创建一个PVC。

 #根据volumeClaimTemplates自动创建的PVC
 $ kubectl get pvc
NAME              STATUS    VOLUME                                  CAPACITY   ACCESS MODES   STORAGECLASS     AGE
www-web-0         Bound     pvc-ecf003f3-828d-11e8-8815-000c29774d39   2G        RWO          gluster-heketi   7m
www-web-1         Bound     pvc-0615e33e-828e-11e8-8815-000c29774d39   2G        RWO          gluster-heketi   6m
www-web-2         Bound     pvc-43a97acf-828e-11e8-8815-000c29774d39   2G        RWO          gluster-heketi   4m

规律总结:

  • 匹配Pod name(网络标识)的模式为:$(statefulset名称)-$(序号),比如上面的示例:web-0,web-1,web-2。

    1. StatefulSet为每个Pod副本创建了一个DNS域名,这个域名的格式为: $(podname).(headless server name)
    2. StatefulSet使用Headless服务来控制Pod的域名,这个域名的FQDN为:$(service name).$(namespace).svc.cluster.local,其中,“cluster.local”指的是集群的域名。
    3. 根据volumeClaimTemplates,为每个Pod创建一个pvc,pvc匹配模式为:(volume_name)-(pod_name),
      比如上面的volumeMounts.name=www, Pod name=web-[0-2],因此创建出来的PVC是www-web-0、www-web-1、www-web-2。
    4. 删除Pod不会删除其pvc,删除pvc将自动释放pv。

Statefulset的启停顺序:
通常上面的示例发现:

  • 有序部署:部署StatefulSet时,如果有多个Pod副本,它们会被顺序地创建(从0到N-1)。
  • 有序删除:当Pod被删除时,它们被终止的顺序是从N-1到0。
  • 有序扩展:当对Pod执行扩展操作时,与部署一样,它前面的Pod必须都处于Running和Ready状态。
      
    Statefulset Pod管理策略:
    在v1.7以后,通过允许修改Pod排序策略,同时通过.spec.podManagementPolicy字段确保其身份的唯一性。
    OrderedReady: 上述的启停顺序,默认设置。
    Parallel: 告诉StatefulSet控制器并行启动或终止所有Pod,并且在启动或终止另一个Pod之前不等待前一个Pod变为Running and Ready或完全终止。

更新策略

在Kubernetes 1.7及更高版本中,通过.spec.updateStrategy字段允许配置或禁用Pod、labels、esource request/limits、annotations自动滚动更新功能。
OnDelete:通过.spec.updateStrategy.type 字段设置为OnDelete,StatefulSet控制器不会自动更新StatefulSet中的Pod。用户必须手动删除Pod,以使控制器创建新的Pod
RollingUpdate:通过.spec.updateStrategy.type 字段设置为RollingUpdate,实现了Pod的自动滚动更新,如果.spec.updateStrategy未指定,则此为默认策略。
StatefulSet控制器将删除并重新创建StatefulSet中的每个Pod。它将以Pod终止(从最大序数到最小序数)的顺序进行,一次更新每个Pod。在更新下一个Pod之前,必须等待这个Pod Running and Ready。
Partitions:通过指定 .spec.updateStrategy.rollingUpdate.partition 来对 RollingUpdate 更新策略进行分区,如果指定了分区,则当 StatefulSet 的 .spec.template 更新时,具有大于或等于分区序数的所有 Pod 将被更新。
具有小于分区的序数的所有 Pod 将不会被更新,即使删除它们也将被重新创建。如果 StatefulSet 的 .spec.updateStrategy.rollingUpdate.partition 大于其 .spec.replicas,则其 .spec.template 的更新将不会传播到 Pod。
在大多数情况下,不需要使用分区。

原文地址:http://blog.51cto.com/newfly/2140003

时间: 2024-08-01 08:21:18

kubernetes之StatefulSet详解的相关文章

kubernetes资源创建详解【持续完善中】

目录 资源创建详解 一:Pod及常用参数 1.简介 2.模板 3.删除pod 4.设置Pod主机名 5.镜像拉取策略(ImagePullPolicy) 二:RC 1.简介 2.模板 三:Deployment 1.简介 2.模板 四:HPA 1.简介 2.模板 五:StatefulSet 1.简介 2.模板 六:PV和PVC 八:扩展 8.1.Pod调度到指定的Node 资源创建详解 一:Pod及常用参数 1.简介 2.模板 3.删除pod 示例流程如下: 用户发送删除pod的命令,默认宽限期是3

K8S statefulset 详解

概述 StatefulSet    RC.Deployment.DaemonSet都是面向无状态的服务,它们所管理的Pod的IP.名字,启停顺序等都是随机的,而StatefulSet是什么?顾名思义,有状态的集合,管理所有有状态的服务,比如MySQL.MongoDB集群等.StatefulSet本质上是Deployment的一种变体,在v1.9版本中已成为GA版本,它为了解决有状态服务的问题,它所管理的Pod拥有固定的Pod名称,启停顺序,在StatefulSet中,Pod名字称为网络标识(ho

资深实践篇 | 基于Kubernetes 1.61的Kubernetes Scheduler 调度详解

欢迎大家前往腾讯云技术社区,获取更多腾讯海量技术实践干货哦~ 作者:腾讯云容器服务团队 源码为 k8s v1.6.1 版本,github 上对应的 commit id 为 b0b7a323cc5a4a2019b2e9520c21c7830b7f708e 本文将对 Scheduler 的调度算法原理和执行过程进行分析,重点介绍 Scheduler 算法中预选和优选的相关内容. Kubernetes Scheduler的基本功能 Kubernetes Scheduler 的作用是根据特定的调度算法将

kubernetes configMap详解

Kubernetes的ConfigMap说明 这篇博文,我们来说一说,关于在kubernetes的pod中自定义配置的问题. 我们知道,在几乎所有的应用开发中,都会涉及到配置文件的变更,比如说在web的程序中,需要连接数据库,缓存甚至是队列等等.而我们的一个应用程序从写第一行代码开始,要经历开发环境.测试环境.预发布环境只到最终的线上环境.而每一个环境都要定义其独立的各种配置.如果我们不能很好的管理这些配置文件,你的运维工作将顿时变的无比的繁琐.为此业内的一些大公司专门开发了自己的一套配置管理中

详解 Kubernetes Pod 的实现原理

Pod.Service.Volume 和 Namespace 是 Kubernetes 集群中四大基本对象,它们能够表示系统中部署的应用.工作负载.网络和磁盘资源,共同定义了集群的状态.Kubernetes 中很多其他的资源其实只对这些基本的对象进行了组合. Pod 是 Kubernetes 集群中能够被创建和管理的最小部署单元,想要彻底和完整的了解 Kubernetes 的实现原理,我们必须要清楚 Pod 的实现原理以及最佳实践. 在这里,我们将分两个部分对 Pod 进行解析,第一部分主要会从

Kubernetes YAML 文件全字段详解

Kubernetes YAML 文件全字段详解 Deployment yaml 其中主要参数都在podTemplate 中,DaemonSet StatefulSet 中的pod部分一样. apiVersion: v1 kind: Deployment metadata: name: <deploy-name> namespace: <ns-name> labels: <key>: <value> spec: replicas: 2 selector: ma

Docker Kubernetes Service 网络服务代理模式详解

Docker Kubernetes  Service 网络服务代理模式详解 Service service是实现kubernetes网络通信的一个服务 主要功能:负载均衡.网络规则分布到具体pod 注:kubernetes deployment服务分配服务器负载均衡VIP只能NODE节点单独访问,这里需要外网用户可以放问到容器内,这里就需要用到service. 网络代理模式 kube-proxy v1.0中只支持userspace模式,在v1.1中,添加了iptables代理,在v1.2开始ip

Docker Kubernetes 服务发现原理详解

Docker Kubernetes  服务发现原理详解 服务发现支持Service环境变量和DNS两种模式: 一.环境变量 (默认) 当一个Pod运行到Node,kubelet会为每个容器添加一组环境变量,Pod容器中程序就可以使用这些环境变量发现Service. 环境变量名格式如下: {SVCNAME}_SERVICE_HOST {SVCNAME}_SERVICE_PORT 注:其中服务名和端口名转为大写,连字符转换为下划线. 限制: 1)Pod和Service的创建顺序是有要求的,Servi

Kubernetes之yaml文件详解-v1.15.x

Kubernetes之yaml文件详解 K8S 创建资源的方式 K8S有两种创建资源的方式:kubectl 命令和 yaml 配置文件. kubectl命令行:最为简单,一条命令就OK,但缺点也很明显,你并不知道这条命令背后到底做了哪些事!yaml配置文件:提供了一种让你知其然更知其所以然的方式.优势如下: 完整性:配置文件描述了一个资源的完整状态,可以很清楚地知道一个资源的创建背后究竟做了哪些事:灵活性:配置文件可以创建比命令行更复杂的结构:可维护性:配置文件提供了创建资源对象的模板,能够重复