[Kubernetes] 쿠버네티스 설치하기 (6) - Running Multiple Instances of Your App

Running Multiple Instances of Your App

Running Multiple Instances of Your App

Objectives

• Scale an app using kubectl.

Scaling an application

In the previous modules we created a Deployment, and then exposed it publicly via a Service. The Deployment created only one Pod for running our application. When traffic increases, we will need to scale the application to keep up with user demand.

Scaling is accomplished by changing the number of replicas in a Deployment

---

이전에 deployment를 생성할 때 아무런 옵션을 주지않아 1개의 pod만 생성되었다.

그러나 트래픽이 증가한다면 1개로는 여유가 없을 것이기 때문에 scaling이 필요하다!

Scaling 이란 deployment할 때 replicas의 개수를 늘리면 된다!

 

 

 

 

지금은 왼쪽처럼 하나의 Pod만 생성되어 있을 것이다.

 

 

 

 

 

 

 

 

하나였던 Pod를 여러 Node에 나눠서, 혹은 같은 Node에 여러개의 Pod를 만들어보자.

 

 

 

Scaling out a Deployment will ensure new Pods are created and scheduled to Nodes with available resources. Scaling will increase the number of Pods to the new desired state. Kubernetes also supports autoscaling of Pods, but it is outside of the scope of this tutorial. Scaling to zero is also possible, and it will terminate all Pods of the specified Deployment.

---

Scaling out Deployment는 새로운 Pod가 생성되고, 사용가능한 리소스를 가지고있는 Node에 예약될 것이라고 한다.

쿠버네티스는 상태에 따라 Pod의 개수가 조절할 수 있는 autoscaling도 가능한데 튜토리얼 에서는 넘어간다고 한다.

scaling을 0으로하면 모든 Pod가 파괴된다고 한다.

 

 

Running multiple instances of an application will require a way to distribute the traffic to all of them. Services have an integrated load-balancer that will distribute network traffic to all Pods of an exposed Deployment. Services will monitor continuously the running Pods using endpoints, to ensure the traffic is sent only to available Pods.

---

여러개의 application이 실행되면 traffic을 분배 해야한다. 이 역할을 Service의 load-balancer로 가능하단다.

Service가 Pod들의 실행 상태를 관찰하고 있다가 traffic 을 사용가능한 Pod에 분배한다고 한다.

 

 

Once you have multiple instances of an Application running, you would be able to do Rolling updates without downtime.

---

application을 다중으로 띄우면 멈출 필요없이 지속적인 업데이트가 가능하다!

 

 

kubectl get deployments

• NAME lists the names of the Deployments in the cluster.
• READY shows the ratio of CURRENT/DESIRED replicas
• UP-TO-DATE displays the number of replicas that have been updated to achieve the desired state.
• AVAILABLE displays how many replicas of the application are available to your users.
• AGE displays the amount of time that the application has been running.

 

kubectl get rs

ReplicaSet은 항상 [DEPLOYMENT-NAME]-[RANDOM-STRING]와 같은 포맷으로 NAME이 정해진다

RANDOM은 pod-template-hash seed를 사용하여 생성한다고 한다.

• DESIRED displays the desired number of replicas of the application, which you define when you create the Deployment. This is the desired state.
• CURRENT displays how many replicas are currently running.

 

 

kubectl scale 을 사용하여 생성되어있는 deployments의 replicas 갯수를 늘려보자!

kubectl scale deployments/kubernetes-bootcamp --replicas=4

이제 우리는 4개의 사용가능한 application instances 가지고 있는것이다.

 

kubectl get pods -o wide

4개로 늘어난 만큼 알아서 분배가 되었다!

이미지에서도 나타나있지만 현재 나의 환경은 Master Node 1대, Slave Node 2대로 구성되어 있다. 쿠버네티스가 알아서 적절히 2개 2개씩 분배를 해놓은 것 같다.

 

kubectl describe deployments/kubernetes-bootcamp

replica set이 변경된 Event를 볼 수 있다.

 

 

---

kubectl describe services/kubernetes-bootcamp

생성되어있단 Service의 Endpoints도 저렇게 추가가 되었다.

 

kubectl scale deployments/kubernetes-bootcamp --replicas=2

replicas를 2개로 낮추자

 

kubectl get deployments

실제 접근가능한 Endpoints가 줄었다.

kubectl get pods -o wide

실행중인 pod의 갯수도 2개로 줄어든것을 확인할 수 있다.

 

 

---

iptables를 이용해서 Service가 어떻게 Endpoint를 찾아가는지, 이전글(morian-kim.tistory.com/23)을 보면 한대여서 별다른 조건없으 그냥 바로 가게되어있었는데 2개를 추가하자 이상한 조건이 달려있는것을 확인할 수 있었다.

50% 확률로 KUBE-SEP-DJG3MTVKM2YZS4P5 로 점프되고 아니면 KUBE-SEP-GMIHPQM65OT2VI7J로 하게되어있다.

[KUBE-SEP-DJG3MTVKM2YZS4P5]

[KUBE-SEP-GMIHPQM65OT2VI7J]

 

random을 이용하여 분배하는 방식이 기발하다.

 

3개의 replicas 일 경우

처음은 1/3, 다음은 1/2 이렇게 되어있다.

 

iptables를 이용하여 random하게 해놓은이유는 우리가 만든 Service의 Type이 NodePort 때문인 것으로 보인다.

LoadBalance Type으로 하면 라운드로빈, 해쉬 여러 방식으로 사용할 수 있을 듯 싶은데 이는 진행하면서 배워봐야 겠다.

 

끝!