Digging around on the Kubernetes cluster

Cloud Platform (intermediate level) posted on 22nd March 2018


This is a part of the series of posts on Getting an API running in Kubernetes, and you should first have created an app to be deployed as described in Building your App ready for Kubernetes deployment, deployed it as described in Creating a Kubernetes deployment , created a service as described in Creating a microservice on Kubernetes, and you should already have a cluster up and running as described in Getting cockroachDB running with Kubernetes and are using the Google Cloud console shell with the kubectl CLI.

I recommend that you save your commands in various scripts so you can repeat them or modify them later.  It's not necessary to work through this post to complete the API excercise, but it should provide a little extra insight to make the next section a little easier to understand.

Kubectl

So far you've used kubectl to issue instructions to Kubernetes. You may also have noticed that these are all reflected in various parts of the the cloud console - mainly under Kubernetes Engine, but some other places such as networking, storage and compute engine are also affected by kubectl commands too.

Kubectl is an extremely rich command line interface for interacting with a Kubernetes cluster. It acts in a kind of client server mode, allowing you to issue commands to cluster components, without actually being on it. However, there are times that it can be useful to run things directly in the sam environment as the cluster. For example, the service set up it Creating a microservice on Kubernetes is currently only accessible within the cluster environment, and you might want to go there directly to do some debugging. 

One way would be to attach to an exsisting pod, using kubectl exec, but since you want just a temporary pod, may as well pull the linux of your choice and run that interactively.

We'll use Ubuntu linux.  You'll also want an image that's already got curl installed (you'll need this shortly), and found one  on docker hub as below.
kubectl run play-around --rm -i --tty --image=tutum/curl -- bash

Here's what happens - in a matter of seconds you have your own linux


And you can use kubectl from another session to see its pod.
NAME                        READY     STATUS    RESTARTS   AGE
play-around-8cd77c8-q84pw   1/1       Running   0          6m


Digging around in the cluster

Kubernetes has its own DNS in the cluster. That means you access service by their names rather than their ip address. Back in Creating a microservice on Kubernetes , we created the playback-service that'll replay parameters and post bodies - so now we're actually on the same cluster it's possible to call that service directly, even though it's not exposed externally. And it works!

Let's try a POST.  

Now you have a way to try things out from the perspective of inside the cluster. 
  • Use "exit" to get out and return to your cloud shell. 
  • To attach to it again while the pod is still running - just replace the pod name.
kubectl attach play-around-5cb4cf76df-h9pq6 -c play-around -i -t
  • To delete
kubectl delete deployment play-around

Next step

After that diversion, and seeing that the service works perfectly within the cluster, we can get back to preparing to expose it externally. See Getting an API running in Kubernetes for how.






Why not join our forum, follow the blog or follow me on twitter to ensure you get updates when they are available.
Comments