GCP (GKE) Cluster Onboarding
Onboard GKE clusters to CoreStack FinOps for namespace and pod-level cost visibility.
Feature Overview
Kubernetes Cluster Onboarding for GCP is an agent-based capability within CoreStack's FinOps module that connects your Google Kubernetes Engine (GKE) cluster to CoreStack, enabling workload-level cost visibility and governance for your Google Cloud containerised workloads. It is most relevant when your organization runs workloads on GKE and needs accurate, namespace- and pod-level cost breakdowns as part of a multi-cloud Kubernetes governance strategy.
This feature is most valuable to Cloud Administrators, FinOps Analysts, and DevOps Engineers who need to bring GKE spend into a unified governance platform. It does not provide real-time cluster monitoring or infrastructure alerting — its purpose is cost ingestion and FinOps reporting.
Note: The CoreStack Kubernetes Agent must be deployed inside your GKE cluster by the CoreStack Technical Support Team. Download the YAML file during onboarding, then raise a support request to complete deployment using kubectl before selecting the confirmation checkbox.
How It Works
When you onboard a GKE cluster, a CoreStack Kubernetes Agent is deployed inside the cluster using a YAML file downloaded from the CoreStack platform and applied with kubectl. The agent connects to Prometheus — which must already be running in your environment — to retrieve node, pod, and container utilisation metrics. At regular intervals, the agent uploads these metrics to a Google Cloud Storage (GCS) bucket (either CoreStack's shared S3 bucket or your own GCS bucket), where CoreStack retrieves and processes the data. The processed data is surfaced as cost and utilisation insights on the CoreStack FinOps Dashboard. Cost data reflects completed ingestion cycles and is not real-time.
Note: If your GKE cluster runs in Autopilot mode, the CoreStack agent YAML may require resource adjustments to comply with Autopilot constraints. Review the generated YAML carefully before deployment. Confirm current GKE Autopilot agent support status with the CoreStack Technical Support Team before onboarding an Autopilot cluster.Before you begin, ensure the following are in place:
Prerequisites
Before you begin, ensure the following are in place:
| Prerequisite | Requirement |
|---|---|
| Role | You have the Account Admin role or equivalent in CoreStack, with access to the GCP project associated with the GKE cluster. |
| GCP project onboarded | The GCP project must be onboarded in CoreStack before GKE cluster onboarding can proceed. Complete cloud account onboarding first if not already done. |
| GKE cluster | A functioning GKE cluster (Standard or Autopilot) is available and accessible within the onboarded GCP project. |
| GCP APIs enabled | Both container.googleapis.com and storage.googleapis.com must be enabled in the GCP project. |
| Prometheus | Prometheus v2.x or higher is running in the cluster. Only one instance per cluster is required. The endpoint must be reachable from within the cluster. For GKE Autopilot, Prometheus must include resource requests/limits compatible with Autopilot. |
| kube-state-metrics | Version v2.9.0 or later (v2.10.x preferred) is deployed in the cluster. |
| cAdvisor | No separate installation required — bundled with the Kubelet on Kubernetes v1.20 or higher. |
| Network access | Outbound connectivity to storage.googleapis.com (GCS) or CoreStack S3 is enabled. For private GKE clusters, outbound to GCS must go through Cloud NAT or VPC Service Controls. |
| Storage decision | Decide whether to use Platform Managed Storage (CoreStack's shared S3 bucket) or User Specific Storage (your own GCS bucket). If User Specific, have GCP Service Account or GCP OAuth credentials ready. |
| Temporary disk space | The /tmp directory is writable and has sufficient free space. Logs are auto-purged above 500 MB. |
| Cluster details | Have the Cluster ID, Cluster Type, Cloud Provider (GCP), Region/Zone, and Cluster Mode (Standard or Autopilot) available. |
| Cost weightage (optional) | Define CPU, Memory, and GPU weightage percentages — total must equal 100%. Defaults: CPU 60%, Memory 20%, GPU 20%. |
Onboarding a GCP GKE Cluster
Navigate to Governance > Account Governance > Container Services.
The Container Services page lists all clusters currently connected to CoreStack. Follow the steps below to onboard a new GCP GKE cluster.
Step 1 — Initiate Cluster Onboarding
Click Onboard Cluster in the top-right corner of the Container Services page.
On the screen that appears, click Onboard to enter the onboarding wizard and select Google GKE as the cluster type.
Tip: Alternatively, on the Container Platform Accounts page, locate a cluster with a pending onboarding status and click Onboard in the Onboarding Status column for that cluster.
Step 2 — Select GCP Project and Cluster
In the Cloud Account drop-down list, select your GCP project and click Ok.
Note: If your GCP project has not yet been onboarded to CoreStack, the following message appears: "Your GCP project is not onboarded with the product. Please onboard your cloud account first to continue." Complete cloud account onboarding before proceeding.
The Cluster ID and Cluster Type fields populate automatically. Review these to confirm the correct cluster is selected.
Click Next.
Step 3 — Activate Products
In the Select and Manage Products step, confirm that FinOps is listed under Active Product(s) and that the drop-down to the left of FinOps is set to Active. Activate any additional product modules as required.
Click Next.
Step 4 — Configure Storage Access
In the Storage Access step, select a storage type from the Select Storage Access Type field. Choose one of the two options below and follow the corresponding instructions.
Option 1: Platform Managed Storage
Select Platform managed storage to store metrics in CoreStack's shared S3 bucket. CoreStack automatically handles storage provisioning, data retrieval, and processing — no Azure storage resources or credentials are required on your end. Choose this option if you do not have specific data residency requirements and want the simplest setup.
Click Next to proceed.
Option 2: User Specific Storage — GCP Service Account
Select User specific storage. Choose this option if you need metrics stored in your own GCP Blob Storage container — for example, to meet data residency or compliance requirements, or to retain direct access to the raw metrics data. You will need your Google storage account details and appropriate permissions ready before proceeding. Depending on whether the GCP account that owns the storage is onboarded in CoreStack, use one of the following methods:
Option 2a: Cloud Account Onboarded with Product
Use this option if the Azure subscription that owns the storage is already onboarded in CoreStack.
- Bucket Name: Enter the name of the GCS bucket.
- Dataset ID: Enter the Dataset ID associated with the storage configuration.
- Project ID: Enter the GCP Project ID.
- Storage Bucket: Enter the Storage Bucket name where metrics will be stored.
- File Path: Enter the file path within the bucket.
Click Save & Validate. A confirmation message indicates successful validation. Click Next to proceed.
Option 2b: GCP Service Account
Use this option if the GCP account that owns the storage is not onboarded in CoreStack. In the Select Authentication Protocol field, select GCP Service Account.
Enter the following details:
- Project ID: Enter the GCP Project ID.
- Upload Credentials File (JSON): Upload the GCP service account JSON key file.
- Storage Bucket: Enter the GCS bucket name where metrics will be stored.
- File Path: Enter the file path within the bucket.
Option 2c: GCP OAuth
Use this option to authenticate using GCP OAuth credentials. In the Select Authentication Protocol field, select GCP OAuth.
Enter the following details:
- Client ID: Enter the OAuth Client ID.
- Client Secret: Enter the OAuth Client Secret.
- Redirect URI: Enter the redirect URI used for OAuth authentication.
- Authorization Code: Enter the Authorization Code.
- Storage Bucket: Enter the Storage Bucket name where metrics will be stored.
- File Path: Enter the file path within the bucket.
Click Save & Validate. A confirmation message indicates successful validation. Click Next to proceed.
Step 5 — Configure Basic Settings and Deploy the Agent
In the Prometheus Endpoint field, enter the full URL of the Prometheus endpoint running in the GKE cluster. The endpoint must be reachable from within the cluster.
If Prometheus certification is required, select the Prometheus certification is required for accessing Prometheus endpoint checkbox and enter the values in the Certificate Path and Certificate fields that appear.
The Deployment Method is set to Kubernetes Deployment by default and does not need to be changed.
Note: If your cluster is running in Autopilot mode, the following message is displayed: "This is a GKE Autopilot cluster. The CoreStack agent YAML may require resource adjustments to comply with Autopilot constraints. Please review the generated YAML before deployment.
In the Install Kubernetes Agent section, click Download YAML to download the agent configuration file specific to this GKE cluster.
Note: Share the downloaded YAML file with the CoreStack Technical Support Team to complete the agent deployment. The agent is deployed using:
kubectl create -f kube-agent-<cluster-id>.yamlThe agent cannot be self-deployed.
After the agent has been deployed, select the I have installed the Kubernetes Agent checkbox and click Next.
Step 6 — Configure Advance Settings
In the Advance Settings step, enter the following:
- Cluster Description (optional): Enter a description for the cluster.
- Cost Resolution Frequency: Select how frequently cost data is calculated. Options: 15 Min, 30 Min (default), or 1 Hour.
In the Cost Weightage section, enter percentage values for CPU Weight (%) (default 60%), Memory Weight (%) (default 20%), and GPU Weight (%) (default 20%). The total must equal 100%.
Step 7 — Complete Onboarding
Click Finish to complete the onboarding of your GCP GKE cluster.
The newly onboarded cluster appears on the Container Platform Accounts page with its onboarding status updated.
Managing Onboarded GKE Clusters
After onboarding, all clusters are listed on the Container Platform Accounts page. Summary cards show counts for Active and Governed, Not Onboarded, Deactivated, and Invalid Credential accounts — filterable by cloud provider. To take action on a cluster, click the ⋯ (ellipsis) under the Actions column.
Edit Configuration
Click the ⋯ and select Edit Configuration. The edit wizard opens with the same steps as the onboarding wizard. The Cluster Details section is read-only and cannot be modified. All other sections are editable: you can update the FinOps product settings, reconfigure storage access and re-validate credentials, re-download the agent YAML if required, and adjust advance settings. Click Next through each step, then click Finish to save.
View Configuration
Click the ⋯ and select View Configuration. The Details tab opens, showing Basic Details (including Cluster Mode), Storage Access, Deployment, and Advance Settings — all read-only. Select the FinOps tab to review cost processing details.
Deactivate
Click the ⋯ and select Deactivate. In the confirmation dialog, click Yes. The cluster remains visible with status Deactivated and can be reactivated at any time.
Delete
Click the ⋯ and select Delete. In the confirmation dialog, click Yes to permanently remove the cluster from CoreStack.
Warning: Deleting a cluster permanently removes it and all associated configuration from CoreStack. This action cannot be undone.
Frequently Asked Questions
Q: My GCP project is not appearing in the Cloud Account drop-down. What should I do?
The GCP project must be onboarded to CoreStack before GKE clusters within it become available for onboarding. Navigate to cloud account management in CoreStack and complete GCP project onboarding first, then return to Container Services to onboard your GKE cluster.
Q: Which storage authentication method is recommended for GCP?
GCP Service Account is the recommended option as it uses a JSON key tied to a GCP service account with scoped permissions. Ensure the service account has Storage Object Admin permissions on the target GCS bucket. Use GCP OAuth if your environment uses OAuth-based credential management.
Q: What is the difference between GKE Standard and GKE Autopilot modes?
GKE Standard gives you full control over node configuration and management. GKE Autopilot is a managed mode where Google controls the node infrastructure. Both modes are supported for CoreStack onboarding, but the Kubernetes Agent YAML for Autopilot clusters may require resource adjustments. The Cluster Mode is auto-detected and displayed in the Cluster Details step.
Q: Can I change the storage authentication method after onboarding?
Yes. Click the ⋯ under Actions for the cluster and select Edit Configuration. Navigate to the Storage Access step, update your settings, and click Save & Validate before proceeding to Finish.
Q: Can I onboard multiple GKE clusters from the same GCP project?
Yes. Each cluster is onboarded independently and receives its own agent deployment and service account. Repeat the onboarding process for each cluster.
Q: How long does it take for cost data to appear in the FinOps Dashboard?
Cost data appears within 2 hours of successful agent deployment. The frequency of subsequent updates depends on the Cost Resolution Frequency set in Advance Settings.
Troubleshooting
No cost data appears in the FinOps Dashboard after onboarding
Cause: The Kubernetes Agent has not completed a successful ingestion cycle. Most commonly caused by network connectivity issues between the agent and Prometheus, or between the agent and the GCS storage endpoint.
Solution:
- Confirm the Prometheus endpoint is correct and reachable from within the cluster.
- Confirm outbound connectivity to storage.googleapis.com is not blocked. For private GKE clusters, verify Cloud NAT or VPC Service Controls are configured to allow outbound GCS traffic.
- Verify the /tmp directory is writable and has available disk space.
- Check the Agent Status column on the Container Platform Accounts page. If not Active, raise a request with the CoreStack Technical Support Team.
Note: If the issue persists, contact CoreStack support with: Cluster ID, GCP Region/Zone, Agent Status, and any error messages from the agent logs in
/tmp.
Storage validation fails with User Specific Storage
Cause: Credentials do not have sufficient permissions on the GCS bucket, or the bucket or project details are incorrect.
Solution:
- Confirm the GCS bucket exists and is accessible in the correct GCP project.
- For GCP Service Account: verify the service account has Storage Object Admin permissions. Confirm Bucket Name, Dataset ID, Project ID, and Storage Bucket values are correct.
- For GCP OAuth: verify Client ID, Client Secret, and Redirect URI are correct. Confirm the Authorization Code is valid and has not expired.
- Click Save & Validate again after correcting the details.
Note: If validation continues to fail, contact CoreStack support with: Cluster ID, storage type, authentication method, and the exact error message displayed.
Agent Status shows as inactive after deployment
Cause: The agent cannot reach the CoreStack management endpoint or the Prometheus endpoint, or the YAML values are incorrect. For Autopilot clusters, the YAML may not include required resource requests/limits.
Solution:
- Confirm the agent YAML was downloaded after completing the onboarding wizard.
- Verify the Prometheus endpoint is reachable from the namespace where the agent pod is deployed.
- Confirm the
kubectl create -f kube-agent-<cluster-id>.yamlcommand completed without errors. - For GKE Autopilot clusters: verify the YAML includes resource requests/limits compatible with Autopilot constraints before redeploying.
- Contact the CoreStack Technical Support Team with the Cluster ID, agent pod logs, Cluster Mode (Standard or Autopilot), and a description of the network configuration.
Updated about 4 hours ago