Deploying Containers Across Cluster

Step 1 - Start Kubernetes

As described in your (Adding Additional Nodes)[/courses/kubernetes/add-additional-nodes-to-cluster] scenario, to begin you need to launch the main Kubernetes cluster and then add the additional Kubelet and Proxy on each node.

Task

Run the following command first to deploy the Kubernetes cluster.

launch.sh

Once the cluster has started, attach the second node.

docker run -d --name=kubs \ --net=host --pid=host --privileged=true \ --volume=/:/rootfs:ro --volume=/sys:/sys:ro \ --volume=/dev:/dev --volume=/var/lib/docker/:/var/lib/docker:rw \ --volume=/var/lib/kubelet/:/var/lib/kubelet:rw \ --volume=/var/run:/var/run:rw \ gcr.io/google_containers/hyperkube:v1.2.2 \ /hyperkube kubelet \ --allow-privileged=true --containerized --enable-server \ --cluster_dns=10.0.0.10 --cluster_domain=cluster.local \ --config=/etc/kubernetes/manifests-multi \ --hostname-override="[[HOST2_IP]]" \ --address=0.0.0.0 --api-servers=http://[[HOST_IP]]:8080 docker run -d --name=proxy \ --net=host --privileged \ gcr.io/google_containers/hyperkube:v1.2.2 \ /hyperkube proxy \ --master=http://[[HOST_IP]]:8080 --v=2

You can view the nodes using kubectl get nodes

Step 2 - Scheduling Policy

Kubernetes manages and controls which Pods should be deployed onto which host. By default, Kubernetes uses a spread policy to evenly distribute the required Pods across the available nodes.

If more Pods are requested, it will allocate them to the most suitable node based on the available resources.

Task

Run the following command to deploy two separate HTTP services, each with two replicas.

kubectl run http-app-a --image=katacoda/docker-http-server:latest --replicas=2 kubectl run http-app-b --image=katacoda/docker-http-server:latest --replicas=2

Kubernetes will manage how to spread these nodes and replicas across the available cluster. Listing all the containers on both machines should indicate that one from each deployment is on each node.

docker ps --filter="ancestor=katacoda/docker-http-server:latest"

Describing the deployment for an app should give you insights into how it's been deployed.

kubectl describe deployment http-app-a

Step 3 - Node Selectors

It is possible to give hints to the scheduler about where certain Pods should be deployed. These hints allow you to specify certain labels, or properties, that the host has defined. This is commonly used to specify resource properties, such as high-cpu or SSD disks, allowing Kubernetes to deploy the Pod onto the most suitable host.

To provide a hint you add a nodeSelector to the container spec. This takes a key/value property that will be matched to key/value properties defined on hosts.

nodeSelector:
   disktype: ssd

A complete example can be viewed with cat nodeSelectedPod.yaml

If a Pod does not contain a nodeSelector, then Kubernetes will use it's own scheduling policy approach.

Define Node Selector for Second Host

The first task is to define a label for our second host based on it's name, in this case it's IP address.

kubectl label nodes [[HOST2_IP]] disktype=ssd

Deploy Pod

Deploying the above Pod should always result in it being deployed onto our second host. If the second host is available, the deployment will wait until a host with the matching selector becomes available.

Deploy the Pod using kubectl create -f nodeSelectedPod.yaml

Once launched, you should see the new deployment on the second host.

docker ps --filter="ancestor=nginx:alpine"

Welcome!

Congratulations!

You've completed the scenario!

Scenario Rating

Steps