Comments (9)
I think that managed nodes will be out of scope for now... we can in-scope them again when they support more configurability / and or custom amis
from terraform-aws-eks.
AMI
Amazon EKS ami | Our Own Custom ami | Notes | ||
---|---|---|---|---|
Pro | Con | Pro | Con | |
Supported by AWS | Supported by us | |||
Limited to Docker | Supports other CRI runtimes (e.g. containerd, cri-o etc) | |||
GPU Support out of the box | Clearly GPU support is possible in our own image, but it would be another thing to maintain | |||
Not able to support our standard SSH infra | Image would be flexible to support our sshd config | Perhaps we don't have to support ssh access to nodes, it would be more secure to have this disabled | ||
Amazon Linux 🤷♀ | Anything | I don't think this is that important... especially if we don't manage configuring the host ourselves | ||
Managed Node Groups |
from terraform-aws-eks.
I am erring towards the Amazon AMI.
So long as we are happy with:
- Docker as the container runtime
- No general ssh access to nodes
It reduces maintenance, and means that there will be little difference between managed node groups and standard ASG groups ...
from terraform-aws-eks.
+1 for not having to maintain GPU-ready AMI 👍
from terraform-aws-eks.
+1 for not having to maintain GPU-ready AMI 👍
To be clear no-one has tested if it works for our needs ... I have no idea about the complexity of using it... so 🤷♂
from terraform-aws-eks.
I say let's stick with Amazon EKS AMI until we have a concrete use-case or performance/reliability optimization we need to tackle that doesn't fit in it.
from terraform-aws-eks.
What should the API look like for defining node groups?
The two ideas I have are:
Single module that manages cluster and groups ... likely a lot of complexity on the inside!
module "production-eks-cluster" {
source = "cookpad/eks/aws"
version = "1.0.1"
name = "production"
... some other config ...
node_groups = [
{
type = "managed"
instance_type = "t3.medium"
},
{
type = "fargate"
selector = {
namespace = "example"
}
}
]
}
vs
The top level module sets up the cluster ... nodes are added by reference to a config object in the output
of the cluster module...
Implementation is much simpler... but usage is arguably a bit more messy ... but perhaps simpler to understand.
module "production-eks-cluster" {
source = "cookpad/eks/aws/"
version = "1.0.1"
name = "production"
... some other config ...
}
module "production-eks-node-group" {
source = "cookpad/eks/aws//managed_node_group"
version = "1.0.1"
cluster = module.production-eks-cluster.cluster
instance_type = "t3.medium"
... some other config ...
}
module "production-eks-fargate-profile" {
source = "cookpad/eks/aws//fargate_profile"
version = "1.0.1"
cluster = module.production-eks-cluster.cluster
... some other config ...
}
I am erring on the side of the second one ... @ettiee do you have a view since you actually used https://ghe.ckpd.co/infra/eks-terraform the most of anyone?
from terraform-aws-eks.
In the past I've used the second approach with good results. It is simpler to understand and more flexible.
You can then wrap both modules on another module or on a single configuration for defining a concrete instance of as cluster + nodes, which mitigates your concern I think.
from terraform-aws-eks.
ASG node group is working fine...
Fargate is a nice to have at this point: #34
from terraform-aws-eks.
Related Issues (20)
- Minimum possible config does not work as written HOT 2
- Default behaviour of endpoint_public_access is not a secure default HOT 5
- Manage vpc-cni, coredns and kube-proxy via eks addons
- move to setup-terraform github action
- Quieten drift detection in plans for desired_capacity attribute of ASGs under terraform 0.15.0 and higher HOT 6
- Upgrade to terraform 1.x HOT 1
- Upgrade cluster autoscaler
- Default alarms
- Possible regression of #209 in 1.20 HOT 1
- InvalidParameterException when endpoint_public_access is true endpoint_public_access_cidrs is not set HOT 1
- Document how to use the module when public access to the cluster endpoint is disabled (the default) HOT 2
- Upgrade module/components for eks 1.21 HOT 1
- Add contributing guide
- Add gpu support for bottlerocket HOT 1
- Replace deprecated hashicorp/template provider HOT 2
- Upgrade AWS Terraform Provider to 4.12.0
- Remove the usage of `template_cloudinit_config`
- Add GPU support for bottlerocket HOT 1
- Update documentation for 1.25
- Allow aws provider higher than 5.0 with 1.24.x
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from terraform-aws-eks.