<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Kubernetes - Tag - Shengxu · Cloud Architecture &amp; DevOps</title><link>https://shengxu.pages.dev/en/tags/kubernetes/</link><description>Cloud architecture &amp; DevOps notes by Shengxu: Kubernetes, Cilium, observability, LLM infra, AI agents.</description><generator>Hugo 0.153.2 &amp; FixIt v0.4.0-alpha.3-20251225101113-8ffb9a95</generator><language>en</language><lastBuildDate>Fri, 17 Apr 2026 19:40:00 +0800</lastBuildDate><atom:link href="https://shengxu.pages.dev/en/tags/kubernetes/index.xml" rel="self" type="application/rss+xml"/><item><title>From Azure SRE Agent to HolmesGPT: AIOps Practices in Multi-Cloud Kubernetes Environments</title><link>https://shengxu.pages.dev/en/posts/azure-sre-agent-to-holmesgpt/</link><pubDate>Fri, 17 Apr 2026 19:40:00 +0800</pubDate><guid>https://shengxu.pages.dev/en/posts/azure-sre-agent-to-holmesgpt/</guid><category domain="https://shengxu.pages.dev/en/categories/ai/">AI</category><category domain="https://shengxu.pages.dev/en/categories/kubernetes/">Kubernetes</category><category domain="https://shengxu.pages.dev/en/categories/devops/">DevOps</category><category domain="https://shengxu.pages.dev/en/categories/observability/">Observability</category><description>&lt;p&gt;In the multi-cloud Kubernetes era, the pain point for SREs is no longer just &amp;ldquo;too many alerts,&amp;rdquo; but rather investigation chains that are too long, context that is too scattered, and troubleshooting costs across clouds that are too high. What truly drains people isn&amp;rsquo;t glancing at a chart, but constantly switching between multiple cloud platforms, logging systems, deployment records, and ticketing systems.&lt;/p&gt;
&lt;p&gt;This is why AI SRE Agents are starting to deliver real value. Their goal isn&amp;rsquo;t to be a better conversational Copilot, but to proactively take over the highly repetitive first half of the work—&amp;ldquo;checking logs, finding correlations, guessing root causes, and giving suggestions&amp;rdquo;—once an alert is triggered.&lt;/p&gt;</description></item><item><title>Cilium 2026 (Continued): How the Unified Data Plane Is Reshaping Kubernetes Platform Architecture</title><link>https://shengxu.pages.dev/en/posts/cilium-2026-part-2-unified-dataplane/</link><pubDate>Sat, 21 Mar 2026 14:31:56 +0800</pubDate><guid>https://shengxu.pages.dev/en/posts/cilium-2026-part-2-unified-dataplane/</guid><category domain="https://shengxu.pages.dev/en/categories/kubernetes/">Kubernetes</category><category domain="https://shengxu.pages.dev/en/categories/devops/">DevOps</category><category domain="https://shengxu.pages.dev/en/categories/observability/">Observability</category><category domain="https://shengxu.pages.dev/en/categories/security/">Security</category><category domain="https://shengxu.pages.dev/en/categories/ai/">AI</category><description>&lt;p&gt;In &lt;a href="https://shengxu.pages.dev/posts/cilium-2026/"&gt;the previous article on Cilium&lt;/a&gt;, we explored the real reasons behind the 2026 migration wave: it&amp;rsquo;s no longer just &amp;ldquo;a faster CNI,&amp;rdquo; but rather a reorganization of Kubernetes networking, security, observability, and multi-cluster capabilities into a more unified infrastructure foundation, while clarifying its division of labor and boundaries with Istio.&lt;/p&gt;
&lt;p&gt;If the previous article answered &amp;ldquo;What exactly can Cilium bring us?&amp;rdquo;, this one goes further, focusing on its core evolution: the &lt;strong&gt;Unified Dataplane&lt;/strong&gt;.&lt;/p&gt;</description></item><item><title>Kubernetes Complexity: Starting from a Job Interview Question</title><link>https://shengxu.pages.dev/en/posts/kubernetes-complexity-interview/</link><pubDate>Sat, 24 Jan 2026 12:47:00 +0800</pubDate><guid>https://shengxu.pages.dev/en/posts/kubernetes-complexity-interview/</guid><category domain="https://shengxu.pages.dev/en/categories/kubernetes/">Kubernetes</category><category domain="https://shengxu.pages.dev/en/categories/devops/">DevOps</category><description>&lt;p&gt;I recently went through a job interview where the interviewer posed a seemingly routine question: &amp;ldquo;In your opinion, when should you use Kubernetes, and when is it unnecessary and just adds complexity?&amp;rdquo;&lt;/p&gt;
&lt;p&gt;I answered it fairly smoothly at the time, but the question lingered in my mind long afterward. What made it so &amp;ldquo;sharp&amp;rdquo; was that it stepped beyond the technical details of &amp;ldquo;how to use K8s&amp;rdquo; and cut straight to the core trade-off in architecture design: Are we introducing a tech stack to solve a real business pain point, or just to satisfy the team&amp;rsquo;s &amp;ldquo;anxiety about being cutting-edge&amp;rdquo;?&lt;/p&gt;</description></item><item><title>OWASP LLM Top 10 Security in Practice</title><link>https://shengxu.pages.dev/en/posts/owasp-llm-top-10-2026/</link><pubDate>Fri, 23 Jan 2026 10:00:00 +0800</pubDate><guid>https://shengxu.pages.dev/en/posts/owasp-llm-top-10-2026/</guid><category domain="https://shengxu.pages.dev/en/categories/security/">Security</category><category domain="https://shengxu.pages.dev/en/categories/ai/">AI</category><category domain="https://shengxu.pages.dev/en/categories/kubernetes/">Kubernetes</category><description>&lt;p&gt;Yesterday I had the privilege of attending a talk by Sergey Saburov from Acronis on &amp;ldquo;Agentic Engineering &amp;amp; LLM Security.&amp;rdquo; Sergey provided an in-depth analysis of security threats facing modern LLM applications, along with numerous real-world case studies aligned with the OWASP LLM Top 10 framework.&lt;/p&gt;
&lt;p&gt;I&amp;rsquo;ve organized and summarized the content based on the latest &lt;strong&gt;OWASP LLM Top 10 v2.0 (2025)&lt;/strong&gt; official standard. I&amp;rsquo;ve corrected some terminology discrepancies from the original talk (e.g., LLM06, LLM10) and compiled Python PoC (Proof of Concept) and defense scripts tailored for Kubernetes platform engineers, hoping this serves as a reference for building secure AI systems.&lt;/p&gt;</description></item><item><title>Helm 4 Deep Dive: More Than a Version Bump – A New Beginning for the Kubernetes-Native Era</title><link>https://shengxu.pages.dev/en/posts/helm-4-deep-dive-kubernetes-native-delivery/</link><pubDate>Thu, 22 Jan 2026 10:00:00 +0800</pubDate><guid>https://shengxu.pages.dev/en/posts/helm-4-deep-dive-kubernetes-native-delivery/</guid><category domain="https://shengxu.pages.dev/en/categories/kubernetes/">Kubernetes</category><category domain="https://shengxu.pages.dev/en/categories/devops/">DevOps</category><description>&lt;p&gt;In the infrastructure world, some version updates are &amp;ldquo;icing on the cake,&amp;rdquo; while others are &amp;ldquo;transformative.&amp;rdquo; If Helm 3 freed us from the nightmare of Tiller, then &lt;strong&gt;Helm 4&lt;/strong&gt;, officially released in &lt;strong&gt;November 2025&lt;/strong&gt;, marks the coming-of-age moment when Helm truly understood and embraced Kubernetes&amp;rsquo; declarative philosophy.&lt;/p&gt;
&lt;p&gt;After two months of community validation and official documentation refinement, this article will clarify the easily misunderstood technical details based on Helm 4&amp;rsquo;s actual release state.&lt;/p&gt;</description></item></channel></rss>