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
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.
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 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 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
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:
kubectl, the Kubernetes command-line tool installed with gcloud CLI
- GKE Workloads menu in the Google Cloud console
- The GKE REST API and the Kubernetes API.
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
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,
runcreates a Deployment object.
runalso 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
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
to create and updates objects declaratively.
objects by reading the whole live object, calculating the differences, then
merging those differences by sending patch requests to the API server.
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.
You can use the GKE REST API and Kubernetes API alongside the Google Cloud Client Libraries to programmatically create and manage workloads.
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
To inspect the live configuration of a deployed object, perform the following steps:
Go to the Workloads page in the Google Cloud console.
Select the desired workload.
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
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
to limit resource consumption within specific namespaces.
GKE also applies a default immutable
object to namespaces on clusters
with 100 nodes or fewer to prevent instability.
- Learn more about deploying stateless applications.
- Learn more about deploying stateful applications.
- Learn about scaling applications.
- Read about the cluster architecture.
- Learn more about managed continuous delivery using Google Cloud Deploy.