Kubernetes 체험기 #2

해당 글은 구글 스터디잼 Kubernetes in the Google Cloud를 통해 경험한 내용을 바탕으로 합니다.

해당 과정의 Link는 https://run.qwiklabs.com/quests/29

이번 스터디 잼을 통해 Kubernetes를 이용하여 Blue-Green/Canary  배포를 해보고, Jenkins/MongoDB 등을 연동해보았다. 

다만, Kubernetes가 기존의 아키텍처를 추상화하였기에, Infrastructure as a Code를 구현할 수 있다는 체험을 했을 뿐이다. 각 명령어가 담고 있는 의미를 재해석하는 노력은 사용자 측면에서는 유의미할 수 있으나, 엔지니어 시점에서 다소 아쉬움이 남는다. 그래서 이번 포스팅을 하며 쓰고 지우기를 반복했다. 

이번 포스팅에서는 지난주에 실습했던 Kubernetes의 각 Component 중 궁금했던 부분들을 정리해보고자 한다. 아래의 내용은 Kubernetes in action를 참고하였습니다.

우선 Pod와 관련하여.. Kubernetes는 Container를 직접 생성하고 동작시키지 않는다. 'kubectl run' 명령으로 ReplicationController(혹은 Replicaset)이 생성되고, 이 ReplicationController가 Pod 객체를 생성한다. 이에 클러스터 외부에서 해당 포드에 접근하려면 ReplicationController가 관리하는 Pod를 Service와 연결시키면된다. 만약 Pod가 누락되면 ReplicationController는 대체할 새로운 Pod를 만든다. 그리고 Service는 새로운 Pod의 IP와 연결되기에 Pod가 어떠한 이유로 제거되더라도 사용자에게 영향이 미치지 않는다.

그렇다면 왜 Container를 직접 사용하지 않을까

Container는 프로세스 자체가 하위 프로세스를 생성하지 않는한 Container당 하나의 프로세스만 실행하도록 설계됐다. 따라서 IPC로 통신하거나 로컬로 저장된 파일을 통해 통신하는 여러 프로세스로 구성된 애플리케이션의 경우 하나의 Container로 묶는데 한계가 있다. 이에 Container를 단일 단위로 관리할 수 있는 상위 레벨로 Pod를 두어 격리한 것으로 보인다. Pod 내의 모든 Container는 동일한 네트워크 및 네임스페이스에서 실행되기에 IPC 통신이 가능하며, 볼륨을 사용하여 파일시스템도 공유할 수 있다.

그렇다면 ReplicationContoller는 어떤 방식으로 동작할까

실행중인 포드의 목록을 지속적으로 모니터링하고 실제 포드 수와 원하는 수가 일치하는지를 확인한다. 이때 ReplicationController가 Pod를 소유하고 있는 개념은 아니기에 필요에 따라 포드를 이동할 수 있으며 이 경우 ReplicationController는 포드가 사라진 것을 알아채면 새로운 포드로 교체한다.

(Replicaset, Deployment는 ReplicationController의 동일한 기능을 제공하면서 추가 확장 기능이 있다.(포드 셀렉터 등))

한가지 또 궁금한 점이 있다.

외부에 노출지점(DMZ를 담당하는?) Service는 각 Pod를 어떻게 구분하는 것일까. 그리고 JWT를 사용하지 않고 Session으로 인증/인가를 구현할 경우 HA proxy의 sticky session과 같은 기능은 어떻게 구현할 수 있을까

우선 서비스는 FQDN, 별칭 등으로 외부서비스를 참조할 수 있고, Pod는 FQDN, 환경변수, DNS 등을 통해 서비스와 연결될 수 있다.

Service의 sessionAffinity 속성을 None대신 ClinetIP로 설정할 경우 서비스 프록시가 같은 클라이언트 IP로 부터 발생한 모든 요청을 같은 포드로 리다이렉트한다. (물론 None 설정하더라도 keep-alive 연결로인해 브라우저 요청의 경우 같은 포드로 연결된다.) 하지만 이는 쿠키기반이 아니다. Kubernetes가 Application Layer(osi 7layer 기준)수준에서 동작하지 않기 때문이다. 

아키텍처상 Service를 LoadBalancer(SNAT 방식) 혹은 Ingress로도 대체할 수 있다. 이때 Ingress의 경우 Application Layer에서 동작하기에 쿠키 기반의 세션 친화성 기능을 제공한다.

기본 개념들도 제대로 학습하려다 보니 꽤나 방대한데, configMap, metadata와 같은 설정들, statefulSet 등의 기능뿐만 아니라 실제 Kubernetes를 운영하면서 고려해야할 성능/보안 등의 이슈들까지 공부하려면 가볍게 접근할 주제는 아닌 것 같다. 이번 스터디 잼에서는 한번 Kubernetes를 맛봤다는데에 의의를 두는 것이 좋겠다.