Skip to main content
Kimbernetes implements a GitOps architecture using FluxCD v2.7.5, where the Git repository serves as the single source of truth for the entire Kubernetes cluster configuration. This approach enables declarative, auditable, and automated cluster management.

​
GitOps Principles

Git as Source of Truth

All cluster configuration is stored in Git, providing version control, audit trails, and rollback capabilities

Automated Synchronization

Flux continuously monitors the Git repository and automatically applies changes to the cluster

Declarative Infrastructure

Desired state is declared in manifests, and Flux ensures the cluster matches this state

Self-Healing System

Flux detects configuration drift and automatically reconciles to the desired state

​
Architecture Diagram

​
The Flux Reconciliation Loop

Flux operates through a continuous reconciliation loop that ensures your cluster state matches the Git repository:
1

Watch Git Repository

The source-controller monitors the Git repository at regular intervals (default: 1 minute) for changes
2

Fetch Changes

When changes are detected, Flux fetches the latest commit and creates an artifact containing the repository contents
3

Build Resources

The kustomize-controller processes Kustomization resources, building the final manifests by applying overlays and patches
4

Apply to Cluster

The controllers apply the manifests to the Kubernetes cluster, creating, updating, or deleting resources as needed
5

Monitor Status

Flux continuously monitors the health of deployed resources and reports status through conditions and events
6

Self-Heal

If configuration drift is detected (manual changes to the cluster), Flux automatically reverts to the Git-defined state

​
Key Architectural Components

​
Git Repository as Source

The repository structure separates concerns into distinct layers:
  • cluster/ - Flux bootstrap and cluster-level configuration
  • overlays/base/ - Reusable base configurations for applications and infrastructure
  • overlays/kimawesome/ - Environment-specific configurations and customizations

​
Flux Controllers

FluxCD v2.7.5 runs six specialized controllers in the flux-system namespace:
Manages source artifacts from Git repositories, Helm repositories, and S3 buckets. It watches the Git repository and makes artifacts available to other controllers.
Processes Kustomization resources, applying Kustomize overlays and deploying manifests to the cluster. This is the primary controller for GitOps deployments.
Manages Helm releases, automatically deploying and upgrading Helm charts based on HelmRelease resources.
Handles events and notifications, enabling integration with external systems like Slack, Discord, or webhooks.
Scans container registries for new image versions, enabling automated image updates.
Automatically updates Git repository with new image versions when detected by the image-reflector-controller.

​
Deployment Flow

The typical deployment flow in Kimbernetes follows this pattern:
The GitRepository resource is configured to check for changes every 1 minute, while Kustomizations reconcile every 10 minutes. This balance ensures timely updates without excessive API calls.

​
Environment Organization

Kimbernetes uses a multi-layered overlay structure to organize configurations:
  1. Base Layer - Generic, reusable configurations in overlays/base/
  2. Environment Layer - Environment-specific configurations in overlays/kimawesome/
  3. Category Organization - Further organized by function:
    • loadbalancer/ - MetalLB configuration for bare-metal load balancing
    • infrastructure/ - Core infrastructure services (cert-manager, observability, sealed-secrets)
    • applications/ - Application workloads (DNS, tooling, version management)
    • site/ - Website and knowledge hub deployments

​
Security and Access Control

RBAC Integration

Flux controllers use Kubernetes ServiceAccounts with ClusterAdmin privileges for reconciliation

SSH Authentication

Git repository access uses SSH keys stored in Kubernetes Secrets

Network Policies

NetworkPolicies restrict traffic to and from Flux components

Sealed Secrets

Sensitive data is encrypted using Sealed Secrets before committing to Git

​
Benefits of This Architecture

Declarative Operations: All changes are made through Git commits, providing a clear audit trail and enabling easy rollbacks using standard Git operations.
  • Version Control: Every change is tracked in Git with author, timestamp, and reason
  • Disaster Recovery: The entire cluster can be rebuilt from the Git repository
  • Preview Changes: Pull requests allow reviewing changes before applying to the cluster
  • Automated Deployments: No manual kubectl commands required
  • Consistency: The same process applies to infrastructure and applications
  • Multi-Environment: Easy to manage multiple clusters with overlay-based configuration

​
Next Steps

Repository Structure

Explore the detailed directory layout and organization

Flux Components

Deep dive into each Flux controller and their responsibilities

Kustomize Overlays

Learn how overlays enable environment-specific configurations

Getting Started

Start deploying your first application

Build docs developers (and LLMs) love

Get started for freeTalk to us