[Kubernetes] Session Affinity를 통해 Sticky Session 설정을 해보자.

Kubernetes Service

• Service는 다른 Pod의 요청이나 외부 클라이언트로부터 오는 HTTP 요청에 모두 응답한다.
  외부 클라이언트가 서비스에 대한 요청을 하려면, 서비스를 노출시키기위해 L4로드밸런서를 사용하는 경우가 일반적이다. 이를 통해 외부 클라이언트의 트래픽이 서비스에 전달된다. 이러한 시나리오에서는 외부 클라이언트 요청을 받는 것이 주요 역할이라고 보면 된다.

Session Affinity 란?

• Kubernetes의 Service에서 Session Affinity라는 기능은 NCP 에서 Sticky Session과 같은 기능이다.
• 클라이언트의 연결을 특정 인스턴스 또는 Pod에 유지시키는 기능이다.
• 클라이언트가 처음으로 연결을 요청한 인스턴스 또는 Pod에 대해서는 세션을 연결주고, 동일한 클라이언트의 후속 요청은 동일한 인스턴스 또는 Pod에 연결된다.
  

예를 들어, 로그인 세션, 장바구니 정보 등을 특정 인스턴스 또는 Pod에 유지하여 일관된 상태를 유지할 수 있다.

Kubernetes에 Service를 생성하는 예시이다.
위 Service는 L4 Layer에서 동작하기 때문에 패킷을 처리하고 페이로드에 대해서는 신경쓰지 않는다.
HTTP와 같은 L7 Layer에서는 쿠키 기반의 세션 유지가 가능하지만, Service는 그러한 기능을 직접적으로 제공하지 않는다.

• Service의 'sessionAffinity'를 설정할 때, 주로 Client IP를 지정하여 세션 유지를 구현한다.
  • Client IP를 기준으로 세션을 유지하면, 동일한 Client IP를 가진 요청은 항상 동일한 Pod로 전달되어 세션 연결을 유지할 수 있다.
  • 쿠키 기반의 세션 유지는 L7 Layer에서 동작하기 때문에 Service 수준에서 직접 제공되지 않는다. 대신, 일부 Ingress Controller나 애플리케이션 자체에서 쿠키 기반의 세션 유지를 구현할 수 있다.
    쿠키 : 클라이언트와 서버 간의 상태 정보를 저장하는 작은 데이터 조각, 웹 브라우저는 서버로부터 받은 쿠키를 저장하고, 이후에 같은 서버에 요청을 보낼 때 쿠키를 함께 전송하여 상태 정볼르 유지한다.

Sticky Session 실습

• 우선 Kubernetes 클러스터에 연결하자.

kubectl config use-context <context-name>

여기서 context-name 은 kubectl config get-contexts로 알 수 있다.

• 다음으로 SessionAffinity를 가진 서비스를 생성하자.
  나는 'my-service'라는 이름의 서비스를 생성하고 'ClientIP' SessionAffinity를 사용했다.
• 서비스를 확인하여 Session Affinity 설정이 제대로 적용되었는지 확인하자.

kubectl get service my-service

• 생성된 서비스의 Session Affinity 설정을 확인한다.

kubectl describe service my-service

'my-service'의 세부 정보를 확인 한 결과 Session Affinity 필드가 ClientIP로 설정되어있어 클라이언트IP에 따라 Session Affinity가 설정되어 클라이언트IP로 들어오는 요청이 항상 같은 Pod로 라우팅 된다는 의미이다.
'Endpoints'필드에서 '198.18.3.126:8080,198.18.3.139:8080,198.18.3.62:8080'와 같이 나열된 IP 주소는 현재 'my-service'에 연결된 Pod의 IP주소와 포트를 나타낸다.

따라서 'Session Affinity'가 'ClientIP'로 설정되었고, 'Endpoints'에서 확인한 IP 주소가 요청을 처리하는 Pod의 IP 주소임을 알 수 있다.

이를 통해 Session Affinity가 제대로 설정되고 동작하고 있음을 확인할 수 있다.