Create an EKS stack

How to create an EKS stack with the Webscale API.

Follow these steps to create an EKS stack and prepare it for Helm deployments.

Prerequisites

Access key: An access key for the account, created in the Access keys section of your Profile page. See Webscale service users for a key that belongs to automation.
AWS provider: An AWS provider in the account. See Working with Providers .
Environment: An environment to hold the stack. See Create an environment .
Network: Subnet IDs when you bring a network you already have. A new network does not need them. See Network topology .
Name: A name for the stack, which becomes the name of the EKS cluster. It must be unique within the environment and among the stacks that share your AWS account. Use 3 to 30 characters from a-z, 0-9, and -, starting with a lowercase letter or a digit.

Every request goes to https://api.webscale.com and carries the access key:

ACCESS_KEY=<my-access-key>

1. Find the environment

curl -s "https://api.webscale.com/v2/environments" \
  -H "Authorization: Bearer $ACCESS_KEY"

[
  {
    "href": "/v2/environments/3ps666yxcanq",
    "name": "Production",
    ...
  }
]

Note the href of the environment the stack belongs to. An empty list means the account has no environment. See Create an environment .

2. Find the AWS service

Saving an AWS provider creates the service that lets a stack build in your AWS account. The service takes the name of the provider.

curl -s "https://api.webscale.com/v2/services" \
  -H "Authorization: Bearer $ACCESS_KEY"

[
  {
    "href": "/v2/services/u91dkrui39cj",
    "category": "vm",
    "type": "aws",
    "name": "AWS production"
  },
  {
    "href": "/v2/services/2tk18ei6581v",
    "category": "cloud",
    "type": "aws",
    "name": "AWS production",
    ...
  }
]

Note the href of the entry whose category is vm and whose type is aws.

3. Create the stack

The stack has two network modes, and each takes a different request body. Save the one you want as stack.json and fill in your own environment, service, name, and network values. See Network topology for the differences between the modes and Variables for the other variables.

Either body can also set api_ingress_cidrs in variables. Add the networks you connect from, so tools such as kubectl or Helm reach the EKS cluster’s public API endpoint. Only the Webscale Control Plane reaches the endpoint otherwise. See Cluster access .

Existing network

The stack puts the nodes and the EKS cluster’s API in subnets you already have, all in one VPC. It opens the NodePort range to that VPC’s primary CIDR block and nothing else. Add any other network to service_ingress_cidrs.

{
  "type": "eks",
  "environment": "/v2/environments/3ps666yxcanq",
  "service": "/v2/services/u91dkrui39cj",
  "name": "production-eks",
  "variables": {
    "region": "us-east-1",
    "node_subnets": ["subnet-0123456789abcdef0", "subnet-0fedcba9876543210"],
    "api_subnets": ["subnet-0aaaa1111bbbb2222", "subnet-0cccc3333dddd4444"]
  }
}

New network

The stack creates a VPC for the nodes and the EKS cluster’s API. It builds a public and a private subnet in each of two zones, and public_nodes puts the nodes on the public pair. The proxies reach public nodes from their public addresses, which is why service_ingress_cidrs holds 0.0.0.0/0. The NodePort range 30000-32767 is then open to any address.

{
  "type": "eks",
  "environment": "/v2/environments/3ps666yxcanq",
  "service": "/v2/services/u91dkrui39cj",
  "name": "production-eks",
  "variables": {
    "region": "us-east-1",
    "public_nodes": true,
    "service_ingress_cidrs": ["0.0.0.0/0"]
  }
}

Post the stack

curl -X POST "https://api.webscale.com/v2/stacks" \
  -H "Authorization: Bearer $ACCESS_KEY" \
  -H "Content-Type: application/json" \
  --data @stack.json

{
  "href": "/v2/stacks/imawpe1lq6lc",
  "name": "production-eks",
  "type": "eks",
  "state": "pending",
  ...
}

Note the href of the stack.

4. Monitor stack provisioning

The Task monitor shows the log of the stack as it builds. The first create takes about 20 minutes.

Read the state of the stack:

curl -s "https://api.webscale.com/v2/stacks/imawpe1lq6lc" \
  -H "Authorization: Bearer $ACCESS_KEY"

The state runs from pending to synchronizing to synchronized. Repeat the request until it reaches synchronized. A state of sync-failed means the stack stopped, and the log names the reason.

5. Deploy to the EKS cluster

The EKS cluster is ready for deployments once the stack reaches synchronized. It has the same name as the stack, and the end of the log gives that name as the kubernetes_cluster_name output. Enable Use for Kubernetes on the AWS provider and enter the name in Cluster Name. The provider’s region must be the region of the EKS cluster. See Working with Providers for more information.

Then create a Kubernetes cluster with a Helm blueprint. See Kubernetes Clusters .