SIGHUP Distribution

SIGHUP Distribution (SD) is a certified battle-tested Kubernetes distribution based purely on upstream Kubernetes.

Overview

SIGHUP Distribution (SD) is a CNCF certified battle-tested Kubernetes distribution based purely on upstream Kubernetes.

It is developed and maintained by SIGHUP by ReeVo and the community, and it is fully open source.

🎯 The goal of SD is to turn any standard Kubernetes cluster into a fully-configured production-grade cluster.

Previously known as KFD (Kubernetes Fury Distribution), the project is now officially named SIGHUP Distribution. ReeVo has acquired SIGHUP, but the project will continue to be open-source and freely available without any changes to its functionality.

Un-distribution model 🧬

SD uses an un-distribution model. This means that we:

• Rely only on open source solutions.
• Are free from vendor lock-in.
• Stay close to upstream Kubernetes and the cloud native landscape.
• Choose, configure and integrate a set of battle-tested open source tools.

Architecture 🏗

SIGHUP Distribution is structured on modules, and each module has a set of packages.

• A package is a single unit of functionality.
• A module groups packages that are functionally related together.

All modules are open source, widely used, easily customizable, and pre-configured with sane defaults and tested to work well together.

The standard way to deploy SD is to:

• Deploy all the Core Modules of the distribution using furyctl.
• Deploy (if needed) any of the Addon modules using furyctl plugin feature.

See the getting started section below for more information.

Recommended Hardware Requirements

SD is a modular and composable system, so hardware requirements ultimately depend on the modules and configuration chosen. Having said that, for a production-grade cluster a good starting point would be:

A SD production grade cluster will be composed of 3 node pools:

• Control Plane: 3 nodes in HA.
• Infrastructure: 3 nodes dedicated to running the infrastructural components of SD (monitoring, logging, policy enforcement, etc., i.e. the modules).
• Workers: where the application workload will run. This is up to you.
• Load Balancers (optional): for on-premises installations, 2 load balancers in HA can be deployed to forward traffic to the control plane and the ingress controllers running in the infrastructure nodes.

Nodes sizing

Node Role	CPU (cores)	RAM (GB)	Disk (GB)	Qty.
Control Plane	2	8	50	3
Infrastructure	4	16	50	3
Load Balancer	2	2	50	2

Storage

Some modules rely on persistent storage via PersistentVolumeClaims, by default (but configurable) the following capacity will be used:

Description	Size (GB)
Prometheus (metrics storage)	150
MinIO Monitoring (metrics storage, 20GBx6)	120
MinIO Logging (logs storage, 20GBx6)	120
OpenSearch (logs storage)	30
MinIO Tracing (traces storage)	120
Total	540

Core Modules 📦

Core modules provide essential functionality to the distribution for production-grade clusters.

Module	Included Release	Description
Networking		Networking functionality via Calico or Cilium CNIs
Ingress		Fast and reliable Ingress Controller and TLS certificate management
Logging		A centralized logging solution based on the LoggingOperator + OpenSearch or Loki stacks
Monitoring		Monitoring and alerting functionality based on Prometheus, AlertManager and Grafana
Tracing		Tracing functionality based on Tempo
Disaster Recovery		Backup and disaster recovery solution using Velero
Policy		Policy and Governance for your cluster using Gatekeeper and Gatekeeper Policy Manager or Kyverno
Auth		Improved auth for your Kubernetes Cluster and its applications

Add-on Modules 📦

Add-on modules provide additional functionality to the distribution. Their release cycle is independent of SD's.

Module	Description
Kong	Add Kong API Gateway for Kubernetes applications via Kong Ingress Controller
Service Mesh	Deploy a service mesh on top of SD
Registry	Integrate a Container Registry solution
Storage	Rook (Ceph Operator) based Storage solution on Kubernetes
Kafka	Apache Kafka event streaming for your Cluster

Get started with SD 🚀

To get started with SD, please head to the quickstart guides on the documentation site.

Issues 🐛

In case you experience any issues, feel free to open a new issue.

If the problem is related to a specific module, open the issue in the module repository.

Commercial Support 🛟

If you are looking to run SD in production and would like to learn more, SIGHUP (the company behind the Fury ecosystem) can help. Feel free to email us or check out our website.

Support & Compatibility 🪢

Current supported versions of SD are:

SD Version	Kubernetes Version
1.35.0	1.35.x
1.34.2	1.34.x
1.33.3	1.33.x

Check the compatibility matrix for additional information about previous releases of the Distribution and the compatibility with furyctl.

Also, check the versioning documentation file to know more about the versioning scheme of the distribution and the upgrade path.

CNCF Certified 🎓

Each version of the SIGHUP Distribution that introduces compatibility with a new version of Kubernetes goes through a conformance certification process with the CNCF. Certified solutions are validated to ensure a set of guarantees such as consistency, timely updates and confirmability.

SD has been certified by the CNCF (Cloud Native Computing Foundation) as a Certified Kubernetes Distribution for all Kubernetes versions since Kubernetes 1.12. Clicking on the badge below you can see the certification process for the latest version of SD:

Roadmap

Find the updated roadmap in the ROADMAP.md file.

Contributing 🤝

If you wish to contribute, please read the Contributing Guidelines.

License

SD is open-source software, and it's released under the following LICENSE