Autoscaling Kubernetes
- 2. A quick recap Node / Kubelet Pod ContainerContainerContainer Pod Container Node / Kubelet Pod Container Container Pod ContainerContainerContainer Node / Kubelet Pod Node / Kubelet Pod Container Container Pod Master Replication Controller Replication Controller ContainerContainerContainerContainer Kubernetes
- 3. Revision Autoscaling Autoscaling: the ability of a system to automatically adjust the amount of used computational resources based on the load Benefits: ● reduce cost (on cloud provider) ● reduce power consumption Horizontal: scale the number of instances Vertical: scale the resources used by an instance
- 4. Autoscaling Kubernetes Kubernetes Nodes Pods Horizontal # of nodes # of pods Vertical resources for a node resources for a pod
- 5. Kubernetes Horizontal autoscaling of nodes Nodes Pods Horizontal # of nodes # of pods Vertical resources for a node resources for a pod
- 6. Example: on Google Cloud Platform Autoscaling nodes Google Compute Engine: ● Infrastructure as a Service (IaaS) ● user can create virtual machines on demand ● charged on a base of per-minute cost Google Compute Engine is an exemplary platform for Kubernetes: ● user may set-up his own cluster on Google Compute Engine ● user may buy a predefined cluster (Google Container Engine) In both cases, Google Compute Engine virtual machine are used as hosts for Kubernetes master and nodes.
- 7. Managed Instance Group Autoscaling nodes Manage virtual machines in bulk! Managed Instance Groups (Google Compute Engine) collectively manage groups of similar virtual machine instances (in the same zone). A Managed Instance Group creates virtual machines on a base of instance template: ‒ image (e.g.: debian distribution) ‒ startup script (e.g.: install pkgs and start services) ‒ shutdown script (e.g: gracefully stop services) ‒ + more... Managed Instance Groups can be manually resized. Managed Instance Groups are now available for Google Compute Engine users.
- 8. Autoscaling MIGs Autoscaling nodes Let the Cloud Autoscaler choose the best size of Managed Instance Group for you! Intent based: ● User specifies average target utilization level for VMs. ● Cloud Autoscaler collects and interprets utilization data and determines how many VMs should be added or removed from the Managed Instance Group to achieve close to the target utilization. Autoscaling policies (currently supported): ● CPU utilization, ● HTTP load balancing serving capacity, ● Custom Cloud Monitoring Metrics. Autoscaling behaviour: increase rapidly, decrease gracefully. Cloud Autoscaler is now available as for Google Compute Engine users.
- 9. Kubernetes on a MIG Autoscaling nodes NodeController automatically discovers nodes by querying cloud provider (based on a regular expression for node names). Let’s create a Managed Instance Group for nodes! Resize of Managed Instance Group → resize of cluster. Master remains on a separate VM (not in the Managed Instance Group), unaffected by resize.
- 10. Problems Autoscaling nodes ● Each node needs to have an IP range (for pods): NodeController distributes IP ranges to nodes during assimilation of a new node. ● Graceful removal of node: ○ mark node an unschedulable in spec (no new pods will be scheduled on it) ○ notify containers that the nodes will be removed (they can stop accepting new traffic, finish writing persistent data, etc) ○ wait for a while before removal May be triggered by shutdown script in Managed Instance Group. ● Rebalancing of pods on node addition: ○ adding new node will not affect already schedule pods ○ the new node may be empty, potentially for a long time ○ first add node, then increase replication controllers May be solved by rescheduling/rebalancing. Done Proposal ???
- 11. Autoscaling Kubernetes nodes Autoscaling nodes Just use Cloud Autoscaler to scale Managed Instance Group for nodes! Considered signals for scaling: ● resource utilization (CPU, memory) ● signals from scheduler (e.g.: # of pending pods)
- 12. Horizontal autoscaling of Pods Kubernetes Nodes Pods Horizontal # of nodes # of pods Vertical resources for a node resources for a pod
- 13. Autoscaling Replication Controllers Autoscaling pods Effort started by Red Hat. AutoScaler: ● abstraction on the top of ReplicationController, ● calls resize on RC, ● RC is unaware of AutoScaler. Two approaches: ● intention based - try to maintain the given value; ● rule based - if the given value is reached, execute the given action (increment/decrement). Proposal
- 14. Problems Autoscaling pods Simplest solution: AutoScaler acts on a single ReplicationController. However: we often have many RCs for service (e.g.: rolling update). Improved solution: AutoScaler acts on set of RCs (with matching labels): ● monitor selector - RCs to monitor ● target selector - RCs to act on (the largest of them) ● during deployment / rolling update - option to disable decrement How to collect signals: ● cAdvisor → Heapster → InfluxDB ● Google Cloud Monitoring (Google Container Engine) Proposal ???
- 15. Autoscaling during rolling update Autoscaling pods Replication Controller version 1.4 Auto Scaler Pod Pod Pod Pod ↕
- 16. Autoscaling during rolling update Autoscaling pods Replication Controller version 1.4 Auto Scaler Pod Pod Pod ↑ Replication Controller version 1.6 Pod Pod
- 17. Autoscaling during rolling update Autoscaling pods Replication Controller version 1.4 Auto Scaler Pod Pod Replication Controller version 1.6 Pod Pod Pod ↑
- 18. Autoscaling during rolling update Autoscaling pods Replication Controller version 1.6 Auto Scaler Pod Pod Pod Pod ↕
- 19. Problems Autosclaing pods Simplest solution: AutoScaler acts on a single ReplicationController. However: we often have many RCs for service (e.g.: rolling update). Improved solution: AutoScaler acts on set of RCs (with matching labels): ● monitor selector - RCs to monitor ● target selector - RCs to act on (the largest of them) ● during deployment / rolling update - option to disable decrement How to collect signals: ● cAdvisor → Heapster → InfluxDB ● Google Cloud Monitoring (Google Container Engine) Proposal ???
- 20. Questions?