Skip to content

Kubernetes to ECS Fargate

Kubernetes to ECS Fargate specification conversion details

The specctl script parses Kubernetes objects and extracts attributes needed for related ECS objects. The tool can convert from either the Kubernetes YAML specification files, or from a Kubernetes cluster. If converting from Kubernetes cluster, your user role will need read access for the Kubernetes resources mentioned below.

  • Kubernetes Deployment object has some attributes that map to ECS service and some that map to ECS task definition object. The deployment related to replica set and settings associated with rolling deployment become part of ECS service definition. For example, replicas become desiredCount, rolling deployment settings maxSurge, maxUnavailable become part of ECS service deploymentConfiguration mapping to attributes maximumPercent, and minimumHealthyPercent respectively (with little bit of manipulation). The deployment template part which captures pod and associated container definitions becomes part of the ECS task definition.

  • Kubernetes Service object maps to ECS service. Currently, this script only handles ClusterIP and Load Balanced service type. The ClusterIP service is simply an ECS service with a CloudMap based DNS entry. For example, my-service.namespace.svc.cluster.local, will remain same in ECS with my-service as the service name and namespace.svc.cluster.local as the domain registry in CloudMap. The Kubernetes load balanced service can maps to ECS service with an NLB or ALB. In practice AWS ALB is more commonly used for load balancing in ECS. So, currently, the Terraform code provisions only AWS ALB. In ECS both the CloudMap registry and ALB (or NLB) have to be created beforehand and appropriate values have to be provided in ECS service definition. That is why we use Terraform to create these resources and provide appropriate attributes to ECS service definition. Another important aspect to note is that in Kubernetes pods and services are independent objects. Kubernetes services use label selectors to identify the pods for a specific service. In ECS service, tasks are created as part of service creation. The tasks belong to service and are not independent, so there is no need for label selectors in ECS.

  • Kubernetes Pod object maps to ECS task and task definition. Container definitions form the bulk of pod specification. Kubernetes and ECS have equivalent attributes for most of the container definition needs such as volumes, environment variables, ports.

  • Kubernetes ConfigMap object maps to AWS SSM Parameter. Just like Kubernetes pods can access the ConfigMap parameters and values, ECS tasks can also access parameters from SSM Parameter Store. The important difference is that the SSM Parameters have to be created separately and the parameter name has to be supplied in ECS task container definitions.

  • Kubernetes Secrets object maps to AWS SSM Parameter Store or AWS Secrets Manager. Just like Kubernetes pods can access the secrets during runtime, ECS tasks can also access secrets from Parameter Store or Secrets Manager securely during runtime. Again the important difference is that secrets need to be stored in either SSM Parameter Store or Secrets Manager and the parameter name/ARN has to be made available in container definition. Currently, the script stores Kubernetes Secrets in SSM Parameter Store as SecureString.

  • Aspects such as envFrom, configMapKeyRef, and secretKeyRef are handled appropriately to ensure the containers in tasks are able to refer and fetch resources from SSM Parameter Store.

  • Kubernetes Ingress object maps to AWS ALB. Most of the conversion logic for ingress objects is to create ALB, listeners, listener rules, and target groups. Once all the ALB related resources are created from parsing Kubernetes ingress, all we need to do is pass the target group(s) to ECS service definition.

  • Kubernetes Service Account can be used to associate AWS IAM roles for pods. In ECS, task IAM roles can be specified in task definition. So the Service Account and any associated IAM roles are added to the ECS task definition.

  • When using Kubernetes on AWS, you may also be using Pod Security Groups through vpcresources.k8s.aws/v1beta1/securitygrouppolicies resource. The tool will extract these and associate with ECS tasks. However, most likely, your ECS Fargate networking environment will be different from Kubernetes environment. It is best to handle the security groups in the Terraform module associated with ECS Fargate service definitions.