Add initial values and container to the kubeapps-apis service.

[absoludity]

Description of the change

Adds the initial values and container for the oci-catalog to the kubeapps-apis service.

Leaving in draft for the moment as there are a number of things I want to check IRL while playing:

• Use an actual grpc liveness check (to test that out, since we can remove the grpc health binary, as our oldest k8s version is now past 1.24) Bitnami tests are still testing with 1.23 apparently.
• Evaluate whether kubeapps-apis is really the right pod for having this side-car. We'll need to use the service when validating a repo from the UX (which is kubeapps-apis), but also during the sync job. It could also run as a separate pod, but not sure it's worth the resources.

Note: I've got ociCatalog.enabled defaulting to false now, so no change to the chart output.

Benefits

Can start integration.

Possible drawbacks

Applicable issues

• ref Implementation of OCI-Catalog gRPC micro-service #6263

Additional Information

$ helm template ./chart/kubeapps --debug --set ociCatalog.enabled=true | grep -A 40 oci-catalog
install.go:200: [debug] Original chart version: ""
install.go:217: [debug] CHART PATH: /Users/minelson/dev/vmware/kubeapps/chart/kubeapps

        - name: oci-catalog
          image: docker.io/kubeapps/oci-catalog:latest
          imagePullPolicy: "IfNotPresent"
          securityContext:
            runAsNonRoot: true
            runAsUser: 1001
          command:
            - /oci-catalog
          args:
          env:
            - name: OCI_CATALOG_PORT
              value: "50061"
          envFrom:
          ports:
            - name: grpc-http
              containerPort: 50061
          livenessProbe:
            failureThreshold: 6
            initialDelaySeconds: 60
            periodSeconds: 10
            successThreshold: 1
            timeoutSeconds: 5
            exec:
              command: ["grpc_health_probe", "-addr=:50061"]
            initialDelaySeconds: 10
          readinessProbe:
            failureThreshold: 6
            initialDelaySeconds: 0
            periodSeconds: 10
            successThreshold: 1
            timeoutSeconds: 5
            exec:
              command: ["grpc_health_probe", "-addr=:50061"]
            initialDelaySeconds: 5
          resources:
            limits:
              cpu: 250m
              memory: 256Mi
            requests:
              cpu: 25m
              memory: 32Mi
          volumeMounts:
      volumes:
        - name: clusters-config
          configMap:
            name: release-name-kubeapps-clusters-config
        - name: ca-certs
          emptyDir: {}

With these changes in dev:

k -n kubeapps logs kubeapps-internal-kubeappsapis-7f5cc7f98b-wnqq4 oci-catalog     
[2023-08-14T01:42:41Z INFO  oci_catalog] listening for gRPC requests at 0.0.0.0:50061

[netlify]

✅ Deploy Preview for kubeapps-dev canceled.

Name	Link
🔨 Latest commit	8b8ffbc
🔍 Latest deploy log	https://app.netlify.com/sites/kubeapps-dev/deploys/64dacb79e4dd480008543fd7

[absoludity]

Struggled to avoid the run-time error:

/oci-catalog/oci-catalog: error while loading shared libraries: libssl.so.1.1: cannot open shared object file: No such file or directory

so the above switches off the default reqwest feature which enables native tls and uses rustls-tls exclusively.

[antgamdia]

Ah, makes sense, latest debian distro deprecated libssl.so.1.1 in favor of a newer version, nice to see it's doable to fall back to rustls-tls. Thanks for the info!

[absoludity]

Ah, makes sense, latest debian distro deprecated libssl.so.1.1 in favor of a newer version

Yeah, but I even tried compiling with rust:1.71.1-bookworm , which compiled fine (so I assume should have been linking to libssl3), but it would have the same runtime error (tested in that same build image just running binary with -h, rather than transferring to the output image). But yes, glad we can use rusttls instead.

[antgamdia]

+1, but I'd have to double-check #6605 (comment). I don't know if here we are also adding duplicated keys to the yaml. Anyway, +1 to merge it now and fix it later (if so).

[absoludity]

+1, but I'd have to double-check #6605 (comment). I don't know if here we are also adding duplicated keys to the yaml. Anyway, +1 to merge it now and fix it later (if so).

Done - thanks.