In [part 1 of this series on Kubernetes](https://konghq.com/blog/kubernetes-modernizing-microservices-architecture)part 1 of this series on Kubernetes, we discussed how companies like VMware offer the necessary tools to launch, monitor, create and destroy virtual machines. In this post, we review how - much like virtual machines - containers need to be created, monitored, destroyed and relaunched to account for the health of the physical or virtual machines on which they run.

As container adoption has exploded, the need for container orchestration, which automates these processes, has become manifest. Container orchestration allows developers to better track, schedule and operationalize containers at scale.

Modern applications are made up of many single-purpose services called microservices, each running in its container. These can be developed and scaled independently based on demand for each particular microservice.

Usually, the containers run in the cloud, are distributed in multiple data centers for resilience in the face of outages and sometimes on a mix of cloud and on-premises servers to optimize for cost and other factors. If DevOps want to run multiple application instances (containers) of numerous applications in more than one location, they need an impossible amount of DevOps manpower and automation. For microservices-based applications, automation tools are an absolute necessity.

## Microservices and Containerization

The complexity introduced by microservices and containerization requires DevOps to answer several questions, such as when to start the right containers, how to ensure the containers can talk to each other, what storage requirements each container has and how to ensure high availability across the entire infrastructure.

Container orchestrators let developers define the rules and requirements of each container while abstracting away the ongoing operations required to match containers with appropriate resources and keep them running and communicating with each other. Much like AWS simplifies EC2 instances management, container orchestrators launch containers and automate or abstract away infrastructure issues, such as what physical server will fulfill the containers' requirements.

Container orchestration tools allow DevOps to start new containers without worrying about what underlying virtual machine will handle the workload. For example, a container orchestration tool such as Kubernetes will do things like deciding if a virtual machine is underutilized and then decide to run a container on that virtual machine over another.

## Kubernetes: Modern Infrastructure for Modern Applications

Recent survey data from The New Stack suggests that container adoption is the most significant catalyst for orchestration adoption. Sixty percent of respondents who have deployed containers in production report that they also rely on [Kubernetes](https://konghq.com/blog/learning-center/what-is-kubernetes)Kubernetes in production. Another 19 percent of respondents with broad container deployments in production were in the initial stages of Kubernetes adoption.

So, what exactly is Kubernetes? Started by Google in 2014, Kubernetes is an open-source project that focuses on building a robust orchestration system for running thousands of containers in production. Kubernetes can automate many of the painful manual tasks and infrastructure complexity required to deploy, scale and manage containerized applications, which would otherwise fall on DevOps teams.

Not every container is the same. A container can be a stateless service like a web app or contain a stateful service like a node of a distributed database. Kubernetes allows DevOps to run individual, stateless containers efficiently and to account for the different requirements of more complex, containerized services, including storage, networking, or interdependencies between containers.

The key to the rise of Kubernetes is its ability to account for the needs of the containerized application as a complete system, not just as individual containers.

Kubernetes addresses common design challenges, including:

• - How to deploy and orchestrate applications that consist of many moving parts
• - How to design applications that can easily move from one cloud to another
• - How to evenly distribute load across different instances of a service
• - How to ensure that stateful applications retain access to required data and storage when they restart

Even with the rise of Kubernetes as the de facto container orchestration system, there are still some misconceptions about Kubernetes. Many misunderstand the relationship between Docker and Kubernetes.

Docker is a company that popularized containerization when it created a standard way of encoding containers (a Docker Image) and the tooling needed to run that container on a host (called Docker Engine).

Kubernetes is an open-source project under the Cloud Native Computing Foundation that orchestrates and manages containers at scale. It automates the container lifecycle, making use of Docker's container format and tooling to encode and run each container while adding functionality to abstract away the infrastructure concerns discussed above.

Another common misconception is that Kubernetes is a platform as a service (PaaS). Although many vendors host Kubernetes as part of a platform, Kubernetes can be deployed anywhere: a laptop, the public cloud or on-prem. This flexibility is part of why Kubernetes has seen so much success.

In the last part of this series, we go into more detail on [How Kubernetes Gets Work Done](https://konghq.com/blog/how-kubernetes-gets-work-done)How Kubernetes Gets Work Done.