Chapter 1: Introduction

	cOS Stream 4.00.03 CNF Series Getting Started Guide	Next

	Note: This document is also available in other formats
A PDF version of this document along with all current and older documentation in PDF format can be found at https://my.clavister.com. It is also available as a single HTML page.

Note: This document is also available in other formats

A PDF version of this document along with all current and older documentation in PDF format can be found at https://my.clavister.com.

It is also available as a single HTML page.

What the container version of cOS Stream provides on a conceptual level is a high-performance containerized firewall that can be managed by the Kubernetes framework. In a typical scenario it leverages SR-IOV interfaces for increased throughput and to be able to handle large volumes of user data, while using the default cluster network for system management. cOS Stream can replace traditional firewalls, with the advantage of fitting in the Kubernetes echo system, and by using resource pools, the number of firewalls can be scaled up or down depending on cluster demands.

Though the firewall runs in a container it is different from a regular micro service in several ways. Some important aspects to note are:

The firewall is not automatically integrated into the traffic flow of the Kubernetes cluster. It is simply a firewall running in a container, so the customer/administrator is responsible for setting up additional network interfaces and routing the traffic that should be firewalled to or through the container, as well as configuring rules, routing etc. in the firewall. The following is assumed:
1. The default pod network is used to manage the firewall only, not to forward traffic.
2. The actual workload traffic is forwarded over the additional network interfaces attached to the pod.

Figure 1.1. Container Deployment Example

The firewall container is running in polled mode, so it will roughly use the same amount of CPU resources regardless of traffic workload. That is, processes inside the container are running at full speed all the time. Expect to observe high CPU load from the outside. To see the actual load, the firewall needs to be queried.
1. Due to this, it is expected that the firewall container is assigned dedicated CPU resources (for instance by using a static CPU manager policy in the cluster) and is running in the guaranteed QoS class.
Using a Deployment, StatefulSet etc. and scaling to multiple pods might not work as expected (or automatically).
The firewall is based on DPDK, so for high performance, NIC devices should be bound to a driver DPDK have native support for (such as, mlx5 or vfio-pci).
High Availability (HA) is achieved by deploying a firewall node pair, with the two firewall HA nodes on separate hardware nodes within the same Kubernetes cluster.

The firewall container does not support running across NUMA boundaries, the container should have all resources assigned from the same NUMA node, example:
```
--topology-manager-policy=single-numa-node
```

The software package contains both the container image needed to run the system, an example of the image name:

clavister-cos-stream-4.00.01.34-cnf-x64-generic.tar.gz

The package also contains an archive with some examples/templates of the files needed to deploy it into kubernetes, an example of the image name:

clavister-cos-stream-4.00.01.34-cnf-x64-generic-deploy.tar.gz