Autopilot Standard
To deploy and manage your containerized applications and other workloads on yourGoogle Kubernetes Engine (GKE) cluster, you use the Kubernetes system to createKubernetes controller objects. These controller objects represent theapplications, daemons, and batch jobs running on your clusters.
You can create these controller objects using the Kubernetes API or by usingkubectl, a command-line interface to Kubernetes installed bygcloud. Typically, you build a representation of yourdesired Kubernetes controller object as a YAML configuration file, and then usethat file with the Kubernetes API or the kubectl command-line interface.
Types of workloads
Kubernetes provides different kinds of controller objects that correspond todifferent kinds of workloads you can run. Certain controller objects are bettersuited to representing specific types of workloads. The following sectionsdescribe some common types of workloads and the Kubernetes controller objectsyou 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 nodata to persistent storage — all user and session data stays with the client.
Some examples of stateless applications include web frontends likeNginx, web servers likeApache Tomcat, and other web applications.
You can create a KubernetesDeployment to deploy a stateless application onyour cluster. Pods created by Deployments are not unique and do not preservetheir state, which makes scaling and updating stateless applications easier.
Stateful applications
A stateful application requires that its state be saved orpersistent. Stateful applications use persistent storage, such aspersistent volumes, to save data for use by the server or by other users.
Examples of stateful applications include databases likeMongoDB and message queues likeApache ZooKeeper.
You can create a Kubernetes StatefulSet to deploy a stateful application. Pods created by StatefulSets have uniqueidentifiers and can be updated in an ordered, safe way.
Batch jobs
Batch jobs represent finite, independent, and often parallel tasks which runto their completion. Some examples of batch jobs include automatic or scheduledtasks like sending emails, rendering video, and performing expensivecomputations.
You can create a Kubernetes Job to execute and manage a batch task on yourcluster. You can specify the number of Pods that should complete their tasksbefore the Job is complete, as well as the maximum number of Pods that shouldrun in parallel.
Daemons
Daemons perform ongoing background tasks in their assigned nodes without theneed for user intervention. Examples of daemons include log collectors likeFluentd and monitoring services.
You can create a Kubernetes DaemonSet todeploy a daemon on your cluster. DaemonSets create one Pod per node, and you canchoose a specific node to which the DaemonSet should deploy.
DaemonSets on GKE Autopilot
GKE administers nodes in clusters that you create using theAutopilot mode of operation.You cannot manually add, remove, or modify the nodes or the underlyingCompute Engine virtual machines (VMs). However, the Kubernetes node object isstill visible, and Autopilot supports DaemonSets as your workloads.
GKE Autopilot limits some administrative functions thataffect all workload Pods, including Pods managed by DaemonSets. DaemonSetsthat perform administrative functions on nodes using elevated privileges, suchas the privileged security context, won't run on Autopilot clustersunless explicitly allowed by GKE.
For more information on the limits enforced by Autopilot, seeWorkload 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 determinethe size of the nodes that Autopilot provisions for the cluster. If youadd or resize a DaemonSet after Autopilot provisions a node,GKE won't resize existing nodes to accommodate the new totalworkload size. DaemonSets with resource requests larger than the allocatablecapacity of existing nodes, after accounting for system pods, also won't getscheduled on those nodes.
Starting in GKE version 1.27.6-gke.1248000, clusters inAutopilot mode detect nodes that can't fit all DaemonSets and, overtime, migrate workloads to larger nodes that can fit all DaemonSets. Thisprocess takes some time, especially if the nodes run system Pods, which needextra time to gracefully terminate so that there's no disruption to core clustercapabilities.
In GKE version 1.27.5-gke.200 or earlier, we recommendcordoning anddraining nodes that can't accommodate DaemonSet Pods.
For all GKE versions, we recommend the following best practices when deploying DaemonSets on Autopilot:
- Deploy DaemonSets before any other workloads.
- Set a higherPriorityClass on DaemonSets than regular Pods. The higher PriorityClass letsGKE evict lower-priority Pods to accommodate DaemonSet podsif the node can accommodate those pods. This helps to ensure that theDaemonSet is present on each node without triggering node recreation.
Managing workload objects
You can create, manage, and delete objects using imperative anddeclarative methods. The following sections describe these methods as well asthe 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
Imperative commands allow you to quicklycreate, view, update, and delete objects with kubectl. These commands areuseful 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 onyour cluster.
kubectl features several verb-driven commands for creating and editingKubernetes objects. For example:
run:Generate a new object in the cluster. Unless otherwise specified,runcreates a Deployment object.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 acontroller object, such as a Deployment.
Imperative commands do not require strong understanding of object schema and donot require configuration files.
Imperative object configuration
Imperative object configuration creates, updates, and deletes objects using configuration files containingfully-defined object definitions. You can store object configuration files insource control systems and audit changes more easily than with imperativecommands.
You can run kubectl apply,delete, andreplace operations with configuration files ordirectories containing configuration files.
Declarative object configuration
Declarative object configuration operates onlocally-stored configuration files but does not require explicitdefinition of the operations to be executed. Instead, operations areautomatically detected per-object by kubectl. This is useful if you areworking with a directory of configuration files with many different operations.Declarative object management requires a strong understanding of objectschemas and configuration files.
You can run kubectl apply to create and updates objects declaratively. apply updatesobjects by reading the whole live object, calculating the differences, thenmerging those differences by sending patch requests to the API server.
Public Docker Hub images
When you deploy a public container image from Docker Hub, GKEautomatically checks the caching proxy mirror.gcr.io for a cached copyof the container image. If a cached copy is unavailable, GKEpulls your requested image from Docker Hub and the caching proxy might cachethe image for future use. For more information, seePulling cached images.
Console
After you have deployed a workload using kubectl or the API, you can use theGKE Workloads menu in the Google Cloud consoleto 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 webbrowser
- 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 Deploymentsfrom the Actions menu.
- You can use Cloud Shell to inspect, edit, and delete anyobject.
API
You can use the GKE REST API andKubernetes API alongside theGoogle Cloud Client Librariesto 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 representsthe object.
An object's live configuration might differ from its local file.YAML is most commonly used to create and representKubernetes objects. You can also use JSON.
To learn more about Kubernetes object specifications, statuses, and the KubernetesAPI, refer to Understanding Kubernetes Objects andthe Kubernetes API reference.
Inspecting live configurations
Console
To inspect the live configuration of a deployed object, perform thefollowing steps:
Go to the Workloads page in the Google Cloud console.
Go to Workloads
Select the desired workload.
Click YAML.
gcloud
To inspect the live configuration of a deployed object, run the followingcommand:
kubectl get [OBJECT_TYPE] [OBJECT_NAME] -o yaml
[OBJECT_TYPE] might be deployment, statefulset, job, or other objecttype. 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 concernthat some could use more than their fair share. You can use the KubernetesResourceQuota object to limit resource consumption within specific namespaces.
GKE also applies a default immutable gke-resource-quotasobject to namespaces on clusterswith 100 nodes or fewer to prevent instability.
Use GitLab to deploy to GKE
If you use GitLab for continuous integration, you can use theGitLab GKE componentto deploy your workload to a GKE cluster.
You can also try the end-to-end tutorialfor using GitLab with Google Cloud.
For more information, see the GitLab on Google Cloud overview.
What's next
- 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 Cloud Deploy.
