What is it?

The GKE Autopilot Template is a pre built system template designed for managing Google Kubernetes Engine (GKE) Autopilot cluster lifecycle management, covering both day-0 and day-2 operations. This template is part of the Template Catalog under the Kubernetes Lifecycle Management section and enables organizations to create self-service workflows for end users without requiring extensive configuration knowledge.

This template provides comprehensive GKE Autopilot management capabilities and is fully supported with regular updates and new features added over time. With these templates, administrators can follow two simple steps to provide a self-service experience for their end users:

1. Configure and customize the system template (provide credentials, specify defaults, and determine what values end users can/cannot override) in a project owned by the Platform team
2. Publish by sharing the template with end user projects

Prerequisites

Before consuming the GKE Autopilot Template, ensure you have the following prerequisites in place:

1. Healthy GitOps Agent

• Deploy a healthy GitOps agent that drives the workflow
• The agent can be deployed as:
  • Docker container
  • Kubernetes deployment
• The agent's network must have reachability to the network where GKE Autopilot clusters will be created
• Refer to the GitOps Agent setup documentation for detailed configuration

2. Valid Rafay API Key

• Obtain a valid Rafay API key for authentication
• The API key should have appropriate permissions for GKE Autopilot template operations
• Refer to the API Key management documentation for setup instructions

3. Google Cloud Service Account Credentials

• Configure valid Google Cloud Service Account credentials with permissions for:
  • Authentication
  • GKE Autopilot lifecycle management operations
• The service account should have the necessary IAM roles for GKE cluster management
• Refer to the GKE credentials documentation for detailed setup instructions

Configuration

The GKE Autopilot System Template includes the following configuration sections:

1. Agent Configuration

• GitOps Agent or Agent Pools can be configured at the template level or added at runtime during environment deployment
• Drives workflow execution.

2. Backend Store Type Configuration

• State Store configuration for managing infrastructure state
• Supports System (Rafay-managed), S3, or TFC (Terraform Cloud) backend stores
• Set to empty by default - use System store for quick deployment

3. Rafay-Specific Configuration

• Blueprint specification for the cluster configuration
• Project name where the GKE Autopilot cluster will be created
• Defines the Rafay platform configuration

4. Google Cloud GKE Autopilot Configuration

• Google Cloud-specific settings for GKE Autopilot cluster creation and management
• Includes region, networking, and other GKE Autopilot-specific parameters
• Note: GKE Autopilot manages node pools automatically, so node pool configuration is not required

5. Credentials

• Rafay API Key for platform authentication
• Google Cloud Credentials (Service Account)
• Can be configured at the template level or applied at runtime during environment deployment

Workflow Overview

The GKE Autopilot Template follows a centralized configuration model where platform administrators first configure and customize the template in a central project, then share it with end-user projects for consumption.

Step-by-Step Guide

WARNING

This guide provides general guidance and example configurations only. It may not meet your specific environment requirements or cover all possible configurations. Tailor this configuration steps to your needs.

Step 1: Locate and Initialize the GKE Autopilot Template

1. Navigate to the Template Catalog from the home page
2. Under Kubernetes Lifecycle Management, locate the GKE Autopilot card
3. Click the Get Started button
4. Provide the following details:
5. Template name for your organization
6. Version identifier
7. Central project where you'll configure the template before sharing

Step 2: Configure the Template

Once the GKE Autopilot template is shared to your central project, configure the essential components:

2.1 Add GitOps Agent

• Configure the GitOps agent at the template level
• This agent will drive the workflow execution for the deployment.

2.2 Configure Backend Store Type

Configure the backend store type for state management. This setting is empty by default and supports the following state store configurations:

Supported State Store Types:

1. System (Recommended for quick deployment)
   • State is managed and stored in Rafay's state store
   • No need to bring your own state store
   • Ideal for getting started quickly without external infrastructure
2. S3
   • Use Amazon S3 as the state store
   • Provide access credentials (Access ID and Secret) to interact with the S3 endpoint
   • Alternatively, use role-based ARN assuming the agent driving the workflow has a role that grants access to the S3 service
3. TFC (Terraform Cloud)
   • Use Terraform Cloud (TFC) as the state store
   • Provide TFC-related configuration including organization, workspace, and authentication details

Quick Start

If you're deploying for the first time or testing, select system backend store type. This uses Rafay's managed state store and requires no additional configuration, allowing you to start deploying immediately.

2.3 Set Up Configuration Context

• Configure the gke-autopilot-env-vars context with:
  • Google Cloud credentials (Service Account)
  • Rafay API key for authentication
• Lock the credentials to prevent end users from modifying them

2.4 Lock Down Credentials

This screenshot shows one variable locking, but you can apply the same approach to other credential variables. Set them as non-overrideable so users cannot see or modify them so that credentials are handled implicitly for end users.

Step 3: Customize Input Variables

Platform administrators can customize which variables to expose to end users:

3.1 Set Default Values

• Blueprint name and version for cluster configuration
• Region for GKE Autopilot cluster deployment
• Kubernetes version for the cluster
• Cluster tags for resource organization

Step 4: Configure Schedules (Optional)

Set up automated schedules for cluster lifecycle management:

• Destroy schedule (e.g., destroy clusters at end of business day)
• Deploy schedule (e.g., recreate clusters in the morning)
• Maintenance windows for updates

Step 5: Share with End User Projects

Once configuration is complete, save it as an active version and share the template with end-user projects:

1. Navigate to the template sharing settings
2. Select target end-user projects
3. Publish the template for consumption

Step 6: Enable Approval Hooks (Optional)

When you share the template with a central project, approval hooks are disabled by default. If you want to review the plan before applying infrastructure changes, you can enable approval hooks.

There are two types of approval hooks available:

• Apply Before: Requires approval before applying infrastructure changes
• Destroy Before: Requires approval before destroying infrastructure resources

Configuration Flexibility

This workflow provides flexibility for different organizational needs:

• Fully Managed: Platform admin configures all settings, end users simply deploy
• Hybrid Approach: Some settings pre-configured, others left for end users
• User-Driven: Minimal pre-configuration, maximum end-user control

The recommended approach is the fully managed configuration, which reduces the burden on end users while maintaining security and compliance standards.

End User Flow

Once the platform administrator shares the GKE Autopilot template to end-user projects, end users can easily deploy GKE Autopilot clusters with minimal configuration effort.

Step 1: Access the Shared Template

1. Navigate to your project where the GKE Autopilot template has been shared
2. Locate the GKE Autopilot Template in your available templates
3. Click Launch to begin the deployment process

Step 2: Configure Template Inputs

Based on the configuration exposed by the platform administrator, provide the necessary inputs:

2.1 Required Configuration

• Cluster name for your GKE Autopilot deployment
• Project ID (if not pre-configured)
• Region (if multiple regions are allowed)
• Resource requests (CPU and memory requirements)

2.2 Optional Configuration

• Cluster tags for resource organization
• Network configuration (if exposed by admin)
• Additional labels or annotations

2.3 State Store Configuration (if exposed by platform admin)

Configure the state store for managing deployment state:

• Backend Store Type: Select from the available options:
  • System: Use Rafay's managed state store (recommended for quick deployment)
  • S3: Use Amazon S3 as the state store
  • TFC: Use Terraform Cloud as the state store
• Backend Store Configuration: Provide the necessary details based on your selected store type:

Step 3: Deploy or Save Configuration

After providing all required inputs, you have two options:

Option 1: Save and Continue Later

• Click Save to store your configuration
• Return later to complete the deployment

Option 2: Save and Deploy

• Click Save & Deploy to immediately start the deployment process
• The GKE Autopilot cluster creation will begin automatically

Step 4: Monitor Deployment Progress

Track the deployment progress through the status indicators.

Step 5: Access Cluster Resources

Once the deployment status shows Success, you will receive the following output configuration:

5.1 Cluster Access Information

• Kubeconfig file for cluster access

5.2 Resource Information

• Google Cloud project where cluster was created
• GKE Autopilot cluster details and status

Step 6: Verify Cluster Access

After successful deployment, download the ZTKA KUBECONFIG from Infrastructure > Clusters to interact with the cluster. You can now deploy workloads on this successfully provisioned cluster.

Benefits for End Users

• Simplified Deployment: Pre-configured templates reduce complexity
• Consistent Configuration: Standardized settings across all deployments
• Security: Credentials managed by platform administrators
• Compliance: Built-in governance and policy enforcement
• Self-Service: Deploy clusters without waiting for platform team assistance.