Core Concepts
Kubernetes Cluster Architecture
A Kubernetes cluster architecture consists of a Control Plane and Worker Nodes, working together to manage and run containerized applications. Understanding this core structure is fundamental for managing a Kubernetes cluster.
Control Plane
The control plane is the brain of the Kubernetes cluster, responsible for managing cluster-wide functions. It includes:
-
API Server: The main management component of Kubernetes. It exposes the Kubernetes API, through which all communication happens (whether through kubectl, the dashboard, or third-party tools). Users and components interact with the cluster through this API.
-
Scheduler: Decides which worker node will run a new pod, based on resource availability and other requirements.
-
Controller Manager: Handles routine tasks in the cluster, like responding to failures, replicating pods, or managing node operations.
-
etcd: A distributed key-value store that holds the cluster’s configuration data and the state of the cluster. It serves as the backend store for all cluster data.
Worker Nodes
Worker nodes host and run your applications. They handle the execution and management of containers, ensuring that workloads are properly distributed across the cluster. The key components on each worker node include:
-
Kubelet: A small agent on each node that communicates with the control plane and ensures the containers specified in the pod definitions are running properly.
-
Kube-Proxy: Manages networking for the node, facilitating communication between pods and services.
-
Container Runtime: The software responsible for running containers on the node (e.g., Docker, containerd).
Worker node flavours are broadly categorized into CPU-based nodes and GPU-based nodes (options available while creating a cluster or scaling node pools).
CPU-Based Worker Nodes
CPU-based worker nodes are suitable for general application workloads that do not require GPU acceleration. These nodes are available in the following flavours:
- Compute Optimized: Designed for CPU-intensive workloads such as high-performance application servers, batch processing, and stateless services (e.g., B8 – 8 vCPU, 16 GB vRAM).
- General Purpose: Suitable for balanced workloads including backend microservices, APIs, and web applications. (e.g., D8 – 8 vCPU, 32 GB vRAM).
- Memory Optimized: Ideal for memory-heavy workloads such as in-memory databases, caching layers, and data processing applications (e.g., H8 – 8 vCPU, 64 GB vRAM).
GPU-Based Worker Nodes
GPU-based worker nodes provide hardware acceleration for compute-intensive workloads such as AI/ML training, inference, high-performance computing (HPC), and large-scale data processing. VKS supports Virtualized GPUs and Bare Metal GPUs.
- Virtualized GPU Worker Nodes: Offer GPU acceleration in a shared, virtualized environment, enabling efficient resource utilization and flexible scaling suitable for AI/ML inference, development, and moderate training workloads.
- Bare Metal GPU Worker Nodes: Provide exclusive, dedicated access to physical GPU hardware, delivering maximum performance with no virtualization overhead.
Vayu Kubernetes Service enables users to scale their clusters horizontally by increasing the number of worker nodes or vertically by choosing higher capacity flavours, ensuring flexibility and performance as application demands grow.
You can choose the operating system and its version for all worker nodes when creating the cluster, with support for popular distributions like Ubuntu, Red Hat, and Windows. VKS ensures compatibility and version alignment with the Kubernetes control plane, allowing users to select from a list of supported OS versions.
Namespaces
Namespaces provide a mechanism for separating resources within a Kubernetes cluster. This allows for better resource management, isolation between teams, and avoiding naming conflicts. It also makes it easier to allocate resources based on teams or departments, especially in a multi-tenant environment.
CNI Drivers
CNI (Container Network Interface) drivers are responsible for managing network connectivity between pods in a Kubernetes cluster. They define how pods communicate with each other, with services, and with external networks. In Vayu Kubernetes Service (VKS), users can choose between two supported CNI drivers - Calico and Cilium, during cluster creation.
- Calico offers traditional IP-based networking with strong network policy support, making it suitable for standard workloads that require reliable routing and isolation.
- Cilium, on the other hand, leverages eBPF technology to deliver enhanced visibility, security, and scalability for modern, cloud-native environments.
Selecting the appropriate CNI driver helps ensure optimal performance, security, and traffic control based on application needs.
Kubernetes Objects
Kubernetes objects are the persistent entities in the Kubernetes system. They represent the desired state of your cluster, such as which containerized applications are running, their available resources, and the policies applied to them. These objects are the building blocks of Kubernetes clusters, and users need to interact with them to manage workloads effectively.
Pods
Pods are the smallest deployable units in Kubernetes, consisting of one or more containers. These containers share the same network and storage resources and are treated as a single application. Pods are often used for scaling and workload management.
Deployments
A Deployment defines the desired state of your application in terms of the number of replicas of Pods and ensures that the specified number is running. It supports rolling updates, which allows for zero-downtime updates to applications.
ReplicaSet
ReplicaSet ensures that a specified number of pod replicas are running at all times. It is often used by Deployments to maintain the correct number of replicas.
Services
A Service is an abstraction that defines a logical set of Pods and a policy to access them. Services provide load balancing, IP stability, and DNS capabilities to pods.
ConfigMaps
A ConfigMap is used to store configuration data in key-value pairs. It decouples environment-specific configurations from container images, making it easier to manage changes in application behavior.
Secrets
Secrets are used to store sensitive data, such as passwords, OAuth tokens, and SSH keys. They ensure that confidential data is stored securely and is not exposed in plaintext inside Pods.
Volumes
A Volume in Kubernetes is a storage abstraction that allows data to persist across pod restarts. It can be used for temporary or permanent data storage needs.
PersistentVolume (PV) and PersistentVolumeClaim (PVC)
PersistentVolume (PV) represents a piece of storage in the cluster, while a PersistentVolumeClaim (PVC) is a request for storage by a user. When configuring a PersistentVolumeClaim (PVC), users can define two key storage parameters:
-
IOPS (Input/Output Operations Per Second): Determines the read/write speed of the storage volume. Higher IOPS levels (e.g., IOPS-5) offer better performance for workloads with high disk throughput needs. Users can select from predefined IOPS tiers to match their workload performance requirements.
-
Capacity: Specifies the total size of the volume in GB. Users can define capacity as per their application’s storage requirements, These settings enable fine-tuned, dynamic provisioning of storage to optimize both cost and performance.
Ingress
Ingress is an API object that manages external access to services within the cluster, typically HTTP or HTTPS. It provides routing rules and can also handle TLS termination.
Backup and Restore
The Backup Manager allows users to automate and manage backups across Kubernetes namespaces with flexible scheduling. The Restore Manager enables recovery of backed-up data to any target cluster, with options for one-time or continuous restores. You can refer to Backup and Restore section for more information.
Tags
Users can assign custom tags to a cluster using predefined categories and key-value pairs, enabling two-level classification for better organization and management.