Kubernetes

Enterprises and telecom operators are focusing on achieving a great amount of flexibility, observability, and dynamic orchestration by deploying and testing Kubernetes at the edge.

Running Kubernetes on bare metal infrastructure is complex, requiring specialized expertise and significant customer investment in time and the tools needed to automate Kubernetes cluster lifecycle management.

This week’s blog is a joint post by Nati Shalom, CTO Cloudify and yours truly. We discuss the need for multiple K8s clusters along with Network orchestration.

I would like to round-out 2021 with a final post on a reference architecture that I have been driving towards all year. This post brings together several themes we have covered since 2019 – on the suitability of Kubernetes as a foundation for Telco 5G workloads. 

While the concept is straightforward, Horizontal pod autoscaling requires time and effort to implement. More often than not, applications need to undergo load testing to tune HPA configuration to determine the best scaling and capacity management settings.

While the concept is straightforward, Horizontal pod autoscaling requires time and effort to implement. More often than not, applications need to undergo load testing to tune HPA configuration to determine the best scaling and capacity management settings.

Cluster autoscaling is typically the easiest autoscaler to configure and to use. However there may be situations where it may not be the best option for an application.

This post discusses how to overcome the first limitation of K8s from a 5G standpoint – enabling pods to assume multiple network interfaces. 

This blog discussed the line of separation from a security standpoint when deploying your application to the cloud. The next post in this series will focus on the fundamental aspects of Kubernetes security.