Cómo ejecutar SeatUnnel en modo de clúster separado en K8S

Apache SeatUnnel es una nueva generación de herramienta de integración de datos y sincronización de datos distribuidos de alto rendimiento que ha sido ampliamente reconocida y aplicada en la industria. SeatUnnel admite tres modos de implementación: modo native, modo de clúster híbrido y modo de clúster separado.

Este artículo tiene como objetivo introducir la implementación de SeatUnnel en el modo de clúster separado en Kubernetes, proporcionando un proceso integral de implementación y ejemplos de configuración para aquellos con necesidades relevantes.

1. Preparación

Antes de comenzar la implementación, los siguientes entornos y componentes deben estar listos:

• Entorno de clúster de Kubernetes
• herramienta de línea de comandos kubectl
• estibador
• Helm (opcional)

Para aquellos familiarizados con Helm, puede consultar directamente el tutorial oficial de implementación del timón:

Este artículo presenta principalmente la implementación basada en Kubernetes y herramientas Kubectl.

2. Construct Seatunnel Docker Imagen

Las imágenes oficiales de varias versiones ya se proporcionan y se pueden extraer directamente. Para más detalles, consulte la documentación oficial: Configurar con Docker.

docker pull apache/seatunnel:

Como necesitamos implementar el modo de clúster, el siguiente paso es configurar la comunicación de pink de clúster. El servicio de pink del clúster SeatUnnel se implementa a través de Hazelcast, por lo que configuraremos esta parte a continuación.

Configuración de servicio sin cabeza

El clúster Hazelcast es una pink formada por miembros del clúster que ejecutan Hazelcast, que automáticamente se une para formar un clúster. Esta unión automática se logra a través de varios mecanismos de descubrimiento utilizados por los miembros del clúster para encontrarse.

Hazelcast admite los siguientes mecanismos de descubrimiento:

• Descubrimiento automático, entornos de apoyo como:
• AWS
• Azur
• GCP
• Kubernetes
• TCP
• Multicast
• Eureka
• Choque

En la implementación de clúster de este artículo, configuramos Hazelcast utilizando el mecanismo de descubrimiento automático de Kubernetes. Los principios detallados se pueden encontrar en el documento oficial: Kubernetes Auto Discovery.

El mecanismo de descubrimiento automático de Kubernetes de Hazelcast (modo de búsqueda DNS) requiere un servicio sin cabeza de Kubernetes para que funcione. El servicio sin cabeza resuelve el nombre de dominio del servicio en una lista de direcciones IP de todas las cápsulas coincidentes, lo que permite a los miembros del clúster Hazelcast que se descubran entre sí.

Primero, creamos un servicio sin cabeza de Kubernetes:

# use for hazelcast cluster be part of
apiVersion: v1
variety: Service
metadata:
  identify: seatunnel-cluster
spec:
  kind: ClusterIP
  clusterIP: None
  selector:
    app.kubernetes.io/occasion: seatunnel-cluster-app
    app.kubernetes.io/model: 2.3.10
  ports:
  - port: 5801
    identify: hazelcast

Partes clave de la configuración anterior:

• metadata.identify: seatunnel-cluster: Nombre del servicio, clientes/nodos de Hazelcast descubren miembros del clúster a través de este nombre
• spec.clusterIP: None: Configuración crítica que declara esto como un servicio sin cabeza sin IP digital
• spec.selector: Etiquetas de cápsod de juego selectores que serán seleccionados por este servicio
• spec.port: Puerto expuesto para Hazelcast

Mientras tanto, para acceder al clúster externamente a través de REST API, definimos otro servicio para el nodo maestro POD:

# use for entry seatunnel from outdoors system by way of relaxation api
apiVersion: v1
variety: Service
metadata:
  identify: seatunnel-cluster-master
spec:
  kind: ClusterIP
  clusterIP: None
  selector:
    app.kubernetes.io/occasion: seatunnel-cluster-app
    app.kubernetes.io/model: 2.3.10
    app.kubernetes.io/identify: seatunnel-cluster-master
    app.kubernetes.io/element: grasp
  ports:
  - port: 8080
    identify: "master-port"
    targetPort: 8080
    protocol: TCP

Después de definir los servicios de Kubernetes anteriores, la próxima configuración hazelcast-master.yaml y hazelcast-worker.yaml Archivos según el mecanismo de descubrimiento de Kubernetes de Hazelcast.

Configuraciones de Yaml de Hazelcast Grasp y Employee Yaml

En el modo de clúster separado de Seatunnel, toda la configuración relacionada con la pink está contenida en hazelcast-master.yaml y hazelcast-worker.yaml.

hazelcast-master.yaml ejemplo:

hazelcast:
  cluster-name: seatunnel-cluster
  community:
    rest-api:
      enabled: true
      endpoint-groups:
        CLUSTER_WRITE:
          enabled: true
        DATA:
          enabled: true
    be part of:
      kubernetes:
        enabled: true
        service-dns: seatunnel-cluster.bigdata.svc.cluster.native
        service-port: 5801
    port:
      auto-increment: false
      port: 5801
  properties:
    hazelcast.invocation.max.retry.rely: 20
    hazelcast.tcp.be part of.port.strive.rely: 30
    hazelcast.logging.kind: log4j2
    hazelcast.operation.generic.thread.rely: 50
    hazelcast.heartbeat.failuredetector.kind: phi-accrual
    hazelcast.heartbeat.interval.seconds: 30
    hazelcast.max.no.heartbeat.seconds: 300
    hazelcast.heartbeat.phiaccrual.failuredetector.threshold: 15
    hazelcast.heartbeat.phiaccrual.failuredetector.pattern.dimension: 200
    hazelcast.heartbeat.phiaccrual.failuredetector.min.std.dev.millis: 200

Elementos de configuración clave:

1. nombre de clúster
2. Esta configuración identifica si varios nodos pertenecen al mismo clúster; Solo los nodos con el mismo nombre de clúster se unirán al mismo clúster de Hazelcast. Diferentes nodos de nombre de clúster rechazan las solicitudes entre sí.
3. Configuración de pink

• REST-API. Debe estar habilitado explícitamente aquí.
• Service-DNS (requerido): nombre de dominio completo del servicio sin cabeza, generalmente ${SERVICE-NAME}.${NAMESPACE}.svc.cluster.native.
• Service-Port (opcional): puerto Hazelcast; Si se especifica y> 0, anula el puerto predeterminado (5701).

Utilizando este mecanismo de unión de Kubernetes, cuando se inicia Hazelcast Pod, resuelve los DNS de servicio para obtener la lista de IP de todas las cápsulas de miembros (a través del servicio sin cabeza), y luego los miembros intentan las conexiones TCP sobre el puerto 5801.

Del mismo modo, el hazelcast-worker.yaml La configuración es:

hazelcast:
  cluster-name: seatunnel-cluster
  community:
    rest-api:
      enabled: true
      endpoint-groups:
        CLUSTER_WRITE:
          enabled: true
        DATA:
          enabled: true
    be part of:
      kubernetes:
        enabled: true
        service-dns: seatunnel-cluster.bigdata.svc.cluster.native
        service-port: 5801
    port:
      auto-increment: false
      port: 5801
  properties:
    hazelcast.invocation.max.retry.rely: 20
    hazelcast.tcp.be part of.port.strive.rely: 30
    hazelcast.logging.kind: log4j2
    hazelcast.operation.generic.thread.rely: 50
    hazelcast.heartbeat.failuredetector.kind: phi-accrual
    hazelcast.heartbeat.interval.seconds: 30
    hazelcast.max.no.heartbeat.seconds: 300
    hazelcast.heartbeat.phiaccrual.failuredetector.threshold: 15
    hazelcast.heartbeat.phiaccrual.failuredetector.pattern.dimension: 200
    hazelcast.heartbeat.phiaccrual.failuredetector.min.std.dev.millis: 200
  member-attributes:
    rule:
      kind: string
      worth: employee

A través de lo anterior, completamos la configuración de descubrimiento de miembros del clúster Hazelcast basada en Kubernetes. A continuación, continúe con el motor Seatunnel.

4. Configure el motor Seatunnel

La configuración relacionada con el motor SeatUnnel está todo en el seatunnel.yaml archivo. A continuación se muestra una muestra seatunnel.yaml Configuración para referencia:

seatunnel:
  engine:
    history-job-expire-minutes: 1440
    backup-count: 1
    queue-type: blockingqueue
    print-execution-info-interval: 60
    print-job-metrics-info-interval: 60
    classloader-cache-mode: true
    http:
      enable-http: true
      port: 8080
      enable-dynamic-port: false
      port-range: 100
    slot-service:
      dynamic-slot: true
    checkpoint:
      interval: 300000
      timeout: 60000
      storage:
        kind: hdfs
        max-retained: 3
        plugin-config:
          namespace: /tmp/seatunnel/checkpoint_snapshot
          storage.kind: hdfs
          fs.defaultFS: hdfs://xxx:8020 # Guarantee listing has write permission
    telemetry:
      metric:
        enabled: true

Esto incluye la siguiente información de configuración:

• history-job-expire-minutes: El período de retención de los registros del historial de tareas es de 24 horas (1440 minutos), después de lo cual se limpiarán automáticamente.
• backup-count: 1: El número de réplicas de respaldo para el estado de la tarea es 1.
• queue-type: blockingqueue: Use una cola de bloqueo para administrar tareas para evitar el agotamiento de los recursos.
• print-execution-info-interval: 60: Imprimir el estado de ejecución de la tarea cada 60 segundos.
• print-job-metrics-info-interval: 60: Métricas de tareas de salida (como rendimiento, latencia) cada 60 segundos.
• classloader-cache-mode: true: Habilite el almacenamiento en caché del cargador de clase para reducir la sobrecarga de carga repetida y mejorar el rendimiento.
• dynamic-slot: true: Permitir un ajuste dinámico de la cantidad de ranura de tareas basada en la carga para optimizar la utilización de recursos.
• checkpoint.interval: 300000: El punto de management de activación cada 5 minutos.
• checkpoint.timeout: 60000: Tiempo de espera del punto de management establecido en 1 minuto.
• telemetry.metric.enabled: true: Habilitar la recopilación de métricas de tareas de tiempo de ejecución (por ejemplo, latencia, rendimiento) para el monitoreo.

5. Cree archivos Kubernetes Yaml para implementar la aplicación

Después de completar el flujo de trabajo anterior, el paso last es crear archivos YAML Kubernetes para nodos maestros y trabajadores, definiendo configuraciones relacionadas con la implementación.

Para desacoplar los archivos de configuración de la aplicación, los archivos de configuración mencionados anteriormente se fusionan en un mapmap, montados en la ruta de configuración del contenedor para administración unificada y actualizaciones más fáciles.

A continuación se muestran configuraciones de muestra para seatunnel-cluster-master.yaml y seatunnel-cluster-worker.yamlcubriendo el montaje de configuración, los comandos de inicio del contenedor y las definiciones de recursos de implementación.

seatunnel-cluster-master.yaml:

apiVersion: apps/v1
variety: Deployment
metadata:
  identify: seatunnel-cluster-master
spec:
  replicas: 2  # modify replicas based on your state of affairs
  technique:
    kind: RollingUpdate
    rollingUpdate:
      maxUnavailable: 25%
      maxSurge: 50%
  selector:
    matchLabels:
      app.kubernetes.io/occasion: seatunnel-cluster-app
      app.kubernetes.io/model: 2.3.10
      app.kubernetes.io/identify: seatunnel-cluster-master
      app.kubernetes.io/element: grasp
  template:
    metadata:
      annotations:
        prometheus.io/path: /hazelcast/relaxation/occasion/metrics
        prometheus.io/port: "5801"
        prometheus.io/scrape: "true"
        prometheus.io/position: "seatunnel-master"
      labels:
        app.kubernetes.io/occasion: seatunnel-cluster-app
        app.kubernetes.io/model: 2.3.10
        app.kubernetes.io/identify: seatunnel-cluster-master
        app.kubernetes.io/element: grasp
    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: nodeAffinity-key
                operator: Exists
      containers:
        - identify: seatunnel-master
          picture: seatunnel:2.3.10
          imagePullPolicy: IfNotPresent
          ports:
            - containerPort: 5801
              identify: hazelcast
            - containerPort: 8080
              identify: "master-port"
          command:
            - /choose/seatunnel/bin/seatunnel-cluster.sh
            - -r
            - grasp
          sources:
            requests:
              cpu: "1"
              reminiscence: 4G
          volumeMounts:
            - mountPath: "/choose/seatunnel/config/hazelcast-master.yaml"
              identify: seatunnel-configs
              subPath: hazelcast-master.yaml
            - mountPath: "/choose/seatunnel/config/hazelcast-worker.yaml"
              identify: seatunnel-configs
              subPath: hazelcast-worker.yaml
            - mountPath: "/choose/seatunnel/config/seatunnel.yaml"
              identify: seatunnel-configs
              subPath: seatunnel.yaml
            - mountPath: "/choose/seatunnel/config/hazelcast-client.yaml"
              identify: seatunnel-configs
              subPath: hazelcast-client.yaml
            - mountPath: "/choose/seatunnel/config/log4j2_client.properties"
              identify: seatunnel-configs
              subPath: log4j2_client.properties
            - mountPath: "/choose/seatunnel/config/log4j2.properties"
              identify: seatunnel-configs
              subPath: log4j2.properties

      volumes:
        - identify: seatunnel-configs
          configMap:
            identify: seatunnel-cluster-configs

Estrategia de implementación

• Use múltiples réplicas (replicas=2) para garantizar la alta disponibilidad del servicio.
• Utilice la estrategia de actualización continua para la implementación de tiempo de inactividad cero:
• maxUnavailable: 25%: Asegúrese de que al menos el 75% de los POD se funcionen durante las actualizaciones.
• maxSurge: 50%: Permitir temporalmente un 50% más de vainas durante la transición para una actualización suave.

Selectores de etiquetas

• Utilice el sistema de etiquetas estándar recomendado de Kubernetes
• spec.selector.matchLabels: Outline el alcance de las cápsulas administradas por la implementación basada en etiquetas
• spec.template.labels: Etiquetas asignadas a nuevos vainas para identificar sus metadatos

Afinidad del nodo

• Configurar affinity Para especificar en qué nodos se debe programar el POD
• Reemplazar nodeAffinity-key con etiquetas que coinciden con sus nodos de entorno Kubernetes

Montaje del archivo de configuración

• Centralice los archivos de configuración del núcleo en un CONFIGMAP para decepcionar la administración desde las aplicaciones
• Usar subPath Para montar archivos individuales desde configMap

El seatunnel-cluster-worker.yaml La configuración es:

apiVersion: apps/v1
variety: Deployment
metadata:
  identify: seatunnel-cluster-worker
spec:
  replicas: 3  # modify replicas based on your state of affairs
  technique:
    kind: RollingUpdate
    rollingUpdate:
      maxUnavailable: 25%
      maxSurge: 50%
  selector:
    matchLabels:
      app.kubernetes.io/occasion: seatunnel-cluster-app
      app.kubernetes.io/model: 2.3.10
      app.kubernetes.io/identify: seatunnel-cluster-worker
      app.kubernetes.io/element: employee
  template:
    metadata:
      annotations:
        prometheus.io/path: /hazelcast/relaxation/occasion/metrics
        prometheus.io/port: "5801"
        prometheus.io/scrape: "true"
        prometheus.io/position: "seatunnel-worker"
      labels:
        app.kubernetes.io/occasion: seatunnel-cluster-app
        app.kubernetes.io/model: 2.3.10
        app.kubernetes.io/identify: seatunnel-cluster-worker
        app.kubernetes.io/element: employee
    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: nodeAffinity-key
                operator: Exists
      containers:
        - identify: seatunnel-worker
          picture: seatunnel:2.3.10
          imagePullPolicy: IfNotPresent
          ports:
            - containerPort: 5801
              identify: hazelcast
          command:
            - /choose/seatunnel/bin/seatunnel-cluster.sh
            - -r
            - employee
          sources:
            requests:
              cpu: "1"
              reminiscence: 10G
          volumeMounts:
            - mountPath: "/choose/seatunnel/config/hazelcast-master.yaml"
              identify: seatunnel-configs
              subPath: hazelcast-master.yaml
            - mountPath: "/choose/seatunnel/config/hazelcast-worker.yaml"
              identify: seatunnel-configs
              subPath: hazelcast-worker.yaml
            - mountPath: "/choose/seatunnel/config/seatunnel.yaml"
              identify: seatunnel-configs
              subPath: seatunnel.yaml
            - mountPath: "/choose/seatunnel/config/hazelcast-client.yaml"
              identify: seatunnel-configs
              subPath: hazelcast-client.yaml
            - mountPath: "/choose/seatunnel/config/log4j2_client.properties"
              identify: seatunnel-configs
              subPath: log4j2_client.properties
            - mountPath: "/choose/seatunnel/config/log4j2.properties"
              identify: seatunnel-configs
              sub

              subPath: log4j2.properties

      volumes:
        - identify: seatunnel-configs
          configMap:
            identify: seatunnel-cluster-configs

Después de definir los archivos YAML de maestro y trabajador anteriores, puede implementarlos en el clúster Kubernetes ejecutando:

kubectl apply -f seatunnel-cluster-master.yaml
kubectl apply -f seatunnel-cluster-worker.yaml

En circunstancias normales, verá el clúster de SeatUnnel en ejecución con 2 nodos maestros y 3 nodos de trabajadores:

$ kubectl get pods | grep seatunnel-cluster

seatunnel-cluster-master-6989898f66-6fjz8                        1/1     Working                0          156m
seatunnel-cluster-master-6989898f66-hbtdn                        1/1     Working                0          155m
seatunnel-cluster-worker-87fb469f7-5c96x                         1/1     Working                0          156m
seatunnel-cluster-worker-87fb469f7-7kt2h                         1/1     Working                0          155m
seatunnel-cluster-worker-87fb469f7-drm9r                         1/1     Working                0          156m

En este punto, hemos implementado con éxito el clúster de SeatUnnel en Kubernetes utilizando el modo de clúster separado. Ahora que el clúster está listo, ¿cómo los clientes envían trabajos a él?

6. El cliente envía trabajos al clúster

Envíe trabajos utilizando la herramienta de línea de comandos

Todas las configuraciones de clientes para SeatUnnel se encuentran en el hazelcast-client.yaml archivo.

Primero, descargue el paquete de instalación binaria localmente en el cliente (que contiene el bin y configdirectorios), y asegúrese de que la ruta de instalación de SeatUnnel sea consistente con el servidor. Esto es a lo que la documentación oficial se refiere como: configurar el satunnel_home lo mismo que el servidor, de lo contrario, los errores como “no pueden encontrar la ruta del complemento del conector en el servidor” pueden ocurrir porque la ruta del complemento del lado del servidor difiere de la ruta del lado del cliente.

Ingrese el directorio de instalación y modifique el config/hazelcast-client.yaml Archivo para señalar la dirección de servicio sin cabeza creada anteriormente:

hazelcast-client:
      cluster-name: seatunnel-cluster
      properties:
        hazelcast.logging.kind: log4j2
      connection-strategy:
        connection-retry:
          cluster-connect-timeout-millis: 3000
      community:
        cluster-members:
          - seatunnel-cluster.bigdata.svc.cluster.native:5801

Una vez realizada la configuración del cliente, puede enviar trabajos al clúster. Hay dos formas principales de configurar las opciones de JVM para el envío del trabajo:

• Configure las opciones de JVM en el config/jvm_client_options archivo:
• Las opciones de JVM configuradas aquí se aplicarán a todos los trabajos enviados a través de seatunnel.shindependientemente de la ejecución en modo native o de clúster. Todos los trabajos enviados compartirán la misma configuración JVM.
• Especifique las opciones de JVM directamente en la línea de comandos al enviar trabajos:
• Al enviar trabajos a través de seatunnel.shpuede especificar parámetros JVM en la línea de comando, por ejemplo,
• sh bin/seatunnel.sh --config $SEATUNNEL_HOME/config/v2.batch.config.template -DJvmOption=-Xms2G -Xmx2G.
• Esto permite especificar opciones de JVM individualmente para cada envío de trabajo.

A continuación, aquí hay una configuración de trabajo de muestra para demostrar enviar un trabajo al clúster:

env {
  parallelism = 2
  job.mode = "STREAMING"
  checkpoint.interval = 2000
}

supply {
  FakeSource {
    parallelism = 2
    plugin_output = "faux"
    row.num = 16
    schema = {
      fields {
        identify = "string"
        age = "int"
      }
    }
  }
}

sink {
  Console {
  }
}

Use el siguiente comando en el cliente para enviar el trabajo:

sh bin/seatunnel.sh --config config/v2.streaming.instance.template -m cluster -n st.instance.template -DJvmOption="-Xms2G -Xmx2G"

En el nodo maestro, enumere los trabajos en ejecución con:

$ sh bin/seatunnel.sh -l

Job ID              Job Title             Job Standing  Submit Time              Completed Time            
------------------  -------------------  ----------  -----------------------  -----------------------  
964354250769432580  st.instance.template  RUNNING     2025-04-15 10:39:30.588  

Puedes ver el trabajo llamado st.instance.template Actualmente está en el estado en ejecución. En los registros de nodo de trabajadores, debe observar entradas de registro como:

2025-04-15 10:34:41,998 INFO  [.a.s.c.s.c.s.ConsoleSinkWriter] [st-multi-table-sink-writer-1] - subtaskIndex=0  rowIndex=1:  SeaTunnelRow#tableId=faux SeaTunnelRow#variety=INSERT : bdaUB, 110348049
2025-04-15 10:34:41,998 INFO  [.a.s.c.s.c.s.ConsoleSinkWriter] [st-multi-table-sink-writer-1] - subtaskIndex=1  rowIndex=1:  SeaTunnelRow#tableId=faux SeaTunnelRow#variety=INSERT : mOifY, 1974539087
2025-04-15 10:34:41,999 INFO  [.a.s.c.s.c.s.ConsoleSinkWriter] [st-multi-table-sink-writer-1] - subtaskIndex=0  rowIndex=2:  SeaTunnelRow#tableId=faux SeaTunnelRow#variety=INSERT : jKFrR, 1828047742
2025-04-15 10:34:41,999 INFO  [.a.s.c.s.c.s.ConsoleSinkWriter] [st-multi-table-sink-writer-1] - subtaskIndex=1  rowIndex=2:  SeaTunnelRow#tableId=faux SeaTunnelRow#variety=INSERT : gDiqR, 1177544796
2025-04-15 10:34:41,999 INFO  [.a.s.c.s.c.s.ConsoleSinkWriter] [st-multi-table-sink-writer-1] - subtaskIndex=0  rowIndex=3:  SeaTunnelRow#tableId=faux SeaTunnelRow#variety=INSERT : bCVxc, 909343602
...

Esto confirma que el trabajo se ha presentado con éxito al clúster de Seatunnel y se está ejecutando normalmente.

Envíe trabajos utilizando la API REST

SeatUnnel también proporciona una API REST para consultar el estado laboral, las estadísticas, el envío y la detención de trabajos. Configuramos un servicio sin cabeza para nodos maestros con el puerto 8080 expuesto. Esto permite enviar trabajos a través de REST API de los clientes.

Puede enviar un trabajo cargando el archivo de configuración a través de Curl:

curl ' --form 'config_file=@"/choose/seatunnel/config/v2.streaming.instance.template"' --form 'jobName=st.instance.template'

{"jobId":"964553575034257409","jobName":"st.instance.template"}

Si el envío tiene éxito, la API devuelve la identificación de trabajo y el nombre del trabajo como se indica anteriormente.

Para enumerar los trabajos de ejecución, consulta:

curl '

[{"jobId":"964553575034257409","jobName":"st.example.template","jobStatus":"RUNNING","envOptions":{"job.mode":"STREAMING","checkpoint.interval":"2000","parallelism":"2"}, ...}]

La respuesta muestra el estado del trabajo y los metadatos adicionales, confirmando que el método de envío de trabajo de la API REST funciona correctamente.

Se pueden encontrar más detalles sobre la API REST en la documentación oficial: RESTFUL API V2

7. Resumen

Este artículo se centró en cómo implementar SeatUnnel en Kubernetes utilizando el modo de clúster separado recomendado. Para resumir, los principales pasos de implementación incluyen:

1. Put together el entorno de Kubernetes: asegúrese de que se ejecute un clúster Kubernetes y las herramientas necesarias se instalen.
2. Construya imágenes de Docker de SeatUnnel: use la imagen oficial si no se necesita desarrollo personalizado; De lo contrario, construya localmente y cree su propia imagen.
3. Configurar el servicio sin cabeza y el clúster de Hazelcast: el modo de búsqueda DNS DNS de Kubernetes de Hazelcast requiere un servicio sin cabeza Kubernetes, así que cree un servicio sin cabeza y configure Hazelcast con el servicio DNS en consecuencia. El servicio sin cabeza se resuelve con los IP de todos los pods para habilitar el descubrimiento de miembros del clúster Hazelcast.
4. Configurar el motor Seatunnel: modificar seatunnel.yaml Para establecer los parámetros del motor.
5. Cree archivos YAML de implementación de Kubernetes: defina las implementaciones de maestría y trabajadores con selectores de nodos, comandos de inicio, recursos y montajes de volumen, luego implementen en Kubernetes.
6. Configurar el cliente de SeatUnnel: instale SEATUnnel en el cliente, asegúrese SEATUNNEL_HOME coincide con el servidor y configure hazelcast-client.yaml para conectarse al clúster.
7. Envíe y ejecute trabajos: envíe trabajos del cliente al clúster de SeatUnnel para su ejecución.

Las configuraciones y los casos presentados aquí sirven como referencias. Puede haber muchas otras opciones de configuración y detalles no cubiertos. Los comentarios y las discusiones son bienvenidos. ¡Espero que esto sea útil para todos!