Process-Control #

Process-control (aka feedback-control) style is suitable when the system’s purpose is to maintain certain properties of a process output near a desired reference value (set point), despite disturbances.

Topology #

Example component diagram:

• Component
  • Controller: computes actions based on the set point and observed output.
  • Process / plant: the physical or software process being controlled.
• Connector
  • Sensors / feedback: measures controlled variables and feeds them back to the controller.
  • Actuators: applies manipulated variables to the process.

Pros and cons #

• Pros
  • Robustness: can adapt to changing conditions and keep the system within acceptable bounds.
  • Autonomy: supports self-correcting behaviors (within designed limits).
• Cons
  • Cost and complexity: requires monitoring/telemetry, calibration, and control logic.
  • Latency sensitivity: delayed or noisy feedback can cause oscillations/instability.
  • Safety and verification: incorrect control logic can have severe consequences; often needs simulation and rigorous testing.

Variants #

• Open-loop vs closed-loop: closed-loop uses feedback (shown above); open-loop does not.
• PID control: proportional–integral–derivative controllers are common in physical systems.
• Hierarchical control: multiple nested controllers (e.g., local controllers + global supervisor).

Real-world examples #

Kubernetes controllers (reconciliation loops) #

Kubernetes is a software-native example of feedback control: controllers continuously observe current state (via the API server) and take actions to move it toward the desired state declared in resource specs. If we map it to the topology, the controller is the controller, the cluster is the “plant”, and the API server plus watches act like the sensors/feedback loop. The key adaptation for distributed systems is idempotent reconciliation: controllers must converge correctly even with duplicate events, partial failures, and retries.

Further reading: Kubernetes docs: Controllers, Kubernetes and reconciliation patterns (blog)

Operator development and “good reconciliation” practices (Kubebuilder) #

Kubebuilder documents patterns for writing safe control loops (e.g., designing reconcilers around desired state rather than event types, and ensuring re-entrancy/idempotency). This is a practical bridge between the control-theory loop diagram and real distributed systems constraints.

Further reading: Kubebuilder Book: Good Practices

Autoscaling as feedback control #

Autoscalers implement a control loop where a controller monitors a metric (CPU utilization, request latency, queue length) and adjusts capacity (replicas/instances). Here, the components include the autoscaler controller and the scalable workload, and the connectors are telemetry signals (metrics) and scaling actions (changing replica counts). Delays and noisy measurements can still cause oscillation if not handled carefully.