openvnf / cgw Goto Github PK

Currently we are using a single bird container which depending on the env variables is running one or 2 daemons, then checking their liveness and if one of them died - the whole container is dying.

IMO we should instead use 2 separate containers (second one created "if needed", if ipv6 is enabled in the configuration) while the entry point for each of them should be directly bird (or bird6 in the second case), running in the foreground mode (possibly with some additional logs).

This would provide imo more k8s native way of whole thing handling (restarts) also having separately logs on consoles for both processes (e.g. right now we don't have any info why previous instance of daemon died and with which status code).

At present, in case of an update of the bird configuration, the CGW pod is re-created. However, it should be possible to change routing configuration at runtime without pod restart.

Kubernetes will update the config in the pod if the ConfigMap is updated. A mechanism is needed to trigger a re-configuration in case of config update: run a configure check and apply the config if valid. If the config is invalid, the pod should indicate that e.g. via health state - otherwise a situation may appear in which a invalid config is applied, as bird can not be re-configured, it will remain running in the old configuration until it is restarted - then it fails to come up. Hence, a invalid config should become quite visible when applied.

Starting with Kubernetes v1.16 Deployment, StatefulSet, and DaemonSet are no longer available in API version extensions/v1beta1, as they are available in apps/v1 since v1.9: https://kubernetes.io/blog/2019/07/18/api-deprecations-in-1-16/

The templates need to be updated to consider this and support k8s 1.16.

Add a watcher for iptables that reloads the config if changed without the need of a pod restart.

At present, the IPSec part of the CGW is mandatory -- opposed to the other functions, there is no ipsec.enabled. However, there are use cases where IPSec is not required, however, the remaining functionality of the CGW should still be utilized. For instance, to setup a GRE tunnel with BGP over a trusted network, I still want to utilize the CGW to have VXLAN controller, BGP metrics, Ping metrics export, etc.
So IPSec termination should become and optional part of the CGW.

Especially in scope of networking, it is often required to adjust some sysctl settings, e.g. to enable forwarding, disable reverse path filtering, changing socket buffer sizes. The CGW should allow to define respective sysctls and apply them to the SecurityContext in the PodSpec as documented.

The values file should consider settings like:

sysctls:
- name: net.ipv4.conf.all.forwarding
   value: "1" 
- name: net.ipv4.conf.all.rp_filter
   value: "2" 

Note: Calico overwrites the setting for net.ipv4.conf.all.forwarding and net.ipv6.conf.all.forwarding, so better use e.g. net.ipv4.conf.all.rp_filter if testing with Calico CNI.

No limits are set for pingExporter.

Warning  FailedCreate  2m               replicaset-controller  Error creating: pods "cgw-tgd-test-a-b97b59d78-kdw65" is forbidden: failed quota: compute-resources: must specify limits.cpu,limits.memory,requests.cpu,requests.memory
Warning  FailedCreate  9s (x7 over 2m)  replicaset-controller  (combined from similar events): Error creating: pods "cgw-tgd-test-a-b97b59d78-k4msp" is forbidden: failed quota: compute-resources: must specify limits.cpu,limits.memory,requests.cpu,requests.memory

The CGW should optionally be able to capture packets according to defined filters. For this purpose, the travelping/pcap docker image should be utilized.

Strongswan has a fake ARP (farp) plugin that sends ARP responses for requests addressing a host in the "rightsite" network. This often causes unforeseeable issues and should be disabled by default. So a fix for openvnf/vnf-ipsec#11 should be considered and the default in the values.yaml for CGW should be to disable farp.

Running helm install . --dry-run --debug yields:

Error: render error in "cgw/templates/strongswan-ipsec-privatekeys.yaml": template: cgw/templates/strongswan-ipsec-privatekeys.yaml:1:40: executing "cgw/templates/strongswan-ipsec-privatekeys.yaml" at <.Values.ipsec.certs....>: can't evaluate field privateKeys in type interface {}

Hence, obviously some default parameters are missing in the values.yaml