sections in this doc
Note: This page assumes that you’ve experimented with Kubernetes before. At this point, you should have basic experience interacting with a Kubernetes cluster (locally with Minikube, or elsewhere), and using API objects like Deployments to run your applications.

If not, you should review the Beginner App Developer topics first.

After checking out the current page and its linked sections, you should have a better understanding of the following:

  • Additional Kubernetes workload patterns, beyond Deployments
  • What it takes to make a Kubernetes application production-ready
  • Community tools that can improve your development workflow

Learn additional workload patterns

As your Kubernetes use cases become more complex, you may find it helpful to familiarize yourself with more of the toolkit that Kubernetes provides. Basic workload objects like DeploymentsAn API object that manages a replicated application. make it straightforward to run, update, and scale applications, but they are not ideal for every scenario.

The following API objects provide functionality for additional workload types, whether they are persistent or terminating.

Persistent workloads

Like Deployments, these API objects run indefinitely on a cluster until they are manually terminated. They are best for long-running applications.

Terminating workloads

In contrast to Deployments, these API objects are finite. They stop once the specified number of Pods have completed successfully.

Other resources

For more info, you can check out a list of additional Kubernetes resource types as well as the API reference docs.

There may be additional features not mentioned here that you may find useful, which are covered in the full Kubernetes documentation.

Deploy a production-ready workload

The beginner tutorials on this site, such as the Guestbook app, are geared towards getting workloads up and running on your cluster. This prototyping is great for building your intuition around Kubernetes! However, in order to reliably and securely promote your workloads to production, you need to follow some additional best practices.

Declarative configuration

You are likely interacting with your Kubernetes cluster via kubectlA command line tool for communicating with a Kubernetes API server. . kubectl can be used to debug the current state of your cluster (such as checking the number of nodes), or to modify live Kubernetes objects (such as updating a workload’s replica count with kubectl scale).

When using kubectl to update your Kubernetes objects, it’s important to be aware that different commands correspond to different approaches:

There are pros and cons to each approach, though the declarative approach (such as kubectl apply -f) may be most helpful in production. With this approach, you rely on local YAML files as the source of truth about your desired state. This enables you to version control your configuration, which is helpful for code reviews and audit tracking.

For additional configuration best practices, familiarize yourself with this guide.


You may be familiar with the principle of least privilege—if you are too generous with permissions when writing or using software, the negative effects of a compromise can escalate out of control. Would you be cautious handing out sudo privileges to software on your OS? If so, you should be just as careful when granting your workload permissions to the Kubernetes APIThe application that serves Kubernetes functionality through a RESTful interface and stores the state of the cluster. server! The API server is the gateway for your cluster’s source of truth; it provides endpoints to read or modify cluster state.

You (or your cluster operatorA person who configures, controls, and monitors clusters. ) can lock down API access with the following:

For even more comprehensive reading about security best practices, consider checking out the following topics:

  • Authentication (Is the user who they say they are?)
  • Authorization (Does the user actually have permissions to do what they’re asking?)

Resource isolation and management

If your workloads are operating in a multi-tenant environment with multiple teams or projects, your container(s) are not necessarily running alone on their node(s). They are sharing node resources with other containers which you do not own.

Even if your cluster operator is managing the cluster on your behalf, it is helpful to be aware of the following:

This list may not be completely comprehensive, but many teams have existing processes that take care of all this. If this is not the case, you’ll find the Kubernetes documentation fairly rich in detail.

Improve your dev workflow with tooling

As an app developer, you’ll likely encounter the following tools in your workflow.


kubectl is a command-line tool that allows you to easily read or modify your Kubernetes cluster. It provides convenient, short commands for common operations like scaling app instances and getting node info. How does kubectl do this? It’s basically just a user-friendly wrapper for making API requests. It’s written using client-go, the Go library for the Kubernetes API.

To learn about the most commonly used kubectl commands, check out the kubectl cheatsheet. It explains topics such as the following:

For the full list of kubectl commands and their options, check out the reference guide.


To leverage pre-packaged configurations from the community, you can use Helm chartsA package of pre-configured Kubernetes resources that can be managed with the Helm tool. .

Helm charts package up YAML configurations for specific apps like Jenkins and Postgres. You can then install and run these apps on your cluster with minimal extra configuration. This approach makes the most sense for “off-the-shelf” components which do not require much custom implementation logic.

For writing your own Kubernetes app configurations, there is a thriving ecosystem of tools that you may find useful.

Explore additional resources


Now that you’re fairly familiar with Kubernetes, you may find it useful to browse the following reference pages. Doing so provides a high level view of what other features may exist:

In addition, the Kubernetes Blog often has helpful posts on Kubernetes design patterns and case studies.

What’s next

If you feel fairly comfortable with the topics on this page and want to learn more, check out the following user journeys: