k8s配置StatefulSet解读

什么是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 se t nam e) -$ (ordinal). $(ser v i ce nam e) .$ (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

k8s配置StatefulSet解读

猜你喜欢