Introduction
Thank you for clicking through to my arcticle. I've been a DevOps engineer for 2 years in dev-team of 7 engineers.
My name is MINSEOK, LEE, but I use Unchaptered as an alias on the interenet. So, you can call me anythings "MINSEOK, LEE" or "Unchaptered" to ask something.
Topic
In this article, I'll cover this followings:
Type 1 - Self Managed Nodes
Type 2 - Managed Node Groups
Type 3 - Fargate
What is the Kubernetes Node?
The kubernetes node means machine execute containerized application.
Each nodes have these elements.
container runtime | software to have role of container execution
kubelet | health check about pod connected by each containers
kube-proxy | maintains network rules that allow communication to your pods.
You can choose each type to execute node.
Self Managed Nodes
Managed Node Groups
Fargate (serverless compute)
Self Managed Nodes
AWS EKS (Docs) | EKS Self Managed Nodes
Self Managed Nodes is the EC2 instances directly managed by engineer. It allow to add into cluster. The user have a responsibility about oepration and security.
Managed Node Groups
AWS EKS (Docs) | EKS Managed Node Groups
Managed Node Group is the EC2 Instance Group managed by Amazon EKS. The user can execute container application without zero administration about containers of server or cluster.
Fargate
It inherits all the basic features of Fargate.
The comparison of 3 types.
AWS EKS (Docs) | EKS Compute Userguide
Criteria | Self Managed Nodes | Managed Node Groups | Fargate |
|---|---|---|---|
Deployment | |||
Can be deployed to | Yes | No | No |
Can be deployed to | Yes | No | No |
Container with OS | |||
Can run containers | Yes | Yes | No |
Can run containers | Yes | Yes | Yes |
Workloads | |||
Can run workloads | Yes | Yes | No |
Can run workloads | Yes | Yes | No |
Can run AWS | Yes | Yes | No |
Isolation and Sharing | |||
Pods share a kernel runtime env with other pods | Yes | Yes | No |
Pods share CPU, | Yes | Yes | No |
Pods can use more | No | ||
Management | |||
Must deploy and | Yes | Yes | No |
Must secure, maintain and patch | Yes | Yes | No |
Can provide bootstrap at deployment of a node, such as extra kubelet args. | Yes | No | |
Can assign IP addresses to Pods from a different | Yes | No | |
Can SSH into node | Yes | Yes | No |
Can deploy your own custom AMI to nodes | Yes | Yes | No |
Can deploy your own custom CNI to nodes | Yes | Yes | No |
Must update node AMI on your own | Yes | No | |
Must update node kubernetes version | Yes | No | |
Storage | |||
Can use EBS with Pods | Yes | Yes | No |
Can use EFS with Pods | Yes | Yes | Yes |
Can use FSx for Lustre with Pods | Yes | Yes | No |
Networking | |||
Can use NLB for services | Yes | Yes | Yes |
Pods can run in a public subnet | Yes | Yes | No |
Can assign different VPC security groups to individual pods | Yes | Yes | Yes |
Can run kubernetes Daemonsets | Yes | Yes | No |
Spport HostPort and HostNetwork in the Pod manifest | Yes | Yes | No |
AWS Region Availability | Yes | Yes | No |
Can run containers on Amazon EC2 dedicated hosts | Yes | Yes | No |
Pricing | |||
Conclusion
In many situations, Managed Node Groups seems to be the easiest way to start and operate. Only if you have some specialized requirements, I think you'ld choose Self Managed Node or Fargate type.
