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 exercise, but it should provide a little extra insight to make the next section a little easier to understand.
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 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 existing 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
After that diversion, and seeing that the service works perfectly within the cluster, we can get back to preparing to expose it externally.