Your First Kubernetes Cluster On Mac
Tags: cloud, container, docker, gke
Published: 2019-09-05 21:05:18

---
title: Your First Kubernetes Cluster On Mac
published: true
tags: cloud,container,docker,GKE
canonical_url: https://greenido.wordpress.com/2019/04/26/your-first-kubernetes-cluster-on-mac/
---

![](https://greenido.files.wordpress.com/2019/04/screen-shot-2019-04-23-at-9.43.46-am.png?w=696)

If you wish to learn about Kubernetes, the first thing is to try it for yourself. Since many developers are using Mac, let’s see how to run it. This post is sort of a ‘checklist’ I wrote when I was first ‘playing’ with K8b… If you want more details please check the [official site.](https://kubernetes.io/docs/tutorials/kubernetes-basics/)

First, on Mac, we will install a few tools that will help us run it. At step zero, you should install [brew](https://brew.sh/) (or homebrew as they call it). You can do it with one line in the terminal:

```
/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
```

Next, we will install kubectl which will help us control K8b from the terminal:

```
$ brew install kubectl
```

kubectl is a binary used to access any Kubernetes cluster. After that, we need a VM (which will host the k8b) and in this case, we are going with Virtual Box:

```
$ brew cask install virtualbox
```

Minikube runs inside a VM both on Linux and Mac.

Let’s install minikube:

```
$ brew cask install minikube
```

Now we can start to play with our first k8s cluster. Check the few commands below on how to start _minikube_ check its status and stop it.

```
# Let's start the $ minikube start --vm-driver=virtualbox --logtostderr #Give minikube a bit of time... the first run might take a few minutes # check what is going on $ minikube status host: Running kubelet: Running apiserver: Running kubectl: Correctly Configured: pointing to minikube-vm at 192.168.99.100 # Let see the UI from our browser $ minikube dashboard http://127.0.0.1:50723/api/v1/namespaces/kube-system/services/http:kubernetes-dashboard:/proxy/#!/overview?namespace=default # Now you might want to stop it $ minikube stop
```

You may need to control multiple clusters from the client environment. For example, have one local k8s cluster running by minikube, and one on GKE. To view, list, and switching current context, you can run the following command

```
$ kubectl config current-context $ kubectl config get-contexts $ kubectl config use-context minikube
```

You can interact with a k8s cluster through:

- _kubectl_ – Which is a Command Line Interface (CLI).
- Graphical User Interface (GUI), cloud provider dashboard. Note that minikube also have build-in UI interface. 
- You may access through`$ minikube dashboard`

By default, _kubectl_ get the master node endpoint and credentials from the config files inside .kube directory. It is usually under the user home directory. We can also view the settings with:

```
$ kubectl config view
```

We can also use kubectl to get detail info about the current cluster:

```
$ kubectl cluster-info
```

_Kubernetes master is running at_ [https://192.168.64.2:8443](https://192.168.64.2:8443)   
\* It might be different for you, depending on your settings.

If we have numerous users whom we would like to organize into teams/projects, we can partition the Kubernetes cluster into sub-clusters using [Namespaces](https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/). The names of the resources/objects created inside a Namespace are unique, but not across Namespaces.

To list all the Namespaces, we can run the following command:

```
$ kubectl get namespaces
```

Generally, Kubernetes creates two default Namespaces: _kube-system_ and _default_. The kube-system Namespace contains the objects created by the Kubernetes system. The default Namespace contains the objects which belong to any other Namespace. By default, we connect to the default Namespace. _kube-public_ is a special Namespace, which is readable by all users and used for special purposes, like bootstrapping a cluster. This namespace exists in clusters created with _kubeadm_ for now. It contains a single ConfigMap object, cluster-info, that aids discovery and security bootstrap (basically, contains the CA for the cluster and such). It is readable without authentication and since the k8s cluster is implemented differently, not all cluster has this namespace by default.

![🛑](https://s0.wp.com/wp-content/mu-plugins/wpcom-smileys/twemoji/2/72x72/1f6d1.png) It is a bad practice to deployment application under the default namespace.

Now, if you wish to deploy a container (with an app) to your cluster. Check which node we have in our cluster:

```
$ kubectl get nodes
```

After you get the one node that we have, you can try:

```
$ kubectl run kubernetes-bootcamp --image=gcr.io/google-samples/kubernetes-bootcamp:v1 --port=8080
```

And verify it:

```
$ kubectl get deployments NAME READY UP-TO-DATE AVAILABLE AGE kubernetes-bootcamp 1/1 1 1 2m22s
```

The app is running but if we wish to see it we need to ‘open’ the network. Pods that are running inside Kubernetes are running on a private, isolated network. By default, they are visible from other pods and services within the same kubernetes cluster, but not outside that network.   
When we use `kubectl`, we’re interacting through an API endpoint to communicate with our application.   
The `kubectl` command can create a proxy that will forward communications into the cluster-wide, private network. The proxy can be terminated by pressing control-C and won’t show any output while it is running. You want to run this command on a new terminal window and let it run in the background:

```
$ kubectl proxy Starting to serve on 127.0.0.1:8001
```

Now, let’s get the pod name and store it for future usage:

```
$ export POD\_NAME=$(kubectl get pods -o go-template --template '{{range .items}}{{.metadata.name}}{{"\n"}}{{end}}') echo Name of the Pod: $POD\_NAME
```

See our application (in this case, just a returning string):

```
$ curl http://localhost:8001/api/v1/namespaces/default/pods/$POD\_NAME/proxy/
```

We should get:

```
Hello Kubernetes bootcamp! | Running on: kubernetes-bootcamp-6bf84cb898-mwb42 | v=1
```

Let’s see the logs:

```
$ kubectl logs $POD\_NAME Kubernetes Bootcamp App Started At: 2019-04-23T17:09:00.785Z | Running On: kubernetes-bootcamp-6bf84cb898-mwb42 Running On: kubernetes-bootcamp-6bf84cb898-mwb42 | Total Requests: 1 | App Uptime: 48.01 seconds | Log Time: 2019-04-23T17:09:48.795Z Running On: kubernetes-bootcamp-6bf84cb898-mwb42 | Total Requests: 2 | App Uptime: 86.209 seconds | Log Time: 2019-04-23T17:10:26.994Z Running On: kubernetes-bootcamp-6bf84cb898-mwb42 | Total Requests: 3 | App Uptime: 214.666 seconds | Log Time: 2019-04-23T17:12:35.451Z
```

The most common operations can be done with the following kubectl commands:

**kubectl get**  – list resources

**kubectl describe**  – show detailed information about a resource

**kubectl exec** – execute a command on a container in a pod. For example, to see all the variables:

```
$ kubectl exec $POD\_NAME env PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin HOSTNAME=kubernetes-bootcamp-6bf84cb898-mwb42 KUBERNETES\_PORT=tcp://10.96.0.1:443 KUBERNETES\_PORT\_443\_TCP=tcp://10.96.0.1:443 KUBERNETES\_PORT\_443\_TCP\_PROTO=tcp KUBERNETES\_PORT\_443\_TCP\_PORT=443 KUBERNETES\_PORT\_443\_TCP\_ADDR=10.96.0.1 KUBERNETES\_SERVICE\_HOST=10.96.0.1 KUBERNETES\_SERVICE\_PORT=443 KUBERNETES\_SERVICE\_PORT\_HTTPS=443 NPM\_CONFIG\_LOGLEVEL=info NODE\_VERSION=6.3.1 HOME=/root
```

Or to open a bash session into the Pod’s container:

```
$ kubectl exec -ti $POD\_NAME bash
```

The next step is to use a service to expose your app.   
You can read and try it over [here](https://kubernetes.io/docs/tutorials/kubernetes-basics/expose/expose-intro/).

Have fun!

![](https://greenido.files.wordpress.com/2019/04/screen-shot-2019-04-23-at-10.18.29-am.png?w=696)