[HN Gopher] Understanding ReplicaSet vs. StatefulSet vs. DaemonS...
       ___________________________________________________________________
        
       Understanding ReplicaSet vs. StatefulSet vs. DaemonSet vs.
       Deployments
        
       Author : Abhisman
       Score  : 51 points
       Date   : 2025-01-05 13:06 UTC (1 days ago)
        
 (HTM) web link (abhisman.notion.site)
 (TXT) w3m dump (abhisman.notion.site)
        
       | ofrzeta wrote:
       | Doesn't seem to offer more insights than the Kubernetes docs.
        
         | LetMeLogin wrote:
         | Totally. Plus it's misguiding readers with different
         | functionality and use cases.
         | 
         | For example "Persistent Storage: StatefulSets provide
         | persistent storage to their pods through Kubernetes
         | PersistentVolumes".
         | 
         | The thing is that STS doesn't do that. That's actually in POD
         | definition.
        
           | MuffinFlavored wrote:
           | I had no idea... probably shows I haven't hit an advanced
           | enough use case.
           | 
           | > why isn't a statefulset just a deployment/pod with PVC
           | mounted?
           | 
           | * StatefulSets provide predictable pod names and hostnames
           | (pod-0, pod-1)
           | 
           | * StatefulSets handle pods sequentially (0-1-2), ensuring
           | proper cluster initialization.
           | 
           | * StatefulSets maintain a consistent pod-to-PVC mapping even
           | after pod rescheduling.
           | 
           | * StatefulSets delete pods in reverse order,
        
             | wbl wrote:
             | You can look at the structure in TFA to see this. The only
             | discussion of the volume mounting is in the pod template,
             | not the Stateful Set itself.
        
             | vanillax wrote:
             | You can map a PVC back to a pod without statefulset. You
             | just need to create the PV and PVC and map it to a
             | deployment.
        
           | sitkack wrote:
           | "Come on!"
        
           | vanillax wrote:
           | Agree. Its more confusion. PVC / PV are native to k8s not
           | something part of statefulsets. In fact you _probably_ only
           | need to use Statefulsets for databases. Which is probably
           | going to be abstracted away with Operators.
        
             | verdverm wrote:
             | It's more about roll forward/backward and services with a
             | master+replica or leader election. That PVCs are common in
             | stateful sets is more a symptom than the cause
        
               | vanillax wrote:
               | Yea for sure. Thats why I dropped the term database
               | because thats the exact scenario ( master / replica )
               | where pod consistency naming,dns, network etc is
               | important for StatefulSet.
        
           | null0pointer wrote:
           | Author is most likely farming credibility with blog spam.
        
       | kevmo314 wrote:
       | > Understanding the nuances and distinctions between these key
       | concepts becomes crucial as you navigate the complex -- yet
       | rewarding -- waters of container orchestration.
       | 
       | Can't say I've ever felt rewarded for using Kubernetes, literally
       | or metaphorically.
        
         | smitelli wrote:
         | Early on I heard the k8s controller ecosystem described as "a
         | half dozen concurrent `while true` loops all fighting with each
         | other." Can't say I disagree.
        
           | pphysch wrote:
           | Isn't that distributed systems in a nutshell?
        
           | ithkuil wrote:
           | Isn't that what we all are?
        
       | dgfitz wrote:
       | I hope I've avoided containers enough to let this phase pass by.
       | Formalizing vocabulary around the different states of a container
       | makes me want to throw up my hands in a Seinfeld "come one"
       | motion.
        
         | Leo_Verto wrote:
         | Like it or not, containers are here to stay. They just make way
         | too much sense as an atomic unit for delivering applicstions
         | and really aren't that complicated.
         | 
         | Kubernetes is a whole nother beast though and while it
         | introduces a ton of overhead, it can be useful at a certain
         | organisational scale as an API definition for delivering
         | services to other teams.
        
         | crabbone wrote:
         | This isn't about the state of container. It's about
         | interactions between several containers (a group of containers
         | is called a pod). Which, probably, doesn't make it better for
         | you, but for the sake of correctness...
        
       ___________________________________________________________________
       (page generated 2025-01-06 23:01 UTC)