Проверка готовности не разрешает доступ к внутренней службе kubernetes, пока модуль не готов

Question

Проверка готовности не разрешает доступ к внутренней службе kubernetes, пока модуль не готов

Датчик готовности держит приложение в неготовом состоянии. Находясь в этом состоянии, приложение не может подключиться ни к какому сервису kubernetes.

Я использую Ubuntu 18 как для мастера, так и для узлов в моем кластере kubernetes. (Проблема все еще возникала, когда я использовал только master в кластере, поэтому я не думаю, что это проблема типа master-узла).

Я настроил свой кластер kubernetes с приложением Spring, которое использует hazelcast для управления кэшем. Таким образом, при использовании проверки готовности приложение не может получить доступ к сервису kubernetes, который я создал для подключения приложений через hazelcast с помощью плагина hazelcast-kubernetes.

Когда я вынимаю проверку готовности, приложение как можно быстрее подключается к сервису, создавая кластеры Hazelcast, и все работает правильно.

Датчик готовности подключится к API отдыха, единственным ответом которого является код 200. Однако, пока приложение работает, в середине процесса он запустит кластер Hazelcast и, как таковой, попытается подключиться к службе Kazernetes Hazelcast, которая соединяет кэш приложения с другими модулями, в то время как тест готовности не очищен, и отсек находится в неготовном состоянии из-за зонда. Это когда приложение не сможет подключиться к сервису kubernetes, и оно либо выйдет из строя, либо застрянет в результате добавления конфигурации.

service.yaml:

apiVersion: v1
kind: Service
metadata:
  name: my-app-cluster-hazelcast
spec:
  selector:
    app: my-app
  ports:
  - name: hazelcast
    port: 5701

deployment.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app-deployment
  labels:
    app: my-app-deployment
spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 2
  replicas: 2
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      terminationGracePeriodSeconds: 180
      containers:
      - name: my-app
        image: my-repo:5000/my-app-container
        imagePullPolicy: Always
        ports:
        - containerPort: 5701
        - containerPort: 9080
        readinessProbe:
          httpGet:
            path: /app/api/excluded/sample
            port: 9080
          initialDelaySeconds: 120
          periodSeconds: 15
        securityContext:
          capabilities:
            add:
              - SYS_ADMIN
        env:
          - name: container
            value: docker

hazelcast.xml:

<?xml version="1.0" encoding="UTF-8"?>

<hazelcast
        xsi:schemaLocation="http://www.hazelcast.com/schema/config http://www.hazelcast.com/schema/config/hazelcast-config-3.11.xsd"
        xmlns="http://www.hazelcast.com/schema/config"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

    <properties>
        <property name="hazelcast.jmx">false</property>
        <property name="hazelcast.logging.type">slf4j</property>
    </properties>

    <network>
        <port auto-increment="false">5701</port>
            <outbound-ports>
                <ports>49000,49001,49002,49003</ports>
            </outbound-ports>
        <join>
            <multicast enabled="false"/>
            <kubernetes enabled="true">
                <namespace>default</namespace>
                <service-name>my-app-cluster-hazelcast</service-name>
            </kubernetes>
        </join>
    </network>
</hazelcast>

hazelcast-client.xml:

<?xml version="1.0" encoding="UTF-8"?>
<hazelcast-client
        xsi:schemaLocation="http://www.hazelcast.com/schema/client-config http://www.hazelcast.com/schema/client-config/hazelcast-client-config-3.11.xsd"
        xmlns="http://www.hazelcast.com/schema/client-config"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

    <properties>
        <property name="hazelcast.logging.type">slf4j</property>
    </properties>

    <connection-strategy async-start="false" reconnect-mode="ON">
        <connection-retry enabled="true">
            <initial-backoff-millis>1000</initial-backoff-millis>
            <max-backoff-millis>60000</max-backoff-millis>
        </connection-retry>
    </connection-strategy>

    <network>
        <kubernetes enabled="true">
            <namespace>default</namespace>
            <service-name>my-app-cluster-hazelcast</service-name>
        </kubernetes>
    </network>
</hazelcast-client>

Ожидаемый результат:

Сервис может подключаться к модулям, создавая конечные точки в своем описании.

$ kubectl описать сервис my-app-cluster-hazelcast

Name:              my-app-cluster-hazelcast
Namespace:         default
Labels:            <none>
Annotations:       kubectl.kubernetes.io/last-applied-configuration:
                     {"apiVersion":"v1","kind":"Service","metadata":{"annotations":{},"name":"my-app-cluster-hazelcast","namespace":"default"},"spec":{"ports...
Selector:          app=my-app
Type:              ClusterIP
IP:                10.244.28.132
Port:              hazelcast  5701/TCP
TargetPort:        5701/TCP
Endpoints:         10.244.4.10:5701,10.244.4.9:5701
Session Affinity:  None
Events:            <none>

Приложение работает правильно и показывает два члена в своем кластере Hazelcast, а развертывание показано как готовое, к приложению можно получить полный доступ:

журналы:

2019-08-26 23:07:36,614 TRACE [hz._hzInstance_1_dev.InvocationMonitorThread] (com.hazelcast.spi.impl.operationservice.impl.InvocationMonitor): [10.244.4.10]:5701 [dev] [3.11] Broadcasting operation control packets to: 2 members

$ kubectl получить развертывания

NAME                  READY   UP-TO-DATE   AVAILABLE   AGE
my-app-deployment   2/2     2            2           2m27s

Фактический результат:

Служба не получает конечной точки.

$ kubectl описать сервис my-app-cluster-hazelcast

Name:              my-app-cluster-hazelcast
Namespace:         default
Labels:            <none>
Annotations:       kubectl.kubernetes.io/last-applied-configuration:
                     {"apiVersion":"v1","kind":"Service","metadata":{"annotations":{},"name":"my-app-cluster-hazelcast","namespace":"default"},"spec":{"ports...
Selector:          app=my-app
Type:              ClusterIP
IP:                10.244.28.132
Port:              hazelcast  5701/TCP
TargetPort:        5701/TCP
Endpoints:
Session Affinity:  None
Events:            <none>

Приложение застревает с включенной стратегией соединения в hazelcast-client.xml со следующими журналами, сохраняя свой собственный кластер без связи и развертывание в неготовом состоянии навсегда:

журналы:

22:54:11.236 [hz.client_0.cluster-] WARN com.hazelcast.client.connection.ClientConnectionManager - hz.client_0 [dev] [3.11] Unable to get alive cluster connection, try in 57686 ms later, attempt 52 , cap retrytimeout millis 60000
22:55:02.036 [hz._hzInstance_1_dev.cached.thread-4] DEBUG com.hazelcast.internal.cluster.impl.MembershipManager - [10.244.4.8]:5701 [dev] [3.11] Sending member list to the non-master nodes:

Members {size:1, ver:1} [
        Member [10.244.4.8]:5701 - 6a4c7184-8003-4d24-8023-6087d68e9709 this
]

22:55:08.968 [hz.client_0.cluster-] WARN com.hazelcast.client.connection.ClientConnectionManager - hz.client_0 [dev] [3.11] Unable to get alive cluster connection, try in 51173 ms later, attempt 53 , cap retrytimeout millis 60000
22:56:00.184 [hz.client_0.cluster-] WARN com.hazelcast.client.connection.ClientConnectionManager - hz.client_0 [dev] [3.11] Unable to get alive cluster connection, try in 55583 ms later, attempt 54 , cap retrytimeout millis 60000

$ kubectl получить развертывания

NAME                  READY   UP-TO-DATE   AVAILABLE   AGE
my-app-deployment   0/2     2            0           45m

1

kubernetes hazelcast readinessprobe

Источник

user11019984 27 авг '19 в 02:11

2 ответа

Другие вопросы по тегам kubernetes hazelcast readinessprobe

user11207414 27 авг '19 в 18:10 2019-08-27 18:10 · Answer 1 · 2019-08-27 18:10

Просто для ясности:

Как описано в Cristian Cordova со ссылкой на проверку готовности:

Kubelet использует датчики готовности, чтобы знать, когда Контейнер готов начать принимать трафик. Стручок считается готовым, когда все его контейнеры готовы. Одним из применений этого сигнала является управление тем, какие Бобы используются в качестве бэкэндов для Сервисов. Когда модуль не готов, он удаляется из службы балансировки нагрузки

user1123894 27 авг '19 в 02:33 2019-08-27 02:33 · Answer 2 · 2019-08-27 02:33

К вашим услугам yaml у вас есть

spec:
  selector:
    app: my-app

но при развертывании yaml значение меток отличается

metadata:
  name: my-app-deployment
  labels:
    app: my-app-deployment

Есть ли причина для этого?

0

Источник

user1123894 27 авг '19 в 02:33