charts: helm v3 charts for agent and analyzer

[hunchback]

in this PR I provide a:

• two independent charts skydive-analyzer and skydive-agent to enable more flexible deployments
• upgrade to helm3

note that I want to propose using the main repo skydive rather than auxiliary repos as this will provide for easier integration, faster development, and better CI coverage (later I would propose EOL of the skydive-helm and skydive-operator). some examples of other projects which use this approach:

• Fleet: https://github.com/rancher/fleet/tree/master/charts
• Istio: https://github.com/istio/istio/tree/master/manifests/charts/base
• cert-manager: https://github.com/jetstack/cert-manager/tree/master/deploy/charts/cert-manager

no CI tests currently - so attaching the status output

traverse to charts directory

cd charts

create a local test cluster:

make k3d

install charts

make install

check status (attaching output as there is currently no CI job):

$ make status
make -C skydive-analyzer status
make[1]: Entering directory '/home/aidan/projects/skydive-project/skydive/charts/skydive-analyzer'
kubectl get all -l app=skydive-analyzer-skydive-analyzer
NAME                                                              READY   STATUS    RESTARTS   AGE
pod/skydive-analyzer-skydive-analyzer-analyzer-54cb487d8d-drwld   2/2     Running   0          55m

NAME                                                         TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)                         AGE
service/skydive-analyzer-skydive-analyzer-internal-service   ClusterIP   10.106.47.49    <none>        12379/TCP,9200/TCP              55m
service/skydive-analyzer-skydive-analyzer-service            NodePort    10.107.18.208   <none>        8082:31996/TCP,8080:30595/TCP   55m

NAME                                                         READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/skydive-analyzer-skydive-analyzer-analyzer   1/1     1            1           55m

NAME                                                                    DESIRED   CURRENT   READY   AGE
replicaset.apps/skydive-analyzer-skydive-analyzer-analyzer-54cb487d8d   1         1         1       55m
make[1]: Leaving directory '/home/aidan/projects/skydive-project/skydive/charts/skydive-analyzer'
make -C skydive-agent status
make[1]: Entering directory '/home/aidan/projects/skydive-project/skydive/charts/skydive-agent'
kubectl get all -l app=skydive-agent-skydive-agent
NAME                                          READY   STATUS    RESTARTS   AGE
pod/skydive-agent-skydive-agent-agent-mqt4v   1/1     Running   0          37m

NAME                                               DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
daemonset.apps/skydive-agent-skydive-agent-agent   1         1         1       1            1           <none>          37m
make[1]: Leaving directory '/home/aidan/projects/skydive-project/skydive/charts/skydive-agent'

and one can now view UI via browser at http://localhost:30000:

[hunchback]

run skydive-functional-tests-backend-orientdb

[hunchback]

run skydive-functional-tests-backend-orientdb

[lebauce]

@hunchback Thanks for it ! The helm charts were moved to a dedicated repository https://github.com/skydive-project/skydive-helm Do you mind posting the PR there ?

[hunchback]

@hunchback Thanks for it ! The helm charts were moved to a dedicated repository https://github.com/skydive-project/skydive-helm Do you mind posting the PR there ?

my proposal is that we move the charts to the main repo (archiving skydive-helm), this way I can push current skydive image (generated in the PR prior to merge) to a local registry (say on localhost:5000) on the CI and then try the full integration with helm prior to someone committing a breaking change. by using modern local k8s clusters (either kind or k3s) I can provide a test which will run fast.

and during a release of skydive we will publish our updated helms to list of helm registries (actually modern docker registries support helm)

w.r.t. helm given how central helm is to any system it makes sense to maintain it in the main repo (just as our docker-compose is maintained here).

[hunchback]

run skydive-functional-tests-backend-elasticsearch

[hunchback]

run skydive-functional-tests-backend-orientdb

[hunchback]

run skydive-functional-tests-backend-elasticsearch

[hunchback]

run skydive-k8s-tests

[hunchback]

run skydive-k8s-tests

[hunchback]

run skydive-functional-tests-backend-orientdb

[hunchback]

run skydive-functional-tests-backend-elasticsearch

[hunchback]

run skydive-cdd-overview-tests run skydive-functional-tests-backend-elasticsearch run skydive-scale-tests

[lebauce]

run skydive-functional-tests-backend-elasticsearch

[lebauce]

run skydive-functional-tests-backend-elasticsearch