github.com/berops/claudie @v0.15.0

Platform for managing multi-cloud, hybrid-cloud, and on-premises Kubernetes clusters, with nodepools that mix cloud providers and your own bare-metal or co-located servers

<img alt="Claudie cluster diagram animation" src="https://github.com/berops/claudie/raw/v0.15.0/docs/assets/cluster-diagram-animation-light.webp">

Intro video

Vision of Claudie

The purpose of Claudie is to become the final Kubernetes engine you'll ever need. It builds clusters that leverage features and costs across on-premises datacenters and multiple cloud vendors, all from a single InputManifest. A Kubernetes that you won't ever need to migrate away from.

Typical use cases

Claudie has been built as an answer to the following Kubernetes challenges.

• Cost savings
• Data locality & compliance (e.g. GDPR)
• Managed Kubernetes for providers that do not offer it
• Cloud bursting
• Service interconnect
• On-premises & hybrid integration of existing bare-metal or co-located servers as nodepools
• Integration of GPU nodes into Kubernetes for AI workloads

Read in more details here.

Features

Manage multi-cloud, hybrid-cloud, and on-premises Kubernetes clusters

Create fully-featured Kubernetes clusters composed of multiple different public Cloud providers and your own on-premises data centers in an easy and secure manner. Simply insert credentials to your cloud projects, define your cluster, and watch how the infra spawns right in front of you.

  <img alt="Claudie cluster diagram – click to play" src="https://github.com/berops/claudie/raw/v0.15.0/docs/assets/cluster-diagram-v2-light.png">

Management via IaC

Declaratively define your infrastructure with a simple, easy to understand YAML syntax. See example manifest.

Fast scale-up/scale-down of your infrastructure

To scale-up or scale-down, simply change a few lines in the input manifest and Claudie will take care of the rest in the matter of minutes.

Loadbalancing

Claudie has its own managed load-balancing solution, which you can use for Ingresses, the Kubernetes API server, or generally anything. Check out our LB docs.

Persistent storage volumes

Claudie comes pre-configured with a storage solution, with ready-to-use Storage Classes. See Storage docs to learn more.

Get started using Claudie

Prerequisites

Before you begin, please make sure you have the following prerequisites installed and set up:

1. Claudie needs to be installed on an existing Kubernetes cluster, referred to as the Management Cluster, which it uses to manage the clusters it provisions. For testing, you can use ephemeral clusters like Minikube or Kind. However, for production environments, we recommend using a more resilient solution since Claudie maintains the state of the infrastructure it creates.

2. Claudie requires the installation of cert-manager in your Management Cluster. To install cert-manager, use the following command: bash kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.19.3/cert-manager.yaml

Supported providers

Note: N/A indicates that the given feature is not applicable for the provider.

For adding support for other cloud providers or on-premises environments, open an issue or propose a PR.

Install Claudie

1. Deploy Claudie to the Management Cluster: bash kubectl apply -f https://github.com/berops/claudie/releases/latest/download/claudie.yaml

To further harden claudie, you may want to deploy our pre-defined network policies: bash # for clusters using cilium as their CNI kubectl apply -f https://github.com/berops/claudie/releases/latest/download/network-policy-cilium.yaml bash # other kubectl apply -f https://github.com/berops/claudie/releases/latest/download/network-policy.yaml

Deploy your cluster

1. Create Kubernetes Secret resource for your provider configuration.

   bash kubectl create secret generic example-aws-secret-1 \ --namespace=<your-namespace> \ --from-literal=accesskey='<your-access-key>' \ --from-literal=secretkey='<your-secret-key>'

   Check the supported providers for input manifest examples. For an input manifest spanning all supported hyperscalers checkout out this example.

2. Deploy InputManifest resource which Claudie uses to create infrastructure, include the created secret in .spec.providers as follows: bash kubectl apply -f - <<EOF apiVersion: claudie.io/v1beta1 kind: InputManifest metadata: name: examplemanifest labels: app.kubernetes.io/part-of: claudie spec: providers: - name: aws-1 providerType: aws secretRef: name: example-aws-secret-1 # reference the secret name namespace: <your-namespace> # reference the secret namespace nodePools: dynamic: - name: control-aws providerSpec: name: aws-1 region: eu-central-1 zone: eu-central-1a count: 1 serverType: t3.medium image: ami-0965bd5ba4d59211c - name: compute-1-aws providerSpec: name: aws-1 region: eu-west-3 zone: eu-west-3a count: 2 serverType: t3.medium image: ami-029c608efaef0b395 storageDiskSize: 50 kubernetes: clusters: - name: aws-cluster version: 1.27.0 network: 192.168.2.0/24 pools: control: - control-aws compute: - compute-1-aws EOF

   Deleting existing InputManifest resource deletes provisioned infrastructure!

Connect to your cluster

Claudie outputs base64 encoded kubeconfig secret <cluster-name>-<cluster-hash>-kubeconfig in the namespace where it is deployed:

1. Recover kubeconfig of your cluster by running: bash kubectl get secrets -n claudie -l claudie.io/output=kubeconfig -o jsonpath='{.items[0].data.kubeconfig}' | base64 -d > your_kubeconfig.yaml
2. Use your new kubeconfig: bash kubectl get pods -A --kubeconfig=your_kubeconfig.yaml

Cleanup

1. To remove your cluster and its associated infrastructure, delete the cluster definition block from the InputManifest: bash kubectl apply -f - <<EOF apiVersion: claudie.io/v1beta1 kind: InputManifest metadata: name: examplemanifest labels: app.kubernetes.io/part-of: claudie spec: providers: - name: aws-1 providerType: aws secretRef: name: example-aws-secret-1 # reference the secret name namespace: <your-namespace> # reference the secret namespace nodePools: dynamic: - name: control-aws providerSpec: name: aws-1 region: eu-central-1 zone: eu-central-1a count: 1 serverType: t3.medium image: ami-0965bd5ba4d59211c - name: compute-1-aws providerSpec: name: aws-1 region: eu-west-3 zone: eu-west-3a count: 2 serverType: t3.medium image: ami-029c608efaef0b395 storageDiskSize: 50 kubernetes: clusters: # - name: aws-cluster # version: 1.27.0 # network: 192.168.2.0/24 # pools: # control: # - control-aws # compute: # - compute-1-aws EOF

2. To delete all clusters defined in the input manifest, delete the InputManifest. This triggers the deletion process, removing the infrastructure and all data associated with the manifest.

   bash kubectl delete inputmanifest examplemanifest

Get involved

Everyone is more than welcome to open an issue, a PR or to start a discussion.

For more information about contributing please read the contribution guidelines.

If you want to have a chat with us, feel free to join our channel on kubernetes Slack workspace (get invite here).

Versioning

Current project releasing follows ZerOver, with the following versioning promise: - In new releases, API might break and functionality might change significantly. Any such releases increment the second digit in the release tag. The users really need to read the release notes before upgrading to these releases. - For all other releases, the third digit increments. Upgrades to these versions can be done blindly without any risk to running environments. Reading the release notes is recommended nevertheless.

Security

While we strive to create secure software, there is always a chance that we miss something. If you've discovered something that requires our attention, see our security policy to learn how t