Kubernetes Operators

Resources Folder

1. MongoDB CRD Sample:

apiVersion: mongodbcommunity.mongodb.com/v1
kind: MongoDBCommunity
metadata:
  name: example-mongodb
spec:
  members: 3
  type: ReplicaSet
  version: "6.0.5"
  security:
    authentication:
      modes: ["SCRAM"]
  users:
    - name: my-user
      db: admin
      passwordSecretRef:
        name: my-user-password
      roles:
        - name: clusterAdmin
          db: admin
        - name: userAdminAnyDatabase
          db: admin
      scramCredentialsSecretName: my-scram

  statefulSet:
    spec:
        # Name for the service object created by the operator
      serviceName: example-openshift-mongodb-svc
      selector: {}
        # Specifies a size for the data volume different from the default 10Gi
      volumeClaimTemplates:
        - metadata:
            name: data-volume
          spec:
            accessModes: [ "ReadWriteOnce", "ReadWriteMany" ]
            resources:
              requests:
                storage: 50Gi

      template:
        # Adds a custom volume to the pods
        spec:
          volumes:
            - name: custom-volume
              emptyDir: {}
          containers:
          - name: mongodb-agent
            volumeMounts:
              - name: custom-volume
                mountPath: /my-custom-version/mount-path

2. Agent Image Version: 12.0.32.7857-1

Key Takeaways

Kubernetes Operators extend the functionality of Kubernetes to manage complex applications by allowing you to define and use custom resources that aren't native to Kubernetes.

Core Concepts

1. Custom Resources:
   • Operators introduce new, application-specific resources that extend the Kubernetes API
   • These resources aren't natively understood by Kubernetes
2. Custom Controllers:
   • Operators implement custom controllers designed to watch for these custom resources
   • Controllers create and manage standard Kubernetes resources based on the custom resource specifications

How Operators Work

1. When you create a custom resource (e.g., a PostgreSQL cluster), the operator's custom controller detects this.
2. The controller then creates the necessary Kubernetes native resources (Pods, Services, ConfigMaps, etc.) to fulfill the desired state specified in your custom resource.
3. The controller continuously monitors these resources, making adjustments as needed to maintain the desired state.

Common Operators and Use Cases

Many popular software systems have dedicated operators, including:

• Databases: PostgreSQL, MongoDB, MySQL, Elasticsearch
• Message Queues: Apache Kafka, RabbitMQ
• Monitoring: Prometheus
• Service Meshes: Istio

Using an Operator: Step-by-Step

• Install the Operator: Typically through Helm.
• Create an Instance of the Custom Resource: This custom resource isn't native to Kubernetes but is understood by the operator.

apiVersion: database.example.com/v1
kind: PostgresCluster
metadata:
  name: my-db
spec:
  version: "13"
  instances: 3
  storage:
    size: 1Gi

• Apply the Custom Resource: The operator's controller will detect this and create necessary Kubernetes resources.

kubectl apply -f postgres-cluster.yaml

• Monitor the Deployment: You can monitor both custom and native resources.

kubectl get postgresclusters
kubectl get pods

Best Practices

1. Understand Custom Resources: Familiarize yourself with the specific CRDs introduced by each operator
2. Monitor Operator Logs: Keep an eye on the operator's logs for insights into its actions
3. Stay Updated: Regularly update operators to benefit from new features and improved controllers

By leveraging Kubernetes Operators, you can work with custom resources that abstract complex applications, letting you manage them just like you would any other Kubernetes resource.