How to deploy Keycloak in AWS Fargate kubernetes cluster

12/23/2019

I have deployed a Kubernetes cluster using AWS EKS Fargate where I deployed the following deployment, service and Ingress for deploying Keycloak:

Deployment.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: ikonnekt-keycloak-deployment
spec:
  selector:
    matchLabels:
      app: ikonnekt-keycloak
  replicas: 1
  template:
    metadata:
      labels:
        app: ikonnekt-keycloak
        project: ikonnekt
        environment: development
    spec:
      containers:
      - name: ikonnekt-keycloak
        image: jboss/keycloak
        imagePullPolicy: Always
        env:
        - name: PROXY_ADDRESS_FORWARDING
          value: "true"
        - name: KEYCLOAK_LOGLEVEL
          value: DEBUG
        - name: ROOT_LOGLEVEL
          value: DEBUG
        ports:
        - containerPort: 8080
          protocol: TCP

Service.yaml:

apiVersion: v1
kind: Service
metadata:
  name: "service-keycloak"
  annotations:
    alb.ingress.kubernetes.io/target-type: ip
spec:
  ports:
    - port: 8080
      targetPort: 8080
      protocol: TCP
  type: NodePort
  selector:
    app: "ikonnekt-keycloak"

Ingress.yaml

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: "keycloak-ingress"
  annotations:
    kubernetes.io/ingress.class: alb
    alb.ingress.kubernetes.io/scheme: internet-facing
  labels:
    app: keycloak-ingress
spec:
  rules:
    - http:
        paths:
          - path: /*
            backend:
              serviceName: "service-keycloak"
              servicePort: 8080

I have tried exactly the same deployment, service and ingress with an NGINX container and it works without problems.

Is it necessary to add any specific configuration to run keycloak? After some minutes the pod prints the next error:

06:57:28,209 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0348: Timeout after [300] seconds waiting for service container stability. Operation will roll back. Step that first updated the service container was 'add' at address '[
    ("core-service" => "management"),
    ("management-interface" => "http-interface")
]'
06:58:04,511 WARN  [com.arjuna.ats.arjuna] (Transaction Reaper) ARJUNA012117: TransactionReaper::check timeout for TX 0:ffffc0a86ffa:1d34cfae:5e0d9329:10 in state  RUN
06:58:05,902 WARN  [com.arjuna.ats.arjuna] (Transaction Reaper) ARJUNA012117: TransactionReaper::check timeout for TX 0:ffffc0a86ffa:1d34cfae:5e0d9329:10 in state  SCHEDULE_CANCEL
06:58:06,812 WARN  [com.arjuna.ats.arjuna] (Transaction Reaper) ARJUNA012117: TransactionReaper::check timeout for TX 0:ffffc0a86ffa:1d34cfae:5e0d9329:10 in state  SCHEDULE_CANCEL
06:58:07,410 WARN  [com.arjuna.ats.arjuna] (Transaction Reaper) ARJUNA012378: ReaperElement appears to be wedged: com.arjuna.ats.arjuna.coordinator.BasicAction.Abort(BasicAction.java:1631)
com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.cancel(TwoPhaseCoordinator.java:124)
com.arjuna.ats.arjuna.AtomicAction.cancel(AtomicAction.java:215)
com.arjuna.ats.arjuna.coordinator.TransactionReaper.doCancellations(TransactionReaper.java:381)
com.arjuna.ats.internal.arjuna.coordinator.ReaperWorkerThread.run(ReaperWorkerThread.java:78)

06:58:10,211 WARN  [com.arjuna.ats.arjuna] (Transaction Reaper) ARJUNA012117: TransactionReaper::check timeout for TX 0:ffffc0a86ffa:1d34cfae:5e0d9329:13 in state  RUN
06:58:11,010 WARN  [com.arjuna.ats.arjuna] (Transaction Reaper) ARJUNA012117: TransactionReaper::check timeout for TX 0:ffffc0a86ffa:1d34cfae:5e0d9329:13 in state  COMPLETE
06:58:10,815 WARN  [com.arjuna.ats.arjuna] (Transaction Reaper Worker 0) ARJUNA012121: TransactionReaper::doCancellations worker Thread[Transaction Reaper Worker 0,5,main] successfully canceled TX 0:ffffc0a86ffa:1d34cfae:5e0d9329:13
06:58:12,612 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0190: Step handler org.jboss.as.server.DeployerChainAddHandler$FinalRuntimeStepHandler@1a2e74e for operation add-deployer-chains at address [] failed handling operation rollback -- java.util.concurrent.TimeoutException: java.util.concurrent.TimeoutException
    at org.jboss.as.controller.OperationContextImpl.waitForRemovals(OperationContextImpl.java:522)
    at org.jboss.as.controller.AbstractOperationContext$Step.handleResult(AbstractOperationContext.java:1518)
    at org.jboss.as.controller.AbstractOperationContext$Step.finalizeInternal(AbstractOperationContext.java:1472)
    at org.jboss.as.controller.AbstractOperationContext$Step.finalizeStep(AbstractOperationContext.java:1445)
    at org.jboss.as.controller.AbstractOperationContext$Step.access$400(AbstractOperationContext.java:1319)
    at org.jboss.as.controller.AbstractOperationContext.executeResultHandlerPhase(AbstractOperationContext.java:876)
    at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:726)
    at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:467)
    at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1412)
    at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:521)
    at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:472)
    at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:434)
    at org.jboss.as.server.ServerService.boot(ServerService.java:435)
    at org.jboss.as.server.ServerService.boot(ServerService.java:394)
    at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:374)
    at java.lang.Thread.run(Thread.java:748)

06:58:13,212 ERROR [org.jboss.as.controller.client] (Controller Boot Thread) WFLYCTL0190: Step handler org.jboss.as.server.DeployerChainAddHandler$FinalRuntimeStepHandler@1a2e74e for operation add-deployer-chains at address [] failed handling operation rollback -- java.util.concurrent.TimeoutException
-- Asier Gomez
amazon-web-services
aws-fargate
keycloak
kubernetes
kubernetes-ingress

1 Answer

1/2/2020

Finally it was solved adding more RAM requests to the deployment. It works fine using 4GB.

resources:
          limits:
            memory: "8192‬Mi"
          requests:
            memory: "4096Mi"
-- Asier Gomez
Source: StackOverflow