Kubernetes comme base de données ? Ce que vous devez savoir sur les CRD

Dans le domaine en développement rapide des technologies cloud natives, Kubernetes est devenu un outil puissant pour l'orchestration d'applications conteneurisées. Mais parmi les développeurs et les informaticiens, « Kubernetes est-il une base de données ? est une question fréquemment posée. Cet article explore cette question et propose une description détaillée des définitions de ressources personnalisées (CRD), mettant en évidence leur utilisation dans l'écosystème Kubernetes. Nous espérons clarifier ces idées et illustrer l'adaptabilité et la puissance de Kubernetes dans la gestion des applications avec état avec des exemples de code approfondis et des applications réelles.

Introduction à Kubernetes

Kubernetes, souvent abrégé en K8s, est une plate-forme open source conçue pour automatiser le déploiement, la mise à l'échelle et le fonctionnement des conteneurs d'applications. Initialement développé par Google, Kubernetes est devenu le standard de facto pour l'orchestration de conteneurs, soutenu par une communauté dynamique et une large gamme d'outils et d'extensions.

Concepts de base de Kubernetes

Avant de plonger dans les spécificités des CRD et la question de Kubernetes en tant que base de données, il est essentiel de comprendre quelques concepts fondamentaux :

Pods : les plus petites unités déployables dans Kubernetes, représentant une instance unique d'un processus en cours d'exécution dans un cluster.

Nœuds : les machines de travail dans Kubernetes, qui peuvent être virtuelles ou physiques.

Cluster : un ensemble de nœuds contrôlés par le maître Kubernetes.

Services : une abstraction qui définit un ensemble logique de pods et une politique permettant d'y accéder.

Kubernetes comme base de données : mythe ou réalité ?

Kubernetes lui-même n'est pas une base de données. Il s'agit d'une plateforme d'orchestration capable de gérer des applications conteneurisées, notamment des bases de données. Cependant, la confusion surgit souvent car Kubernetes peut être utilisé pour déployer et gérer efficacement des applications de base de données.

Comprendre les définitions de ressources personnalisées (CRD)

Les définitions de ressources personnalisées (CRD) étendent l'API Kubernetes pour permettre aux utilisateurs de gérer leurs propres ressources personnalisées spécifiques à l'application. Cette fonctionnalité rend Kubernetes hautement extensible et personnalisable pour s'adapter à divers cas d'utilisation.

Que sont les CRD ?

Les CRD permettent aux utilisateurs de définir des objets personnalisés qui se comportent comme des ressources Kubernetes intégrées. Par exemple, bien que Kubernetes dispose de ressources intégrées telles que des pods, des services et des déploiements, vous pouvez créer des ressources personnalisées telles que « MySQLluster » ou « PostgreSQLBackup ».

Créer un CRD

Pour créer un CRD, vous devez le définir dans un fichier YAML et l'appliquer à votre cluster Kubernetes. Voici un exemple simple :

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

L'application de ce fichier YAML avec kubectl apply -f myresource-crd.yaml créera la définition de ressource personnalisée dans votre cluster.

Gestion des ressources personnalisées

Une fois le CRD créé, vous pouvez commencer à gérer des ressources personnalisées comme vous le feriez avec des ressources Kubernetes natives. Voici un exemple d'instance de ressource personnalisée :

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

Vous pouvez créer cette ressource personnalisée avec :

kubectl apply -f myresource-instance.yaml

Utilisation des CRD pour les applications avec état

Les définitions de ressources personnalisées sont particulièrement utiles pour gérer les applications avec état, y compris les bases de données. Ils vous permettent de définir l'état souhaité d'un cluster de bases de données, les politiques de sauvegarde et d'autres comportements personnalisés.

Exemple : Gestion d'un cluster MySQL avec des CRD

Envisagez un scénario dans lequel vous devez gérer un cluster MySQL avec Kubernetes. Vous pouvez définir une ressource personnalisée pour représenter la configuration du cluster MySQL :

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

Avec ce CRD, vous pouvez créer, mettre à jour et supprimer des clusters MySQL à l'aide de commandes Kubernetes standard, rendant la gestion de base de données plus simple et intégrée au reste de votre infrastructure.

Fonctionnalités CRD avancées

Les CRD offrent plusieurs fonctionnalités avancées qui améliorent leur fonctionnalité et leur intégration avec l'écosystème Kubernetes.

Schémas de validation

Vous pouvez définir des schémas de validation pour les ressources personnalisées afin de garantir que seules les configurations valides sont acceptées. Voici un exemple d'ajout d'un schéma de validation au 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

Contrôleurs personnalisés

Pour automatiser la gestion des ressources personnalisées, vous pouvez écrire des contrôleurs personnalisés. Ces contrôleurs surveillent les modifications apportées aux ressources personnalisées et prennent des mesures pour réconcilier l'état réel avec l'état souhaité.

Voici un aperçu de la façon dont vous pourriez écrire un contrôleur pour la ressource MySQLCluster :

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)
    }
}

Gestion des versions

Les CRD prennent en charge le contrôle de version, vous permettant de gérer différentes versions de vos ressources personnalisées et de migrer facilement entre elles. Ceci est crucial pour maintenir la compatibilité ascendante et faire évoluer vos API au fil du temps.

Étude de cas : opérateurs Kubernetes pour les bases de données

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.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!