Deploying workloads

As you read in our Cluster lifecycle guide, as a GKE user you generally use Google Cloud tools for cluster management and Kubernetes tools like kubectl for cluster-internal tasks like deploying applications. This means that if you're already familiar with deploying workloads on another Kubernetes implementation, deploying workloads on GKE should involve many of the same workflows (if you're not already familiar with deploying workloads on Kubernetes, see Deployments and the other resources in Start learning about Kubernetes).

However, GKE also provides additional features for deploying and managing your workloads, including observability tools, fully-managed database options for stateful applications, and specific hardware options for special workload types, including AI/ML workloads.

This page provides a quick overview for developers and administrators who want to deploy workloads on GKE clusters, with links to some more detailed documentation. You can find many more specific guides and tutorials in the Deploy... sections of the GKE core documentation.

Before you read this page, you should be familiar with the following:

Required roles

If you are not a project owner, you must have the following Identity and Access Management (IAM) role at minimum to deploy workloads:

  • Kubernetes Engine Cluster Viewer (roles/container.clusterViewer): This provides the container.clusters.get permission, which is required to authenticate to clusters in a Google Cloud project. This does not authorize you to perform any actions inside those clusters. Your cluster administrator can authorize you to perform other actions on the cluster by using either IAM or Kubernetes RBAC.

    For details about all the permissions included in this role, or to grant a role with read/write permissions, see Kubernetes Engine roles in the IAM documentation.

You can learn more about how access control works in GKE in Access control.

Stateless applications

Stateless applications are applications which don't store data or application state to the cluster or to persistent storage. Stateless applications can be deployed directly from the Workloads menu in the Google Cloud console as well as by using the Kubernetes API. You can learn how to deploy a stateless Linux application on GKE in Deploying a stateless Linux application. If you prefer, you can also learn how to deploy a stateless Windows Server application.

Stateful applications and storage

Applications that need to save data that exists beyond the lifetime of their Pod are known as stateful applications. You or your administrator can use a Kubernetes PersistentVolume object to provision this storage. In GKE, PersistentVolume storage is backed by Compute Engine disks. You can learn how to deploy a simple stateful application on GKE in Deploying a stateful application.

If you need your stateful application's data to persist in a database rather than storage that is tied to the lifetime of a cluster, GKE offers the following options:

  • Fully-managed databases: A managed database, such as Cloud SQL or Spanner, provides reduced operational overhead and is optimized for Google Cloud infrastructure. Managed databases require less effort to maintain and operate than a database that you deploy directly in Kubernetes.
  • Kubernetes application: You can deploy and run a database instance (such as MySQL or PostgreSQL) on a GKE cluster.

You can learn much more about data options in GKE in Data on GKE and Plan your database deployments on GKE.

AI/ML workloads

GKE has rich support for deploying AI/ML workloads. This includes support for training and serving models on specialist hardware, as well as flexible integration with distributed computing and data-processing frameworks. You can start learning more in the following guides:

  • About TPUs in GKE introduces you to using Cloud TPU accelerators for AI/ML workloads in GKE. GKE provides full support for TPU node and node pool lifecycle management, including creating, configuring, and deleting TPU VMs. You can deploy TPU workloads on both Standard and Autopilot clusters.
  • About GPUs in GKE explains how to request and use GPU hardware with GKE workloads.

Workloads with other special requirements

GKE provides features and guides to help you deploy workloads with other special requirements, including applications that require particular node architectures, or that need their Pods to run on the same or separate nodes. You can learn more about deploying some of these in the following guides:

  • Compute classes in Autopilot explains how you can pick specific compute architectures for scheduling your Pods when deploying applications on Autopilot clusters. For Standard clusters, you can directly specify the machine family you want to use for your nodes when creating a cluster.
  • About custom compute classes describes how to create custom compute classes for even greater flexibility when specifying hardware options for your applications on both Autopilot and Standard clusters.
  • Configure workload separation in GKE tells you how to ensure that your application's Pods run on the same or different underlying machines.
  • GKE Sandbox explains how to protect your host kernel by using sandbox Pods when you deploy unknown or untrusted workloads.

Observing your workloads

GKE provides a range of features for observing your workloads and their health, including at-a-glance overviews of workload state and metrics in the Google Cloud console, as well as more in-depth metrics, logs, and alerting.

Managing workload deployment

If you or your administrator want to set up a continuous integration and delivery (CI/CD) pipeline for deploying your workloads, you can find GKE-specific best practices and guidelines for CI/CD in Best practices for continuous integration and delivery to GKE, as well as tutorials for setting up CI/CD pipelines with specific tools and products.

What's next