중급(?) 코스로 가기 전에

큰 그림을 그려봅시다

리뷰

앞서 심플 코스에서는 관리 클러스터로 kind 를 사용하고 워커로드로 managed cluster 를 생성했습니다.
kind의 경우는 주로 개발용으로 사용됩니다.
여러가지 이유가 있겠지만 kind가 docker에 종속적이기 때문에 운영체제 위에서 동작하는 쿠버네티스에 비해 의존적이고 기능상의 확장성이 떨어진다는 점이 프로덕션용으로 쓰이기에 부적합한 것이 아닐까 합니다.
워크로드 역시 managed cluster로 생성해서 주도권이 클라우드 제공업체에 있기 때문에 커스텀이 어렵습니다.

배경

중급 코스에 걸맞게 관리 클러스터를 k8s로, 워크로드를 일반 cluster로 생성해 봅시다.
세팅에 좀더 손이 가긴 하지만 그만큼 할 수 있는 것이 늘어납니다.

종전에는 관리 클러스터는 워크로드를 생성하는 것 외에 별 다른 역할이 없었습니다.
특히 CI/CD를 중점으로 보면 워크로드의 클러스터마다 argocd를 설치하여 각각 배포를 관리했습니다.
지금은 워크로드가 1개지만 비지니스가 복잡해지면 워크로드가 100개가 될 수도 있습니다.
100개의 클러스터와 argocd를 관리하고 각각 application를 등록해서 관리하는 걸 상상해 봅시다.
생각만해도 머리가 아프네요.

목적

관리 클러스터의 기능을 확장시켜서 이 문제들을 해결해 봅시다.
모든 워크로드의 argocd를 관리 클러스터로 통합합니다.

1. 워크로드 클러스터가 추가될 때 '자동'으로 argocd 등록됩니다.
   자동! 이 중요합니다.

2. 워크로드 application 배포를 관리 클러스터에서 제어합니다.
   배포를 중앙에서 관리하는 것이죠.

방법

어떻게 하면 될까요?
한정된 자원이지만 가능한 한 프로덕션과 유사하게 설정해 봅시다.

0. devops 환경을 준비합니다.

devops 시리즈를 참고하세요!

1. 관리 클러스터를 K8S로 생성합니다.

우리는 오라클 사에서 제공하는 K8S 서비스인 oke를 사용합니다.
프리티어로 가입하면 무료로 제공되는 서비스입니다.

2. 관리 클러스터에 NLB, Ingress Nginx, SSL을 설정합니다.

L4계층에 네트워크 로드밸런싱, 인그레스로는 Nginx class 를 사용하여 이렇게 하면 단일 IP를 노출하고 여러 개의 도메인을 연결할 수 있습니다. 보안상 https 적용은 기본이겠죠? cert-manager과 Let's 인증서로 ssl/tsl을 설정합니다.

3. 관리 클러스터에 argocd를 설치하고 dashbord를 외부에서 접근할 수 있도록 합니다.

다중 클러스터 배포를 할 수 있도록 argocd 설치하고 대시보드를 도메인과 연결합니다.

4. 일반 및 Managed 클러스터 워크로드를 각각 생성합니다.

여러 종류의 클러스터에 잘 배포되는지 확인하기 위해 일반 및 OKE 클러스터를 생성합니다.
우리는 각각 1개씩 워크로드 클러스터를 생성해 보겠습니다.

5. 관리 클러스터에 클러스터 정책을 적용합니다.

관리 클러스터에서 워크로드 클러스터를 추가하면 자동으로 워크로드의 클러스터가 관리 클러스터의 argocd에 등록되도록 합니다.

일반적으로 관리클러스터에서 워크로드를 생성할 때, 관리 클러스터가 해당 워크로드에 접근할 수 있도록 지정한 네임스페이스에 secret(워크로드명-kubeconfig)이 함께 생성됩니다. 반면, argocd는 별도의 네임스페이스(argocd) 내에 존재하며 사용할 수 있는 리소스의 형식(kind)이 다르기 때문에 argocd에서 워크로드에 접근할 때는 해당 secret을 사용할 수 없습니다.

워크로드의 secret을 argocd의 cluster 형태로 등록해 주면 이 문제가 해결됩니다. argocd dashbord에서 수동으로 등록할 수 있지만 우리는 워크로드가 생성될 때 자동으로 이를 수행하도록 관리 클러스터에 kyverno 클러스터 정책을 적용할 것입니다. 지금은 클러스터 정책이라는 개념이 좀 낮설 수 있지만 함께 실습해보면 좀더 친숙해 질 것입니다.

6. 관리 클러스터에서 워크로드 클러스터에 애플리케이션 배포합니다.

관리 클러스터의 argocd에 워크로드 클러스터가 등록되었기 때문에 동일한 애플리케이션을 우리는 100개의 워크로드에 한 번에 배포할 수 있습니다. 물론 실제 서비스에서는 이렇게 하지 않지만 배포 시뮬레이션을 단순화하면 그렇습니다. 이를 위해 ApplicationSet 리소스를 정의하고 적용할 것입니다.

나아갈 방향

위 아키텍처는 약간 아쉬운 부분이 남아 있습니다.

1. 워크로드 생성 후 수동으로 설정해야 하는 부분이 많습니다.
   CNI, CCM 설치를 자동화할 수 있을 것 같습니다.
   엔지닉스 인그레스도 자동 적용할 수 있으면 좋을 것 같습니다.
   클러스터 정책 부분을 좀더 검토해 보아야 합니다.

2. Application 배포 시 ApplicationSet을 디테일하게 설정할 수 있어야 실제 프로덕션 배포에 적용 가능할 것으로 보입니다.

3. 사실 같은 앱을 여러 클러스터에 걸쳐서 배포한다는 것은 다중 클러스터 인그레스 및 트래픽 분산이 전제가 됩니다. 이 부분은 해당 포스팅의 범위를 벋어나기 때문에 포함하지 않았지만 간단히 소개하면 크게 네 가지 방법이 있습니다.

1. 멀티 클러스터 인그레스 컨트롤러
   멀티 클러스터 인그레스 컨트롤러는 여러 클러스터에 걸쳐 인그레스 리소스를 관리할 수 있게 해줍니다. 이를 통해 단일 인그레스 정의를 사용하여 여러 클러스터에 걸쳐 서비스에 대한 트래픽을 분산시킬 수 있습니다. Google Cloud의 Multi-cluster Ingress는 이러한 방법을 지원합니다.
2. 서비스 메시
   서비스 메시는 트래픽을 여러 클러스터에 걸쳐 분산시키는 데 사용할 수 있는 또 다른 방법입니다. Istio는 멀티 클러스터 서비스 메시를 지원하며, 이를 통해 트래픽을 여러 클러스터에 걸쳐 분산시킬 수 있습니다.
3. 클러스터 페더레이션
   Kubernetes Federation을 사용하면 여러 클러스터를 하나의 논리적 클러스터로 관리할 수 있습니다. 이를 통해 트래픽을 여러 클러스터에 분산시킬 수 있습니다.
4. 글로벌 로드 밸런서
   클라우드 제공자가 제공하는 글로벌 로드 밸런서를 사용하여 트래픽을 여러 클러스터에 분산시킬 수도 있습니다. 예를 들어, AWS의 Route 53, Google Cloud의 Global Load Balancer 등이 있습니다.

참고: https://medium.com/google-cloud/navigating-scalability-and-efficiency-with-gcp-multi-cluster-ingress-f7e8f960c772

워커 클러스터가 2개로 제한적이라 테스트 서버로 1개, 운영 서버로 1개를 사용할 예정이라 아직 필요하지는 않지만
추후 규모를 확장해야 할 때를 대비하여 공부해 두면 좋을 듯합니다.

그 외에도 채워나가야 하는 부분이 많지만 개발의 매력 중 하나는 끊임없이 개선할 수 있는 점이 아닐까 합니다.
어제 보이지 않던 개선점이 오늘은 보이고 리팩토링 할 수 있다는 것은 참 즐거운 일입니다.
(물론 일이 많으면 마음의 짐....)