Deploy ReactJS App Container to Kubernetes on Mac

In the previous post, we Dockerized the ReactJS App and were able expose it from our Container to our machine to run it in the browser on http://localhost:3000. Now we want our Docker containers to be Orchestrated using Kubernetes.

First, we need to enable Kubernetes from Docker Desktop settings. This will install Kubernetes with Apply and Restart option. Just follow the default options.

Verify the installation with to check Client and Server versions:

>kubectl version

Make sure the context is set to docker-desktop which can also be checked from the docker icon at the top.

>kubectl config current-context

docker-desktop

If the context is different (in case you’re also running MiniKube), we can switch it using:

>kubectl config use-context docker-for-desktop

Switched to context "docker-for-desktop"

Check cluster info:

>kubectl cluster-info

Kubernetes master is running at https://kubernetes.docker.internal:6443
KubeDNS is running at https://kubernetes.docker.internal:6443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy

Check the pods running in the cluster:

>kubectl get nodes

NAME             STATUS   ROLES    AGE   VERSION
docker-desktop   Ready    master   23h   v1.19.7

Install the Kubernetes Dashboard with:

>kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.0.0-rc3/aio/deploy/recommended.yaml

The Dashboard application will get deployed as a Pod in the kubernetes-dashboard namespace. We can get a list of all our Pods in all namespaces via the following command:

>kubectl get pods --all-namespaces

kubernetes-dashboard   dashboard-metrics-scraper-c95fcf479-8l8vf   1/1     Running   0          23h
kubernetes-dashboard   kubernetes-dashboard-5bc6d86cfd-6b68m       1/1     Running   1          23h

Just check if your kubernetes-dashboard-* pod is in running state. Now, start the local Proxy server to access your Dashboard:

>kubectl proxy

Starting to serve on 127.0.0.1:8001

Once the proxy server is started, you can access the Dashboard at:

http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy

To Login to the Dashboard, we’ll login using a token. The Token can be generated by running the command:

>kubectl -n kube-system describe secret $(kubectl -n kube-system get secret | awk '/^deployment-controller-token-/{print $1}') | awk '$1=="token:"{print $2}'

Now our basic setup is complete to get Kubernetes running on Mac.

Now we need to get our ReactJS App ready for Deployment on Kubernetes. Create the Deployment and Service manifest to run it on Kubernetes and expose the required port. Create the combined .yml file as below, however these can be created separately as well:

kind: Deployment
apiVersion: apps/v1
metadata:
  name: reactondocker
spec:
  replicas: 2
  selector:
    matchLabels:
      app: reactondocker
  template:
    metadata:
      labels:
        app: reactondocker
    spec:
      containers:
        - name: reactondocker
          image: myimage/reactondocker:latest
          imagePullPolicy: Always
          ports:
            - containerPort: 3000

---

kind: Service
apiVersion: v1
metadata:
  name: reactondocker
spec:
  type: NodePort
  ports:
    - port: 3000
      targetPort: 3000
      protocol: TCP
      nodePort: 30004
  selector:
    app: reactondocker
      

I’m using the NodePort Service to expose it on port 30004. Number of Pods to run is 2.

Note: If you’ve not pushed the image to a registry, then change imagePullPolicy: Never or IfNotPresent so it uses the local image created using Docker on your machine. Also, change the image name accordingly.

Run the below command to create the Deployment and the Service:

>kubectl create -f deployment.yml

deployment.apps/reactondocker created
service/reactondocker created

You can check the Pods running for reactondocker in your Kubernetes dashboard or with the below command:

>kubectl get pods

The status of the Pods should be running. Try accessing the Application in your browser as http://localhost:30004.

Finally, we should delete the ReactJS Application from the Kubernetes cluster:

>kubectl delete service,deployment reactondocker

service "reactondocker" deleted
deployment.apps "reactondocker" deleted

Kubernetes ReplicaSet example on Mac using VS Code

A ReplicaSet helps load balance and scale our Application up or down when the demand for it changes. It makes sure the desired number of pods are always running for high availability.

I’m using VS Code on Mac to create the below yaml file.

Create the following yaml file:

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: myapp-replicaset
  labels:
    app: myapp
spec:
  selector:
    matchLabels:
      app: myapp
  replicas: 3
  template:
    metadata:
      name: nginx-2
      labels:
        app: myapp
    spec:
      containers:
        - name: nginx
          image: nginx

The above yaml file has 4 main properties which are apiVersion, kind, metadata and spec. The spec contains the definition for the number of replicas and the containers to be created inside the pods.

Run the following command:

$ kubectl create -f ReplicaSetsDemo.yaml 

replicaset.apps/myapp-replicaset created

Now let’s check the status of the replicaSet and then the pods:

$ kubectl get replicaset
NAME               DESIRED   CURRENT   READY   AGE
myapp-replicaset   3         3         3       2m29s


$ kubectl get pods

NAME                     READY   STATUS    RESTARTS   AGE
myapp-replicaset-s7jm7   1/1     Running   0          33s
myapp-replicaset-svqvm   1/1     Running   0          33s
myapp-replicaset-xnbbq   1/1     Running   0          33s

The above command shows 3 pods created for nginx with the name of the replicaset prefixed. A replicaset ensures that sufficient number of replicas or pods are available at all times.

Now, let’s delete a pod:

$ kubectl delete pod myapp-replicaset-s7jm7

pod "myapp-replicaset-s7jm7" deleted

Check the status of the pods again:

$ kubectl get pods
                         
NAME                     READY   STATUS    RESTARTS   AGE
myapp-replicaset-d7f88   1/1     Running   0          36s
myapp-replicaset-svqvm   1/1     Running   0          5m53s
myapp-replicaset-xnbbq   1/1     Running   0          5m53s

Notice that there are still 3 pods running as one more pod was created to maintain the desired state. Also, if you try to create a pod with the same label app=myapp outside of the replicaset, it’ll still come under the purview of the replicaset we created and will terminate that pod to maintain the desired state of 3 replicas. This is where it differs from a Replication Controller.

Now, let’s edit the replicaset to scale it up as below:

$ kubectl edit replicaset myapp-replicaset

The above command let’s you edit the in-memory configuration file that Kubernetes creates. Search for the replicas section and edit it to 4 using the vi editor commands and save it with wq!

Upon saving you’ll see the output as:

replicaset.apps/myapp-replicaset edited

Check the pods status and you’ll see and additional pod created:

$ kubectl get pods
                            
NAME                     READY   STATUS    RESTARTS   AGE
myapp-replicaset-d7f88   1/1     Running   0          14m
myapp-replicaset-pnlvh   1/1     Running   0          55s
myapp-replicaset-svqvm   1/1     Running   0          19m
myapp-replicaset-xnbbq   1/1     Running   0          19m

Another way to scale the replicaset is to use the below command and check the status again:

$ kubectl scale replicaset myapp-replicaset --replicas=2

replicaset.apps/myapp-replicaset scaled


$ kubectl get pods

NAME                     READY   STATUS    RESTARTS   AGE
myapp-replicaset-svqvm   1/1     Running   0          22m
myapp-replicaset-xnbbq   1/1     Running   0          22m

Notice that the pods are scaled down to 2 only as other 2 got terminated.

Kubernetes Deployments demo with update and rollback

We’re going to follow this demo by creating a Deployment for nginx image. Below is the example yaml file that I’m using for creating the Deployment as deployment.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-deployment
  labels:
    tier: frontend
spec:
  replicas: 6
  template:
    metadata:
      name: nginx-2
      labels:
        app: myapp
    spec:
      containers:
        - name: nginx
          image: nginx
  selector:
    matchLabels:
      app: myapp

First we’ll create the deployment using the below command and record it:

$ kubectl create -f deployment.yaml --record

Now, let’s quickly check the status of the deployment:

$ kubectl rollout status deployment/myapp-deployment

The above command will give output as below:

Waiting for deployment "myapp-deployment" rollout to finish: 0 of 6 updated replicas are available...
Waiting for deployment "myapp-deployment" rollout to finish: 1 of 6 updated replicas are available...
Waiting for deployment "myapp-deployment" rollout to finish: 2 of 6 updated replicas are available...
Waiting for deployment "myapp-deployment" rollout to finish: 3 of 6 updated replicas are available...
Waiting for deployment "myapp-deployment" rollout to finish: 4 of 6 updated replicas are available...
Waiting for deployment "myapp-deployment" rollout to finish: 5 of 6 updated replicas are available...
deployment "myapp-deployment" successfully rolled out

To view the version history, run below command:

$ kubectl rollout history deployment/myapp-deployment

//You can see below output with change-cause..
deployment.apps/myapp-deployment 
REVISION  CHANGE-CAUSE
1         kubectl create --filename=deployment.yaml --record=true

Now let’s edit the deployment and change the nginx version to a lower version:

$ kubectl edit deployment myapp-deployment --record

Search for the image name and change the section as below and save with wq! vi command:

containers:
  image: nginx:1.18


//output after saving with wq!:
deployment.apps/myapp-deployment edited

Run the status command again to see the effect of Rolling updates:

$ kubectl rollout status deployment/myapp-deployment

You can also run the describe deployment command to check the effect as below:

$ kubectl describe deployment myapp-deployment


//Check the events section in the output as below:
Events:
  Type    Reason             Age                    From                   Message
  ----    ------             ----                   ----                   -------
  Normal  ScalingReplicaSet  13m                    deployment-controller  Scaled up replica set myapp-deployment-fd8649446 to 6
  Normal  ScalingReplicaSet  6m9s                   deployment-controller  Scaled up replica set myapp-deployment-ddbb47dd8 to 2
  Normal  ScalingReplicaSet  6m9s                   deployment-controller  Scaled down replica set myapp-deployment-fd8649446 to 5
  Normal  ScalingReplicaSet  6m9s                   deployment-controller  Scaled up replica set myapp-deployment-ddbb47dd8 to 3
  Normal  ScalingReplicaSet  5m40s                  deployment-controller  Scaled down replica set myapp-deployment-fd8649446 to 4
  Normal  ScalingReplicaSet  5m40s                  deployment-controller  Scaled up replica set myapp-deployment-ddbb47dd8 to 4
  Normal  ScalingReplicaSet  5m34s                  deployment-controller  Scaled down replica set myapp-deployment-fd8649446 to 3
  Normal  ScalingReplicaSet  5m34s                  deployment-controller  Scaled up replica set myapp-deployment-ddbb47dd8 to 5
  Normal  ScalingReplicaSet  5m27s                  deployment-controller  Scaled down replica set myapp-deployment-fd8649446 to 2
  Normal  ScalingReplicaSet  5m17s (x3 over 5m26s)  deployment-controller  (combined from similar events): Scaled down replica set myapp-deployment-fd8649446 to 0

The Annotations in the above description from the output after you run the describe command, will show the revision and the image is now nginx:1.18.

Let’s again change the nginx version using a set mage command and record it and check the status:

$ kubectl set image deployment myapp-deployment nginx=nginx:1.18-perl --record

Check the recorded versions again:

$ kubectl rollout history deployment/myapp-deployment


//output as below:
REVISION  CHANGE-CAUSE
1         kubectl create --filename=deployment.yaml --record=true
2         kubectl edit deployment myapp-deployment --record=true
3         kubectl set image deployment myapp-deployment nginx=nginx:1.18-perl --record=true

You can see above how we changed between different nginx versions and the reason for it got recorded. Verify your pods, as all 6 should be running:

$ kubectl get pods

Let’s rollback the last version and see how we move back to the previous version, then check the version again which should show as Revision 4:

$ kubectl rollout undo deployment/myapp-deployment

$ kubectl rollout status deployment/myapp-deployment

$ kubectl describe deployment myapp-deployment

//check the nginx image should be nginx:1.18 in the description..

Check the versions again:

$ kubectl rollout history deployment/myapp-deployment

deployment.apps/myapp-deployment 
REVISION  CHANGE-CAUSE
1         kubectl create --filename=deployment.yaml --record=true
3         kubectl set image deployment myapp-deployment nginx=nginx:1.18-perl --record=true
4         kubectl edit deployment myapp-deployment --record=true

Please note that the Revision 2 earlier now shows as Revision 4 after undo.

Once you’re done, delete the Deployments as below:

$ kubectl delete deployment myapp-deployment