• Controllers
    • Controller pattern
      • Control via API server
      • Direct control
    • Desired versus current state
    • Design
    • Ways of running controllers
    • What's next
    • Feedback

    Controllers

    In robotics and automation, a control loop isa non-terminating loop that regulates the state of a system.

    Here is one example of a control loop: a thermostat in a room.

    When you set the temperature, that’s telling the thermostatabout your desired state. The actual room temperature is thecurrent state. The thermostat acts to bring the current statecloser to the desired state, by turning equipment on or off.

    In Kubernetes, controllers are control loops that watch the state of yourclusterA set of machines, called nodes, that run containerized applications managed by Kubernetes. A cluster has at least one worker node and at least one master node., then make or requestchanges where needed.Each controller tries to move the current cluster state closer to the desiredstate.

    Controller pattern

    A controller tracks at least one Kubernetes resource type.These objectshave a spec field that represents the desired state. Thecontroller(s) for that resource are responsible for making the currentstate come closer to that desired state.

    The controller might carry the action out itself; more commonly, in Kubernetes,a controller will send messages to theAPI serverControl plane component that serves the Kubernetes API. that haveuseful side effects. You’ll see examples of this below.

    Control via API server

    The JobA finite or batch task that runs to completion. controller is an example of aKubernetes built-in controller. Built-in controllers manage state byinteracting with the cluster API server.

    Job is a Kubernetes resource that runs aPodThe smallest and simplest Kubernetes object. A Pod represents a set of running containers on your cluster., or perhaps several Pods, to carry outa task and then stop.

    (Once scheduled, Pod objects become part of thedesired state for a kubelet).

    When the Job controller sees a new task it makes sure that, somewherein your cluster, the kubelets on a set of Nodes are running the rightnumber of Pods to get the work done.The Job controller does not run any Pods or containersitself. Instead, the Job controller tells the API server to create or removePods.Other components in thecontrol planeThe container orchestration layer that exposes the API and interfaces to define, deploy, and manage the lifecycle of containers.act on the new information (there are new Pods to schedule and run),and eventually the work is done.

    After you create a new Job, the desired state is for that Job to be completed.The Job controller makes the current state for that Job be nearer to yourdesired state: creating Pods that do the work you wanted for that Job, so thatthe Job is closer to completion.

    Controllers also update the objects that configure them.For example: once the work is done for a Job, the Job controllerupdates that Job object to mark it Finished.

    (This is a bit like how some thermostats turn a light off toindicate that your room is now at the temperature you set).

    Direct control

    By contrast with Job, some controllers need to make changes tothings outside of your cluster.

    For example, if you use a control loop to make sure thereare enough NodesA node is a worker machine in Kubernetes.in your cluster, then that controller needs something outside thecurrent cluster to set up new Nodes when needed.

    Controllers that interact with external state find their desired state fromthe API server, then communicate directly with an external system to bringthe current state closer in line.

    (There actually is a controller that horizontally scales thenodes in your cluster. SeeCluster autoscaling).

    Desired versus current state

    Kubernetes takes a cloud-native view of systems, and is able to handleconstant change.

    Your cluster could be changing at any point as work happens andcontrol loops automatically fix failures. This means that,potentially, your cluster never reaches a stable state.

    As long as the controllers for your cluster are running and able to makeuseful changes, it doesn’t matter if the overall state is or is not stable.

    Design

    As a tenet of its design, Kubernetes uses lots of controllers that each managea particular aspect of cluster state. Most commonly, a particular control loop(controller) uses one kind of resource as its desired state, and has a differentkind of resource that it manages to make that desired state happen.

    It’s useful to have simple controllers rather than one, monolithic set of controlloops that are interlinked. Controllers can fail, so Kubernetes is designed toallow for that.

    For example: a controller for Jobs tracks Job objects (to discovernew work) and Pod object (to run the Jobs, and then to see when the work isfinished). In this case something else creates the Jobs, whereas the Jobcontroller creates Pods.

    Note:

    There can be several controllers that create or update the same kind of object.Behind the scenes, Kubernetes controllers make sure that they only pay attentionto the resources linked to their controlling resource.

    For example, you can have Deployments and Jobs; these both create Pods.The Job controller does not delete the Pods that your Deployment created,because there is information (labelsTags objects with identifying attributes that are meaningful and relevant to users.)the controllers can use to tell those Pods apart.

    Ways of running controllers

    Kubernetes comes with a set of built-in controllers that run insidethe kube-controller-managerComponent on the master that runs controllers.. Thesebuilt-in controllers provide important core behaviors.

    The Deployment controller and Job controller are examples of controllers thatcome as part of Kubernetes itself (“built-in” controllers).Kubernetes lets you run a resilient control plane, so that if any of the built-incontrollers were to fail, another part of the control plane will take over the work.

    You can find controllers that run outside the control plane, to extend Kubernetes.Or, if you want, you can write a new controller yourself.You can run your own controller as a set of Pods,or externally to Kubernetes. What fits best will depend on what that particularcontroller does.

    What's next

    • Read about the Kubernetes control plane
    • Discover some of the basic Kubernetes objects
    • Learn more about the Kubernetes API
    • If you want to write your own controller, see Extension Patterns in Extending Kubernetes.

    Feedback

    Was this page helpful?

    Thanks for the feedback. If you have a specific, answerable question about how to use Kubernetes, ask it onStack Overflow.Open an issue in the GitHub repo if you want toreport a problemorsuggest an improvement.