Intro to kubernetes
0 likes55 views
The document provides an in-depth overview of container technology, with a focus on Kubernetes as a container orchestration platform. It covers the history and evolution of containers, the need for orchestration, and the specific functionalities and benefits of using Kubernetes, including its role in managing microservices and optimizing resource allocation. Additionally, it discusses the limitations and areas where Kubernetes may require further development to enhance its capabilities.
More Related Content
Similar to Intro to kubernetes (20)
Intro to kubernetes
- 2. Contents Why even bother Containers Container Orchestrators Kubernetes - What? Why? How? Kubernetes - The details Extending Kubernetes Relation status - it’s complicated Going forward
- 4. Let’s define players Service based Event driven Open API No infra management Managed security Pay only for usage Developer Operator
- 7. Containers
- 8. Container - What's in a name? Coming from the shipping industry Caused aquatic theme for domain
- 9. Shipping containers Portability - can be used on any of supported types of ships Wide variety of cargo that can be packed inside Standard sizes - standard fittings on ships Many containers on a ship Isolates cargo from each other
- 10. Translated to software Portability - can be used on any supported system (system with container execution environment) Wide variety of software that can be packed inside Standard format Many containers to a physical node Isolates execution of one container from another
- 11. What is a container? way to pack code and dependencies together can run anywhere execute multiple containers to a physical machine
- 12. Sounds familiar? same concept as virtual machines pack OS and software together, to run in isolated instances can run anywhere the specific hypervisor runs multiple VMs to a physical machine
- 13. How do VMs work? hypervisor = layer between VM and kernel emulates system calls allows multiple types of operating systems on a machine (Windows on Linux) overhead for hypervisor
- 14. Containers on the other hand ... only contain application and application-related libraries and frameworks, that run on the host machine's kernel smaller lower overhead differences in OS distributions and dependencies are abstracted - same kernel
- 15. Working together, not against each other Windows on Linux possible only with VMs older software needs to be adapted to be run as containers (and won't) usage of VMs as a medium for containers (better isolation and easier scaling)
- 16. Greater modularity in software Monolithic application → independent services that interact (microservices)
- 17. Containers empowering microservices quicker start times -> easy to prototype or scale allow work to be done independently on modules -> independent releases for components (take care of interfaces) isolated and abstracted runtime environments, that can be tailored for each module shared runtime environment, for heterogeneous applications
- 18. Containers history – early days need for resources to be shared among many users -> multiple terminals connected to the same mainframe main problem - execution can cause the main computer to crash -> down for everybody
- 19. Containers history – Linux containers (lxc) 2008 Provides virtualization at OS level Provides containers with its own process and network space
- 20. Containers history – Docker 2013 Container execution and management system Originally started with lxc, then moved to libcontainer, which allows containers to work with: • linux namespaces • libcontainer control groups • capabilities • app armor security profiles • network interfaces • firewall rules
- 21. Containers history – OCI & CNCF Open Container Initiative – 2015 industry format for a container format and container runtime software for all platforms spend resources on developing additional software to support use of standard containers, instead of format alternatives Cloud Native Container Foundation – 2015 Working on different projects to further standardize the market: • Kubernetes • Container Network Interface • Containerd
- 23. Need for something more? docker started out with a CLI tool on top of lxc, that built, created, started, stopped and exec'd containers does management at a node level, upon specific requests easy to manually manage with up to 100s of containers and 10s of nodes, but what next?
- 24. Orchestrator manage and organize both hosts and docker containers running on a cluster main issue - resource allocation - where can a container be scheduled, to fulfill its requirements (CPU/RAM/disk) + how to keep track of nodes and scale
- 25. Some orchestrator tasks manage networking and access track state of containers scale services do load balancing relocation in case of unresponsive host service discovery attribute storage to containers
- 26. Orchestrator options Kubernetes – open-source, product of CNCF Apache Mesos – cluster management tool, with container orchestration being only one of the things it can do, originally through a plugin called Marathon Docker Swarm – integrated in docker container platform
- 27. Lately ... Mesos announced Kubernetes support as container orchestration, alongside Marathon Docker Enterprise Edition - integration with Kubernetes alongside Swarm → Kubernetes becoming the de-facto standard for container orchestration (allowing developers to focus on building on top instead of alternatives)
- 28. Kubernetes – What? Why? How?
- 29. What is Kubernetes? “Kubernetes” = Greek for governor, helmsman, captain open-source container orchestration system originally designed by Google, maintained by CNCF aim to provide "platform for automating deployment, scaling and operations of application containers across clusters of hosts"
- 30. Why Kubernetes? - Goals Main objectives, stated by devs, for community Achieve velocity Allow scaling of both software and teams Present abstract infrastructure Gain efficiency
- 31. Achieve velocity Velocity = number of things you ship while maintaining a highly available service Achieved by: • immutability - created artifact cannot be changed • declarative configuration - declare desired state and Kubernetes' job is to ensure it matches • self-healing systems - trying to maintain desired states if something changes
- 32. Allow scaling of software encouraging decoupling in applications - separated components that communicate via defined APIs via load-balanced services running in shared abstract environment, without interference utilizing standard container format that runs on any machine
- 33. Allow scaling of teams separation of concerns for consistency and scaling • application ops rely on the SLA provided by the platform • orchestrator ops uphold SLA
- 34. Present abstract infrastructure decoupling container images and machines cluster can be heterogeneous and reduce overhead and cost portability - container can be used on another cluster without being changed
- 35. Gain efficiency optimized usage of physical machines - multiple containers on same machine isolated with namespaces, to not interfere with each other
- 36. Kubernetes - the details
- 37. Container image format layered format, allowing to inherit from lower levels and to modify them by adding, changing or removing files using unified file system that allows this layering issue – deleted file remains in older layers image size bigger and build time longer -> development of better tools
- 38. Running a container image provides the filesystem base for execution configuration, to interoperate with the rest of the system – environment variables, CPU/RAM requirements, process to execute, ports to expose, etc.
- 39. Kubernetes and containers Can you deploy a container in Kubernetes? NO (not directly) Why not? Because the smallest deployable unit of computing is not a container, but ...
- 40. Pod smallest deployable unit of computing in Kubernetes colocated multiple apps(containers) into a single atomic unit, scheduled onto a single machine upon creation, statically allocated to a certain node
- 41. Pod each container runs in its own cgroup (CPU + RAM allocation), but they share some namespaces and filesystems, such as: • IP address and port space • same hostname • IPC channels for communication
- 42. So, why a pod and not container directly? all or nothing approach for a group of symbiotic containers, that need to be kept together at all times pod considered running if all containers are scheduled and running Can you deploy a container in Kubernetes? Yes, inside a pod!
- 43. Service abstraction which defines a logical set of Pods (selected using label selector), that provide the same functionality (same microservice) different types, for different types of exposure provided by the service
- 44. Deployment manages replica set through time and versions for pod spec scale != version update using health checks, makes sure a new version works allows rollbacks to older versions (keeps track of changes)
- 45. Deployment strategies - recreate all previous pods are destroyed and new pods are created quickest downtime while new pods start in case of problems and rollback, even more downtime
- 46. Kubernetes - next steps
- 47. Soooo many things to configure :( at least one controller some services some configMaps and Secrets preallocate persistentVolumes or create storage class for dynamic provisioning
- 48. Solution: another level of abstraction higher-level controller that can manage lower-level elements for the moment, not included in Kubernetes ... YET! BUT can be added, through third-party controllers
- 49. What is Helm? package manager for Kubernetes provides higher-level abstraction (Chart) to configure full-fledged applications manage complexity, easy upgrades, simple sharing of full application setups, safe rollbacks
- 50. How does Helm work? Helm CLI + Tiller server in Kubernetes (which is a controller) CLI responsible for management + requests for releases of charts on Kubernetes Tiller - listens for requests, combines chart + configuration = release, install release, track release
- 51. Helm++ Helm release controller - current Lentiq way to manage applications expose HelmRelease as a CRD (custom resource definition) in Kubernetes, to work directly with Kubernetes to manage apps
- 52. What are Operators? domain-specific controller manages lifetime of a single application works with Kubernetes primitives, as well as performing application-specific steps
- 53. Operators pre and post provision hooks, for application-specific operations single tool to perform all management (kubectl) work in a scalable, repeatable, standard fashion improve resiliency while reducing burden on IT teams
- 54. Relation status - it’s complicated Write Build a container image Deploy the application Expose at an endpoint Request-level load balancing Set up SSL/TLS Scale up based on demand Scale down to zero Canary deployments Monitor metrics
- 56. What Kubernetes missing ? Source-to-URL deploys Canary deployments, rollouts/rollbacks Kubernetes needs container images built/pushed Kubernetes has no notion of immutable revisions to cleanly rollback Manage application traffic Kubernetes cannot natively split traffic (lack of L7 HTTP load balancing) Out-of-the box monitoring Kubernetes doesn’t provide monitoring signals beyond CPU/memory Scale-to-zero Kubernetes cannot do natively
- 57. Going forward More projects will natively support k8s CockroachDB - A database architected and built for Kubernetes SiSense BI engine rewritten in k8s) More business scenarios (KubeFlow - Running ML/DS pipeline) Go serverless (Knative ,kubeless) Lightweight k8s (k3s - running on edge devices) Advanced k8s management systems (Multi cloud ,Backup and restore ,Security)
- 58. Q&A