This scenario will walk you through the following steps:
- What is Fury Kubernetes Distribution
- What is Furyctl cli
- Interacting with Furyfile.yml
- Let's install the Monitoring stack
- Let's install the Logging stack
Introduction to Kubernetes Fury Distribution 🇬🇧
Step 1 - Introduction to Fury
In this step, we briefly introduce the Fury Kubernetes Distribution and its underlying architecture.
Fury Kubernetes Distribution
Fury is a CNCF certified battle-tested Kubernetes distribution based purely on upstream Kubernetes.
It is developed and maintained by SIGHUP, and it is fully open source.
What is the goal of Fury? 🎯
The goal of Fury is to turn any standard Kubernetes cluster into a fully-configured production-grade cluster.
We like to use the term battle-tested simplicity, meaning that we will do all the heavy lifting to provide you with a simple workflow to make your cluster ready to be deployed in the wild. 🦁
The un-distribution model
Fury uses an un-distribution model. This concept originates with Heptio, and the idea behind this model is to avoid to create proprietary solutions but instead rely only on open source technologies.
This freedom from vendor lock-in allows the flexibility to deploy Fury on various environments.
In a nutshell, what Fury does is stay close to upstream Kubernetes and the cloud-native landscape to provide you with a set of pre-configured battle-tested open source tools.
The underlying principles of Fury:
📦 Modularity We designed the distribution with modularity in mind. There are no strict requirements or interdependencies between modules. You can pick and choose only the one you need.
📖 Open source All the modules are fully open source. You can find the list of the GitHub repositories here
🚀 Only upstream Kubernetes We don't want to diverge from upstream Kubernetes and re-invent the wheel. We 💙 Kubernetes as it is.
🌱 Substrate independence You can deploy Fury on top of any cluster, both on-premises and in any of the major cloud providers. There are various installers that integrate best practices to deploy a Fury cluster in multiple environments.
Fury is architecture is simple. It is composed of a set of modules.
A module is a set of cohesive functionalities offered by the distribution.
There are two types of modules:
- Core modules offer essential functionality for a production-grade cluster
- Addon modules are plugins to provide additional features. For example, we can integrate with kong and istio.
The core modules of Fury are:
More information about modules can be found here
Each module it's composed of a set of packages.
A package is a single unit of functionality.
As an example, the logging module of Fury is composed of the following packages:
- Fluentd to collect logging data
- Kibana to visualize and analyze Elasticsearch data.
- Elasticsearch-single to index logging data (single node deployment)
- Elasticsearch-triple to index logging data (three nodes deployment)
- Cerebro to manage Elasticsearch cluster via GUI
- Curator to manage Elasticsearch indices
As you can see, the logging module of Fury relies on the commonly adopted EFK stack (Elastic, Fluentd, Kibana). All tools are widely used, not proprietary, pre-configured and easily customizable.
Battle-tested simplicity. ⚔️
To recap, Fury is composed of a set modules. Each module contains a set of packages. Packages are a single unit of functionality; modules group together packages that are related.
Modules and packages are loosely coupled. You don't have to deploy all the distribution modules, and you don't have to deploy all the packages inside a module.
All clear? Let's see it in action. 😎