5 Kubernetes Concepts You Must Know: HPA, API Gateway, OpenTelemetry, and More

Kubernetes is an open source platform for automating the deployment, scaling and management of containerized applications. It was originally designed by Google and is now maintained by the Cloud Native Computing Foundation. 

Kubernetes provides a way to run distributed applications in a cluster environment, allowing you to scale your applications up or down and manage their life cycle in a more automated and efficient way. It is often used in conjunction with Docker, an open-source containerization platform, to help deploy and manage applications in a microservices architecture.

5 Advanced Kubernetes Concepts You Must Know

HorizontalPodAutoscaler (HPA)

The Horizontal Pod Autoscaler (HPA) is a Kubernetes feature that automatically scales the number of pods in a deployment based on observed CPU utilization or other metrics. This allows you to ensure that your application has the resources it needs to handle the incoming traffic without having to manually adjust the number of pods. 

HPA can use either custom metrics or built-in metrics like CPU utilization to determine when to scale the number of pods. It can be configured to scale the number of pods up or down, and it can also be used in conjunction with other Kubernetes features like replica sets and deployment controllers.

If the average CPU utilization is below the target, the HPA will not perform any scaling. However, if the average CPU utilization is above the target, the HPA will scale the number of pods up or down to try to bring the average back to the target value.

API Gateway

In Kubernetes, an API gateway is a service that acts as an entry point for external clients to access the services in a Kubernetes cluster. The API gateway handles the authentication and routing of incoming requests to the appropriate service, as well as other tasks such as request validation and rate limiting. This allows clients to access the services in the cluster without having to know the details of how the services are deployed or how to reach them directly.

API gateways are typically used in situations where a Kubernetes cluster contains multiple services that need to be accessed by external clients. This can include situations where the services are part of a microservices architecture, where each service has a specific role and is accessed by other services or by clients directly. In such cases, an API gateway can help to provide a single, consistent entry point for accessing the services in the cluster.

An API gateway can be implemented using a variety of tools and technologies, depending on the specific requirements of the Kubernetes cluster and the services it contains. Some common options for implementing an API gateway in Kubernetes include using a Kubernetes ingress controller, a service mesh like Istio, or the new Kubernetes Gateway API.

What is the Kubernetes Gateway API?

Gateway API is the standard API gateway for Kubernetes, currently available as a beta version. The SIG-NETWORK open source community maintains this project.

The Kubernetes API gateway encompasses several resources that produce a model of the service network in Kubernetes. They provide scalable, expressive, role-based interfaces that enjoy broad support and can be implemented by many vendors. These include GatewayClass, HTTPRoute, Gateway, Service, and TCPRoute.

Kubernetes RBAC

RBAC, or Role-Based Access Control, is a method for managing access to resources. In Kubernetes, RBAC is used to control who is allowed to perform certain actions on certain resources within the cluster.

RBAC uses Roles and RoleBindings to define and enforce the access controls in a Kubernetes cluster. A Role is a set of permissions that define what actions a user or group of users can perform on a given resource. A RoleBinding is a mapping between a role and a user or group of users. It specifies which role is granted to which users or groups, and in what namespace the role is effective.

For example, you could create a Role that allows users to read and update the information about pods in a namespace, and then create a RoleBinding that grants that role to a specific user or group of users. This would allow those users to view and update the information about pods in that namespace, but not to perform any other actions on other resources in the cluster.

Persistent Storage in Kubernetes

Persistent storage refers to data storage that is not lost when a pod or other Kubernetes resource is deleted or terminated. This allows applications to store and access data even when the pods or other resources that are using the data are no longer available.

Kubernetes uses volumes to provide persistent storage for applications. A volume is a file system directory that is accessible to one or more pods, and that exists as a separate entity from the pods themselves. This allows the data in the volume to be accessed by the pods, even if the pods are deleted or restarted.

Kubernetes supports a variety of different storage types for volumes, including local storage, network-attached storage (NAS), and block storage. The specific storage type that is used for a volume depends on the requirements of the application and the underlying infrastructure of the Kubernetes cluster.

What are PVs and PVCs?

In Kubernetes, PersistentVolumes (PVs) and PersistentVolumeClaims (PVCs) are used to manage the lifecycle of persistent storage in a cluster. A PV is a resource that represents a piece of storage that is available in the cluster. It contains details about the specific storage volume, such as the type of storage, the capacity, and the access modes. A PV is created and managed by an administrator, and it is independent of any specific pod or application.

A PVC is a request for storage by a user. It specifies the desired characteristics of the storage, such as the capacity and access modes, and it is associated with a specific namespace. When a PVC is created, Kubernetes will try to find a PV that matches the requested characteristics, and it will bind the PVC to the PV. 

This creates a relationship between the PVC and the PV, and it allows the PVC to be used as a volume by one or more pods. The PVC acts as an abstraction layer between the application and the underlying storage, allowing the application to access the storage without having to know the details of the PV.


OpenTelemetry is an open source project that provides a set of tools and APIs for collecting, storing, and processing telemetry data from applications and services. Telemetry data includes information about the performance and behavior of an application, such as metrics, logs, and traces.

OpenTelemetry provides a vendor-neutral API that allows developers to instrument their applications with telemetry data, and a set of libraries and components that can be used to collect, process, and export that data to a variety of different back-end systems. 

The OpenTelemetry Operator for Kubernetes is a tool that allows you to automate the process of deploying and managing the OpenTelemetry components, including the collectors, exporters, and agents that are used to collect and process telemetry data from applications running in the cluster.


In conclusion, Kubernetes is a powerful and popular platform for deploying and managing containerized applications. In order to effectively use Kubernetes, it is important to understand some key concepts, such as the Horizontal Pod Autoscaler (HPA), the API gateway, and OpenTelemetry. 

These features and tools provide powerful capabilities for scaling and monitoring applications, and for managing access to services in a Kubernetes cluster. By understanding these concepts and how they work, you can better leverage the power of Kubernetes to deploy and manage your applications.


Gilad David Mayaan

Gilad David Maayan is a technology writer who has worked with over 150 technology companies including SAP, Samsung NEXT, NetApp and Imperva, producing technical and thought leadership content that elucidates technical solutions for developers and IT leadership.

Gilad David Mayaan has 53 posts and counting. See all posts by Gilad David Mayaan