feat: Helm Charts created

[Helion55]

Description

Helm chart to install Network Observability Operator

Fixes #1000

Upstream-only feature

Dependencies

n/a

[openshift-ci]

Hi @Helion55. Thanks for your PR.

I'm waiting for a netobserv member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[Helion55]

This helm chart contains

1. A deployment file created from This
2. ClusterRole form This
3. Role from This
4. Metrics Service file from netobserv-metrics-service_v1_service.yaml
5. Webhook Service file from netobserv-webhook-service_v1_service.yaml
6. Flow collector CRD from flows.netobserv.io_flowcollectors.yaml
7. Flow metrics CRD from flows.netobserv.io_flowmetrics.yaml
8. ConfigMap from netobserv-manager-config_v1_configmap.yaml

for the Issue #1000

[jotak]

Thanks a lot @Helion55 !

I've found a couple of issues while trying, posting here suggestions.

There's still an issue related to the certificate that I'm looking into. A certificate is needed for the operator webhooks, and we rely on cert-manager to generate them. Need to figure out how to do that with helm. Basically, it is expected that a certificate is generated in a Secret named webhook-server-cert.

[jotak]

typo here

Suggested change

	name: wnetobserv-controller-manager
	name: netobserv-controller-manager

[Helion55]

my bad😅

[jotak]

this is actually still there :-)

[jotak]

I think in your last commit you reverted some of the changes that you did, I guess inadvertently

[Helion55]

Thanks a lot @Helion55 !

I've found a couple of issues while trying, posting here suggestions.

There's still an issue related to the certificate that I'm looking into. A certificate is needed for the operator webhooks, and we rely on cert-manager to generate them. Need to figure out how to do that with helm. Basically, it is expected that a certificate is generated in a Secret named webhook-server-cert.

Hello @jotak Thanks for the suggestions. I have committed them. I am also starting to find any solutions regarding that certificate stuff, I have recently worked with cert manager; I hope to get help from that.

[jotak]

We surely want the namespace to be configurable:

Suggested change

	namespace: netobserv
	namespace: {{ .Release.Namespace }}

[jotak]

Same here:

Suggested change

	namespace: netobserv
	namespace: {{ .Release.Namespace }}

[jotak]

I'm installing latest cert-manager on kind, and use this certificate config:

# The following manifests contain a self-signed issuer CR and a certificate CR.
# More document can be found at https://docs.cert-manager.io
apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: selfsigned-issuer
spec:
  selfSigned: {}
---
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: serving-cert
spec:
  dnsNames:
  - netobserv-webhook-service.{{ .Release.Namespace }}.svc
  - netobserv-webhook-service.{{ .Release.Namespace }}.svc.cluster.local
  issuerRef:
    kind: Issuer
    name: selfsigned-issuer
  secretName: webhook-server-cert

Which generates the intended certificate, and the oeprator pod now starts correctly.
However it still has errors in logs, tls related:

2025/01/27 10:33:30 http: TLS handshake error from 10.244.0.1:34825: remote error: tls: bad certificate
E0127 10:33:31.386704       1 leaderelection.go:347] error retrieving resource lock netobserv/7a7ecdcd.netobserv.io: leases.coordination.k8s.io "7a7ecdcd.netobserv.io" is forbidden: User "system:serviceaccount:netobserv:default" cannot get resource "leases" in API group "coordination.k8s.io" in the namespace "netobserv"
2025/01/27 10:33:31 http: TLS handshake error from 10.244.0.1:1923: remote error: tls: bad certificate

... so we're not done yet

[jotak]

Hi @Helion55 ,
I rebased the branch and added the certificate - I haven't fully tested yet, but now the operator pod starts correctly

[jotak]

I think it can be merged as a first iteration, or let me know if there's more you plan to add.

Later we'll want to have the chart automatically generated from the make targets, similar to what we have today with the OLM bundle. And then we can think about pushing that to ArtifactHub. So let me know if you're interested :-)

[Helion55]

Yes, it sounds good. Just one thing: can we go with the Let's Encrypt issuer rather than self-signed certificates? Please check this once.

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: cert-issuer
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: <YOUR-MAIL@MAIL.COM>
    privateKeySecretRef:
      name: private-key-cert
    solvers:
    - http01:
        ingress:
          class: nginx 

[jotak]

Yes, it sounds good. Just one thing: can we go with the Let's Encrypt issuer rather than self-signed certificates? Please check this once.

I guess that's the kind of things that make sense to customize in the helm values? So user can choose between self-signed or let's encrypt, and in case of the latter, they have to provide an email and key secret ref?

[jotak]

@Helion55 on second thought, I don't think it's the role of netobserv to create a real ClusterIssuer on the server. Instead we could go that way:

• either the user supplies an existing issuer (so, users can have their let's encrypt issuer already configured, and we use a reference to it
• or they don't, and a self-signed certificate is created

[jotak]

/lgtm
@Helion55 looks good to you?

[openshift-ci]

@Helion55: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
ci/prow/e2e-operator	fe90f58	link	false	/test e2e-operator

Full PR test history. Your PR dashboard.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.

[Helion55]

@Helion55 on second thought, I don't think it's the role of netobserv to create a real ClusterIssuer on the server. Instead we could go that way:

• either the user supplies an existing issuer (so, users can have their let's encrypt issuer already configured, and we use a reference to it
• or they don't, and a self-signed certificate is created

Yes, this will be much more convenient.

Can you merge this for now? After that, we can improve this as required in the future.
I am also eager to make a dynamic chart for this application, which will be very useful after getting an idea of how this is working at this moment, and if required, we can make a whole helm deployment with installing Prometheus and Loki, just like Kubernetes monitoring setup helm charts.

[jotak]

/approve
thanks for your contrib @Helion55 !

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: jotak

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [jotak]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment