Eksctl: Generating fully private cluster with managed node groups

Created on 15 Dec 2020  路  1Comment  路  Source: weaveworks/eksctl

Hey guys
I'm trying to create a fully private cluster with a managed node groups but i can't manage to get it working
Here's the yaml file i use with the command eksctl create cluster -f <filename>.yaml

apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
  name: test-cluster
  region: <my-region-1>
privateCluster:
  enabled: true
  additionalEndpointServices:
  - "autoscaling"
  - "cloudformation"
  - "logs"
vpc:
  id: <my-vpc-id>
  subnets:
    private:
      <az-1>: { id: <my-subnet-1-id> }
      <az-2>: { id: <my-subnet-2-id> }
managedNodeGroups:
  - name: test-nodegroup
    instanceType: t3.medium
    desiredCapacity: 2
    volumeSize: 20
    privateNetworking: true

But i get the error:

One or more Amazon EC2 Subnets of [<my-subnet-1-id>, <my-subnet-2-id>] for node group test-nodegroup does not automatically assign public IP addresses to instances launched into it. If you want your instances to be assigned a public IP address, then you need to enable auto-assign public IP address for the subnet. See IP addressing in VPC guide: https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html#subnet-public-ip

Or i already know that i disabled this option since i want this cluster to be fully private
Do you have any idea why i can't generate my managed node group ?
Thanks guys! 馃槂
(Also, i managed to generate a self-managed node group that seemed to work well, but i'd like to use a managed node group)

Versions

eksctl==0.34.0
kubectl==Client Version: version.Info{Major:"1", Minor:"18+", GitVersion:"v1.18.9-eks-d1db3c", GitCommit:"d1db3c46e55f95d6a7d3e5578689371318f95ff9", GitTreeState:"clean", BuildDate:"2020-10-20T22:21:03Z", GoVersion:"go1.13.15", Compiler:"gc", Platform:"windows/amd64"}
Unable to connect to the server: dial tcp [::1]:8080: connectex: No connection could be made because the target machine actively refused it.

Thanks for your help !

kinbug prioritimportant-soon

Most helpful comment

For others, the solution is to ensure that the subnets are indeed private by making sure they do not include an internet gateway (IGW) in their route table.

>All comments

For others, the solution is to ensure that the subnets are indeed private by making sure they do not include an internet gateway (IGW) in their route table.

Was this page helpful?
0 / 5 - 0 ratings