James Walker is the founder of Heron Web, a UK-based software development studio providing bespoke solutions for SMEs. He's experienced in delivering custom software using engineering workflows built around modern DevOps methodologies.

All post by James Walker - DevOps Expert

James Walker

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

What Is Argo CD? Practical Tutorial With Kubernetes

General | Spacelift Blog

General

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

Kubernetes

In this article, we&#8217;ll explore <a href="https://argo-cd.readthedocs.io/en/stable" target="_blank" rel="nofollow noopener">Argo</a>&#8216;s features and use it to run a simple demo application.
<a href="https://argoproj.github.io/cd/" target="_blank" rel="nofollow noopener">Argo CD</a> is &#8220;a declarative, GitOps continuous delivery tool for Kubernetes.&#8221; It can monitor your source repositories and automatically deploy changes to your cluster.
Kubernetes orchestrates <a href="https://spacelift.io/blog/kubernetes-tutorial" target="_blank" rel="noopener">container deployment and management</a> tasks. It starts your containers, replaces them when they fail, and scales your service across the compute nodes in your cluster.
Kubernetes is best used as part of a continuous delivery workflow. Running automated deployments when new code is merged ensures changes reach your cluster quickly after passing through a consistent pipeline.

ArgoCD is a popular tool for setting up continuous delivery with Kubernetes. It automates application deployment into Kubernetes clusters by continually reconciling your repository&#8217;s state against your live workloads.
The <a href="https://about.gitlab.com/topics/gitops" target="_blank" rel="nofollow noopener">GitOps model</a> is integral to Argo&#8217;s design. It makes the repository the single source of truth for your application&#8217;s desired state. All the Kubernetes manifests, Kustomize templates, Helm charts, and config files your app needs should be committed to your repository. These resources &#8220;declare&#8221; what a successful deployment of your app looks like.
Argo compares the declared state to what&#8217;s actually running in your cluster, then applies the correct changes to resolve any discrepancies. This process can be configured to run automatically, preventing your cluster from drifting away from your repository. Argo resynchronizes the state whenever differences occur, such as after you manually run Kubectl commands.
Argo comes with both a CLI and web UI. It supports multi-tenant and multi-cluster environments, integrates with SSO providers, produces an audit trail, and can implement complex rollout strategies such as canary deployments and blue/green upgrades. It also offers integrated rollbacks so you can quickly recover from deployment failures.
<h3>Push vs. Pull-based CI/CD</h3>
Historically, most CI/CD implementations have relied on push-driven behavior. This requires you to connect your cluster to your CI/CD platform, then use tools like Kubectl and Helm within your pipeline to apply Kubernetes changes.
Argo is a pull-based CI/CD system. It runs inside your Kubernetes cluster and pulls source from your repositories. Argo then applies the changes for you without a manually configured pipeline.
This model is more secure than push-based workflows. You don&#8217;t have to expose your cluster&#8217;s API server or store Kubernetes credentials in your CI/CD platform. Compromising a source repository only gives an attacker access to your code instead of the code and a route to your live deployments.

Argo is easy to learn once you understand its <a href="https://argo-cd.readthedocs.io/en/stable/core_concepts" target="_blank" rel="nofollow noopener">basic concepts</a>. Here are some terms to get familiar with.
<ul>
<li style="font-weight: 400;" aria-level="1">Argo controller &#8211; Argo&#8217;s Application Controller <a href="https://argo-cd.readthedocs.io/en/stable/operator-manual/architecture/#application-controller" target="_blank" rel="nofollow noopener">is the component</a> you install in your cluster. It implements the <a href="https://kubernetes.io/docs/concepts/architecture/controller" target="_blank" rel="nofollow noopener">Kubernetes controller pattern</a> to monitor your applications and compare their state against their repositories.</li>
<li style="font-weight: 400;" aria-level="1">Application &#8211; An Argo application is a group of Kubernetes resources which collectively deploy your workload. Argo stores the details of applications in your cluster as instances of an included <a href="https://spacelift.io/blog/kubernetes-crd" target="_blank" rel="noopener">Custom Resource Definition (CRD)</a>.</li>
<li style="font-weight: 400;" aria-level="1">Live state &#8211; The live state is the current state of your application inside the cluster, such as the number of Pods created and the image they&#8217;re running.</li>
<li style="font-weight: 400;" aria-level="1">Target state &#8211; The target state is the version of the state that&#8217;s declared by your Git repository. When the repository changes, Argo will apply actions that evolve the live state into the target state.</li>
<li style="font-weight: 400;" aria-level="1">Refresh &#8211; A refresh occurs when Argo fetches the target state from your repository. It will compare the changes against the live state but doesn’t necessarily apply them at this stage.</li>
<li style="font-weight: 400;" aria-level="1">Sync &#8211; A Sync is the process of applying the changes discovered by a Refresh. Each Sync moves the cluster back towards the target state.</li>
</ul>
Now we&#8217;ve covered the core concepts, we can use Argo to deploy an example app to Kubernetes. You can read more about Argo&#8217;s <a href="https://argo-cd.readthedocs.io/en/stable/core_concepts" target="_blank" rel="nofollow noopener">terminology</a> and the <a href="https://argo-cd.readthedocs.io/en/stable/operator-manual/architecture" target="_blank" rel="nofollow noopener"> tool&#8217;s architecture</a> in the official docs.

Let&#8217;s use Argo to run a basic <a href="https://hub.docker.com/_/nginx" target="_blank" rel="nofollow noopener">NGINX web server</a> instance in Kubernetes. We&#8217;ll assume you&#8217;ve already got access to a Kubernetes cluster, and you&#8217;ve got the <a href="https://kubernetes.io/docs/tasks/tools" target="_blank" rel="nofollow noopener"> Kubectl</a> and <a href="https://helm.sh" target="_blank" rel="nofollow noopener">Helm</a> CLIs available on your machine.
<h3>Create Your App&#8217;s GitHub Repository</h3>
First, head to GitHub and create a new repository for your app. Afterward, clone your repo to your machine, ready to commit your Kubernetes manifests:

Copy the following YAML and save it as <code>deployment.yaml</code> inside your repository:

It defines a basic Kubernetes <a href="https://kubernetes.io/docs/concepts/workloads/controllers/deployment" target="_blank" rel="nofollow noopener">Deployment object</a> that runs three NGINX replicas.
Next, copy this second YAML file and save it to <code>service.yaml</code>. It sets up a <a href="https://kubernetes.io/docs/concepts/services-networking/service/#loadbalancer" target="_blank" rel="nofollow noopener">LoadBalancer</a> service to expose your Deployment outside your cluster:

Finally, add a manifest that will create your application’s namespace:

Commit your changes to your repository, then push them up to GitHub:

You&#8217;re ready to install Argo and start deploying your app.

install-argo-cd

install argo cd

<h3>Get the Argo CLI</h3>
Argo&#8217;s CLI lets you interact with your applications from your terminal. You&#8217;ll need it later to register your app with your Argo instance.
You can download the latest CLI release from <a href="https://github.com/argoproj/argo-cd/releases" target="_blank" rel="nofollow noopener">GitHub</a>. Select the right binary for your platform, then make it executable and move it to a location in your path. The following steps work for most Linux systems &#8211; substitute the latest version number instead of 2.6.1 below, first:

Check you can now run <code>argocd</code> commands:

The CLI&#8217;s also distributed in <a href="https://brew.sh" target="_blank" rel="nofollow noopener">Homebrew</a>’s package list. Use the <code>brew install</code> command to add <code>argocd</code> to your system using this method:

<ul>
<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/why-devops-engineers-recommend-spacelift" target="_blank" rel="noopener">Why DevOps Engineers Recommend Spacelift</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>

<h3>Install Argo In Your Cluster</h3>
Next, install Argo in your Kubernetes cluster. This will add the Argo CD API, controller, and Custom Resource Definitions (CRDs).
Begin by creating a namespace for Argo:

Next, use Kubectl to apply Argo CD&#8217;s YAML manifest to your cluster. You can <a href="https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml" target="_blank" rel="nofollow noopener"> inspect the manifest</a> before you use it to see the resources that&#8217;ll be created.

It can take several seconds for all of Argo&#8217;s components to be running in your cluster. Monitor progress by using Kubectl to list the deployments in the <code>argocd</code> namespace. 
You can continue once the deployments are ready:

<h3>Connecting to Argo</h3>
Argo CD doesn&#8217;t automatically expose its API server on an external IP. You can connect to it by starting a new Kubectl port-forwarding session instead. Open another terminal window and run the following command:

This redirects your local port 8080 to port 443 of Argo&#8217;s service. Visit <code>localhost:8080</code> in your browser to access the Argo UI. You&#8217;ll be warned that the page is insecure because it uses a self-signed certificate. 
You can continue with this setup while you&#8217;re experimenting, but you should <a href="https://argo-cd.readthedocs.io/en/stable/operator-manual/tls" target="_blank" rel="nofollow noopener">follow the detailed steps</a> in the Argo docs to configure TLS with an Ingress route before you move to production.

argo-cd-login

argo cd login

Before you can login, you need to retrieve the password for the default admin user. This is generated automatically during Argo’s installation process. You can access it by running the following <code>argocd</code> command:

Use these credentials to login to Argo. 
Once you&#8217;re in, head straight to the User Info item in the left sidebar, then click the &#8220;Update Password&#8221; button at the top of the screen. Follow the prompts to change your password to something unique.

argo-cd-update-password

argo cd Update Password

Now you can delete the Kubernetes secret that contains the original password for the admin account:

Login to the CLI
To login to the Argo CLI, run <code>argocd login</code> and supply the API server&#8217;s URL as an argument:

Similarly to the browser warning encountered above, you&#8217;ll be prompted to accept Argo&#8217;s built-in self-signed certificate if you haven&#8217;t configured your own TLS:

Accept the prompt by typing y and pressing return. You&#8217;ll then be asked to enter your username and password. The CLI should successfully authenticate to your Argo instance:

<h3>Deploying Your App With Argo</h3>
Everything&#8217;s ready to start deploying apps to Argo! First, run the following CLI command to register your app:

Let&#8217;s unpack what&#8217;s happening here:
<ul>
<li style="font-weight: 400;" aria-level="1">The <code>--repo</code> flag specifies the URL of your Git repository.</li>
<li style="font-weight: 400;" aria-level="1">The <code>--path</code> flag instructs Argo to search for Kubernetes manifests, Helm charts, and other deployable assets inside this path within your repo. <code>.</code> is used here because the example manifests are stored in the repo’s root.</li>
<li style="font-weight: 400;" aria-level="1">The <code>--dest-server</code> flag specifies the URL of the Kubernetes cluster to deploy to. You can use <code>kubernetes.default.svc</code> when you&#8217;re deploying to the same cluster that Argo&#8217;s running in.</li>
<li style="font-weight: 400;" aria-level="1"><code>--dest-namespace</code> sets the Kubernetes namespace that your app will be deployed into. This should match the <code>metadata.namespace</code> fields set on your resources.</li>
</ul>
Your app will now be registered with Argo. You can retrieve its details with the <code>argocd app list</code> command:

The app also shows up in the Argo UI:

argo-cd-ui

argo cd ui

Your First Sync
The app shows as &#8220;missing&#8221; and &#8220;out of sync.&#8221; Creating the app doesn&#8217;t automatically sync it into your cluster. Perform a sync now to have Argo apply the target state currently defined by your repo&#8217;s content:

The sync results display in your terminal. You should see the Namespace, Service, and Deployment objects all get synced into your cluster, as in the command output above. The messages for all three objects confirm they were created successfully.
Repeat the <code>apps list</code> command to check the app’s new status:

Now the app is Synced and Healthy! It&#8217;s also green in the Argo UI:

argo-cd-synced-app

argo cd synced app

As a final proof, use Kubectl to inspect the deployments in the app&#8217;s namespace. This should confirm that <code>nginx</code> is up and running three replicas:

<h3>Syncing App Updates</h3>
Now let&#8217;s make a change to our app. Modify the <code>spec.replicas</code> field in your <code>deployment.yaml</code> so there&#8217;s now five Pods in the Deployment:

Commit and push your changes:

Next, repeat the <code>argocd app sync</code> command to apply your changes to your cluster. 
Alternatively, you can click the &#8220;Sync&#8221; button within the user interface.

Argo refreshes your app&#8217;s target state from the repo, then takes action to transition the live state. The Deployment is reconfigured and now runs five Pods:

Enabling Auto-Sync
The change to five replicas didn&#8217;t apply until you repeated the sync command. Argo can automatically sync changes from your repo though, eliminating the need to issue the command each time. This fully automates your delivery workflow.
You can activate auto-sync for an app by clicking the &#8220;App Details&#8221; button within the user interface and scrolling down to the &#8220;Sync Policy&#8221; section. Click the &#8220;Enable Auto-Sync&#8221; button.

argo-cd-enabling-auto-sync

argo cd Enabling Auto-Sync

Auto-sync can also be enabled using the CLI by running the following command:

To test auto-sync out, revert the <code>spec.replicas</code> field back to three replicas:

Commit and push the change:

This time Argo will automatically detect the repository&#8217;s state change. You should see your Deployment scale back to 3 replicas within a few minutes of pushing the commit:

Auto-sync runs <a href="https://argo-cd.readthedocs.io/en/stable/user-guide/auto_sync/#automated-sync-semantics" target="_blank" rel="nofollow noopener">every three minutes</a> by default. You can change this value by <a href="https://argo-cd.readthedocs.io/en/stable/faq/#how-often-does-argo-cd-check-for-changes-to-my-git-or-helm-repository" target="_blank" rel="nofollow noopener">modifying Argo&#8217;s config map</a>, if you need more frequent deployments.
Managing Your App
Argo&#8217;s CLI and web app offer extensive options for managing and monitoring your deployments. While these are outside the scope of this beginner&#8217;s tutorial, you can start exploring <a href="https://argo-cd.readthedocs.io/en/stable/user-guide/commands/argocd" target="_blank" rel="nofollow noopener">the CLI commands</a> and UI panels to take control of your app. Most features are implemented in both interfaces.

argo-cd-managing-your-app

argo cd Managing Your App

Clicking your app&#8217;s tile from the homescreen displays an overview that visualizes its components with their current sync and health states. You can view the app&#8217;s details, edit its config, and view events that describe Argo&#8217;s activity by clicking the &#8220;App Details&#8221; button in the top-left.
You can access previous deployments via the &#8220;History and Rollback&#8221; button. This lists all the syncs that Argo has performed, including an option to restore an older version. If a deployment introduces a bug, you can use this screen to rollback before you push a fix to your repo.

<a href="https://argo-cd.readthedocs.io/en/stable" target="_blank" rel="nofollow noopener">Argo CD</a> is a continuous delivery tool for Kubernetes. It provides a pull-based GitOps workflow for automatically synchronizing source repositories with in-cluster deployments. While this article has only covered the basics, Argo gives you a complete toolkit for deploying your apps, inspecting their health, and quickly rolling back any failed changes.
Argo CD is an ideal solution for managing your Kubernetes workloads. It doesn&#8217;t handle how you provision and change your cluster infrastructure, though.
Try <a href="https://spacelift.io" target="_blank" rel="noopener">Spacelift&#8217;s CI/CD platform</a> to collaborate on infrastructure using multiple IaC providers, including Kubernetes, Ansible, and Terraform. Spacelift lets you visualize your resources, prevent drift, and help developers ship fast within precise policy-driven guardrails.

<span data-sheets-value="{&quot;1&quot;:2,&quot;2&quot;:&quot;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 for infrastructure management.&quot;}" data-sheets-userformat="{&quot;2&quot;:769,&quot;3&quot;:{&quot;1&quot;:0},&quot;11&quot;:4,&quot;12&quot;:0}">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 for infrastructure management.

Using Kubeconfig Files to Organize Kubernetes Cluster Access

Kubernetes Security : 6 Best Practices for 4C Security Model

5 Most Useful CI/CD Tools for DevOps in 2023

In this article we will cover the basics of Argo CD and show how to use it with Kubernetes.

163-argo-cd

What Is ArgoCD? A Practical Tutorial With Kubernetes

<dfn>Kubeconfig</dfn> files configure <a href="https://kubernetes.io/docs/tasks/tools" target="_blank" rel="nofollow noopener">Kubectl</a>, the default Kubernetes client tool. These essential files define the cluster Kubectl commands will target and the user credentials they&#8217;ll authenticate with.
Kubectl automatically loads the Kubeconfig file stored at <code>~/.kube/config</code>. You can access multiple clusters with one Kubectl installation by specifying a different file, either by setting the <code>KUBECONFIG</code> environment variable or using Kubectl&#8217;s <code>--kubeconfig</code> flag:

This approach is inconvenient when you have several different clusters, however. You need to remember the path to each Kubeconfig file and must specify it each time you run <a href="https://spacelift.io/blog/kubernetes-cheat-sheet" target="_blank" rel="noopener">Kubectl</a>.
A better alternative is to merge your files into one, then use Kubectl&#8217;s built-in config management features to switch between clusters seamlessly. Let&#8217;s see how.

Switching to a single Kubeconfig file lets you more efficiently organize your <a href="https://spacelift.io/blog/kubernetes-cluster" target="_blank" rel="noopener">Kubernetes cluster</a> access. 
Here are some of the benefits you&#8217;ll gain:
<ul>
<li style="font-weight: 400;" aria-level="1">One file can contain all your clusters and users. No more duplication of Kubeconfig files each time you need to connect as a new user account, or register an additional cluster.</li>
<li style="font-weight: 400;" aria-level="1">You can quickly switch between configs by running Kubectl commands. Kubectl natively supports multiple config contexts within a single Kubeconfig file. The CLI includes commands for inspecting your active context and switching to another &#8211; we&#8217;ll see these below.</li>
<li style="font-weight: 400;" aria-level="1">You don&#8217;t have to remember to set KUBECONFIG or &#8211;kubeconfig every time you use Kubectl. Kubeconfig contexts you select within Kubectl are automatically persisted until you make another change. You don&#8217;t have to repeat the &#8211;kubeconfig flag with every command, or restore the value of KUBECONFIG after you reopen your terminal window.</li>
<li style="font-weight: 400;" aria-level="1">You can easily inspect the file to view the complete list of clusters you&#8217;ve used. Ever forgotten which clusters you have access to, or misplaced an important Kubeconfig file? This is a common problem for admins working with multiple clusters, where Kubeconfigs can become scattered across your storage drives. When you use a single file, you can view all your clusters in one location.</li>
</ul>
These advantages mean a single Kubeconfig file is often the most effective option for Kubernetes developers and administrators. This doesn&#8217;t mean they’re always the best approach, though – in some situations, it can make sense to split up connections, such as when different files require unique security characteristics or are intended for specific situations.

Let&#8217;s get started adding some cluster connections to Kubeconfig. Use <a href="https://jamesdefabia.github.io/docs/user-guide/kubectl/kubectl_config_set-cluster" target="_blank" rel="nofollow noopener">the config set-cluster command</a> to register a new cluster. You must supply a name for the cluster, its API server URL, and the path to its TLS certificate authority file:

To add another cluster, simply repeat the command with different arguments:

If you&#8217;re running a local cluster without TLS, you can disable TLS verification instead of supplying certificate authority data:

View all the clusters present in your active Kubeconfig file with the config get-clusters command:

Next you need to add user credentials for each of your clusters. The <a href="https://jamesdefabia.github.io/docs/user-guide/kubectl/kubectl_config_set-credentials" target="_blank" rel="nofollow noopener"><code>config set-credentials</code> command</a> registers credentials in several different formats.
Specify the name of your new credentials entry as the command&#8217;s first argument. This name will be used to refer to the credentials when you link them to your cluster in the next step. 
Flags must also be set to supply the user&#8217;s authentication data. This example creates a user entry called <code>production-admin</code> that authenticates with a token:

Token-based auth is the correct method when your user is a service account created within Kubernetes. Use <code>--username</code> and <code>--password</code> instead if you&#8217;re using HTTP Basic Auth, or set <code>--client-certificate</code> and <code>--client-key</code> for <a href="https://kubernetes.io/docs/reference/access-authn-authz/authentication/#x509-client-certs" target="_blank" rel="nofollow noopener">certificate-based authentication</a>.
Repeat the command to add another user for your staging cluster:

After you&#8217;ve added your credentials, you can view them with the <code>config get-credentials</code> command:

Now you&#8217;re ready to link your clusters and credentials together as functioning configuration contexts. A context is a combination of cluster and credentials; Kubectl connects to the cluster specified by your selected context, using its configured credentials.
Contexts are created by the<a href="https://jamesdefabia.github.io/docs/user-guide/kubectl/kubectl_config_set-context" target="_blank" rel="nofollow noopener"> <code>config set-context</code> command</a>. Specify the name of your new context as the command&#8217;s argument, then set the <code>--cluster</code> and <code>--user</code> flags to reference the respective entries in your Kubeconfig file:

You can view the contexts within your Kubeconfig file by running <code>config get-contexts</code>:

<ul>
<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/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/infrastructure-problems-that-spacelift-solves" target="_blank" rel="noopener"><span data-sheets-value="{&quot;1&quot;:2,&quot;2&quot;:&quot;Common Infrastructure Challenges and How to Solve Them&quot;}" data-sheets-userformat="{&quot;2&quot;:513,&quot;3&quot;:{&quot;1&quot;:0},&quot;12&quot;:0}">Common Infrastructure Challenges and How to Solve Them</a></li>
</ul>

Once you&#8217;ve created your contexts, you can switch between them by running the<a href="https://jamesdefabia.github.io/docs/user-guide/kubectl/kubectl_config_use-context" target="_blank" rel="nofollow noopener"> <code>config use-context</code> command</a>. Kubectl will mark the specified context as the current one. The cluster and user it specifies will be targeted by all subsequent commands, until you switch away to a different context.

The currently selected context is indicated by an asterisk in the <code>get-contexts</code> command&#8217;s output:

You can override the current context for a specific command with Kubectl&#8217;s <code>--context</code> flag:

This avoids having to switch context twice when you need to quickly run one command against a particular cluster, then revert to the previous one.

Contexts can also specify a default namespace. Kubectl commands will target the namespace set in the context, unless you override it with the <code>--namespace</code> or <code>-n</code> flag.
To assign a namespace to a context, run <code>config set-context</code> and include the <code>--namespace</code> flag:

Kubectl merges your new config values with the context&#8217;s existing ones when you run <code>set-context</code>. You only need to supply new values for the fields you want to update.

Switching between contexts with <code>kubectl config use-context</code> is simpler and less repetitive than juggling separate Kubeconfig files with <code>KUBECONFIG</code> or <code>--kubeconfig</code>. You can make it even easier by installing two Kubectl plugins: <a href="https://github.com/ahmetb/kubectx" target="_blank" rel="nofollow noopener">kubectx and kubens</a>. These let you rapidly switch between contexts and namespaces using quick shortcuts.
It&#8217;s easiest to install the tools using <a href="https://krew.sigs.k8s.io/docs/user-guide/setup/install" target="_blank" rel="nofollow noopener">Krew</a>, Kubectl&#8217;s plugin manager. Run the script on the Krew website to download it if you need to.
Afterwards, run the following commands to install the plugins:

With the plugins installed, you can view the contexts available in your Kubeconfig file by running <code>kubectl ctx</code>:

The active context will be highlighted. Switch to a different context by supplying its name as an argument to the <code>ctx</code> command:

Similarly, <code>kubectl ns</code> lists and navigates between namespaces in your active cluster:

These time-saving aliases for <code>kubectl config</code> commands help you efficiently work across clusters and environments.

Kubeconfig lets you edit your config files at any time. Change the properties of clusters, contexts, and users by repeating the set-cluster, set-context, and set-user commands with appropriate flags to apply the change you need:

You can always check which context you&#8217;ve selected by running <code>config current-context</code>:

Clusters, contexts, and users can be deleted with their respective <code>delete-</code> commands. 
There&#8217;s no confirmation prompt, so check you&#8217;ve typed the correct name before pressing enter!

To view the contents of your current Kubeconfig file, run <code>kubectl config view</code>:

It displays the same content as if you&#8217;d accessed the file directly, including the clusters, users, and contexts you&#8217;ve registered.

Got lots of existing Kubeconfig files for different clusters? You can merge them into a single file, then set up contexts to access your environments.
First, set the <code>KUBECONFIG</code> environment variable to reference all your files. Separate each file&#8217;s path with a colon (<code>:</code>) character:

Next use Kubectl&#8217;s <code>config view</code> command with the <code>--flatten</code> flag to export a new combined Kubeconfig file:

The resulting Kubeconfig will be the product of merging all the individual files together. You can now use the clusters and users in the merged file to set up your contexts.

Kubeconfig files are sensitive assets that should be treated with caution. Whether you merge your files or keep them separate, remember that anyone with access to them can connect to your cluster.
Avoid sharing Kubeconfigs and ensure they don&#8217;t get accidentally committed to code repositories. If you know or suspect that a file has been leaked, you should immediately take action to invalidate the credentials it contained. <a href="https://kubernetes.io/docs/reference/access-authn-authz/service-accounts-admin/#delete-token" target="_blank" rel="nofollow noopener">Replace the secrets</a> for service accounts and revoke any <a href="https://kubernetes.io/docs/reference/access-authn-authz/authentication" target="_blank" rel="nofollow noopener">user tokens</a> that may have been exposed from your identity provider.
You should also be wary of using Kubeconfig files you don&#8217;t trust. It&#8217;s possible to create <a href="https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig" target="_blank" rel="nofollow noopener">malicious Kubeconfig files</a> that execute arbitrary code on your host. Kubeconfigs you receive are best treated similarly to shell scripts. Don&#8217;t use them without inspecting their content, even if the source seems to be genuine.

Kubeconfig files work with more than just Kubectl. Other Kubernetes ecosystem tools such as Helm and graphical clients like <a href="https://k8slens.dev/" target="_blank" rel="nofollow noopener">Lens</a> also support the clusters, users, and contexts you create. Opening Lens after following the steps in this tutorial will automatically show your cluster connections, for example:

kubeconfig-tools

kubeconfig tools

Multi-cluster Kubernetes access doesn&#8217;t have to mean multiple Kubeconfigs, cumbersome environment variables, and confusion over which file is correct for each situation. Merging your Kubeconfigs into one file lets you use Kubectl&#8217;s built-in commands for quickly switching between clusters, users, and contexts.
While this simplifies ease-of-use, it still requires you to share sensitive cluster credentials and certificates before users can connect. Use a centralized infrastructure automation platform like <a href="https://spacelift.io" target="_blank" rel="noopener">Spacelift</a> to avoid this risky practice. Spacelift provides precise guardrails that let your developers ship straight to Kubernetes clusters without breaking security and compliance requirements.
Want to learn more about Kubernetes and Kubectl? Try our <a href="https://spacelift.io/blog/kubernetes-tutorial" target="_blank" rel="noopener">beginners tutorial</a>, or check out the <a href="https://spacelift.io/blog/kubernetes-namespaces" target="_blank" rel="noopener">advanced topics</a> on the Spacelift blog.

<span data-sheets-value="{&quot;1&quot;:2,&quot;2&quot;:&quot;Spacelift is a sophisticated SaaS product for Infrastructure as Code that helps DevOps develop and deploy new infrastructures or changes quickly and with confidence.&quot;}" data-sheets-userformat="{&quot;2&quot;:769,&quot;3&quot;:{&quot;1&quot;:0},&quot;11&quot;:4,&quot;12&quot;:0}">Spacelift is a sophisticated SaaS product for Infrastructure as Code that helps DevOps develop and deploy new infrastructures or changes quickly and with confidence.

Kubernetes Image Pull Policy - imagePullPolicy in Detail

20 Most Useful DevOps Tools for Infrastructure Automation

Setting up Prometheus Monitoring On a Kubernetes Cluster

Learn why and how to use Kubeconfig files for Kubernetes Clusters and how to merge your Kubeconfigs into one file to use Kubectl's built-in commands.

161-kubeconfig

Using Kubeconfig Files

<a href="https://spacelift.io/blog/kubernetes-tutorial" target="_blank" rel="noopener">Kubernetes</a> automates container management tasks so you can efficiently deploy and scale your workloads. It can distribute your containers across clusters of hundreds or thousands of Nodes.
Most developers begin using Kubernetes for stateless apps. A stateless system doesn&#8217;t modify its environment or write any persistent data. These components are easy to deploy to Kubernetes because their container instances are interchangeable.
Kubernetes can also be used for stateful systems, though. This could be a database, a backend that writes files to persistent volumes, or a service where one replica is elected the leader to gain control of its neighbors.
 In this article, you&#8217;ll learn how to use <a href="https://kubernetes.io/docs/concepts/workloads/controllers/statefulset" target="_blank" rel="nofollow noopener">StatefulSet objects</a> to reliably manage state in your cluster.

<dfn>StatefulSets</dfn> are Kubernetes <a href="https://kubernetes.io/docs/concepts/workloads" target="_blank" rel="nofollow noopener">workload objects</a> that simplify the deployment of stateful applications. They provide several advantages over the <a href="https://kubernetes.io/docs/concepts/workloads/controllers/replicaset" target="_blank" rel="nofollow noopener">ReplicaSet</a> and <a href="https://kubernetes.io/docs/concepts/workloads/controllers/deployment" target="_blank" rel="nofollow noopener">Deployment</a> controllers used for stateless Pods:
<ul>
<li style="font-weight: 400;" aria-level="1">Reliable replica identifiers. Each Pod in a StatefulSet is allocated a persistent identifier. The Pod will retain its identifier even if it&#8217;s replaced or rescheduled, ensuring the new Pod runs with the same characteristics.</li>
<li style="font-weight: 400;" aria-level="1">Stable storage access. Pods in a StatefulSet are individually assigned their own Persistent Volume claims. The Pod&#8217;s volume will be reattached after it&#8217;s rescheduled, providing stable storage access after a rollout or scaling operation.</li>
<li style="font-weight: 400;" aria-level="1">Rolling updates in a guaranteed order. StatefulSets support automated rolling updates in the order that Pods were created. You can predict the order in which an update will apply, with newer Pods only replaced once older ones have updated.</li>
<li style="font-weight: 400;" aria-level="1">Consistent network identities. Pods in StatefulSets have reliable network identities. Their hostnames <a href="https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/#stable-network-id" target="_blank" rel="nofollow noopener">include their numerical replica identifier</a>, allowing external applications to interact with the same replica after a Pod&#8217;s rescheduled.</li>
</ul>
StatefulSets are created in a similar way to Deployment objects. A StatefulSet&#8217;s YAML manifest defines a template for its Pods. Kubernetes automatically creates, replaces, and deletes Pods as you scale the StatefulSet, while preserving any previously assigned identities.

StatefulSets should be used when you&#8217;re deploying an application that requires stable identities for its Pods. Reach for a StatefulSet instead of a ReplicaSet or Deployment if your system will be disrupted when a specific Pod replica is replaced.
Replicated databases are a good example of the scenarios that StatefulSets accommodate. One Pod acts as the primary database node, handling both read and write operations, while additional Pods are deployed as read-only replicas.
Although each Pod may run the same container image, each one needs special configuration to set whether it&#8217;s in primary or read-only mode. This means your Pods possess their own state:
<ul>
<li style="font-weight: 400;" aria-level="1">postgres-0 &#8211; Primary node (read-write).</li>
<li style="font-weight: 400;" aria-level="1">postgres-1 &#8211; Read-only replica.</li>
<li style="font-weight: 400;" aria-level="1">postgres-2 &#8211; Read-only replica.</li>
</ul>
Regular ReplicaSets and Deployments aren&#8217;t suitable for this situation. Scaling down a Deployment removes arbitrary Pods, which could include the primary node in your database system. When you use a StatefulSet, Kubernetes terminates Pods in the opposite order to their creation. This ensures it&#8217;ll be postgres-2 that&#8217;s destroyed first.
Several other StatefulSet features also apply to this example:
<ul>
<li style="font-weight: 400;" aria-level="1">The applications that use your database need to reliably connect to the primary node, so they can both read and write data. The StatefulSet&#8217;s stable network identifiers ensure postgres-0.service.namespace.svc.cluster.local will always map to the primary Node, even after scaling or replacing your Pods.</li>
<li style="font-weight: 400;" aria-level="1">The read-only replicas shouldn&#8217;t start until after the primary is up. StatefulSets use rolling updates so each successive Pod is only created when the previous one is ready. This ensures there&#8217;s data available to replicate.</li>
<li style="font-weight: 400;" aria-level="1">Each replica has its own sticky volume for storage. The persistent data stored by each replica is bound to its Pod. The version of the database that postgres-1 has replicated needs to be maintained separately to the copy held by postgres-2. StatefulSets can handle this requirement.</li>
</ul>

Ready to put this example into practice? Here&#8217;s how to run three replicas of PostgreSQL in Kubernetes using a StatefulSet.
First, create a <a href="https://kubernetes.io/docs/concepts/services-networking/service/#headless-services" target="_blank" rel="nofollow noopener">headless service</a> for your deployment. A headless service is a service that defines a port binding but has its <code>clusterIP</code> set to <code>None</code>. StatefulSets <a href="https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/#limitations" target="_blank" rel="nofollow noopener">require you</a> to create a headless service to control their network identities.
Copy the following <a href="https://spacelift.io/blog/yaml" target="_blank" rel="noopener">YAML</a> and save it as <code>postgres-service.yaml</code> in your working directory:

Use Kubectl to add the service to your cluster:

Next, copy the following YAML to <code>postgres-statefulset.yaml</code>. It defines a StatefulSet that runs three replicas of the <code>postgres:latest</code> image.

Apply the manifest to your <a href="https://spacelift.io/blog/kubernetes-cluster" target="_blank" rel="noopener">cluster</a> to create your StatefulSet:

Now you can list the Pods running in your cluster. The names of the three Pods from your StatefulSet will be suffixed with the sequential index they’ve been assigned:

The StatefulSet creates each Pod in order, once the previous one has entered the Running state. This ensures the replicas don&#8217;t start until the previous Pod is ready to synchronize data. If a ReplicaSet had been used, all three Pods would have been created at the same time.
The StatefulSet uses <a href="https://kubernetes.io/docs/concepts/workloads/pods/init-containers" target="_blank" rel="nofollow noopener">init containers</a> to determine whether new Pods are the Postgres primary or a replica. Each init container inspects its numeric index assigned by the StatefulSet controller; if it’s 0, the Pod is the first in the StatefulSet, so it becomes the primary database node.
Otherwise, it’s a replica:

This demonstrates how StatefulSets let you consistently designate Pods as having a specific role. In a real-life Postgres example, you&#8217;d use your init containers <a href="https://stacksoft.io/blog/postgres-statefulset" target="_blank" rel="nofollow noopener">to set up database replication</a> from the primary Pod to the replicas. When the Pod&#8217;s index is <code>0</code>, it should be configured as the primary; when it&#8217;s a higher number, the Pod is a replica that needs to synchronize the existing data and run in read-only mode.
Each Pod in the StatefulSet gets its own Persistent Volume and Persistent Volume Claim. These are created using the manifest template defined in the StatefulSet’s <code>volumeClaimTemplates</code> field.

This allows the Pods to manage their own state, independently of the others in the StatefulSet.

<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">Terraform vs. Kubernetes Comparison</a></li>
</ul>

<h3>Using Rolling Updates</h3>
Finally, let&#8217;s try scaling this StatefulSet. Running the following command will add two new replicas without affecting the existing Pods:

Now there are five Pods, with the new ones created sequentially, one after the other:

When you scale down the StatefulSet, Kubernetes terminates Pods in the reverse order of their creation:

Kubernetes has scaled down from five to two replicas by removing the three newest Pods.

Although StatefulSets make it much easier to run stateful workloads in Kubernetes, they do come with some common &#8220;gotchas&#8221; that can trip you up. These are <a href="https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/#limitations" target="_blank" rel="nofollow noopener">well-documented</a> but still surprising when you encounter them for the first time.
<ul>
<li style="font-weight: 400;" aria-level="1">There&#8217;s no built-in way to resize volumes. StatefulSets don&#8217;t let you resize your volumes after initial creation. This can quickly become problematic as your service scales. There is <a href="https://github.com/kubernetes/kubernetes/issues/68737" target="_blank" rel="nofollow noopener">a workaround</a> but it&#8217;s clunky: you have to delete the StatefulSet and <a href="https://kubernetes.io/docs/tasks/administer-cluster/use-cascading-deletion" target="_blank" rel="nofollow noopener">orphan its Pods</a>, then recreate it with the updated volume template. The StatefulSet controller should detect your orphaned Pods and reattach them to the new object.</li>
<li style="font-weight: 400;" aria-level="1">Volumes aren&#8217;t deleted by default. StatefulSets don&#8217;t delete the volumes allocated to your Pods by default, even if a Pod is terminated because the StatefulSet&#8217;s removed or scaled down. This minimizes the risk of data loss but can cause you to accumulate many old volumes from redundant StatefulSets. Since Kubernetes v1.23, you can opt-in to automatically deleting volumes by enabling the <code>StatefulSetAutoDeletePVC</code> API server feature gate and <a href="https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/#persistentvolumeclaim-retention" target="_blank" rel="nofollow noopener">setting the <code>persistentVolumeClaimRetentionPolicy</code> field</a> on your StatefulSets.</li>
<li style="font-weight: 400;" aria-level="1">Deleting a StatefulSet doesn&#8217;t guarantee that Pods will terminate in order. Scaling down a StatefulSet reliably terminates Pods in the reverse order of their creation. This behavior doesn&#8217;t occur when a StatefulSet&#8217;s deleted, though. Kubernetes will revert to deleting Pods simultaneously, which might prevent your application from cleanly exiting. You can avoid this problem by scaling your StatefulSets down to 0 before you delete them.</li>
<li style="font-weight: 400;" aria-level="1">You have to manually create <a style="font-weight: 400;" href="https://kubernetes.io/docs/concepts/services-networking/service/#headless-services" target="_blank" rel="nofollow noopener">headless services</a> to benefit from reliable network identifiers. The StatefulSet controller won&#8217;t create services for you. Forgetting to define one will leave you without the predictable network identity features.</li>
</ul>
Keeping these sticking points in mind will help ensure your StatefulSet deployments perform as you expect.

StatefulSets are Kubernetes objects for running stateful applications in your cluster. They provide stable Pod identifiers, sticky storage, and automated rolling updates that let you predict the replicas that&#8217;ll be affected by scaling operations.
Use a StatefulSet each time you deploy a service with non-interchangeable Pods. Without StatefulSets, critical replicas could be replaced after you scale your deployment or Pods get rescheduled.
And check out how <a href="https://spacelift.io" target="_blank" rel="noopener">Spacelift</a> brings the benefits of CI/CD to infrastructure management. You can use Spacelift to deploy changes to Kubernetes with GitOps while benefiting from robust security policies and automated compliance checks. Spacelift also works with other <a href="https://spacelift.io/ci-cd-for-infrastructure" target="_blank" rel="noopener">infrastructure as code (IaC)</a> providers, so you can use similar techniques to manage every component of your stack.

Tricking PostgresSQL into Using an Insane - but 200x Faster - Query Plan

Terraform vs. Kubernetes : Key Differences and Comparison

How and when to use Kubernetes StatefulSet objects to reliably manage state in your cluster. See a practical example.

157-statefulset

Guide to Kubernetes StatefulSet

Guide to Kubernetes StatefulSet - When to Use It and Examples 

CI/CD Pipelines with Kubernetes | Best Practices and Tools

CI/CD pipelines enhance the software delivery process by automating key stages such as testing, security scanning, and deployment. Adopting a pipeline-based workflow helps you ship more quickly by passing all code through a consistent set of steps. This guarantees that required standards are adhered to.
You&#8217;ll see the greatest CI/CD success when you combine the right set of tools for your team&#8217;s situation. With so many platforms available, it can be challenging to select an optimal solution.
In this article, you&#8217;ll learn some best practices and techniques for managing <a href="https://spacelift.io/blog/ci-cd-pipeline" target="_blank" rel="noopener">CI/CD pipelines</a> with Kubernetes. You can use these strategies to automate deployments straight to your production clusters. Let&#8217;s dive in!

Kubernetes is the leading <a href="https://spacelift.io/blog/kubernetes-architecture" target="_blank" rel="noopener">container orchestrator</a> for deploying, scaling and administering container workloads in production. But how do those workloads reach your cluster? Manually creating them by running Kubectl terminal commands is inefficient and prone to error.
Using CI/CD pipelines with Kubernetes lets you automatically deploy applications whenever your source code changes. You can improve the Kubernetes management experience by automating key tasks. CI/CD also provides an opportunity to verify new deployments meet the standards you expect, such as passing your test suite and being free from security issues.
Nonetheless, integrating Kubernetes into CI/CD workflows can create new problems. Cluster administrators often struggle to see what&#8217;s actually running in their environments, while addressing any deployment failures can be time-consuming. Integrations are also potential security risks, as compromising your CI/CD provider could let attackers access your clusters. 
Here&#8217;s how you can address these drawbacks to combine CI/CD and Kubernetes with confidence.
7 Best Practices for CI/CD and Kubernetes:
<ol>
<li><a href="https://spacelift.io/blog/kubernetes-ci-cd#1-use-gitops">Use GitOps</a></li>
<li><a href="https://spacelift.io/blog/kubernetes-ci-cd#2-scan-your-container-images">Scan Your Container Images</a></li>
<li><a href="https://spacelift.io/blog/kubernetes-ci-cd#3-use-helm-to-manage-deployments">Use Helm to Manage Deployments</a></li>
<li><a href="https://spacelift.io/blog/kubernetes-ci-cd#4-ensure-theres-a-rollback-mechanism-and-check-it-works">Ensure There&#8217;s a Rollback Mechanism</a></li>
<li><a href="https://spacelift.io/blog/kubernetes-ci-cd#5-use-immutable-image-tags">Use Immutable Image Tags</a></li>
<li><a href="https://spacelift.io/blog/kubernetes-ci-cd#6-follow-kubernetes-security-best-practices">Follow Kubernetes Security Best Practices</a></li>
<li><a href="https://spacelift.io/blog/kubernetes-ci-cd#7-try-pullbased-cicd-workflows">Try Pull-Based CI/CD Workflows</a></li>
</ol>

The term <a href="https://www.gitops.tech" target="_blank" rel="nofollow noopener">GitOps</a> refers to the practice of keeping your infrastructure configuration as files in your source control repository. Managing everything with Git ensures every essential resource is versioned. It also means you can reference any resource within your pipelines, so you can check the validity of your config and quickly identify any errors.
Manually triggering pipelines from external systems is unreliable and error-prone. Using Git to run a pipeline each time you commit ensures changes can&#8217;t slip through to production unnoticed. If you need to revert a deployment, you can check out an older commit and replay the pipeline.

Deploying container images straight to Kubernetes is a security risk. Your images could include zero-day vulnerabilities, accidentally hardcoded secrets, or a malicious package that&#8217;s made it into your supply chain.
To stay safe, you can use your pipeline to perform image vulnerability scans. Abort the rest of the pipeline if a fault is found. This will prevent new vulnerabilities from being silently pushed into your cluster.
You can use tools such as <a href="https://github.com/snyk/cli" target="_blank" rel="nofollow noopener">Snyk</a> to generate your reports. Snyk also powers the <a href="https://docs.docker.com/engine/scan" target="_blank" rel="nofollow noopener">docker scan command</a> that&#8217;s integrated into Docker’s CLI.

Applying Kubernetes manifests individually is problematic because files can get overlooked. Packaging your applications as <a href="https://helm.sh" target="_blank" rel="nofollow noopener">Helm charts</a> lets you version your manifests and easily repeat deployments into different environments. Helm tracks the state of each deployment as a &#8220;release&#8221; in your cluster.
Helm also simplifies configuration management. You can <a href="https://helm.sh/docs/chart_best_practices/values" target="_blank" rel="nofollow noopener">easily supply variables</a> when you install your charts, either using YAML files or as command line arguments. This lets you conveniently override specific variables within your pipeline scripts.

Continuous delivery (CD) pipelines are great until they break. When this happens in Kubernetes, it can be unclear how to proceed. Your deployment could be stuck in a failed state, unable to transition into the newly desired one.
Make sure you&#8217;ve got a reliable rollback strategy that&#8217;s ready to deal with these events. If you&#8217;re using GitOps, you should be able to rollback by reverting to a previous commit, then running your pipeline again. The old revision will now be new once more, enabling it to replace the bad state in your cluster.
Stateful workloads, such as databases, might need additional steps in case the failed deployment partially migrated some data while leaving other components stuck on the old version. Your rollback strategy should be capable of preserving and restoring persistent data when required. Finally, make sure your rollback system actually works – too many teams only discover bugs in their rollback scripts during real incidents.

Image tag immutability makes your deployments reproducible and helps enable resilient rollbacks. Always deploying my-app:latest is dangerous because the exact image that&#8217;s selected could change each time.
It&#8217;s much safer to uniquely tag each image you build. Using a truncated commit SHA is a popular strategy, resulting in tags like my-app:0ab43f. This allows you to easily cross-reference commits against the image artifacts and deployments they create. If you need to rollback, you can modify your Kubernetes deployment to refer to the image built from the previous commit.

It&#8217;s important to keep following <a href="https://spacelift.io/blog/kubernetes-security" target="_blank" rel="noopener">standard Kubernetes security best practices</a> when you&#8217;re integrating your clusters with CI/CD platforms. Harden your environment by enabling <a href="https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data" target="_blank" rel="nofollow noopener">etcd encryption</a>, setting up precise <a href="https://kubernetes.io/docs/reference/access-authn-authz/rbac" target="_blank" rel="nofollow noopener">RBAC permissions</a> for your CI/CD user accounts, and ensuring any sensitive config values are added to <a href="https://spacelift.io/blog/kubernetes-secrets" target="_blank" rel="noopener">Secrets</a> instead of plain ConfigMaps.
You should check your CI/CD platform only exposes your cluster connections to projects and users you&#8217;ve specifically authorized. Remember that anyone who can commit to your project could send malicious code through the pipeline into your <a href="https://spacelift.io/blog/kubernetes-cluster" target="_blank" rel="noopener">Kubernetes cluster</a>.

There are two main ways to connect CI/CD systems to Kubernetes:
<ul>
<li style="font-weight: 400;" aria-level="1">Push-based workflows rely on the CI/CD platform being provided with certificates and credentials that let it reach out to your Kubernetes cluster. You then use familiar tools such as Kubectl and Helm to push changes into Kubernetes from the outside.</li>
<li style="font-weight: 400;" aria-level="1">Pull-based workflows run an agent utility inside the cluster. The agent is given credentials for your source control system. Its access should be scoped to just the projects it needs to deploy. The agent periodically looks for changes and pulls them into the cluster. This inverts the push-based model.</li>
</ul>
Pull-based CI/CD is increasingly popular because it provides stronger protection for your cluster. In order to be effective, push-based workflows require privileged Kubernetes credentials to be stored on your source control server. If the server&#8217;s compromised, attackers could steal the credentials, access your cluster, and perform arbitrary actions. With a pull-based workflow, attacks against the CI/CD platform won&#8217;t grant access to your entire cluster.

<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/infrastructure-problems-that-spacelift-solves" target="_blank" rel="noopener"><span data-sheets-value="{&quot;1&quot;:2,&quot;2&quot;:&quot;Common Infrastructure Challenges and How to Solve Them&quot;}" data-sheets-userformat="{&quot;2&quot;:513,&quot;3&quot;:{&quot;1&quot;:0},&quot;12&quot;:0}">Common Infrastructure Challenges and How to Solve Them</a></li>
</ul>

None of these best practices need to be difficult. You should aim to create a toolchain that supports you in efficiently running CI/CD pipelines with Kubernetes, while avoiding security problems and common mistakes. Here are five tools you can try out.
<h3>GitLab</h3>
<a href="https://about.gitlab.com" target="_blank" rel="nofollow noopener">GitLab</a> is one of the most popular all-in-one software delivery platforms. It includes source management and CI/CD functions with excellent Kubernetes integration.
Modern GitLab releases <a href="https://docs.gitlab.com/ee/user/clusters/agent/ci_cd_workflow.html" target="_blank" rel="nofollow noopener">have transitioned to a pull-based workflow</a> using the GitLab Agent for Kubernetes. The agent runs in your cluster and is authorized to access specific GitLab projects. You can then interact with Kubernetes from within your pipeline scripts. All communication flows securely through the agent.
<h3>GitHub Actions</h3>
<a href="https://github.com/features/actions" target="_blank" rel="nofollow noopener">GitHub Actions</a> is GitHub&#8217;s CI/CD solution. You can use it to run automated tasks each time you change your code. Although the platform lacks a built-in Kubernetes integration, third-party plugins such as Azure&#8217;s <a href="https://github.com/marketplace/actions/deploy-to-kubernetes-cluster" target="_blank" rel="nofollow noopener">Deploy to Kubernetes Cluster</a> action can automate deployments and manage different rollout strategies.
<h3>Argo CD</h3>
<a href="https://argo-cd.readthedocs.io/en/stable" target="_blank" rel="nofollow noopener">Argo CD</a> is a continuous delivery tool that&#8217;s purpose-built for Kubernetes. It&#8217;s maintained as a <a href="https://www.cncf.io" target="_blank" rel="nofollow noopener">Cloud Native Computing Foundation (CNCF)</a> project.
Argo is installed in your cluster as a Kubernetes controller. It monitors your applications and identifies any differences compared with your source control repository. When drift occurs, Argo will automatically resynchronize the state by pulling your code and updating the resources in your cluster. It facilitates fully automated Kubernetes deployments.
<span data-sheets-value="{&quot;1&quot;:2,&quot;2&quot;:&quot;Read more about this tool in our ArgoCD - Practical Tutorial With Kubernetes article.&quot;}" data-sheets-userformat="{&quot;2&quot;:513,&quot;3&quot;:{&quot;1&quot;:0},&quot;12&quot;:0}">Read more about this tool in our <a href="https://spacelift.io/blog/argocd" target="_blank" rel="noopener">ArgoCD &#8211; Practical Tutorial With Kubernetes</a> article.
<h3>Kubectl and Helm</h3>
You can use existing Kubernetes CLIs such as <a href="https://kubernetes.io/docs/tasks/tools" target="_blank" rel="nofollow noopener">Kubectl</a> and <a href="https://helm.sh" target="_blank" rel="nofollow noopener">Helm</a> within your own CI/CD scripts. This will require you to supply credentials that let the CLIs authenticate with your cluster, creating a push-based workflow.
This method can be more approachable and easier to set up than using a dedicated tool, especially if you&#8217;re only experimenting with Kubernetes. It lets you use the same commands you run on your workstation to roll out changes within your pipelines.
<h3>Spacelift</h3>
<a href="https://spacelift.io" target="_blank" rel="noopener">Spacelift</a> brings the benefits of CI/CD to infrastructure management. You can use Spacelift to deploy changes to Kubernetes with GitOps while benefiting from robust security policies and automated compliance checks. Spacelift also works with other <a href="https://spacelift.io/ci-cd-for-infrastructure" target="_blank" rel="noopener">infrastructure as code (IaC)</a> providers, so you can use similar techniques to manage every component of your stack.

Using CI/CD with Kubernetes allows you to automate deployments, rapidly scale your services, and be confident that all live code has passed your test suite. The two technologies pair well together if you follow the best practices we&#8217;ve explored.
When selecting a CI/CD pipeline solution for Kubernetes, you should assess how deep the integration goes and look at its security model, rollback mechanisms, and support for your source management system.
You can use CI/CD to apply infrastructure changes using IaC techniques, either to Kubernetes or other tools such as Terraform and Ansible. Check out<a href="https://spacelift.io" target="_blank" rel="noopener"> Spacelift</a> to collaborate on infrastructure with full control and flexibility. It includes role-based security policies, detailed usage insights, and full visibility into everything running in your cloud accounts.

How to Deploy your Infrastructure in CI/CD using Terraform

OpenShift vs. Kubernetes : Product & Project Comparison

Learn some best practices and techniques for managing CI/CD pipelines with Kubernetes and five tools you can try out.

159-kubernetes-in-ci-cd

Kubernetes CI/CD Pipelines - 7 Best Practices and Tools

How to Setup Prometheus Monitoring On a Kubernetes Cluster

<a href="https://spacelift.io/blog/kubernetes-tutorial" target="_blank" rel="noopener">Kubernetes</a> is the most popular orchestrator for running containerized workloads in production. It gives you a complete set of tools for deploying, scaling, and administering your containers.
Kubernetes alone isn&#8217;t enough to successfully operate apps, though. You also need visibility into cluster utilization, performance, and any errors that occur.<a href="https://prometheus.io" target="_blank" rel="nofollow noopener"> Prometheus</a> is an open-source monitoring system that collects metrics in a time series database, allowing you to answer these questions.
In this article, you&#8217;ll learn how to set up and use Prometheus with your Kubernetes cluster. We&#8217;ll cover the basics of installing Prometheus, querying data, setting up visual dashboards, and managing alerting rules. You&#8217;ll need <a href="https://kubernetes.io/docs/reference/kubectl/kubectl" target="_blank" rel="nofollow noopener">Kubectl</a>, <a href="https://helm.sh/docs/intro/install" target="_blank" rel="nofollow noopener">Helm</a>, and a Kubernetes cluster before you begin. Let&#8217;s get started!

The <a href="https://github.com/prometheus-community/helm-charts/blob/main/charts/kube-prometheus-stack/README.md" target="_blank" rel="nofollow noopener">kube-prometheus-stack</a> Helm chart is the simplest way to bring up a complete Prometheus stack inside your Kubernetes cluster. It bundles several different components in one automated deployment:
<ul>
<li style="font-weight: 400;" aria-level="1">Prometheus &#8211; Prometheus is the time series database that scrapes, stores, and exposes the metrics from your Kubernetes environment and its applications.</li>
<li style="font-weight: 400;" aria-level="1">Node-Exporter &#8211; Prometheus works by scraping data from a variety of configurable sources called exporters. <a href="https://github.com/prometheus/node_exporter" target="_blank" rel="nofollow noopener">Node-Exporter</a> is an exporter which collects resource utilization data from the Nodes in your Kubernetes cluster. The kube-prometheus-stack chart automatically deploys this exporter and configures your Prometheus instance to scrape it.</li>
<li style="font-weight: 400;" aria-level="1">Kube-State-Metrics &#8211; <a href="https://github.com/kubernetes/kube-state-metrics" target="_blank" rel="nofollow noopener">Kube-State-Metrics</a> is another exporter that supplies data to Prometheus. It exposes information about the API objects in your Kubernetes cluster, such as Pods and containers.</li>
<li style="font-weight: 400;" aria-level="1">Grafana &#8211; Although you can directly query Prometheus, this is often tedious and repetitive. <a href="https://grafana.com" target="_blank" rel="nofollow noopener">Grafana</a> is an observability platform that works with several data sources, including Prometheus databases. You can use it to create dashboards that surface your Prometheus data.</li>
<li style="font-weight: 400;" aria-level="1">Alertmanager &#8211; <a href="https://prometheus.io/docs/alerting/latest/alertmanager" target="_blank" rel="nofollow noopener">Alertmanager</a> is a standalone Prometheus component that provides notifications when metrics change. You can use it to get an email when CPU utilization spikes or a Slack notification if a Pod is evicted, for example.</li>
</ul>
Deploying, configuring, and maintaining all these components individually can be burdensome for administrators. Kube-Prometheus-Stack provides an automated solution that performs all the hard work for you.

First register the chart&#8217;s repository in your Helm client:

Next, update your repository lists to discover the chart:

Now you can run the following command to deploy the chart into a new namespace in your cluster:

It can take a couple of minutes for the chart&#8217;s components to start. Run the following command to check how they&#8217;re progressing:

Once all the Pods show as Running, your monitoring stack is ready to use. The data exposed by the exporters will be automatically scraped by Prometheus. 
Now you can start querying your metrics.

Prometheus includes a web UI that you can use to query your data. This is not exposed automatically. You can access it by using Kubectl port forwarding to redirect local traffic to the service in your cluster:

This command redirects traffic to <code>localhost:9090</code> to the Prometheus service. Visiting this URL in your web browser will reveal the Prometheus UI:

prometheus-monitring-prometheus-ui

prometheus monitring prometheus UI

The &#8220;Expression&#8221; input at the top of the screen is where you enter your queries as <a href="https://prometheus.io/docs/prometheus/latest/querying/basics" target="_blank" rel="nofollow noopener">PromQL</a> expressions. Start typing into the input to reveal autocomplete suggestions for the available metrics.
Try selecting the <code>node_memory_Active_bytes</code> metric, which surfaces the memory consumption of each of the Nodes in your cluster. Press the &#8220;Execute&#8221; button to run your query. The results will be displayed in a table that provides the query&#8217;s raw output:

prometheus-monitoring-querys-raw-output

prometheus monitoring query's raw output

Most metrics are easier to interpret as graphs. 
Switch to the &#8220;Graph&#8221; tab at the top of the screen to see a visualization of the metric over time. You can use the controls above the graph to change the time period that&#8217;s displayed.

prometheus-monitoring-graphs

prometheus monitoring graphs

PromQL <a href="https://prometheus.io/docs/prometheus/latest/querying/basics" target="_blank" rel="nofollow noopener">queries</a> allow detailed interrogation of your data. Manually running individual queries in the Prometheus UI is an inefficient form of monitoring, however.
Next, let&#8217;s use Grafana to visualize metrics conveniently on live dashboards.

Start a new Kubectl port forwarding session to access the Grafana UI. Use port 80 as the target because this is what the Grafana service binds to. 
You can map it to a different local port, such as 8080, in this example:

Next visit <code>http://localhost:8080</code> in your browser. You&#8217;ll see the Grafana login page. The default user account is admin with a password of <code>prom-operator</code>.

prometheus-monitoring-grafana-login-page

prometheus monitoring Grafana login page

After you&#8217;ve logged in, you&#8217;ll initially reach the Grafana welcome screen:

prometheus-monitoring-grafana-welcome-page

prometheus monitoring Grafana welcome page

Use the sidebar to switch to the Dashboards screen. Its icon is four squares arranged to resemble panes of glass. This is where all your saved dashboards can be found, including the prebuilt ones that come with Kube-Prometheus-Stack deployments.

prometheus-monitoring-dashboards-screen

prometheus monitoring Dashboards screen

There are several included dashboards that contain the metrics scraped from Node-Exporter, Kube-State-Metrics, and various Kubernetes and Prometheus components. Here are a few notable ones:
<h3>Monitoring Cluster Utilization With &#8220;Kubernetes / Compute Resources / Cluster&#8221;</h3>
This dashboard provides an overview of the resource utilization for your entire cluster. Headline statistics are displayed at the top, with more detailed information presented in panels below.

prometheus-monitoring-cluster-utilization

prometheus Monitoring Cluster Utilization

Learn how to set up and use Prometheus with your Kubernetes cluster with querying data, setting up visual dashboards, and managing alerting rules.

James Walker

What Is ArgoCD? A Practical Tutorial With Kubernetes

Get the newsletter

Recent posts

Using Kubeconfig Files to Organize Kubernetes Cluster Access

Guide to Kubernetes StatefulSet – When to Use It and Examples

Kubernetes CI/CD Pipelines – 7 Best Practices and Tools

Setting up Prometheus Monitoring On a Kubernetes Cluster

Docker Tutorial for Beginners – Introduction & Getting Started

What Is Platform Engineering? Role, Principles & Benefits

What Is Kubernetes Architecture? – Components Overview

Kubernetes Security : 6 Best Practices for 4C Security Model

Kubernetes Tutorial for Beginners – Basic Concepts & Examples