Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.skyhook.io/llms.txt

Use this file to discover all available pages before exploring further.

The management cluster hosts centralized components that aren’t needed on every cluster, such as ArgoCD (if using GitOps), and frontends for monitoring tools like Prometheus, Grafana, and Jaeger. This is especially relevant when self-hosting these components rather than using managed services.

​
Why Use a Management Cluster?

Separating management components from workload clusters reduces the risk of disruption to either production workloads or the supporting tools. Best practices recommend a dedicated management cluster, though Skyhook doesn’t technically prevent you from designating any cluster as your management cluster. Benefits of a dedicated management cluster:
  • Isolation: Keep management tools separate from production workloads
  • Access control: Simplify permissions management for centralized services
  • Reliability: Prevent resource contention between apps and management tools
  • Scalability: Size the cluster specifically for management workloads

​
Configuring Your Management Cluster

Navigate to Organization Settings > Management Cluster to designate which cluster hosts your centralized components.
Management cluster configuration showing cluster details
If you don’t have a management cluster configured yet, you’ll see a prompt to select one:
  1. Click Select Cluster
  2. Choose a cluster from your connected clusters
  3. Optionally configure the default domain
You don’t need to specify a management cluster immediately. You can leave this field empty and configure it later when you’re ready to install ArgoCD or centralized monitoring tools.

​
Management Cluster Details

Once configured, you’ll see the following information:
  • Name: The name of your management cluster (e.g., acme-production-main). This field is editable.
  • Status: Current operational status of the cluster. Common statuses:
    • ONLINE: Cluster is actively running and accessible
    • OFFLINE: Cluster is not reachable
    • DEGRADED: Cluster has issues but is partially operational
  • Location: The cloud region where the management cluster is hosted (e.g., us-west-2, eu-west-1). Important for understanding data residency and latency.
  • Project: The cloud project or account the cluster belongs to (e.g., acme-prod). Helps segregate and organize resources across multiple projects.
  • Default Domain: The default domain for centralized services (e.g., acme.com). When you configure tools like Grafana or ArgoCD with an Ingress, Skyhook uses this domain by default. For example, ArgoCD might be accessible at argocd.acme.com.

​
Addons

This section lists the additional components or “addons” that have been installed on the management cluster to extend its functionality. Examples include:
  • ArgoCD: ArgoCD is a declarative, GitOps continuous delivery tool for Kubernetes.
  • Cert Manager: Ensures the management cluster has capabilities for automating the management and issuance of TLS certificates.
  • External Secrets Operator: Facilitates integrating external secret management systems (e.g., AWS Secrets Manager, Azure Key Vault) with the Kubernetes cluster, enabling secure and centralized management of sensitive information.

​
Custom Resource Definitions (CRDs)

Provides a searchable list of CRDs deployed within the management cluster. CRDs are extensions of the Kubernetes API that allow for the creation of new, custom resources. They are pivotal for customizing Kubernetes clusters to meet specific needs. Each CRD entry includes the name, scope (indicating whether the CRD is namespaced or cluster-wide), supported versions, age (how long it has been deployed), a brief description, and any applicable labels. The list covers a wide range of groups, indicating the diverse functionalities and integrations supported by your management cluster, such as monitoring, auto-scaling, certificate management, networking, and data migration.