color code markdown [ci skip]

Author: tanmaykm

WalkThrough.md

@@ -8,14 +8,14 @@ In this article, we shall launch a Kubernetes cluster on Azure and use it from J
 
 Start by deciding on the cluster name and region to launch it in.
 
-```
+```bash
 $ RESOURCE_GROUP=akstest
 $ LOCATION=eastus
 $ CLUSTERNAME="${RESOURCE_GROUP}cluster"
 ```
 
 Create a Resource Group to hold our AKS instance
-```
+```bash
 $ az group create --name $RESOURCE_GROUP --location $LOCATION
 {
   "id": "/subscriptions/b509b56d-725d-4625-a5d3-ae68c72f15b9/resourceGroups/akstest",
@@ -30,7 +30,7 @@ $ az group create --name $RESOURCE_GROUP --location $LOCATION
 ```
 
 Use the `az aks create` command to launch the cluster. We start only one node for this example, and use the defaults for most other options.
-```
+```bash
 $ az aks create --resource-group $RESOURCE_GROUP --name $CLUSTERNAME --node-count 1 --enable-addons monitoring --generate-ssh-keys
 {
   ...
@@ -49,7 +49,7 @@ $ az aks create --resource-group $RESOURCE_GROUP --name $CLUSTERNAME --node-coun
 ```
 
 To make it easy for us to connect to it from our local machine, fetch the cluster credentials and start a `kubectl proxy` process.
-```
+```bash
 $ az aks install-cli
 $ az aks get-credentials --resource-group $RESOURCE_GROUP --name $CLUSTERNAME
 $ kubectl proxy
@@ -60,7 +60,7 @@ Starting to serve on 127.0.0.1:8001
 
 We shall now try and explore the cluster using Kuber.jl. First, add the package and load it on to the Julia REPL.
 
-```
+```julia
 julia> using Pkg
 
 julia> Pkg.add("Kuber")
@@ -70,14 +70,14 @@ julia> using Kuber
 
 A cluster connection is represented by a `KuberContext` instance. A context encapsulates the TCP connection to the cluster, and connection options. By default, Kuber.jl attempts to connect to a local port opened through `kubectl proxy`. If you followed all the steps in the previous section to start the Azure AKS cluster, you would have already done that.
 
-```
+```julia
 julia> ctx = KuberContext()
 Kubernetes namespace default at http://localhost:8001
 ```
 
 Kubernets has multiple API sets and revisions thereof. We need to set the appropriate API versions to interact with our server. The `set_api_versions!` call detects the API versions supported and preferred by the server. They are stored in the context object to be used in subsequent communitcation.
 
-```
+```julia
 julia> Kuber.set_api_versions!(ctx; verbose=true)
 ┌ Info: Core versions
 │   supported = "v1"
@@ -137,7 +137,7 @@ Things in the cluster are identified by entities. Kubernetes `Pod`, `Job`, `Serv
 
 Now that we have set up our connection properly, let's explore what we have in our cluster. Kubernetes publishes the status of its components, and we can take a look at it to see if everything is fine. We can use Kuber.jl APIs for that. To do that we use the `get` API to fetch the `ComponentStatus` entity.
 
-```
+```julia
 julia> result = get(ctx, :ComponentStatus);
 
 julia> typeof(result)
@@ -146,7 +146,7 @@ Kuber.Kubernetes.IoK8sApiCoreV1ComponentStatusList
 
 Note that we got back a Julia type `Kuber.Kubernetes.IoK8sApiCoreV1ComponentStatusList`. It represents a list of `ComponentStatus` entities that we asked for. It has been resolved to match the specific to the version of API we used - `CoreV1` in this case. We can display the entity in JSON form in the REPL, by simply `show`ing it.
 
-```
+```julia
 julia> result
 {
   "apiVersion": "v1",
@@ -174,7 +174,7 @@ julia> result
 ```
 
 Or we can access it like a regular Julia type and look at individual fields:
-```
+```julia
 julia> for item in result.items
            println(item.metadata.name, " ", item.conditions[1]._type, " => ", item.conditions[1].status)
        end
@@ -185,7 +185,7 @@ etcd-0 Healthy => True
 
 Notice that APIs that fetch a list, have the entities in a field named `item`, and entities have thier name in the `metadata.name` field. We can list the namespaces available in the cluster, and now we can do it succintly as:
 
-```
+```julia
 julia> collect(item.metadata.name for item in (get(ctx, :Namespace)).items)
 3-element Array{String,1}:
  "default"    
@@ -195,14 +195,14 @@ julia> collect(item.metadata.name for item in (get(ctx, :Namespace)).items)
 
 And similarly a list of pods:
 
-```
+```julia
 julia> collect(item.metadata.name for item in (get(ctx, :Pod)).items)
 0-element Array{Any,1}
 ```
 
 We do not have any pods in the default namespace yet, because we have not started any! But we must have some system pods running in the "kube-system" namespace. We can switch namespaces and look into the "kube-system" namespace:
 
-```
+```julia
 julia> set_ns(ctx, "kube-system")
 
 julia> collect(item.metadata.name for item in (get(ctx, :Pod)).items)
@@ -220,7 +220,7 @@ julia> collect(item.metadata.name for item in (get(ctx, :Pod)).items)
 
 There! Now let's get back to the default namespace and start something of our own. How about a nginx webserver that we can access over the internet? Kubernetes entities can be created from their JSON specification with the `kuber_obj` utility API provided with Kuber.jl.
 
-```
+```julia
 julia> nginx_pod = kuber_obj(ctx, """{
            "kind": "Pod",
            "metadata":{
@@ -262,7 +262,7 @@ Kuber.Kubernetes.IoK8sApiCoreV1Service
 
 To create the pod in the cluster, use the `put!` API. And we should see it when we list the pods.
 
-```
+```julia
 julia> result = put!(ctx, nginx_pod);
 
 julia> collect(item.metadata.name for item in get(ctx, :Pod).items)
@@ -272,7 +272,7 @@ julia> collect(item.metadata.name for item in get(ctx, :Pod).items)
 
 We create the service, with an external LoadBalancer, to be able to access it from our browser:
 
-```
+```julia
 julia> result = put!(ctx, nginx_service)
 {
   "apiVersion": "v1",
@@ -313,7 +313,7 @@ julia> result = put!(ctx, nginx_service)
 
 Note that the `loadBalancer` status field is empty. It takes a while to hook up a load balancer to our service. We need to wait for it to be able to access our webserver!
 
-```
+```julia
 julia> while true
            println("waiting for loadbalancer to be configured...")
            sleep(30)
@@ -331,7 +331,7 @@ waiting for loadbalancer to be configured...
 
 Our web server is up! And we can fetch a page from it.
 
-```
+```bash
 shell> curl http://40.121.19.163/
 <!DOCTYPE html>
 <html>
@@ -364,13 +364,13 @@ Commercial support is available at
 
 Once we are done, we can delete the entities we created in the cluster with the `delete!` API.
 
-```
+```julia
 julia> delete!(ctx, :Service, "nginx-service");
 julia> delete!(ctx, :Pod, "nginx-pod");
 ```
 
 To delete the Kubernetes cluster, we can delete the resource group itself, which would also terminate the cluster created under it.
 
-```
+```bash
 $ az group delete --name $RESOURCE_GROUP --yes --no-wait
 ```