Telling you something you already know:  You've got some bad state in your container image or in the persistent storage. 

I think we'd need to see more to be able to help:
* What's the command you're using to run the container?  All the environment variables and mount points is super-important here
* What's the container you're running?  If its your own, maybe the Dockerfile would help

Here's an example I had put together in a different context.  It sets up a single IRIS instance with a WebGateway and IAM.  It also sets up TLS on the IAM instance.

apiVersion: intersystems.com/v1alpha1
kind: IrisCluster
metadata:
  name: fhir-iam
spec:
  imagePullSecrets:
    - name: icr-secret
  storageClassName: gp2
  licenseKeySecret:
    name: fhir-iris-key-secret
  configSource:
    name: fhir-iris-cpf
  tls:
    iam:
      secret:
        secretName: fhir-iam-tls
  topology:
    iam:
      image: containers.intersystems.com/intersystems/iam:3.0.2.0-4
    webgateway:  
      image: containers.intersystems.com/intersystems/webgateway:2022.1.0.209.0
      type: apache
      replicas: 1
      applicationPaths:
        - /csp/sys
        - /myfhirserver
        - /csp/healthshare
      alternativeServers: LoadBalancing
    data:
      image: containers.intersystems.com/intersystems/irishealth:2022.1.0.209.0
  serviceTemplate:
    spec:
      type: ClusterIP

Glad to hear the interest in Python.

When you use embedded python, IRIS loads Python into memory in the process (via CPython).  The specific version of Python depends on your OS.  That's documented here:  https://docs.intersystems.com/irisforhealthlatest/csp/docbook/DocBook.UI...

Loading Python into the IRIS process does just what you think it does - not a separate process and references in Python to ObjectScript objects are in-memory.  So there's no performance difference between using Embedded Python from IRIS or starting with a Python program and `import iris`.

The start.sh script just calls docker-compose up.  You should be able to do podman-compose up to start SAM.  The first time it runs, it needs to download the containers (you can see what they are in the docker-compose.yaml file) if you don't already have them in your local podman cache.

During normal runtime, SAM doesn't require access to the internet.  That said, I haven't personally tested SAM without internet access.

Good luck!  Let us know how it goes.

It sounds like you're looking for persistent storage, which means you want to use the Durable %SYS feature.  Here's the info to get you started:  https://docs.intersystems.com/irislatest/csp/docbook/DocBook.UI.Page.cls....

To answer your specific questions:

1. Yes, IRIS works with any StorageClass that your Kubernetes cluster has installed, including any storage class you might have created for EBS or EFS. If you haven't yet tried it, the InterSystems Kubernetes Operator can simplify deployments in Kubernetes.  Even if you don't use IKO in production, it's a good way to see how everything should be configured.  https://docs.intersystems.com/irislatest/csp/docbook/DocBook.UI.Page.cls...

2. IRIS 2022.1 also includes first-class support for AWS SQS.  You can use it in your Productions or use ObjectScript to send messages to it.  https://docs.intersystems.com/irislatest/csp/documatic/%25CSP.Documatic....