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

AWS: Spacelift Reduces Time Spent on Cloud Management by 90% 🚀

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

Jack Roper

A pod is the smallest unit in Kubernetes (K8S). They should run until they are replaced by a new deployment. Because of this, there is no way to restart a pod, instead, it should be replaced.
There is no <code>kubectl restart [podname]</code> command for use with K8S (with <a href="https://spacelift.io/blog/docker-tutorial" target="_blank" rel="noopener">Docker</a> you can use <code>docker restart [container_id]</code> ), so there are a few different ways to achieve a pod ‘restart’ with <code>kubectl</code>.
You may need to ‘restart’ a pod in several situations, commonly when the pod status is stuck in a ‘terminating’ state, or when a pod is erroring and that error cannot be fixed without a restart. In certain situations, you may need to restart a pod after modifying the configuration, such as amending the resource limits to restrict a pod&#8217;s memory limits, or changing the persistent volume storage a pod is using.

A pod has five possible statuses:
<ol>
<li>Pending: This state shows at least one container within the pod has not yet been created.</li>
<li>Running: All containers have been created, and the pod has been bound to a Node. At this point, the containers are running, or are being started or restarted.</li>
<li>Succeeded: All containers in the pod have been successfully terminated and will not be restarted.</li>
<li>Failed: All containers have been terminated, and at least one container has failed. The failed container exists in a non-zero state.</li>
<li>Unknown: The status of the pod cannot be obtained.</li>
</ol>
If you notice a pod in an undesirable state where the status is showing as ‘error’, you might try a ‘restart’ as part of your troubleshooting to get things back to normal operations. You may also see the status ‘<a href="https://spacelift.io/blog/crashloopbackoff" target="_blank" rel="noopener">CrashLoopBackOff</a>’, which the default when an error is encountered, and K8S trys to restart the pod automatically.

You can use the following methods to ‘restart’ a pod with <code>kubectl</code>. Once new pods are re-created they will have a different name than the old ones. A list of pods can be obtained using the <code>kubectl get pods</code> command.

<h3>Method 1</h3>
<code>kubectl rollout restart</code>
This method is the recommended first port of call as it will not introduce downtime as pods will be functioning. A rollout restart will kill one pod at a time, then new pods will be scaled up. This method can be used as of K8S v1.15.
<code>kubectl rollout restart deployment &lt;deployment_name&gt; -n &lt;namespace&gt;</code>

<h3>Method 2</h3>
<code>kubectl scale</code>
This method will introduce an outage and is not recommended. If downtime is not an issue, this method can be used as it can be a quicker alternative to the <code>kubectl rollout restart method</code> (your pod may have to run through a lengthy Continuous Integration / Continuous Deployment Process before it is redeployed).
If there is no YAML file associated with the deployment, you can set the number of replicas to 0.
<code>kubectl scale deployment &lt;deployment name&gt; -n &lt;namespace&gt; --replicas=0</code>
This terminates the pods. Once scaling is complete the replicas can be scaled back up as needed (to at least 1):
<code>kubectl scale deployment &lt;deployment name&gt; -n &lt;namespace&gt; --replicas=3</code>
Pod status can be checked during the scaling using:
<code>kubectl get pods -n &lt;namespace&gt;</code>

<h3>Method 3</h3>
<code><a href="https://spacelift.io/blog/kubectl-delete-pod" target="_blank" rel="noopener">kubectl delete pod</a> and kubectl delete replicaset</code>
Each pod can be deleted individually if required:
<code>kubectl delete pod &lt;pod_name&gt; -n &lt;namespace&gt;</code>
Doing this will cause the pod to be recreated because K8S is declarative, it will create a new pod based on the specified configuration.
However, where lots of pods are running this is not really a practical approach. Where lots of pods have the same label however, you could use that to select multiple pods at once:
<code>kubectl delete pod -l “app:myapp” -n &lt;namespace&gt;</code>
Another approach if there are lots of pods, then ReplicaSet can be deleted instead:
<code>kubectl delete replicaset &lt;name&gt; -n &lt;namespace&gt;</code>

<h3>Method 4</h3>
<code>kubectl get pod | kubectl replace</code>
The pod to be replaced can be retrieved using the <code>kubectl get pod</code> to get the YAML statement of the currently running pod and pass it to the <code>kubectl replace</code> command with the <code>--force</code> flag specified in order to achieve a restart. This is useful if there is no YAML file available and the pod is started.
<code>kubectl get pod &lt;pod_name&gt; -n &lt;namespace&gt; -o yaml | kubectl replace --force -f -</code>

<h3>Method 5</h3>
<code>kubectl set env</code>
Setting or changing an environment variable associated with the pod will cause it to restart to take the change. The example below sets the environment variable <code>DEPLOY_DATE</code> to the date specified, causing the pod to restart.
<code>kubectl set env deployment &lt;deployment name&gt; -n &lt;namespace&gt; DEPLOY_DATE="$(date)"</code>

<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>

Having a range of commands to use in your toolbox when running into issues with pods in K8S will enable you to use the appropriate method to restart them, depending on how you have deployed the pods, the necessity for application uptime, and the speed you need the restart to happen. In general, the best approach is to use the <code>kubectl rollout restart</code> method described above as it will avoid application downtime.
A restart will not resolve the problem that caused the pods to have issues in the first place, so further investigation will be required into the root cause.
If you need more help with Kubernetes, <a href="https://spacelift.io" target="_blank" rel="noopener">Spacelift</a> helps you manage the complexities and compliance challenges of using Kubernetes. Anything that can be run via kubectl can be run within a Spacelift stack. 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. Find out more about <a href="https://docs.spacelift.io/vendors/kubernetes/" target="_blank" rel="noopener">how Spacelift works with Kubernetes</a>.

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.

Kubernetes Tutorial for Beginners - Basic Concepts & Examples

15 Kubernetes Best Practices Every Developer Should Know

Kubectl Cheat Sheet - 15 Kubernetes Commands & Objects

There is no kubectl restart [podname] command for use with Kubernetes. Learn different ways to achieve a pod ‘restart’ with kubectl.

how-to-restart-kubernetes-pods

How to Restart Kubernetes Pods With Kubectl

Automate workflows, enable drift detection, self-service, cost estimation, improve collaboration and security of your infrastructure.  

James Walker

<a title="Kubernetes" href="https://kubernetes.io" target="_blank" rel="nofollow noopener">Kubernetes</a> is the most popular orchestrator for deploying and scaling containerized systems. You can use Kubernetes to reliably build and distribute your applications in the cloud.
In this beginner&#8217;s guide, you&#8217;ll learn what Kubernetes can do and how to get started running your own containerized solutions.
<ol>
<li><a href="https://spacelift.io/blog/kubernetes-tutorial#what-is-kubernetes">What Is Kubernetes?</a></li>
<li><a href="https://spacelift.io/blog/kubernetes-tutorial#kubernetes-features">Kubernetes Features</a></li>
<li><a href="https://spacelift.io/blog/kubernetes-tutorial#how-kubernetes-works">How Kubernetes Works</a></li>
<li><a href="https://spacelift.io/blog/kubernetes-tutorial#installation-and-setup">Installation and Setup</a></li>
<li><a href="https://spacelift.io/blog/kubernetes-tutorial#kubernetes-basic-terms-and-concepts">Kubernetes Basic Terms and Concepts</a></li>
<li><a href="https://spacelift.io/blog/kubernetes-tutorial#using-kubectl-to-interact-with-kubernetes">Using Kubectl to Interact With Kubernetes</a></li>
</ol>

Kubernetes is an open-source system that automates container deployment tasks. It was originally developed at Google but is now maintained as part of the <a href="https://www.cncf.io" target="_blank" rel="nofollow noopener"> Cloud Native Computing Foundation (CNCF).</a>
Kubernetes has risen to prominence because it solves many of the challenges around using containers in production. It makes it easy to launch limitless container replicas, distribute them across multiple physical hosts, and set up networking so users can reach your service.
Most developers begin their container journey with <a href="https://spacelift.io/blog/docker-tutorial" target="_blank" rel="noopener"> Docker</a>. While this is a comprehensive tool, it&#8217;s relatively low-level and relies on CLI commands that interact with one container at a time. Kubernetes provides much higher-level abstractions for defining applications and their infrastructure using declarative schemas you can collaborate on.

Kubernetes has a comprehensive feature set that includes a full spectrum of capabilities for running containers and associated infrastructure:
<ul>
<li>Automated rollouts, scaling, and rollbacks &#8211; Kubernetes automatically creates the specified number of replicas, distributes them onto suitable hardware, and takes action to reschedule your containers if a node goes down. You can instantly scale the number of replicas on-demand or in response to changing conditions such as CPU usage.</li>
<li>Service discovery, load balancing, and network ingress &#8211; Kubernetes provides a complete networking solution that covers internal service discovery and public container exposure.</li>
<li>Stateless and stateful applications &#8211; While Kubernetes initially focused on stateless containers, it&#8217;s now also got <a href="https://kubernetes.io/docs/concepts/workloads/controllers/statefulset" target="_blank" rel="nofollow noopener"> built-in objects</a> to represent stateful apps too. You can run any kind of application in Kubernetes</li>
<li>Storage management &#8211; Persistent storage is abstracted by a consistent interface that works across providers, whether in the cloud, on a network share, or on a local filesystem.</li>
<li>Declarative state &#8211; Kubernetes uses object manifests in YAML files to define the state you want to create in your cluster. Applying a manifest instructs Kubernetes to automatically transition the cluster to the target state. You don&#8217;t have to manually script the changes you want to see.</li>
<li>Works across environments &#8211; Kubernetes can be used in the cloud, at the edge, or on your developer workstation. Many different distributions are available to match different use cases. Major cloud providers like AWS and Google Cloud offer managed Kubernetes services, while single-node distributions such as <a href="https://minikube.sigs.k8s.io/docs" target="_blank" rel="nofollow noopener">Minikube</a> and <a href="https://k3s.io" target="_blank" rel="nofollow noopener">K3s</a> are great for local use.</li>
<li>Highly extensible &#8211; Kubernetes packs in a lot of functionality, but you can add even more using extensions. You can create <a href="https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources" target="_blank" rel="nofollow noopener">custom object types</a>, controllers, and <a href="https://kubernetes.io/docs/concepts/extend-kubernetes/operator" target="_blank" rel="nofollow noopener">operators</a> to support your own workloads.</li>
</ul>
With so many features available, Kubernetes is ideal for any situation where you want to deploy containers with declarative configuration.
Check out our <a href="https://spacelift.io/blog/openshift-vs-kubernetes" target="_blank" rel="noopener">OpenShift vs. Kubernetes comparison</a>.

Kubernetes has a reputation for complexity because it has several moving parts. Understanding the basics of how they fit together will help you start out on your Kubernetes journey.
A Kubernetes environment is termed a cluster. It includes one or more nodes. A node is simply a machine that will run your containers. It could be physical hardware or a VM.
As well as nodes, the cluster also has a control plane. The control plane coordinates the entire cluster&#8217;s operations. It schedules new containers onto available nodes and provides the API server that you interact with. It&#8217;s possible to run a cluster with <a href="https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/high-availability" target="_blank" rel="nofollow noopener">multiple control plane instances</a> to create a highly available setup with greater resiliency.
Here are the most important Kubernetes components:
<ul>
<li>kube-apiserver &#8211; This is the part of the control plane that runs the API server. It&#8217;s the only way to interact with a running Kubernetes cluster. You can issue commands to the API server using the <a href="https://kubernetes.io/docs/tasks/tools" target="_blank" rel="nofollow noopener">Kubectl CLI</a> or an HTTP client.</li>
<li>kube-controller-manager &#8211; The controller manager starts and runs Kubernetes&#8217; built-in controllers. A <a href="https://kubernetes.io/docs/concepts/architecture/controller" target="_blank" rel="nofollow noopener">controller</a> is essentially an event loop that applies actions after changes in your cluster. They create, scale, and delete objects in response to events such as an API request or increased load.</li>
<li>kube-scheduler &#8211; The scheduler assigns new Pods (containers) onto the nodes in your cluster. It establishes which nodes can fulfill the Pod&#8217;s requirements, then selects the most optimal placement to maximize performance and reliability.</li>
<li>kubelet &#8211; Kubelet is a worker process that runs on each of your nodes. It maintains communication with the Kubernetes control plane to receive its instructions. Kubelet is responsible for pulling container images and starting containers in response to scheduling requests.</li>
<li>kube-proxy &#8211; Proxy is another component found on individual nodes. It configures the host&#8217;s networking system so traffic can reach the services in your cluster.</li>
</ul>
<a href="https://kubernetes.io/docs/tasks/tools" target="_blank" rel="nofollow noopener">Kubectl</a> is usually the final piece in a functioning Kubernetes environment. You&#8217;ll need this CLI to interact with your cluster and its objects. Once your cluster&#8217;s set up, you can also install the <a href="https://kubernetes.io/docs/tasks/access-application-cluster/web-ui-dashboard" target="_blank" rel="nofollow noopener">official dashboard</a> or a third-party solution to control Kubernetes from a GUI.

<ul>
<li><a href="https://spacelift.io/blog/provision-kubernetes-cluster-terraform-spacelift" target="_blank" rel="noopener">How to Provision Kubernetes Cluster with 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/terraform-vs-kubernetes" target="_blank" rel="noopener"><span data-sheets-value="{&quot;1&quot;:2,&quot;2&quot;:&quot;Terraform vs. Kubernetes : Key Differences and Comparison&quot;}" data-sheets-userformat="{&quot;2&quot;:513,&quot;3&quot;:{&quot;1&quot;:0},&quot;12&quot;:0}">Terraform vs. Kubernetes Comparison</a></li>
</ul>

There are many different ways to get started with Kubernetes because of the range of distributions on offer. Creating a cluster <a href="https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm" target="_blank" rel="nofollow noopener">using the official distribution</a> is relatively involved so most people use a packaged solution like <a href="https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm" target="_blank" rel="nofollow noopener">Minikube</a>, <a href="https://microk8s.io" target="_blank" rel="nofollow noopener">MicroK8s</a>, <a href="https://k3s.io" target="_blank" rel="nofollow noopener">K3s</a>, or <a href="https://kind.sigs.k8s.io" target="_blank" rel="nofollow noopener">Kind</a>.
We&#8217;ll use K3s for this tutorial. It&#8217;s an ultra-lightweight Kubernetes distribution that bundles all the Kubernetes components into a single binary. Unlike other options, there&#8217;s no dependencies to install or heavy VMs to run. It also includes the Kubectl CLI that you&#8217;ll use to issue <a href="https://spacelift.io/blog/kubernetes-cheat-sheet" target="_blank" rel="noopener">Kubernetes commands</a>.
Running the following command will install K3s on your machine:

It automatically downloads the latest available Kubernetes release and registers a system service for K3s.
After installation, run the following command to copy the auto-generated Kubectl config file into your .kube directory:

Now tell K3s to use this <a href="https://spacelift.io/blog/kubeconfig" target="_blank" rel="noopener">config file</a> by running the following command:

You can add this line to your <code>~/.profile</code> or <code>~/.bashrc</code> file to automatically apply the change after you login.
Next run this command:

You should see a single node appear, named with your machine&#8217;s hostname. The node shows as Ready so your Kubernetes cluster can now be used!

Your cluster&#8217;s running, but what can you do with it? It&#8217;s worth getting familiar with some key Kubernetes terms before you continue.

<h3>Nodes</h3>
Nodes represent the physical machines that form your <a href="https://spacelift.io/blog/kubernetes-cluster" target="_blank" rel="noopener">Kubernetes cluster</a>. They run the containers you create. Kubernetes tracks the status of your nodes and exposes each one as an object. You used Kubectl to retrieve a list of nodes in the example above.
While your fresh cluster has only one node, Kubernetes advertises support for <a href="https://kubernetes.io/docs/setup/best-practices/cluster-large" target="_blank" rel="nofollow noopener">up to 5,000 nodes</a>. It&#8217;s theoretically possible to <a href="https://openai.com/blog/scaling-kubernetes-to-7500-nodes" target="_blank" rel="noopener">scale even further</a>.
<h3>Namespaces</h3>
<a href="https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces" target="_blank" rel="nofollow noopener">Namespaces</a> isolate different groups of resources. They avoid name collisions by scoping the visibility of your resources.
Creating two objects with the same name is forbidden within the same namespace. If you&#8217;re in the default namespace, you can&#8217;t create two Pods that are both called database, for example. Namespaces resolve this by providing logical separation of resources. Two namespaces called app-1 and app-2 could each contain a Pod called database without causing a conflict.
Namespaces are flexible and can be used in many different ways. It&#8217;s a good idea to create a namespace for each workload in your cluster. You can also use namespaces to divide resources between users and teams by applying <a href="https://kubernetes.io/docs/reference/access-authn-authz/rbac" target="_blank" rel="nofollow noopener">role-based access control</a>.
<h3>Pods</h3>
<a href="https://kubernetes.io/docs/concepts/workloads/pods" target="_blank" rel="nofollow noopener">Pods</a> are the fundamental compute unit in Kubernetes. A Pod is analogous to a container but with some key differences. Pods can contain multiple containers, each of which share a context. The entire Pod will always be scheduled onto the same node. The containers within a Pod are tightly coupled so you should create a new Pod for each distinct part of your application, such as its API and database.
In simple situations, Pods will usually map one-to-one with the containers your application runs. In more advanced cases, Pods can be enhanced with <a href="https://kubernetes.io/docs/concepts/workloads/pods/init-containers" target="_blank" rel="nofollow noopener">init containers</a> and <a href="https://kubernetes.io/docs/concepts/workloads/pods/ephemeral-containers" target="_blank" rel="nofollow noopener">ephemeral containers</a> to customize startup behavior and provide detailed debugging.
<h3>ReplicaSets</h3>
<a href="https://kubernetes.io/docs/concepts/workloads/controllers/replicaset" target="_blank" rel="nofollow noopener">ReplicaSets</a> are used to consistently replicate a Pod. They provide a guarantee that a set number of replicas will be running at any time. If a node goes offline or a Pod becomes unhealthy, Kubernetes will automatically schedule a new Pod instance to maintain the specified replica count.
<h3>Deployments</h3>
<a href="https://kubernetes.io/docs/concepts/workloads/controllers/deployment" target="_blank" rel="nofollow noopener">Deployments</a> wrap ReplicaSets with support for declarative updates and rollbacks. They&#8217;re a higher level of abstraction that&#8217;s easier to control.
A Deployment object lets you specify the desired state of a set of Pods. This includes the number of replicas to run. Modifying the Deployment will automatically detect the required changes and scale the ReplicaSet as required. You can <a href="https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#pausing-and-resuming-a-deployment" target="_blank" rel="nofollow noopener">pause the rollout</a> or revert to an earlier revision, features that aren&#8217;t available with plain ReplicaSets.
<h3>Services</h3>
<a href="https://kubernetes.io/docs/concepts/services-networking/service" target="_blank" rel="nofollow noopener">Services</a> are used to expose Pods to the network. They allow defined access to Pods either within your cluster or externally.
<a href="https://kubernetes.io/docs/concepts/services-networking/ingress" target="_blank" rel="nofollow noopener">Ingresses</a> are closely related objects. These are used to set up HTTP routes to services via a load balancer. Ingresses also support HTTPS traffic secured by TLS certificates.
Read more: <a href="https://spacelift.io/blog/kubernetes-ingress">Kubernetes Ingress with NGINX Ingress Controller Example</a>
<h3>Jobs</h3>
A Kubernetes <a href="https://kubernetes.io/docs/concepts/workloads/controllers/job" target="_blank" rel="nofollow noopener">Job</a> is an object that creates a set of Pods and waits for them to terminate. It will retry any failed Pods until a specified number have exited successfully. The Job&#8217;s then marked as complete.
Jobs provide a mechanism for running ad-hoc tasks inside your cluster. Kubernetes also provides <a href="https://spacelift.io/blog/kubernetes-cronjob" target="_blank" rel="noopener">CronJobs</a> that wrap Jobs with <a href="https://en.wikipedia.org/wiki/Cron" target="_blank" rel="nofollow noopener">cron-like</a> scheduling support. These let you automatically run a job on a regular cadence to accommodate batch activities, backups, and any other scheduled tasks your application requires.
<h3>Volumes</h3>
<a href="https://kubernetes.io/docs/concepts/storage/volumes" target="_blank" rel="nofollow noopener">Volumes</a> mount external filesystem storage inside your Pods. They abstract away the differences between different cloud providers&#8217; storage implementations.
Volumes can and shared between your Pods. This allows Kubernetes to run stateful applications where data must be preserved after a Pod gets terminated or rescheduled. You&#8217;ll need to use a volume whenever you&#8217;re running a database or file server in your cluster.
<h3>Secrets and ConfigMaps</h3>
<a href="https://spacelift.io/blog/kubernetes-secrets" target="_blank" rel="noopener">Secrets</a> are used to inject sensitive data into your cluster such as API keys, certificates, and other kinds of credential. They can be supplied to Pods as environment variables or files mounted into a volume.
<a href="https://kubernetes.io/docs/concepts/configuration/configmap" target="_blank" rel="nofollow noopener">ConfigMaps</a> are a similar concept for non-sensitive information. These objects should store any general settings your app requires.
<h3>DaemonSets</h3>
<a href="https://kubernetes.io/docs/concepts/workloads/controllers/daemonset" target="_blank" rel="nofollow noopener">DaemonSets</a> are used to reliably run a copy of a Pod on each of the Nodes in your cluster. When a new Node joins, it will automatically start an instance of the Pod. You can optionally <a href="https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/#running-pods-on-select-nodes" target="_blank" rel="nofollow noopener">restrict DaemonSet Pods</a> to only running on specific Nodes in more advanced situations.
DaemonSets are useful when you’re adding global functionality to your cluster. DaemonSets are often used to run monitoring services and log aggregation agents. Placing these workloads into a DaemonSet guarantees they’ll always be running adjacent to your application’s Pods. It ensures metrics and logs will be collected irrespective of the Node a Pod gets scheduled to.
<h3>Networking Policies</h3>
Kubernetes supports a <a href="https://kubernetes.io/docs/concepts/services-networking/network-policies" target="_blank" rel="nofollow noopener">policy-based system</a> for controlling network traffic flows between your Pods. You can isolate sensitive Pods from other resources to prevent attackers moving through your infrastructure.
Network policies are expressed as an object that targets one or more matching Pods. Each Pod can be the subject of both ingress and egress policies. Ingress policies define whether incoming traffic is allowed, while egress rules affect outbound flows. Communications between two Pods are only permitted when no networking policy on either Pod denies ingress or egress from the other.
Learn more: <a href="https://spacelift.io/blog/kubernetes-architecture" target="_blank" rel="noopener">What Is Kubernetes Architecture?</a>

Now you&#8217;re familiar with the basics, you can start adding workloads to your cluster with Kubectl. Here&#8217;s a quick reference for some key commands.
<h3>List Pods</h3>
This displays the Pods in your cluster:

Specify a namespace with the <code>-n</code> or <code>--namespace</code> flag:

Alternatively, get Pods from all your namespaces by specifying <code>--all-namespaces</code>:

This includes Kubernetes system components.

<h3>Create a Pod</h3>
Create a Pod with the following command:

This starts a Pod called nginx that will run the nginx:latest container image.

<h3>Create a Deployment</h3>
Creating a Deployment lets you scale multiple replicas of a container:

You&#8217;ll see three Pods are created, each running the nginx:latest image:

<h3>Scale a Deployment</h3>
Now use this command to increase the replica count:

Kubernetes has created two extra Pods to provide additional capacity:

<h3>Expose a Service</h3>
Now let&#8217;s make this NGINX server accessible.
Run the following command to create a service that&#8217;s exposed on a port of the Node running the Pods:

Discover the port that&#8217;s been assigned by running this command:

The port is 30226. Visiting &lt;node-ip&gt;:30226 in your browser will show the default NGINX landing page.
You can use localhost as &lt;node-ip&gt; if you&#8217;ve been following along with the single-node K3s cluster created in this tutorial. Otherwise run the get nodes command and use the INTERNAL-IP that&#8217;s displayed.

<h3>Using Port Forwarding</h3>
You can access a service without binding it to a Node port by using Kubectl’s integrated port-forwarding functionality. Delete your first service and create a new one without the <code>--type</code> flag:

This creates a ClusterIP service that can be accessed on an internal IP, within the cluster.
Retrieve the service’s details by running this command:

The service can be accessed inside the cluster at 10.100.191.238:80.
You can reach this address from your local machine with the following command:

Visiting localhost:8080 in your browser will display the NGINX landing page. Kubectl is redirecting traffic to the service inside your cluster. You can press Ctrl+C in your terminal to stop the port forwarding session when you’re done.
Port forwarding works without services too. You can directly connect to a Pod in your deployment with this command:

Visiting localhost:8080 will again display the NGINX landing page, this time without going through a service.

<h3>Apply a YAML File</h3>
Finally, let&#8217;s see how to apply a declarative YAML file to your cluster. First write a <a href="https://kubernetes.io/docs/concepts/workloads/pods/#using-pods" target="_blank" rel="nofollow noopener">simple manifest</a> for your Pod:

Save this manifest to nginx.yaml and run <code>kubectl apply</code> to automatically create your Pod:

You can repeat the command after you modify the file to apply any changes to your cluster.
Now you&#8217;re familiar with the basics of using Kubectl to interact with Kubernetes!
Anything that can be run via kubectl can be run within a Spacelift stack. <a href="https://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’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>. Find out more about <a href="https://docs.spacelift.io/vendors/kubernetes/" target="_blank" rel="noopener">how Spacelift works with Kubernetes</a>.

Kubernetes is the leading container orchestrator. In this article, we&#8217;ve explored its features, looked at how it works, and covered the most important object types you&#8217;ll use to assemble your applications.
Beyond the theory, you&#8217;ve also seen how to start your own Kubernetes cluster with the popular K3s distribution. Now you can build and run your own containerized systems at scale with minimal manual configuration. You&#8217;re ready to continue your Kubernetes adventure by moving to more advanced topics &#8211; look out for future posts on our <a href="https://spacelift.io/blog/kubernetes">blog</a>!

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.

5 Different Types of Kubernetes Deployment Strategies

Enable Auto-completion for Kubectl in a Linux Bash Shell

In this beginners Kubernetes tutorial, you'll learn what Kubernetes can do and how to get started running your own containerized solutions.

kubernetes-tutorial-2

kubernetes-tutorial

In this article, we explore the Ingress object in Kubernetes (K8S), and look at how it can be used with some examples. We will then walk step-by-step through setting up an NGINX Ingress controller with Azure Kubernetes Service (AKS).

Ingress in K8S is an object that allows access to services within your <a href="https://spacelift.io/blog/kubernetes-cluster" target="_blank" rel="noopener">cluster</a>, from outside your cluster.
The official documentation on kubernetes.io describes Ingress:
<blockquote class="mo mp mq">
An API object that manages external access to the services in a cluster, typically HTTP. Ingress may provide load balancing, SSL termination and name-based virtual hosting.
</blockquote>
Traffic routing is defined by rules specified on the Ingress resource.
Ingress objects refer to allowing HTTP or HTTPS traffic through to your cluster services. They do not expose other ports or protocols to the wider world. For this, a service type of LoadBalancer or NodePort should be used.
A service is an external interface to a logical set of Pods. Services use a &#8216;virtual IP address&#8217; local to the cluster, external services would have no way to access these IP addresses without an Ingress.

Ingress, LoadBalancer, and NodePort are all ways of exposing services within your K8S cluster for external consumption.
NodePort and LoadBalancer let you expose a service by specifying that value in the service’s type.
With a NodePort, K8S allocates a specific port on each node to the service specified. Any request received on the port by the cluster simply gets forwarded to the service.
With a LoadBalancer, there needs to be an external service outside of the K8S cluster to provide the public IP address. In Azure, this would be an Azure Application Gateway in front of your Azure Kubernetes Service (AKS) cluster. In AWS, this would be an Application Load Balancer (ALB) in front of your Elastic Kubernetes Service (EKS), and in Google cloud, this would be a Network Load Balancer in front of your Google Kubernetes Engine (GKE) cluster.
Each time a new service is exposed, a new LoadBalancer needs to be created to get a public IP address. Conveniently, the Load balancer provisioning happens automatically for you because of the way the Cloud providers plugin to Kubernetes, so that doesn’t have to be done separately.
Ingress is a completely independent resource to your service. As well as enabling routing rules to be consolidated in one place (the Ingress object), this has the advantage of being a separate, decoupled entity that can be created and destroyed separately from any services.

To set up Ingress in K8S, you need to configure an Ingress controller. These do not come as default with the cluster and must be installed separately. An ingress controller is typically a reverse web proxy server implementation in the cluster.
There are many available Ingress controllers, all of which have different features. The official documentation lists the available Ingress controllers. A few commonly used ones include:
<ul class="">
<li id="46c2" class="mv mw in ke b kf kg ki kj kl mx kp my kt mz kx na nb nc nd gr" data-selectable-paragraph=""><a class="au ln" href="https://docs.microsoft.com/azure/application-gateway/tutorial-ingress-controller-add-on-existing?toc=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fazure%2Faks%2Ftoc.json&amp;bc=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fazure%2Fbread%2Ftoc.json" target="_blank" rel="noopener ugc nofollow">AKS Application Gateway Ingress Controller</a> is an ingress controller that configures the <a class="au ln" href="https://docs.microsoft.com/azure/application-gateway/overview" target="_blank" rel="noopener ugc nofollow">Azure Application Gateway</a>.</li>
<li id="655b" class="mv mw in ke b kf ne ki nf kl ng kp nh kt ni kx na nb nc nd gr" data-selectable-paragraph=""><a class="au ln" href="https://github.com/kubernetes/ingress-gce" target="_blank" rel="noopener ugc nofollow">GKE Ingress Controller for Google Cloud</a></li>
<li id="7621" class="mv mw in ke b kf ne ki nf kl ng kp nh kt ni kx na nb nc nd gr" data-selectable-paragraph=""><a class="au ln" href="https://docs.aws.amazon.com/eks/latest/userguide/alb-ingress.html" target="_blank" rel="noopener ugc nofollow">AWS Application Load Balancer Ingress Controller</a></li>
<li id="2e85" class="mv mw in ke b kf ne ki nf kl ng kp nh kt ni kx na nb nc nd gr" data-selectable-paragraph=""><a class="au ln" href="https://haproxy-ingress.github.io/" target="_blank" rel="noopener ugc nofollow">HAProxy Ingress</a> is an ingress controller for <a class="au ln" href="https://www.haproxy.org/#desc" target="_blank" rel="noopener ugc nofollow">HAProxy</a>.</li>
<li id="ad9c" class="mv mw in ke b kf ne ki nf kl ng kp nh kt ni kx na nb nc nd gr" data-selectable-paragraph=""><a class="au ln" href="https://istio.io/latest/docs/tasks/traffic-management/ingress/kubernetes-ingress/" target="_blank" rel="noopener ugc nofollow">Istio Ingress</a> is an <a class="au ln" href="https://istio.io/" target="_blank" rel="noopener ugc nofollow">Istio</a> based ingress controller.</li>
<li id="e30a" class="mv mw in ke b kf ne ki nf kl ng kp nh kt ni kx na nb nc nd gr" data-selectable-paragraph="">The <a class="au ln" href="https://www.nginx.com/products/nginx-ingress-controller/" target="_blank" rel="noopener ugc nofollow">NGINX Ingress Controller for Kubernetes</a> works with the <a class="au ln" href="https://www.nginx.com/resources/glossary/nginx/" target="_blank" rel="noopener ugc nofollow">NGINX</a> webserver (as a proxy).</li>
<li id="3162" class="mv mw in ke b kf ne ki nf kl ng kp nh kt ni kx na nb nc nd gr" data-selectable-paragraph="">The <a class="au ln" href="https://doc.traefik.io/traefik/providers/kubernetes-ingress/" target="_blank" rel="noopener ugc nofollow">Traefik Kubernetes Ingress provider</a> is an ingress controller for the <a class="au ln" href="https://traefik.io/traefik/" target="_blank" rel="noopener ugc nofollow">Traefik</a> proxy.</li>
</ul>
You can have multiple ingress controllers in a cluster mapped to multiple load balancers should you wish!
Learnk8s has a fantastic feature <a class="au ln" href="https://docs.google.com/spreadsheets/d/191WWNpjJ2za6-nbG4ZoUMXMpUK8KlCIosvQB0f-oq3k/edit#gid=907731238" target="_blank" rel="noopener ugc nofollow">comparison of all the available ingress controllers</a> to help you make your choice. Note the limitations of the Azure application gateway ingress controller. For now, the NGINX Ingress Controller seems like a better choice…

<ul>
<li><a href="https://spacelift.io/blog/terraform-vs-kubernetes"><span data-sheets-value="{&quot;1&quot;:2,&quot;2&quot;:&quot;What is difference between Terraform and Kubernetes?\r&quot;}" data-sheets-userformat="{&quot;2&quot;:513,&quot;3&quot;:{&quot;1&quot;:0},&quot;12&quot;:0}">What is the difference between Terraform and Kubernetes?</a></li>
<li><a href="https://spacelift.io/blog/how-specialized-solution-can-improve-your-iac"><span data-sheets-value="{&quot;1&quot;:2,&quot;2&quot;:&quot;10 Ways to Improve Your Infrastructure as Code&quot;}" data-sheets-userformat="{&quot;2&quot;:513,&quot;3&quot;:{&quot;1&quot;:0},&quot;12&quot;:0}">10 Ways to Improve Your Infrastructure as Code</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>

NGINX is a widely used Ingress controller, we will run through how to set this up with Azure Kubernetes Service. We will set up two simple web services and use the NGINX Ingress to route the traffic accordingly.
<h3>Step 1 &#8211; Fire up your AKS cluster and connect to it</h3>
To do this, browse to the AKS cluster resource in the Azure Portal and click on connect. The commands needed to connect via your shell using the Azure CLI will be shown.
<h3>Step 2 &#8211; Install the NGINX Ingress controller</h3>
It will install the controller in the <code class="gq og oh oi oj b">ingress-nginx</code> namespace, creating that namespace if it doesn&#8217;t already exist.

Keep all of your kubectl commands in one place with our <a href="https://spacelift.io/blog/kubernetes-cheat-sheet" target="_blank" rel="noopener">Kubernetes Cheat Sheet</a>.

kubernetes-ingress-install-nginx

kubernetes ingress - install nginx

Note you can also use Helm to install if you have it installed (you don’t need to run this if you have already installed using the previous command):

<h3>Step 3 &#8211; Check the Ingress controller pod is running</h3>

kubernetes-ingress-checking-nginx

kubernetes ingress - checking nginx

<h3>Step 4 &#8211; Check the NGINX Ingress controller has been assigned a public Ip address</h3>

Note the service type is LoadBalancer:

kubernetes-ingress-loadbalancer

kubernetes ingress - loadbalancer

Browsing to this IP address will show you the NGINX 404 page. This is because we have not set up any routing rules for our services yet.

kubernetes-ingress-nginx-404

kubernetes ingress - nginx 404

<h3>Step 5 &#8211; Set up a basic web app for testing our new Ingress controller</h3>
First, we need to set up a DNS record pointing to the External IP address we discovered in the previous step. Once that is set, run the following command to set up a demo (replace the [DNS_NAME] with your record, e.g. www.jackwesleyroper.io).
Note that you must set up a DNS record, this step will not work with an IP address. This command comes from the NGINX documentation, we will look at declarative approaches later in this article.

<h3 id="7a30" class="pw-post-body-paragraph kc kd in ke b kf kg jo kh ki kj jr kk kl km kn ko kp kq kr ks kt ku kv kw kx ig gr">Step 6 &#8211; Browse to the web address</h3>
You will see ‘It works!’ displayed, confirming that the Ingress controller is correctly routing traffic to the demo app.
<h3 id="1eea" class="pw-post-body-paragraph kc kd in ke b kf kg jo kh ki kj jr kk kl km kn ko kp kq kr ks kt ku kv kw kx ig gr">Step 7 &#8211; Set up two more web apps</h3>
Now we will set up two more web apps, and route traffic between them using NGINX.
We will create two YAML files using the demo apps from the official Azure documentation.
aks-helloworld-one.yaml

aks-helloworld-two.yaml

Apply the two configuration files to setup the apps:

kubernetes-ingress-configuration-file-one

kubernetes ingress - configuration file one

kubernetes-ingress-configuration-file-two

kubernetes ingress - configuration file two

Check the new pods are running (you should see two <code>aks-helloworld</code> pods running):

kubernetes-ingress-kubectl-get-pods

kubernetes ingress - kubectl get pods

<h3 id="8348" class="pw-post-body-paragraph kc kd in ke b kf kg jo kh ki kj jr kk kl km kn ko kp kq kr ks kt ku kv kw kx ig gr">Step 8 &#8211; Setup the Ingress to route traffic between the two apps</h3>
We will set up path-based routing to direct traffic to the appropriate web apps based on the URL the user enters. EXTERNAL_IP/hello-world-one is routed to the service named <code class="gq og oh oi oj b">aks-helloworld-one</code>. Traffic to EXTERNAL_IP/hello-world-two is routed to the <code class="gq og oh oi oj b">aks-helloworld-two</code> service. Where the path is not specified by the user (EXTERNAL_IP/), the traffic is routed to <code class="gq og oh oi oj b">aks-helloworld-one</code>.
Create a file named hello-world-ingress.yaml.

kubernetes-ingress-ingress

kubernetes ingress - ingress

<h3>Step 9 &#8211; Browse to the EXTERNAL_IP/hello-world-one</h3>

kubernetes-ingress-welcome-one

kubernetes ingress - welcome one

And EXTERNAL_IP/hello-world-two:

kubernetes-ingress-welcome-two

kubernetes ingress - welcome two

An Ingress in K8S is a robust way to expose services within your K8S cluster to the outside world. It allows you to consolidate routing rules in one place. There are many available Ingress controllers available for use, in this article, we configured an NGINX Ingress on AKS and used it to route traffic between two demo apps.
For more information on Kubernetes Ingress, check out the <a href="https://kubernetes.io/docs/concepts/services-networking/ingress/" target="_blank" rel="nofollow noopener">Kubernetes documentation</a>, <a href="https://kubernetes.github.io/ingress-nginx/deploy/" target="_blank" rel="nofollow noopener">Kubernetes GitHub</a> and <a href="https://docs.microsoft.com/en-us/azure/aks/ingress-basic?tabs=azure-cli#create-an-ingress-controller" target="_blank" rel="nofollow noopener">AKS documentation</a>.
And if you want to learn how Spacelift can help you with Kubernetes management, see <a href="https://docs.spacelift.io/vendors/kubernetes/" target="_blank" rel="noopener">Spacelift documentation</a>. Anything that can be run via kubectl can be run within a Spacelift stack.

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.

Managing Azure Resources using Spacelift

How to Provision Azure AKS Cluster Using Terraform

Explore the Kubernetes Ingress object and see a step-by-step tutorial on how to configure an NGINX Ingress on AKS.

107-kubernetes-ingress

Kubernetes Ingress & Examples

Kubernetes Ingress with NGINX Ingress Controller Example

In this short post, we will demonstrate how to install kubectl, setup up auto-completion, and set an alias for kubectl in your bash shell.
When using kubectl commands to interact with your <a href="https://spacelift.io/blog/kubernetes-cluster" target="_blank" rel="noopener">Kubernetes cluster</a> (K8S), auto-completion can be very useful to avoid having to reference a cheat sheet constantly!
Setting an alias for kubectl on the command line, (commonly as <code class="gr kj kk kl km b">k</code> ), also helps save a lot of time when managing your cluster, and is also recommended for the CKA administrator exam as it is very time limited.

1. Open your bash shell. Type <code class="gr kj kk kl km b">kubectl</code>. If you see the message ‘kubectl: command not found’, follow these steps to install <code class="gr kj kk kl km b">kubectl</code>. If it is installed, skip to Step 7.

kubectl-autocompletion

kubectl autocompletion

2. Download the latest <code class="gr kj kk kl km b">kubectl</code> release with the command:

3. Download the checksum file:

4. Validate the kubectl binary against the checksum file:

5. Install kubectl:

6. Type <code class="gr kj kk kl km b">kubectl</code> . You should now see the tool is installed.

kubectl-autocompletion-installation

kubectl autocompletion - installation

<ul>
<li><a href="https://spacelift.io/blog/terraform-vs-kubernetes" target="_blank" rel="noopener"><span data-sheets-value="{&quot;1&quot;:2,&quot;2&quot;:&quot;What is the difference between Terraform and Kubernetes?&quot;}" data-sheets-userformat="{&quot;2&quot;:513,&quot;3&quot;:{&quot;1&quot;:0},&quot;12&quot;:0}">What is the difference between Terraform and Kubernetes?</a></li>
<li><a href="https://spacelift.io/blog/how-specialized-solution-can-improve-your-iac" target="_blank" rel="noopener"><span data-sheets-value="{&quot;1&quot;:2,&quot;2&quot;:&quot;10 Ways to Improve Your Infrastructure as Code&quot;}" data-sheets-userformat="{&quot;2&quot;:513,&quot;3&quot;:{&quot;1&quot;:0},&quot;12&quot;:0}">10 Ways to Improve Your Infrastructure as Code</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>

7. Check if <code class="gr kj kk kl km b">bash-completion</code> is already installed:

If it is already installed, you will see something like the following:

kubectl-autocompletion-bash-completion

kubectl autocompletion - bash-completion

If it is not installed, install using apt or yum, depending on which package manager you are using (usually apt for Ubuntu):

8. Set the kubectl completion script source for your shell sessions:
For all users on the system:

9. Reload your bash shell. Type <code class="gr kj kk kl km b">kubectl -</code> followed by pressing tab twice to see the available options and verify auto-complete is working:

kubectl-autocompletion-reload-your-bash-shell

kubectl autocompletion - Reload your bash shell

10. Set an alias for kubectl as <code class="gr kj kk kl km b">k</code>.

11. Enable the alias for auto-completion.

12. Reload your bash shell. Type <code class="gr kj kk kl km b">k -</code> followed by pressing tab twice to see the available options and verify auto-complete is working with the alias.

kubectl-autocompletion-reload-your-bash-shell-again

kubectl autocompletion - Reload your bash shell again

Enabling auto-completion for <code class="gr kj kk kl km b">kubectl</code> and setting an alias will save you time!
Additionally, Spacelift can help you manage the complexities and compliance challenges of using Kubernetes. Anything that can be run via kubectl can be run within a Spacelift stack. Read more about <a href="https://docs.spacelift.io/vendors/kubernetes/" target="_blank" rel="noopener">how Spacelift works with Kubernetes</a>.
Cheers!

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.

Spacelift Worker Pools on Kubernetes with Spacelift

See this step-by-step tutorial and save time by enabling auto-completion for kubectl and setting an alias!

105-kubectl-autocomplition

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

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 an open-source software 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

<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.

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 DevOps tools, 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.

Provision a Kubernetes Cluster with Spacelift and Terraform

Terraform vs. Ansible : Key Differences and Comparison of Tools

Terraform vs. AWS CloudFormation : The Ultimate Comparison

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.

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!
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><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/terraform-vs-kubernetes" target="_blank" rel="noopener"><span data-sheets-value="{&quot;1&quot;:2,&quot;2&quot;:&quot;Terraform vs. Kubernetes : Key Differences and Comparison&quot;}" data-sheets-userformat="{&quot;2&quot;:513,&quot;3&quot;:{&quot;1&quot;:0},&quot;12&quot;:0}">Terraform vs. Kubernetes Comparison</a></li>
</ul>

<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.
<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, PersistentVolumes, 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.

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

How to Restart Kubernetes Pods With Kubectl

Get the newsletter

Recent posts

Kubernetes Tutorial for Beginners – Basic Concepts & Examples

Kubernetes Ingress with NGINX Ingress Controller Example

Enable Auto-completion for Kubectl in a Linux Bash Shell

Terraform vs. Kubernetes : Key Differences and Comparison

Kubectl Cheat Sheet – 15 Kubernetes Commands & Objects

5 Different Types of Kubernetes Deployment Strategies

What Is a Kubernetes Cluster? Key Components Explained

15 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