skydive icon indicating copy to clipboard operation
skydive copied to clipboard

does skydive support crio as a container runtime

Open raffaelespazzoli opened this issue 5 years ago • 10 comments

I'm trying to evaluate the possibility of using skydive with OCP 4.x and one thing that seems to be missing is the ability to have crio as the container runtime.

raffaelespazzoli avatar Mar 17 '20 13:03 raffaelespazzoli

It is supposed to work, please see this old thread: https://github.com/skydive-project/skydive/issues/1391

I didn't check this for a while, but I think it is still valid as we do have users using crio

safchain avatar Mar 17 '20 14:03 safchain

@safchain following some of the suggestions in that issue, I was able to enable the runc information gathering, but I don't see the crio-level or pod level aggregation. Not sure if that is a feature I should expect to see...

raffaelespazzoli avatar Mar 17 '20 17:03 raffaelespazzoli

I guess this should be reported by the k8s probe. did you activate it ?

safchain avatar Mar 17 '20 22:03 safchain

I disabled the docker probe, which is on the OCP template I enabled the k8s probe with all the subprobes (namespace cluster service pod node). I am not 100% sure what to expect, but it doesn't seem that pods are matched with containers. Also nodes don't have a relationship with the cluster. Is there a way for me to get some assistance on this? I'd be willing to invest some time in making this work in OCP out of the box.

raffaelespazzoli avatar Mar 18 '20 14:03 raffaelespazzoli

Can you share a screenshot of what you get ? It could help to understand. is there a way to reproduce the environment you are using ?

Reading the code you should have a link between the pod and the containers.

The best way to discuss about this is on Slack. There are some folks here that have written the k8s probes. https://github.com/skydive-project/skydive#get-involved

safchain avatar Mar 18 '20 15:03 safchain

here is the initial image: image

we can see the VMs comprising the cluster and the cluster itself. The VMs are not considered nodes.

Here is what I see when I explode one of the nodes: image

I can see containers and container netnamespaces, but they are not mapped to pods.

Here is what I see when I explode the cluster:

image

I can see namespaces and nodes (which are not mapped to the VMs of the previous diagram). If I explode the namespaces I can see services and pods, but pods are not mapped to network namespaces from the VM pictures.

raffaelespazzoli avatar Mar 18 '20 16:03 raffaelespazzoli

One thing to note is that there is no link between the "physical" environment meaning VMs and the logical representation meaning "kubernetes". AFAIK the only link between them is between the pods and the containers.

That said I think I found why there is no link in the context of crio/runc : https://github.com/skydive-project/skydive/blob/3d8fc8a3e08eabd4e1d7444773089d6ff4fb5c6e/topology/probes/k8s/container.go#L154

The mapping is using metadata of docker, so I think it should be adapted to have it working with runc

Another thing to note is that there is another UI (still wip) here

https://github.com/skydive-project/skydive-ui

safchain avatar Mar 18 '20 16:03 safchain

@safchain skydive could assume that when a physical host has the same ip as a OCP node, then it is a OCP node. RFE?

Also will someone fix the mapping between pods an container when running runc?

I'll give the new UI a try....

raffaelespazzoli avatar Mar 18 '20 19:03 raffaelespazzoli

@raffaelespazzoli yes that could be an approach, we need to agree on the best way to achieve this. I'll try to have a look to produce a fix for the mapping between pod and container.

safchain avatar Mar 19 '20 09:03 safchain

FWIW, the container <-> pod links should now be properly handled for both docker and runc The host <-> k8s nodes links are based on the hostname : the nodes with Type: host and Hostname: mynode with be linked to the k8s nodes with Type: node and Name: mynode

lebauce avatar Mar 01 '21 07:03 lebauce