Overview of deploying workloads

To deploy and manage your containerized applications and other workloads on your Google Kubernetes Engine (GKE) cluster, you use the Kubernetes system to create Kubernetes controller objects. These controller objects represent the applications, daemons, and batch jobs running on your clusters.

You can create these controller objects using the Kubernetes API or by using kubectl, a command-line interface to Kubernetes installed by gcloud. Typically, you build a representation of your desired Kubernetes controller object as a YAML configuration file, and then use that file with the Kubernetes API or the kubectl command-line interface.

Types of workloads

Kubernetes provides different kinds of controller objects that correspond to different kinds of workloads you can run. Certain controller objects are better suited to representing specific types of workloads. The following sections describe some common types of workloads and the Kubernetes controller objects you can create to run them on your cluster, including:

  • Stateless applications
  • Stateful applications
  • Batch jobs
  • Daemons

Stateless applications

A stateless application does not preserve its state and saves no data to persistent storage — all user and session data stays with the client.

Some examples of stateless applications include web frontends like Nginx, web servers like Apache Tomcat, and other web applications.

You can create a Kubernetes Deployment to deploy a stateless application on your cluster. Pods created by Deployments are not unique and do not preserve their state, which makes scaling and updating stateless applications easier.

Stateful applications

A stateful application requires that its state be saved or persistent. Stateful applications use persistent storage, such as persistent volumes, to save data for use by the server or by other users.

Examples of stateful applications include databases like MongoDB and message queues like Apache ZooKeeper.

You can create a Kubernetes StatefulSet to deploy a stateful application. Pods created by StatefulSets have unique identifiers and can be updated in an ordered, safe way.

Batch jobs

Batch jobs represent finite, independent, and often parallel tasks which run to their completion. Some examples of batch jobs include automatic or scheduled tasks like sending emails, rendering video, and performing expensive computations.

You can create a Kubernetes Job to execute and manage a batch task on your cluster. You can specify the number of Pods that should complete their tasks before the Job is complete, as well as the maximum number of Pods that should run in parallel.

Daemons

Daemons perform ongoing background tasks in their assigned nodes without the need for user intervention. Examples of daemons include log collectors like Fluentd and monitoring services.

You can create a Kubernetes DaemonSet to deploy a daemon on your cluster. DaemonSets create one Pod per node, and you can choose a specific node to which the DaemonSet should deploy.

DaemonSets on GKE Autopilot

GKE administers nodes in clusters that you create using the Autopilot mode of operation. You cannot manually add, remove, or modify the nodes or the underlying Compute Engine virtual machines (VMs). However, the Kubernetes node object is still visible, and Autopilot supports DaemonSets as your workloads.

GKE Autopilot limits some administrative functions that affect all workload Pods, including Pods managed by DaemonSets. DaemonSets that perform administrative functions on nodes using elevated privileges, such as the privileged security context, won't run on Autopilot clusters unless explicitly allowed by GKE.

For more information on the limits enforced by Autopilot, see Workload limitations and restrictions. You can use DaemonSets with workloads that meet the restrictions set by Autopilot, as well as DaemonSets from some Google Cloud partners.

Best practices for DaemonSets on Autopilot

GKE uses the total size of your deployed workloads to determine the size of the nodes that Autopilot provisions for the cluster. If you add or resize a DaemonSet after Autopilot provisions a node, GKE won't resize existing nodes to accommodate the new total workload size. DaemonSets with resource requests larger than the allocatable capacity of existing nodes, after accounting for system pods, also won't get scheduled on those nodes.

We recommend the following best practices when deploying DaemonSets on Autopilot:

  • Deploy DaemonSets before any other workloads.
  • Set a higher PriorityClass on DaemonSets than regular Pods. The higher PriorityClass lets GKE evict lower-priority Pods to accommodate DaemonSet pods if the node can accommodate those pods. This helps to ensure that the DaemonSet is present on each node.
  • To ensure DaemonSet presence on your nodes, keep your CPU resource requests for DaemonSets to 250m or less. Larger DaemonSets, especially those that are larger than your regular Pods, might not fit on every node.

Managing workload objects

You can create, manage, and delete objects using imperative and declarative methods. The following sections describe these methods as well as the following tools you can use to employ them:

Imperative commands

Imperative commands allow you to quickly create, view, update, and delete objects with kubectl. These commands are useful for one-off tasks or for making changes to active objects in a cluster. Imperative commands are commonly used to operate on live, deployed objects on your cluster.

kubectl features several verb-driven commands for creating and editing Kubernetes objects. For example:

  • run: Generate a new object in the cluster. Unless otherwise specified, run creates a Deployment object. run also supports several other generators.
  • expose: Create a new Service object to load balance traffic across a set of labelled Pods.
  • autoscale: Create a new Autoscaler object to automatically horizontally scale a controller object, such as a Deployment.

Imperative commands do not require strong understanding of object schema and do not require configuration files.

Imperative object configuration

Imperative object configuration creates, updates, and deletes objects using configuration files containing fully-defined object definitions. You can store object configuration files in source control systems and audit changes more easily than with imperative commands.

You can run kubectl apply, delete, and replace operations with configuration files or directories containing configuration files.

Declarative object configuration

Declarative object configuration operates on locally-stored configuration files but does not require explicit definition of the operations to be executed. Instead, operations are automatically detected per-object by kubectl. This is useful if you are working with a directory of configuration files with many different operations. Declarative object management requires a strong understanding of object schemas and configuration files.

You can run kubectl apply to create and updates objects declaratively. apply updates objects by reading the whole live object, calculating the differences, then merging those differences by sending patch requests to the API server.

Console

After you have deployed a workload using kubectl or the API, you can use the GKE Workloads menu in the Google Cloud console to inspect, manage, and edit workloads running on your clusters.

The menu offers the following features:

  • You can use the YAML-based text editor to edit live objects from your web browser
  • You can view detailed information about objects, including revision history, recent events and activities, and its managed Pods
  • You can easily scale Deployments, Jobs, and StatefulSets
  • You can autoscale, trigger rolling updates, and manually scale Deployments from the Actions menu.
  • You can use Cloud Shell to inspect, edit, and delete any object.

API

You can use the GKE REST API and Kubernetes API alongside the Google Cloud Client Libraries to programmatically create and manage workloads.

Configuration files

When you deploy a workload using any of the methods previously described, GKE adds a configuration file to your cluster that represents the object.

An object's live configuration might differ from its local file. YAML is most commonly used to create and represent Kubernetes objects. You can also use JSON.

To learn more about Kubernetes object specifications, statuses, and the Kubernetes API, refer to Understanding Kubernetes Objects and the Kubernetes API reference.

Inspecting live configurations

Console

To inspect the live configuration of a deployed object, perform the following steps:

  1. Go to the Workloads page in the Google Cloud console.

    Go to Workloads

  2. Select the desired workload.

  3. Click YAML.

gcloud

To inspect the live configuration of a deployed object, run the following command:

kubectl get [OBJECT_TYPE] [OBJECT_NAME] -o yaml

[OBJECT_TYPE] might be deployment, statefulset, job, or other object type. For example:

kubectl get deployment my-stateless-app -o yaml

Managing resource usage with quotas

When many users or teams share the resources in your cluster, there's a concern that some could use more than their fair share. You can use the Kubernetes ResourceQuota object to limit resource consumption within specific namespaces.

GKE also applies a default immutable gke-resource-quotas object to namespaces on clusters with 100 nodes or fewer to prevent instability.

What's next