SIGHUP Distribution (SD) is a certified battle-tested Kubernetes distribution based purely on upstream Kubernetes.
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.
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.
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.
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.
| 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 |
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 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 |
| OPA |  |
Policy and Governance for your cluster using OPA Gatekeeper and Gatekeeper Policy Manager or Kyverno |
| Auth |  |
Improved auth for your Kubernetes Cluster and its applications |
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 |
To get started with SD, please head to the quickstart guides on the documentation site.
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.
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.
Current supported versions of SD are:
| SD Version | Kubernetes Version |
|---|---|
1.31.0 |
1.31.x |
1.30.1 |
1.30.x |
1.29.6 |
1.29.x |
1.28.6 |
1.28.x |
Note
Usually, SD supports 3 versions simultaneously that are compatible with 3 different underlying Kubernetes versions. With SD v1.31.0 the support for SD v1.28.x will be extended for some time, effectively providing support for 4 versions (1.28, 1.29, 1.30 and 1.31). See the versioning document for more details on SD's version skew policy.
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.
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:
Find the updated roadmap in the ROADMAP.md file.
If you wish to contribute please read the Contributing Guidelines.
SD is open-source software and it's released under the following LICENSE