Running Kubernetes on Google Compute Engine

    If you want a simplified getting started experience and GUI for managing clusters, please consider trying Google Kubernetes Engine for hosted cluster installation and management.

    For an easy way to experiment with the Kubernetes development environment, click the button below to open a Google Cloud Shell with an auto-cloned copy of the Kubernetes source repo.

    If you want to use custom binaries or pure open source Kubernetes, please continue with the instructions below.

    1. Install as necessary. gcloud can be installed as a part of the Google Cloud SDK.
    2. Enable the in the Google Cloud developers console.
    3. Make sure that gcloud is set to use the Google Cloud Platform project you want. You can check the current project using gcloud config list project and change it via gcloud config set project <project-id>.
    4. Make sure you have credentials for GCloud by running gcloud auth login.
    5. (Optional) In order to make API calls against GCE, you must also run gcloud auth application-default login.
    6. Make sure you can start up a GCE VM from the command line. At least make sure you can do the part of the GCE Quickstart.
    7. Make sure you can SSH into the VM without interactive prompts. See the Log in to the instance part of the GCE Quickstart.

    Starting a cluster

    You can install a client and start a cluster with either one of these commands (we list both in case only one is installed on your machine):

    or

    1. wget -q -O - https://get.k8s.io | bash

    Once this command completes, you will have a master VM and four worker VMs, running as a Kubernetes cluster.

    By default, some containers will already be running on your cluster. Containers like fluentd provide logging, while heapster provides services.

    The script run by the commands above creates a cluster with the name/prefix “kubernetes”. It defines one specific cluster config, so you can’t run it more than once.

    Alternately, you can download and install the latest Kubernetes release from this page, then run the <kubernetes>/cluster/kube-up.sh script to start the cluster:

    1. cd kubernetes
    2. cluster/kube-up.sh

    If you want more than one cluster running in your project, want to use a different name, or want a different number of worker nodes, see the <kubernetes>/cluster/gce/config-default.sh file for more fine-grained configuration before you start up your cluster.

    The next few steps will show you:

    1. How to set up the command line client on your workstation to manage the cluster
    2. Examples of how to use the cluster
    3. How to delete the cluster
    4. How to start clusters with non-default options (like larger clusters)

    The cluster startup script will leave you with a running cluster and a kubernetes directory on your workstation.

    The tool controls the Kubernetes cluster manager. It lets you inspect your cluster resources, create, delete, and update components, and much more. You will use it to look at your new cluster and bring up example apps.

    You can use gcloud to install the kubectl command-line tool on your workstation:

    Getting started with your cluster

    Inspect your cluster

    Once kubectl is in your path, you can use it to look at your cluster. E.g., running:

    1. kubectl get --all-namespaces services

    should show a set of services that look something like this:

    1. default       kubernetes    ClusterIP        10.0.0.1         <none>            443/TCP        1d
    2. kube-system   kube-dns      ClusterIP        10.0.0.2         <none>            53/TCP,53/UDP  1d
    3. kube-system   kube-ui       ClusterIP        10.0.0.3         <none>            80/TCP         1d
    4. ...

    Similarly, you can take a look at the set of that were created during cluster startup. You can do this via the

    command.

    You’ll see a list of pods that looks something like this (the name specifics will be different):

    1. NAMESPACE     NAME                                           READY     STATUS    RESTARTS   AGE
    2. kube-system   coredns-5f4fbb68df-mc8z8                       1/1       Running   0          15m
    3. kube-system   fluentd-cloud-logging-kubernetes-minion-63uo   1/1       Running   0          14m
    4. kube-system   fluentd-cloud-logging-kubernetes-minion-c1n9   1/1       Running   0          14m
    5. kube-system   fluentd-cloud-logging-kubernetes-minion-c4og   1/1       Running   0          14m
    6. kube-system   fluentd-cloud-logging-kubernetes-minion-ngua   1/1       Running   0          14m
    7. kube-system   kube-ui-v1-curt1                               1/1       Running   0          15m
    8. kube-system   monitoring-heapster-v5-ex4u3                   1/1       Running   1          15m

    Some of the pods may take a few seconds to start up (during this time they’ll show Pending), but check that they all show as Running after a short period.

    For more complete applications, please look in the examples directory. The is a good “getting started” walkthrough.

    To remove/delete/teardown the cluster, use the kube-down.sh script.

    1. cd kubernetes
    2. cluster/kube-down.sh

    Likewise, the kube-up.sh in the same directory will bring it back up. You do not need to rerun the curl or wget command: everything needed to setup the Kubernetes cluster is now on your workstation.

    Customizing

    The script above relies on Google Storage to stage the Kubernetes release. It then will start (by default) a single master VM along with 3 worker VMs. You can tweak some of these parameters by editing kubernetes/cluster/gce/config-default.sh You can view a transcript of a successful cluster creation .

    Project settings

    You need to have the Google Cloud Storage API, and the Google Cloud Storage JSON API enabled. It is activated by default for new projects. Otherwise, it can be done in the Google Cloud Console. See the for more details.

    Also ensure that— as listed in the Prerequisites section-- you’ve enabled the Compute Engine Instance Group Manager API, and can start up a GCE VM from the command line as in the instructions.

    If the Kubernetes startup script hangs waiting for the API to be reachable, you can troubleshoot by SSHing into the master and node VMs and looking at logs such as /var/log/startupscript.log.

    Once you fix the issue, you should run kube-down.sh to cleanup after the partial cluster creation, before running kube-up.sh to try again.

    SSH

    If you’re having trouble SSHing into your instances, ensure the GCE firewall isn’t blocking port 22 to your VMs. By default, this should work but if you have edited firewall rules or created a new non-default network, you’ll need to expose it: gcloud compute firewall-rules create default-ssh --network=<network-name> --description "SSH allowed from anywhere" --allow tcp:22

    Additionally, your GCE SSH key must either have no passcode or you need to be using ssh-agent.

    The instances must be able to connect to each other using their private IP. The script uses the “default” network which should have a firewall rule called “default-allow-internal” which allows traffic on any port on the private IPs. If this rule is missing from the default network or if you change the network being used in cluster/config-default.sh create a new rule with the following field values:

    • Allowed Protocols and Port: tcp:1-65535;udp:1-65535;icmp

    Support Level