CNFs are becoming the dominant way to deploy traditional telecommunications functions. In Anatomy of a CNF - Part 1 and Part 2 of the series, we discussed the term CNF and the key subcomponent of a CNF, the container image. Anatomy of a CNF - Part 3 focuses on storing container images, but a CNF is more than a set of container images. Other supporting resources are needed.
One fundamental assumption is that all CNF deployments will be in a container-based cloud that Kubernetes manages. Kubernetes is a popular platform for managing containerized applications across multiple nodes and provides rich features and tools to orchestrate, scale, and monitor your workloads. Kubernetes also provides a set of resources for a CNF vendor to utilize and provide the functions of a CNF.
The smallest unit of deployment in Kubernetes is a pod. A pod is a group of one or more containers sharing the same network namespace and storage volumes. So when we discuss deploying a container within Kubernetes, we mean deploying a pod with one or more containers.
Two additional types of resources are deployments and StatefulSets, which describe containers to deploy and supporting information for deployment. A deployment defines the desired state of your application using a pod template and a replica count and creates new pods, updates existing ones, or deletes old ones based on the template and the current state. A StatefulSet defines the desired state of your application and creates new pods with unique names and persistent volumes, updates existing ones, or deletes old ones based on the template and the index.
A service is a way to expose your pods to other pods or external clients. A service defines a logical set of pods providing specific functionality and assigns them a stable IP address and DNS name. Services may also load balance traffic among the pods and provide discovery mechanisms.
A way to store configuration data for your pods is with a ConfigMap. A ConfigMap is a key-value map mounted as environment variables or files inside your containers. ConfigMaps allow you to decouple configuration from your pod images and update them without restarting your pods.
A way to store sensitive data for your pods is with a secret. A secret is like a ConfigMap but encrypted at rest and only accessible by authorized pods. Secrets mount as environment variables or files inside your containers or are used by other Kubernetes components, such as service accounts or ingress controllers.
A Custom Resource Definition (CRD) is a way to extend the Kubernetes API with your resources and consists of two parts. The first is the custom resource definition, which defines your custom resource's name, scope, schema, and validation. The second is the custom resource object, an instance of your custom resource containing the actual data.
You can use CRDs to store any relevant data for your application. For example, you might create a CRD for planets and store information about their names, sizes, orbits, etc.
Building on the CRD concept, a set of defined plug-ins enhances Kubernetes. Concerning networking, the Container Networking Interface (CNI) supports various network connections to a CNF.
One of the most popular CNIs is Multus. Multus allows you to attach multiple network interfaces to your pods. In addition, Multus enables you to use different CNI plug-ins for each interface, such as Antrea or Calico for pod-to-pod communication and SR-IOV for high-performance networking.
While these are some of the essential Kubernetes resources, others offer different functionalities and use cases, such as ingresses, cronjobs, horizontal pod autoscalers, etc.
Kubernetes allows us to create a large number of resources, as we have seen. The next challenge is how to provide a definition file of some form so that we can correctly deploy all of these resources for our CNF.
Part 5 of Anatomy of a CNF explores Helm and Helm Charts, a supporting technology of Kubernetes that provides a way to deploy the container images and all of these resources.
Chris Reece, Technologist, Award Solutions, Inc.
Chris Reece works with leading global service providers, transforming networks and empowering individuals in 5G, Virtualization/Containerization, and Machine Learning/Artificial Intelligence. Service providers rely on Chris to paint both the big picture and the business impact of technology and appreciate his enthusiasm for getting into deep, detailed discussions when needed. You may have seen Chris on Award Solutions' YouTube Channel. In addition, Chris is featured at leading telecom conferences worldwide, including MWC, and in publications like IEEE Spectrum and DZONE.
Chris holds a master's degree in Computer Science Telecommunications from the University of Missouri at Kansas City and a bachelor's degree in Computer Science and Mathematics from Cameron University. He also holds four patents in wireless technologies.