3

Docker CoreOS Cluster in less than 10 Minutes


Install a Docker Cluster in less than 10 Minutes

This blog shows, how a Docker CoreOS cluster can be set up in ~10 minutes (dependent on your Internet speed), excluding the time to install Vagrant, Virtualbox and git.

2015.07.21-17_25_32-hc_001

In order to speed up the installation process of a CoreOS cluster, I have created a fork of the coreos-vagrant git repository. With that repository fork, a CoreOS cluster with 3 cluster nodes can be up and running and discovered in less than 10 minutes, if the prerequisites are met.

Prerequisites:

  • Vagrant, Virtualbox and git are assumed to be installed.
  • Unix tools like dos2unix is assumed to be installed, but any tool to convert the files is possible.

The procedure is tested on Windows, but should work on Linux as well. Please report any issues on https://github.com/oveits/coreos-vagrant or add a note on this blog.

1. Download Vagrant file like follows:
a) specify the HTTP proxy, if needed
(adapt IP address:Port to match your case:; use “export” instead of “SET” on Linux systems):

SET HTTP_PROXY=http://<your_proxy_IP>:<your_proxy_port>
SET HTTPS_PROXY=http://<your_proxy_IP>:<your_proxy_port>

b) download the Vagrant file

git clone https://github.com/oveits/coreos-vagrant
cd coreos-vagrant

c) on Windows, the files must be converted to UNIX format (minimum:  provision_ssh_agent_bashrc.sh must be in UNIX format). If bash is installed on the system, you can do the following (otherwise you might be able to use your editor, e.g. PSPAD, Ultraedit, … to do so):   bash   dos2unix * 

2. Adapt the configuration files

cp user-data.sample user-data

get token from https://discovery.etcd.io/new
copy token output to user-data file as:

discovery: https://discovery.etcd.io/<token>

adapt the Vagrantfile:

$num_instances=3

(more instances will take longer to boot up and be provisioned)

3. Start cluster:

vagrant up

4. Cluster discovery:
temporarily connect to the Internet, since HTTP proxy is not supported by etcd discovery
check https://discovery.etcd.io/<token> again
–> should show the nodes

etcd discovery output
Public etcd discovery service showing that it has learned about the three nodes

5. Connect to one of the nodes and check cluster health:

vagrant ssh core-01
etcdctl cluster-health

–> should show “healthy”
Oliver Veits

fleetctl list-machines

–> should show IP addresses of the nodes

DONE

1

Docker CoreOS Cluster Failover Test in less than 15 Minutes


In this post, I will explore services failover scenarios for docker containers on CoreOS clusters using fleet. A container-based service will be defined and started, and we will explore the service recovery after a failure of one or all cluster nodes (e.g. a power outage).

If you happen to read the full description after tl;dr section below, you will learn about the difference between fleet used here and orchestration tools like Kubernetes. In addition, we will explore the proper SSH key handling and HTTP proxy configuration.

Rescuing (restarting) containers, if a docker node fails
Rescuing (restarting) containers, if a docker node fails

tl;dr: Docker CoreOS Cluster Failover Test in less than 15 Minutes

In this chapter, we start from a cluster that is up and running as created in the appendix of last my last blog. In that blog we have created a CoreOS cluster in less than 10 minutes. Now, we will define a hello world service that can be started on the cluster, and we will check that the cluster failover works as expected.

Prerequisite: you have followed the instructions in the blog Install a CoreOS Docker Cluster in less than 10 Minutes.

  1. If you are behind a HTTP proxy (adapt IP address:Port to match your case):
    SET HTTP_PROXY=http://<your_proxy_ip>:<your_proxy_port>
    SET HTTPS_PROXY=http://<your_proxy_ip>:<your_proxy_port>
    vagrant plugin install vagrant-proxyconf
    

    uncomment 5 lines in the Vagrantfile starting with the line containing “vagrant-proxyconf”
    exchange “proxy.example.com:8080” by the IP address/Port pair valid in your environment and save the document

    vagrant reload --provision
  2. connect to one of the cluster nodes:
    vagrant ssh core-01
  3. check the HTTP proxy configuration, if applicable: issue the command “set” and confirm that http_proxy and https_proxy are set to the appropriate values
  4. copy&paste the content of the hello service from the Hello Service section below into a new hello.service file in the home directory
    [Unit]
    Description=My Service
    After=docker.service
    
    [Service]
    TimeoutStartSec=0
    ExecStartPre=-/usr/bin/docker kill hello
    ExecStartPre=-/usr/bin/docker rm hello
    ExecStartPre=/usr/bin/docker pull busybox
    ExecStart=/usr/bin/docker run --name hello busybox /bin/sh -c "while true; do echo Hello World; sleep 1; done"
    ExecStop=/usr/bin/docker stop hello
  5. start the service:
    fleetctl load hello.service
    fleetctl start hello.service
  6. check the service (issue several times until you see some lines with date and “Hello World”):
    fleetctl status hello.service
    

  7. Failover Test: via Virtualbox console, shutdown the machine that has the service running (might differ from the machine you have started the service)
  8. Connect to another node, e.g. via
    vagrant ssh core-03
    

    and repeat step 7. It should show that the service is up and running like follows:

Bingo!

Full description: Starting a distributed Hello World Service

Versions

v1 (2015-07-22): step by step instruction with manual changes required
v2 (2015-07-27): added the “Appendix: CoreOS Cluster Failover Test in less than 15 Minutes”
v3 (2015-08-19): moved to WordPress, since the LinkedIn blog is not available publicly anymore
v4 (2015-08-19): moved the CoreOS Cluster Failover Tests in less than 15 Minutes to the top (for the quick reader)

About fleet

For service definition and management, we explore the features and handling of fleet software that ships with CoreOS. fleet is based on an open source project that calls fleet a “simple distributed init system”. The project team points to Kubernetes for all those, who are looking for more complex scheduling requirements or a first-class container orchestration system.

Still, I would like to learn about fleet. fleet is described in the CoreOS Quick Start Guide and it seems to be simple, and still powerful, if you are looking for following features:

  • define a (docker container) service independent of the CoreOS node it will run on later
  • deploy and start the a service unit on any of the CoreOS nodes
  • deploy and start service units on all of the CoreOS nodes
  • upon failure of a node: automatic restart of a service unit on an other node
  • make sure that all required service units are started on the same machine (affinity)
  • forbid specific service units from running on the same machine (anti-affinity)
  • allow for machine specific metadata

Note that the fleet software could work on any Linux system with an up to date systemd, but officially, it is supported only on CoreOS (see a group discussion here).

Following the CoreOS Quick Start Guide, I have create a hello.service file in home directory of the “core” user on core-01:

hello.service

[Unit]
Description=My Service
After=docker.service

[Service]
TimeoutStartSec=0
ExecStartPre=-/usr/bin/docker kill hello
ExecStartPre=-/usr/bin/docker rm hello
ExecStartPre=/usr/bin/docker pull busybox
ExecStart=/usr/bin/docker run --name hello busybox /bin/sh -c "while true; do echo Hello World; sleep 1; done"
ExecStop=/usr/bin/docker stop hello

It is not clear to me yet, where this service definition is supposed to be located. Will it be distributed to all systems? If not, what happens if the machine, this service definition is located is unavailable? We will see in the “Power Outage” section further down below, that the service is still started automatically. For now, let us go on:

Now let us load and start the service:

fleetctl load hello.service
fleetctl start hello.service

We can see that the service has not been started on core-01, but on core-03 instead, since the IP address 172.17.8.103 is owned by core-03. Let us try to check the service status with the command

fleetctl status hello.service

Failed. We can still see that the file has been started on core-03 by using the command

fleetctl list-unit-files

However, the “fleetctl status hello.service” command works locally on core-03, though, where the service has been started:

It is not up and running, because busybox could not be downloaded. This is caused by a missing HTTP proxy configuration and will be fixed later. As a workaround, you can also connect temporarily to the Internet without HTTP proxy (e.g. using the hot spot function of your mobile phone), and it will work. However, let us fix that later and let us concentrate on the fleetctl status command issue first:

Fixing the fleetctl status Problem

A long troubleshooting session has lead me to the result that the problem is caused by the ssh agent not being started and by a missing SSH private key on the system that is issuing the fleetctl command. For resolution, we need to perform following steps:

  1. Find and upload the insecure SSH key to the nodes
  2. start the ssh-agent
  3. set permissions of the ssh key to 600
  4. add the key with ssh-add

1. find and upload the SSH key to the nodes

If you are using WinSCP as SFTP client, you need to convert the insecure private key found on

$USERPROFILE/.vagrant.d/insecure_private_key
(where $USERPROFILE=C:/Users/<yourusername> on Windows)

to ppk format. This can be done by importing and saving the private key using the puTTYgen tool.

The ppk key then can be used by WinSCP to connect to the system and transfer the private key (the one in the original format):

Here, you see the WinSCP connection to the core-0x machines with manually added private keys in the .ssh folder.

2. start the ssh agent

Perform the command

eval `ssh-agent -s`

After that the error message changes to “ssh: handshake failed: ssh: unable to authenticate”

3. set permissions of the SSH key file to 600

perform

chmod 600 .ssh/insecure_private_key

on the node:

4. add the key with ssh-add

Now we need to perform the command

ssh-add .ssh/insecure_private_key

With that, the fleetctl problem is resolved and the command fleetctl status hello.service works also on core-01:

You need to perform those steps from any machine you want to be able to perform fleetctl commands with full access to all of the nodes of the cluster. In the Appendix, I will show that this can be automated using Vagrant.

Manually Fixing the HTTP proxy Problems

Now let us fix the busybox download topic: the service could not be started because I am behind a proxy and the cluster nodes cannot download the busybox image from the repository. For that to work, I either need to pre-load the images, or I need to control the http proxy configuration of each cluster node, similar to how I have done it on DDDocker (6) in the section “HTTP Proxy Problems”.

The cool, automated way of doing this is by using the Proxy Configuration Plugin for Vagrant described on http://tmatilai.github.io/vagrant-proxyconf/. But note, that there is an open bug, which will be fixed in the Appendix.

For core-03, let us test the manual way of solving the problem first:

  1. check that the download fails e.g. by trying a “docker search busybox” on the command line or on core-03: fails like expected (this takes a long time):
  2. Perform the commands:
    sudo mkdir /etc/systemd/system/docker.service.d
    sudo vi /etc/systemd/system/docker.service.d/http-proxy.conf

    and add something like:

    [Service]
    Environment="HTTP_PROXY=http://proxy.example.com:8080"

    (replace the URL, so it fits to your environment)

  3. reboot core-03 (best via “vagrant reload core-03” on the vagrant folder) and check again the command, which should succeed now:

Success: all docker requests are sent to the HTTP proxy and docker search command succeeds.

An implicit Cluster Node Failover Test

Now let us see, what happened to our service:

We can see, that it is still down. However, because of the reboot of core-03, the service was automatically moved to core-02. However, core-02 still has a false HTTP proxy configuration; therefore the download of the busybox image has failed. Let us force the service back to core-03 by reloading core-02 and core-01 via

vagrant reload core-02 core-01

(performed on the host system in the vagrant project folder). As expected the service is moved to core-03 and is up and running:

Note that our fleetctl (SSH key) fix has not survived the reload on core-01:

Therefore it is a good idea to look for an automated (vagrant) way to fix the SSH key problem as shown below.

Automated Fix of the SSH Key Problem

We have seen above that the fleetctl status commands fails if the service is running on a remote cluster node. The reason was that the fleetctl client has no trusted private SSH key installed and the ssh agent is not started. The manual workaround to activate the SSH key has not survived a reboot of the node. Therefore, I have automated the installation of the vagrant SSH key on my github fork https://github.com/oveits/coreos-vagrant.

To make use of it, follow the instructions in my DDDocker (7) blog, but replace the git clone command from https://github.com/coreos/coreos-vagrant to the new repository https://github.com/oveits/coreos-vagrant. After that, the commands

fleetctl status <your started service, e.g. hello.service>

should be working on all 3 nodes. If not, please report it as an issue on https://github.com/oveits/coreos-vagrant.

Automation of the HTTP proxy Configuration Distribution

On core-03, we manually have fixed the HTTP proxy configuration by editing the file /etc/systemd/system/docker.service.d/http-proxy.conf. On core-01 and core-02, we will now fix it using a nice plugin, the vagrant-proxyconf plugin. This plugin provisions the HTTP proxy configuration of all nodes of the cluster during vagrant deployment.

Install the vagrant-proxyconf plugin

If you are currently behind a HTTP proxy, the HTTPS_PROXY variable must be set manually on the host system for the command

vagrant plugin install vagrant-proxyconf

to succeed. Below, I was connected directly to the Internet, so the HTTPS_PROXY had to be empty:

Now configure the Vagrantfile:
before:

after:

Replace the IP addresses and ports to the ones that fit to your networking environment.

Let us verify that the HTTP configuration is still wrong for core-01:

The variables $HTTP_PROXY and $http_proxy are empty and docker search busybox has failed (timed out):

Now let us provision the cluster node via (if you omit the name core-01, it will provision all nodes in the cluster; however, we want to quickly see and verify the results first before rolling out the provisioning to all nodes):

vagrant reload --provision core-01
# (also possible: vagrant provision core-01, but you need to make sure you reconnect via SSH, since the effect will not be visible in the current SSH session)

After reconnecting to core-01 via SSH, we will see following output of the “set” command (with different IP addresses and/or ports in your case):

Now docker search is successful:

We remove the file /etc/systemd/system/docker.service.d/http-proxy.conf from core-03, since we will not need it anymore:

and we perform the same provisioning step for core-02 and core-03:

vagrant reload --provision core-02 core-03

After that, the hello.service should have been moved to core-01 and the busybox download should have been successful:

If you have done the tests based on the git repository https://github.com/oveits/coreos-vagrant instead of https://github.com/coreos/coreos-vagrant, you will see the same status on all 3 nodes:

If you have used the original git repository https://github.com/coreos/coreos-vagrant, you will need see

Again, this can be resolved by uploading the private key found on

$USERPROFILE/.vagrant.d/insecure_private_key
(where $USERPROFILE =  C:/Users/<yourusername> on Windows)

to the ~core/.ssh folder and re-issuing the commands

eval `ssh-agent -s`; chmod 600 .ssh/insecure_private_key; ssh-add .ssh/insecure_private_key

before issuing the fleetctl status command, as seen below:

The hello.service is up and running also from behind a HTTP proxy.

Total Cluster Failure (e.g. Power Outage)

Now, we will simulate a total cluster failure by shutting down the cluster node VMs via Virtualbox. The hello.service has been defined on core-01 only. Let us first start core-02 and core-03, if they start up the service:

Cool: even after a simulated power outage, the service is restarted. And this, although I have not yet started core-01, where the service definition file is located. Perfect. In a productive environment, we just need to make sure that the virtual machines are automatically booted, after power is back again (e.g. using vSphere functions).

Summary

fleet is a low level init system for clusters, which can be used to manage clusters directly and also also can be used to bootstrap higher-level container orchestration software like Kubernetes. It allows to define services, and run the service on any node of the cluster.

In this post, using fleet, the failover and recovery of a container-based service after a cluster node failure has been tested successfully:

  1. after failure of the node the service was running on, the service is automatically started on another node of the cluster.
  2. After a simulated total cluster outage, the service will be started, even if the cluster node, where the hello.service file is located, is kept down.

Special care had to be taken to following topics:

  1. SSH keys and ssh agent on the fleet client
  2. HTTP proxy onfiguration, if applicable to your environment

Both topics have been shown that they can be handled either manually or through automatic Vagrant provisioning.

About 1. SSH connection requirements:
The node running the fleet client needs to be provisioned with a trusted SSH private key. This can be automated using Vagrant; an according git repository has been provided here: https://github.com/oveits/coreos-vagrant.

About 2. HTTP proxy configuration:
If your cluster runs behind a HTTP proxy, several measures should be considered:

  1. initial cluster discovery (see DDDocker (8)): a temporary direct Internet access is needed, if you do not want to install a local etcd discovery agent, since etcd discovery does not yet support HTTP proxies.
  2. Successful service launch requires a correct HTTP proxy configuration of each node. This can be automated via the vagrant-proxyconf plugin. However, in the current version, a bug needs to be fixed manually (can be performed in two minutes).

2

Container Orchestration with Kubernetes


This blog post shows a quick way how to install Kubernetes, a Docker orchestration framework published by Google, as a set of Docker containers. With that you can circumvent the hassle you may run into while trying to install Kubernetes natively.

Note: previous blogs in the DDDocker series can be found on LinkedIn; more recent blog posts on Docker are found here on WordPress.

Versions

v0.1 (draft) 2015-08-12: described 3 ways of installing Kubernetes, but they either failed or they led to problems later on, because ‘make’ and other commands were missing on the machine running the kubectl client (Windows related problem). Now this installation version is moved to the appendix, since it might still be needed later on, if testing other procedures on Linux.
v0.2 (draft) 2015-08-14: added coarse outline of my (now successful) 4th attempt
v1.0 2015-08-17: full description of the successful attempt; I have moved the old, problematic attempt into the appendix.
v1.1 2015-08-17: added a subchapter “Networking Challenges”, which shows how to route from the Windows host to the service.
v1.2 2015-08-18: moved the page to wordpress.com, since LinkedIn blogs was not available to all of my colleagues.
v1.3 2016-07-11: moved the documentation of the unsuccessful attempts to the end of the document

Introduction

What is Kubernetes all about? You might love this intro: The Illustrated Children’s Guide to Kubernetes.

In the last blog I have investigated some low level container orchestration using fleet, which calls itself a “simple distributed init system”, but we could show that it offers possibilities to

  • define container-based services and
  • monitor the health of Docker hosts
  • automatic restart of containers on other hosts, if a Docker host fails.

For those looking for more complex scheduling requirements or a first-class container orchestration system, Kubernetes of google is recommended. Let us explore, what Kubernetes adds to fleet’s capabilities, how to install it and how to test its core features. Kubernetes is a core element of other, more complete Container frameworks, e.g. Red Hat’s OpenShift Container Platform (a.k.a. OpenShift Enterprise 3.x).

Kubernetes Architecture

In the architecture consists of a master docker node and one or more minion nodes. In our example the master node offers:

  1. kubectl, i.e. the kube client
  2. the REST API with authentication, Replication Controller and Scheduler
  3. the kubelet info service, i.e. the service, which talks to the other docker hosts

Depending on the size of the solution, the functions can be spread over different docker hosts.

2015.08.05-18_55_22-hc_001

The minion docker hosts that are hosting pods offer following functions:

  1. kublet, i.e. the kube agent the kubelet info service talks to
  2. cAdvisor, which is used to monitor containers
  3. a proxy, which offers an abstraction layer for the communication with pods, see the description of pods.

Pods:

  • are a set of containers on a single docker host
  • each pod is assigned an IP address
  • communication between pods is performed via a proxy, which is the abstraction layer offering the pod’s IP address from outside

kubectl is the client talking to a REST API, which in turn talks to the kublet info service, which in turn talks to the pods via local kublet agents.

etcd is used as a distributed key storage system. I guess, host clustering is done via the etcd discovery service (t.b.v.).

Installation of Kubernetes

…on Ubuntu Docker host (works well)…

We are following the instructions: Running Kubernetes locally via Docker on a Ubuntu VM created via Vagrant.

Installation of Ubuntu using Vagrant

Prerequisites:

  • Vagrant, Virtualbox are installed

If you are operating behind a HTTP proxy, set the http_proxy and https_proxy variables accordingly (please replace the name/IP address and port that it matches your environment):

export http_proxy="http://proxy.example.com:8080"
export https_proxy="http://proxy.example.com:8080"

Create and initialize a Vagrant working directory:

mkdir ubuntu-trusty64-docker; cd ubuntu-trusty64-docker
vagrant init williamyeh/ubuntu-trusty64-docker

Start and connect to the VM:

vagrant up
vagrant ssh

Start Kubernetes Docker Containers

If you are operating behind a proxy, set the http_proxy and https_proxy variables accordingly and add those variables also to the docker environment:

# perform this section, if you are behind a HTTP proxy, but replace IP address and port to match your environment:
export http_proxy="http://proxy.example.com:8080"
export https_proxy="http://proxy.example.com:8080"
sudo vi  /etc/default/docker
# add the export commands above to the file /etc/default/docker (with sudo vi  /etc/default/docker) and restart the docker service:
sudo service docker restart

Install kubectl:

sudo wget https://storage.googleapis.com/kubernetes-release/release/v1.0.3/bin/linux/amd64/kubectl -O /tmp/kubectl
sudo cp /tmp/kubectl /usr/local/bin/; sudo chmod +x /usr/local/bin/kubectl

Stop the cAdvisor, since it would lead to a clash in the port assignment:

docker ps | grep -i cadvisor | grep ':8080->' | awk '{print $1}' | xargs --no-run-if-empty docker stop

With docker ps, make sure that no docker container is running at this point:

Now you can follow the instructions on https://github.com/pires/kubernetes-vagrant-coreos-cluster/blob/master/README.md, like follows:

Step One: Run etcd

docker run --net=host -d gcr.io/google_containers/etcd:2.0.9 /usr/local/bin/etcd --addr=127.0.0.1:4001 --bind-addr=0.0.0.0:4001 --data-dir=/var/etcd/data

Step Two: Run the master

docker run --net=host -d -v /var/run/docker.sock:/var/run/docker.sock gcr.io/google_containers/hyperkube:v0.21.2 /hyperkube kubelet --api_servers=http://localhost:8080 --v=2 --address=0.0.0.0 --enable_server --hostname_override=127.0.0.1 --config=/etc/kubernetes/manifests

Step Three: Run the service proxy

docker run -d --net=host --privileged gcr.io/google_containers/hyperkube:v0.21.2 /hyperkube proxy --master=http://127.0.0.1:8080 --v=2

Test it out

kubectl get nodes

Run an application

kubectl -s http://localhost:8080 run-container nginx --image=nginx --port=80

Now run

docker ps

you should see nginx running. You might need to wait a few minutes for the image to get pulled:

Expose it as a service

kubectl expose rc nginx --port=80

If CLUSTER_IP is blank (Known kubernetes issue #10836) run the following command to obtain it:

kubectl get svc nginx

Test the web server:

export no_proxy="<insert-ip-from-above-here>"
curl <insert-ip-from-above-here>

Bingo! The NginX web server is up and running!

Accessing the Service from remote

The service is reachable from the Vagrant Linux host. However, the service cannot be reached from my Windows machine yet.

The problem can be described like follows:

  1. Kubernetes is automatically fetching an IP address from a pool (defined where?) for each service. In case of the Nginx service, this was the IP address 10.0.0.146.
  2. The address is not owned by the Vagrant Linux VM, as can be seen with an ifconfig.
  3. In Vagrant, per default, we have no public IP address. However, Vagrant offers the possibility to map a VM’s IP address and port to a port of the host (= Windows host in my case). However, I have not found any possibility to map a host’s IP:port pair to an IP and port that is not owned by the VM.

We have two possibilities to resolve the problem:

1) Chained port mapping (only theory; not tested yet):

  • In Vagrant map the host’s port to an IP:port pair owned by the VM
  • In the VM, using e.g. iptables NAT function to map the IP:port pair to the service’s IP:port pair

2) Create an additional, reachable interface for the VM and route the service IP address to this public interface

  • In the Vagrantfile, add e.g. the line
    config.vm.network “private_network”, ip: “192.168.33.10” -> this will automatically create the interface eth1 in a new host-only network. You need to issue “vagrant reload –provision” to activate this setting.
  • On the (Windows) host, add a route to the network, which matches the pool Kubernetes is choosing the service IP addresses from. In my case, I have added the route using the command
    route add 10.0.0.0 mask 255.255.255.0 192.168.33.10

With this, the Nginx service becomes reachable (now on another, randomly chosen IP address 10.0.0.19, since I have restarted the host):

Perfect! The service is now available also from the Windows host.
In a real world example, external load balancers will map the externally visible IP:port pair to the service’s IP:Port pair; and the IP address and port will be chosen statically. Routing needs to take care that the service is reached, no matter, on which host it is located. This is something, I need to explore in more detail an another post: how can we connect several Minions to the same network, and can we make sure that the IP packets are routed to the right Minion? Gratuitous ARP?

Appendix: Installation of Kubernetes on CoreOS (removed)

This was a log of my efforts, but it lead to a dead end (installation of kubectl on CoreOS is not supported and running kubectl in a docker container did not lead to the desired results), so I have removed it; still available on request as revision 18 …

Appendix: Attempts to install Kubernetes (including unsuccessful attempts)

Installation of Kubernetes on Windows seems to be hard, as can be seen with the first three unsuccessful installation attempts. However, I have found a fairly automated way of installing Kubernetes as a set of Docker containers by using Vagrant and a base image that has docker already installed on an Ubuntu VM. This is described as successful attemt 4) below and is described in more detail in the main part of this blog.

UNSUCCESSFUL ATTEMPTS:

1) Multi-node CoreOS cluster installation on the Getting Started CoreOS page
I had to try 3 times, until the kubectl client was downloaded and installed correctly. And when trying to start my first NginX example, I found myself in a dead end: the example(s) require normal Linux commands line “make”, but CoreOS neither support those commands, nor allows to install them.

2) Running Kubernetes locally via Docker
this is supposed to be the quick way for an evaluation installation, since we only need to download and run pre-installed Docker images. Not so this time: here, I run into the problem that kubectl client cannot be installed on my boot2docker host. When I try to use one of the kubectl docker images, I always get an error that 127.0.0.1:8080 cannot be reached.

3) Running Kubernetes locally via Docker within an Ubuntu docker container on Windows boot2docker does not work either: if I install kubectl on that container, kubectl cluster-info always returns a success message no matter, which server IP address I specify and no matter, whether the kubernetes containers are up and running or not. Shoot.

SUCCESSFUL ATTEMPT:

4) SUCCESS: Running Kubernetes locally via Docker within an Ubuntu VM has succeeded finally: I had created an Ubuntu VM using Vagrant with the image ubuntu-trusty64-docker from the Vagrant boxes repository and I have downloaded kubectl v1.0.1 into /usr/local/bin of that image. First, I had the problem that kubectl always had returned an error that I could not find on Google, saying that it had received the string “Supported versions: [v1.0,…]” or similar. Then I had found out that kubectl is connecting to http://localhost:8080, which was occupied already with a docker image google/cadvisor, that was up and running in the Ubuntu Vagrant image I had used. After finding this docker image with “docker ps” and stopping it with “docker stop <container-id>”, kubectl worked as expected. Now “wget -qO- http://localhost:8080/ | less” returns a list of paths in json format and all kubectl commands on the instruction page are working as expected. That was hard work. My assumption that it would work on Ubuntu was correct. I will troubleshoot in more details, why it had not worked in one of the other ways.