<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Kubernetes on DevOps &amp; Rock&#39;N&#39;Roll</title>
    <link>https://artazar.pages.dev/tags/kubernetes/</link>
    <description>Recent content in Kubernetes on DevOps &amp; Rock&#39;N&#39;Roll</description>
    <generator>Hugo</generator>
    <language>en</language>
    <lastBuildDate>Wed, 19 Aug 2026 15:55:02 +0700</lastBuildDate>
    <atom:link href="https://artazar.pages.dev/tags/kubernetes/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Wrapping Kyverno policies into a chart you can actually tune</title>
      <link>https://artazar.pages.dev/blog/12-kyverno-policies-helm-chart/</link>
      <pubDate>Tue, 07 Jul 2026 00:08:30 +0000</pubDate>
      <guid>https://artazar.pages.dev/blog/12-kyverno-policies-helm-chart/</guid>
      <description>&lt;p&gt;Kyverno&amp;rsquo;s policy library is excellent and you should read it. It is also a directory of static YAML files, which means adopting it looks like copying twenty ClusterPolicy manifests into your GitOps repo and then editing them by hand, per cluster, forever.&lt;/p&gt;&#xA;&lt;p&gt;That works until the second cluster. Dev wants &lt;code&gt;audit&lt;/code&gt; where prod wants &lt;code&gt;enforce&lt;/code&gt;. The infra cluster needs the CRI socket policy relaxed because your monitoring agent legitimately mounts it. A new namespace needs to be excluded from the Flux label requirement. Each of these is a one-line change to a file that&amp;rsquo;s now duplicated across three repositories, and none of them are visible from a single place.&lt;/p&gt;</description>
    </item>
    <item>
      <title>IRSA to Pod Identity: notes from the migration</title>
      <link>https://artazar.pages.dev/blog/10-irsa-to-pod-identity/</link>
      <pubDate>Tue, 02 Jun 2026 00:08:30 +0000</pubDate>
      <guid>https://artazar.pages.dev/blog/10-irsa-to-pod-identity/</guid>
      <description>&lt;p&gt;IRSA has been the way to give a Kubernetes pod an AWS identity since 2019, and it works. It also requires an OIDC provider per cluster, a trust policy per role that names a specific cluster&amp;rsquo;s OIDC issuer, and a mental model involving projected service account tokens that you re-derive from scratch every time something breaks.&lt;/p&gt;&#xA;&lt;p&gt;EKS Pod Identity does the same job with less machinery. I&amp;rsquo;ve now moved a few clusters over and it&amp;rsquo;s mostly good news, with a couple of edges worth knowing before you start.&lt;/p&gt;</description>
    </item>
    <item>
      <title>A FluxCD repo layout that survives forty applications</title>
      <link>https://artazar.pages.dev/blog/08-fluxcd-repo-layout/</link>
      <pubDate>Tue, 05 May 2026 00:08:30 +0000</pubDate>
      <guid>https://artazar.pages.dev/blog/08-fluxcd-repo-layout/</guid>
      <description>&lt;p&gt;Every GitOps repository starts beautiful. One cluster, five apps, a flat &lt;code&gt;apps/&lt;/code&gt; directory, and a Kustomization that reconciles the lot. Then the second cluster appears. Then staging needs a different replica count. Then somebody needs their own namespace with their own RBAC and no access to anyone else&amp;rsquo;s. Six months later you are grepping through forty &lt;code&gt;kustomization.yaml&lt;/code&gt; files trying to work out why a change to a shared ConfigMap took down two environments.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Node labels for Node Exporter alerts</title>
      <link>https://artazar.pages.dev/blog/05-node-exporter-labels/</link>
      <pubDate>Wed, 04 Mar 2026 00:08:30 +0000</pubDate>
      <guid>https://artazar.pages.dev/blog/05-node-exporter-labels/</guid>
      <description>&lt;p&gt;Running a multipurpose Kubernetes cluster where production, dev and infra workloads share the same infrastructure is pretty common. In such a setup, you often want your alerting rules to be smarter: fire a critical alert when a prod node is burning CPU, but keep it informational for a dev node. To do that, you need your Prometheus metrics to carry environment context. This post shows how to thread that label all the way from a Karpenter node pool down to the Prometheus alert.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Yet another Vault story</title>
      <link>https://artazar.pages.dev/blog/03-vault-my-experience/</link>
      <pubDate>Fri, 06 Oct 2023 00:08:30 +0000</pubDate>
      <guid>https://artazar.pages.dev/blog/03-vault-my-experience/</guid>
      <description>&lt;p&gt;One can find a million blog posts about various aspects of using Hashicorp Vault, this solution has truly received massive adoption. So now you don&amp;rsquo;t even question what you&amp;rsquo;re going to use as secrets storage, but the matter is more of &amp;ldquo;how&amp;rdquo;.&lt;/p&gt;&#xA;&lt;p&gt;Being a complete and inveterate gitops&amp;rsquo;er, one of my primary objectives is to store as much as I can in Git and to deploy that into Kubernetes. This brought me to the BanzaiCloud Bank Vaults solution bundle that allows you to achieve exactly this. It provides the ability to configure Vault as a Custom Resource and store all its primary settings on a repository. This is not very far from the official Helm chart deployment with their values, but BanzaiCloud give you a bit more:&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
