Skip to main content
Version: main

Managing existing clusters enterprise

Managing non-capi clusters

Any kubernetes cluster whether capi or not can be added to Weave Gitops Enterprise. The only thing we need is a secret containing a valid kubeconfig.

If you already have a kubeconfig stored in a secret in your management cluster, continue below to create a GitopsCluster.

If you have a kubeconfig, you can load in into the cluster like so:

kubectl create secret generic demo-01-kubeconfig \
--from-file=value.yaml=./demo-01-kubeconfig

Connect a cluster

Get started first!

Make sure you've

  1. Added some common RBAC rules into the clusters/bases folder, as described in Getting started.
  2. Configured the cluster bootstrap controller as described in Getting started.

Create a GitopsCluster

./clusters/management/clusters/demo-01.yaml
apiVersion: gitops.weave.works/v1alpha1
kind: GitopsCluster
metadata:
name: demo-01
namespace: default
# Signals that this cluster should be bootstrapped.
labels:
weave.works/capi: bootstrap
spec:
secretRef:
name: demo-01-kubeconfig

When the GitopsCluster appears in the cluster, the Cluster Bootstrap Controller will install flux on it and by default start reconciling the ./clusters/demo-01 path in your management cluster's git repository. To inspect the Applications and Sources running on the new cluster we need to give permissions to the user accessing the UI. Common RBAC rules like this should be stored in ./clusters/bases. Here we create a kustomziation to add these common resources onto our new cluster:

./clusters/demo-01/clusters-bases-kustomization.yaml
apiVersion: kustomize.toolkit.fluxcd.io/v1beta2
kind: Kustomization
metadata:
creationTimestamp: null
name: clusters-bases-kustomization
namespace: flux-system
spec:
interval: 10m0s
path: clusters/bases
prune: true
sourceRef:
kind: GitRepository
name: flux-system

Save these 2 files into your git repository. Commit and push.

Once flux has reconciled the cluster you can inspect your flux resources via the UI!

Debugging

How to test a kubeconfig secret in a cluster

To test a kubeconfig secret has been correctly setup apply the following manifest and check the logs after the job completes:

apiVersion: batch/v1
kind: Job
metadata:
name: kubectl
spec:
ttlSecondsAfterFinished: 30
template:
spec:
containers:
- name: kubectl
image: bitnami/kubectl
args:
[
"get",
"pods",
"-n",
"kube-system",
"--kubeconfig",
"/etc/kubeconfig/value.yaml",
]
volumeMounts:
- name: kubeconfig
mountPath: "/etc/kubeconfig"
readOnly: true
restartPolicy: Never
volumes:
- name: kubeconfig
secret:
secretName: demo-01-kubeconfig
optional: false

In the manifest above demo-01-kubeconfigis the name of the secret that contains the kubeconfig for the remote cluster.


Background