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?
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?
To validate the behavior of your application when a specific microservice crashes, utilizing Istio's fault injection capabilities is the most appropriate approach. Istio allows for precise control to simulate various failure scenarios at the microservice level without causing broader disruption in the cluster. By using fault injection, you can introduce errors such as abrupt crashes or delays specifically to the microservice in question, thereby accurately observing the application's response under controlled and targeted fault conditions. This method ensures that other components in the system are not unintentionally affected, maintaining a more isolated and relevant testing environment for the microservice's failure behavior.
Answer is B. application crash, not node.
I see it the same way - it is b)
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.
Istio is replicated and replaced by Anthos service mesh, please update the answer.
Istio fault injection :https://istiobyexample.dev/fault-injection/
B seems correct. Istio's fault injection is right way to introduce fault.
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.
Probably C is the best to simulate the entire microservice crashing.
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.
destroying a node is not really testing microservices failure
B is ok
B is the correct answer
Isn’t Istio used in the context of Anthos vs. GKE?
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.
B is the correct option, if you deleted a node you will deleted more than the microservices that you wanted to eliminated.
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)
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.
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.
Between B and C. C is the wrong answer as the microservice may very well be running in one of the other nodes that were not destroyed.