Quando considerar o uso de useIrisFsGroup em suas implantações do IKO

Se você olhar o arquivo values.yaml do Helm chart do IKO, você encontrará:

useIrisFsGroup: false 

Vamos detalhar o que isso é e em quais situações você pode querer configurá-lo como true.

FsGroup se refere ao grupo do sistema de arquivos.

Por padrão, os volumes do Kubernetes pertencem ao usuário root, mas precisamos que o IRIS seja o dono de seus arquivos (o IRIS em containers é instalado sob o usuário irisowner). Para contornar isso, utilizamos um de dois métodos:

1) initContainers

Os initContainers são executados antes dos containers da aplicação (como o IRIS) em um pod. Eles geralmente preparam o ambiente para a aplicação e, em seguida, são executados até a conclusão e encerram. O initContainer é executado como root antes do IRIS e executa:

chown -R irisowner:irisowner /irissys/*

O SecurityContext é, por padrão, configurado como:

RunAsUser: 51773
RunAsGroup: 51773
RunAsNonRoot: true

para o pod. E vemos que 51773 é o ID de usuário e de grupo do irisowner:

$ id
uid=51773(irisowner) gid=51773(irisowner) groups=51773(irisowner)

2) Montar volumes com uma determinada propriedade de grupo

Alguns ambientes podem restringir a execução de qualquer container como root, por exemplo por meio de Security Context Constraints no OpenShift. Nesse caso, não podemos nem mesmo executar um initContainer como root e será necessário que os volumes recebam a propriedade correta do sistema de arquivos no momento da montagem. Para isso, implante o InterSystems Kubernetes Operator com

useIrisFsGroup: true 

em /chart/iris-operator/values.yaml file.

Agora seus pods serão implantados sem initContainers.

Como ressalva, se você quiser configurar sidecars, será necessária uma etapa extra. Você não pode usar o sidecar padrão do Apache/NGINX. Você encontrará este problema:

>> kubectl get pods
NAME                                              READY   STATUS    RESTARTS      AGE
intersystems-iris-operator-amd-76b75f6b48-7lnw2   1/1     Running   0             43m
iris-data-0-0                                     1/2     Error     2 (22s ago)   2m

o que resultará em um CrashLoopBackOff. Uma análise mais detalhada mostra que, quando o sidecar padrão do gateway web Apache/NGINX está presente, o useIrisFsGroup não é considerado. Isso acontece porque esses containers do Apache/NGINX, nesse caso o sidecar, são executados como root. O IRIS não é executado como root e, portanto, não consegue acessar seus diretórios, causando o problema.

irisowner@iris-data-0-0:/irissys$ ls -l
total 16
drwxrwxrwx 3 root root  107 Mar 31 14:28 cpf
drwxr-xr-x 3 root root 4096 Mar 31 14:21 data
drwxr-xr-x 3 root root 4096 Mar 31 14:21 journal1
drwxr-xr-x 3 root root 4096 Mar 31 14:21 journal2
drwxrwxrwt 3 root root  100 Mar 31 14:28 key
drwxr-xr-x 3 root root 4096 Mar 31 14:21 wij

IRIS falha com o erro:

[ERROR] Command "iris start IRIS quietly" exited with status 256
03/31/25-14:41:06:870 (795) 3 [Utility.Event] Error while moving data directories ERROR #5001: Cannot create target: /irissys/data/IRIS/

Em vez disso, devemos usar a imagem do gateway web que não roda como root (já que queremos que todas as nossas imagens sejam executadas como não-root). Isso implica um gateway web mais restrito. Também precisamos garantir que o security context seja adicionado para reforçar essa condição. Devemos declarar explicitamente:

securityContext:
  runAsUser: 51773
  runAsGroup: 51773
  runAsNonRoot: true
  fsGroup: 51773

no seu data/compute nodes.

Um exemplo de YAML para o nosso IrisCluster CRD reunindo tudo isso pode ser visto abaixo.

apiVersion: intersystems.com/v1alpha1
kind: IrisCluster
metadata:
  name: iris
spec:
  licenseKeySecret:
    name: iris-key-secret
  configSource:
    name: iris-cpf
  imagePullSecrets:
    - name: intersystems-pull-secret
  topology:
    data:
      image: containers.intersystems.com/intersystems/irishealth:2025.1
      compatibilityVersion: "2025.1.0"
      mirrored: true
      podTemplate:
        spec:
          resources:
            requests:
              memory: "4Gi"
              cpu: "2"
            limits:
              memory: "4Gi"
              cpu: "2"
          securityContext:
            runAsUser: 51773
            runAsGroup: 51773
            runAsNonRoot: true
            fsGroup: 51773
      webgateway:
        image: containers.intersystems.com/intersystems/webgateway-lockeddown:2025.1
        type: apache-lockeddown
        applicationPaths:
          - /csp/sys
          - /csp/user
          - /csp/broker
          - /api
          - /isc
          - /oauth2
          - /ui
          - /csp/healthshare
        loginSecret:
          name: iris-webgateway-secret
    webgateway:
      replicas: 1
      image: containers.intersystems.com/intersystems/webgateway-lockeddown:2025.1
      type: apache-lockeddown
      podTemplate:
        spec:
          resources:
            requests:
              memory: "2Gi"
              cpu: "1"
            limits:
              memory: "2Gi"
              cpu: "1"
      applicationPaths:
        - /csp/sys
        - /csp/user
        - /csp/broker
        - /api
        - /isc
        - /oauth2
        - /ui
        - /csp/healthshare
      alternativeServers: LoadBalancing
      loginSecret:
        name: iris-webgateway-secret
    arbiter:
      image: containers.intersystems.com/intersystems/arbiter:2025.1
  serviceTemplate:
    spec:
      type: ClusterIP

Happy YAMLing