<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>Containers on Shubham Singh</title>
    <link>https://1shubham7.blog/tags/containers/</link>
    <description>Recent content in Containers on Shubham Singh</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en-us</language><atom:link href="https://1shubham7.blog/tags/containers/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>How Log Collectors Collect and Label Your Logs</title>
      <link>https://1shubham7.blog/log-collection-and-labels/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      
      <guid>https://1shubham7.blog/log-collection-and-labels/</guid>
      <description>A container log line on disk contains no idea which pod wrote it. Everything you filter by later is constructed by the collector at collection time. What the file actually looks like, how collectors find it, where every label comes from, and why that design decides the health of your logging stack.</description>
    </item>
    
    <item>
      <title>Where Linux Meets Kubernetes: Six Mental Models for When top Isn&#39;t Enough</title>
      <link>https://1shubham7.blog/linux-concepts/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      
      <guid>https://1shubham7.blog/linux-concepts/</guid>
      <description>Processes and signals, namespaces and cgroups, memory, storage, networking, and identity: the mechanism behind each, the two or three ways it breaks under a pod, and the one check that confirms it. Written from on-call across 100&#43; production Kubernetes clusters.</description>
    </item>
    
  </channel>
</rss>
