[k8s] 쿠버네티스의 StatefulSet, Ingress, Autoscaler

StatefulSet

Stateless Application: 

Web Server가 여기 해당된다. (APACHE HTTP Server, Nginx, IIS app이 여러개 배포되더라도 모두 동일한 기능을 수행

 

그래서 app이 죽으면 단순히 동일한 app을 하나 더 만들면 된다.

 

반드시 볼륨이 필요하진 않음. 만약 app의 로그를 영구적으로 저장하고 싶은 경우 각각의 볼륨이 아닌 단일 볼륨으로 충분한 경우가 많음.

 

들어오는 트래픽을 여러 앱에 동일하게 분산시켜야 함. (네트워크의 연결은 단순 분산 용도)

 

즉, 쿠버네티스의 ReplicaSet에 해당함

 

 

 

Stateful Application:

Database 등이 여기 해당된다. (mongoDB, MariaDB, redis app이 여러개 배포되더라도 각각의 역할이 있음)

 

따라서 app이 죽으면 상황에 맞게 특정한 app을 복구해야 한다. 각각의 역할이 다른 만큼 볼륨도 각각에 맞게 필요하다. 그래야 특정 app이 죽어도 새 app이 각각의 볼륨가 연결되면서 해당 역할을 이어갈 수 있기 때문이다. 

 

앱들의 특성에 맞게 트래픽이 분산되어야 한다. stateless Application과 달리 네트워크의 연결에 의도가 있다는 뜻이다.

 

즉, 쿠버네티스의 StatefulSet에 해당함.

 

 

 

StatefulSet  vs  ReplicaSet

StatefulSet와 ReplicaSet의 차이는 아래 사진과 같다.

 

replicas를 n으로 생성할 경우 ReplicaSet은 Pod의 이름이 랜덤으로 생성 되고, StatefulSet에는 Ordinal Index 이름으로 생성된다.

 

Pod가 생성될 때 ReplicaSet은 동시에, StatefulSet은 순차적으로 생성된다.

 

Pod가 재생성 되는 경우 ReplicaSet은 랜덤으로 새롭게 이름을 생성하고, StatefulSet은 기존과 동일한 이름으로 Pod가 생성된다.

 

만약 Replicas가 0으로 변경될 경우 ReplicaSet은 Pod들이 동시에 삭제되는 반면 StatefulSet은 index가 높은 Pod부터 순차적으로 삭제된다. 

 

 

 

둘의 차이는 PVC를 다룰 때도 차이가 있다. 

 

ReplicaSet을 생성할 때 Pod에 PV를 연결하려면 직접 PVC를 생성해주어야 한다. 반면 StatefulSet은 volumeClaimTemplate을 사용하여 PVC를 자동으로 생성하고 Pod에 연결할 수 있다. 

따라서 ReplicaSet은 생성되는 Pod들이 모두 같은 PVC를 연결하지만, StatefulSet의 경우 Pod마다 PVC를 다르게 설정할 수 있다. 

 

StatefulSet으로 만들어진 Pod2가 삭제되고 다시 만들어지면 기존에 있던 PVC-2와 다시 연결된다. 즉, Pod가 삭제되도 PVC는 남아있는다는 말이다.

 

 

 

ReplicaSet은 각 노드들과 PVC가 같은 노드에 있어야 연결할 수 있다. 만약 Pod-913jg가 PVC1과 다른 노드에 존재한다면 연결할 수 없다. 따라서 템플릿 안에 nodeSelector: 를 지정해서 노드를 정해줘야 한다. 

반면 StatefulSet은 알아서 노드와 동일한 위치에 PVC들을 만들어주기 때문에 균등하게 배포할 수 있다.

 

ReplicaSet에서 nodeSelector를 사용하지 않고 여러 개의 Pod들을 생성할 경우 PVC와 다른 node에 생성된 Pod엔 오류가 발생하는 걸 확인할 수 있다. 

 

 

 

 

StatefulSet 만들 때 ServiceName이라는 속성으로 서비스 이름을 넣을 수 있는데 이 이름과 매칭되는 Headless 서비스를 만들게 되면 만들어진 Pod의 예측 가능한 도메인 이름이 만들어지게된다.

따라서 InternalServer의 특정 pod에서 원하는 pod로 연결할 수 있다.  

 

 

 

 

 

 

 

Ingress

쿠버네티스에서는 Ingress Controller를 사용하여 도메인으로 들어오는 트래픽을 각 서비스에 맞는 Pod로 분산시킬 수 있다.

 

Ingress 를 이용하면 Canary Upgrade도 수행할 수 있다. 

 

Ingress Controller를 사용하여 쿠버네티스로 들어오는 트래픽의 일부만 특정 Service로 분산 시키는 방법으로 신규 서비스를 테스트할 수 있다.

 

우리는 Ingress 를 생성하여 다음과 같은 룰들을 지정할 수 있다. 

 

이런 Ingress를 생성했다면 Ingress Controller를 설치하여 적용시켜야 한다.

동작을 위해선 별도의 플러그인인 nginx, kong등을 설치해야한다. 만약 Nginx를 설치한다면 deployment와 replicaset이 생성되고 실제 ingress의 구현체인 ingress pod가 생성된다. 

 

이 ingress pod가 ingress rule이 있는지 확인하고 rule대로 service들에 연결해주는 역할을 하게 된다. 

 

또한 외부에서 ingress pod에 접근할 수 있도록 service를 만들어줘야 하는데 직접 쿠버네티스를 설치했다면 NodePort를 사용, 클라우드 서비스를 이용하고 있다면 LoadBalancer를 사용하여 외부에서 접근할 수 있도록 해준다. 

 

Ingress는 여러 개 설정할 수 있다. 

 

 

 

Ingress 기능 3가지

 

1. Service Loadbalancing

Ingress rule을 정의하여 요청한 path에 알맞은 서비스로 LoadBalancing을 할 수 있다.

 

 

2. Canary Upgrade

기존과 동일한 host로 serviceName만 다르게 Ingress를 생성하여 트래픽의 일부만 새로 생성한 Service로 분산시켜 Canary Upgrade를 진행할 수 있다. 

이때 weight를 지정하여 얼마의 트래픽을 새로 생성한 svc-v2로 보낼건지 지정할 수 있다.

또한 특정 나라별로 테스트하고 싶다면 헤더 옵션을 사용하여 Language: kr인 요청이 오면 svc-v2로 보낼 수도 있다. 

 

 

3. 인증서 관리

Ingress를 생성할 때, tls라는 옵션으로 secret name으로 실제 secret 오브젝트를 연결하고 이 secret 안에 인증서를 담아서 구성하면 사용자가 도메인 앞에 https://를 붙여야만 접근할 수 있게된다. 

 

이 secret안에는 data값으로 인증서를 담고 있다. 

 

 

 

 

Autoscaler

쿠버네티스의 Autoscaler에는 3가지가 있다. Pod의 개수를 증가시키는 HPA(Horizontal Pod Autoscaler), Pod의 리소스를 증가시키는 VPA(Vertical Pod Autoscaler), 클러스터에 노드를 추가하는 CA(Cluster AutoScaler)가 있다. 

 

3개 중 가장 많이 사용되는 HPA에 대해 알아보자.

 

HPA (Horizontal Pod Autoscaler)

Pod의 개수를 조절하는 Autoscaler 이다.

트래픽이 증가하여 현재 동작중인 Pod의 리소스 자원이 모두 사용되는 상황에 도달하게 될 경우, 사전에 정의한 HPA가 Controller의 replicas를 조절하여 Pod의 개수를 조절한다.

 

Pod의 개수가 수평적으로 증가하는 것을 Scale Out / 줄어드는 것을 Scale In이라고 합니다. (수직적으로 증가하는 것은 Scale up이라고 함)

 

장애 복구가 신속하게 이루어져야하므로 App에서 권장을 한다.  자체의 기동 시간이 오래 걸리는 App에는 권장하지 않음. Pod의 수평적 증가만이 일어나므로 모든 pod의 역할이 같은 stateless app에서만 가능.

 

예를들어 stateful app 중 master, slave Pod가 있다고 가정해보자. HPA는 master, slave Pod중 어떤걸 scale up 해야할 지 알 수 없다.  

 

 

 

HPA의 아키텍처는 다음과 같다.

 

Master Node에는 쿠버네티스의 중요 기능을 하는 컴포넌트들이 Pod형태로 띄워져있고 여기엔 Deployment, ReplicaSet, HPA 등등이 있다. 

 

 

HPA가 Pod의 개수를 관리하는 동작 프로세스는 아래와 같다. 

 

쿠버네티스 설치 시 kubelet이라는 것이 각각의 노드마다 설치되고, 노드 자신에게 있는 파드들을 관리한다. 

 

사용자가 ReplicaSet을 생성하면 kube-apiserver를 통해 pod 생성 요청이 kubelet에게 전달되고 전달된 요청은 각 노드에서 Container를 만들게 된다. 

 

HPA가 각 Pod의 성능을 분석하는 방법은 Resource Estimator인 cAdvisor가 kubelet에 메모리 정보를 전달하는 방식이다. 그럼 metrics-server가 각각의 노드에 있는 kubelet을 통해 리소스 정보를 가져와서 다른 컴포넌트들이 사용할 수 있도록 kube-apiserver에 등록한다. HPA는 여기 등록된 정보를 받아갈 수 있고, 15초마다 체크를 하고 있다가 적절히 Scale Out, Scale In을 진행하는 프로세스이다.