Spring cloud netflix + Kubernetes + Docker. Part II

Spring cloud netflix + Kubernetes + Docker

New article to deploy microservice on Kubernetes 

Execution

1º) We download rabbitmq image using the next command:

docker pull rabbitmq:3-management

2º) We download the code:

git clone https://github.com/davsuapas/KubernetesMicroservices.git

3º) We build the docker images of our services from project:

gradle clean build distDocker

4º) Checking that the docker images has been created:

docker images

5º) Launching the kubernetes cluster (from folder where we download kubernete repository), executing the next command into a new terminal:

sudo hack/local-up-cluster.sh

6º) We create all pods executing the next command from kubernete-config (into project repository) folder.

./createpods.sh

7º) Checking that all pods and kubernete service have been created correctly:

kubectl get pods, services

 

We can see that all have been created with running state. We can also see that both order and order line have a random name. This is because these pods can have multiple instances.

8º) Checking that the discovery service is working. So, we must find out the IP address assigned by kubernetes. We do this, running the command:

kubectl get -o json pod discovery

Once we get the result we seek the "podIP" word and get the address that we will use in the broswer.

We write in the browse http://172.17.0.3:8761/ and checking the services:

9º) We call order service using curl:

curl -s 172.17.0.4:8765/orders/orders/1 | jq .

We get the address of the previous figure in the eureka viewer. We look for the address assigned to edge. Edge will be the dispatcher to our order service.

 

10º) We simulate a shutdown OrderLine service, and we will see while the instance is shudown, the order service is still working correctly. It is possible, because hystrix manage the states of services and if there is error it will redirect the call to a method to work. In our case "defaultOrder" method.

 

Before we can see the state of services into monitor, we must get the address so monitor service as turbine service. We use the same way to get address, that we saw in the 8º) point.

kubectl get -o json pod monitor

kubectl get -o json pod turbine

We write in browse http://172.17.0.7:7979/ and the page we write http://172.17.0.5:8989/turbine.stream and click "monitor stream" button.

172.17.0.7 :  monitor address

172.17.0.5 :  turbine address

We can see that the circuit for order service is closed. This means that the circuit supports requests.

Now we going to drop orderline pod using the next command:

kubectl delete pod orderline-47fhv

orderline-47fhv: Depend of the name gaven by kubernetes.




The pods is dropped and automatically the system restart a new pod.

In the figure below we can see how the channel is open. This means you can not connect to OrderDetail and redirects the call to a failure method, which in our case return a order by default.



Order service work correctly, even if the circuit is open

Finally when the OrderLine service has been raised, the channel is again closed, and the service work fine.