A 10,000 foot view of Kubernetes Concepts and Architecture. This is a part of our 101 Series. For more, check out the Magalix Blog. If you are into the DevOps or the IT field in general, you surely heard the term . In this article, we explore Kubernetes from a 10,000 ft. We’ll also shed light on some of its most important use cases and best practices. Kubernetes To fully understand the technology, you need to be aware of containers orchestration tool, and how Kubernetes came into existence. The Kubernetes story starts with containers. To appreciate the merits of containers, let’s see how software deployment mechanisms evolved over time. why Docker Containers Changed How We Deploy Software In the old days, software deployment was hard, time-consuming, and error-prone. To install an application, you need to purchase a number of physical machines and pay for CPU and memory than you might actually need. A few years later, virtualization was dominant. This saved you some costs as one powerful bare-metal server can host multiple machines. Thus, CPU and memory could be shared. In modern days, machines can be split into even smaller parts than virtual servers: . Containers became so popular only a few years ago. So, what exactly is a Linux container? And where does fit? containers Docker A container provides a type of virtualization just like virtual machines. However, while a hypervisor provides a hardware isolation level, containers offer isolation level. To understand this difference, let’s return to our example. process Instead of creating a virtual machine for Apache and another for MySQL, you decide to use containers. Now, your stack looks like below illustration. A container is nothing but a set of processes on the operating system. A container works in complete isolation from other processes/containers through Linux kernel features, such as , , , and ,. cgroups chroot UnionFS namespaces This means you’ll only pay for one physical host, install one OS, and run as many containers as your hardware can handle. Reducing the number of operating systems that you need to run on the same host means less storage, memory and CPU wasted. In 2010, Docker was founded. Docker may refer to both the company and the product. Docker made it very easy for users and companies to utilize containers for software deployment. An important thing to note, though, is that Docker is not the only tool in the market that does this. Other applications exist like , , among others. Docker is just the most popular one. rkt Apache Mesos LXC Containers And Microservices: The Need For An Orchestrator The ability to run complete services in the form of processes (a.k.a containers) on the same OS was revolutionary. It brought a lot of possibilities of its own: Because containers are way cheaper and faster than virtual machines, large applications could now be broken down into small, interdependent components, each running in its own container. This architecture became known as . microservices With the microservices architecture becoming more dominant, applications had more freedom to get larger and richer. Previously, a monolithic application grew till a certain limit where it became cumbersome, harder to debug, and very difficult to be re-deployed. However, with the advent of containers, all what you need to do to add more features to an application is to build more containers/services. With IaC ( ), deployment is as easy as running a command against a configuration file. Infrastructure as Code Today, it is no longer acceptable to have downtime. The user simply does not care if your application is experiencing a network outage or your cluster nodes crashed. If your system is not running, the user will simply switch to your competitor. Containers are processes, and processes are ephemeral by nature. What happens if a container crashes? To achieve high availability, you create more than one container for each component. For example, two containers for Apache, each hosting a web server. But, which one of them will respond to client requests? When you need to update your application, you want to make use of having multiple containers for each service. You will deploy the new code on a portion of the containers, recreate them, then do the same on the rest. But, it’s very hard to do this manually. Not to mention, it’s error-prone. Container provisioning. Maintaining the state (and number) of running containers. Distribute application load evenly on the hardware nodes by moving containers from one node to the other. Load balancing among containers that host the same service. Handling container persistent storage. Ensuring that the application is always available even when rolling out updates. All the above encourages IT professionals to do one thing: create as many containers as possible. However, this also has its drawbacks: For example, let’s say you have a microservices application that has multiple services running Apache, Ruby, Python, and NodeJS. You use containers to make the best use of the hardware at hand. However, with so many containers dispersed on your nodes without being managed, your infrastructure may look as shown in below illustration. You need a container orchestrator! Enter Kubernetes is a container orchestration tool. Orchestration is another word for lifecycle management. A container orchestrator does many tasks, including: Kubernetes Like Docker not being the only container platform out there, Kubernetes is not the sole orchestration tool in the market. There are other tools like , , , and others. So, what makes Kubernetes the most used one? Docker Swarm Apache Mesos Marathon Why Is Kubernetes So Popular? Kubernetes was originally developed by the software and search giant, Google. It was a branch of their project. Since its inception, Kubernetes received a lot of momentum from the open source community. It is the main project of the . Some of the biggest market players are backing it: , , , , and to name a few. Borg Cloud Native Computing Foundation Google AWS Azure IBM Cisco Kubernetes Architecture And Environment Kubernetes is a Greek word that or captain. It is the governor of your cluster, the maestro of the orchestra. To be able to do this critical job, Kubernetes was designed in a highly modular manner. Each part of the technology provides the necessary foundation for the services that depend on it. The illustration below represents a high overview of how the application works. Each module is contained inside a larger one that relies on it to function. Let’s dig deeper into each one of these. stands for helmsman Let’s now have an overview of the landscape of Kubernetes as a system. Kubernetes Core Features Also referred to as the control plane, it is the most basic part of the whole system. It offers a number of APIs that enable the cluster to do its most basic operations. The other part of the core is . Execution involves a number of controllers like , , ...etc. It also includes the , which is the module responsible for communicating with the container runtime. RESTful execution replication controller replicaset deployments kubelet The core is also responsible for contacting other layers (through kubelet) to fully manage containers. Let’s have a brief look at each of them: Container runtime Kubernetes uses to transparently manage your containers without necessarily having to know (or deal with) the runtime used. When we discussed containers, we mentioned that Docker, despite its popularity, is not the only container management system available. Kubernetes uses (pronounced ) by default as a container runtime. This is how you are able to issue standard Docker commands against Kubernetes containers. It also uses as an alternative runtime. Don’t be too confused at this part. This is the very inner workings of Kubernetes that, although you need to understand, you won’t have to deal with almost entirely. Kubernetes abstracts this layer through its rich set of APIs. Container Runtime Interface (CRI) containerd container d rkt The Network Plugin As we discussed earlier, a container orchestration system is responsible (among other things) for managing the network through which containers and services communicate. Kubernetes uses a library called as an interface between the cluster and various network providers. There are a number of network providers that can be used in Kubernetes. This number is constantly changing. To name a few: Container Network Interface (CNI) Weave net Contiv Flannel Calico The list is too long to mention here. You might be asking: why does Kubernetes need more than one networking provider to choose from? Kubernetes was designed mainly to be deployed in diverse environments. A Kubernetes node can be anything from a bare metal physical server, a virtual machine, or a cloud instance. With such diversity, you have a endless number of options for how your containers will communicate with each other. This requires more than one to choose among. That is why Kubernetes designers chose to abstract the network provider layer behind CNI. virtually The Volume Plugin A volume broadly refers to the storage that will be availed for the . A pod is one or more containers managed by Kubernetes as one unit. Because Kubernetes was designed to be deployed in multiple environments, there is a level of abstraction between the cluster and the underlying storage. Kubernetes also uses the CSI ( ) to interact with various storage plugins that are already available. pod Container Storage Interface Image Registry Kubernetes must contact an image registry (whether public or private) to be able to pull images and spin out containers. Cloud Provider Kubernetes can be deployed on almost any platform you may think of. However, the majority of users resort to cloud providers like AWS, Azure, or GCP to save even more costs. Kubernetes depends on the cloud provider APIs to perform scalability and resources provisioning tasks, such as provisioning load balancers, accessing cloud storage, utilizing the inter-node network and so on. Identity Provider If you’re provisioning a Kubernetes cluster in a small company with a small number of users, authentication won’t be a big issue. You can create an account for each user and that’s it. But, if you’re working in a large enterprise, with hundreds or even thousands of developers, operators, testers, security professionals...etc. then having to manually create an account for each person may quickly turn into a nightmare. Kubernetes designers had that in mind when working on the authentication mechanism. You can use your own identity provider system to authenticate your users to the cluster as long as it uses . OpenID connect Kubernetes Controllers Layer This is also referred to as the service fabric layer. It is responsible for some higher level functions of the cluster: routing, self-healing, load balancing, service discovery, and basic deployment(for more info, , and ), among other things. https://kubernetes.io/docs/concepts/services-networking/ https://kubernetes.io/docs/concepts/workloads/controllers/deployment/ Management Layer This is where policy enforcement options are applied. In this layer, functions like metrics collection, and autoscaling are performed. It also controls authorization, and quotas among different resources like the network and storage. You can learn more about resource quotas . here The Interface Layer In this layer, we have the client-facing tools that are used to interact with the cluster. is the most popular client-side program out there. Behind the scenes, it issues RESTful API requests to Kubernetes and displays the response either in JSON or YAML depending on the options provided. can be easily integrated with other higher level tools to facilitate cluster management. kubectl kubectl In the same area, we have , which can be thought of as an application package manager running on top of Kubernetes. Using , you can build a full application on Kubernetes by just defining its properties in a configuration file. helm helm-charts The DevOps and Infrastructure Environment Kubernetes is one of the busiest open-source projects out there. It has a large, vibrant community and it’s constantly changing to adapt to new requirements and challenges. Kubernetes provides a tremendous number of features. Although it is only a few years old, it is able to support almost all types of environments. Kubernetes is used in many modern software building/deployment practices including: provisioning ephemeral environments for testing and QA is easier and faster. DevOps : building continuous integration/deployment, and even delivery pipelines is more seamless using Kubernetes-managed containers. You can easily integrate tools like , , with the Kubernetes cluster to build/test/deploy your applications and other cloud components. CI/CD : Jenkins TravisCI Drone CI chat applications like can easily be integrated with the rich API set provided by Kubernetes to monitor and even manage the cluster. ChatOps : Slack Cloud-managed Kubernetes: Most cloud providers offer products that already has Kubernetes installed. For example , , and . AWS EKS Google GKE Azure AKS : Everything in Kubernetes is managed through code (YAML files). Using version control systems like , you can easily manage your cluster through pull requests. You don’t even have to use . GitOps Git kubectl TL;DR In this article, we had a 10,000 ft. overview of Kubernetes. We briefly covered the concept of containers, , and the difference between a container and a virtual machine. Finally, we discussed Kubernetes as a tool, why it came into existence and how it works at a very basic level. I intentionally avoided any Kubernetes-specific lingo as much as possible so that you focus on the core concepts. In future articles, we’ll delve deeper into the ideas that we touched here, and explain how they work under the hood. Kubernetes is a very large topic and you can easily get lost getting deeper into one of its components. If that happened, you can always return to this article to have the full picture before you. why everybody is using it Learn how to continuously optimize your k8s cluster with Magalix KubeAdvisor

Apache

Cisco

Discovery

Google

Slack

Helping you get K8s in prod faster

Read My Stories

Too Long; Didn't Read

In your car, at home, or at work — Bosch technology shapes many areas of life.

Kubernetes 101- Concepts, Potential, and lots of Container Orchestrations

Too Long; Didn't Read

Companies Mentioned

Magalix

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

Kubernetes 101- Concepts, Potential, and lots of Container Orchestrations

Too Long; Didn't Read

Companies Mentioned

Magalix

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES