In HW2, you created two docker containers – a client which continuously makes requests to a server which will respond with some message. In HW3 you enabled upgrading the server (with a new message). In HW4, you'll expand this to run in Kubernetes, with some modifications - namely, the server returns it's own hostname and some hard coded message.
Note: njsapp that I provided includes the hostname, so you just need to extend that a bit.
PART 1:
Server must: 1) be able to scale out, 2) tolerate failure.
Use ReplicationController and a Service.
Server instances must run on machine2 (need nodeSelector)
Client must run on machine3 (need nodeSelector)
PART 2:
Now, support upgrades. Without bringing down the server.
Easiest way will be create a deployment (which will launch new Pods), then delete the Replication controller. You could also delete the Replication controller without deleting the Pods (recall kubectl delete rc <name> --cascade=false won't delete the pods), then launch a Deployment.
https://upendra-kumarage.medium.com/kubernetes-replicationcontrollers-deployments-and-update-existing-replicationcontroller-to-3b0ecf0bf349
Then, demonstrate an upgrade by changing the message of the server.
HAND IN:
1) Dockerfiles (even if they were unchanged from what was handed out),
2) Build scripts (builds container and pushes to registry),
3) yaml files,
4) README with exact sequence of commands to run to verify all of the above (including killing some pods, scaling out, changing to a deployment, and then upgrading the server).
Assumptions:
* I (and your peer) have Kubernetes installed with 3 VMs (machine1-3), I (and your peer) will have a Registry running at 192.168.33.10:5000
* Each Student will put all of their files in a unique directory. <firstname>_HW4
/home/vagrant/eric_HW4
/home/vagrant/karl_HW4
* Image names and resource names should all start with student's first name.
e.g., eric-njsapp, eric-njsapp-svc, etc.
