Kubernetes als Datenbank? Was Sie über CRDs wissen müssen

Im sich schnell entwickelnden Bereich der Cloud-nativen Technologien hat sich Kubernetes zu einem leistungsstarken Werkzeug für die Orchestrierung von Containeranwendungen entwickelt. Aber unter Entwicklern und IT-Spezialisten: „Ist Kubernetes eine Datenbank?“ ist eine häufig gestellte Frage. Dieser Beitrag geht dieser Frage nach und bietet eine ausführliche Beschreibung von Custom Resource Definitions (CRDs) sowie deren Verwendung im Kubernetes-Ökosystem. Wir hoffen, diese Ideen klar zu machen und die Anpassungsfähigkeit und Leistungsfähigkeit von Kubernetes im Stateful Application Management anhand ausführlicher Codebeispiele und realer Anwendungen zu veranschaulichen.

Einführung in Kubernetes

Kubernetes, oft als K8s abgekürzt, ist eine Open-Source-Plattform zur Automatisierung der Bereitstellung, Skalierung und des Betriebs von Anwendungscontainern. Kubernetes wurde ursprünglich von Google entwickelt und hat sich zum De-facto-Standard für die Container-Orchestrierung entwickelt, der von einer lebendigen Community und einer breiten Palette an Tools und Erweiterungen unterstützt wird.

Kernkonzepte von Kubernetes

Bevor wir uns mit den Besonderheiten von CRDs und der Frage nach Kubernetes als Datenbank befassen, ist es wichtig, einige Kernkonzepte zu verstehen:

Pods: Die kleinsten bereitstellbaren Einheiten in Kubernetes, die eine einzelne Instanz eines laufenden Prozesses in einem Cluster darstellen.

Knoten: Die Arbeitsmaschinen in Kubernetes, die entweder virtuell oder physisch sein können.

Cluster: Eine Reihe von Knoten, die vom Kubernetes-Master gesteuert werden.

Dienste: Eine Abstraktion, die einen logischen Satz von Pods und eine Richtlinie für den Zugriff darauf definiert.

Kubernetes als Datenbank: Mythos oder Realität?

Kubernetes selbst ist keine Datenbank. Es handelt sich um eine Orchestrierungsplattform, die containerisierte Anwendungen, einschließlich Datenbanken, verwalten kann. Allerdings kommt es oft zu Verwirrung, weil Kubernetes zur effektiven Bereitstellung und Verwaltung von Datenbankanwendungen verwendet werden kann.

Benutzerdefinierte Ressourcendefinitionen (CRDs) verstehen

Custom Resource Definitions (CRDs) erweitern die Kubernetes-API, um Benutzern die Verwaltung ihrer eigenen anwendungsspezifischen benutzerdefinierten Ressourcen zu ermöglichen. Diese Fähigkeit macht Kubernetes in hohem Maße erweiterbar und anpassbar, um es an verschiedene Anwendungsfälle anzupassen.

Was sind CRDs?

CRDs ermöglichen es Benutzern, benutzerdefinierte Objekte zu definieren, die sich wie integrierte Kubernetes-Ressourcen verhalten. Während Kubernetes beispielsweise über integrierte Ressourcen wie Pods, Dienste und Bereitstellungen verfügt, können Sie benutzerdefinierte Ressourcen wie „MySQLCluster“ oder „PostgreSQLBackup“ erstellen.

Erstellen eines CRD

Um ein CRD zu erstellen, müssen Sie es in einer YAML-Datei definieren und auf Ihren Kubernetes-Cluster anwenden. Hier ist ein einfaches Beispiel:

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: myresources.example.com
spec:
  group: example.com
  versions:
    - name: v1
      served: true
      storage: true
  scope: Namespaced
  names:
    plural: myresources
    singular: myresource
    kind: MyResource
    shortNames:
      - mr

Durch Anwenden dieser YAML-Datei mit kubectl apply -f myresource-crd.yaml wird die benutzerdefinierte Ressourcendefinition in Ihrem Cluster erstellt.

Benutzerdefinierte Ressourcen verwalten

Sobald das CRD erstellt ist, können Sie mit der Verwaltung benutzerdefinierter Ressourcen beginnen, wie Sie es mit nativen Kubernetes-Ressourcen tun würden. Hier ist ein Beispiel einer benutzerdefinierten Ressourceninstanz:

apiVersion: example.com/v1
kind: MyResource
metadata:
  name: myresource-sample
spec:
  foo: bar
  count: 10

Sie können diese benutzerdefinierte Ressource erstellen mit:

kubectl apply -f myresource-instance.yaml

CRDs für zustandsbehaftete Anwendungen verwenden

Benutzerdefinierte Ressourcendefinitionen sind besonders nützlich für die Verwaltung zustandsbehafteter Anwendungen, einschließlich Datenbanken. Sie ermöglichen Ihnen, den gewünschten Status eines Datenbankclusters, Sicherungsrichtlinien und andere benutzerdefinierte Verhaltensweisen zu definieren.

Beispiel: Verwalten eines MySQL-Clusters mit CRDs

Stellen Sie sich ein Szenario vor, in dem Sie einen MySQL-Cluster mit Kubernetes verwalten müssen. Sie können eine benutzerdefinierte Ressource definieren, um die MySQL-Clusterkonfiguration darzustellen:

apiVersion: example.com/v1
kind: MySQLCluster
metadata:
  name: my-mysql-cluster
spec:
  replicas: 3
  version: "5.7"
  storage:
    size: 100Gi
    class: standard

Mit diesem CRD können Sie MySQL-Cluster mit Standard-Kubernetes-Befehlen erstellen, aktualisieren und löschen, wodurch die Datenbankverwaltung einfacher und in den Rest Ihrer Infrastruktur integriert wird.

Erweiterte CRD-Funktionen

CRDs bieten mehrere erweiterte Funktionen, die ihre Funktionalität und Integration in das Kubernetes-Ökosystem verbessern.

Validierungsschemata

Sie können Validierungsschemata für benutzerdefinierte Ressourcen definieren, um sicherzustellen, dass nur gültige Konfigurationen akzeptiert werden. Hier ist ein Beispiel für das Hinzufügen eines Validierungsschemas zum MySQLCluster CRD:

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: mysqlclusters.example.com
spec:
  group: example.com
  versions:
    - name: v1
      served: true
      storage: true
      schema:
        openAPIV3Schema:
          type: object
          properties:
            spec:
              type: object
              properties:
                replicas:
                  type: integer
                  minimum: 1
                version:
                  type: string
                storage:
                  type: object
                  properties:
                    size:
                      type: string
                    class:
                      type: string
  scope: Namespaced
  names:
    plural: mysqlclusters
    singular: mysqlcluster
    kind: MySQLCluster
    shortNames:
      - mc

Benutzerdefinierte Controller

Um die Verwaltung benutzerdefinierter Ressourcen zu automatisieren, können Sie benutzerdefinierte Controller schreiben. Diese Controller achten auf Änderungen an benutzerdefinierten Ressourcen und ergreifen Maßnahmen, um den tatsächlichen Zustand mit dem gewünschten Zustand abzugleichen.

Hier ist eine Übersicht, wie Sie einen Controller für die MySQLCluster-Ressource schreiben könnten:

package main

import (
    "context"
    "log"

    mysqlv1 "example.com/mysql-operator/api/v1"
    "k8s.io/apimachinery/pkg/runtime"
    "k8s.io/client-go/kubernetes/scheme"
    ctrl "sigs.k8s.io/controller-runtime"
    "sigs.k8s.io/controller-runtime/pkg/client"
    "sigs.k8s.io/controller-runtime/pkg/manager"
)

type MySQLClusterReconciler struct {
    client.Client
    Scheme *runtime.Scheme
}

func (r *MySQLClusterReconciler) Reconcile(ctx context.Context, req ctrl.Request) (ctrl.Result, error) {
    var mysqlCluster mysqlv1.MySQLCluster
    if err := r.Get(ctx, req.NamespacedName, &mysqlCluster); err != nil {
        return ctrl.Result{}, client.IgnoreNotFound(err)
    }

    // Reconciliation logic goes here

    return ctrl.Result{}, nil
}

func main() {
    mgr, err := ctrl.NewManager(ctrl.GetConfigOrDie(), ctrl.Options{
        Scheme: scheme.Scheme,
    })
    if err != nil {
        log.Fatalf("unable to start manager: %v", err)
    }

    if err := (&MySQLClusterReconciler{
        Client: mgr.GetClient(),
        Scheme: mgr.GetScheme(),
    }).SetupWithManager(mgr); err != nil {
        log.Fatalf("unable to create controller: %v", err)
    }

    if err := mgr.Start(ctrl.SetupSignalHandler()); err != nil {
        log.Fatalf("unable to run manager: %v", err)
    }
}

Versionierung

CRDs unterstützen die Versionierung, sodass Sie verschiedene Versionen Ihrer benutzerdefinierten Ressourcen verwalten und reibungslos zwischen ihnen migrieren können. Dies ist entscheidend für die Aufrechterhaltung der Abwärtskompatibilität und die Weiterentwicklung Ihrer APIs im Laufe der Zeit.

Fallstudie: Kubernetes-Operatoren für Datenbanken

Kubernetes Operators leverage CRDs and custom controllers to automate the management of complex stateful applications like databases. Let's explore a real-world example: the MySQL Operator.

The MySQL Operator

The MySQL Operator simplifies the deployment and management of MySQL clusters on Kubernetes. It uses CRDs to define the desired state of the MySQL cluster and custom controllers to handle tasks like provisioning, scaling, and backups.

Defining the MySQLCluster CRD

The MySQL Operator starts by defining a CRD for the MySQLCluster resource, as shown earlier. This CRD includes fields for specifying the number of replicas, MySQL version, storage requirements, and more.

Writing the MySQLCluster Controller

The controller for the MySQLCluster resource continuously watches for changes to MySQLCluster objects and reconciles the actual state with the desired state. For example, if the number of replicas is increased, the controller will create new MySQL instances and configure them to join the cluster.

Code Example: Scaling a MySQL Cluster

Here’s a simplified version of the controller logic for scaling a MySQL cluster:

func (r *MySQLClusterReconciler) Reconcile(ctx context.Context, req ctrl.Request) (ctrl.Result, error) {
    var mysqlCluster mysqlv1.MySQLCluster
    if err := r.Get(ctx, req.NamespacedName, &mysqlCluster); err != nil {
        return ctrl.Result{}, client.IgnoreNotFound(err)
    }

    // Fetch the current number of MySQL pods
    var pods corev1.PodList
    if err := r.List(ctx, &pods, client.InNamespace(req.Namespace), client.MatchingLabels{
        "app":  "mysql",
        "role": "master",
    }); err != nil {
        return ctrl.Result{}, err
    }

    currentReplicas := len(pods.Items)
    desiredReplicas := mysqlCluster.Spec.Replicas

    if currentReplicas < desiredReplicas {
        // Scale up
        for i := currentReplicas; i < desiredReplicas; i++ {
            newPod := corev1.Pod{
                ObjectMeta: metav1.ObjectMeta{
                    Name:      fmt.Sprintf("mysql-%d", i),
                    Namespace: req.Namespace,
                    Labels: map[string

]string{
                        "app":  "mysql",
                        "role": "master",
                    },
                },
                Spec: corev1.PodSpec{
                    Containers: []corev1.Container{
                        {
                            Name:  "mysql",
                            Image: "mysql:5.7",
                            Ports: []corev1.ContainerPort{
                                {
                                    ContainerPort: 3306,
                                },
                            },
                        },
                    },
                },
            }
            if err := r.Create(ctx, &newPod); err != nil {
                return ctrl.Result{}, err
            }
        }
    } else if currentReplicas > desiredReplicas {
        // Scale down
        for i := desiredReplicas; i < currentReplicas; i++ {
            podName := fmt.Sprintf("mysql-%d", i)
            pod := &corev1.Pod{
                ObjectMeta: metav1.ObjectMeta{
                    Name:      podName,
                    Namespace: req.Namespace,
                },
            }
            if err := r.Delete(ctx, pod); err != nil {
                return ctrl.Result{}, err
            }
        }
    }

    return ctrl.Result{}, nil
}

Benefits of Using Kubernetes Operators

Kubernetes Operators, built on CRDs and custom controllers, provide several benefits for managing stateful applications:

Automation: Operators automate routine tasks such as scaling, backups, and failover, reducing the operational burden on administrators.

Consistency: By encapsulating best practices and operational knowledge, Operators ensure that applications are managed consistently and reliably.

Extensibility: Operators can be extended to support custom requirements and integrate with other tools and systems.

Conclusion

Although Kubernetes is not a database in and of itself, it offers a strong framework for installing and administering database applications. A strong addition to the Kubernetes API, bespoke Resource Definitions (CRDs) allow users to design and manage bespoke resources that are suited to their particular requirements.

You may build Kubernetes Operators that automate the administration of intricate stateful applications, such as databases, by utilizing CRDs and custom controllers. This method offers more flexibility and customization, improves consistency, and streamlines processes.

This article has covered the foundations of CRDs, shown comprehensive code examples, and shown how stateful applications may be efficiently managed with CRDs. To fully utilize Kubernetes, you must comprehend and make use of CRDs, regardless of whether you are implementing databases or other sophisticated services on this potent orchestration platform.

As Kubernetes develops further, its adaptability to a variety of use cases and needs is ensured by its expansion through CRDs and Operators. Keep investigating and experimenting with these functionalities as you progress with Kubernetes to open up new avenues for your infrastructure and apps.

Das obige ist der detaillierte Inhalt vonKubernetes als Datenbank? Was Sie über CRDs wissen müssen. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!