Kubernetes is neither an NFVI (NFV Infrastructure) nor a VIM (Virtualized Infrastructure Manager). It is an orchestrator. Moreover, it’s an extensible orchestrator.
It can be extended via plugins, such as CNI, or via custom controllers, which in Kubernetes are called “operators”.
When developing CNFs (Cloud Native Network Functions) we can deliberately choose not to extend Kubernetes and instead use only its built-in controllers and their associated resources: Deployments, DaemonSets, Services, PersistentVolumeClaims, ConfigMaps, Secrets, etc.
It is entirely possible to follow cloud native principles without deep integration into the platform itself. However, doing so leaves many of the advantages of Kubernetes on the table and can increase complexity by forcing us to add non-native layers of orchestration.
In this guide, we’ll focus on custom controllers (“operators”) and how they can and why to implement the operator design pattern for Telco Workloads.