Configurar el almacenamiento de mensajes con Milvus Operator

Milvus utiliza RocksMQ, Pulsar o Kafka para gestionar registros de cambios recientes, emitir registros de flujo y proporcionar suscripciones a registros. Este tema presenta cómo configurar las dependencias de almacenamiento de mensajes cuando instala Milvus con Milvus Operator. Para más detalles, consulte Configurar el almacenamiento de mensajes con Milvus Oper ator en el repositorio de Milvus Operator.

Este tema asume que usted ha desplegado Milvus Operator.

Consulte Despliegue de Milvus Operator para obtener más información.

Necesita especificar un archivo de configuración para utilizar Milvus Operator para iniciar un cluster Milvus.

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

Sólo necesita editar la plantilla de código en milvus_cluster_default.yaml para configurar las dependencias de terceros. Las siguientes secciones presentan cómo configurar el almacenamiento de objetos, etcd y Pulsar respectivamente.

Antes de empezar

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

RocksMQPulsarKafkaWoodpecker
Modo autónomo✔️✔️✔️✔️
Modo clúster✖️✔️✔️✔️

También hay otras limitaciones para especificar el almacenamiento de mensajes:

  • Sólo se admite un almacenamiento de mensajes para una instancia de Milvus. Sin embargo, todavía tenemos compatibilidad con múltiples almacenamientos de mensajes establecidos para una instancia. La prioridad es la siguiente
    • modo autónomo: RocksMQ (por defecto) > Pulsar > Kafka
    • modo clúster: Pulsar (por defecto) > Kafka
  • El almacenamiento de mensajes no puede cambiarse mientras el sistema Milvus está en funcionamiento.
  • Sólo se admite la versión 2.x o 3.x de Kafka.
  • Limitaciones de actualización: Limitaciones de la cola de mensajes: Al actualizar a Milvus v2.6.15, debe mantener su elección actual de cola de mensajes. No es posible cambiar entre diferentes sistemas de colas de mensajes durante la actualización. El soporte para el cambio de sistemas de colas de mensajes estará disponible en futuras versiones.

Configuración de RocksMQ

RocksMQ es el almacenamiento de mensajes por defecto en Milvus standalone.

Actualmente, sólo puede configurar RocksMQ como almacenamiento de mensajes para Milvus standalone con Milvus Operator.

Ejemplo

El siguiente ejemplo 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 la cola de mensajes.
  • persistence.enabled: Habilita el almacenamiento persistente para los datos de RocksMQ
  • persistence.pvcDeletion: Cuando es true, el PVC se borrará cuando se borre la instancia de Milvus
  • persistentVolumeClaim.spec: Especificación estándar de PVC de Kubernetes
  • accessModes: Típicamente ReadWriteOnce para almacenamiento en bloque
  • storageClassName: Clase de almacenamiento de su clúster
  • storage: Tamaño del volumen persistente

Configurar Woodpecker

Woodpecker es un registro de escritura en cabeza (WAL) nativo de la nube diseñado para el almacenamiento de objetos. Ofrece un alto rendimiento, baja sobrecarga operativa y escalabilidad sin fisuras. Para obtener más información, consulte Uso de Woodpecker.

Configurar Pulsar

Pulsar gestiona registros de cambios recientes, genera registros de flujo y proporciona suscripciones a registros. La configuración de Pulsar para el almacenamiento de mensajes está soportada tanto en Milvus independiente como en Milvus cluster. Sin embargo, con Milvus Operator, sólo puede configurar Pulsar como almacenamiento de mensajes para Milvus cluster. Añada los campos necesarios 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 true indica que Milvus utiliza un servicio Pulsar externo.
  • endpoints: Los puntos finales 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 cuando se inicia un clúster Milvus, se inicia automáticamente un servicio 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: {}            
Este ejemplo especifica el número de réplicas de cada componente de Pulsar, los recursos informáticos de Pulsar BookKeeper y otras configuraciones.
Encuentra los elementos de configuración completos para configurar un servicio Pulsar interno en values.yaml. Añade los elementos de configuración que necesites en pulsar.inCluster.values como se muestra en el ejemplo anterior.

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 es el almacenamiento de mensajes predeterminado en un clúster Milvus. 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 Kafka externo.

Los campos utilizados para configurar un servicio Kafka externo incluyen:

  • external: Un valor true indica que Milvus utiliza un servicio 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 el operador v0.8.5 o versiones superiores.

Kafka interno

inCluster indica que cuando se inicia un cluster Milvus, se inicia automáticamente un servicio Kafka en el cluster.

Ejemplo

El siguiente ejemplo configura un servicio Kafka interno.

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: {}

Encuentre los elementos de configuración completos para configurar un servicio Kafka interno aquí. Añada los elementos de configuración que necesite 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

Lo que sigue

Aprenda a configurar otras dependencias de Milvus con Milvus Operator: