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.
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.
| RocksMQ | Pulsar | Kafka | Woodpecker | |
|---|---|---|---|---|
| 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 RocksMQpersistence.pvcDeletion: Cuando es true, el PVC se borrará cuando se borre la instancia de MilvuspersistentVolumeClaim.spec: Especificación estándar de PVC de KubernetesaccessModes: TípicamenteReadWriteOncepara almacenamiento en bloquestorageClassName: Clase de almacenamiento de su clústerstorage: 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 valortrueindica 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: {}
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 valortrueindica 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: