Configurar el almacenamiento de mensajes con Milvus Operator

En Milvus 3.x, Woodpecker es la cola de mensajes predeterminada (véase Woodpecker). Con Milvus Operator, también puedes configurar RocksMQ, Pulsar o Kafka para gestionar los registros de cambios recientes, generar registros de flujo y ofrecer suscripciones a registros. En este tema se explica cómo configurar las dependencias de almacenamiento de mensajes al instalar Milvus con Milvus Operator. Para obtener más detalles, consulta «Configurar el almacenamiento de mensajes con Milvus Operator » en el repositorio de Milvus Operator.

Este tema da por hecho que ya ha implementado Milvus Operator.

Es necesario especificar un archivo de configuración para utilizar Milvus Operator e iniciar un clúster de Milvus.

kubectl apply -f https://raw.githubusercontent.com/zilliztech/milvus-operator/main/config/samples/milvus_cluster_default.yaml

Solo tiene que editar la plantilla de código en milvus_cluster_default.yaml para configurar las dependencias de terceros. En las secciones siguientes se explica cómo configurar el almacenamiento de objetos, etcd y Pulsar, respectivamente.

Antes de empezar

La tabla siguiente muestra si RocksMQ, Pulsar, Kafka y Woodpecker son compatibles con Milvus en modo autónomo y en modo clúster.

También existen otras limitaciones a la hora de especificar el almacenamiento de mensajes:

• Solo se admite un almacenamiento de mensajes por instancia de Milvus. No obstante, seguimos manteniendo la compatibilidad con versiones anteriores en las que se configuraban varios almacenes de mensajes para una misma instancia. La prioridad es la siguiente:
  • modo autónomo: Woodpecker (predeterminado) > RocksMQ > Pulsar > Kafka
  • modo clúster: Woodpecker (predeterminado) > Pulsar > Kafka
• El almacenamiento de mensajes no se puede cambiar mientras el sistema Milvus está en funcionamiento.
• Solo se admiten las versiones 2.x o 3.x de Kafka.
• Limitaciones de la actualización: Limitaciones de la cola de mensajes: al actualizar a Milvus v3.0.1, debes mantener tu elección actual de cola de mensajes. No se admite el cambio entre diferentes sistemas de colas de mensajes durante la actualización. La posibilidad de cambiar de sistema de colas de mensajes estará disponible en futuras versiones.

Configurar RocksMQ

RocksMQ era el almacenamiento de mensajes predeterminado en Milvus independiente hasta la versión 2.5.x (sustituido por Woodpecker a partir de la 2.6.x).

Ejemplo

En el siguiente ejemplo se configura un servicio RocksMQ.

apiVersion: milvus.io/v1beta1
kind: Milvus
metadata:
  name: milvus
spec:
  mode: standalone
  dependencies:
    msgStreamType: rocksmq
    rocksmq:
      persistence:
        enabled: true
        pvcDeletion: true
        persistentVolumeClaim:
          spec:
            accessModes: ["ReadWriteOnce"]
            storageClassName: "local-path"  # Specify your storage class
            resources:
              requests:
                storage: 10Gi  # Specify your desired storage size
  components: {}
  config: {}

Opciones clave de configuración:

• msgStreamType: rocksmq: Establece explícitamente RocksMQ como cola de mensajes
• persistence.enabled: Habilita el almacenamiento persistente para los datos de RocksMQ
• persistence.pvcDeletion: Si se establece en «true», el PVC se eliminará cuando se elimine la instancia de Milvus
• persistentVolumeClaim.spec: Especificación estándar de PVC de Kubernetes
• accessModes: Normalmente « ReadWriteOnce » para almacenamiento en bloques
• storageClassName: La clase de almacenamiento de tu clúster
• storage: Tamaño del volumen persistente

Configurar Woodpecker

Woodpecker es un registro de escritura anticipada (WAL) nativo de la nube diseñado para el almacenamiento de objetos. Ofrece un alto rendimiento, una baja sobrecarga operativa y una escalabilidad fluida. Para obtener más detalles, consulta Woodpecker.

Configurar Pulsar

Pulsar gestiona los registros de cambios recientes, genera registros de flujo y ofrece suscripciones a registros. La configuración de Pulsar para el almacenamiento de mensajes es compatible tanto con Milvus independiente como con el clúster de Milvus. Sin embargo, con Milvus Operator, solo se puede configurar Pulsar como almacenamiento de mensajes para el clúster de Milvus. Añade los campos obligatorios en « spec.dependencies.pulsar » para configurar Pulsar.

pulsar Admite external y inCluster.

Pulsar externo

external indica que se utiliza un servicio Pulsar externo. Los campos utilizados para configurar un servicio Pulsar externo incluyen:

• external: Un valor de true indica que Milvus utiliza un servicio Pulsar externo.
• endpoints: Los puntos de conexión de Pulsar.

Ejemplo

El siguiente ejemplo configura un servicio Pulsar externo.

apiVersion: milvus.io/v1alpha1
kind: Milvus
metadata:
  name: my-release
  labels:
    app: milvus
spec:
  dependencies: # Optional
    pulsar: # Optional
      # Whether (=true) to use an existed external pulsar as specified in the field endpoints or 
      # (=false) create a new pulsar inside the same kubernetes cluster for milvus.
      external: true # Optional default=false
      # The external pulsar endpoints if external=true
      endpoints:
      - 192.168.1.1:6650
  components: {}
  config: {}           

Pulsar interno

inCluster indica que, al iniciarse un clúster de Milvus, se inicia automáticamente un servicio de Pulsar en el clúster.

Ejemplo

El siguiente ejemplo configura un servicio Pulsar interno.

apiVersion: milvus.io/v1alpha1
kind: Milvus
metadata:
  name: my-release
  labels:
    app: milvus
spec:
  dependencies:
    pulsar:
      inCluster:
        values:
          components:
            autorecovery: false
          zookeeper:
            replicaCount: 1
          bookkeeper:
            replicaCount: 1
            resoureces:
              limit:
                cpu: '4'
              memory: 8Gi
            requests:
              cpu: 200m
              memory: 512Mi
          broker:
            replicaCount: 1
            configData:
              ## Enable `autoSkipNonRecoverableData` since bookkeeper is running
              ## without persistence
              autoSkipNonRecoverableData: "true"
              managedLedgerDefaultEnsembleSize: "1"
              managedLedgerDefaultWriteQuorum: "1"
              managedLedgerDefaultAckQuorum: "1"
          proxy:
            replicaCount: 1
  components: {}
  config: {}            

Suponiendo que el archivo de configuración se llama « milvuscluster.yaml », ejecute el siguiente comando para aplicar la configuración.

kubectl apply -f milvuscluster.yaml

Configurar Kafka

Pulsar era el almacenamiento de mensajes predeterminado en un clúster de Milvus hasta la versión 2.5.x (sustituido por Woodpecker a partir de la versión 2.6.x). Si desea utilizar Kafka, añada el campo opcional « msgStreamType » para configurar Kafka.

kafka Admite external y inCluster.

Kafka externo

external indica que se utiliza un servicio externo de Kafka.

Los campos utilizados para configurar un servicio de Kafka externo incluyen:

• external: Un valor « true » indica que Milvus utiliza un servicio de Kafka externo.
• brokerList: La lista de brokers a los que enviar los mensajes.

Ejemplo

El siguiente ejemplo configura un servicio Kafka externo.

apiVersion: milvus.io/v1alpha1
kind: Milvus
metadata:
  name: my-release
  labels:
    app: milvus
spec:
  config:
    kafka:
      # securityProtocol supports: PLAINTEXT, SSL, SASL_PLAINTEXT, SASL_SSL 
      securityProtocol: PLAINTEXT
      # saslMechanisms supports: PLAIN, SCRAM-SHA-256, SCRAM-SHA-512
      saslMechanisms: PLAIN
      saslUsername: ""
      saslPassword: ""
  # Omit other fields ...
  dependencies:
    # Omit other fields ...
    msgStreamType: "kafka"
    kafka:
      external: true
      brokerList: 
        - "kafkaBrokerAddr1:9092"
        - "kafkaBrokerAddr2:9092"
        # ...

Las configuraciones SASL son compatibles con la versión v0.8.5 o superior del operador.

Kafka interno

inCluster indica que, al iniciarse un clúster de Milvus, se inicia automáticamente un servicio de Kafka en dicho clúster.

Ejemplo

El siguiente ejemplo muestra cómo configurar un servicio interno de Kafka.

apiVersion: milvus.io/v1alpha1
kind: Milvus
metadata:
  name: my-release
  labels:
    app: milvus
spec: 
  dependencies:
    msgStreamType: "kafka"
    kafka:
      inCluster: 
        values: {} # values can be found in https://artifacthub.io/packages/helm/bitnami/kafka
  components: {}
  config: {}

Consulta aquí los elementos de configuración completos para configurar un servicio interno de Kafka. Añade los elementos de configuración que necesites en « kafka.inCluster.values ».

Suponiendo que el archivo de configuración se llama « milvuscluster.yaml », ejecute el siguiente comando para aplicar la configuración.

kubectl apply -f milvuscluster.yaml

Próximos pasos

Descubre cómo configurar otras dependencias de Milvus con Milvus Operator:

• Configurar el almacenamiento de objetos con Milvus Operator
• Configurar el almacenamiento de metadatos con Milvus Operator