Introduction to Containers

 

Section: Introduction to Containers

By the end of this lesson, you should understand:

• What containers are and why we need them.

• The difference between physical servers, virtual machines (VMs), and containers.

• How containers work.

• Why containers are important for Kubernetes and GKE.

1. First, understand the problem

Imagine you have developed a Java Spring Boot application.

For your application to run, you need:

• Java (JDK/JRE)

• Required libraries and dependencies

• Configuration files

• Your application code

The problem is that your application works on your laptop but fails on another computer because the Java version or dependencies are different.

Containers solve this problem by packaging your application with its required dependencies.

2. The evolution: Physical servers → VMs → Containers

1. Physical servers

Imagine one physical computer dedicated to running your application.

Problems:

• Hardware is expensive.

• Resources can be wasted.

• Scaling requires additional machines.

• Setup and maintenance take time.

2. Virtual machines (VMs)

A single physical computer can run multiple virtual computers using software called a hypervisor.

Each VM has its own operating system.

Advantages: Better resource utilization and faster provisioning.

Limitations: Each VM needs its own OS, uses more resources, and takes time to boot.

3. Containers

Containers isolate applications and their dependencies while sharing the host operating system's kernel.

Advantages:

• Lightweight.

• Start quickly.

• Use resources efficiently.

• Easier to move between compatible environments.

3. What exactly is a container?

Think of a container as a packed lunchbox.

fyndiq.se

Your lunchbox contains everything you need for lunch. Similarly, a container image packages the application code and its required runtime, libraries, and configuration.

For example, a Java application might need:

• Your Spring Boot application JAR.

• A compatible Java runtime.

• Required libraries and supporting files.

These are packaged into a container image. A container runtime can then use that image to run the application.

One important detail: a container does not normally contain its own complete operating system kernel. It uses the kernel provided by the host environment.

4. VM vs Container — the most important difference

Virtual machine architecture

Physical hardware ->Hypervisor ->

VM 1-Guest OS-Application A

VM 2 -Guest OS-Application B

Container architecture

Physical hardware ->Host operating system and kernel ->

Container A ->App + dependencies

Container B ->App + dependencies

Conceptual diagrams: containers share the host kernel, while VMs have separate guest operating systems.

Feature	Virtual machine	Container
Operating system	Each VM has its own guest OS	Shares the host kernel
Size	Usually larger	Usually smaller
Startup	Generally slower	Generally faster
Resource usage	Higher overhead	Lower overhead
Isolation	Separate guest OS boundary	Process and resource isolation
Portability	VM images depend on compatible virtualization environments	Images run wherever a compatible container runtime and environment are available

Remember: containers are portable, but not universally compatible. For example, a Linux container generally requires a Linux kernel environment, even when running on a Windows laptop through a Linux VM.

5. What is a hypervisor?

A hypervisor is software that creates and manages virtual machines on physical hardware.

For example, suppose a physical server has 64 GB of RAM. A hypervisor can allocate resources to multiple VMs according to their configurations and needs.

Examples include KVM and VMware ESXi.

Each VM has its own guest operating system, which is why running many VMs can consume significant resources.

6. What is a kernel and user space?

• Kernel: The core of the operating system. It manages CPU time, memory, devices, and processes.

• User space: The environment where applications and ordinary programs run.

Containers isolate applications in user space while sharing the host kernel.

This is why you can run many containers on one machine without booting a complete operating system for each application.

7. What is a container image?

A container image is the packaged template used to create containers.

For example, you build a Spring Boot application and package it into a Docker image. You can then use that same image in development, testing, and production.

Here is the typical workflow:

1. Write application code

Java / Spring Boot

2. Build a container image

Application + runtime + dependencies

3. Store the image

For example, Google Artifact Registry

4. Run the container

On a VM or in Google Kubernetes Engine

A simple distinction:

• Image: The packaged template.

• Container: A running instance of that image.

One image can be used to create multiple containers.

8. What is Google Cloud Build?

Google Cloud Build is a Google Cloud service that automates building software artifacts, including container images.

For example, when you update your Spring Boot application's code, a build pipeline can:

1. Retrieve your source code.

2. Compile the Java application.

3. Build a container image.

4. Push the image to Artifact Registry.

5. Make it available for deployment.

Cloud Build handles the build process. Artifact Registry stores the resulting image. GKE can then deploy and manage the containers created from it.

9. Why are containers useful for microservices?

Imagine a banking application with separate services:

• Payment service

• Authentication service

• Notification service

• Transaction service

Each service can be packaged in its own container, with its own dependencies and release process.

This means you can update the notification service without necessarily rebuilding or redeploying the payment service.

Containers do not automatically provide perfect isolation or scalability, but they make independent deployment much easier.