Skip to content

Kubernetes

1. Overview

Setup
  • Each student should launch one instance of the k8s-helm branch (9eb0508e) from my profile csc468ngo.
  • When it gets to the Parameterize stage, set the following options
    • Number of nodes (3 or more): 3
    • CloudLab user ID to deploy K8s from (should be your CloudLab ID. Defaulted to none): This should be your CloudLab user ID.
    • `Number of cores in each node (4 or more): 4
    • MB of RAM in each node: 8192
  • For cluster selection, go with Emulab
  • Once the experiment is ready and all startup are Finished, run the following to confirms:
kubectl get nodes
  • In the figure below, you can see that I have 4 nodes, when I launched a 4-nodes experiment. You should see a list of 3 nodes (1 head and 2 workers).

4-node Kubernetes cluster

kubectl to manage everything - You will:

  • Create a pod
  • Expose it via service
  • Deploy it with replication

12: Your Goal This Week

  • Rebuild the RAMCoin miner in Kubernetes

  • Learn:

  • YAML object creation

  • Pod and service exposure
  • Logging and troubleshooting

From design to deployment: this is cloud engineering in action.

13: Coming Up

  • Kubernetes Dashboard
  • Namespaces
  • CI/CD pipelines and Helm
  • Securing services

14: Key Takeaways

  • Design is only the beginning
  • Deployment is the real engineering
  • Kubernetes is not just a tool — it's your platform

You don’t run containers. You orchestrate services.

3. Kubernetes: Pods, Service, Deployment

Info

  • Pod: group of containers sharing IP and volumes
  • Service: stable access to dynamic pod groups
  • Deployment: declarative state, rolling updates
  • NodePort*- and Ingress**: access from outside the cluster
Overview
  • This is done via Kubernetes Objects, described through YAML files.
  • Kubernetes objects are persistent entities in the Kubernetes system, which represent the state of your cluster.
    • What containerized applications are running (and on which nodes)
    • The resources available to those applications
    • The policies around how those applications behave, such as restart policies, upgrades, and fault-tolerance
  • A Kubernetes object is a "record of intent"--once you create the object, the Kubernetes system will constantly work to ensure that object exists. By creating an object, you're effectively telling the Kubernetes system what you want your cluster's workload to look like; this is your cluster's desired state.
  • Documentation
Terminologies: Pods
  • Pod: Smallest deployable units of computings that can be created and managed in Kubernetes
  • A pod can contain one or more containers with shared storage and network resources and specifications for how to run the containers.
  • Create the following file called nginx.yml

  • Deploy the pod:
kubectl apply -f nginx.yml
kubectl get pods
kubectl describe pods nginx
  • How to access this nginx container?
Terminologies: Service
  • Service: A method of exposing network application running as one or more Pods without making any changes to the application.
  • Each Service object defines a logical set of endpoints (usually endpoints are pods) along with a policy about how to make those pods accessible.
  • For exposing Service to an external IP address, there are several types:
    • ClusterIP
    • NodePort
    • LoadBalancer
    • ExternalName
  • ClusterIP: expose service onto a cluster-internal (Kubernetes) IP. For world access, Ingress needs to be used.
  • NodePort: Expose the service on each Node (worker computers) at a static port.

  • Deploy the service:
kubectl apply -f nginx-svc.yml
kubectl get svc
kubectl describe svc nginx
  • Visit the headnode of your Kubernetes cluster at the nodePort 30007.
Terminologies: Deployment
  • Deployment: provides declarative updates for Pods (and ReplicaSets) .
    • A desired state is described in a Deployment.

  • Deploy the application:
kubectl delete pods nginx
kubectl delete svc nginx
kubectl apply -f nginx-deployment.yml
kubectl get deployment nginx-deployment
kubectl get svc
kubectl describe svc nginx
kubectl get pods
kubectl describe pods nginx
  • Visit the headnode of your Kubernetes cluster again at the nodePort 30007.
  • Delete the deployment
kubectl delete deployment nginx-deployment

4. Kubernetes Dashboard

Deploy the dashboard
  • Run the following commands 
cd /local/repository
bash launch_dashboard.sh
  • Go to the head node URL at port 30082 for kubernetes-dashboard
  • Hit skip to omit security (don't do that at your job!).
Kubernetes namespace
  • Provides a mechanism for isolating groups of resources within a single cluster.
  • Uniqueness is enforced only within a single namespace for namespaced objects (Deployment and Services)
  • Uniquess of other cluster-wide objects (StorageClass, Nodes, PersistentVolumes, etc) is enforced across namespaces.
  • Run the following commands from inside the ram_coin directory
  • namespaces, namespace or ns
kubectl get namespaces
kubectl get ns
kubectl get namespace
  • Using --namespace or -n let you specify a namespace and look at objects within that namespace.
  • Without any specification, it is the default namespace (default)
kubectl get ns
kubectl get pods -n kubernetes-dashboard
kubectl get pods
kubectl get services --namespace kubernetes-dashboard
kubectl get services

5. More Kubernetes Deployment

Launch ram_coin on Kubernetes
  • First, we deploy a registry service. This is equivalent to a local version of Docker Hub.
    • Only one member of the team does this
cd
kubectl create deployment registry --image=registry
kubectl expose deploy/registry --port=5000 --type=NodePort
kubectl get deployment
kubectl get pods
kubectl get svc

Pod registry

  • We can patch configurations of deployed services to set a specific external port. 
kubectl patch service registry --type='json' --patch='[{"op": "replace", "path": "/spec/ports/0/nodePort", "value":30000}]'
kubectl get svc
  • You can see the external port has now been changed (patched)

Patched pod registry

Building and pushing images for ramcoin
  • We test our local registry by pulling busybox from Docker Hub and then tag/push it to our local registry. 
docker pull busybox
docker tag busybox 127.0.0.1:30000/busybox
docker push 127.0.0.1:30000/busybox
curl 127.0.0.1:30000/v2/_catalog
  • Next, we clone ramcoin repository
cd
git clone https://github.com/CSC468-WCU/ram_coin.git
cd ram_coin
docker-compose -f docker-compose.images.yml build
docker-compose -f docker-compose.images.yml push
curl 127.0.0.1:30000/v2/_catalog
kubectl create deployment redis --image=redis
for SERVICE in hasher rng webui worker; do kubectl create deployment $SERVICE --image=127.0.0.1:30000/$SERVICE:v0.1; done
kubectl expose deployment redis --port 6379
kubectl expose deployment rng --port 80
kubectl expose deployment hasher --port 80
kubectl expose deploy/webui --type=NodePort --port=80
kubectl get svc
  • Identify the port mapped to port 80/TCP for webui service. You can use this port and the hostname of the head node from CloudLab to access the now operational ram coin service. 
$ kubectl get svc
$ kubectl get pods
Exercise
  • Patch the webui service so that it uses port 30080 as the external port

6. Automated Kubernetes Deployment

Ramcoin dpeployment 
kubectl create namespace ramcoin
kubectl create -f ramcoin.yaml --namespace ramcoin
kubectl get pods -n ramcoin
kubectl create -f ramcoin-service.yaml --namespace ramcoin
kubectl get services --namespace ramcoin
Automated recovery
  • Check status and deployment locations of all pods on the head node
kubectl get pods -n ramcoin -o wide
  • SSH into worker-1 and reset the Kubelet. Enter y when asked. 
sudo kubeadm reset
  • Run the following commands on head to observe the events
    • After a few minutes, worker-1 becomes NotReady via kubectl get nodes
    • After five minutes, kubectl get pods -n ramcoin -o wide will show that pods on worker-1 being terminated and replications are launched on worker-2 to recover the desired state of ramcoins.
    • The five-minute duration can be set by the --pod-eviction-timeout parameter. 
kubectl get nodes
kubectl get pods -n ramcoin -o wide