FeatureRequest: Kubernetes manifest

[greenbone]

FeatureRequest: Kubernetes manifest

[bjoernricks]

Yes we are interested in a kubernetes deployment for our software stack. Therefore feel free to create a PR but currently I can't promise that it gets merged at the end because I don't know how much maintenance burden it will create. Just let us start and we will see what the future will bring us. You can ask question in this issue and I'll try to answer them.

[rdxmb]

Ok, sounds great!
Just to get the context: In kubernetes there is no depends_on like it is in docker-compose. I will try to do this with initContainers, as this is very common in kubernetes manifests.

First, I have to understand how the services in the docker-compose connect each other.

I assume that this is done via the service-names and the docker-dns. So the hostnames that will be connected are hardcoded in the images.

Example:

The image: greenbone/ospd-openvas connects redis via its hostname redis-server and the default redis-port. Here it is quite obviously.

However, I do not know about all the other stuff.

So first we have to define all the ports the services want to connect to each other. You could do that by listing the ports to the services? For example like this:

services:
  vulnerability-tests:6136    # this is just an example
  notus-data:    #  no network connection needed from the other containers

Could you support here? With this I will try to build the next step. That would be great. Thanks and kind regards!

[bjoernricks]

Not sure if you have found https://greenbone.github.io/docs/latest/22.4/container/index.html#description already. I've tried to describe the container images and their purpose.

The data containers like vulnerability-tests and notus-data are just storage containers that are run to update data in a volume. During their startup they copy data into some path that is mounted as a volume. After the copying they just exit and are shut down. The data of the volume is mounted in other containers (gvmd, ospd-openvas, notus-scanner) for consumption.

[rdxmb]

Not sure if you have found https://greenbone.github.io/docs/latest/22.4/container/index.html#description already. I've tried to describe the container images and their purpose.

Oh, this link is great, thanks! Actually, I haven't seen that yet.

As a workaround I have tried https://github.com/immauss/openvas , which runs all the stuff in one image. So as this is working quite well, I am wondering if the manifest with multiple containers is such a great idea - for we need many data volumes (and also sockets) with read-write-access from multiple containers.

This means we would have to
a) use ReadWriteMany-volumes, which means kind of NFS or something, which is also not useful for databases - or
b) put all containers in one pod. As this also is a kind of workaround, I do not really see an advantage over the all-in-one image linked above.

crosslink: https://forum.greenbone.net/t/re-kubernetes-manifest/13782

[bjoernricks]

Hi, sorry for the late response. Of course putting all the stuff into one container is easier because of the extensive usage of unix domain sockets. But that also means we don't need kubernetes at all. It just contradict the idea of separating services in distinct reusable containers. Therefore I wouldn't go the b) route.

[rdxmb]

But that also means we don't need kubernetes at all.

For me it is not if I need it or not. My complete infrastructure is in kubernetes, so my personal use-case was to get greenbone running within that infrastructure.
For my use case, the all-in-one-container works quite great (in kubernetes). So I am not going to work on a kubernetes-manifest for this project anymore. *)

It just contradict the idea of separating services in distinct reusable containers. Therefore I wouldn't go the b) route.

Correct.

But, to be honest, those ReadWriteMany-Volumes also do that, because not every kubernetes-provider do have them.
So I think I haven't seen a software-project with even one ReadeWriteMany-Volume needed. It's just not very typical in the kubernets-world - for usually there are Block-Devices mounted.

To get those data in a container, usually initContainers are used. They run before the "real" process in the container is started.

*) If someone else wants to work on this feature, I see this (not quite simple) roadmap:

• connect all the containers via tcp-network and not via sockets
• break up the volume-dependencies between those containers (I am not sure if initContainers would do that the way this project works)
• possibly rewrite greenbone/ospd-openvas:stable-Image, because there is no init-command in a kubernetes-manifest like it is in the docker-compose.yml

Please feel free to close this featureRequest or leave it open.

[brekke-roq]

@rdxmb We do also follow k8s first deployment rule so lack of k8s deployment is a bit problematic for us too. There is one thing that you can consider helpful:

https://github.com/admirito/gvm-containers

My initial idea was to use official community images together with this helmchart (in order to avoid overhead) but this images are not kubernetes friendly yet.

[y0urself]

I know that @pascalholthaus run our community images successfully in k8s ... Pascal, can you give some insights?

[durabledata]

I've added example k8s manifests here: https://github.com/durabledata/greenbone-community-k8s