从Service Fabric转Kubernetes：升级域与故障域相关技术问询

Great question! I’ve worked with both Service Fabric and Kubernetes, so let me break down how Kubernetes handles the high-availability and controlled upgrade patterns you’re familiar with from Service Fabric.

Failure Domains in Kubernetes #

Service Fabric’s failure domains group nodes to avoid losing all instances of a service if a single infrastructure component (like a rack or availability zone) fails. Kubernetes doesn’t have an explicit "failure domain" concept, but it achieves the same goal using topology labels and pod topology spread constraints.

• Topology Labels: Kubernetes uses standard node labels like topology.kubernetes.io/zone (for availability zones) and topology.kubernetes.io/region (for geographic regions) to categorize nodes into logical failure domains. You can also add custom labels (e.g., failure-domain.k8s.io/rack) to group nodes by rack, server group, etc.
• Pod Topology Spread Constraints: These let you control how pods are distributed across these topology domains to prevent pod concentration in a single failure domain. For example:

  apiVersion: apps/v1
  kind: Deployment
  metadata:
    name: my-app
  spec:
    replicas: 6
    selector:
      matchLabels:
        app: my-app
    template:
      metadata:
        labels:
          app: my-app
      spec:
        topologySpreadConstraints:
        - maxSkew: 1
          topologyKey: topology.kubernetes.io/zone
          whenUnsatisfiable: DoNotSchedule
          labelSelector:
            matchLabels:
              app: my-app
  

  This configuration ensures no availability zone has more than 1 pod more than any other zone for your app, minimizing the impact of a zone outage.

You can also use node affinity/anti-affinity for simpler distribution rules, but topology spread constraints offer more granular control over pod placement across failure domains.

Upgrade Domains in Kubernetes #

Service Fabric’s upgrade domains let you roll out updates in batches, ensuring a subset of nodes is upgraded at a time while keeping the service available. Kubernetes uses rolling updates (the default strategy for Deployments and StatefulSets) to replicate this behavior, though it works a bit differently than pre-defined upgrade domains.

For Deployments (Stateless Services) #

The rolling update strategy controls how many pods are replaced during an update using two key parameters:

• maxSurge: The maximum number of extra pods that can be created above the desired replica count during the update.
• maxUnavailable: The maximum number of pods that can be unavailable during the update.

Example configuration:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-stateless-app
spec:
  strategy:
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 0
    type: RollingUpdate
  # ... rest of deployment spec

Here, maxUnavailable: 0 ensures no pods are taken down before new ones are ready, and maxSurge: 25% means updates roll out in batches of 25% of the replica count. This keeps your service fully available during the upgrade, just like Service Fabric’s upgrade domains.

For StatefulSets (Stateful Services) #

StatefulSets use an ordered rolling update strategy by default, updating pods one at a time (starting from the highest ordinal) or in batches if you configure partition. This ensures stateful services maintain consistency during updates, similar to how Service Fabric handles stateful service upgrades across domains.

Beyond Basic Rolling Updates #

If you need more control (like canary releases to a subset of users first), Kubernetes supports patterns like canary deployments (using multiple Deployments with traffic splitting) or blue-green deployments, but the core rolling update mechanism is the closest equivalent to Service Fabric’s upgrade domains.

Key Difference to Note #

Unlike Service Fabric, where upgrade domains are pre-defined node groups, Kubernetes doesn’t require pre-configured "upgrade domains"—instead, it uses dynamic batch sizing based on your replica count and update strategy parameters. The end result is the same: controlled, highly available updates.

内容的提问来源于stack exchange，提问作者Vaccano