Operator Based Installation for AMCOP 2.1

Updated: Aug 12, 2021

This blog is focused on the installation of AMCOP Release 2.1 on any existing Kubernetes deployment using AMCOP Operator. See demo here.


A Kubernetes cluster, which will host AMCOP deployment. AMCOP is validated to work with a minimal single node all-in-one cluster with following hardware configuration

● 8 vCPUs, 32 GB RAM and 80 GB SSD

Storage Class:

AMCOP requires usage of persistent volumes to manage stateful information. These persistent volumes are required to be provided by a default storage class configured with a persistent volume provisioner, more details are available at kubernetes storage class

Check if there is already a default storage class available in your kubernetes cluster

kubectl get storageclass

If you’re using public cloud, chances are you’ll already be having a default storage class.

Otherwise for the deployment you can proceed with the following to create your own storage class with persistent volume provisioner, where persistent volumes will be backed by local SSD.

kubectl apply -f https://aarna-networks.gitlab.io/amcop-deployment/amcop-k8s-operator/storage.yaml

AMCOP Operator:

Once availability of storage class is ensured, we will roll out AMCOP Operator itself

kubectl apply -f https://aarna-networks.gitlab.io/amcop-deployment/amcop-k8s-operator/v2.1.0/operator.yaml

This will deploy the AMCOP Operator deployment along with necessary constructs for RBAC and CRD. This AMCOP Operator deployment carries the intelligence about the components required for AMCOP Release 2.1, dependencies between them and information about ordered roll out of these components.

Additionally, it introduces the Custom Resource Definition (CRD) for defining properties of AMCOP deployment

● Enabling disabling certain components

● Choosing specific storage class instead of the default

● Etc.

AMCOP Custom Resource:

Once AMCOP operator deployment is available, you can now use the Custom Resource of type Installer to customize AMCOP deployment.

apiVersion: amcop.aarnanetworks.com/v1alpha1

kind: Installer


name: default




storageClass: ""

debug: enable

cds: enable

In Most of the cases, you will not require to change these parameters and can safely execute creation of Custom Resource using following

kubectl apply -f https://aarna-networks.gitlab.io/amcop-deployment/amcop-k8s-operator/v2.1.0/default.yaml

Upon creation of this Custom Resource, AMCOP Operator starts deployment of various AMCOP components in a staged manner. Progress of deployment can be monitored by watching kubernetes pods in amcop-system namespace or by watching the status of Custom Resource itself.

kubectl get installer.amcop

Over time, when all the components of AMCOP are rolled out successfully. The status of deployment will change from “RollingOut” to “Deployed”, beyond this you can then start using AMCOP.

See a recording of the technical meetup that covered this topic in more depth along with a hands-on demo. If you would like to replicate any of this work in your environment, please contact us.

Interested in an AMCOP presentation and demo meeting? Let us know at info@aarnanetworks.com and we can schedule it.

131 views0 comments