Passaggio da Kafka a Woodpecker

Questa pagina descrive come passare dalla coda dei messaggi (MQ) di un cluster Milvus da Kafka (integrato o esterno) a Woodpecker (backend MinIO) e viceversa. Per il flusso di lavoro generale e i prerequisiti, consultare Passare alla coda dei messaggi.

Con Helm

Passaggio da Kafka a Woodpecker (Helm)

Passaggio 1: Verifica che l’istanza di Milvus sia in esecuzione. Assicurati che il tuo cluster Milvus funzioni correttamente — ad esempio, creando una raccolta di prova, inserendo dati ed eseguendo una query.

Passo 2: Eseguire il cambio di MQ. Esporre l’interfaccia di gestione MixCoord, quindi chiamare l’API di cambio:

kubectl port-forward --address 0.0.0.0 service/my-release-milvus-mixcoord 29091:9091

In un altro terminale:

curl -X POST http://127.0.0.1:29091/management/wal/alter \
  -H "Content-Type: application/json" \
  -d '{"target_wal_name": "woodpecker"}'

Passaggio 3: Verifica che il passaggio sia stato completato.

kubectl logs <mixcoord-pod> | grep "successfully updated mq.type configuration in etcd"

Se il passaggio va a buon fine, viene registrato il messaggio " [mqTypeValue=woodpecker]".

Passaggio 4: (Facoltativo) Arrestare Kafka ed eseguire la pulizia. Per Kafka integrato, rimuovere i pod Kafka e i relativi PVC. Per Kafka esterno, ripulire gli argomenti Milvus nell’istanza Kafka esterna: seguono il formato <cluster_prefix>-dml_<seqNo>_<TimeTick><Version>.

Passaggio da Woodpecker a Kafka (Helm)

Passaggio 1: Verificare che l’istanza di Milvus sia in esecuzione.

Passaggio 2: configurare la connessione a Kafka di destinazione e riavviare Milvus. Il passaggio richiede che Milvus conosca già la connessione a Kafka, quindi inserirla in user.yaml tramite extraConfigFiles e applicare con helm upgrade (che esegue il rollover dei pod). streaming.enabled=true è necessario per la funzionalità Switch MQ. Per i dettagli su SASL/SSL, consultare Connettersi a Kafka con SASL/SSL.

# values.yaml
extraConfigFiles:
  user.yaml: |+
    kafka:
      brokerList:
        - <your_kafka_address>:<your_kafka_port>
      saslUsername:
      saslPassword:
      saslMechanisms: PLAIN
      securityProtocol: SASL_SSL

helm upgrade -i my-release zilliztech/milvus \
  --set kafka.enabled=true \
  --set woodpecker.enabled=false \
  --set streaming.enabled=true \
  -f values.yaml

Attendere che tutti i pod siano pronti, quindi verificare che la configurazione di accesso a Kafka sia stata incorporata nella configurazione di Milvus.

Passaggio 3: Eseguire il passaggio a MQ.

kubectl port-forward --address 0.0.0.0 service/my-release-milvus-mixcoord 29091:9091

In un altro terminale:

curl -X POST http://127.0.0.1:29091/management/wal/alter \
  -H "Content-Type: application/json" \
  -d '{"target_wal_name": "kafka"}'

Passaggio 4: verificare che il passaggio sia stato completato.

kubectl logs <mixcoord-pod> | grep "successfully updated mq.type configuration in etcd"

Se il passaggio ha esito positivo, viene registrato il messaggio " [mqTypeValue=kafka]".

Passaggio 5: (Facoltativo) Eliminare i dati di Woodpecker. Eliminare i dati di Woodpecker su MinIO/S3 (nella directory <rootPath>/wp/..., in genere files/wp/...) e i metadati di Woodpecker in etcd (etcdctl get woodpecker --prefix). Se si prevede di tornare a Woodpecker in un secondo momento, eliminare prima questi file.

Con Milvus Operator

Passaggio da Kafka a Woodpecker (Milvus Operator)

Passaggio 1: Verificare che l’istanza di Milvus sia in esecuzione.

Passaggio 2: Eseguire il passaggio a MQ. Il servizio MixCoord non è esposto, quindi eseguire l’API di passaggio dall’interno del pod MixCoord:

kubectl exec -it <mixcoord-pod> -- \
  curl -X POST http://localhost:9091/management/wal/alter \
  -H "Content-Type: application/json" \
  -d '{"target_wal_name": "woodpecker"}'

Passaggio 3: Verificare che il passaggio sia stato completato.

kubectl logs <mixcoord-pod> | grep "successfully updated mq.type configuration in etcd"

Se il passaggio va a buon fine, viene registrato il messaggio " [mqTypeValue=woodpecker]".

Passaggio 4: aggiornare il tipo di MQ nell’Operator. Aggiornare la configurazione gestita dall’Operator in modo che l’Operator non annulli il passaggio. Creare change_configmap.yaml:

apiVersion: milvus.io/v1beta1
kind: Milvus
metadata:
  name: my-release
  labels:
    app: milvus
spec:
  dependencies:
    msgStreamType: woodpecker

kubectl patch -f change_configmap.yaml --patch-file change_configmap.yaml --type merge

Passaggio 5: (Facoltativo) Arrestare Kafka ed eseguire la pulizia. Per Kafka integrato, rimuovere i pod Kafka e i relativi PVC. Per Kafka esterno, ripulire gli argomenti Milvus (formato <cluster_prefix>-dml_<seqNo>_<TimeTick><Version>).

Passaggio da Woodpecker a Kafka (Operatore Milvus)

Passaggio 1: Verificare che l’istanza di Milvus sia in esecuzione.

Passaggio 2: configurare la connessione a Kafka di destinazione e riavviare Milvus. Inserire la connessione a Kafka in spec.config (l’Operator converte spec.config in user.yaml) e impostare il tipo di MQ; l’applicazione del CR aggiorna i pod con la nuova configurazione. Per i dettagli su SASL/SSL, consultare Connettersi a Kafka con SASL/SSL.

# change_configmap.yaml
apiVersion: milvus.io/v1beta1
kind: Milvus
metadata:
  name: my-release
  labels:
    app: milvus
spec:
  config:
    kafka:
      brokerList:
        - <your_kafka_address>:<your_kafka_port>
      saslUsername:
      saslPassword:
      saslMechanisms: PLAIN
      securityProtocol: SASL_SSL
  dependencies:
    msgStreamType: kafka

kubectl patch -f change_configmap.yaml --patch-file change_configmap.yaml --type merge

Attendere che tutti i pod siano pronti, quindi verificare che la configurazione di accesso a Kafka sia stata applicata alla configurazione di Milvus.

Passaggio 3: Eseguire il passaggio a MQ.

kubectl exec -it <mixcoord-pod> -- \
  curl -X POST http://localhost:9091/management/wal/alter \
  -H "Content-Type: application/json" \
  -d '{"target_wal_name": "kafka"}'

Passaggio 4: Verificare che il passaggio sia stato completato.

kubectl logs <mixcoord-pod> | grep "successfully updated mq.type configuration in etcd"

Se il passaggio va a buon fine, viene registrato il messaggio « [mqTypeValue=kafka] ».

Passaggio 5: (Facoltativo) Eliminare i dati di Woodpecker. Eliminare i dati di Woodpecker su MinIO/S3 (nella directory <rootPath>/wp/..., in genere files/wp/...) e i metadati di Woodpecker in etcd (etcdctl get woodpecker --prefix). Se si prevede di tornare a Woodpecker in un secondo momento, eliminare prima questi file.

Scenari supportati

MQ di origine	MQ di destinazione	Helm	Operatore Milvus
Kafka integrato	Woodpecker (MinIO)	Supportato	Supportato
Kafka esterno	Woodpecker (MinIO)	Supportato	Supportato
Woodpecker (MinIO)	Kafka esterno	Supportato	Supportato
Kafka	Woodpecker (locale)	Supportato ma non consigliato (tutti i pod necessitano di un sistema di file condiviso)	Non supportato