web-dev-qa-db-fra.com

Redémarrage du déploiement de Kubectl pour le jeu avec état

Selon les kubectl docs , kubectl rollout restart s'applique aux déploiements, aux démons et aux ensembles d'états. Il fonctionne comme prévu pour les déploiements. Mais pour les jeux avec état, il redémarre un seul pod des 2 pods.

✗ k rollout restart statefulset alertmanager-main                       (playground-fdp/monitoring)
statefulset.apps/alertmanager-main restarted

✗ k rollout status statefulset alertmanager-main                        (playground-fdp/monitoring)
Waiting for 1 pods to be ready...
Waiting for 1 pods to be ready...
statefulset rolling update complete 2 pods at revision alertmanager-main-59d7ccf598...

✗ kgp -l app=alertmanager                                               (playground-fdp/monitoring)
NAME                  READY   STATUS    RESTARTS   AGE
alertmanager-main-0   2/2     Running   0          21h
alertmanager-main-1   2/2     Running   0          20s

Comme vous pouvez le voir, le pod alertmanager-main-1 a été redémarré et son âge est de 20 ans. Alors que l'autre pod dans le gestionnaire d'alerte avec état, c'est-à-dire le pod alertmanager-main-0 n'a pas été redémarré et son âge est de 21h. Une idée de la façon dont nous pouvons redémarrer un statefulset après la mise à jour d'une configmap utilisée par celui-ci?

[Mise à jour 1] Voici la configuration du jeu avec état. Comme vous pouvez le voir, le .spec.updateStrategy.rollingUpdate.partition n'est pas défini.

apiVersion: apps/v1
kind: StatefulSet
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"monitoring.coreos.com/v1","kind":"Alertmanager","metadata":{"annotations":{},"labels":{"alertmanager":"main"},"name":"main","namespace":"monitoring"},"spec":{"baseImage":"10.47.2.76:80/alm/alertmanager","nodeSelector":{"kubernetes.io/os":"linux"},"replicas":2,"securityContext":{"fsGroup":2000,"runAsNonRoot":true,"runAsUser":1000},"serviceAccountName":"alertmanager-main","version":"v0.19.0"}}
  creationTimestamp: "2019-12-02T07:17:49Z"
  generation: 4
  labels:
    alertmanager: main
  name: alertmanager-main
  namespace: monitoring
  ownerReferences:
  - apiVersion: monitoring.coreos.com/v1
    blockOwnerDeletion: true
    controller: true
    kind: Alertmanager
    name: main
    uid: 3e3bd062-6077-468e-ac51-909b0bce1c32
  resourceVersion: "521307"
  selfLink: /apis/apps/v1/namespaces/monitoring/statefulsets/alertmanager-main
  uid: ed4765bf-395f-4d91-8ec0-4ae23c812a42
spec:
  podManagementPolicy: Parallel
  replicas: 2
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      alertmanager: main
      app: alertmanager
  serviceName: alertmanager-operated
  template:
    metadata:
      creationTimestamp: null
      labels:
        alertmanager: main
        app: alertmanager
    spec:
      containers:
      - args:
        - --config.file=/etc/alertmanager/config/alertmanager.yaml
        - --cluster.listen-address=[$(POD_IP)]:9094
        - --storage.path=/alertmanager
        - --data.retention=120h
        - --web.listen-address=:9093
        - --web.external-url=http://10.47.0.234
        - --web.route-prefix=/
        - --cluster.peer=alertmanager-main-0.alertmanager-operated.monitoring.svc:9094
        - --cluster.peer=alertmanager-main-1.alertmanager-operated.monitoring.svc:9094
        env:
        - name: POD_IP
          valueFrom:
            fieldRef:
              apiVersion: v1
              fieldPath: status.podIP
        image: 10.47.2.76:80/alm/alertmanager:v0.19.0
        imagePullPolicy: IfNotPresent
        livenessProbe:
          failureThreshold: 10
          httpGet:
            path: /-/healthy
            port: web
            scheme: HTTP
          periodSeconds: 10
          successThreshold: 1
          timeoutSeconds: 3
        name: alertmanager
        ports:
        - containerPort: 9093
          name: web
          protocol: TCP
        - containerPort: 9094
          name: mesh-tcp
          protocol: TCP
        - containerPort: 9094
          name: mesh-udp
          protocol: UDP
        readinessProbe:
          failureThreshold: 10
          httpGet:
            path: /-/ready
            port: web
            scheme: HTTP
          initialDelaySeconds: 3
          periodSeconds: 5
          successThreshold: 1
          timeoutSeconds: 3
        resources:
          requests:
            memory: 200Mi
        terminationMessagePath: /dev/termination-log
        terminationMessagePolicy: File
        volumeMounts:
        - mountPath: /etc/alertmanager/config
          name: config-volume
        - mountPath: /alertmanager
          name: alertmanager-main-db
      - args:
        - -webhook-url=http://localhost:9093/-/reload
        - -volume-dir=/etc/alertmanager/config
        image: 10.47.2.76:80/alm/configmap-reload:v0.0.1
        imagePullPolicy: IfNotPresent
        name: config-reloader
        resources:
          limits:
            cpu: 100m
            memory: 25Mi
        terminationMessagePath: /dev/termination-log
        terminationMessagePolicy: File
        volumeMounts:
        - mountPath: /etc/alertmanager/config
          name: config-volume
          readOnly: true
      dnsPolicy: ClusterFirst
      nodeSelector:
        kubernetes.io/os: linux
      restartPolicy: Always
      schedulerName: default-scheduler
      securityContext:
        fsGroup: 2000
        runAsNonRoot: true
        runAsUser: 1000
      serviceAccount: alertmanager-main
      serviceAccountName: alertmanager-main
      terminationGracePeriodSeconds: 120
      volumes:
      - name: config-volume
        secret:
          defaultMode: 420
          secretName: alertmanager-main
      - emptyDir: {}
        name: alertmanager-main-db
  updateStrategy:
    type: RollingUpdate
status:
  collisionCount: 0
  currentReplicas: 2
  currentRevision: alertmanager-main-59d7ccf598
  observedGeneration: 4
  readyReplicas: 2
  replicas: 2
  updateRevision: alertmanager-main-59d7ccf598
  updatedReplicas: 2
kuberneteskubectlkubernetes-statefulset
2
livinston

Vous n'avez pas fourni de scénario complet. Cela peut dépendre de Readiness Probe ou Update Strategy.

StatefulSet redémarrer les pods à partir de l'index 0 to n-1. Les détails peuvent être trouvés ici .

Raison 1 *

Statefulset ont 4 stratégies de mise à jour .

  • Lors de la suppression
  • Mises à jour continues
  • Cloisons
  • Restauration forcée

Dans Partition update, vous pouvez trouver des informations qui:

Si une partition est spécifiée, tous les pods dont l'ordinal est supérieur ou égal à la partition seront mis à jour lorsque le .spec.template Est mis à jour. Tous les pods dont l'ordinal est inférieur à la partition ne seront pas mis à jour et, même s'ils sont supprimés, ils seront recréés dans la version précédente. Si un StatefulSet .spec.updateStrategy.rollingUpdate.partition est supérieur à son .spec.replicas, mises à jour de son .spec.template ne sera pas propagé à ses pods. Dans la plupart des cas, vous n'aurez pas besoin d'utiliser une partition, mais ils sont utiles si vous souhaitez organiser une mise à jour, déployer un canari ou effectuer un déploiement progressif.

Donc, si quelque part dans StatefulSet vous avez défini updateStrategy.rollingUpdate.partition: 1 il redémarrera tous les pods avec l'index 1 ou supérieur.

Exemple de partition: 3

NAME    READY   STATUS    RESTARTS   AGE
web-0   1/1     Running   0          30m
web-1   1/1     Running   0          30m
web-2   1/1     Running   0          31m
web-3   1/1     Running   0          2m45s
web-4   1/1     Running   0          3m
web-5   1/1     Running   0          3m13s

Raison 2

Configuration de Readiness probe.

Si vos valeurs de initialDelaySeconds et periodSeconds sont élevées, cela peut prendre un certain temps avant qu'un autre ne soit redémarré. Les détails sur ces paramètres peuvent être trouvés ici .

Dans l'exemple ci-dessous, le pod attendra 10 secondes qu'il s'exécutera et readiness probe vérifie ceci toutes les 2 secondes. Dépend des valeurs qu'il peut être à l'origine de ce comportement.

    readinessProbe:
      failureThreshold: 3
      httpGet:
        path: /
        port: 80
        scheme: HTTP
      initialDelaySeconds: 10
      periodSeconds: 2
      successThreshold: 1
      timeoutSeconds: 1

Raison 3

J'ai vu que vous avez 2 conteneurs dans chaque pod.

NAME                  READY   STATUS    RESTARTS   AGE
alertmanager-main-0   2/2     Running   0          21h
alertmanager-main-1   2/2     Running   0          20s

Comme décrit dans docs :

Running - Le pod a été lié à un noeud et tous les conteneurs ont été créés. À au moins un conteneur est toujours en cours d'exécution , ou est en train de démarrer ou de redémarrer .

Il serait bon de vérifier si tout va bien avec les deux containers (readinessProbe/livenessProbe, redémarre, etc.)

2
PjoterS

Vous devez le supprimer. Les ensembles avec état sont supprimés en suivant leur index ordinal avec l'index ordinal le plus élevé en premier.

De plus, vous n'avez pas besoin de redémarrer le pod pour relire la carte de configuration mise à jour. Cela se produit automatiquement (après un certain temps).

1
fg78nc