How to intall in a custom Kubernetes Cluster?

[rsoika]

Hi,
I did not understand the instructions in the README.md file. what does the following command do??

kubectl apply -f https://raw.githubusercontent.com/jitsi-contrib/jitsi-kubernetes-operator/master/deploy/jitsi-operator.yaml

How can I configure my own Web Address for the Jitsi server? I guess I need somehow a Ingres configuration? Also the files in the /config/samples folder are not clear to me? How should I customize these files an how are these files applied during the deployment?

Can someone give me a hint how to setup my own jitsi server using this kubernetes-obperator?

[hrenard]

Hey !
Sorry the documentation is still missing...
The above command will install the Custom Resource Definition and the operator in your k8s cluster.
Then you can deploy a jitsi cluster simply with a kubectl apply of :

apiVersion: apps.jit.si/v1alpha1
kind: Jitsi
metadata:
  name: my-jitsi
spec:
  domain: meet.my-domain.com
  ingress:
    annotations:
      cert-manager.io/cluster-issuer: letsencrypt
    enabled: true
    tls: true
  jibri:
    enabled: true
    replicas: 1
  jvb:
    gracefulShutdown: true
    strategy:
      replicas: 1
      type: static
  region: europe
  timezone: Europe/Paris
  variables:
    ENABLE_BREAKOUT_ROOMS: "1" 

For now, we rely on the nginx-ingresss controller's annotations.
Every environment variables of the docker jitsi can be used in the variables field (except the ones managed by the operator).

[rsoika]

Thanks, yes we are also running nginx-ingress. So I will try this out and give you feedback...

[rsoika]

ok, everything seems to work fine.
The installation of the operator was no problem.

Installing my custom deployment also worked well. I just needed to rename the cert-manager.io/cluster-issuer from letsencrypt to letsencrypt-prod because of my cluster setup.

In addition I added a namespace to my deployment config which was at the end no problem.

Great Work!!
I think I will update the https://github.com/jitsi-contrib/jitsi-kubernetes page to use this operator as the installation seems to be more easy. Or maybe I describe this as an alternative way to run Jitsi on Kubernetes

[hrenard]

Wonderful, thank you !

We, IndieHosters use it in production to host multiple Jitsi instances. You can chat with us on Matrix, if you want.
Unfortunately we haven't had the time to advocate the operator to the community. But we believe, although building an operator is more work, that it's the way to go for managing things at scale.

I'll try to clean up the readme to list features like autoscaling, graceful upgrade (upgrading when there are no conferences)... And add a roadmap, we want to support shared JVB & Jibri pools, add Jigasi... And some documentation.

[rsoika]

Another point you probably already know:

I protected my installation with a password for meetings by adding the following two environment variables:

  variables:
    ENABLE_BREAKOUT_ROOMS: "1"
    # Close Rooms with password
    ENABLE_AUTH: "1"
    ENABLE_GUESTS: "1"
    # Set admin password in the prosody server with:
    #  prosodyctl --config /config/prosody.cfg.lua register admin [YOUR-JITSI-DOMAIN]

This also worked great out of the box.

[hrenard]

We use the JWT_* vars for auth 😄

[rsoika]

Hi @hrenard can you please give an example how you set the auth via JWT_* ?
Setting the password with

prosodyctl --config /config/prosody.cfg.lua register admin [YOUR-JITSI-DOMAIN]

did no longer work. See also here

[hrenard]

Hey !

We add those env vars :

AUTH_TYPE: jwt
ENABLE_AUTH: "1"
JWT_ALLOW_EMPTY: "0"
JWT_APP_ID: my-app
JWT_APP_SECRET: XXX
JWT_AUTH_TYPE: token

And we manually create a JWT that look like this :

{
  "context": {
    "user": {
      "avatar": "your_client_avatar_url",
      "name": "your_client_name",
      "email": "your_client_email"
    }
  },
  "moderator": true,
  "aud": "jitsi",
  "iss": "my-app",
  "sub": "jitsimeet.your_domain.com",
  "room": "*",
  "exp": 1753498815
}

(Not all fields are required).