Я настроил модуль весенней загрузки и настроил датчики liveness и readiness. Когда я запускаю модуль, команда describe показывает вывод ниже.

Events:
  Type     Reason     Age                From               Message
  ----     ------     ----               ----               -------
  Normal   Scheduled  92s                default-scheduler  Successfully assigned pradeep-ns/order-microservice-rs-8tqrv to pool-h4jq5h014-ukl3l
  Normal   Pulled     43s (x2 over 91s)  kubelet            Container image "classpathio/order-microservice:latest" already present on machine
  Normal   Created    43s (x2 over 91s)  kubelet            Created container order-microservice
  Normal   Started    43s (x2 over 91s)  kubelet            Started container order-microservice
  Warning  Unhealthy  12s (x6 over 72s)  kubelet            Liveness probe failed: Get "http://10.244.0.206:8222/actuator/health/liveness": dial tcp 10.244.0.206:8222: connect: connection refused
  Normal   Killing    12s (x2 over 52s)  kubelet            Container order-microservice failed liveness probe, will be restarted
  Warning  Unhealthy  2s (x8 over 72s)   kubelet            Readiness probe failed: Get "http://10.244.0.206:8222/actuator/health/readiness": dial tcp 10.244.0.206:8222: connect: connection refused

Определение стручка, как показано ниже

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: order-microservice-rs
  labels:
    app: order-microservice
spec:
  replicas: 1
  selector:
    matchLabels:
      app: order-microservice
  template:
    metadata:
      name: order-microservice
      labels:
        app: order-microservice
    spec:
      containers:
        - name: order-microservice
          image: classpathio/order-microservice:latest
          imagePullPolicy: IfNotPresent
          env:
            - name: SPRING_PROFILES_ACTIVE
              value: dev
            - name: SPRING_DATASOURCE_USERNAME
              valueFrom:
                secretKeyRef:
                  key: username
                  name: db-credentials
            - name: SPRING_DATASOURCE_PASSWORD
              valueFrom:
                secretKeyRef:
                  key: password
                  name: db-credentials
          volumeMounts:
            - name: app-config
              mountPath: /app/config
            - name: app-logs
              mountPath: /var/log
          livenessProbe:
            httpGet:
              port: 8222
              path: /actuator/health/liveness
            initialDelaySeconds: 10
            periodSeconds: 10
          readinessProbe:
            httpGet:
              port: 8222
              path: /actuator/health/readiness
            initialDelaySeconds: 10
            periodSeconds: 10
          resources:
            requests:
              memory: "550Mi"
              cpu: "500m"
            limits:
              memory: "550Mi"
              cpu: "750m"
      volumes:
        - name: app-config
          configMap:
            name: order-microservice-config
        - name: app-logs
          emptyDir: {}
      restartPolicy: Always

Если я отключу зонд liveness и readiness в манифесте replica-set и exec в поде, я получу правильный ответ при вызове http://localhost:8222/actuator/health/liveness и http://localhost:8222/actuator/health/readiness конечная точка. Почему мой модуль перезапускается и не работает при вызове конечных точек readiness и liveness с Kubernetes. Где я ошибаюсь?

Обновить Если я удалю раздел resource, модули будут работать, но при добавлении параметров resource произойдет сбой probes.

0
zilcuanu 2 Фев 2022 в 15:58
Когда модуль перезапустился, запустилось ли приложение весенней загрузки? @zilcuanu
 – 
Dolphin
2 Фев 2022 в 18:55

3 ответа

Когда вы ограничиваете приложение контейнера/пружины до 0,5 ядра (500 миллиядер), запуск, вероятно, занимает больше времени, чем заданные пороговые значения проверки живучести.

Вы можете либо увеличить их, либо использовать startupProbe с более мягкими настройками (например, failureThreshold 10). В этом случае вы можете сократить период проверки работоспособности и получить более быструю обратную связь после обнаружения успешного запуска контейнера.

1
Thomas 2 Фев 2022 в 18:41
Как узнать настройки ядер и памяти для приложений с весенней загрузкой? Каковы ориентиры для получения числа
 – 
zilcuanu
2 Фев 2022 в 18:47

Ваша конфигурация модуля дает только 0,5 ядра процессора, и время проверки было слишком коротким. Запуск весенней загрузки может занять более 10 секунд в зависимости от производительности ЦП вашего сервера. Это моя конфигурация весеннего загрузочного модуля, которая может дать вам представление.

"livenessProbe": {
              "httpGet": {
                "path": "/actuator/liveness",
                "port": 11032,
                "scheme": "HTTP"
              },
              "initialDelaySeconds": 90,
              "timeoutSeconds": 30,
              "periodSeconds": 30,
              "successThreshold": 1,
              "failureThreshold": 3
            },
            "readinessProbe": {
              "httpGet": {
                "path": "/actuator/health",
                "port": 11032,
                "scheme": "HTTP"
              },
              "initialDelaySeconds": 60,
              "timeoutSeconds": 30,
              "periodSeconds": 30,
              "successThreshold": 1,
              "failureThreshold": 3
            },

И я не ограничивал ЦП и ресурс памяти, если ограничить ЦП, то это займет больше времени. Хоп, это может тебе помочь.

1
Dolphin 2 Фев 2022 в 19:05

Когда вы пытаетесь выполнить запрос к своему localhost, и он работает, это не гарантирует, что он будет работать на других сетевых интерфейсах. Kubelet — это агент узла, поэтому запрос отправляется вашему eth0 или его эквиваленту, а не вашему localhost.

Вы можете проверить это, отправив запрос из другого модуля на IP-адрес вашего модуля или сервис, поддерживающий его.

Вероятно, вы делаете свое приложение для обслуживания на localhost, в то время как вам нужно настроить его на 0.0.0.0 или eth0.

0
suren 2 Фев 2022 в 19:27