Kubernetes by default

[BrianHicks]

• Installs cleanly on a fresh build of most recent master branch
• Upgrades cleanly from the most recent release
• Updates documentation relevant to the changes

Add Kubernetes by default, incorporating many of @Zogg's changes. Docs are at 3af143e

Successor to #1302, obsoletes #1121 (since we no longer have to customize those variables)

[BrianHicks]

Just rebased onto lastest master.

[langston-barrett]

After rebasing onto #1296, this upgrades cleanly from 1.0.3 👍

[centos@ip-10-1-1-148 ~]$ kubectl get pods  
NAME                                  READY     STATUS    RESTARTS   AGE
fluentd-elasticsearch-ip-10-1-1-148   1/1       Running   0          26m
[...]
kube-apiserver-ip-10-1-1-148          1/1       Running   0          25m
[...]
kube-podmaster-ip-10-1-1-148          2/2       Running   0          26m
[...]
kube-proxy-ip-10-1-1-148              1/1       Running   0          25m
[...]

[centos@ip-10-1-1-148 ~]$ kubectl get services
NAME                    CLUSTER-IP       EXTERNAL-IP   PORT(S)             AGE
elasticsearch-logging   10.254.54.16     <none>        9200/TCP            27m
heapster                10.254.175.15    <none>        80/TCP              27m
kibana-logging          10.254.207.207   <none>        5601/TCP            27m
kube-ui                 10.254.92.166    <none>        80/TCP              27m
monitoring-grafana      10.254.248.89    <none>        80/TCP              27m
monitoring-influxdb     10.254.253.76    <none>        8083/TCP,8086/TCP   27m

[langston-barrett]

@BrianHicks is this ready to merge now that we know it upgrades cleanly?

[BrianHicks]

I thought it was, but it looks like Kubelet is killing the logstash and nginx-consul containers on the box when it starts up. This leads to an unhealthy status in Consul (because of the dsitributive check.)

I think it's going to require a few changes to nginx-consul and logstash (specifically to restart them when they fail), which may fall outside the scope of this PR. @ryane do you have a preference for where that should go?

[BrianHicks]

I added it in 48d0058, but we can revert that commit.

[ryane]

I suppose we could move it to a new PR but I don't have a problem with leaving it in this one...

[BrianHicks]

Cool, then it's ready to merge

On Apr 6, 2016, at 5:37 PM, Ryan Eschinger [email protected] wrote:

I suppose we could move it to a new PR but I don't have a problem with leaving it in this one...

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub