How to specify TLS cert for this to work

[michielbdejong]

Up to now we had https://mesh.pondersource.org/ running with revad listening directly to port 443, using this built-in TLS feature of revad.

But this helm chart doesn't seem to use it. Instead, it seems that we should be using some sort of ingress using the ingress.services.{http,grpc}.tls config that is mentioned in https://github.com/cs3org/charts/tree/master/revad#configuration ?

I'm not very experienced with kubernetes and there is very little "Getting Started" info here.

I see the following sites all run revad with TLS on port 443:

• https://iop.sciencemesh.uni-muenster.de/iop/ocm
• https://sciencemesh.cesnet.cz/iop/ocm
• https://sciencemesh.cernbox.cern.ch/iop/ocm
• https://app.cs3mesh-iop.k8s.surfsara.nl/iop/ocm
• https://surf-iop-rd-app-acc.data.surfsara.nl/ocm
• https://exp-surf-iop-rd-app-acc.data.surfsara.nl/ocm
• https://sciencemesh.cubbit.io/ocm
• https://sciencemesh.softwaremind.com/iop/ocm
• https://sciencemesh-test.switch.ch/iop/ocm
• https://cs3mesh.sciencedata.dk/ocm
• https://mesh.pondersource.org/ocm

How do they do it? Are there no docs about this?

[michielbdejong]

What I tried so far:

helm repo add cs3org https://cs3org.github.io/charts/
helm install my-reva cs3org/revad
kubectl get configMaps
-> you should see 'my-reva-revad-config' listed there
kubectl describe configmaps my-reva
-> you should see the config

[michielbdejong]

https://github.com/cs3org/charts/blob/7d4fb62/revad/templates/ingress.yaml#L28 seems related

[michielbdejong]

The cert I want to use is in /etc/letsencrypt/live/mesh.pondersource.org/ - maybe something like helm install custom-reva cs3org/revad \ --set-file configFiles.revad\\.toml=custom-config.toml can fill that into the templates somehow?

[SamuAlfageme]

Hi @michielbdejong, you can take a look at the docs on https://developer.sciencemesh.io/docs/technical-documentation/iop/deployment/kubernetes/#configuring-an-iop-deployment. There's a TLS-terminated setup for the revad gateway ingress resource described in there.

Let us know if something remains unclear from that documentation. cc/ @dagl

[michielbdejong]

Thanks! I was able to follow those instructions and import my LetsEncrypt cert into a Kubernetes secret. Just debugging this error now:

helm upgrade -i iop sciencemesh/iop   --set-file gateway.configFiles.revad\\.toml=standalone.toml   --set-file gateway.configFiles.users\\.json=users-cern.json   --set-file gateway.configFiles.ocm-providers\\.json=providers.demo.json   -f custom-ingress.yaml
Release "iop" does not exist. Installing it now.
Error: unable to build kubernetes objects from release manifest: [resource mapping not found for name: "iop-gateway-grpc" namespace: "" from "": no matches for kind "Ingress" in version "networking.k8s.io/v1beta1"
ensure CRDs are installed first, resource mapping not found for name: "iop-gateway-http" namespace: "" from "": no matches for kind "Ingress" in version "networking.k8s.io/v1beta1"
ensure CRDs are installed first]

[michielbdejong]

Changing sciencemesh/iop to cs3org/revad there helps.

Compare:

helm repo add cs3org https://cs3org.github.io/charts/

vs

helm repo add sciencemesh https://sciencemesh.github.io/charts/

[michielbdejong]

Ref https://github.com/sciencemesh/charts/issues/24

[michielbdejong]

helm repo list
NAME        URL                                  
cs3org      https://cs3org.github.io/charts/     
sciencemesh https://sciencemesh.github.io/charts/

[michielbdejong]

There seems to be a mismatch between Values.ingress.enabled and gateway.ingress.enabled.

[SamuAlfageme]

@michielbdejong could you post the values of running the helm update -i command with the--debug and --dry-run flags? the generated ingress YAML manifests should contain the right networking.k8s.io/v1 as API version after https://github.com/cs3org/charts/pull/34.

Which version of Kubernetes are you using?

There's no mismatch between those two values. The sciencemesh/iop chart is an umbrella depending on the cs3org/revad chart amongst others. When setting gateway.ingress.enabled=true you're explicitly exposing through an ingress resource just 1/3 of the reva daemons that the IOP chart contains, both through HTTP and gRPC.

[michielbdejong]

@SamuAlfageme thanks! CC @navid-dada

[shokri-navid]

I think it is based on our side in Kubernetes because I could not expose even a simple project on port 80 on the internet. So we were using Minikube and I guess the problem is from that, I installed Kubernetes and I am trying to figure it out

[wkloucek]

I think it is based on our side in Kubernetes because I could not expose even a simple project on port 80 on the internet. So we were using Minikube and I guess the problem is from that, I installed Kubernetes and I am trying to figure it out

When using Minikube you can run minikube addons enable ingress and then your service will be exposed on the minikube interface, from which you can get the ip by running minikube ip (https://minikube.sigs.k8s.io/docs/commands/ip/).