Want to level up your Kubernetes knowledge? Explore our tutorials and step-by-step guides written by Kubernetes experts. Learn Kubernetes best practices and solutions to the most difficult problems.

Kubernetes Guides and Tutorials | Spacelift Blog

Author title

Title category

Get all the latest content on Infrastructure as Code, DevOps, Spacelift features & news directly to your inbox!

Level up your IaC knowledge. Stay up to date with educational devops guides & news in infrastructure as code, cloud & more!

Managing Infrastructure at Scale | Spacelift Blog

Transform your IaC management to scale
securely, efficiently, and productively
into the future.

Blog

What Are Terraform Modules and How to Use Them: Tutorial

Terraform Functions, Expressions, Loops (Examples)

Managing Terraform State - Best Practices & Examples

Terraform For Loop - Expression Overview with Examples

What is Terraform? What is it Used For, How it Works

44 Ansible Best Practices to Follow [Tips & Tricks]

How to Stop and Remove Docker Containers

How to Create a CI/CD Pipeline with Docker [Tutorial]

CI/CD Pipeline : Everything You Need To Know

Kubernetes CI/CD Pipelines - 7 Best Practices and Tools

How to Deploy Infrastructure in CI/CD Using Terraform (Pipeline)

Terraform with Azure DevOps CI/CD Pipelines - Tutorial

Terragrunt Tutorial - Getting Started & Examples

Pulumi Pricing – Editions Overview 2024

73 Most Useful DevOps Tools to Use in 2024

Top 10 Terraform Enterprise Alternatives for 2024

Terraform Cloud/Enterprise Pricing - Tiers Overview 2024

16 Most Useful Infrastructure as Code (IaC) Tools for 2024

Terraform Cheat Sheet - 23 Terraform CLI Commands & Examples

ebook-global-banner

ebook global banner

Why Spacelift

How it works

Integrations

Product

Solutions

Scale your infrastructure safely and efficiently with an end-to-end workflow

productivity

Productivity

productivity-2

IaC at Scale

Standardize and control infrastructure provisioning and configuration

cicd

CICD

cicd-2

Infrastructure Governance

Implement and automate secure, collaborative workflows

team

Team

team-2

Collaboration

Make it easy for developers to provision and configure with a single workflow

speed-2

Speed

speed-3

Developer Velocity

By Initiative

CI/CD for Infrastructure

Drift Detection

Achieve Terraform at Scale

OpenTofu Migration

By Use Case

Request a meeting

Enjoy an action-packed day at AWS Summit London 2024, where the latest in cloud innovation comes to life.

ebook-pic

Practitioner’s Guide to Scaling IaC

Check out the Practitioner's Guide to Scaling IaC

Docs

Pricing

Resources

Learn more about Spacelift and infrastructure best practices

blog

blog-2

partners

Partners

partners-2

events

Events

events-2

Insights and quick guides to get you started

cheatsheets

Cheatsheets

cheatsheets-3

Ebooks & Cheatsheets

users

Users

users-2

Case studies

33-what-makes-spacelift-secure

What Makes Spacelift Secure

About Us

Contact Us

About

cheatsheets-2

Test

See more

Test webinar name

applepodcasts

spotify

missionctrl

Welcome to missionCTRL, a show dedicated to exploring the frontiers of modern DevOps. Listen (or watch) as we sit down with the practitioners who are pushing the boundaries of development

Kubernetes

Want to level up your Terraform knowledge? Explore our tutorials and step-by-step guides written by Terraform experts. Learn Terraform best practices and solutions to the most difficult problems.

Terraform Guides and Tutorials | Spacelift Blog

Terraform

Ioannis Moustakis

Flavius Dinu

This article will compare two of the most dominant tools in the cloud infrastructure space, Terraform and Kubernetes. These two tools share some similarities but are built to serve different purposes. Terraform is a tool focused on infrastructure provisioning and operates in the Infrastructure as code space. Kubernetes focuses on running container workloads and operates in the container orchestration space.
We will briefly take a look at each one of them and discuss their similarities and differences.
To learn more about these two foundational cloud infrastructure technologies, check the multiple tutorials on Spacelift’s blog around <a href="https://spacelift.io/blog/kubernetes" target="_blank" rel="noopener" data-saferedirecturl="https://www.google.com/url?q=https://spacelift.io/blog/kubernetes&amp;source=gmail&amp;ust=1661233733361000&amp;usg=AOvVaw0U55gyVSYyB8fmHIbefmpF">Kubernetes</a> and <a href="https://spacelift.io/blog/terraform" target="_blank" rel="noopener" data-saferedirecturl="https://www.google.com/url?q=https://spacelift.io/blog/terraform&amp;source=gmail&amp;ust=1661233733361000&amp;usg=AOvVaw3AGtv2eOlNveyd8H80rYk_">Terraform</a>.

<a href="https://spacelift.io/blog/what-is-terraform" target="_blank" rel="noopener">Terraform</a> is a tool that allows us to safely and predictably manage infrastructure at scale using cloud-agnostic and infrastructure as code principles. It is a powerful tool developed by Hashicorp that enables infrastructure provisioning both on the cloud and on-premises. 
Terraform is written in a declarative configuration language, Hashicorp Configuration Language (HCL), and facilitates the automation of infrastructure management in any environment. It allows IT professionals to collaborate and perform changes safely on cloud environments and scale them on-demand according to the business needs. 
<a href="https://spacelift.io/blog/what-are-terraform-modules-and-how-do-they-work" target="_blank" rel="noopener">Modules</a> provide excellent reusability and code-sharing opportunities to boost the collaboration and productivity of teams operating on the cloud. <a href="https://spacelift.io/blog/terraform-providers" target="_blank" rel="noopener">Providers</a> are plugins that offer integration and interaction with different APIs and are one of the main ways to extend Terraform’s functionality. 
Terraform keeps an internal <a href="https://www.terraform.io/language/state" target="_blank" rel="nofollow noopener">state</a> of the managed infrastructure, which represents resources, configuration, metadata, and their relationships. The state is actively maintained by Terraform and utilized to create plans, track changes, and enable modifications of infrastructure environments. The state should be stored remotely to allow teamwork and collaboration as a best practice. 
The core Terraform workflow consists of three concrete stages. First, we generate the infrastructure as code configuration files representing our environment&#8217;s desired state. Next, we check the output of the generated plan based on our manifests. After carefully reviewing the changes, we apply the plan to provision infrastructure resources.

terraform-vs-kubernetes-terraform-workflow

terraform vs kubernetes - terraform workflow

Note: New versions of Terraform are placed under the BUSL license, but everything created before version 1.5.x stays open-source. <a href="https://opentofu.org/" target="_blank" rel="nofollow noopener">OpenTofu</a> is an open-source version of Terraform that expands on Terraform’s existing concepts and offerings. It is a viable alternative to HashiCorp’s Terraform, being forked from Terraform version 1.5.6.

<a href="https://spacelift.io/blog/kubernetes-tutorial" target="_blank" rel="noopener">Kubernetes</a> (K8s) is an open-source system for container orchestration, automating deployments, and managing containerized apps. Its powerful orchestration system enables applications to scale seamlessly and achieve high availability. It has been designed and developed by Google, leveraging its vast experience in running and maintaining critical workloads in production.
Kubernetes strives to be cloud agnostic at its core, providing great flexibility in running workloads across cloud and on-premises environments. Additionally, it is designed with extensibility in mind, providing the option to add features and custom tooling to clusters easily.  
One of its main benefits is the self-healing capabilities it provides. Containers that fail are automatically restarted and rescheduled, nodes can be configured to be automatically replaced, and traffic is served only by healthy components based on health checks.  
Rollouts are handled progressively, and Kubernetes provides smart mechanisms to monitor application health during deployments. Rolling back problematic changes happens automatically if the application health doesn’t report a healthy status after a new deployment. Keeping the application running while rolling out new software versions has been a hot topic in the Kubernetes ecosystem over the past years, with many possible deployment strategies.
Kubernetes handles service discovery and load-balances traffic between similar pods natively without the need for complex external solutions. It has extendable built-in mechanisms to manage configuration and secrets for your applications. Scaling your applications has never been easier since it provides autoscaling options, scaling through commands, or via a UI. 
Kubernetes provides a cluster of nodes, a group of worker machines that run containerized applications. Each node hosts pods that hold application workload containers. The brain of the whole system is the control plane. Each cluster consists of several components that manage the worker nodes and pods and guarantee operational continuity. 
The API server is the component exposing the Kubernetes API and operates as the front-end of the control plane by handling all the communication between other parts. The etcd component is used to store all cluster data and state. The scheduler manages how pods are assigned to nodes and takes all the workload scheduling decisions. The controller manager components run different controller processes to ensure that the cluster&#8217;s desired state matches its current state. The cloud controller manager integrates Kubernetes clusters with external cloud providers, embeds their logic, and links the Kubernetes API with the Cloud Provider’s API. On each node, the kubelet is the agent responsible for running containers in pods, and kube-proxy is the component that adds the necessary networking capabilities for communication between pods and nodes.

terraform-vs-kubernetes-kubernetes-cluster

terraform vs kubernetes - kubernetes cluster

Check out this article to learn more about the <a href="https://spacelift.io/blog/kubernetes-cluster" target="_blank" rel="noopener">Key Kubernetes Cluster Components</a>.

<ul>
<li><a href="https://spacelift.io/blog/terraform-automation" target="_blank" rel="noopener">How to Automate Terraform Deployments</a></li>
<li><a href="https://spacelift.io/blog/provision-kubernetes-cluster-terraform-spacelift" target="_blank" rel="noopener"><span data-sheets-value="{&quot;1&quot;:2,&quot;2&quot;:&quot;How to Provision Kubernetes Cluster with Terraform&quot;}" data-sheets-userformat="{&quot;2&quot;:513,&quot;3&quot;:{&quot;1&quot;:0},&quot;12&quot;:0}">How to Provision Kubernetes Cluster with Terraform</a></li>
<li><a href="https://spacelift.io/blog/5-ways-to-manage-terraform-at-scale" target="_blank" rel="noopener"><span data-sheets-value="{&quot;1&quot;:2,&quot;2&quot;:&quot;5 Ways to Manage Terraform at Scale&quot;}" data-sheets-userformat="{&quot;2&quot;:6723,&quot;3&quot;:{&quot;1&quot;:0},&quot;4&quot;:{&quot;1&quot;:2,&quot;2&quot;:16777215},&quot;9&quot;:0,&quot;12&quot;:0,&quot;14&quot;:{&quot;1&quot;:2,&quot;2&quot;:0},&quot;15&quot;:&quot;Arial&quot;}">5 Ways to Manage Terraform at Scale</a></li>
</ul>

These two modern technologies have many similarities but also fundamental differences. Let’s look into some of them in more detail.
<h3>1) Area of Focus</h3>
First and foremost, Terraform and Kubernetes have different purposes and try to solve different problems. Terraform focuses on provisioning infrastructure components and targets the Infrastructure as Code space. Kubernetes aims to enable us to run container workloads and targets the container orchestration space. 
<h3>2) Configuration Language and CLI</h3>
Manifests in Terraform are written in HCL language, while in Kubernetes in YAML or JSON. Each tool has its own command line utility and tool-specific internals to understand before being productive. 
<h3>3) Tool workflow</h3>
The Terraform workflow is generally considered easy to understand and provides a welcoming experience for new users. On the other hand, to be effective in running applications in Kubernetes, one has to understand a lot of cluster internal components and mechanics, and usually, it takes more time for users to get up to speed with Kubernetes. 
<h3>4) Configuration Drift &amp; Planning Phase</h3>
Terraform provides a native way to detect and inform you about configuration drift and unwanted changes by leveraging the planning phase of the typical workflow. In contrast, Kubernetes doesn’t support this functionality out of the box.

terraform-vs-kubernetes-2

terraform vs kubernetes

<h3>1) DevOps Tools</h3>
Both tools operate in the DevOps space and are typically set up and configured by the same type of IT practitioners; Site Reliability, DevOps, and Cloud engineers. 
<h3>2) Open Source &amp; Cloud Agnostic</h3>
Both tools are open source with various contributions by their online communities. They also take a similar approach to striving to be as cloud, platform, and API agnostic as possible to accommodate workloads across different environments. Even though they try to keep the core of the projects agnostic to external providers, both tools have mature and actively maintained integrations with the most common cloud providers.
<h3>3) Declarative Configuration</h3>
Although they use different languages, Terraform and Kubernetes take a similar approach conceptually to define the configuration. Manifests in both tools are written with the declarative approach. 
<h3>4) State Management</h3>
The notion of the state exists in both tools, although it is implemented differently. Terraform and Kubernetes apply some logic to reconcile the desired state configured in declarative configuration files with the running state.
<h3>5) Extensibility</h3>
Both tools are highly extensible by leveraging external plugins, connecting to external APIs, or defining custom resources if necessary. 
<h3>6) Well-Suited for Scale</h3>
Terraform and Kubernetes are battle-tested technologies that can support huge scale since they are designed and architected with scaling considerations for modern cloud-native environments.
<h3>7) CI/CD Compatibility</h3>
Since both tools offer highly and easily automatable workflows, they can be integrated and combined with CI/CD pipelines to automate their lifecycle.

By decomposing all the information we discussed, we realize that Kubernetes and Terraform complement each other since they operate at two different levels and can be utilized in parallel. 
A typical model that cloud practitioners adopt is to use Terraform to provision infrastructure resources (e.g. Kubernetes clusters) and use Kubernetes to manage the containerized apps that run on top of the clusters. 
Terraform’s approach simplifies and standardizes the complex task of provisioning Kubernetes clusters. Terraform, in this case, enables a unified flow for provisioning Kubernetes clusters across providers with a declarative approach that is preferred over command line utilities. This approach works great, but users must use separate flows to manage infrastructure and application resources. 
Another approach is to use Terraform to manage Kubernetes-specific application components as well. This model has the advantage of adding the Terraform workflow to Kubernetes components. This way, IT operators can detect configuration drift on Kubernetes and manage infrastructure and application resources with the same workflow and configuration language. 
This approach has a significant disadvantage since Terraform requires a well-defined schema for each managed resource. Thus each Kubernetes resource needs to be translated into a Terraform schema to be available. This dependency makes maintaining Kubernetes resources through Terraform cumbersome at times.

Kubernetes Cloud Operators manage, configure, and integrate cloud-specific resources with a Kubernetes cluster. Cloud providers usually develop these operators to facilitate integrations with their respective services.
They facilitate the following use cases:
<ul>
<li>Service Provisioning: You can automatically provision services required by your microservices. For example, if your application requires a database, you can use a k8s operator to provide the service for you.</li>
<li aria-level="1">Secrets Integrations: When you are working with k8s, you will most likely have many configmaps and secrets defined. Sometimes, sharing these secrets on some of your Infrastructure resources can be tricky. By leveraging operators, this becomes easier as you can seamlessly integrate your k8s resources with your secrets management tool.</li>
<li aria-level="1">GitOps workflows: Using operators in the cloud context, can facilitate your GitOps workflow, as you will declare both your infrastructure and the applications in the same way</li>
</ul>
There are a couple of advantages of using Kubernetes Cloud Operator, but there are many downsides to using them too. The downsides are: 

<ul>
<li aria-level="1">Limited service coverage – Terraform providers are always close to supporting absolutely anything that a cloud provider supports due to the extensive work of the community. When it comes to k8s cloud operators, they don’t have such a big community backing them up, and sometimes, for specific services, only some basic operations are available, requiring fallback to other services/methods.</li>
<li aria-level="1">Troubleshooting complexity – Using k8s cloud operators increases the troubleshooting complexity. This happens because you will not only need to troubleshoot your code and the resource you are provisioning but the operator itself too, which will be harder to do.</li>
<li aria-level="1">Learning curve – Terraform is more popular among DevOps engineers than k8s cloud operators are. Managing infrastructure resources via k8s will steepen the learning curve.</li>
<li aria-level="1">Vendor lock-in – By managing your infrastructure with a k8s cloud operator, will tie your infrastructure to a cloud provider and migrating will be harder to do than by using Terraform.</li>
<li aria-level="1">Maturity – Some k8s cloud operators are newer and might not be as stable as tools such as Terraform, Pulumi, or CloudFormation.</li>
</ul>
Some popular Cloud Operators provided by major cloud providers are: 

<ul>
<li style="font-weight: 400;" aria-level="1"><a href="https://aws-controllers-k8s.github.io/community/docs/community/overview/" target="_blank" rel="nofollow noopener">AWS Controllers for Kubernetes (ACK)</a> </li>
<li style="font-weight: 400;" aria-level="1"><a href="https://github.com/Azure/azure-service-operator" target="_blank" rel="nofollow noopener">Azure Service Operator</a></li>
<li style="font-weight: 400;" aria-level="1"><a href="https://cloud.google.com/config-connector/docs/overview" target="_blank" rel="nofollow noopener">GCP Config Connector</a></li>
</ul>

<h3>AWS ACK configuration</h3>
AWS ACK can be deployed on any k8s cluster, and for this example, I will be using an EKS cluster.
<a href="https://aws-controllers-k8s.github.io/community/docs/user-docs/install/" target="_blank" rel="nofollow noopener">The recommended way to install an ACK Service Controller</a> is by using Helm.
I already have the EKS cluster deployed, so the next step would be to deploy the S3 ACK service controller. 
This is done by logging into the ecr public registry, getting the correct helm chart for your service, and running helm install, similar to the commands below:

You can check the status of the controller by running:

Now, ACK is deployed, but we still need to configure it before we are able to use it.
The next step refers to configuring IAM Roles for Service Accounts (IRSA). 
First, ensure you have eksctl installed on your machine. Check out this guide to see how to <a href="https://docs.aws.amazon.com/eks/latest/userguide/eksctl.html" target="_blank" rel="nofollow noopener">install it</a>.
Create an OpenID Connect (OIDC) identity provider for your EKS cluster:

Next, create a bash script based on <a href="https://aws-controllers-k8s.github.io/community/docs/user-docs/irsa/#create-an-iam-role-for-your-ack-service-controller" target="_blank" rel="nofollow noopener">this</a> and run it. This will create an IAM role for your ACK service controller. You will also need to attach an IAM policy to that role. For that, you can create another bash script based on <a href="https://aws-controllers-k8s.github.io/community/docs/user-docs/irsa/#attach-iam-policy-to-the-iam-role" target="_blank" rel="nofollow noopener">this</a> and run it. The policy can be changed to satisfy your needs.
Associate the IAM role you’ve created with the ACK service account like so:

To ensure that everything will work properly, You will also need to create a cluster role and cluster role binding for the leases.

Apply the above configurations to ensure the role and rolebinding are created successfully.
Now, restart your deployment to take all changes into consideration:

<h4>AWS ACK S3 bucket creation</h4>
To generate an S3 bucket, you will just need to define a configuration for it similar to:

Save it to a file and run:

You can head over to your AWS account and see the S3 bucket created.
If you are facing any issues and you don’t see your bucket created in AWS, even though you ran kubectl apply successfully, you will need to check the controller logs to understand what has happened.
<h3>Terraform S3 bucket creation</h3>
The process of installing and using Terraform is pretty straightforward. Simply go <a href="https://developer.hashicorp.com/terraform/downloads?product_intent=terraform" target="_blank" rel="nofollow noopener">here</a> and download the correct Terraform version for your operating system.
The following code will generate an S3 bucket with the name terraform-test-bucket.

You will simply need to run the following commands, and you are good to go:

After you run the apply, your resource will be created if you are not receiving any errors. 
As mentioned above, with k8s operators, even though you are getting a successful result after running kubectl apply, you can still have surprises in your environment. The controller is the source of truth, so that’s the place you will need to look for logs and understand what has happened. 
With Terraform, this is not the case, as if your apply succeeds, your resources will be provisioned successfully, and if you are having any issues, you will see them directly after your apply fails.
As you can see, Kubernetes operators achieve the same thing as Terraform does, but they are hard to deploy, hard to maintain, and you have to do troubleshooting in multiple places. For Terraform, the process is easy, and you won’t get false positives as you can get by using operators.

Spacelift supports both <a href="https://docs.spacelift.io/vendors/terraform/" target="_blank" rel="noopener">Terraform</a> and <a href="https://docs.spacelift.io/vendors/kubernetes/" target="_blank" rel="noopener">Kubernetes</a> and enables users to create <a href="https://docs.spacelift.io/concepts/stack/" target="_blank" rel="noopener">stacks</a> based on them. Leveraging Spacelift, you can build CI/CD pipelines to combine them and get the best of each tool. This way, you will use a single tool to manage your Terraform and Kubernetes resources lifecycle, allow your teams to collaborate easily, and add some necessary security controls to your workflows.
You could, for example, deploy Kubernetes clusters with Terraform stacks and then, on separate Kubernetes stacks, deploy your containerized applications to your clusters. With this approach, you can easily integrate drift detection into your Kubernetes stacks and enable your teams to <a href="https://docs.spacelift.io/concepts/stack/organizing-stacks" target="_blank" rel="noopener">manage all your stacks from a single place</a>. 
To take this one step further, you could add <a href="https://docs.spacelift.io/concepts/policy/" target="_blank" rel="noopener">custom policies</a> to harden the security and reliability of your configurations and deployments. Spacelift provides different types of policies and workflows easily customizable to fit every use case. You could, for instance, add <a href="https://docs.spacelift.io/concepts/policy/terraform-plan-policy" target="_blank" rel="noopener">plan policies</a> to restrict or warn about security or compliance violations or <a href="https://docs.spacelift.io/concepts/policy/approval-policy" target="_blank" rel="noopener">approval policies</a> to add an approval step during deployments. The possibilities are endless with Spacelift since it provides a great way to blend Terraform and Kubernetes and enhance their capabilities with extra functionality. 
Take a look at the <a href="https://docs.spacelift.io/getting-started" target="_blank" rel="noopener">Getting Started Guide</a> to liftoff with Spacelift!

We delved into two of the most used modern <a href="https://spacelift.io/blog/devops-tools" target="_blank" rel="noopener">DevOps tools</a>, Kubernetes and Terraform. We discovered what makes each of them appealing and what functionalities they provide to IT operators and developers. We discussed their similarities, differences, and synergies and explored ways to combine them with Spacelift.
Thank you all for reading, and I hope you enjoyed this as much as I did.

Spacelift allows you to automate, audit, secure, and continuously deliver your infrastructure.  It helps overcome common state management issues and adds several must-have features for infrastructure management.

Initialize/ plan/ apply your IaC, manage modules, state, and more. 

frame-8479

Frame 8479

Terraform vs. Ansible : Key Differences and Comparison of Tools

Docker Compose vs Kubernetes - Differences Explained

Ansible vs. Kubernetes [Key Differences Explained]

See the comparison of Terraform and Kubernetes, the most dominant tools in the cloud infrastructure space. Learn about their similarities and differences. 

78-terraform-vs-kubernetes

Terraform vs Kubernetes

Terraform vs. Kubernetes : Key Differences and Comparison

Ioannis is a Cloud Architect with a background in DevOps &amp; Site Reliability Engineering interested in Cloud Infrastructure, Automation, CI/CD Pipelines &amp; Containerization. In his free time, he curates a personal blog at <a href="https://devopsmadness.com" rel="noopener nofollow">devopsmadness.com</a> and <a href="https://moustakisioannis.medium.com" rel="noopener nofollow">moustakisioannis.medium.com</a>. Opinions expressed are solely his own.

Jack Roper

In this post, we will list and describe each commonly used category or component of Kubernetes (K8S) with appropriate <code class="gr kz la lb lc b">kubectl</code> commands for quick reference!
<code>kubectl</code> is a Kubernetes command-line tool that allows you to run commands against Kubernetes clusters. You can use <code>kubectl</code> to deploy applications, inspect and manage cluster resources, and view logs.
The descriptions are taken directly from the official documentation at <a class="au ld" href="https://kubernetes.io/" target="_blank" rel="nofollow noopener">kubernetes.io</a>, and each will link to the appropriate documentation page should you require more information or a deeper dive.

<ul class="">
<li id="ed33" class="mo mp io kf b kg mq kj mr km ms kq mt ku mu ky mv mw mx my gs" data-selectable-paragraph=""><a href="https://spacelift.io/blog/kubernetes-cheat-sheet#common-options">Common Options</a></li>
<li id="56e2" class="mo mp io kf b kg mz kj na km nb kq nc ku nd ky mv mw mx my gs" data-selectable-paragraph=""><a href="https://spacelift.io/blog/kubernetes-cheat-sheet#configuration-files-also-referred-to-as-manifest-or-yaml-files">Configuration Files (Manifest files)</a></li>
<li id="c317" class="mo mp io kf b kg mz kj na km nb kq nc ku nd ky mv mw mx my gs" data-selectable-paragraph=""><a href="https://spacelift.io/blog/kubernetes-cheat-sheet#cluster-management-and-context">Cluster Management &amp; Context</a></li>
<li id="247e" class="mo mp io kf b kg mz kj na km nb kq nc ku nd ky mv mw mx my gs" data-selectable-paragraph=""><a href="https://spacelift.io/blog/kubernetes-cheat-sheet#daemonsets">Daemonsets</a></li>
<li id="1af2" class="mo mp io kf b kg mz kj na km nb kq nc ku nd ky mv mw mx my gs" data-selectable-paragraph=""><a href="https://spacelift.io/blog/kubernetes-cheat-sheet#deployments">Deployments</a></li>
<li id="9752" class="mo mp io kf b kg mz kj na km nb kq nc ku nd ky mv mw mx my gs" data-selectable-paragraph=""><a href="https://spacelift.io/blog/kubernetes-cheat-sheet#events">Events</a></li>
<li id="aff3" class="mo mp io kf b kg mz kj na km nb kq nc ku nd ky mv mw mx my gs" data-selectable-paragraph=""><a href="https://spacelift.io/blog/kubernetes-cheat-sheet#logs">Logs</a></li>
<li id="8eb3" class="mo mp io kf b kg mz kj na km nb kq nc ku nd ky mv mw mx my gs" data-selectable-paragraph=""><a href="https://spacelift.io/blog/kubernetes-cheat-sheet#namespaces">Namespaces</a></li>
<li id="9066" class="mo mp io kf b kg mz kj na km nb kq nc ku nd ky mv mw mx my gs" data-selectable-paragraph=""><a href="https://spacelift.io/blog/kubernetes-cheat-sheet#nodes">Nodes</a></li>
<li id="596c" class="mo mp io kf b kg mz kj na km nb kq nc ku nd ky mv mw mx my gs" data-selectable-paragraph=""><a href="https://spacelift.io/blog/kubernetes-cheat-sheet#pods">Pods</a></li>
<li id="31ae" class="mo mp io kf b kg mz kj na km nb kq nc ku nd ky mv mw mx my gs" data-selectable-paragraph=""><a href="https://spacelift.io/blog/kubernetes-cheat-sheet#replication-controllers">Replication Controllers</a></li>
<li id="29bd" class="mo mp io kf b kg mz kj na km nb kq nc ku nd ky mv mw mx my gs" data-selectable-paragraph=""><a href="https://spacelift.io/blog/kubernetes-cheat-sheet#replicasets">ReplicaSets</a></li>
<li id="1633" class="mo mp io kf b kg mz kj na km nb kq nc ku nd ky mv mw mx my gs" data-selectable-paragraph=""><a href="https://spacelift.io/blog/kubernetes-cheat-sheet#secrets">Secrets</a></li>
<li id="2066" class="mo mp io kf b kg mz kj na km nb kq nc ku nd ky mv mw mx my gs" data-selectable-paragraph=""><a href="https://spacelift.io/blog/kubernetes-cheat-sheet#services">Services</a></li>
<li id="52d4" class="mo mp io kf b kg mz kj na km nb kq nc ku nd ky mv mw mx my gs" data-selectable-paragraph=""><a href="https://spacelift.io/blog/kubernetes-cheat-sheet#service-accounts">Service Accounts</a></li>
</ul>
Anything that can be run via kubectl can be run within a Spacelift stack. Find out more about <a href="https://docs.spacelift.io/vendors/kubernetes/" target="_blank" rel="noopener">how Spacelift works with Kubernetes</a>.

In kubectl you can specify optional flags for use with various commands.
<code class="gr kz la lb lc b">alias</code> &#8211; Set an alias for kubectl.

<code class="gr kz la lb lc b">-o=json</code> &#8211; Output format in JSON.

<code class="gr kz la lb lc b">-o=yaml</code> &#8211; Output format in YAML.

<code class="gr kz la lb lc b">-o=wide</code> &#8211; Output in the plain-text format with any additional information, and for pods, the node name is included.

<code class="gr kz la lb lc b">-n</code> &#8211; Alias for <code class="gr kz la lb lc b">namespace</code>.

<code class="gr kz la lb lc b">-f</code> &#8211; Filename, directory, or URL to files to use to create a resource.

<code class="gr kz la lb lc b">-l</code> &#8211; Filter using a specified label.

<code class="gr kz la lb lc b">-h</code> &#8211; Help for kubectl.

<a href="https://kubernetes.io/docs/tasks/manage-kubernetes-objects/declarative-config/" target="_blank" rel="nofollow noopener">Configuration Files</a> (Also referred to as Manifest or YAML Files.) &#8211; Kubernetes objects can be created, updated, and deleted by storing multiple object configuration files in a directory and using <code class="gr kz la lb lc b">kubectl apply</code> to recursively create and update those objects as needed. This method retains writes made to live objects without merging the changes back into the object configuration files. <code class="gr kz la lb lc b">kubectl diff</code> also gives you a preview of what changes <code class="gr kz la lb lc b">apply</code> will make.

<code>kubectl create -f &lt;configuration file&gt;</code>  &#8211; Create objects.
<code>kubectl create -f &lt;configuration file directory&gt;</code> &#8211; Create objects in all manifest files in a directory.
<code>kubectl create -f &lt;‘url’&gt;</code> &#8211; Create objects from a URL.
<code>kubectl delete -f &lt;configuration file&gt;</code> &#8211; Delete an object.
Read more about <a href="https://spacelift.io/blog/kubectl-apply-vs-create" target="_blank" rel="noopener">Kubectl Apply vs. Kubectl Create – What’s the Difference?</a>.

Cluster management refers to querying information about the K8S cluster itself.
<code>kubectl cluster-info</code> &#8211; Display endpoint information about the master and services in the cluster.
<code>kubectl version</code> &#8211; Display the Kubernetes version running on the client and server.
<code>kubectl config view</code> &#8211; Get the configuration of the cluster.
<code>kubectl config view -o jsonpath='{.users[*].name}'</code> &#8211; Get a list of users.
<code>kubectl config current-context</code> &#8211; Display the current context.
<code>kubectl config get-contexts</code> &#8211; Display a list of contexts.
<code>kubectl config use-context &lt;cluster name&gt;</code> &#8211; Set the default context.
<code>kubectl api-resources</code> &#8211; List the API resources that are available.
<code>kubectl api-versions</code> &#8211; List the API versions that are available.
<code class="gr kz la lb lc b">-A</code> &#8211; List pods, services, daemonsets, deployments, replicasets, statefulsets, jobs, and <a href="https://spacelift.io/blog/kubernetes-cronjob" target="_blank" rel="noopener">CronJobs</a> in all namespaces, not custom resource types. Note the alias for <code class="gr kz la lb lc b">--all-namespaces</code> is <code class="gr kz la lb lc b">-A</code>

<ul>
<li style="list-style-type: none">
<ul>
<li><a href="https://spacelift.io/blog/kubernetes-tools" target="_blank" rel="noopener">26 Top Kubernetes Tools for Your K8s Ecosystem</a></li>
<li><a href="https://spacelift.io/blog/how-to-maintain-operations-around-kubernetes-cluster" target="_blank" rel="noopener">How to Maintain Operations Around Kubernetes Cluster</a></li>
<li><a href="https://spacelift.io/blog/kubernetes-best-practices" target="_blank" rel="noopener">15 Kubernetes Best Practices to Follow</a></li>
</ul>
</li>
</ul>
&nbsp;

<a href="https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/" target="_blank" rel="nofollow noopener">Daemonsets</a> &#8211; A DaemonSet ensures that all (or some) Nodes run a copy of a Pod. As nodes are added to the cluster, Pods are added to them. As nodes are removed from the cluster, those Pods are garbage collected. Deleting a DaemonSet will clean up the Pods it created.
<code>kubectl get daemonset</code> &#8211; List one or more daemonsets.
<code>kubectl edit daemonset &lt;daemonset_name&gt;</code> &#8211; Edit and update the definition of one or more daemonset.
<code>kubectl delete daemonset &lt;daemonset_name&gt;</code> &#8211; Delete a daemonset.
<code>kubectl create daemonset &lt;daemonset_name&gt;</code> &#8211; Create a new daemonset.
<code>kubectl rollout daemonset</code> &#8211; Manage the rollout of a daemonset.
<code>kubectl describe ds &lt;daemonset_name&gt; -n &lt;namespace_name&gt;</code> &#8211; Display the detailed state of daemonsets within a namespace.

<a href="https://kubernetes.io/docs/concepts/workloads/controllers/deployment/" target="_blank" rel="nofollow noopener">Deployments</a> &#8211; A Deployment provides declarative updates for <a class="au ld" href="https://kubernetes.io/docs/concepts/workloads/pods/" target="_blank" rel="noopener ugc nofollow">Pods</a> and <a class="au ld" href="https://kubernetes.io/docs/concepts/workloads/controllers/replicaset/" target="_blank" rel="noopener ugc nofollow">ReplicaSets</a>. You describe a desired state in a Deployment, and the Deployment <a class="au ld" href="https://kubernetes.io/docs/concepts/architecture/controller/" target="_blank" rel="noopener ugc nofollow">Controller</a> changes the actual state to the desired state at a controlled rate. You can define Deployments to create new ReplicaSets, or to remove existing Deployments and adopt all their resources with new Deployments. See <a href="https://spacelift.io/blog/statefulset-vs-deployment" target="_blank" rel="noopener">StatefulSet vs. Deployment</a>.
<code>kubectl get deployment</code> &#8211; List one or more deployments.
<code>kubectl describe deployment &lt;deployment_name&gt;</code> &#8211; Display the detailed state of one or more deployments.
<code>kubectl edit deployment &lt;deployment_name&gt;</code> &#8211; Edit and update the definition of one or more deployments on the server.
<code>kubectl create deployment &lt;deployment_name&gt;</code> &#8211; Create a new deployment.
<code>kubectl delete deployment &lt;deployment_name&gt;</code> &#8211; Delete deployments.
<code>kubectl rollout status deployment &lt;deployment_name&gt;</code> &#8211; See the rollout status of a deployment.
<code>kubectl set image deployment/&lt;deployment name&gt; &lt;container name&gt;=image:&lt;new image version&gt;</code> &#8211; Perform a rolling update (K8S default), set the image of the container to a new version for a particular deployment.
<code>kubectl rollout undo deployment/&lt;deployment name&gt;</code> &#8211; Rollback a previous deployment.
<code>kubectl replace --force -f &lt;configuration file&gt;</code> &#8211; Perform a replace deployment — Force replace, delete and then re-create the resource.
Read more about Kubernetes deployment strategies: <a href="https://spacelift.io/blog/kubernetes-deployment-strategies" target="_blank" rel="noopener">Different Types of Kubernetes Deployment Strategies (Examples)</a>

<code>kubectl get events</code> &#8211; List recent events for all resources in the system.
<code>kubectl get events --field-selector type=Warning</code> &#8211; List Warnings only.
<code>kubectl get events --sort-by=.metadata.creationTimestamp</code> &#8211; List events sorted by timestamp.
<code>kubectl get events --field-selector involvedObject.kind!=Pod</code> &#8211; List events but exclude Pod events.
<code>kubectl get events --field-selector involvedObject.kind=Node, involvedObject.name=&lt;node_name&gt;</code> &#8211; Pull events for a single node with a specific name.
<code>kubectl get events --field-selector type!=Normal</code> &#8211; Filter out normal events from a list of events.

<a href="https://kubernetes.io/docs/concepts/cluster-administration/system-logs/" target="_blank" rel="nofollow noopener">Logs</a> &#8211; System component logs record events happening in cluster, which can be very useful for debugging. You can configure log verbosity to see more or less detail. Logs can be as coarse-grained as showing errors within a component, or as fine-grained as showing step-by-step traces of events (like HTTP access logs, pod state changes, controller actions, or scheduler decisions).
<code>kubectl logs &lt;pod_name&gt;</code> &#8211; Print the logs for a pod.
<code>kubectl logs --since=6h &lt;pod_name&gt;</code> &#8211; Print the logs for the last 6 hours for a pod.
<code>kubectl logs --tail=50 &lt;pod_name&gt;</code> &#8211; Get the most recent 50 lines of logs.
<code>kubectl logs -f &lt;service_name&gt; [-c &lt;$container&gt;]</code> &#8211; Get logs from a service and optionally select which container.
<code>kubectl logs -f &lt;pod_name&gt;</code> &#8211; Print the logs for a pod and follow new logs.
<code>kubectl logs -c &lt;container_name&gt; &lt;pod_name&gt;</code> &#8211; Print the logs for a container in a pod.
<code>kubectl logs &lt;pod_name&gt; pod.log</code> &#8211; Output the logs for a pod into a file named ‘pod.log’.
<code>kubectl logs --previous &lt;pod_name&gt;</code> &#8211; View the logs for a previously failed pod.

<a href="https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/" target="_blank" rel="nofollow noopener">Namespaces</a> &#8211; In Kubernetes, namespaces provides a mechanism for isolating groups of resources within a single cluster. Names of resources need to be unique within a namespace, but not across namespaces. Namespace-based scoping is applicable only for namespaced objects (e.g. Deployments, Services, etc) and not for cluster-wide objects (e.g. StorageClass, Nodes, <a href="https://spacelift.io/blog/kubernetes-persistent-volumes" target="_blank" rel="noopener">PersistentVolumes</a>, etc).
<code>kubectl create namespace &lt;namespace_name&gt;</code> &#8211; Create a namespace.
<code>kubectl get namespace &lt;namespace_name&gt;</code> &#8211; List one or more namespaces.
<code>kubectl describe namespace &lt;namespace_name&gt;</code> &#8211; Display the detailed state of one or more namespaces.
<code>kubectl delete namespace &lt;namespace_name&gt;</code> &#8211; Delete a namespace.
<code>kubectl edit namespace &lt;namespace_name&gt;</code> &#8211; Edit and update the definition of a namespace.
<code>kubectl top namespace &lt;namespace_name&gt;</code> &#8211; Display Resource (CPU/Memory/Storage) usage for a namespace.

<a href="https://kubernetes.io/docs/concepts/architecture/nodes/" target="_blank" rel="nofollow noopener">Nodes</a> &#8211; Kubernetes runs your workload by placing containers into Pods to run on Nodes. A node may be a virtual or physical machine, depending on the cluster. Each node is managed by the <a class="au ld" href="https://kubernetes.io/docs/reference/glossary/?all=true#term-control-plane" target="_blank" rel="noopener ugc nofollow">control plane</a> and contains the services necessary to run <a class="au ld" href="https://kubernetes.io/docs/concepts/workloads/pods/" target="_blank" rel="noopener ugc nofollow">Pods</a>. Typically you have several nodes in a cluster; in a learning or resource-limited environment, you might have only one node. The <a class="au ld" href="https://kubernetes.io/docs/concepts/overview/components/#node-components" target="_blank" rel="noopener ugc nofollow">components</a> on a node include the <a class="au ld" href="https://kubernetes.io/docs/reference/generated/kubelet" target="_blank" rel="noopener ugc nofollow">kubelet</a>, a <a class="au ld" href="https://kubernetes.io/docs/setup/production-environment/container-runtimes" target="_blank" rel="noopener ugc nofollow">container runtime</a>, and the <a class="au ld" href="https://kubernetes.io/docs/reference/command-line-tools-reference/kube-proxy/" target="_blank" rel="noopener ugc nofollow">kube-proxy</a>.
<code>kubectl taint node &lt;node_name&gt;</code> &#8211; Update the taints on one or more nodes.
<code>kubectl get node</code> &#8211; List one or more nodes.
<code>kubectl delete node &lt;node_name&gt;</code> &#8211; Delete a node or multiple nodes.
<code>kubectl top node &lt;node_name&gt;</code> &#8211; Display Resource usage (CPU/Memory/Storage) for nodes.
<code>kubectl get pods -o wide | grep &lt;node_name&gt;</code> &#8211; Pods running on a node.
<code>kubectl annotate node &lt;node_name&gt;</code> &#8211; Annotate a node.
<code>kubectl cordon node &lt;node_name&gt;</code> &#8211; Mark a node as unschedulable.
<code>kubectl uncordon node &lt;node_name&gt;</code> &#8211; Mark node as schedulable.
<code>kubectl drain node &lt;node_name&gt;</code> &#8211; Drain a node in preparation for maintenance.
<code>kubectl label node</code> &#8211; Add or update the labels of one or more nodes.

<a href="https://kubernetes.io/docs/concepts/workloads/pods/" target="_blank" rel="nofollow noopener">Pods</a> &#8211; Pods are the smallest deployable units of computing that you can create and manage in Kubernetes. A Pod (as in a pod of whales or pea pod) is a group of one or more <a class="au ld" href="https://kubernetes.io/docs/concepts/containers/" target="_blank" rel="noopener ugc nofollow">containers</a>, with shared storage and network resources, and a specification for how to run the containers. A Pod’s contents are always co-located and co-scheduled, and run in a shared context. A Pod models an application-specific “logical host”: it contains one or more application containers which are relatively tightly coupled. In non-cloud contexts, applications executed on the same physical or virtual machine are analogous to cloud applications executed on the same logical host. As well as application containers, a Pod can contain <a class="au ld" href="https://kubernetes.io/docs/concepts/workloads/pods/init-containers/" target="_blank" rel="noopener ugc nofollow">init containers</a> that run during Pod startup. You can also inject <a class="au ld" href="https://kubernetes.io/docs/concepts/workloads/pods/ephemeral-containers/" target="_blank" rel="noopener ugc nofollow">ephemeral containers</a> for debugging if your cluster offers this.
<code>kubectl get pod</code> &#8211; List one or more pods.
<code>kubectl get pods --sort-by='.status.containerStatuses[0].restartCount'</code> &#8211; List pods Sorted by Restart Count.
<code>kubectl get pods --field-selector=status.phase=Running</code> &#8211; Get all running pods in the namespace.
<code>kubectl delete pod &lt;pod_name&gt;</code> &#8211; Delete a pod.
<code>kubectl describe pod &lt;pod_name&gt;</code> &#8211; Display the detailed state of a pods.
<code>kubectl create pod &lt;pod_name&gt;</code> &#8211; Create a pod.
<code>kubectl exec &lt;pod_name&gt; -c &lt;container_name&gt; &lt;command&gt;</code> &#8211; Execute a command against a container in a pod. Read more: <a href="https://spacelift.io/blog/kubectl-exec" target="_blank" rel="noopener">Using Kubectl Exec: Connect to Your Kubernetes Containers</a>
<code>kubectl exec -it &lt;pod_name&gt; /bin/sh</code> &#8211; Get an interactive shell on a single-container pod.
<code>kubectl top pod</code> &#8211; Display Resource usage (CPU/Memory/Storage) for pods.
<code>kubectl annotate pod &lt;pod_name&gt; &lt;annotation&gt;</code> &#8211; Add or update the annotations of a pod.
<code>kubectl label pods &lt;pod_name&gt; new-label=&lt;label name&gt;</code> &#8211; Add or update the label of a pod.
<code>kubectl get pods --show-labels</code> &#8211; Get pods and show labels.
<code>kubectl port-forward &lt;pod name&gt; &lt;port number to listen on&gt;:&lt;port number to forward to&gt;</code> &#8211; Listen on a port on the local machine and forward to a port on a specified pod.

<a href="https://kubernetes.io/docs/concepts/workloads/controllers/replicationcontroller/" target="_blank" rel="nofollow noopener">Replication Controllers</a> &#8211; Note: A <code class="gr kz la lb lc b"><a class="au ld" href="https://kubernetes.io/docs/concepts/workloads/controllers/deployment/" target="_blank" rel="noopener ugc nofollow">Deployment</a></code> that configures a <code class="gr kz la lb lc b"><a class="au ld" href="https://kubernetes.io/docs/concepts/workloads/controllers/replicaset/" target="_blank" rel="noopener ugc nofollow">ReplicaSet</a></code> is now the recommended way to set up replication. A ReplicationController ensures that a specified number of pod replicas are running at any one time. In other words, a ReplicationController makes sure that a pod or a homogeneous set of pods is always up and available.
<code>kubectl get rc</code> &#8211; List the replication controllers.
<code>kubectl get rc --namespace=”&lt;namespace_name&gt;”</code> &#8211; List the replication controllers by namespace.

<a href="https://kubernetes.io/docs/concepts/workloads/controllers/replicaset/" target="_blank" rel="nofollow noopener">ReplicaSets</a> &#8211; A ReplicaSet’s purpose is to maintain a stable set of replica Pods running at any given time. As such, it is often used to guarantee the availability of a specified number of identical Pods.
<code>kubectl get replicasets</code> &#8211; List ReplicaSets.
<code>kubectl describe replicasets &lt;replicaset_name&gt;</code> &#8211; Display the detailed state of one or more ReplicaSets.
<code>kubectl scale --replicas=[x]</code> &#8211; Scale a ReplicaSet.

<a href="https://kubernetes.io/docs/concepts/configuration/secret/" target="_blank" rel="nofollow noopener">Secrets</a> &#8211; A Secret is an object that contains a small amount of sensitive data such as a password, a token, or a key. Such information might otherwise be put in a <a class="au ld" href="https://kubernetes.io/docs/concepts/workloads/pods/" target="_blank" rel="noopener ugc nofollow">Pod</a> specification or in a <a class="au ld" href="https://kubernetes.io/docs/reference/glossary/?all=true#term-image" target="_blank" rel="noopener ugc nofollow">container image</a>. Using a Secret means that you don’t need to include confidential data in your application code.
<code>kubectl create secret</code> &#8211; Create a secret.
<code>kubectl get secrets</code> &#8211; List secrets.
<code>kubectl describe secrets</code> &#8211; List details about secrets.
<code>kubectl delete secret &lt;secret_name&gt;</code> &#8211; Delete a secret.

<a href="https://kubernetes.io/docs/concepts/services-networking/service/" target="_blank" rel="nofollow noopener">Services</a> &#8211; An abstract way to expose an application running on a set of <a class="au ld" href="https://kubernetes.io/docs/concepts/workloads/pods/" target="_blank" rel="noopener ugc nofollow">Pods</a> as a network service. With Kubernetes you don’t need to modify your application to use an unfamiliar service discovery mechanism. Kubernetes gives Pods their own IP addresses and a single DNS name for a set of Pods, and can load-balance across them.
<code>kubectl get services</code> &#8211; List one or more services.
<code>kubectl describe services</code> &#8211; Display the detailed state of a service.
<code>kubectl expose deployment [deployment_name]</code> &#8211; Expose a replication controller, service, deployment, or pod as a new Kubernetes service.
<code>kubectl edit services</code> &#8211; Edit and update the definition of one or more services.

<a href="https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/" target="_blank" rel="nofollow noopener">Service Accounts</a> &#8211; A service account provides an identity for processes that run in a Pod.
Note: This document is a user introduction to Service Accounts and describes how service accounts behave in a cluster set up as recommended by the Kubernetes project. Your cluster administrator may have customized the behavior in your cluster, in which case this documentation may not apply.
When you (a human) access the cluster (for example, using <code class="gr kz la lb lc b">kubectl</code>), you are authenticated by the apiserver as a particular User Account (currently this is usually <code class="gr kz la lb lc b">admin</code>, unless your cluster administrator has customized your cluster). Processes in containers inside pods can also contact the apiserver. When they do, they are authenticated as a particular Service Account (for example, <code class="gr kz la lb lc b">default</code>).
<code>kubectl get serviceaccounts</code> &#8211; List service accounts.
<code>kubectl describe serviceaccounts</code> &#8211; Display the detailed state of one or more service accounts.
<code>kubectl replace serviceaccount</code> &#8211; Replace a service account.
<code>kubectl delete serviceaccount &lt;service_account_name&gt;</code> &#8211; Delete a service account.

<a href="https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/" target="_blank" rel="nofollow noopener">StatefulSet</a> &#8211; StatefulSet is the workload API object used to manage stateful applications. Manages the deployment and scaling of a set of <a class="au ld" href="https://kubernetes.io/docs/concepts/workloads/pods/" target="_blank" rel="noopener ugc nofollow">Pods</a>, and provides guarantees about the ordering and uniqueness of these Pods.
Like a <a class="au ld" href="https://kubernetes.io/docs/concepts/workloads/controllers/deployment/" target="_blank" rel="noopener ugc nofollow">Deployment</a>, a StatefulSet manages Pods that are based on an identical container spec. Unlike a Deployment, a StatefulSet maintains a sticky identity for each of their Pods. These pods are created from the same spec, but are not interchangeable: each has a persistent identifier that it maintains across any rescheduling.
If you want to use storage volumes to provide persistence for your <a href="https://spacelift.io/blog/kubernetes-workload" target="_blank" rel="noopener">Kubernetes workload</a>, you can use a StatefulSet as part of the solution. Although individual Pods in a StatefulSet are susceptible to failure, the persistent Pod identifiers make it easier to match existing volumes to the new Pods that replace any that have failed.
<code>kubectl get statefulset</code> &#8211; List StatefulSet
<code>kubectl delete statefulset/[stateful_set_name] --cascade=false</code> &#8211; Delete StatefulSet only (not pods).

<a href="https://docs.spacelift.io/" target="_blank" rel="noopener">Spacelift</a> helps you manage the complexities and compliance challenges of using Kubernetes. It brings with it a GitOps flow, so your Kubernetes Deployments are synced with your Kubernetes Stacks, and pull requests show you a preview of what they&#8217;re planning to change. It also has an extensive selection of <a href="https://docs.spacelift.io/concepts/policy/" target="_blank" rel="noopener">policies</a>, which lets you <a href="https://docs.spacelift.io/concepts/policy/terraform-plan-policy" target="_blank" rel="noopener">automate compliance checks</a> and <a href="https://docs.spacelift.io/concepts/policy/trigger-policy" target="_blank" rel="noopener">build complex multi-stack workflows</a>. You can also use Spacelift to mix and match Terraform, Pulumi, CloudFormation, and Kubernetes Stacks and have them talk to one another. For example, you can set up Terraform Stacks to provision the required infrastructure (like an ECS/EKS cluster with all its dependencies) and then deploy the following via a Kubernetes Stack.
If you want to learn more about Spacelift, <a href="https://spacelift.io/free-trial" target="_blank" rel="noopener">create a free account today</a> or <a href="https://spacelift.io/schedule-demo" target="_blank" rel="noopener">book a demo with one of our engineers</a>.

When using K8S, cut to the chase and use a cheat sheet!
Cheers!

Spacelift is an alternative to using homegrown solutions on top of a generic CI. It helps overcome common state management issues and adds several must-have capabilities s for infrastructure management.

Transform your IaC management to scale securely, efficiently, and productively into the future.

ebook-sidebanner

ebook bottom overlay

17 Kubernetes Best Practices Every Developer Should Know

What Is a Kubernetes Cluster? Key Components Explained

How to Install Kubernetes - 4 Different Ways [Step-by-Step]

See the helpful list of each commonly used category or component of Kubernetes (K8S) with appropriate kubectl commands for quick reference!

91-kubernetes-cheat-sheet

Kubernetes cheat sheet

Kubectl Cheat Sheet - 15 Kubernetes Commands & Objects

In this post, we will delve into Kubernetes (K8s) deployment concepts and some common strategies, looking at the advantages and disadvantages of each. A suitable deployment strategy enables you to minimize downtime, enhance your customer experience, and increase reliability when releasing your application.

A Kubernetes Deployment is a declarative statement usually configured in a YAML file that defines the application lifecycle and how updates to that application should be applied.
When deploying your applications to a <a href="https://spacelift.io/blog/kubernetes-cluster" target="_blank" rel="noopener">K8s cluster</a>, your chosen deployment strategy will determine how those applications are updated to a newer version from an older one. Some strategies will involve downtime. Some will introduce testing concepts and enable user analysis. There are two basic commonly used K8s deployment strategies we will look at in this post:
<ul class="">
<li id="d400" class="mp mq io kf b kg kh kj kk km mr kq ms ku mt ky mu mv mw mx gs" data-selectable-paragraph="">Recreating</li>
<li id="8ab3" class="mp mq io kf b kg my kj mz km na kq nb ku nc ky mu mv mw mx gs" data-selectable-paragraph="">Rolling</li>
</ul>
The following strategies are considered &#8220;Advanced deployment strategies&#8221; because the flow of traffic can be controlled in various ways:
<ul class="">
<li id="a009" class="mp mq io kf b kg kh kj kk km mr kq ms ku mt ky mu mv mw mx gs" data-selectable-paragraph="">Blue/Green</li>
<li id="ba8f" class="mp mq io kf b kg my kj mz km na kq nb ku nc ky mu mv mw mx gs" data-selectable-paragraph="">Canary</li>
<li id="49bc" class="mp mq io kf b kg my kj mz km na kq nb ku nc ky mu mv mw mx gs" data-selectable-paragraph="">A/B</li>
<li data-selectable-paragraph="">Ramped Slow Rollout</li>
<li data-selectable-paragraph="">Best-Effort Controlled Rollout</li>
<li data-selectable-paragraph="">Shadow Deployment</li>
</ul>
K8s uses a Rolling deployment strategy as the default, but there are certain use cases when this may not be appropriate. Let&#8217;s discuss each in more detail!
See how Spacelift can help you manage the complexities and compliance challenges of using Kubernetes with the newest <a href="https://docs.spacelift.io/vendors/kubernetes/" target="_blank" rel="noopener">Kubernetes integration</a>. It brings with it a GitOps flow, so your Kubernetes Deployments are synced with your Kubernetes Stacks, and pull requests show you a preview of what they&#8217;re planning to change. It also has an extensive selection of <a href="https://docs.spacelift.io/concepts/policy/" target="_blank" rel="noopener">policies</a>, which lets you <a href="https://docs.spacelift.io/concepts/policy/terraform-plan-policy" target="_blank" rel="noopener">automate compliance checks</a> and <a href="https://docs.spacelift.io/concepts/policy/trigger-policy" target="_blank" rel="noopener">build complex multi-stack workflows</a>.

Recreating deployment terminates all the pods and replaces them with the new version. This can be useful in situations where an old and new version of the application cannot run at the same time. The amount of downtime incurred using this strategy will depend on how long the application takes to shut down and start back up. The application state is entirely renewed since they are completely replaced.
An example Spec: section in the manifest file could look like this:

Rolling deployments are the default K8S offering designed to reduce downtime to the cluster. A rolling deployment replaces pods running the old version of the application with the new version without downtime.
To achieve this, Readiness probes are used:
<ul class="">
<li id="ec87" class="mp mq io kf b kg kh kj kk km mr kq ms ku mt ky mu mv mw mx gs" data-selectable-paragraph="">Readiness probes monitor when the application becomes available. If the probes fail, no traffic will be sent to the pod. These are used when an app needs to perform certain initialization steps before it becomes ready. An application may also become overloaded with traffic and cause the probe to fail, preventing more traffic from being sent to it and allowing it to recover.</li>
</ul>
Once the readiness probe detects the new version of the application is available, the old version of the application is removed. If there is a problem, the rollout can be stopped and rolled back to the previous version, avoiding downtime across the entire cluster. Because each pod is replaced one by one, deployments can take time for larger clusters. If a new deployment is triggered before another has finished, the version is updated to the version specified in the new deployment, and the previous deployment version is disregarded where it has not yet been applied.
A rolling deployment is triggered when something in the pod spec is changed, such as when the image, environment, or label of a pod is updated. A pod image can be updated using the command <code class="gr nj nk nl nf b">kubectl set image</code>.
The spec: -&gt; strategy: section of the manifest file can be used to refine the deployment by making use of two optional parameters — <code class="gr nj nk nl nf b">maxSurge</code> and <code class="gr nj nk nl nf b">maxUnavailable</code>. Both can be specified using a percentage or absolute number. A percentage figure should be used when Horizontal Pod Autoscaling is used.
<ul class="">
<li id="bbc5" class="mp mq io kf b kg kh kj kk km mr kq ms ku mt ky mu mv mw mx gs" data-selectable-paragraph="">MaxSurge specifies the maximum number of pods the Deployment is allowed to create at one time.</li>
<li id="87a3" class="mp mq io kf b kg my kj mz km na kq nb ku nc ky mu mv mw mx gs" data-selectable-paragraph="">MaxUnavailable specifies the maximum number of pods that are allowed to be unavailable during the rollout.</li>
</ul>
For example, the configuration below would specify a requirement for 10 replicas, with a maximum of 3 being created at any one time, allowing for 1 to be unavailable during the rollout:

<ul>
<li><a href="https://spacelift.io/blog/provision-kubernetes-cluster-terraform-spacelift" target="_blank" rel="noopener">How to Provision Kubernetes Cluster with Spacelift and Terraform</a></li>
<li><a href="https://spacelift.io/blog/kubernetes-best-practices" target="_blank" rel="noopener">15 Kubernetes Best Practices to Follow</a></li>
<li><a href="https://spacelift.io/blog/ci-cd-tools" target="_blank" rel="noopener">Top Most Useful CI/CD Tools for DevOps</a></li>
</ul>

Ramped Slow Rollout means the new version is rolled out slowly, creating new replicas replacing the old ones. This is also another term for a Canary deployment that we discuss later in the article.

A <a href="https://spacelift.io/blog/blue-green-deployment-kubernetes" target="_blank" rel="noopener">blue-green deployment</a> involves deploying the new application version (green) alongside the old one (blue). A <a href="https://spacelift.io/blog/kubernetes-load-balancer" target="_blank" rel="noopener">load balancer</a> in the form of the service selector object is used to direct the traffic to the new application (green) instead of the old one when it has been tested and verified. Blue/Green deployments can prove costly as twice the amount of application resources need to be stood up during the deployment period.
To enable this, we set up a service sitting in front of the deployments. For example, the service selector section of the manifest file for the blue deployment for an app called web-app with v1.0.0 could look like the below:

And the deployment for the blue web app:

When we want to direct traffic to the new (green) version of the app, we update the manifest to point to the new version, v2.0.0.

The deployment for the green app:

Blue / green deployments may also be referred to as ‘best-effort controlled rollouts’ — again, with the focus on updating your application or microservices with a focus on minimizing downtime and ensuring that the application remains available as much as possible during the deployment process.

Canary or ‘Ramped slow rollout’ strategies are sometimes used interchangeably with the term ‘Shadow Deployment’. 
A Shadow Deployment is a strategy where a new version of an application is deployed alongside the existing production version, primarily for monitoring and testing purposes. User traffic is not actively routed to the new version in a shadow deployment.

A Canary deployment can be used to let a subset of the users test a new version of the application or when you are not fully confident about the new version&#8217;s functionality. This involves deploying a new version of the application alongside the old one, with the old version of the application serving most users and the newer version serving a small pool of test users. The new deployment is rolled out to more users if it is successful.
For example, in a <a href="https://spacelift.io/blog/provision-kubernetes-cluster-terraform-spacelift" target="_blank" rel="noopener">K8s cluster</a> with 100 running pods, 95 could be running v1.0.0 of the application, with 5 running the new v2.0.0 of the application. 95% of the users will be routed to the old version, and 5% will be routed to the new version. For this, we use 2 deployments side-by-side that can be scaled separately.
The spec section of the old application manifest would look like the following:

Delve into different Kubernetes (K8s) deployment strategies. Take a look at the advantages and disadvantages of each of them.

Terraform vs. Kubernetes : Key Differences and Comparison

Get the newsletter

Recent posts

Kubectl Cheat Sheet – 15 Kubernetes Commands & Objects

8 Different Types of Kubernetes Deployment Strategies

What Is a Kubernetes Cluster? Key Components Explained

17 Kubernetes Best Practices Every Developer Should Know

Provision a Kubernetes Cluster with Spacelift and Terraform

Initial Availability of Kubernetes Integration in Spacelift

Running Spacelift CI/CD workers in Kubernetes using DinD

Provisioning AWS EKS Cluster with Terraform – Tutorial

Share your data and download the guide