什么是StatefulSet?
直接参考原博客:k8s配置StatefulSet

  • StatefulSet和Deployment一样,可以保证集群中运行指定个数的pod,也支持横向扩展,但每个pod都是不可互换的。无论pod被怎样调度,它们的标记都不会改变,StatefulSet所创建的pod都是有状态的,所以pod重新调度之后,和它绑定的存储仍然是原先那个

StatefulSet的一些限制和要求
pod的存储必须使用StorageClass关联的PVC提供,或者由管理员预先创建好。
删除StatefulSet或者是减小StatefulSet的replicas,k8s不会自动删除和已终止运行的pod绑定的数据卷。这样做是为了保证数据安全。
为了确保StatefulSet管理的每个pod的网络标识不同,需要创建对应的headless service。
当StatefulSet被删除的时候,它不能保证所有被管理的pod都停止运行。因此,在删除StatefulSet之前,需要先将它scale到0个pod。
pod管理策略使用默认的OrderedReady,进行滚动升级的时候可能会出现问题,需要手工修复。
StatefulSet的描述文件

apiVersion: apps/v1
kind: StatefulSet
metadata:
  annotations:
    auther: bigcc
  name: test-service
  namespace: default
spec:
  serviceName: test-service
  replicas: 1
  selector:
    matchLabels:
      app: test-service
  template:
    metadata:
      labels:
        app: test-service
        env: t1
        sys: test
    spec:
      containers:
      - name: test-service
        image: harbor.com/test-service:latest
        imagePullPolicy: Always
        livenessProbe:
          initialDelaySeconds: 30
          periodSeconds: 60
          timeoutSeconds: 5
          tcpSocket:
            port: 80
        readinessProbe:
          initialDelaySeconds: 30
          periodSeconds: 60
          timeoutSeconds: 5
          httpGet:
            scheme: HTTP
            port: 9260
            path: /health
        env:
        - name: JAVA_OPTS
          value: -Didc=t1 -Denv=UAT -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/usr/local/test-service
            -XX:+UseParallelGC -XX:MaxGCPauseMillis=1500 -XX:GCTimeRatio=9 -XX:+DisableExplicitGC
            -Dfile.encoding=UTF8 -Xms2048m -Xmx2048m -Xss512k
            -Dskywalking.agent.service_name=test-service-t1 -Dskywalking.collector.backend_service=10.1.1.1:11800
            -Dnoah.app.home=/usr/local/test-service/ -Dnoah.app.name=test-service -Dnoah.cat.servers=cathome.test.bigcc.com
            -Dnoah.host.type=Container -Dnoah.app.env=SIT -Dnoah.app.idc=aliyun -Dnoah.app.cluster=t1
        - name: CONFIG
          value: --eureka.client.serviceUrl.defaultZone=http://10.1.1.1:8761/eureka/
        - name: POD_IP
          valueFrom:
            fieldRef:
              apiVersion: v1
              fieldPath: status.podIP
        lifecycle:
          preStop:
            exec:
              command:
              - /bin/sh
              - -c
              - curl -X PUT http://10.1.1.1:8761/eureka/apps/test-service/${POD_IP}:9260/status?value=OUT_OF_SERVICE;sleep
                120
        resources:
          limits:
            memory: 4Gi
            cpu: 2000m
          requests:
            memory: 2048Mi
            cpu: 1000m
        ports:
        - containerPort: 9260
          protocol: TCP
        volumeMounts:
        - name: logdata
          mountPath: /usr/local/test-service/logs/
      - name: logtail
        image: harbor.com/tool/logtail:latest
        command:
        - sh
        - -c
        - /usr/local/ilogtail/run_logtail.sh 10
        livenessProbe:
          exec:
            command:
            - /etc/init.d/ilogtaild
            - status
          initialDelaySeconds: 30
          periodSeconds: 30
        resources:
          limits:
            memory: 512Mi
          requests:
            memory: 512Mi
        env:
        - name: ALIYUN_LOGTAIL_USER_ID
          value: '12345678'
        - name: ALIYUN_LOGTAIL_USER_DEFINED_ID
          value: test-service-t1
        - name: ALIYUN_LOGTAIL_CONFIG
          value: /etc/ilogtail/conf/cn-shanghai/ilogtail_config.json
        - name: ALIYUN_LOG_ENV_TAGS
          value: _pod_name_|_pod_ip_|_namespace_|_node_name_|_node_ip_
        - name: _pod_name_
          valueFrom:
            fieldRef:
              fieldPath: metadata.name
        - name: _pod_ip_
          valueFrom:
            fieldRef:
              fieldPath: status.podIP
        - name: _namespace_
          valueFrom:
            fieldRef:
              fieldPath: metadata.namespace
        - name: _node_name_
          valueFrom:
            fieldRef:
              fieldPath: spec.nodeName
        - name: _node_ip_
          valueFrom:
            fieldRef:
              fieldPath: status.hostIP
        volumeMounts:
        - name: logdata
          mountPath: /usr/local/test-service/logs/
      volumes:
      - name: logdata
        emptyDir: {}

pod标识
StatefulSet中每个pod的标识都是不同的。pod标识包含一个整数序号,固定的网络标识和存储标识。无论pod被调度到哪个节点运行,这些标识始终会跟随这个pod,如果StatefulSet运行了n个pod,这些pod会被编号,从0到n - 1。
网络标识
建立了对应的headless service之后,StatefulSet每个pod对应的DNS遵循如下的命名规则:
( s t a t e f u l s e t n a m e ) − (statefulset name)- (statefulsetname)(ordinal). ( s e r v i c e n a m e ) . (service name). (servicename).(namespace).svc.cluster.local
#例如:web-0.nginx.default.svc.cluster.local
存储标识
每个pod都分配了一个单独的PV,PV和pod是强关联的。如果pod意外停止,无论再次启动的时候被调度到了何处,它仍然绑定到之前相同的PV上。如果这个pod,甚至是StatefulSet被删除,PV也不会被自动删除,需要手工操作。
pod命名标签
StatefulSet创建pod的时候会自动为pod添加一个statefulset.kubernetes.io/pod-name标签。可用于专门为某个特定的pod绑定service。
StatefulSet的部署和扩缩容
需要注意如下几点:

StatefulSet创建pod的时候是串行化按照顺序执行,从0创建到n-1。
删除pod的时候(比如缩容),按照相反的方向操作,即先删除pod n-1,在删除pod n-2,直到pod0。
创建StatefulSet或者是扩容的之后,当且仅当一个pod运行成功进入就绪状态的时候,下一个pod才会开始创建。
同理,StatefulSet缩容的时候,当且仅当一个pod彻底停止之后,下一个pod才会开始停止过程。
StatefulSet不应该配置pod.Spec.TerminationGracePeriodSeconds为0,会有潜在的问题。
Pod管理策略
配置项位于.spec.podManagementPolicy。用来配置pod的创建和销毁是否可以并行操作。有如下两个配置值:

OrderedReady:pod安装顺序创建和销毁。且每个pod的创建和销毁都必须要求前一个pod已经完全创建或销毁完毕。这个是默认的行为。
Parallel:允许同时创建和销毁多个pod,不必等待前一个pod创建或销毁完毕。仅仅对扩容缩容有效,pod update过程不受影响。
升级策略
用来配置滚动升级的行为。配置项位于.spec.updateStrategy。
可供配置的值如下:

OnDelete:.spec.updateStrategy.type设置为OnDelete时,如果pod发生更新,StatefulSet不会更新已经运行的pod,必须将这些pod手工删除。新创建出来的pod是已更新过的pod。
RollingUpdate:如果没有配置.spec.updateStrategy,默认使用这个配置。.spec.updateStrategy.type设置为RollingUpdate时,如果发生pod更新,StatefulSet会挨个删除并重新创建所有的pod。操作的顺序为从pod n-1 到 pod0,。即先删除pod n-1,等它彻底停止后,创建新的pod n-1。等pod n-1进入ready状态后,删除pod n-2 ……以此类推,直到操作完pod0。
partition:配置一个.spec.updateStrategy.rollingUpdate.partition整数值。发生更新的时候,所有序号大于等于partition的pod会更新,所有序号小于partition的pod不会更新。即便是把序号小于partition的pod删除了,pod还是会按照之前的版本创建,不会更新。
强制回滚
如果滚动升级发生问题,某个pod总是无法进入就绪状态,StatefulSet会停止滚动升级,进入等待状态。发生这种情况的时候,仅仅将pod template修改正确是不够的。必须手工将无法启动的pod删除掉,StatefulSet会重新以正确的配置创建pod。否则StatefulSet仍会处于无限等待状态。
需要注意
StatefulSet会最大程度确保序号相同的pod同时只运行1个。
比如说这个场景:

集群中某个节点突然和集群失去网络联系,这个节点又恰好运行了某StatefulSet的一个pod。此时,这个pod不会立刻停止运行,状态会改变为Unknown。
如果操作集群其他正常节点,手工删除这个pod,这个pod也不会真正删除,仅会被标记为删除(mark for deletion)。这时候k8s不会创建序号相同的pod,直到那个失去连接的节点重新连接到集群,k8s才会把这个pod删除,并创建出新的序号相同的pod。
如果需要强制删除这个pod,可以执行如下命令(web-0为要强制删除的pod名称):
kubectl delete po web-0 --force --grace-period 0

Logo

K8S/Kubernetes社区为您提供最前沿的新闻资讯和知识内容

更多推荐