Skip to content

Requirements

Note

See the Self Hosted Controller v1.24 for the latest process.

For organizations who need to maintain control over their environment, they can run the Self Hosted Controller in an Amazon Web Service Elastic Kubernetes Service (AWS EKS). While organizations might use cloud services, like AWS, their organization administrators will be the only ones with access to their Self Hosted Controller.

With the Self Hosted Controller, the organization is responsible for all aspects of the controller. This includes deployment, maintenance, backup procedures, and troubleshooting issues. For organizations that would prefer a SaaS model, there is a service available for that.

Here are the pre-requisites for installation of the self hosted Controller in Amazon EKS environments.

Note

If you use Terraform and need reference examples, contact Support at support@rafay.co.

Infrastructure

The AWS EKS requirements for installing the self hosted controller are as follows.

  • Amazon Elastic Kubernetes Service (EKS)
  • Virtual Private Cloud (VPC), Subnets, and NAT Gateway
  • Relational Database Service (RDS)
  • Amazon OpenSearch Service
  • Kinesis Firehose
  • S3 Buckets
  • Route 53 (DNS)
  • Amazon Managed Prometheus (AMP)
  • Amazon Managed Grafana (AMG)
  • Elastic File System (EFS)
  • Simple Notification Service (SNS)
  • Karpenter
  • Key Management Service (KMS)
  • IAM Roles and Policies

DNS Records

Installation of the self hosted controller requires DNS records as mentioned below. In the below examples, replace company.example.com with the desired domain. DNS records for the wildcard FQDN should point to the controller nodes’ IP addresses.

The following is an example of a wildcard FQDN.

*.company.example.com

The following individual records should be allowed. For AWS Cloud DNS, add these as Records.

  • Create the following DNS records with an "A" record and a "TXT" record.
ui.<company.example.com>
backend.<company.example.com>
  • The above DNS records should have their "A" record pointing to any sample address (example: 0.0.0.0).
  • The above DNS records should have their "TXT" record with the following value:
heritage=external-dns,external-dns/owner=default,external-dns/resource=service/istio-system/istio-ingressgateway-https
  • Create the following DNS records with a CNAME value of ui.<company.example.com>.
console.<company.example.com>
fluentd-aggr.<company.example.com>
grafana.<company.example.com>
kibana.<company.example.com>
ops-console.<company.example.com>
prometheus.<company.example.com>
  • Create the following DNS records with a CNAME value of backend.<company.example.com>.
*.cdrelay.<company.example.com>
*.core-connector.<company.example.com>
*.core.<company.example.com>
*.connector.infrarelay.<company.example.com>
*.kubeapi-proxy.<company.example.com>
peering.<company.example.com>
rcr.<company.example.com>
regauth.<company.example.com>
*.user.infrarelay.<company.example.com>
*.user.<company.example.com>

Logo (optional)

To change the logo displayed in the console, the company logo must be less than 600 KB and in the PNG format. Use this for white labeling and branding purposes.

X.509 Certificates (Optional)

The controller uses TLS for secure communication. As a result, X.509 certificates are required to secure all endpoints. Customers are expected to provide a trusted CA signed wildcard certificate for the target DNS (e.g. *.company.example.com)

For non-production or internal to organization scenarios, if signed certificates are not available, the controller can generate self-signed certificates automatically. This can be achieved by setting the generate-self-signed-certs key to true in config.yaml during installation.

generate-self-signed-certs: true

Email Addresses

The installation also requires below email addresses.

  • An email address for super user authentication to the controller’s admin
  • An email address for receiving support emails from the controller
  • An email address for receiving alerts and notifications (Optional)