프로젝트 아키텍처 및 TS 과정

 

1.아키텍처 개요

(1) 고객사 환경이 폐쇄망으로 운영되므로, 인바운드 요청이 불가능함

-> 따라서 고객사에서 주기적으로 Gitlab에 Polling함으로써 업데이트된 내용은 자동 배포하는 환경 구축

(2) K8s Node를 3개로 분산함으로써 가용성 확보.

-> Redis, Postgresql도 마찬가지로 이중화함으로써 가용성 확보

(3) Gitlab, Redis, Postgresql은 Helm을 통해 manifest.yaml을 커스터마이징해서 install

(4) 클라우드는 GCP 활용

 

Q. 왜 Node Affinity가 필요한가?

A. Node Affinity를 지정해야 Redis, Postgresql Master, replica pod가 각각 다른 K8s 노드에서 실행될 수 있음

-> 즉, Pod가 여러 노드에 분산되어 실행함을 보증하기 위해 Node Affinity 필요 

 

 

2.TS 과정

1.Gitlab을 Helm install 시 다수의 Pod가 생성됨

→ 이 때, 일부 Gitlab Pod가 Crashoff되는 현상 발생

→ Crashoff되는 현상을 해결하기 위해 문제에 대한 Deep-Dive 착수

 

(1)Gitlab Pod간 Dependency 확인

-Gitlab Pod간에는 Dependency로 인해 특정 Pod의 동작이 멈춘 경우, 다른 Pod가 연쇄적으로

멈추는 경우가 있을 것이라고 판단

→ CrashOff된 Pod간에 Dependency를 파악하고자 했으나, 특별한 Dependency가 없었음

 

(2) GCP Node Spec 확인

→ 여러 Gitlab Pod가 한 번에 동작할 때, GCP 노드에 필요한 메모리가 충분히 할당되어 있는지 확인

→ GCP Node Spec을 확인했을 때, 각각이 Memory Spec이 10GB였고, 이것이 문제의 원인일 것이라고 생각

-> Node Memory Spec을 100GB로 업그레이드 

→ 일부 Gitlab Pod가 CrashOff 되는 현상 해결

 

2.Gitlab webservice pod와 Redis, Postgresql pod가 연결되지 않는 현상 발생

→ Redis, Postgresql Pod가 각각은 제대로 동작하나, Gitlab Pod와 연결이 되지 않음

 

(1) Redis, Postgresql secret을 재생성 후 연결 시도

-Redis, Postgresql secret 재생성 후 Gitlab webservice pod의 yaml 파일을 업데이트해서

재연결 시도 했으나 연결되지 않음

 

(2) Redis, Postgresql PV, PVC 삭제 및 재생성 후 연결 시도

-Helm으로 Redis, Postgresql install 시 PV, PVC가 자동으로 생성되었음

→ 따라서, 이 부분까지 일괄적으로 삭제 및 재생성, Secret 재생성 후 연결 시도

→ 연결 문제 해결

 

 

3) 얻게 된 Insight

- Helm으로 Redis, Postgresql install 시 PV, PVC가 자동 생성되는데,

  이 경우 추후에 Secret을 재생성하더라도 해당 Secret이 PV, PVC의 존재로 인해 오버라이딩 되지 않음

→ 따라서 Redis, Postgresql Pod의 Secret 업데이트를 하려는 경우는,

    PV, PVC도 동시에 삭제 후 재생성해줘야 합니다

 

Q. 왜 Redis, PostgreSQL pod를 삭제해도 PV, PVC가 삭제되지 않나요?

A. 이는 k8s의 데이터 보호 메커니즘 때문입니다. 

    (1) PVC는 네임스페이스 리소스이며, 일반적으로 Pod와 같은 네임스페이스에 있습니다.

         Pod를 삭제해도 PVC는 그대로 유지됩니다.

    (2) PV는 클러스터 범위의 리소스로, PVC나 Pod의 생명주기와 독립적입니다.

    (3) 이는 데이터 손실을 방지하고, 필요시 같은 데이터로 새 Pod를 생성할 수 있게 하기 위함입니다.