Failing cart-db and order-db due to missing AVX support on kubernetes cluster

[amchoukir]

Based on:

9bffa02 (HEAD -> master, origin/master, origin/HEAD) Merge pull request #872 from jrryjcksn/master

When deploying the application

microservices-demo/deploy/kubernetes$ kubectl apply -f complete-demo.yaml

cart-db and orders-db are in CrashLoopBackOff

Every 2.0s: kubectl get pods -n sock-shop                                                                                                              k8s1: Fri Sep  3 15:32:04 2021

NAME                            READY   STATUS             RESTARTS   AGE
carts-b4d4ffb5c-trvtq           1/1     Running            0          3m19s
carts-db-6c6c68b747-667m2       0/1     CrashLoopBackOff   4          3m19s
catalogue-5bd97b4988-r89wl      0/1     Running            0          3m19s
catalogue-db-96f6f6b4c-ffll2    1/1     Running            0          3m18s
front-end-6649c54d45-7wtvh      1/1     Running            0          3m18s
orders-7664c64d75-c9bnp         1/1     Running            0          3m17s
orders-db-659949975f-fgjc7      0/1     CrashLoopBackOff   4          3m17s

Looking at the pod logs it is due to a missing AVX support on the cluster that mongo requires.

ubuntu@k8s1:~/learning/microservices-demo/deploy/kubernetes$ kubectl logs carts-db-6c6c68b747-85q45 -n sock-shop

WARNING: MongoDB 5.0+ requires a CPU with AVX support, and your current system does not appear to have that!
  see https://www.mongodb.com/community/forums/t/mongodb-5-0-cpu-intel-g4650-compatibility/116610/2
  see also https://github.com/docker-library/mongo/issues/485#issuecomment-891991814

By changing the image version back to mongo 4.2.16-rc0 in complete-demo.yaml we avoid the CrashLoopBackOff

…
      - name: carts-db
        image: mongo:4.2.16-rc0
…
      - name: orders-db
        image: mongo:4.2.16-rc0
…

Every 2.0s: kubectl get pods -n sock-shop                                                                                                              k8s1: Fri Sep  3 16:19:36 2021

NAME                            READY   STATUS    RESTARTS   AGE
carts-b4d4ffb5c-d57kt           1/1     Running   0          75s
carts-db-64599bdbb6-wkhsn       1/1     Running   0          75s
catalogue-5bd97b4988-7kxpq      0/1     Running   0          75s
catalogue-db-96f6f6b4c-9l6bp    1/1     Running   0          75s
front-end-6649c54d45-8glrw      0/1     Running   0          74s
orders-7664c64d75-pwxl2         1/1     Running   0          74s
orders-db-84fd8b4858-n48tm      1/1     Running   0          73s
payment-dd67fc96f-8th74         0/1     Running   0          73s
queue-master-5f6d6d4796-5q8mc   1/1     Running   0          72s
rabbitmq-5bcbb547d7-b8qrq       2/2     Running   0          72s
session-db-7cf97f8d4f-2gj9j     1/1     Running   0          72s
shipping-7f7999ffb7-txsch       1/1     Running   0          71s
user-888469b9f-6pnvh            0/1     Running   0          71s
user-db-6df7444fc-wp5ms         1/1     Running   0          70s

If mongo 5.0+ is not a strong requirement I would suggest freezing the version. If it is then lest just document this workaround.

[rudipoppes]

THANK YOU @amchoukir. This solved my problem that I have been having with other Kubernetes applications as well.