AWS EKS Addon

AMP is also available in the AWS Marketplace with an alternative delivery method - EKS Addon, which enables users to quickly and efficiently deploy AMP directly from their EKS clusters.

Addon usage instructions

In order to use Cloudsoft AMP as an EKS Addon, the user needs to have an EKS cluster running in one of supported regions. The user needs to be subscribed to the product, then in the console navigate to the cluster and go to the Add-ons tab. Then simply press Get more addons and find the add-on for Cloudsoft AMP.

Initial configuration

Prior to deploying AMP as an EKS Addon, it is worthwhile considering a few configurations required for the best experience.

Mandatory configuration

If passing custom configuration to th EKS addon, as per the schema defined and displayed on the configuration page, there are 2 required configuration objects, namely ampResourceLimits and ampServiceType. An example of the configuration including these 2 mandatory objects is presented below, on top of which user can add further customizations as explained below:

ampResourceLimits:
  requests:
    cpu: "1"
    memory: "4G"
  limits:
    cpu: "4"
    memory: "8G"
    
ampServiceType:
  loadBalancer: true
  nodePort: false
  clusterIp: false

AMP Password

The first configuration to note is the password for AMP. For EKS Addons, it is not allowed to provide passwords directly in the configuration file (values.yaml) and therefore an alternative method has been created to allow users to specify admin password for AMP deployed as EKS Addon.

In order to achieve that, one needs to create a secret in namespace cloudsoft-amp in the EKS cluster, which is the same namespace where AMP is installed. By default, AMP the Helm chart used to deploy AMP will look for secret names amp-secrets with key amp-admin-password. One can easily create this using the following template:

apiVersion: v1
kind: Secret
metadata:
  name: amp-secrets
type: Opaque
data:
  amp-admin-password: cGFzc3dvcmQ= # base64 encoded, in this example evaluates to password

then save as a file and use kubectl to apply it to the cluster (please note that the current context needs to be set to the EKS cluster where the secret should be applied):

kubectl apply -f amp-secrets.yaml --namespace cloudsoft-amp --create-namespace

The command above will install the secret in the desired namespace, creating it if it doesn’t exist already.

Alternatively, user can choose a different name for the secret and install it the same way as instructed above, in which case when deploying the addon, they also need to specify the name in the configuration value:

ampSecretsNameOverride: "my-secret-name"

If the user doesn’t specify the secret using either of the methods above, the password will be generated randomly. The user can then get the password using kubectl as follows:

kubectl get secret --namespace cloudsoft-amp -l "app.kubernetes.io/instance=cloudsoft-amp" -o jsonpath="{.items[0].data.amp-admin-password}" | base64 --decode  

Please note that if a random password gets used, it will be regenerated every time the addon is reinstalled/updated, hence it is advisable to set the secret as per instructions above.

Persistence

The next consideration is the configuration of the persistence for AMP. AMP supports both EBS and EFS for the persistent volumes, allowing amp to retain its state between addon re-installs/updates.

Amazon EFS/EBS

Persistence in AMP is enabled by default but needs to be correctly configured before deploying the addon. As AMP requires EFS or EBS storage for persistence, user needs to first install and configure the relevant CSI driver. Please see the following documentation from AWS explaining how to set up the CSI driver.

After the driver is configured as per above, it is also important to correctly specify the AMP configuration under Optional configuration settings as follows:

store:
  reclaimPolicy: "Retain" # 'Retain' is required to maintain the data after corresponding PVC is deleted
  existingPersistence:
    volumeHandle: "" # id for the volume handle, e.g fs-00ee19c855e28954c
    driver: "" # efs.csi.aws.com / ebs.csi.aws.com
  storageClass:
    provisioner: "" # efs.csi.aws.com / ebs.csi.aws.com
    name: "amp-sc"
  persistToLocalContainerOnly: false

Not that as per above, we should specify the reclaimPolicy to Retain in order to ensure that data is retained after PVC is deleted. We also need to specify the relevant driver, depending on which storage option is chosen, as well as the ID of the storage that should be used to maintain the persistence data

Running with local persistence only (pod storage)

There is also an alternative mode to run AMP without configuring the EFS/EBS persistence. In such case, AMP will use pod storage for its persistence data and therefore data will be only available throughout the pod’s lifetime. Please be aware that it is not recommended to run AMP with only local container persistence, however this option is available to users for quickstart and testing purposes.

In order to enable this option, one can use the following configuration setting:

store:
  persistToLocalContainerOnly: true

Note that is this option is set to true (false by default), the configuration properties specified in the previous section are not taken into account.

Accessing AMP

After AMP is deployed and Pod is in running state, AMP is ready to be used and interacted with. In order to visit AMP UI, the easiest method is to find the load balancer IP address, by executing the following command:

kubectl get service amp-service-lb --namespace cloudsoft-amp -o=jsonpath='{.status.loadBalancer.ingress[0].hostname}'

This will output the IP that can be visited in the browser to access AMP, e.g.: af4b8a81235a6417c893b87a053836f9-850078777.ap-northeast-2.elb.amazonaws.com. Note that in order to access AMP, it is required to log in with usr admin and password as set in the secret set in the previous section.