10.3.1 Deployment Considerations

A few important points to understand to deploy Access Manager:

  • The Kubernetes cluster should contain one Master node and at least one Worker node.

  • Each worker node can run only one replica of an Access Manager component. However, two different components can run in the same node.

    For example, two instances of Administration Console, Identity Server, or Access Gateway cannot run in the same node. An instance of Administration Console and another of Identity Server can run in the same node.

  • If the number of users or your requirement of resource usage is low, it is possible to run all the components in a single worker node.

  • In a node, the port used by one container cannot be used by another container because Access Manager uses host networking.

  • To scale up, you must increase the number of worker nodes. For example, to run three instances of Identity Server, you must have three worker nodes.

  • Ensure that the system meets the requirements for installing Access Manager containers. See System Requirements of Administration Console, Identity Server, Access Gateway Containers.

The following table lists the maximum number of Access Manager pods that can be deployed on a given number of worker nodes:

Number of Worker Nodes

Administration Console Pod

Identity Server Pod

Access Gateway Pod

1

1

1

1

2

1

2

2

3

1

3

3

NOTE:As you increase the number of worker nodes, you can increase Identity Server and Access Gateway to that many instances.

Memory Allocation of Pods

The default resource memory limit of Access Manager pods are as follows:

Pod

Default Memory

eDirectory

1 Gi

Administration Console

2 Gi

Identity Server

2 Gi

Access Gateway

2 Gi

However, based on your need, you might need to allocate more memory to Tomcat as per the performance sizing recommendations for a production environment.

To determine the JAVA memory that you should allocate for Identity Server, see JAVA Memory Allocations, and for Access Gateway, see JAVA Memory Allocations.

To increase the pods’ memory, replace the respective values in the access-manager/values.yaml file.

IMPORTANT:You must update the memory values before running the Access Manager helm chart.

Docker containers usually have a default list of Linux capabilities enabled. You must ensure to keep only the following capabilities enabled for Primary Administration Console, secondary Administration Console, Identity Server, Access Gateway, and eDirectory containers and do not use the others:

  • CHOWN

  • FOWNER

  • SYS_CHROOT

  • DAC_OVERRIDE

  • SETGID

  • SETUID

  • NET_BIND_SERVICE

  • AUDIT_WRITE

Adding Privileges for Access Manager Docker

To add any extra privileges:

  1. Navigate to the access-manager/templates/_am-templates.tpl file.

  2. Add or Drop privileges as relevant in the following format:

    {{/******  Spec for capabilities required by Access Manager  ****/}}
{{- define "access-manager.capabilities" -}}
capabilities:
  drop:
  - all
  add:
  - CHOWN
  - KILL
  - FOWNER
  - DAC_OVERRIDE
  - SETGID
  - SETUID
  - AUDIT_WRITE
  - NET_BIND_SERVICE
{{- end }}

    Similarly, for Analytics Dashboard you can add extra privileges in the section in file named _am-templates.tpl. After you add, helm install can be done (for fresh install) or helm upgrade (if already installed)

  3. Enter the helm install (if installing for the first time) or helm upgrade (if you are upgrading) command as applicable.