Getting started on MOCO, the MySQL Operator for Kubernetes Part 1

MOCO (MySQL Operator for Kubernetes) is a powerful, cloud-native tool designed for streamlined MySQL cluster management within Kubernetes. It automates key tasks like provisioning, scaling, backups, and maintenance, ensuring high availability and dependability. MOCO leverages Kubernetes resources to efficiently create, monitor, and manage your MySQL deployments.

MOCO supports specific MySQL and Kubernetes versions. Currently, it's compatible with MySQL 8.0.28, 8.0.37, 8.0.39, 8.0.40, and 8.4.3, and Kubernetes 1.29, 1.30, and 1.31.

How MOCO Functions

Cluster Provisioning

MOCO provisions MySQL clusters using Kubernetes StatefulSets. This involves:

1. Defining a MySQLCluster custom resource (CR) specifying desired configurations.
2. The MOCO controller creating StatefulSets and persistent volume claims (PVCs) for cluster nodes.
3. Configuring MySQL instances with semi-synchronous replication for high availability.

Deployment Services

MOCO deploys the following services:

• Primary Service: Directs traffic to the primary node.
• Replica Service: Routes read queries to replica nodes.
• Backup Service: Manages backups via sidecars integrated into the StatefulSet.

Deployment Types

• Single Primary with Replicas: The default; one primary and multiple replicas.
• Multi-Region Clusters: For geographically distributed replication.

Backup and Restore

MOCO facilitates regular full and incremental backups stored in Amazon S3-compatible object storage. Features include:

• Scheduled backups to object storage.
• On-demand backups via the Kubernetes API.
• Simple CR updates for restorations.
• Point-in-Time Recovery (PITR) for robust disaster recovery.

Object Storage Bucket

The bucket is the S3 management unit for objects. MOCO stores backups within a designated bucket. Note that MOCO doesn't automatically remove old backups; you'll need to configure bucket lifecycle management for this.

Further details are available in the provided link.

Handling Problematic Pods

MOCO automatically detects and isolates MySQL nodes with inconsistent data (errant pods), preventing replication issues. Manual removal is also possible if required.

Replication Management

MOCO utilizes semi-synchronous replication for data consistency, ensuring the primary node writes changes to replicas before committing transactions. Failovers are automated by promoting a replica to primary, minimizing disruption. MOCO also monitors replication lag to maintain synchronization and performance.

Stateful vs. Stateless

MOCO deployments are inherently stateful due to MySQL's persistent storage requirements. Kubernetes StatefulSets ensure:

• Persistent storage via PVCs.
• Stable network identities for MySQL nodes.
• Ordered scaling and rolling updates.

Quick Start

Two installation methods are available:

Using Raw Manifests:

<code class="language-bash">curl -fsLO https://github.com/cybozu-go/moco/releases/latest/download/moco.yaml
kubectl apply -f moco.yaml</code>

Using Helm Chart:

<code class="language-bash">helm repo add moco https://cybozu-go.github.io/moco/
helm repo update
helm install --create-namespace --namespace moco-system moco moco/moco</code>

Manifest customization is supported via the config/ directory (kustomize).

Cluster Creation

A new cluster designates one writable instance as the primary; all others are read-only replicas. The following YAML creates a three-node cluster with pod anti-affinity and resource limits:

<code class="language-yaml">apiVersion: moco.cybozu.com/v1beta2
kind: MySQLCluster
metadata:
  namespace: default
  name: test
spec:
  replicas: 3
  podTemplate:
    spec:
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app.kubernetes.io/name
                operator: In
                values:
                - mysql
              - key: app.kubernetes.io/instance
                operator: In
                values:
                - test
            topologyKey: "kubernetes.io/hostname"
      containers:
      - name: mysqld
        image: ghcr.io/cybozu-go/moco/mysql:8.4.3
        resources:
          limits:
            cpu: "10"
            memory: "10Gi"
  volumeClaimTemplates:
  - metadata:
      name: mysql-data
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 1Gi</code>

Additional example manifests are located in the examples directory.

Cluster Usage

The kubectl moco plugin (available on GitHub releases) provides external access to MOCO MySQL instances. Services (moco-test-primary.foo.svc and moco-test-replica.foo.svc for a test cluster in the foo namespace) allow network access.

Cluster Status Monitoring

Use kubectl get mysqlcluster and kubectl describe mysqlcluster to monitor cluster health, availability, and recent events.

Log Access

Access mysqld error and slow query logs using kubectl logs.

Switchover and Failover

MOCO handles automatic switchover and failover to ensure high availability. Manual switchover is possible via kubectl moco switchover CLUSTER_NAME.

Recovering Errant Replicas

Remove the PVC and Pod of an errant replica using kubectl delete.

Reference: https://www.php.cn/link/2bbc1cc8fd0e5f9e0b91f01828c87814

The above is the detailed content of Getting started on MOCO, the MySQL Operator for Kubernetes Part 1. For more information, please follow other related articles on the PHP Chinese website!