### Example Output: Kubectl Get Pods for Milvus Operator

Source: https://github.com/zilliztech/milvus-operator/blob/main/docs/installation/installation.md

Illustrative output showing the status of the Milvus Operator pod after successful deployment, indicating it is ready and running.

```log
NAME                                                  READY   STATUS    RESTARTS   AGE
milvus-operator-698fc7dc8d-8f52d   1/1     Running   0          65s
```

--------------------------------

### Example Output: Milvus Instance Ready Condition

Source: https://github.com/zilliztech/milvus-operator/blob/main/docs/installation/installation.md

Illustrative output confirming that the Milvus instance has met its 'MilvusReady' condition, indicating successful deployment and readiness.

```text
milvus.milvus.io/my-release condition met
```

--------------------------------

### Install Milvus Operator with Helm (Quick Start)

Source: https://github.com/zilliztech/milvus-operator/blob/main/docs/installation/installation.md

Installs the Milvus Operator using Helm from a remote chart. This is the recommended quick start method for deploying the operator.

```shell
helm install milvus-operator \
  -n milvus-operator --create-namespace \
  https://github.com/zilliztech/milvus-operator/releases/download/v1.3.0-rc1/milvus-operator-1.3.0-rc1.tgz
```

--------------------------------

### Kind Installation Guide for Local Development

Source: https://github.com/zilliztech/milvus-operator/blob/main/docs/installation/installation.md

Reference to the documentation for installing Kind (Kubernetes in Docker) for local development purposes, useful for setting up a local testing environment.

```text
Kind installation guide: ./kind-installation.md
```

--------------------------------

### Example Output: Kubectl Get Service for Milvus

Source: https://github.com/zilliztech/milvus-operator/blob/main/docs/installation/installation.md

Illustrative output showing the service details for a deployed Milvus instance, including its external IP, cluster IP, and exposed ports.

```text
NAME               TYPE          CLUSTER-IP     EXTERNAL-IP    PORT(S)                         AGE
my-release-milvus  LoadBalancer  10.101.144.12  10.100.31.101  19530:31309/TCP,9091:30197/TCP  10m
```

--------------------------------

### Example: Connecting to Milvus Instance

Source: https://github.com/zilliztech/milvus-operator/blob/main/docs/installation/installation.md

Illustrative Python-like code snippet showing how to connect to a Milvus instance using its external IP address and port. This demonstrates the usage of the retrieved external IP.

```text
connections.connect("default", host="10.100.31.101", port="19530")
```

--------------------------------

### Quick Start Milvus Operator with Minimum Configuration

Source: https://github.com/zilliztech/milvus-operator/blob/main/charts/milvus-operator/templates/NOTES.txt

Apply a minimal Milvus Operator configuration directly from the official GitHub repository to quickly get started. This command fetches a sample YAML file and applies it to your Kubernetes cluster.

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

--------------------------------

### Milvus Operator Administration Guides

Source: https://github.com/zilliztech/milvus-operator/blob/main/docs/installation/installation.md

Reference to the administration guides for the Milvus Operator, covering topics related to managing and maintaining the operator.

```APIDOC
Administration Guides: https://github.com/zilliztech/milvus-operator/tree/main/docs/administration
```

--------------------------------

### Deploy Milvus Standalone Demo Instance

Source: https://github.com/zilliztech/milvus-operator/blob/main/docs/installation/installation.md

Deploys a single-node Milvus instance for demonstration purposes by applying a sample YAML manifest with kubectl.

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

--------------------------------

### Deploy Milvus Cluster Demo Instance

Source: https://github.com/zilliztech/milvus-operator/blob/main/docs/installation/installation.md

Deploys a Milvus cluster instance for demonstration purposes by applying a sample YAML manifest with kubectl.

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

--------------------------------

### List Helm Installations for Milvus Operator

Source: https://github.com/zilliztech/milvus-operator/blob/main/docs/installation/installation.md

Lists all Helm releases within the 'milvus-operator' namespace to verify the installation status of the Milvus Operator.

```shell
helm -n milvus-operator list
```

--------------------------------

### Milvus Operator Common Configuration Samples

Source: https://github.com/zilliztech/milvus-operator/blob/main/docs/installation/installation.md

Reference to a collection of common configuration samples for the Milvus Operator, useful for understanding typical deployment patterns and settings.

```APIDOC
Common configuration samples: https://github.com/zilliztech/milvus-operator/tree/main/config/samples
```

--------------------------------

### Install Milvus Operator using Kubectl Apply

Source: https://github.com/zilliztech/milvus-operator/blob/main/docs/installation/installation.md

Deploys the Milvus Operator by applying a raw deployment manifest directly with kubectl. This method is an alternative to Helm for installation.

```shell
kubectl apply -f https://raw.githubusercontent.com/zilliztech/milvus-operator/v1.3.0-rc1/deploy/manifests/deployment.yaml
```

--------------------------------

### Get Helm Configuration Values for Milvus Operator

Source: https://github.com/zilliztech/milvus-operator/blob/main/docs/installation/installation.md

Retrieves the current configuration values of the 'milvus-operator' Helm release, useful for inspecting its settings.

```shell
helm -n milvus-operator get values milvus-operator
```

--------------------------------

### Check Milvus Operator Pods with Kubectl

Source: https://github.com/zilliztech/milvus-operator/blob/main/docs/installation/installation.md

Lists the pods in the 'milvus-operator' namespace to verify that the Milvus Operator has been successfully deployed and is running.

```shell
kubectl get pods -n milvus-operator
```

--------------------------------

### Example Output of Kubernetes Cluster Information (Log)

Source: https://github.com/zilliztech/milvus-operator/blob/main/docs/installation/kind-installation.md

This log snippet shows a typical output from the `kubectl cluster-info` command, indicating the successful running status of the Kubernetes master and KubeDNS services.

```log
Kubernetes master is running at https://127.0.0.1:39821
KubeDNS is running at https://127.0.0.1:39821/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy

To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.
```

--------------------------------

### Wait for Milvus Instance Readiness Condition

Source: https://github.com/zilliztech/milvus-operator/blob/main/docs/installation/installation.md

Waits for the deployed Milvus instance to reach the 'MilvusReady' condition, with a timeout of 10 minutes, ensuring the instance is fully operational before proceeding.

```shell
kubectl wait --for=condition=MilvusReady  milvus/my-release --timeout 10m
```

--------------------------------

### Install Milvus Operator with Helm, Disabling Cert-Manager Check

Source: https://github.com/zilliztech/milvus-operator/blob/main/docs/installation/installation.md

Installs the Milvus Operator using Helm, specifically disabling the cert-manager check. Use this option if you have a non-default cert-manager installation to avoid errors.

```shell
helm install milvus-operator \
  -n milvus-operator --create-namespace \
  https://github.com/zilliztech/milvus-operator/releases/download/v1.3.0-rc1/milvus-operator-1.3.0-rc1.tgz \
  --set checker.disableCertManagerCheck=true
```

--------------------------------

### Install Milvus Operator using Kubectl and Raw Manifests

Source: https://github.com/zilliztech/milvus-operator/blob/main/README.md

This command applies the Milvus Operator deployment manifest directly from a GitHub raw URL using kubectl, providing an alternative installation method without Helm.

```shell
kubectl apply -f https://raw.githubusercontent.com/zilliztech/milvus-operator/v1.3.0-rc1/deploy/manifests/deployment.yaml
```

--------------------------------

### Get Milvus Service External IP Address

Source: https://github.com/zilliztech/milvus-operator/blob/main/docs/installation/installation.md

Retrieves information about Kubernetes services, including the external IP address of the deployed Milvus instance, which is necessary for external access.

```shell
kubectl get service
```

--------------------------------

### Milvus Custom Resource Definition (CRD) Configuration Fields

Source: https://github.com/zilliztech/milvus-operator/blob/main/docs/installation/installation.md

Reference to the documentation for all configurable fields within the Milvus Custom Resource Definition (CRD), providing details for advanced configuration.

```APIDOC
Milvus CRD: All configuration fields for Milvus CRD are documented at ../CRD/milvus.md
```

--------------------------------

### Install OpenSSL on Ubuntu

Source: https://github.com/zilliztech/milvus-operator/blob/main/docs/administration/security/encryption-in-transit.md

Install OpenSSL on Ubuntu using the apt package manager if it's not already installed.

```shell
sudo apt install openssl
```

--------------------------------

### Install Milvus Operator using Helm

Source: https://github.com/zilliztech/milvus-operator/blob/main/README.md

This command installs or upgrades the Milvus Operator using Helm, fetching the chart directly from a GitHub release URL. It creates the 'milvus-operator' namespace if it doesn't exist.

```shell
helm upgrade --install milvus-operator \
  -n milvus-operator --create-namespace \
  https://github.com/zilliztech/milvus-operator/releases/download/v1.3.0-rc1/milvus-operator-1.3.0-rc1.tgz
```

--------------------------------

### Define Kind Cluster Configuration (YAML)

Source: https://github.com/zilliztech/milvus-operator/blob/main/docs/installation/kind-installation.md

This YAML snippet outlines the configuration for a Kind cluster, specifying one control-plane node and three worker nodes. This setup is ideal for local development and testing environments.

```yaml
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
- role: control-plane
- role: worker
- role: worker
- role: worker
```

--------------------------------

### Deploy Milvus Operator using Kubectl and Raw Manifests

Source: https://github.com/zilliztech/milvus-operator/blob/main/README.md

Command to apply the Milvus Operator deployment manifest directly using kubectl from a raw GitHub URL, providing an alternative installation method without Helm.

```shell
kubectl apply -f https://raw.githubusercontent.com/zilliztech/milvus-operator/v1.3.0-rc1/deploy/manifests/deployment.yaml
```

--------------------------------

### Check Milvus Operator Deployment Status

Source: https://github.com/zilliztech/milvus-operator/blob/main/charts/milvus-operator/templates/NOTES.txt

Use this `kubectl` command to verify if the Milvus Operator has been successfully installed and deployed in your Kubernetes cluster. Replace `{{ .Release.Namespace }}` and `{{ .Release.Name }}` with your specific release details.

```Shell
kubectl get -n {{ .Release.Namespace }} deploy/{{ .Release.Name }}
```

--------------------------------

### Upgrade Milvus Operator using Helm

Source: https://github.com/zilliztech/milvus-operator/blob/main/docs/installation/installation.md

Upgrades an existing Milvus Operator Helm release to a newer version, reusing existing configuration values. This command ensures a smooth update process.

```shell
helm upgrade -n milvus-operator milvus-operator --reuse-values \
  https://github.com/zilliztech/milvus-operator/releases/download/v1.3.0-rc1/milvus-operator-1.3.0-rc1.tgz
```

--------------------------------

### Check OpenSSL Installation

Source: https://github.com/zilliztech/milvus-operator/blob/main/docs/administration/security/encryption-in-transit.md

Verify if OpenSSL is installed on your system by checking its version. This is a prerequisite for generating certificates.

```shell
openssl version
```

--------------------------------

### Uninstall Milvus Operator using Helm

Source: https://github.com/zilliztech/milvus-operator/blob/main/docs/installation/installation.md

Deletes the Milvus Operator Helm release and its associated resources from the specified namespace, effectively uninstalling the operator.

```shell
helm uninstall milvus-operator -n milvus-operator
```

--------------------------------

### Configure Extensions for User Certificates in OpenSSL

Source: https://github.com/zilliztech/milvus-operator/blob/main/docs/administration/security/encryption-in-transit.md

Details various X.509 extensions applicable to end-user certificates, including basic constraints, nsCertType examples (server, client, email, objsign), keyUsage, nsComment, subjectKeyIdentifier, authorityKeyIdentifier, and subjectAltName options. Also includes commented-out examples for URL-related extensions and extendedKeyUsage.

```OpenSSL Config
[ usr_cert ]

# These extensions are added when 'ca' signs a request.

# This goes against PKIX guidelines but some CAs do it and some software
# requires this to avoid interpreting an end user certificate as a CA.

basicConstraints=CA:FALSE

# Here are some examples of the usage of nsCertType. If it is omitted
# the certificate can be used for anything *except* object signing.

# This is OK for an SSL server.
# nsCertType			= server

# For an object signing certificate this would be used.
# nsCertType = objsign

# For normal client use this is typical
# nsCertType = client, email

# and for everything including object signing:
# nsCertType = client, email, objsign

# This is typical in keyUsage for a client certificate.
# keyUsage = nonRepudiation, digitalSignature, keyEncipherment

# This will be displayed in Netscape's comment listbox.
nsComment			= "OpenSSL Generated Certificate"

# PKIX recommendations harmless if included in all certificates.
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid,issuer

# This stuff is for subjectAltName and issuerAltname.
# Import the email address.
# subjectAltName=email:copy
# An alternative to produce certificates that aren't
# deprecated according to PKIX.
# subjectAltName=email:move

# Copy subject details
# issuerAltName=issuer:copy

#nsCaRevocationUrl		= http://www.domain.dom/ca-crl.pem
#nsBaseUrl
#nsRevocationUrl
#nsRenewalUrl
#nsCaPolicyUrl
#nsSslServerName

# This is required for TSA certificates.
# extendedKeyUsage = critical,timeStamping
```

--------------------------------

### Example Milvus Operator Global Component Configuration

Source: https://github.com/zilliztech/milvus-operator/blob/main/docs/CRD/milvus.md

This YAML snippet demonstrates how to define global specifications for Milvus operator components. It includes settings for enabling rolling updates, specifying image update modes, pausing deployments, applying global pod labels and annotations, defining the Milvus image and pull policy, setting environment variables, configuring node selectors and tolerations, and allocating compute resources. It also shows options for volumes, service accounts, metrics, and tool images.

```yaml
spec:
  components:
    # Components specifications

    # Components global specifications

    # Enable rolling update, supported in milvus v2.2.3.
    # For compatity reason defaults to false, but we suggest you to enable it if you are using milvus v2.2.3 or above.
    enableRollingUpdate: true # Optional default=false

    # imageUpdateMode is the mode when update components' image.
    # rollingUpgrade: to update the components' image in the order of coords -> nodes -> proxy
    # rollingDowngrade: to update the components' image in the order of proxy -> nodes -> coords
    # all: to update all the components' image rightaway.
    # one of rollingUpgrade / rollingDowngrade / all
    imageUpdateMode: rollingUpgrade # Optional default=rollingUpgrade

    # Paused is used to pause all components' deployment rollout
    paused: false # Optional

    # Global pod labels.
    podLabels: # Optional
      key: value
    
    # Global pod annotations.
    podAnnotations: # Optional
      key: value

    # Global image name for milvus components. It will override the default one. Default is determined by operator version
    image: milvusdb/milvus:latest # Optional

    # Global image pull policy. It will override the the default one.
    imagePullPolicy: IfNotPresent # Optional, default = IfNotPresent

    # Global image pull secrets.
    imagePullSecrets: # Optional
    - name: mySecret
    # Global environment variables
    env: # Optional
    - name: key
      value: value

    # Global nodeSelector.
    # NodeSelector is a selector which must be true for the component to fit on a node.
    # Selector which must match a node's labels for the pod to be scheduled on that node.
    # More info: https://kubernetes.io/docs/concepts/configuration/assign-pod-node/
    nodeSelector: # Optional
      key: value

    # Global tolerations.
    # If specified, the pod's tolerations.
    # More info: https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/
    tolerations: {} # Optional
    
    # Global compute resources required.
    # Compute Resources required by this component.
    # Cannot be updated.
    # More info: https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/
    resources: # Optional
      # Limits describes the maximum amount of compute resources allowed.
      # More info: https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/
      limits: {} # Optional
      # Requests describes the minimum amount of compute resources required.
      # If Requests is omitted for a container, it defaults to Limits if that is explicitly specified,
      # otherwise to an implementation-defined value.
      # More info: https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/
      requests: {} # Optional

    # Global volumes for all components 
    # More info: https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.21/#volume-v1-core
    volumes: [] # Optional
    
    # Global volumeMounts.
    # More info: https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.21/#volumemount-v1-core
    VolumeMounts: [] # Optional

    # Global serviceAccountName.
    serviceAccountName: "" # Optional

    # Disable metrics collection for all components
    disableMetrics: false # Optional

    # The interval of podmonitor metric scraping in string
    metricInterval : "30s" # Optional

    # ToolImage specify tool image to merge milvus config to original one in image, default uses same image as milvus-operator
    toolImage: "" # Optional

    # UpdateToolImage specifies when milvus-operator upgraded, whether milvus should restart to update the tool image, too
    updateToolImage: false # Optional

    # Components private specifications
    # ... Skipped fields
```

--------------------------------

### Milvus Operator Resource Allocation Example

Source: https://github.com/zilliztech/milvus-operator/blob/main/docs/administration/allocate-resources.md

This YAML configuration demonstrates how to set resource limits (CPU and memory) for different components within a Milvus cluster managed by the Milvus Operator. It shows specific allocations for 'mixCoord' (1 CPU, 2 GiB), 'proxy' (2 CPUs, 4 GiB), and a default for all other components (4 CPUs, 8 GiB).

```yaml
apiVersion: milvus.io/v1beta1
kind: Milvus
metadata:
  name: my-release
  labels:
    app: milvus
spec:
  # Omit other fields ...
  mode: cluster
  components:
    resources:
      limits:
        cpu: '4'
        memory: 8Gi
    mixCoord:
      resources:
        limits:
          cpu: '1'
          memory: 2Gi
    proxy:
      serviceType: LoadBalancer
      resources:
        limits:
          cpu: '2'
          memory: 4Gi
```

--------------------------------

### Deploy Milvus Operator using Helm

Source: https://github.com/zilliztech/milvus-operator/blob/main/README.md

Commands to add the Milvus Operator Helm repository, update it, and install or upgrade the operator in a Kubernetes cluster, ensuring the latest version is deployed.

```shell
helm repo add milvus-operator https://zilliztech.github.io/milvus-operator/
helm repo update milvus-operator
helm -n milvus-operator upgrade --install --create-namespace milvus-operator milvus-operator/milvus-operator
```

--------------------------------

### Apply MilvusUpgrade Configuration to Start Migration

Source: https://github.com/zilliztech/milvus-operator/blob/main/docs/administration/upgrade.md

This `kubectl` command applies the `milvusupgrade.yaml` file, initiating the metadata migration process for the Milvus cluster. This step is crucial for upgrading Milvus 2.1.x to 2.2.x due to metadata structure changes.

```shell
kubectl apply -f milvusupgrade.yaml
```

--------------------------------

### Configure Internal Kafka Service for Milvus

Source: https://github.com/zilliztech/milvus-operator/blob/main/docs/administration/manage-dependencies/message-storage.md

This YAML configuration illustrates how to deploy an internal Kafka service alongside a Milvus cluster. It sets `msgStreamType` to 'kafka' and enables `inCluster` for Kafka, allowing Milvus to automatically start a Kafka instance within the cluster. It notes that `values` can be found in the Bitnami Kafka Helm chart.

```YAML
apiVersion: milvus.io/v1beta1
kind: Milvus
metadata:
  name: my-release
  labels:
    app: milvus
spec: 
  dependencies:
    msgStreamType: "kafka"
    kafka:
      inCluster: 
        values: {} # values can be found in https://github.com/bitnami/charts/blob/1fdd2283f0e5a8772e4a763b455733c77e01b119/bitnami/kafka/values.yaml
```

--------------------------------

### Configure Extensions for OpenSSL Proxy Certificates

Source: https://github.com/zilliztech/milvus-operator/blob/main/docs/administration/security/encryption-in-transit.md

Details extensions for proxy certificates, similar to user certificates, including basicConstraints (CA:FALSE), and examples for nsCertType (server, objsign, client, email) and keyUsage.

```OpenSSL Config
[ proxy_cert_ext ]
# These extensions should be added when creating a proxy certificate

# This goes against PKIX guidelines but some CAs do it and some software
# requires this to avoid interpreting an end user certificate as a CA.

basicConstraints=CA:FALSE

# Here are some examples of the usage of nsCertType. If it is omitted
# the certificate can be used for anything *except* object signing.

# This is OK for an SSL server.
# nsCertType			= server

# For an object signing certificate this would be used.
# nsCertType = objsign

# For normal client use this is typical
# nsCertType = client, email

# and for everything including object signing:
# nsCertType = client, email, objsign

# This is typical in keyUsage for a client certificate.
# keyUsage = nonRepudiation, digitalSignature, keyEncipherment
```

--------------------------------

### Delete Milvus Operator using Makefile

Source: https://github.com/zilliztech/milvus-operator/blob/main/docs/installation/installation.md

Uninstalls the Milvus Operator by executing the 'undeploy' target in the project's Makefile, providing an alternative deletion method.

```shell
make undeploy
```

--------------------------------

### Milvus CRD Basic Structure (YAML)

Source: https://github.com/zilliztech/milvus-operator/blob/main/docs/CRD/milvus.md

Illustrates the basic structure of the Milvus Custom Resource Definition (CRD), including apiVersion, kind, metadata, and top-level spec fields like mode, components, dependencies, and config. It provides a starting point for defining a Milvus cluster.

```yaml
apiVersion: milvus.io/v1beta1
kind: Milvus
metadata:
  name: milvus-sample
  namespace: sample-ns
spec:
  mode: standalone # Optional ("standalone", "cluster") default="standalone"
  components: {} # Optional
  dependencies: {} # Optional
  config: {} # Optional
```

--------------------------------

### Configure Extensions for OpenSSL CA Certificates (v3)

Source: https://github.com/zilliztech/milvus-operator/blob/main/docs/administration/security/encryption-in-transit.md

Defines extensions typical for a Certificate Authority (CA) certificate, including subjectKeyIdentifier, authorityKeyIdentifier, and basicConstraints (set to CA:true). Also includes commented-out examples for keyUsage and nsCertType for CA certificates.

```OpenSSL Config
[ v3_ca ]


# Extensions for a typical CA


# PKIX recommendation.

subjectKeyIdentifier=hash

authorityKeyIdentifier=keyid:always,issuer

# This is what PKIX recommends but some broken software chokes on critical
# extensions.
#basicConstraints = critical,CA:true
# So we do this instead.
basicConstraints = CA:true

# Key usage: this is typical for a CA certificate. However since it will
# prevent it being used as an test self-signed certificate it is best
# left out by default.
# keyUsage = cRLSign, keyCertSign

# Some might want this also
# nsCertType = sslCA, emailCA

# Include email address in subject alt name: another PKIX recommendation
# subjectAltName=email:copy
# Copy issuer details
# issuerAltName=issuer:copy

# DER hex encoding of an extension: beware experts only!
# obj=DER:02:03
# Where 'obj' is a standard or added object
# You can even override a supported extension:
# basicConstraints= critical, DER:30:03:01:01:FF
```

--------------------------------

### Milvus Operator Cluster Configuration Override (YAML)

Source: https://github.com/zilliztech/milvus-operator/blob/main/docs/CRD/milvus.md

Provides an example of how to override specific fields within the Milvus Cluster's internal configuration file using the `config` section. This allows customizing settings for dependencies like etcd's root path and minio's bucket name directly through the operator's custom resource.

```yaml
spec:
  dependencies: {}
  components: {}
  config: # Optional
    etcd:
      rootPath: my-release
    minio:
      bucketName: my-bucket
```

--------------------------------

### Scale out Milvus Cluster Components using YAML

Source: https://github.com/zilliztech/milvus-operator/blob/main/docs/administration/scale-a-milvus-cluster.md

This example demonstrates how to horizontally scale out a Milvus cluster by increasing the replica counts for specific components in the Milvus custom resource definition. It shows setting 2 proxies, 3 query nodes, 3 index nodes, and 3 data nodes, while keeping mixCoord at 1 replica.

```yaml
apiVersion: milvus.io/v1beta1
kind: Milvus
metadata:
  name: my-release
  labels:
    app: milvus
spec:
  # Omit other fields ...
  mode: cluster
  components:
    dataNode:
      replicas: 3
    indexNode:
      replicas: 3
    queryNode:
      replicas: 3
    mixCoord:
      replicas: 1
    proxy:
      serviceType: LoadBalancer
      replicas: 2
```

--------------------------------

### Configure Milvus log settings via CRD

Source: https://github.com/zilliztech/milvus-operator/blob/main/docs/administration/configure-milvus.md

This example demonstrates how to modify Milvus's logging configurations, such as log level, maximum log file size, and root path, by specifying them within the `spec.config` section of the Milvus CRD. This overrides the default log settings.

```yaml
apiVersion: milvus.io/v1beta1
kind: Milvus
metadata:
  name: my-release
  labels:
    app: milvus
spec:
  config:
    # ref: https://milvus.io/docs/configure_log.md
    log:
      level: warn
      file:
        maxSize: 300
        rootPath: /var/log/milvus
```

--------------------------------

### Scale in Milvus Cluster Components using YAML

Source: https://github.com/zilliztech/milvus-operator/blob/main/docs/administration/scale-a-milvus-cluster.md

This example demonstrates how to horizontally scale in a Milvus cluster by decreasing the replica counts for all components to 1 in the Milvus custom resource definition. This can be used to reduce resource consumption when the cluster is under-utilized. Setting replicas to 0 can stop Milvus without deleting resources.

```yaml
apiVersion: milvus.io/v1beta1
kind: Milvus
metadata:
  name: my-release
  labels:
    app: milvus
spec:
  # Omit other fields ...
  mode: cluster
  components:
    replicas: 1
```

--------------------------------

### Verify Kubernetes Cluster Information (Shell)

Source: https://github.com/zilliztech/milvus-operator/blob/main/docs/installation/kind-installation.md

Run this `kubectl` command to display essential information about the currently configured Kubernetes cluster. It provides details such as the master URL and KubeDNS service endpoint.

```shell
kubectl cluster-info
```

--------------------------------

### Delete Milvus Operator using Kubectl Delete

Source: https://github.com/zilliztech/milvus-operator/blob/main/docs/installation/installation.md

Removes the Milvus Operator and its resources by deleting the deployment manifest directly with kubectl.

```shell
kubectl delete -f https://raw.githubusercontent.com/zilliztech/milvus-operator/v1.3.0-rc1/deploy/manifests/deployment.yaml
```

--------------------------------

### Create Milvus Demo Instance

Source: https://github.com/zilliztech/milvus-operator/blob/main/README.md

Command to deploy a standalone Milvus demo instance with its dependencies using kubectl, suitable for testing and development environments with minimal resource requirements.

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

--------------------------------

### Create Kind Cluster from Configuration File (Shell)

Source: https://github.com/zilliztech/milvus-operator/blob/main/docs/installation/kind-installation.md

Execute this shell command to create a new Kind Kubernetes cluster named 'myk8s'. The cluster's topology and settings are defined in the `kind.yaml` configuration file.

```shell
kind create cluster --name myk8s --config kind.yaml
```

--------------------------------

### Apply Milvus Operator Sample Configuration

Source: https://github.com/zilliztech/milvus-operator/blob/main/docs/administration/manage-dependencies/object-storage.md

This command applies a sample `demo.yaml` configuration file for the Milvus Operator, which can then be edited to configure third-party dependencies like object storage.

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

--------------------------------

### Apply Milvus Operator Demo Configuration

Source: https://github.com/zilliztech/milvus-operator/blob/main/docs/administration/manage-dependencies/meta-storage.md

This shell command applies the default `demo.yaml` configuration from the Milvus Operator repository. It serves as the initial step to deploy a Milvus instance, which can then be customized for meta storage dependencies like etcd.

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

--------------------------------

### Create Milvus User with Python

Source: https://github.com/zilliztech/milvus-operator/blob/main/docs/administration/security/enable-authentication.md

This Python snippet uses the "pymilvus" library to create a new user with a specified username and password. It leverages the "utility.create_user" function, allowing for user management within a Milvus instance. The "using" parameter specifies the Milvus server alias.

```python
from pymilvus import utility
utility.create_user('user', 'password', using='default')
```

```APIDOC
utility.create_user(user: str, password: str, using: str)
  user: Username to create.
  password: Password for the user to create.
  using: Alias of the Milvus server to create the user.
```

--------------------------------

### Create Certificate Directory and Configuration Files

Source: https://github.com/zilliztech/milvus-operator/blob/main/docs/administration/security/encryption-in-transit.md

Create a new directory named 'cert' and navigate into it. Then, create two empty files, `openssl.cnf` and `gen.sh`, which will be used for certificate generation.

```shell
mkdir cert && cd cert
touch openssl.cnf gen.sh
```

--------------------------------

### Connect to Milvus with Authenticated User in Python

Source: https://github.com/zilliztech/milvus-operator/blob/main/docs/administration/security/enable-authentication.md

This Python snippet demonstrates how to establish a connection to a Milvus server using specific user credentials. It utilizes the "connections.connect" function from "pymilvus", requiring host, port, username, and password for secure access. The "alias" parameter provides a convenient name for the connection.

```python
from pymilvus import connections
connections.connect(
    alias='default',
    host='localhost',
    port='19530',
    user='user',
    password='password',
)
```

```APIDOC
connections.connect(alias: str, host: str, port: str, user: str, password: str)
  alias: Alias of the Milvus server to connect.
  host: IP address of the Milvus server to connect.
  port: Port of the Milvus server to connect.
  user: Username used to connect.
  password: Password used to connect.
```

--------------------------------

### Execute OpenSSL Certificate Generation Script

Source: https://github.com/zilliztech/milvus-operator/blob/main/docs/administration/security/encryption-in-transit.md

These commands provide instructions on how to make the `gen.sh` script executable and then run it. Executing the script will generate all necessary certificate and key files, including `ca.key`, `ca.pem`, `ca.srl`, `server.key`, `server.pem`, `server.csr`, `client.key`, `client.pem`, and `client.csr`.

```shell
chmod +x gen.sh
./gen.sh
```

--------------------------------

### Milvus Operator Dependencies Configuration (YAML)

Source: https://github.com/zilliztech/milvus-operator/blob/main/docs/CRD/milvus.md

Outlines the structure for configuring Milvus's external dependencies within the operator's custom resource. This includes options for `etcd`, `storage`, and specifying the `msgStreamType` (e.g., `pulsar`, `kafka`, `rocksmq`) along with their respective configurations.

```yaml
spec:
  # ... Skipped fields
  dependencies: # Optional
    etcd: {} # Optional
    storage: {} # Optional
    
    # Optional. msgStreamType determines which message stream to use. It should be one of "pulsar", "kafka", "rocksmq"
    # "rocksmq" is only available for standalone mode
    # by default, the operator will choose "pulsar" for cluster mode and "rocksmq" for standalone mode
    msgStreamType: "kafka" 
    pulsar: {} # Optional
    kafka: {} # Optional
```

--------------------------------

### Upgrade Milvus Operator to Latest Stable Version

Source: https://github.com/zilliztech/milvus-operator/blob/main/docs/administration/upgrade.md

This shell command sequence adds the Milvus Operator Helm repository, updates it, and then upgrades the Milvus Operator installation to its latest stable version. This is a prerequisite for upgrading Milvus 2.1.x to 2.2.x.

```shell
helm repo add milvus-operator https://zilliztech.github.io/milvus-operator/
helm repo update milvus-operator
helm -n milvus-operator upgrade milvus-operator milvus-operator/milvus-operator
```

--------------------------------

### Apply Milvus Operator Demo Configuration

Source: https://github.com/zilliztech/milvus-operator/blob/main/docs/administration/manage-dependencies/message-storage.md

This command applies the default demo configuration for Milvus Operator from a remote YAML file. It's a foundational step for customizing Milvus deployments and configuring third-party dependencies.

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

--------------------------------

### Milvus Operator YAML for In-Cluster etcd Configuration

Source: https://github.com/zilliztech/milvus-operator/blob/main/docs/administration/manage-dependencies/meta-storage.md

This YAML snippet demonstrates configuring an in-cluster etcd deployment for Milvus using the Milvus Operator. It specifies the desired `replicaCount` (e.g., 3 nodes) and resource `limits` (CPU, memory) for each etcd instance. It also includes `deletionPolicy` and `pvcDeletion` settings for managing etcd data persistence upon Milvus instance deletion.

```yaml
apiVersion: milvus.io/v1beta1
kind: Milvus
metadata:
  name: my-release
  labels:
    app: milvus
spec:
  # Omit other fields ...
  dependencies:
    # Omit other fields ...
    etcd:
      inCluster:
        values:
          replicaCount: 3
          resources:
            limits:
              cpu: 1
              memory: 4Gi
        deletionPolicy: Delete
        pvcDeletion: true
```

--------------------------------

### Milvus Operator RootCoord Component Configuration (YAML)

Source: https://github.com/zilliztech/milvus-operator/blob/main/docs/CRD/milvus.md

Illustrates the detailed configuration options for a `rootCoord` component, including `replicas`, `port`, and overrides for global specifications like `image`, `imagePullPolicy`, `imagePullSecrets`, `env`, `nodeSelector`, `tolerations`, and `resources`. These private component specifications take precedence over global settings.

```yaml
spec:
  components:
    # Global Component Spec fields
    # ... Skipped fields

    rootCoord: # Optional
      # Supply number of replicas.
      replicas: 1 # Optional, default=1

      # Port number the conponent's server will listen
      port: 8080 # Optional

      # Private Component Spec fields overrides the global ones
      image: milvusdb/milvus:latest # Optional
      imagePullPolicy: IfNotPresent # Optional
      imagePullSecrets: # Optional
      - name: mySecret
      env: # Optional
      - name: key
        value: value
      nodeSelector: # Optional
      - key: value
      tolerations: {} # Optional
      resources: {} # Optional
        requests: {} # Optional
        limits: {} # Optional

    # ... Skipped fields
  # ... Skipped fields
```

--------------------------------

### Milvus CRD default configuration deployment

Source: https://github.com/zilliztech/milvus-operator/blob/main/docs/administration/configure-milvus.md

This snippet shows a basic Milvus CRD deployment where no specific configurations are set under `spec.config`. In this scenario, the Milvus instance will use its default configuration file.

```yaml
apiVersion: milvus.io/v1beta1
kind: Milvus
metadata:
  name: my-release
  labels:
    app: milvus
spec:
  config: {}
# Omit other fields
# ...
```

--------------------------------

### Reset Milvus User Password with Python

Source: https://github.com/zilliztech/milvus-operator/blob/main/docs/administration/security/enable-authentication.md

This Python snippet allows resetting the password for an existing Milvus user using the "pymilvus" library. The "utility.reset_password" function requires the username, old password, and new password. The "using" parameter specifies the Milvus server alias.

```python
from pymilvus import utility
utility.reset_password('user', 'old_password', 'new_password', using='default')
```

```APIDOC
utility.reset_password(user: str, password: str, using: str)
  user: Username to reset password.
  password: New password for the user.
  using: Alias of the Milvus server.
```

--------------------------------

### List All Milvus Users with Python

Source: https://github.com/zilliztech/milvus-operator/blob/main/docs/administration/security/enable-authentication.md

This Python snippet retrieves a list of all authenticated usernames in Milvus using the "pymilvus" library. The "utility.list_usernames" function queries the specified Milvus server alias to fetch all registered users. The result is a list of usernames.

```python
from pymilvus import utility
users = utility.list_usernames(using='default')
```

```APIDOC
utility.list_usernames(using: str) -> list[str]
  using: Alias of the Milvus server.
```

--------------------------------

### Connect to Milvus with TLS using Python SDK

Source: https://github.com/zilliztech/milvus-operator/blob/main/docs/administration/security/encryption-in-transit.md

This Python code demonstrates how to establish a secure connection to a Milvus server using the PyMilvus SDK with TLS enabled. It specifies the paths to the client's certificate, private key, and the CA certificate for mutual authentication.

```python
from pymilvus import connections

_HOST = '127.0.0.1'
_PORT = '19530'

print(f"\nCreate connection...")
connections.connect(host=_HOST, port=_PORT, secure=True, client_pem_path="cert/client.pem",
                        client_key_path="cert/client.key",
                        ca_pem_path="cert/ca.pem", server_name="localhost")
print(f"\nList connections:")
print(connections.list_connections())
```

--------------------------------

### Configure Internal Pulsar Service for Milvus

Source: https://github.com/zilliztech/milvus-operator/blob/main/docs/administration/manage-dependencies/message-storage.md

This YAML configuration demonstrates how to set up an internal Pulsar service within a Milvus cluster with minimal resource allocation. It specifies resource requests, replica counts, and memory settings for Zookeeper, Bookkeeper, Broker, and Proxy components, optimizing for low resource consumption.

```YAML
apiVersion: milvus.io/v1beta1
kind: Milvus
metadata:
  name: my-release
  labels:
    app: milvus
spec:
  # Omit other fields ...
  dependencies:
    # Omit other fields ...
    pulsar:
      inCluster:
        chartVersion: pulsar-v3
        deletionPolicy: Delete
        pvcDeletion: true
        values:
          volumes:
            persistence: false
          components:
            autorecovery: false
          zookeeper:
            replicaCount: 1
            podMonitor:
              enabled: false
            resources:
              requests:
                memory: 64Mi
                cpu: 0.001
            volumes:
              # use a persistent volume or emptyDir
              persistence: false
            configData:
              PULSAR_MEM: >
                -Xms64m -Xmx256m
          bookkeeper:
            component: bookie
            replicaCount: 1
            podMonitor:
              enabled: false
            resources:
              requests:
                memory: 64Mi
                cpu: 0.001
            volumes:
              # use a persistent volume or emptyDir
              persistence: false
            configData:
              PULSAR_MEM: >
                -Xms64m
                -Xmx4096m
                -XX:MaxDirectMemorySize=8192m
          autorecovery:
            replicaCount: 0
            podMonitor:
              enabled: false
          broker:
            replicaCount: 1
            podMonitor:
              enabled: false
            resources:
              requests:
                memory: 64Mi
                cpu: 0.001
            configData:
              PULSAR_MEM: >
                -Xms64m -Xmx4096m -XX:MaxDirectMemorySize=8192m
              managedLedgerDefaultEnsembleSize: '1'
              managedLedgerDefaultWriteQuorum: '1'
              managedLedgerDefaultAckQuorum: '1'
          proxy:
            replicaCount: 1
            autoscaling:
              enabled: false
            podMonitor:
              enabled: false
              interval: 30s
              scrapeTimeout: 10s
            resources:
              requests:
                memory: 64Mi
                cpu: 0.001
            configData:
              PULSAR_MEM: >
                -Xms64m -Xmx512m -XX:MaxDirectMemorySize=2048m
```

--------------------------------

### Milvus Operator YAML for External etcd Configuration

Source: https://github.com/zilliztech/milvus-operator/blob/main/docs/administration/manage-dependencies/meta-storage.md

This YAML snippet illustrates how to configure Milvus to use an existing external etcd service via the Milvus Operator. It requires setting `external` to `true` under `spec.dependencies.etcd` and providing a list of `endpoints` for the external etcd cluster.

```yaml
apiVersion: milvus.io/v1beta1
kind: Milvus
metadata:
  name: my-release
  labels:
    app: milvus
spec:
  dependencies: # Optional
    etcd:
      external: true
      endpoints:
      # your etcd endpoints
      - 192.168.1.1:2379
```

--------------------------------

### Configure Milvus Operator In-Cluster Kafka Helm Values

Source: https://github.com/zilliztech/milvus-operator/blob/main/docs/CRD/milvus.md

This YAML snippet shows how to customize the in-cluster Kafka deployment using Helm values, specifically for a minimum mode configuration. It sets default replication factors and Zookeeper replica count.

```YAML
spec:
  # ... Skipped fields
  dependencies: # Optional
    kafka: # Optional
      # ... Skipped fields
      inCluster:
        # ... Skipped fields
        values:
          defaultReplicationFactor: 1
          offsetsTopicReplicationFactor: 1
          replicaCount: 1
          zookeeper:
            replicaCount: 1
```

--------------------------------

### Milvus Operator: Configure Storage Dependency

Source: https://github.com/zilliztech/milvus-operator/blob/main/docs/CRD/milvus.md

This YAML snippet outlines the configuration for the storage dependency in Milvus Operator. It supports using an external storage solution (like S3) or deploying an in-cluster MinIO instance. Key fields include `external`, `type` (MinIO or S3), `secretRef` for credentials, `endpoint` for external storage, and `inCluster` settings for deletion policies.

```yaml
spec:
  # ... Skipped fields
  dependencies: # Optional
    storage: # Optional
      # Whether (=true) to use an existed external storage as specified in the field endpoints or 
      # (=false) create a new storage inside the same kubernetes cluster for milvus.
      external: false # Optional default=false
      type: "MinIO" # Optional ("MinIO", "S3") default:="MinIO"
      # Secret reference of the storage if it has
      secretRef: mySecret # Optional
      # The external storage endpoint if external=true
      endpoint: "storageEndpoint"
      # in-Cluster storage configuration if external=false
      inCluster: 
        # deletionPolicy of storage when the milvus cluster is deleted
        deletionPolicy: Retain # Optional ("Delete", "Retain") default="Retain"
        # When deletionPolicy="Delete" whether the PersistantVolumeClaim shoud be deleted when the storage is deleted
        pvcDeletion: false # Optional default=false
        # ... Skipped fields
    # ... Skipped fields
```

--------------------------------

### Milvus Operator: Configure In-Cluster MinIO Helm Values

Source: https://github.com/zilliztech/milvus-operator/blob/main/docs/CRD/milvus.md

This snippet demonstrates how to provide custom Helm values for the in-cluster MinIO deployment managed by the Milvus Operator. The `inCluster.values` field allows for detailed configuration of the embedded MinIO instance, such as setting the `mode` to `standalone` for a minimal deployment.

```yaml
spec:
  # ... Skipped fields
  dependencies: # Optional
    storage: # Optional
      # ... Skipped fields
      inCluster:
        # ... Skipped fields
        values: # Optional
          mode: standalone
```

--------------------------------

### Configure In-Cluster MinIO for Milvus Operator

Source: https://github.com/zilliztech/milvus-operator/blob/main/docs/administration/manage-dependencies/object-storage.md

This YAML configuration snippet for the Milvus CRD (`spec.dependencies.storage.inCluster`) demonstrates how to configure the in-cluster MinIO instance deployed by Milvus Operator. It sets the MinIO mode to `standalone`, allocates `100Mi` memory, and defines `deletionPolicy` and `pvcDeletion` for data retention.

```yaml
apiVersion: milvus.io/v1beta1
kind: Milvus
metadata:
  name: my-release
  labels:
    app: milvus
spec:
  # Omit other fields ...
  dependencies:
    # Omit other fields ...
    storage:
      inCluster:
        values:
          mode: standalone
          resources:
            requests:
              memory: 100Mi
        deletionPolicy: Delete # Delete | Retain, default: Retain
        pvcDeletion: true # default: false
```