Azure Kubernetes Service is an Kubernetes service provided by Microsoft Azure that simplifies the deployment, management and scaling of containerize applications. AKS takes care of the underlying infrastructure while you focus on your application. This post is the first in a series about Azure Kubernetes Service. The objective of the first post is to cover the basic terminology, and architecture.
What is Kubernetes (a.k.a. K8s)? Kubernetes, originally developed by Google, is an open source platform used to manage containerized applications and distributed systems via clusters. A Kubernetes cluster is a set of nodes (VMs) that consist of two components. A Control Plane is used to manage the cluster and the nodes or worker machines themselves.
AKS Architecture includes several key components that work together to manage, orchestrate, and secure containerized applications. With AKS, the control plane is fully managed by Azure, simplifying the Kubernetes experience while allowing you to focus on your workloads.
An AKS Cluster is what we build in Azure to support containerized applications and services. A Cluster consists of two essential components:
- The "control plane" is responsible for all the core services and orchestration.
- The "Nodes" are what actually run your application.
AKS Clusters can contain 1 or more nodes. Multiple nodes offer more reliability and can be scaled horizontally to support your application. A single node is fully capable of supporting development and test environments. AKS nodes can support both Windows and Linux operating systems. Linux is the default. Windows nodes are usually housed in Node pools where a all nodes in the pool must support the same OS.
AKS clusters must be deployed into a network. We have the option to deploying AKS clusters into an existing subnet or letting AKS create it's own virtual network. This decision is primarily based on how much control of the network is required.
We can stipulate whether the AKS load balancer is "public" allowing for internet traffic accessibility into the network or "private" allowing for only internal network traffic.
We must also define the network model and have 2 options for doing so...
Kubenet and
Azure CNI. This decision is also about your requirement control. Kubenet is much simpler and all the nodes used IP addresses internally and managed by AKS. Azure CNI requires that the node IP Addresses be taken from the network subnet range. There is some upfront planning required here. You can learn more information about networking in AKS
here......An
AKS Pod is the smallest deployable unit in Kubernetes and represents single instance of a running process in the AKS cluster. A Pod consists of one or more containers that share resources such as networking and storage. Pods provide a level of abstraction over containers. Although Pods can consist of multiple containers, it is more common practice to have single container Pods. We will see more about Pods in future posts in this series.
Keep watch for our next post in the series where we will create an AKS cluster and deploy a containerized application.
See Part 2 - Creating an AKS Cluster
FutureSystems
