Home Explore Blog CI



kubernetes

2nd chunk of `content/en/blog/_posts/2017-02-00-Highly-Available-Kubernetes-Clusters.md`
5a27caca1237945442560f905937df3c1ec8fc257dd07c2100000001000009c1
kubernetes-minion-group-6s52 Ready                 39m

kubernetes-minion-group-cw8e Ready                 48m

kubernetes-minion-group-fw91 Ready                 48m

kubernetes-minion-group-h2kn Ready                 31m

kubernetes-minion-group-ietm Ready                 39m

kubernetes-minion-group-j6lf Ready                 31m

kubernetes-minion-group-soj7 Ready                 31m

kubernetes-minion-group-tj82 Ready                 39m

kubernetes-minion-group-vd96 Ready                 48m
  ```



As we can see, we have 3 master replicas (with disabled scheduling) and 9 worker nodes.



We will deploy a sample application (nginx server) to verify that our cluster is working correctly:  


 ```
$ kubectl run nginx --image=nginx --expose --port=80
  ```



After waiting for a while, we can verify that both the deployment and the service were correctly created and are running:  


 ```
$ kubectl get pods

NAME                READY STATUS RESTARTS AGE

...

nginx-3449338310-m7fjm 1/1 Running 0     4s

...


$ kubectl run -i --tty test-a --image=busybox /bin/sh

If you don't see a command prompt, try pressing enter.

# wget -q -O- http://nginx.default.svc.cluster.local

...

\<title\>Welcome to nginx!\</title\>

...
  ```



Now, let’s simulate failure of one of master’s replicas by executing halt command on it (kubernetes-master-137, zone europe-west1-c):  


 ```
$ gcloud compute ssh kubernetes-master-2d4 --zone=europe-west1-c

...

$ sudo halt
  ```



After a while the master replica will be marked as NotReady:  


 ```
$ kubectl get nodes

NAME                      STATUS                   AGE

kubernetes-master         Ready,SchedulingDisabled 51m

kubernetes-master-2d4     NotReady,SchedulingDisabled 8m

kubernetes-master-85f     Ready,SchedulingDisabled 4m

...
  ```



However, the cluster is still operational. We may verify it by checking if our nginx server works correctly:




 ```
$ kubectl run -i --tty test-b --image=busybox /bin/sh

If you don't see a command prompt, try pressing enter.

# wget -q -O- http://nginx.default.svc.cluster.local

...

\<title\>Welcome to nginx!\</title\>

...
  ```



We may also run another nginx server:




 ```
$ kubectl run nginx-next --image=nginx --expose --port=80
  ```



The new server should be also working correctly:




 ```
$ kubectl run -i --tty test-c --image=busybox /bin/sh

If you don't see a command prompt, try pressing enter.

# wget -q -O- http://nginx-next.default.svc.cluster.local

Title: Verifying and Testing HA Cluster Functionality
Summary
The provided text details the process of verifying and testing the functionality of a High Availability (HA) Kubernetes cluster. It includes steps to deploy an Nginx server to confirm the cluster's operational status, simulating a master replica failure by halting one of the master nodes, and verifying that the cluster remains operational by confirming the Nginx server still works and deploying a new one. This demonstrates the HA cluster's resilience to node failures.