You are developing your microservices application on Google Kubernetes Engine. During testing, you want to validate the behavior of your application in case a specific microservice should suddenly crash. What should you do?
A.
Add a taint to one of the nodes of the Kubernetes cluster. For the specific microservice, configure a pod anti-affinity label that has the name of the tainted node as a value.
B.
Use Istio's fault injection on the particular microservice whose faulty behavior you want to simulate.
C.
Destroy one of the nodes of the Kubernetes cluster to observe the behavior.
D.
Configure Istio's traffic management features to steer the traffic away from a crashing microservice.
I think that c) is not the correct answer.
I am not a GKE or Kubernetes expert, so maybe I am wrong.
My understanding is, that in Kubernetes a microservice can run on pods on different nodes and one node can contain pods running differend microservices - so to kill one node will not kill a microservice but several pods running on that node. Please correct me if I am wrong.
Fault injection is a technique used in chaos engineering to deliberately introduce errors into a system to test its resilience and observe its behavior under failure conditions. Istio is a service mesh that can manage the traffic between microservices. It includes fault injection capabilities that enable you to simulate failures such as delays or crashed services without actually stopping the service or damaging the environment. This allows you to validate how the rest of your application reacts to the failure of a specific microservice.
Testing Objective: The choice between options B and C depends on the testing objectives. If the goal is to understand the behavior of the system when a specific microservice fails (this is how the question is formulated), then a targeted approach (Option B) is more appropriate. If the goal is to understand the broader resiliency of the system to node failures, then Option C would be more relevant.
Microservice Focus: Given the question's focus on a specific microservice, Istio's fault injection (Option B) provides a more direct and controlled way to simulate the failure of that microservice and observe the system's response, aligning better with the scenario described.
Selected Answer: B
Kill one randomly selected k8s cluster node doesn't guarantee you kill pods of the microservice. The node could or colud not have microservices of that app running on it.
IMHO the right answer is C. This link clearly explains why (remember that we are in a testing environment, so what's the problem in generating a cras of an entire node of the cluster?):
https://www.linkedin.com/pulse/google-cloud-architect-case-study-5-biswa-prakash-nayak/
The problem is that according to the question: "During testing, you want to validate the behavior of your application in case a specific micsoservice should suddenly crash"....Even on testing environment specific microservice can run on more then one node and not on the one you destroyed.....moreover you should not affect other parts o the application (other microservices running on the destroyed node)
https://istiobyexample.dev/fault-injection/
In a Kubernetes environment, you can approach chaos testing at different layers - for instance, by deleting pods at random, or shutting off entire nodes.
But failures also happen at the application layer. Infinite loops, broken client libraries - application code can fail in an infinite number of ways! This is where Istio fault injection comes in. You can use Istio VirtualServices to do chaos testing at the application layer, by injecting timeouts or HTTP errors into your services, without actually updating your app code. Let’s see how.
So both C and B work.
I think perhaps C is correct due to the very specific test scenario. Chaos testing would be great for generally resilience test but it wants to test the behaviour of the app when the microservice crashed. Shutting down the microservice seems the simplest way to test this scenario.
I agree, mostly because we are in a testing environment, so a node crash is not a great disaster even if there are other microservices running in thst node's pods.
A voting comment increases the vote count for the chosen answer by one.
Upvoting a comment with a selected answer will also increase the vote count towards that answer by one.
So if you see a comment that you already agree with, you can upvote it instead of posting a new comment.
TotoroChina
Highly Voted 3 years, 3 months agoXDevX
3 years, 3 months agoXDevX
Highly Voted 3 years, 3 months agoplumbig11
Most Recent 3 months, 3 weeks agode1001c
4 months, 2 weeks agohzaoui
9 months agoammonia_free
9 months, 2 weeks agospuyol
9 months, 3 weeks agoJoeJoe
11 months, 1 week agoGino17m
6 months agoMiguelMiguel
12 months agosomeone2011
1 year, 1 month agosomeone2011
1 year, 1 month agorakp
1 year, 1 month agoBiddlyBdoyng
1 year, 4 months agoJoeJoe
11 months, 1 week agoBeCalm
1 year, 7 months agoroaming_panda
1 year, 9 months agosurajkrishnamurthy
1 year, 10 months agoale_brd_111
1 year, 10 months agomegumin
1 year, 11 months ago