gcp-gke-cost-optimization
Analyzes and optimizes Google Kubernetes Engine costs through right-sizing resources, comparing cluster modes, and implementing autoscaling strategies. Use when analyzing GKE spending, comparing Autopilot vs Standard billing models, configuring Spot VMs for batch workloads, right-sizing pod resources, setting up budget alerts, or tracking cost per service. Includes per-pod billing analysis and resource utilization optimization patterns.
What this skill does
# GKE Cost Optimization
## Purpose
Reduce GKE spending while maintaining performance and reliability. This skill covers cost analysis, resource right-sizing, cluster mode comparison, and budget monitoring strategies.
## When to Use
Use this skill when you need to:
- Analyze GKE spending and identify cost optimization opportunities
- Compare Autopilot vs Standard billing models for your workload
- Right-size pod resource requests and limits
- Configure Horizontal/Vertical Pod Autoscaling to reduce waste
- Set up Spot VMs for batch or non-critical workloads
- Create budget alerts and track cost per service
- Optimize resource utilization
Trigger phrases: "optimize GKE costs", "reduce Kubernetes spending", "right-size resources", "Autopilot vs Standard pricing", "GKE budget alerts"
## Table of Contents
- [Purpose](#purpose)
- [When to Use](#when-to-use)
- [Quick Start](#quick-start)
- [Instructions](#instructions)
- [Step 1: Understand Your Billing Model](#step-1-understand-your-billing-model)
- [Step 2: Analyze Current Resource Usage](#step-2-analyze-current-resource-usage)
- [Step 3: Right-Size Pod Resources](#step-3-right-size-pod-resources)
- [Step 4: Configure Horizontal Pod Autoscaling](#step-4-configure-horizontal-pod-autoscaling-hpa)
- [Step 5: Use Spot VMs](#step-5-use-spot-vms-gke-standard-only)
- [Step 6: Set Up Cost Monitoring](#step-6-set-up-cost-monitoring)
- [Step 7: Analyze Cost by Namespace/Service](#step-7-analyze-cost-by-namespaceservice)
- [Examples](#examples)
- [Requirements](#requirements)
- [See Also](#see-also)
## Quick Start
Analyze and optimize costs in three steps:
```bash
# 1. Check current resource usage
kubectl top pods -n wtr-supplier-charges
# 2. Analyze resource requests vs actual usage
kubectl describe deployment supplier-charges-hub -n wtr-supplier-charges | grep -A 10 "resources:"
# 3. Compare Autopilot vs Standard pricing for your workload
# Autopilot: Pay per pod per second for requests
# Standard: Pay per provisioned node per hour (regardless of usage)
```
## Instructions
### Step 1: Understand Your Billing Model
#### GKE Autopilot (Per-Pod Billing - Recommended)
**Cost Calculation:**
```
Monthly Cost = (vCPU requests * $0.04 + Memory requests GB * $0.004 + Disk GB * $0.0001) * seconds per month
```
**Example for Supplier Charges Hub:**
- 2 replicas, each requesting: 1 vCPU + 2 GB memory
- Monthly cost ≈ (2 * 1 * $0.04 + 2 * 2 * $0.004) * 2.592M seconds ≈ $260
**Advantages:**
- Pay only for what pods request (not what entire cluster capacity is)
- No idle resource costs
- Perfect for variable workloads (scales up/down automatically)
- Up to 60% cheaper than Standard for typical workloads
#### GKE Standard (Node Billing)
**Cost Calculation:**
```
Monthly Cost = Number of nodes * Machine type hourly rate * 730 hours per month
```
**Example for Supplier Charges Hub:**
- 3 `n2-standard-4` nodes (standard pool) = ~$400/month
- Even if pods use only 30% of capacity, you pay for 100%
**Advantages:**
- Predictable costs (great for committed use discounts)
- Full control over infrastructure
- Better for stable, high-utilization workloads
### Step 2: Analyze Current Resource Usage
Check if pods are over-provisioned:
```bash
# View actual vs requested resources
kubectl top pods -n wtr-supplier-charges -o wide
# Compare to requests
kubectl get pods -n wtr-supplier-charges -o jsonpath='{.items[*].spec.containers[*].resources.requests}'
```
**Analysis Questions:**
- Are actual values significantly lower than requests?
- Is memory usage consistently below 75% of limits?
- Is CPU usage consistently below 70% of requests?
**If Yes → Right-size resources (reduce requests)**
### Step 3: Right-Size Pod Resources
Use Vertical Pod Autoscaler (VPA) recommendations:
```bash
# Apply VPA to deployment
cat <<EOF | kubectl apply -f -
apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
name: supplier-charges-hub-vpa
namespace: wtr-supplier-charges
spec:
targetRef:
apiVersion: "apps/v1"
kind: Deployment
name: supplier-charges-hub
updatePolicy:
updateMode: "Off" # Only provide recommendations, don't auto-update
resourcePolicy:
containerPolicies:
- containerName: supplier-charges-hub-container
minAllowed:
cpu: 500m
memory: 1Gi
maxAllowed:
cpu: 2
memory: 4Gi
EOF
# Wait 1 week for data collection, then view recommendations
kubectl describe vpa supplier-charges-hub-vpa -n wtr-supplier-charges | grep -A 20 "Recommendation"
```
**Recommended VPA Values:**
```yaml
resources:
requests:
cpu: 500m # Reduced from 1000m if usage averages 300m
memory: 1.5Gi # Reduced from 2Gi if usage averages 1Gi
limits:
cpu: 500m # Match requests for Guaranteed QoS
memory: 1.5Gi
```
### Step 4: Configure Horizontal Pod Autoscaling (HPA)
Let Kubernetes scale replicas based on demand:
```yaml
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: supplier-charges-hub-hpa
namespace: wtr-supplier-charges
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: supplier-charges-hub
minReplicas: 1 # Scale down to 1 during low traffic
maxReplicas: 5 # Scale up to 5 during peak
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 70
- type: Resource
resource:
name: memory
target:
type: Utilization
averageUtilization: 80
behavior:
scaleDown:
stabilizationWindowSeconds: 300
policies:
- type: Percent
value: 50
periodSeconds: 60
```
**Cost Savings:** Reduces off-peak replicas from 2 to 1 = ~30% savings if traffic varies.
### Step 5: Use Spot VMs (GKE Standard Only)
For non-critical or fault-tolerant workloads, use Spot VMs (91% discount):
```bash
# Create Spot node pool
gcloud container node-pools create spot-pool \
--cluster=shared-gke-standard-01-euw2 \
--region=europe-west2 \
--spot \
--machine-type=n2-standard-4 \
--num-nodes=2 \
--enable-autoscaling \
--min-nodes=0 \
--max-nodes=10
# Add toleration to workloads that can run on Spot
tolerations:
- key: cloud.google.com/gke-spot
operator: Equal
value: "true"
effect: NoSchedule
```
**Use Cases:** Batch processing, CI/CD build workers, non-critical background jobs
**Not for:** Production APIs (Supplier Charges Hub should NOT use Spot)
### Step 6: Set Up Cost Monitoring
Create budget alerts:
```bash
# Create budget with 50%, 90%, 100% thresholds
gcloud billing budgets create \
--billing-account=BILLING_ACCOUNT_ID \
--display-name="GKE Labs Environment" \
--budget-amount=500USD \
--threshold-rule=percent=50 \
--threshold-rule=percent=90 \
--threshold-rule=percent=100 \
--notification-rule-name=email-alert
```
### Step 7: Analyze Cost by Namespace/Service
Export billing data for detailed analysis:
```bash
# Tag namespace for cost tracking
kubectl label namespace wtr-supplier-charges \
cost-center=supplier-charges \
environment=labs
# Later, filter GCP Billing reports by labels
# In Cloud Console: Billing → Reports → Filter by labels
```
## Examples
### Example 1: Optimize Supplier Charges Hub Deployment
```bash
#!/bin/bash
# Step-by-step optimization
DEPLOYMENT="supplier-charges-hub"
NAMESPACE="wtr-supplier-charges"
echo "=== GKE Cost Optimization ==="
echo ""
echo "1. Current Resource Usage:"
kubectl top pods -l app=$DEPLOYMENT -n $NAMESPACE
echo ""
echo "2. Current Resource Requests:"
kubectl get deployment $DEPLOYMENT -n $NAMESPACE \
-o jsonpath='{.spec.template.spec.containers[0].resources}'
echo ""
echo "3. Applying VPA for recommendations:"
cat <<EOF | kubectl apply -f -
apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
name: ${DEPLOYMENT}-vpa
namespace: $NAMESPACE
spec:
targetRef:
apiVersion: "apps/v1"
kind: Deployment
name: $DEPLRelated in Cloud & DevOps
appbuilder-action-scaffolder
IncludedCreate, implement, deploy, and debug Adobe Runtime actions with consistent layout, validation, and error handling. Use this skill whenever the user needs to add actions to an App Builder project, understand action structure (params, response format, web/raw actions), configure actions in the manifest, use App Builder SDKs (State, Files, Events, database), deploy and invoke actions via CLI, debug action issues, or implement patterns such as webhook receivers, custom event providers, journaling consumers, large payload redirects, action sequence pipelines, and Asset Compute workers. Also trigger when users mention serverless functions in Adobe context, action logging, IMS authentication for actions, or cron-style scheduled actions.
orchestrating-datacloud
IncludedSalesforce Data Cloud product orchestrator for connect→prepare→harmonize→segment→act workflows. Use this skill when the user needs a multi-step Data Cloud pipeline, cross-phase troubleshooting, or data space and data kit management. TRIGGER when: user needs a multi-step Data Cloud pipeline, asks to set up or troubleshoot Data Cloud across phases, manages data spaces or data kits, or wants a cross-phase sf data360 workflow. DO NOT TRIGGER when: work is isolated to a single phase (use the matching phase-specific skill), the task is STDM/session tracing/parquet telemetry (use observing-agentforce), standard CRM SOQL (use querying-soql), or Apex implementation (use generating-apex).
github-project-automation
IncludedAutomate GitHub repository setup with CI/CD workflows, issue templates, Dependabot, and CodeQL security scanning. Includes 12 production-tested workflows and prevents 18 errors: YAML syntax, action pinning, and configuration. Use when: setting up GitHub Actions CI/CD, creating issue/PR templates, enabling Dependabot or CodeQL scanning, deploying to Cloudflare Workers, implementing matrix testing, or troubleshooting YAML indentation, action version pinning, secrets syntax, runner versions, or CodeQL configuration. Keywords: github actions, github workflow, ci/cd, issue templates, pull request templates, dependabot, codeql, security scanning, yaml syntax, github automation, repository setup, workflow templates, github actions matrix, secrets management, branch protection, codeowners, github projects, continuous integration, continuous deployment, workflow syntax error, action version pinning, runner version, github context, yaml indentation error
sf-datacloud
IncludedSalesforce Data Cloud product orchestrator for connect→prepare→harmonize→segment→act workflows. TRIGGER when: user needs a multi-step Data Cloud pipeline, asks to set up or troubleshoot Data Cloud across phases, manages data spaces or data kits, or wants a cross-phase `sf data360` workflow. DO NOT TRIGGER when: work is isolated to a single phase (use the matching sf-datacloud-* skill), the task is STDM/session tracing/parquet telemetry (use sf-ai-agentforce-observability), standard CRM SOQL (use sf-soql), or Apex implementation (use sf-apex).
fabric-cli
IncludedUse this skill for Fabric.so CLI workflows with the `fabric` terminal command: diagnose/install/login, search or browse a Fabric library, save notes/links/files, create folders, ask the Fabric AI assistant, manage tasks/workspaces, generate shell completion, check subscription usage, produce JSON output, and use Fabric as persistent agent memory. Do not use for Microsoft Fabric/Azure/Power BI `fab`, Daniel Miessler's Fabric framework, Python Fabric SSH, Fabric.js, or textile/fashion fabric.
lark
IncludedLark/Feishu CLI skills: lark-cli operations for docs, markdown, sheets, base, calendar, im, mail, task, okr, drive, wiki, slides, whiteboard, apps, approval, attendance, contact, vc, minutes, event. Use when the user needs to operate Lark/Feishu resources via lark-cli, send messages, manage documents, spreadsheets, calendars, tasks, OKRs, deploy web pages, or any Feishu/Lark workspace operations.