Hi,

FYI, we have most of what you've mentioned in our roadmap 
<https://github.com/coreos/coreos-kubernetes/issues/340> and some of them 
already have working PRs:

   - Discrete etcd cluster 
   <https://github.com/coreos/coreos-kubernetes/pull/544> (3+ dedicated 
   etcd nodes)
   - HA control plane <https://github.com/coreos/coreos-kubernetes/pull/596> 
(multiple 
   EC2 instances and an ELB load balancer, a separate ASG for the 
   master=controller)
   - Cluster upgrades <https://github.com/coreos/coreos-kubernetes/pull/608>

If you'd like to apply the cluster-autoscaler from kubernetes/contrib 
<https://github.com/kubernetes/contrib/tree/master/cluster-autoscaler> for 
node auto-scaling, you would be interested in the issue I've reported 
<https://github.com/coreos/coreos-kubernetes/issues/667>.
Regarding the single CF template thing, I suppose splitting templates would 
be an implication of that issue.

Also, if you'd like to apply AWS native node auto-scaling based on 
CloudWatch alarms, especially when automatic down-scaling, you would be 
interested in this PR <https://github.com/coreos/coreos-kubernetes/pull/465> to 
avoid small downtime while terminating nodes.

Yusuke

2016年10月14日金曜日 6時58分34秒 UTC+9 Henning Jacobs:
>
> Brief answer why we are not using kube-aws directly right now:
>
>    - It uses a single master EC2 instance --- we want to have an ASG for 
>    the master nodes (probably running with size 1 usually, but having the 
>    option for more, e.g. during updates/migrations etc)
>    - It runs etcd on the master --- we want to run etcd separately 
>    (currently we use our own 3 node etcd appliance with DNS discovery (SRV 
>    records))
>    - It does not configure an ELB for the API server --- we want to 
>    terminate SSL at ELB in order to leverage existing SSL infrastructure 
>    (including ACM)
>    - It uses a single CF template --- we want to split into at least 3 CF 
>    templates to facilitate future upgrades and extra node pools (one for etcd 
>    cluster, one for master and one for worker nodes)
>
> We therefore adapted the generated Cloud Formation to YAML and are using 
> our own Senza Cloud Formation tool 
> <https://github.com/zalando-stups/senza> for deployment (it's not doing 
> any magic, but e.g. makes ELB+DNS config easy).
>
> I'll put our current (hacked) config into some public repo tomorrow...
>
> - Henning
>
>
> 2016-10-13 21:23 GMT+02:00 Brandon Philips <brandon...@coreos.com 
> <javascript:>>:
>
>> On Thu, Oct 13, 2016 at 9:28 AM Henning Jacobs <henning...@zalando.de 
>> <javascript:>> wrote:
>>
>>>
>>>    - 
>>>    
>>>    We currently deploy test clusters with Cloud Formation (adapted from 
>>>    kube-aws 
>>>    <https://github.com/coreos/coreos-kubernetes/tree/master/multi-node/aws>
>>>    )
>>>    
>>>
>> Why couldn't you use kube-aws directly? What would your ideal tool do 
>> differently?
>>
>> Thanks,
>>
>> Brandon 
>>
>> -- 
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "Kubernetes user discussion and Q&A" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/kubernetes-users/WRsVjG7vc9Y/unsubscribe
>> .
>> To unsubscribe from this group and all its topics, send an email to 
>> kubernetes-use...@googlegroups.com <javascript:>.
>> To post to this group, send email to kubernet...@googlegroups.com 
>> <javascript:>.
>> Visit this group at https://groups.google.com/group/kubernetes-users.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Kubernetes user discussion and Q&A" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to kubernetes-users+unsubscr...@googlegroups.com.
To post to this group, send email to kubernetes-users@googlegroups.com.
Visit this group at https://groups.google.com/group/kubernetes-users.
For more options, visit https://groups.google.com/d/optout.

Reply via email to