📒 Developer Guide
There is always room for improvement over at Kubernetes Fury Distribution (KFD). We welcome all contributors who would like to get their hands dirty, and we promise to guide you through the journey.
Get an understanding of the core concepts of Fury Distribution
We have great documentation about the core concepts of KFD over here. We recommend you go through it to understand the base principles on how our distribution works and what makes it easy to use and configure. If you have any questions or doubts, please feel free to drop our engineers quickly a message at our Slack or via e-mail.
You can also open a Question issue over at Github.
Understand our tooling and distribution methods
We use a lot of popular package management and infra configuration tools for the KFD distribution. We recommend you get them installed and get a basic understanding of how to use them:
kubectlkustomizeterraform- furyctl (ideally, the latest available)
Basic working knowledge of Kubernetes is required.
Explore our repositories
Finding your way around our repositories can be a bit of a hassle. Due to the modular nature of our distro, the parts comprising our module is rather spreading around. So here is a quick list of our most important repositories:
| Repo Name/URL | Description |
|---|---|
| fury-distribution | This is the base repo of KFD. |
| furyctl | furyctl is the KFD (Kubernetes Fury Distribution) lifecycle manager |
Core Modules
| Module | Description |
|---|---|
| Networking | Networking functionality via Calico CNI |
| Ingress | Fast and reliable Ingress Controller and TLS certificate management |
| Logging | A centralized logging solution based on the EFK stack (Elastic, Fluentd, and Kibana) |
| 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 |
| Auth | Improved auth for your Kubernetes Cluster and its applications |
Add-on Modules
| Module | Description |
|---|---|
| Kong | Add Kong API Gateway for Kubernetes applications via Kong Ingress Controller |
| Service Mesh | Deploy a service mesh on top of KFD |
| Registry | Comprehensive Container Registry solution |
| Kafka | Apache Kafka event streaming for your Clustersolution |
| Storage | Rook (Ceph Operator) based Storage solution on Kubernetes |
Testing Fury out
The best way to get started with Fury is to test it on your favourite cloud provider. We have very well explained documentation about how to set it up with a step by step guide over here. If you are stuck, you know where to get help.
Contributing
If you can think of a feature that might work great with Fury by you can't find it, please open an issue in the
fury-distribution repo under the Enhancements template and ask us to add it. Make sure the following information is clear while opening the issue:
- Describe the feature in a couple of lines.
- Give us a quick description of the environment where the need arises
- Describe any available alternative out there
We will review the issue and let you know if it works for us to implement it.
Hands-on
In case someone at SIGHUP reviewed the issue and validated the idea, you will need to
fork the repository
and create a new branch with a self-descriptive name.
For example git checkout -b add-envoy-rate-limit.
💡 we use semantic commits internally, we invite you to follow this standard too when commiting.
It would be best if you worked in your branch until you reached a stable enough feature.
Remember that you will have an engineer at SIGHUP who will help you if you have doubts about the feature.
Once you feel it's the right moment to open a pull request, do it against a new branch SIGHUP engineer should open (ask for it).
The Product Team will review this PR at SIGHUP. Once the Product Team approves the change, it will be merged into our repository, and E2E validation tests will run.
SIGHUP's Product Team is responsible for the releases, so the new feature will be released when the Product Team thinks it's the right moment.