Skip to content

Latest commit

 

History

History
47 lines (25 loc) · 3.69 KB

ARCHITECTURE.md

File metadata and controls

47 lines (25 loc) · 3.69 KB
Raw

Flamingo's Architectural Approach: Centralized vs. Decentralized Setups

Introduction

Flamingo, offering the synergy between Flux and Argo CD, provides a powerful platform for automating deployments and managing workloads in Kubernetes clusters using GitOps principles. Although inherently designed to manage single-cluster environments effectively, the architectural flexibility of Flamingo allows it to be adapted to various setups. Here, we explore two architectural setups: a centralized setup where a single Flamingo instance controls the whole cluster, and a decentralized setup where Flamingo is instantiated per namespace.

I. Centralized Setup: A Singular Control Point

A. Overview

In a centralized Flamingo architecture, a singular Flamingo instance is deployed, which takes charge of managing resources, configurations, and workloads across the entire Kubernetes cluster. This approach simplifies overall management but consolidates control and resource allocation to a single point.

B. Key Architectural Components

  • Single Flamingo Instance: One Flamingo instance is deployed cluster-wide, managing resources and configurations across all namespaces and reducing the operational overhead.

  • Centralized Resource Management: Centralized control and management of all applications, policies, and resources across various namespaces within the cluster.

C. Architecture Workflow

  • Deployment: One Flamingo instance is deployed, becoming the pivotal point for managing all deployments and configurations across the cluster.

  • Unified Management: The centralized Flamingo manages all resources, ensuring a unified policy and configuration application while streamlining administration.

  • Scalability and Performance: It’s crucial to monitor the performance and scalability aspects, as the centralized Flamingo instance will bear the load of managing the entire cluster.

II. Decentralized Setup: Implementing Tenant per Namespace

A. Overview

In contrast, the decentralized setup involves deploying individual Flamingo instances within each namespace, ensuring isolated, autonomous, and dedicated management of resources and workflows within its scope. This approach maximizes autonomy and minimizes the risk of operational interference among namespaces.

B. Key Architectural Components

  • Flamingo Namespace Tenants: Each namespace is endowed with its own Flamingo instance, ensuring management is localized and isolated to that specific namespace.

  • Independent Resource Management: Each Flamingo instance manages only the resources within its namespace, ensuring policies and configurations are contained and do not impact other namespaces.

C. Architecture Workflow

  • Individualized Deployment: A Flamingo instance is deployed per namespace, each one autonomously managing its resources and workloads.

  • Isolated Management: Management is entirely localized, ensuring that configurations, policies, and resources are managed in isolation, providing a safeguard against unintentional impact on other namespaces.

  • Autonomy and Security: Autonomous operation bolsters security by isolating potential impact and reducing the attack surface.

Conclusion

Choosing between a centralized and decentralized setup should stem from the specific use-case, organizational structure, security considerations, and management preference. Flamingo's inherent architectural flexibility provides a robust platform to implement either centralized or decentralized setups, each offering its unique advantages and potential challenges. A centralized setup simplifies overall management but consolidates control and resource allocation, while a decentralized setup maximizes autonomy and operational isolation.