Documentation is not up-to-date about jitsi-kubernetes HOT 11 CLOSED

Yes maybe it is an architecture problem. Please report your issue here, because this is not something we can resolve here. This project only has the focus to support Kubernetes deployments with Kubernetes Kustomize

from jitsi-kubernetes.

You need to create the 041-ingress.yaml file by your self. We can not provide a generic version as it includes environment specific settings. But an example of that file can be found here

Can you provide more information what happens in your environment when you try to run the deployment?

from jitsi-kubernetes.

Thanks for your quick reply.

• Does kubectl apply -k ./my-deployment mean that I need to run kubectl apply -k . inside the doc/kustomize folder?
• FYI: The 010-deployment.yaml file described in the README is not the same as the one you have in the code base. The one you have in the code base is 030-deployment.yaml - Probably a new version of that file so need to update the docs.

I get the following error when creating the resources:

service/jvb-udp created
podsecuritypolicy.policy/jitsi-privileged created
role.rbac.authorization.k8s.io/jitsi-privileged created
rolebinding.rbac.authorization.k8s.io/jitsi-privileged created
serviceaccount/jitsi created
deployment.apps/jitsi created
service/web created
ingress.networking.k8s.io/jitsi created
error: error validating "kustomize/kustomization.yaml": error validating data: [apiVersion not set, kind not set]; if you choose to ignore these errors, turn validation off with --validate=false

The status of the pod is CrashLoopBackOff. kubectl get events -n jitsi returns all normal, so, I don't know where the issue is.

from jitsi-kubernetes.

Which command have you used to run the deployment?

It should be:

$ kubectl apply -k  ./my-jitsi

And in the folder /my-jitsi/ you need only to place the files with your customization - these are the files:

• 010-deployment.yaml
• 041-ingress.yaml

The file kustomization.yaml references to the main files hosted on github. see the 3rd line:

namespace: jitsi
bases:
- https://github.com/jitsi-contrib/kubernetes/doc/kustomize

resources:
- 041-ingress.yaml

patchesStrategicMerge:
- 010-deployment.yaml

I fear that you have copied also the files from the /kustomize/ folder into your local deployment? This is not necessary.

You local deployment should look like this:

.
├── my-jitsi
│   ├── 010-deployment.yaml
│   ├── 041-ingress.yaml
│   └── kustomization.yaml

The command kubectl apply -k will than only look into the file 'kustomization.yaml' and processes all the references made there.

from jitsi-kubernetes.

You were right, I did have the other files under that directory.

Now my folder looks like:

|── my-jitsi
│   ├── 010-deployment.yaml
│   ├── 041-ingress.yaml
│   └── kustomization.yaml

However, when executing kubectl apply -k ./my-jitsi I get:

error: SliceFromPatches: evalsymlink failure on '/Users/lucas/Documents/study/git/jitsi-kubernetes/my-jitsi/010-deployment.yaml' : lstat /Users/lucas/Documents/study/git/jitsi-kubernetes/my-jitsi/010-deployment.yaml: no such file or directory

from jitsi-kubernetes.

OK. I had a type in my kustomization.yaml file. Now I can successfully run the command kubectl apply -k ./my-jitsi.

However, my POD is still in CrashLoopBackOff.

Getting the events I don't see any error message. Do you have any tips on how to troubleshoot this?

Cheers!

from jitsi-kubernetes.

I'll put all the steps I followed below, to help troubleshoot it:

1. kubectl create namespace jitsi
2. Install nginx-ingress-controller and ACME with Let's Encrypt following these steps
3. Created file kustomization.yaml
4. Created file 041-ingress.yaml
5. kubectl apply -k ./my-jitsi

File kustomization.yaml:

namespace: jitsi
bases:
- https://github.com/jitsi-contrib/kubernetes/doc/kustomize

resources:
- 041-ingress.yaml

patchesStrategicMerge:
- 030-deployment.yaml

File 041-ingress.yaml:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: jitsi
  namespace: jitsi
  annotations:
    kubernetes.io/ingress.class: "nginx"    
    cert-manager.io/issuer: "letsencrypt-staging"

spec:
  tls:
  - hosts:
    - meet.lpossamai.me
    secretName: quickstart-example-tls
  rules:
  - host: meet.example.me
    http:
      paths:
      - path: /
        pathType: Exact
        backend:
          service:
            name: jitsi
            port:
              number: 80

Output of kubectl get all -n jitsi:

NAME                        READY   STATUS             RESTARTS   AGE
pod/jitsi-b7687cf96-ztzqj   0/4     CrashLoopBackOff   20         6m45s

NAME              TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)           AGE
service/jvb-udp   NodePort    10.98.241.55     <none>        30300:30300/UDP   6m45s
service/web       ClusterIP   10.111.172.142   <none>        80/TCP,443/TCP    6m45s

NAME                    READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/jitsi   0/1     1            0           6m45s

NAME                              DESIRED   CURRENT   READY   AGE
replicaset.apps/jitsi-b7687cf96   1         1         0       6m45s

Edit: I'm using a MAC M1 chip to run kubectl, and my Kubernetes cluster is from a couple of Raspberry Pi 4. Maybe those containers are not ARM?

from jitsi-kubernetes.

You need to figure out the cause of the CrashLoopBackOff. Take a look into the event logs

from jitsi-kubernetes.

You need to figure out the cause of the CrashLoopBackOff. Take a look into the event logs

I'm a bit rusty from K8s, but when I type kubectl logs jitsi-b7687cf96-ztzqj --all-containers=true -n jitsi, I get:

standard_init_linux.go:211: exec user process caused "exec format error"
standard_init_linux.go:211: exec user process caused "exec format error"
standard_init_linux.go:211: exec user process caused "exec format error"
standard_init_linux.go:211: exec user process caused "exec format error"

I don't know if that error is coming from those containers, or if it's from kubectl. Did I run the right kubectl command?

Thanks!

from jitsi-kubernetes.

Edit: I'm using a MAC M1 chip to run kubectl, and my Kubernetes cluster is from a couple of Raspberry Pi 4. Maybe those containers are not ARM?

Looks like that's exactly the issue here.

from jitsi-kubernetes.

I can confirm the issue was due to me running the containers in a Raspberry PI (ARM architecture). Running it on EKS worked.

from jitsi-kubernetes.