Εφαρμογή του μοτίβου Singleton για τη διαχείριση της παγκόσμιας διαμόρφωσης στους Operators Kubernetes

package config

import (
 "os"
 "sync"
)

// Config holds all operator configuration.
type Config struct {
 LogLevel string
 DatabaseURL string
 // ... other fields
}

var (
 instance *Config
 once sync.Once
)

// GetConfig returns the singleton Config, initializing it on the first call.
func GetConfig() *Config {
 once.Do(func() {
 instance = &Config{
 LogLevel: getEnv("LOG_LEVEL", "info"),
 DatabaseURL: getEnv("DATABASE_URL", "localhost:5432"),
 }
 // Optionally validate or parse from a file / ConfigMap.
 })
 return instance
}

func getEnv(key, fallback string) string {
 if value, ok := os.LookupEnv(key); ok {
 return value
 }
 return fallback
}

Γιατί είναι Προτιμήσιμο

Χρησιμοποιώντας εγγυάται ότι η λειτουργία αρχικοποίησης τρέχει ακριβώς μία φορά, ακόμη και υπό βαριά σύμπτωση. Η μέθοδος μπλοκάρει όλους τους καλούντες μέχρι να ολοκληρωθεί η λειτουργία, εξασφαλίζοντας ότι το singleton είναι πλήρως κατασκευασμένο πριν από οποιαδήποτε γορουτίνη μπορεί να το διαβάσει.

Δοκιμή του Singleton

Στις δοκιμές μονάδων χειριστή, συχνά θέλετε να προμηθεύσετε μια εικονική διαμόρφωση. Μια απλή εργασία είναι να εκθέσετε ένα [[LFT:0]] δοκιμαστικό γάντζο[[LFT:1]] που επαναφέρει την περίπτωση:

// ResetForTest clears the singleton – only for use in test files.
func ResetForTest() {
 once = sync.Once{}
 instance = nil
}

Στη συνέχεια, στις δοκιμές μπορείτε να καλέσετε , ρυθμίστε τις μεταβλητές περιβάλλοντος, και καλέστε [[LFT:7]] και πάλι για να πάρετε μια νέα περίπτωση. Αυτό το μοτίβο χρησιμοποιείται από επιφανή έργα όπως [[LFT:0]]cert-manager[[[LFT:1]] και [[LFT:2]] Prometheus Operator[[LFT:3]]].

Εναλλακτικές προσεγγίσεις: ConfigMaps και Μεταβλητές Περιβάλλοντος

Πριν από την υιοθέτηση ενός Singleton, αξίζει να κατανοήσουμε τις εναλλακτικές λύσεις που διατίθενται στο οικοσύστημα Kubernetes:

1. Μεταβλητές περιβάλλοντος

Η λίστα με τις εγγραφές [[LFT:8]] και ο αερομεταφορέας τις διαβάζει μέσω [[LPT:9]]. Δεν χρειάζεται ένα μονότονο εάν κάθε συστατικό διαβάζει αυτό που χρειάζεται ανεξάρτητα. Ωστόσο, αυτό γίνεται προβληματικό όταν:

• Πολλαπλά εξαρτήματα χρειάζονται την ίδια τιμή ⁇ επαναλαμβάνετε παντού.
• Θέλετε να αλλάξετε την πηγή (π.χ., από env σε ένα αρχείο) ⁇ πρέπει να ενημερώσετε κάθε τοποθεσία κλήσης.

2. Kubernetes ConfigMaps

Οι φορείς εκμετάλλευσης παρακολουθούν συχνά ένα ConfigMap για να επιτρέψουν [[LFT:0]] ζωντανές ενημερώσεις ρυθμίσεων[[LFT:1]]. Ένα singleton που κατέχει την τελευταία ρύθμιση και την ενημερώνει μέσω ενός ⁇ ολογιού είναι μια φυσική εφαρμογή. Για παράδειγμα:

func WatchConfigMap(ctx context.Context, client kubernetes.Interface, namespace, name string) {
 watcher, _ := client.CoreV1().ConfigMaps(namespace).Watch(ctx, metav1.ListOptions{FieldSelector: "metadata.name=" + name})
 for event := range watcher.ResultChan() {
 cm := event.Object.(*v1.ConfigMap)
 updateFromConfigMap(cm)
 }
}

func updateFromConfigMap(cm *v1.ConfigMap) {
 // Write to a global singleton.
 configSingleton.Update(cm.Data)
}

Το μοτίβο singleton συμπληρώνει το ConfigMaps: το ρολόι ρουτίνα ενημερώνει το ενιαίο παράδειγμα, και όλες τις άλλες goroutines απλά διαβάζονται από αυτό.

3. Ένεση εξάρτησης

Η πιο ευέλικτη εναλλακτική λύση είναι να περάσει τη διαμόρφωση ρητά σε κάθε ελεγκτή ή δομή. Αυτό βελτιώνει τη δυνατότητα ελέγχου και καθιστά τις εξαρτήσεις σαφείς. Ωστόσο, σε ένα μεγάλο χειριστή με πολλούς ελεγκτές, καλωδίωση όλες τις εξαρτήσεις μπορεί να γίνει ⁇ ήμα.

Συγκρίνοντας το Singleton με την ένεση εξάρτησης

Για πολλούς φορείς εκμετάλλευσης, το μοτίβο Singleton είναι η προεπιλογή προεπιλογής [[LFT:1]] επειδή απλοποιεί τη βάση κώδικα χωρίς να θυσιάζει αξιοπιστία. Ομάδες που δίνουν προτεραιότητα στην καθαρότητα δοκιμής μπορεί να προτιμούν το DI, αλλά τα γενικά έξοδα συχνά δεν δικαιολογούνται για τους μικροχειριστές-σε-μεσαίου.