I'd like to create a cluster with 3 master nodes and 3 workers in existing vpc with existing private subnets. All nodes, master and workers should be in the same subnet. The reason? It's not reusing NATgateways as far as I can see, so the first cluster provisioning going to hit all the sort of aws limits.
Is it possible to do with current version?
Also, what's the reason 3 ASG being created?
Actually 4! 1 per master plus one for 3 workers. Makes no sense.
topology:
dns:
type: Public
masters: private
nodes: private
And yet it creates a public loadbalancer for master :(
Our design assumes that we need to house a master in on az, with that assumption we need a asg per master, one for a bastion, and another for the nodes. With 1.5 you have fine grain control of this. You can edit the instance groups to your hearts content.
We have noticed about the subnet, and that is an enhancement that we would like to see.
What would you like?
Actually, subnets question is solved.
I simply added in the config.yaml subnet ids, both for private (workers) and public (masters).
It seems that having API exposed is standard practice for k8s, makes lots of sense now to me.
Still not clear why 1 ASG per master, though. ASG can manage instances perfectly fine in multiple azs, it's a standard practice.
1 asg per az guarantees 1 node per region. Is there a way to ensure that the masters are spread across each az all the time?
Of course, that's what ASGs are for!
http://docs.aws.amazon.com/autoscaling/latest/userguide/auto-scaling-benefits.html#arch-AutoScalingMultiAZ
@justinsb can you comment here? I think we created 3 asg for some edge cases that I do not recall.
The edge case is probably called 'kubernetes"
Lol
Probably called etcd and ebs volumes.
I must be missing some implementation details, but what's special about those volumes?
Etcd is super critical and we should attempt to keep the same volumes in the same az, through az failures. Need @justinsb to chime in on this one though.
We use 3 single-AZ ASGs so we get a stronger guarantee from AWS. We don't benefit from having multiple master instances in the same AZ because they must each mount an EBS volume. Further, some people have asked to have 2 masters in the same zone, and the 3rd in another. I don't know how _that_ would be expressed in one ASG.
But... I actually think our model is rich enough to express a single master InstanceGroup in 3 AZs. We probably have some sanity checks, but it might be interesting to turn them off and see what happens. How is your go code?
Also, a note on tone: in the kubernetes community, we strive to be technical and polite. This phrasing here could have been more polite. But much more problematically, the issue was not expressed technically, and so it's not clear how we ever fix & close this issue i.e. what are the exit criteria. I'm going to change the title to what I believe the outstanding issue to be. Please feel free to open more issues, but focused issues with technical criteria are appreciated, even if that means opening more issues. For example, I'm not sure whether it is possible to have a single NAT gateway with multiple AZs, and I don't want that to be lost, so I'm going to open an issue for that.
Thanks!
More on only having 1 subnet https://github.com/kubernetes/kops/issues/1368
Will point the other issue as well.
I think it should be set something like this in aws:
Also "instance group" is used in AWS for EMR (managed hadoop) service. It can be named simply as autoscaling group, so aws users won't get confused.
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Prevent issues from auto-closing with an /lifecycle frozen comment.
If this issue is safe to close now please do so with /close.
Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle stale
Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.
Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle rotten
/remove-lifecycle stale
Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close
Most helpful comment
Also, a note on tone: in the kubernetes community, we strive to be technical and polite. This phrasing here could have been more polite. But much more problematically, the issue was not expressed technically, and so it's not clear how we ever fix & close this issue i.e. what are the exit criteria. I'm going to change the title to what I believe the outstanding issue to be. Please feel free to open more issues, but focused issues with technical criteria are appreciated, even if that means opening more issues. For example, I'm not sure whether it is possible to have a single NAT gateway with multiple AZs, and I don't want that to be lost, so I'm going to open an issue for that.
Thanks!