|
| 1 | +[id="cnf-best-practices-developer-guide"] |
| 2 | += CNF Developer Guide |
| 3 | + |
| 4 | +This section discusses recommendations and requirements for CNF application builders. |
| 5 | + |
| 6 | +== Preface |
| 7 | + |
| 8 | +Cloud-native Network Functions (CNFs) are containerized instances of classic physical or virtual network functions (VNF) which have been decomposed into microservices supporting elasticity, lifecycle management, security, logging, and other capabilities in a Cloud-Native format. |
| 9 | + |
| 10 | +== Goal |
| 11 | + |
| 12 | +This document is mainly for the developers of CNFs, who need to build high-performance Network Functions in a containerized environment. We have created a guide that any partner can take and follow when developing their CNFs so that they can be deployed on the OpenShift Container Platform (OCP) in a secure, efficient and supportable way. |
| 13 | + |
| 14 | +== Non-Goal |
| 15 | + |
| 16 | +This is not a guide on how to build CNF’s functionality. |
| 17 | + |
| 18 | +=== Refactoring |
| 19 | + |
| 20 | +NFs should break their software down into the smallest set of microservices as possible. Running monolithic applications inside of a container is not the operating model to be in. |
| 21 | + |
| 22 | +It is hard to move a 1000LB boulder. However, it is easy when that boulder is broken down into many pieces (pebbles). All containerized network functions (CNFs) should break apart each piece of the functions/services/processes into separate containers. These containers will still be within kubernetes pods and all of the functions that perform a single task should be within the same namespace. |
| 23 | + |
| 24 | +There is a quote that describes this best from link:Lewis and Fowler:# "the microservice architectural []style is an approach to developing a single application as a suite of small services, eachrunning in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. " |
| 25 | + |
| 26 | +=== CNF Security |
| 27 | + |
| 28 | +In OCP, it is possible to run privileged containers that have all of the root capabilities on a host machine, allowing the ability to access resources which are not accessible in ordinary containers. This, however, increases the security risk to the whole cluster. Containers should only request those privileges they need to run their legitimate functions. No containers will be allowed to run with full privileges without an exception. |
| 29 | + |
| 30 | +The general guidelines are: |
| 31 | + |
| 32 | +. Only ask for the necessary privileges and access control settings for your application. 2. If the function required by your CNF can be fulfilled by OCP components, your application should not be requesting escalated privilege to perform this function. |
| 33 | + |
| 34 | +. Avoid using any host system resource if possible. |
| 35 | + |
| 36 | +. Leveraging read only root filesystem when possible. |
| 37 | + |
| 38 | +.CNF Requirement |
| 39 | +[IMPORTANT] |
| 40 | +==== |
| 41 | +Only ask for the necessary privileges and access control settings for your application |
| 42 | +==== |
| 43 | + |
| 44 | +.CNF Requirement |
| 45 | +[IMPORTANT] |
| 46 | +==== |
| 47 | +If the function required by your CNF can be fulfilled by OCP components, your application should not be |
| 48 | +requesting escalated privilege to perform this function. |
| 49 | +==== |
| 50 | + |
| 51 | +.CNF Requirement |
| 52 | +[IMPORTANT] |
| 53 | +==== |
| 54 | +*Avoid* using any host system resource |
| 55 | +==== |
| 56 | + |
| 57 | +.CNF Requirement |
| 58 | +[IMPORTANT] |
| 59 | +==== |
| 60 | +*Do not* mount host directories for device access |
| 61 | +==== |
| 62 | + |
| 63 | +.CNF Requirement |
| 64 | +[IMPORTANT] |
| 65 | +==== |
| 66 | +*Do not* use host network namespace |
| 67 | +==== |
| 68 | + |
| 69 | +.CNF Requirement |
| 70 | +[IMPORTANT] |
| 71 | +==== |
| 72 | +CNFs may *not* modify the platform in any way |
| 73 | +==== |
| 74 | + |
| 75 | +==== Avoid Accessing Resource on Host |
| 76 | + |
| 77 | +It is not recommended for an application to access following resources on the host. |
| 78 | + |
| 79 | +==== Avoid Mounting host directories as volumes |
| 80 | + |
| 81 | +It is not necessary to mount host /sys/ or host /dev/ directory as a volume in a pod in order to use a network device such as SR-IOV VF. The moving of a network interface into the pod network namespace is done automatically by CNI. Mounting the whole /sys/ or /dev/ directory in the container will overwrite the network device descriptor inside the container which causes 'device not found' or 'no such file or directory' error. |
| 82 | + |
| 83 | +Network interface statistics can be queried inside the container using the same /sys/ path as was done when running directly on the host. When running network interfaces in containers, relevant /sys/ statistics interfaces are available inside the container, such as '/sys/class/net/net1/statistics/', '/proc/net/tcp' and '/proc/net/tcp6'. |
| 84 | + |
| 85 | +For running DPDK applications with SR-IOV VF, device specs (in case of vfio-pci) are automatically attached to the container via the Device Plugin. There is no need to mount the /dev/ directory as a volume in the container as the application can find device specs under '/dev/vfio/' in the container. |
| 86 | + |
| 87 | +==== Avoid the host network namespace |
| 88 | + |
| 89 | +Application pods must avoid using hostNetwork. Applications may not use the host network, including nodePort for network communication. Any networking needs beyond the functions provided by the pod network and ingress/egress proxy must be serviced via a MULTUS connected interface. |
| 90 | + |
| 91 | +.CNF Requirement |
| 92 | +[IMPORTANT] |
| 93 | +==== |
| 94 | +Applications may *not* use NodePorts or the hostNetwork |
| 95 | +==== |
| 96 | + |
0 commit comments