From cc070996878088ea7c5ed505dd14f7a602fffc0d Mon Sep 17 00:00:00 2001 From: Dalton Hubble Date: Thu, 17 Nov 2016 00:46:14 -0800 Subject: [PATCH] examples: Bump self-hosted Kubernetes to v1.4.6 --- CHANGES.md | 2 +- Documentation/bootkube.md | 11 +++++++---- examples/ignition/bootkube-controller.yaml | 4 ++-- examples/ignition/bootkube-worker.yaml | 2 +- 4 files changed, 11 insertions(+), 8 deletions(-) diff --git a/CHANGES.md b/CHANGES.md index 59cebd24..bd41b057 100644 --- a/CHANGES.md +++ b/CHANGES.md @@ -6,7 +6,7 @@ * Upgrade Kubernetes v1.4.6 (static manifest) example clusters * Upgrade Kubernetes v1.4.6 (rktnetes) example clusters -* Upgrade Kubernetes v1.4.3 (self-hosted) example cluster +* Upgrade Kubernetes v1.4.6 (self-hosted) example cluster ## v0.4.1 (2016-10-17) diff --git a/Documentation/bootkube.md b/Documentation/bootkube.md index e5f4205f..902a132b 100644 --- a/Documentation/bootkube.md +++ b/Documentation/bootkube.md @@ -1,7 +1,7 @@ # Self-Hosted Kubernetes -The self-hosted Kubernetes example provisions a 3 node "self-hosted" Kubernetes v1.4.3 cluster. On-host kubelets wait for an apiserver to become reachable, then yield to kubelet pods scheduled via daemonset. [bootkube](https://github.com/kubernetes-incubator/bootkube) is run on any controller to bootstrap a temporary apiserver which schedules control plane components as pods before exiting. An etcd cluster backs Kubernetes and coordinates CoreOS auto-updates (enabled for disk installs). +The self-hosted Kubernetes example provisions a 3 node "self-hosted" Kubernetes v1.4.6 cluster. On-host kubelets wait for an apiserver to become reachable, then yield to kubelet pods scheduled via daemonset. [bootkube](https://github.com/kubernetes-incubator/bootkube) is run on any controller to bootstrap a temporary apiserver which schedules control plane components as pods before exiting. An etcd cluster backs Kubernetes and coordinates CoreOS auto-updates (enabled for disk installs). ## Requirements @@ -13,6 +13,9 @@ Ensure that you've gone through the [bootcfg with rkt](getting-started-rkt.md) o Build and install the [fork of bootkube](https://github.com/dghubble/bootkube), which supports DNS names. + $ bootkube version + Version: bd5a87af28f84898272519894b09d16c5e5df441 + ## Examples The [examples](../examples) statically assign IP addresses to libvirt client VMs created by `scripts/libvirt`. The examples can be used for physical machines if you update the MAC addresses. See [network setup](network-setup.md) and [deployment](deployment.md). @@ -38,7 +41,7 @@ Add your SSH public key to each machine group definition [as shown](../examples/ Use the `bootkube` tool to render Kubernetes manifests and credentials into an `--asset-dir`. Later, `bootkube` will schedule these manifests during bootstrapping and the credentials will be used to access your cluster. # If running with docker, use 172.17.0.21 instead of 172.15.0.21 - bootkube render --asset-dir=assets --api-servers=https://172.15.0.21:443 --etcd-servers=http://node1.example.com:2379 --api-server-alt-names=DNS=node1.example.com,IP=172.15.0.21 + bootkube render --asset-dir=assets --api-servers=https://172.15.0.21:443 --api-server-alt-names=DNS=node1.example.com,IP=172.15.0.21 ## Containers @@ -48,7 +51,7 @@ Client machines should boot and provision themselves. Local client VMs should ne ## bootkube -We're ready to use [bootkube](https://github.com/kubernetes-incubator/bootkube) to create a temporary control plane and bootstrap a self-hosted Kubernetes cluster. +We're ready to use bootkube to create a temporary control plane and bootstrap a self-hosted Kubernetes cluster. Secure copy the `kubeconfig` to `/etc/kubernetes/kubeconfig` on **every** node (i.e. 172.15.0.21-23 for metal0 or 172.17.0.21-23 for docker0). @@ -70,7 +73,7 @@ Watch the temporary control plane logs until the scheduled kubelet takes over in [ 299.241993] bootkube[5]: Pod Status: kube-controller-manager Running [ 299.311743] bootkube[5]: All self-hosted control plane components successfully started -You may cleanup the `bootkube` assets on the node, but you should keep the copy on your laptop. It contains a `kubeconfig` and may need to be re-used if the last apiserver were to fail and bootstrapping were needed. +You may cleanup the `bootkube` assets on the node, but you should keep the copy on your laptop. It contains a `kubeconfig` used to access the cluster. ## Verify diff --git a/examples/ignition/bootkube-controller.yaml b/examples/ignition/bootkube-controller.yaml index 32c7fa43..c560d6c5 100644 --- a/examples/ignition/bootkube-controller.yaml +++ b/examples/ignition/bootkube-controller.yaml @@ -97,7 +97,7 @@ storage: contents: inline: | KUBELET_ACI=quay.io/coreos/hyperkube - KUBELET_VERSION=v1.4.3_coreos.0 + KUBELET_VERSION=v1.4.6_coreos.0 - path: /etc/hostname filesystem: root mode: 0644 @@ -122,7 +122,7 @@ storage: # Wrapper for bootkube start set -e BOOTKUBE_ACI="${BOOTKUBE_ACI:-quay.io/coreos/bootkube}" - BOOTKUBE_VERSION="${BOOTKUBE_VERSION:-v0.2.2}" + BOOTKUBE_VERSION="${BOOTKUBE_VERSION:-v0.2.5}" BOOTKUBE_ASSETS="${BOOTKUBE_ASSETS:-/home/core/assets}" exec /usr/bin/rkt run \ --trust-keys-from-https \ diff --git a/examples/ignition/bootkube-worker.yaml b/examples/ignition/bootkube-worker.yaml index 30e4c80a..c7dc2029 100644 --- a/examples/ignition/bootkube-worker.yaml +++ b/examples/ignition/bootkube-worker.yaml @@ -87,7 +87,7 @@ storage: contents: inline: | KUBELET_ACI=quay.io/coreos/hyperkube - KUBELET_VERSION=v1.4.3_coreos.0 + KUBELET_VERSION=v1.4.6_coreos.0 - path: /etc/hostname filesystem: root mode: 0644