From the course: Spring on Kubernetes: Deploying and Managing Cloud-Native Applications

Containerized workloads - Spring Boot Tutorial

From the course: Spring on Kubernetes: Deploying and Managing Cloud-Native Applications

Start my 1-month free trial Buy for my team

Containerized workloads

“

- [Instructor] Kubernetes is an orchestration engine, and as such, we need to discuss a little bit about containerized workloads as that's what Kubernetes orchestrates. Let's start with a brief history of containerization because this may be shocking to some of you. The idea of segregation in computing in a single server is older than me and probably most of you. Sandboxing processes and using shared resources makes sense financially and is a responsible option when you look at the power consumption of computers. In 1979, chroot was introduced in Unix 7, making the first major jump into the world of container and process isolation, even though containerization as a concept in sandboxing had been around since the '60s. Several advancements continued through the years, especially in namespaces, and then in 2008, we had the introduction of Linux Containers or LXC. This was really the first complete thought in Linux containers, leveraging both cgroups and namespaces running on a single kernel without patches. The years passed with several other advancements building on LXC and then deviating from it. Looking at you, Warden. And then in 2013, the entire world changed with Docker. Much like Warden, Docker leveraged LXC and then replaced it, this time, with libcontainer. But what really made the container world explode with Docker was the ecosystem that came with it. As containers began replacing traditional virtualization, thanks in part to tools like Kubernetes, many of us were all in on this new world. containerd was donated to the CNCF, and all was well. And then the landscape shifted again with Docker Enterprise being acquired. Despite the changes and the turmoil, containerization continued to grow, and today, it has become the defacto way of building distributed platforms. So let's talk about what containers really are. At their highest level, a container is a packaged and isolated runtime for running all of your application workloads. One of the biggest benefits, especially from a cloud native viewpoint, is that these containers bring all of their dependencies with them. This means any tool you need, you package with your container instead of relying on it being provided to you, which inherently has caused more software bugs than many of us, including myself, care to admit. These packaged, isolated, and independent containers yield truly portable and self-contained applications that can run anywhere that you can run the container itself, which includes almost every modern operating system, including the Cloud and Enterprise abstractions. One thing that is important to know is that the kernel itself is shared with the host and all other containers running on that host. There are not complete operating systems within the kernel. Even though we think of them from the distro perspective, it is not the complete OS. While the kernel is shared, the application processes are all isolated, building a sandboxed environment.

Contents