Originally reported by The Register. Original publication date: February 2020.
Overview
Google introduced Application Manager for Google Kubernetes Engine (GKE) as a beta feature aimed at simplifying GitOps workflows for Kubernetes deployments. The tool, centered around a component Google calls Application Delivery, is designed to attract developers who want code-oriented, repository-driven deployment automation without stitching together multiple third-party tools.
What Is GitOps?
GitOps is an operational model in which the desired state of infrastructure and application deployments is stored declaratively in a Git repository, alongside application source code. Key principles include:
- Declarative configuration: Infrastructure requirements are described in version-controlled files, typically YAML.
- Pull-request-driven changes: Any change to infrastructure or configuration goes through a standard Git review and merge process.
- Automated reconciliation: A controller or agent continuously ensures the live environment matches the state described in the repository.
- Full audit trail: Git history provides a complete, tamper-evident record of every change.
GitOps has become increasingly popular for Kubernetes environments because Kubernetes itself is API-driven and configuration is naturally expressed in YAML manifests, making it a natural fit for repository-based management.
How Google’s Application Manager Works
Application Manager runs as an add-on inside a GKE cluster and is controlled through a command-line interface invoked with the appctl binary. Here is the general workflow:
1. Repository Setup
Repositories must be hosted on either GitHub or GitLab. After installing Application Manager into a GKE cluster, developers initialize their project with appctl, which provisions two default repositories:
- One for application source code
- One for deployment configuration
Separating configuration from code is a common GitOps best practice, as it allows deployment state to evolve independently of the application’s release cycle.
2. Defining Kubernetes Configuration with Kustomize
Developers describe their Kubernetes deployment requirements in YAML using a Kustomize configuration. Kustomize is a Kubernetes-native configuration management tool that allows base manifests to be patched for different environments (e.g., staging vs. production) without duplicating YAML files.
3. Adding Environments
Using appctl commands, developers register named environments such as testing, staging, and production. Each environment maps to a distinct Kubernetes namespace or cluster target, and the configuration for each is tracked in the deployment repository.
4. Preparing and Reviewing a Release
When a developer is ready to deploy, they run:
appctl prepareThis command tags the application version and automatically opens a pull request in the configuration repository. The team can review infrastructure and configuration changes exactly as they would review code changes. This is the core GitOps loop: changes are proposed, reviewed, and approved before anything reaches the cluster.
5. Applying the Deployment
Once the pull request is approved and merged, the developer runs:
appctl applyThis creates or updates the target environment and deploys the application to the GKE cluster according to the approved configuration.
6. Promoting and Rolling Back
appctl prepare can also be used to promote a verified deployment from one environment to another — for example, from staging to production. Rollbacks are also supported, leveraging Git history to revert to a previously known-good state.
Observability and the Google Cloud Console
Application Manager surfaces deployment metadata in the Google Cloud Console, including:
- Current deployed version
- Revision history
- Application health status
This gives teams a consolidated view of deployment state without needing to query the cluster directly or consult the Git log manually.
Google Cloud Marketplace Integration
Google also designed Application Manager with third-party applications in mind. Applications installed from the Google Cloud Marketplace could potentially use Application Manager for version updates, allowing cluster operators to trigger upgrades of marketplace applications directly from the Cloud Console with an Update button, rather than performing manual Helm or kubectl operations.
CI/CD Pipeline Integration
Application Manager is designed to complement existing CI/CD tooling rather than replace it. It is intended to integrate with:
- Jenkins — a widely used open-source CI/CD server
- Tekton Pipelines — a Kubernetes-native CI/CD framework that Google has contributed to and champions
For teams that want a leaner setup, Application Manager also provides a self-contained GitOps workflow without requiring additional orchestration tools.
Limitations to Be Aware Of
Application Manager simplifies the automation of Kubernetes deployments, but it does not simplify the design of those deployments. Teams still need to:
- Understand Kubernetes resource types (Deployments, Services, Ingress, etc.)
- Write correct and appropriately scoped YAML manifests
- Configure Kustomize overlays for each environment
- Manage secrets and RBAC policies separately
The tool assumes you already know what to deploy; it automates how that deployment is tracked, reviewed, and executed.
Strategic Significance for Google Cloud
Developer experience is a key competitive differentiator among major cloud providers. By reducing friction in the GitOps setup for GKE, Google is lowering the barrier for development teams to adopt repeatable, auditable deployment practices on its platform. For organizations already invested in GitHub or GitLab and Kubernetes, Application Manager offers a tightly integrated path to GitOps without requiring teams to evaluate and integrate standalone tools such as Argo CD or Flux independently.
Whether Application Manager has matured significantly since its 2020 beta launch, or whether Google has evolved its GitOps strategy (for example, through Config Sync or other GKE features), warrants a check against current Google Cloud documentation before making adoption decisions.