Creating an additional Kubernetes cluster is optional. Although one Kubernetes cluster is automatically created during the bootstrap process you may prefer to create a new Kubernetes cluster to isolate one set of Elastic Path services from other services. For more information about this architecture, see Multi-Cluster Architecture.
Creating a Additional Kubernetes Cluster
To create an additional cluster using CloudOps for Kubernetes, run the
create-additional-kubernetes-cluster job in Jenkins.
The cluster name is specified as a job parameter and a DNS
CNAME record is created for this cluster with the recordSetName
*.central<clusterName>. This new secondary cluster will share the following resources with the primary cluster that was created using docker-compose:
- Docker container registry
- DNS zone
- AWS account
- Web Application Firewall
- Terraform backend
create-additional-kubernetes-cluster Jenkins job includes the following parameters:
Whether to delete the cluster created by this job. If no cluster has been created, the job can still be run to build the bootstrap Docker image.
When specified, the job will re-build the bootstrap Docker image. This parameter must be set to
true when first running this job.
The name of the Kubernetes cluster to create. This value is also used to determine the DNS records for this cluster. For more information about how DNS and cluster names are used, see URL reference.
(optional) Whether or not to enable New Relic on the newly created Kubernetes cluster. If set to
true you must also specify values for a New Relic License key and New Relic cluster name to use with New Relic.
(optional) The New Relic License Key to use with the newly created cluster.
(optional) The name of the cluster set in New Relic.
Whether or not to enable Prometheus in the cluster.
(optional) The Alert Logic registration key to use. If left blank, Alert Logic is not enabled on this cluster.
The CIDR range that is allowed to access Jenkins and Nexus on the new server.
The branch of CloudOps for Kubernetes to use when running the job. This determines which scripts are used when the job is run.
The Git repository from which to pull CloudOps for Kubernetes code. This determines which scripts are used when the job is run.
Whether to install a Fluentd agent to forward all Pod logs to CloudWatch.
The AWS EC2 instance size to use for the Kubernetes worker nodes.
The minimum number of nodes per node group. By default, three node groups will be created, so a value of
1 will create 3 nodes,
2 will create 6 nodes, and so on.
The CIDR for the VPC that will be created. If you are using multiple connected VPCs or are connecting this VPC with other resources, it is a best practice to ensure the CIDR ranges do not overlap.