Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Evolution of Kubernetes - Google's Borg

Evolution of Kubernetes - Google's Borg

Avatar for Mithun Arunan

Mithun Arunan

May 04, 2019

More Decks by Mithun Arunan

Other Decks in Technology

Transcript

  1. • Google’s Borg ◦ User perspective ◦ Architecture ◦ Components

    - Master ◦ Components - Scheduler ◦ Components - Borglet ◦ Deployment from beginning ◦ Scalability ◦ Utilization ◦ KubeOps View Agenda • Introduction ◦ What is Kubernetes? ◦ Why Kubernetes? ◦ Kubernetes Timeline Evolution of Kubernetes - Google’s Borg
  2. Kubernetes is an open source container orchestration platform, for automating

    deployments, scaling and management and other operational burden of applications. Kubernetes was designed from the ground-up as a loosely coupled collection of components centered around these key aspects. It abstracts away the underlying hardware of the nodes and provides a uniform interface for applications to be both deployed and consume the shared pool of resources. Intro - What is Kubernetes? Evolution of Kubernetes - Google’s Borg
  3. Puppet, Chef and Ansible used to be the most preferred

    configuration management tools for DevOps Teams. Deploying new services to production required rigorous work, - Boot up a dedicated VM instance with required OS & resources (RAM, CPU, Disk) after careful considerations (With the preferred cloud provider or on-premise) - Write custom multiple chef recipes/puppet scripts to automate processes like Initial setup, Configuration, Deployments and Shutdown. Eg., AWS OpsWorks - For each deployments, the chef recipe should contain steps to pull latest application code, install dependencies and other custom configurations based on the operating system and the application framework. - After testing the chef recipes, setup service discovery and Health checks for monitoring. It’s completely manual and time-consuming process to deploy services. Before containers and kubernetes Evolution of Kubernetes - Google’s Borg
  4. Kubernetes - Timeline 2003: Google Borg Internal cluster management tool

    running hundreds of thousands of jobs. 2013: Transitions from Borg to Omega For clusters with large scale compute 2014: Google Introduces Kubernetes 2015: The year of Kube v1.0 & CNCF 2016: The Year Kubernetes Goes Mainstream! 2017: The Year of Enterprise Adoption & Support - GKE, EKS, AKS 2018: Vernacular.ai embraces Kubernetes Evolution of Kubernetes - Google’s Borg
  5. Google’s Borg Google’s Borg system is a cluster manager that

    runs hundreds of thousands of jobs, from many thousands of different applications, across a number of clusters each with up to tens of thousands of machines. Google’s Borg maintains the lifecycle of all the applications. It Admits, Schedules, Starts, Restarts and Monitors the application. Hides the internal details of resource management and failure handling so it's users can focus on application development. Operates with very high reliability and availability, and supports applications that do the same Evolution of Kubernetes - Google’s Borg
  6. Borg's users are Google developers and SRE's who runs many

    application and services. User submits their work as tasks that run as one or more jobs in a Borg Cell. Google’s Borg - User perspective Evolution of Kubernetes - Google’s Borg
  7. A Borg cell contains many machines, it has - Borg

    master, centralized controller - Borglet, in each worker machine. Borg Master - Handles the client RPC calls and mutates the state of the workloads. Borg master process is logically one, but replicated five times. Each replica maintains an in-memory copy of the state of the cell and this state is also recorded in a highly available Paxos based store on the replica's local store. When a job is submitted, the Borgmaster records it persistently in the Paxos store and adds the job’s tasks to the pending queue. Google’s Borg - Master Evolution of Kubernetes - Google’s Borg
  8. The pending queue is scanned asynchronously by the scheduler, which

    assigns tasks to machines if there are sufficient available resources that meet the job’s constraints. The scheduling algorithm has two parts: - Feasibility checking, to find machines on which the task could run - Scoring, which picks one of the feasible machines. E-PVM approach, minimizes the change in cost when placing a task ends up spreading the tasks in multiple machines at the expense of large tasks that require more resources, "worst fit" algorithm. "Best fit" algorithm tries to pack the worker machines as much tightly as possible, leaving other machines empty of jobs. Borg’s scoring model is a hybrid one that tries to reduce the amount of stranded resources – ones that cannot be used. It provides about 3–5% better packing efficiency Google’s Borg - Scheduler Evolution of Kubernetes - Google’s Borg
  9. Google’s Borg - Borglet The Borglet is a local Borg

    agent that is present on every machine in a cell. It manages the workloads and reports the state of the machine to the Borg master and other monitoring systems. The Borg master polls each Borglet every few seconds to retrieve the machine’s current state and send it any outstanding requests. If a Borglet does not respond to several poll messages its machine is marked as down and any tasks it was running are rescheduled on other machines. Evolution of Kubernetes - Google’s Borg
  10. Score caching Evaluating feasibility and scoring a machine is expensive,

    so Borg caches the scores until the properties of the machine or task change Equivalence classes Tasks in a Borg job usually have identical requirements and constraints, so rather than determining feasibility for every pending task on every machine, and scoring all the feasible machines, Borg only does feasibility and scoring for one task per equivalence class Relaxed randomization It is wasteful to calculate feasibility and scores for all the machines in a large cell, so the scheduler examines machines in a random order until it has found “enough” feasible machines to score, and then selects the best within that set. Google’s Borg - Scalability Evolution of Kubernetes - Google’s Borg
  11. Google’s Borg - Utilization Evolution of Kubernetes - Google’s Borg

    Borg’s primary goals is to make efficient use of Google’s fleet of machines, which represents a significant financial investment, increasing utilization can save millions of dollars. Evaluation methodology Cell compaction technique, given a workload, find out how small a cell it could be fitted into by removing machines until the workload no longer fitted. Experiment with same set of workload in different cells and then plot min and max machines needed in a graph allot 90%ile resources for better policies that promises scheduling and cost benefits. Cell Sharing Running both production and non-production workloads in the same cell increases resource utilization. Large cells Google runs large cells to run large compute and to avoid cell fragmentations
  12. Fine-grained resource requests & Resource reclamation - Resource requests -

    Resource limits - Resource usage Borg users request CPU in units of milli-cores, and memory and disk space in bytes. Google’s Borg - Utilization Evolution of Kubernetes - Google’s Borg
  13. Kubernetes Direct Borg analogues Borg containers => Docker containers alloc

    (task group) => pod (container group) Borglet => Kubelet Persistent, declarative specs Improvisation labels + label queries service abstraction composable microservices replication controller Evolution of Kubernetes - Google’s Borg