code: func (ssc *defaultStatefulSetControl) UpdateStatefulSet(set *apps.StatefulSet, pods []*v1.Pod) error {
  
  	// list all revisions and sort them
  	revisions, err := ssc.ListRevisions(set)
  	if err != nil {
  		return err
  	}
  	history.SortControllerRevisions(revisions)
  
  	// get the current, and update revisions
  	currentRevision, updateRevision, collisionCount, err := ssc.getStatefulSetRevisions(set, revisions)
  	if err != nil {
  		return err
  	}
  
  	// perform the main update function and get the status
  	status, err := ssc.updateStatefulSet(set, currentRevision, updateRevision, collisionCount, pods)
  	if err != nil {
  		return err
  	}
  
  	// update the set's status
  	err = ssc.updateStatefulSetStatus(set, status)
  	if err != nil {
  		return err
  	}
  
  	klog.V(4).Infof("StatefulSet %s/%s pod status replicas=%d ready=%d current=%d updated=%d",
  		set.Namespace,
  		set.Name,
  		status.Replicas,
  		status.ReadyReplicas,
  		status.CurrentReplicas,
  		status.UpdatedReplicas)
  
  	klog.V(4).Infof("StatefulSet %s/%s revisions current=%s update=%s",
  		set.Namespace,
  		set.Name,
  		status.CurrentRevision,
  		status.UpdateRevision)
  
  	// maintain the set's revision history limit
  	return ssc.truncateHistory(set, pods, revisions, currentRevision, updateRevision)
  }
docs: // UpdateStatefulSet executes the core logic loop for a stateful set, applying the predictable and
  // consistent monotonic update strategy by default - scale up proceeds in ordinal order, no new pod
  // is created while any pod is unhealthy, and pods are terminated in descending order. The burst
  // strategy allows these constraints to be relaxed - pods will be created and deleted eagerly and
  // in no particular order. Clients using the burst strategy should be careful to ensure they
  // understand the consistency implications of having unpredictable numbers of pods available.