5. 쿠버네티스 인그레스, AWS LB Controller, External DNS Controller 이해

이번 장은 AWS Load Balancer Controller와 External DNS Controller를 이용하여 쿠버네티스 인그레스(Ingress)를 실습을 통하여 알아보겠습니다. 먼저 인그레스의 개념을 알아봅니다.

클러스터 외부에서 클러스터 내부의 파드로 접속하는 방법은 앞장에서 배운 쿠버네티스 서비스의 노드포트, 로드밸런서, 그리고 이번 장에서 배울 인그레스가 있습니다. 쿠버네티스 인그레스는 노드포트, 로드밸런서 타입의 서비스와 달리 도메인(host)과 Path 기반으로 연결이 가능하여 일반적으로 가장 많이 사용하고 있습니다. 전통적인 의미의 L4, L7 스위치로 구분한다면 인그레스는 L7 기능을 지원합니다. 

인그레스의 주요 기능은 아래와 같습니다.

. Path(경로) 기반 라우팅: 인그레스는 들어오는 요청의 경로를 기준으로 적절한 내부 파드로 라우팅합니다. 예를 들어, ‘/api’ 경로로 들어오는 요청은 백엔드 API 서비스로 전달할 수 있습니다.

. 가상 호스트 기반 라우팅: 인그레스는 요청된 도메인 이름을 기준으로 가상 호스트를 설정하여 서로 다른 도메인 또는 서브도메인으로 접근하는 요청을 서비스로 전달할 수 있습니다. 예를 들어 argocd.myweb.com과 grafana.myweb.com으로 도메인을 구분하여 연결합니다.

. SSL 인증서 관리: 인그레스는 HTTPS 프로토콜을 지원하며, SSL 인증서를 관리하여 암호화된 통신을 제공할 수 있습니다. 인그레스 컨트롤러에서 인증서를 처리하고 인그레스 컨트롤러와 내부 파드 간 연결은 평문(http)으로 통신합니다. 백엔드 파드 단에서 인증서 관리를 하지 않아 관리 편의성을 향상합니다.

. 로드 밸런싱: 인그레스는 여러 개의 백엔드 서비스에 대한 로드 밸런싱을 지원하여 트래픽을 분산시킵니다. 백엔드 서비스 간에 트래픽을 균등하게 분배하거나, 특정 규칙에 따라 트래픽을 전달할 수 있습니다.

이번 장의 실습을 위해서는 사전에 AWS Route 53에 도메인이 등록되어 있어야 합니다. 테스트 용도의 회사 도메인 또는 Route 53 홈페이지와 구글 검색 등을 통하여 각자 실습에 필요한 개인 도메인을 준비 바랍니다.

1. AWS Load Balancer Controller + External DNS Controller 이해

AWS EKS 환경에서는 관리 편의와 성능 향상을 위하여 Load Balancer Controller와 External DNS Controller를 사용할 수 있습니다.

먼저, AWS Load Balancer Controller(이하 LB Controller)는 쿠버네티스 환경에서 외부 CSP(Cloud Service Provider)의 로드 밸런서 서비스를 관리하기 위한 오픈 소스 프로젝트입니다. 이 컨트롤러는 쿠버네티스 애플리케이션을 위한 로드 밸런서를 생성, 구성 및 관리하는 역할을 수행합니다. LB Controller를 사용하면 기존 ALB(Application Load Balancer)에서 목적지 파드로 직접 연결이 가능하여 네트워크 홉(Hop)을 기존 4단계에서 2단계로 줄일 수 있습니다.

LB Controller는 쿠버네티스 인그레스 리소스와 함께 사용되어 클러스터 내부의 서비스에 대한 외부 트래픽을 관리합니다. 쿠버네티스 인그레스 매니페스트(명세서, YAML 파일)를 기반으로 외부의 AWS Application Load Balancer(ALB) 또는 Network Load Balancer(NLB)를 생성하고 구성합니다. 

LB Controller는 다음의 기능을 제공합니다:

. 로드 밸런서 생성 및 구성: LB Controller는 쿠버네티스 인그레스 리소스를 기반으로 ALB 또는 NLB를 생성하고 관리합니다. 애플리케이션 요구 사항에 맞게 로드 밸런서를 구성할 수 있으며, SSL/TLS 인증서 관리, 경로 기반 라우팅, 세션 관리 등 다양한 설정을 지원합니다.

. AWS Auto Scaling 그룹과 통합: LB Controller는 외부의 AWS Auto Scaling 그룹과 사용되어 로드 밸런서가 자동으로 서버 인스턴스를 조정하도록 지원합니다. Auto Scaling 그룹 내의 인스턴스 확장 및 축소를 자동으로 감지하고 로드 밸런서 구성을 업데이트하여 자동으로 트래픽을 분산시킵니다.

다음으로 External DNS Controller는 인그레스 리소스에 인레스에 사용할 DNS을 등록하면 이를 기반으로 DNS 컨트롤러가 AWS Route 53 DNS 레코드를 자동으로 관리하는 오픈 소스 컨트롤러입니다. 이를 통해 쿠버네티스 내의 서비스나 Ingress 리소스가 배포되거나 변경될 때, 해당 정보가 AWS의 DNS 서비스인 Route 53에 자동으로 반영됩니다. 기존에 수동으로 등록하여 발생할 수 있는 실수 등을 방지할 수 있습니다.

간단한 사용 예시입니다.

. 인그레스 리소스에서 www.myweb.com 도메인에 대한 서비스를 생성합니다.

.  AWS External DNS Controller가 이를 자동으로 감지하고 AWS Route 53에서 www.myweb.com에 대한 새 DNS 레코드를 생성합니다.

. 사용자가 www.myweb.com에 접근하면 자동으로 쿠버네티스 클러스터의 해당 서비스로 라우팅됩니다.

이러한 기능으로 AWS External DNS Controller는 쿠버네티스와 AWS Route 53 간의 연계를 간소화하고 자동화합니다, 그로 인해 운영 팀은 DNS 관리에 들이는 수고와 시간을 크게 줄일 수 있습니다.

2. IRSA(Identity and Access Management Roles for Service Accounts) 이해

LB Controller 실습에 앞서 설치에 필요한 IRSA를 알아보겠습니다. LB Controller는 EKS 외부의 AWS 로드밸런서와 Auto Scaling 그룹을 관리하므로 해당 자원에 대한 추가 권한이 필요합니다. 이렇게 EKS 외부 자원의 권한을 획득하기 위하여 AWS는 IRSA를 사용합니다. 

IRSA는 AWS에서 제공하는 기능으로, 쿠버네티스 클러스터 내의 Service Account에 대한 AWS Identity and Access Management (IAM) 역할을 연결합니다. Service Account란 쿠버네티스 클러스터 내의 애플리케이션을 위해 특별히 디자인된 계정 형태입니다. 이는 클러스터 내의 리소스에 접근하거나 조작할 때 사용할 수 있는 자격 증명을 제공합니다. 일반적으로, 파드가 특정 리소스에 접근할 필요가 있을 때 Service Account를 사용하게 됩니다.

내부 리소스가 아닌 외부 AWS 리소스를 사용하면 파드는 AWS 클러스터 자격 증명을 사용합니다. 그러나 파드는 AWS API에 직접 액세스할 수 없어 파드가 실행중인 노드의 AWS IAM 역할로 대신하여 액세스를 시도합니다. 하지만 이로 인해 보안상의 문제가 발생할 수 있습니다.

IRSA를 사용하면 파드가 특정 AWS 리소스에 대한 접근 권한을 필요로 할 때, 해당 Service Account에 연결된 AWS IAM 역할을 사용하여 인증 및 인가를 수행할 수 있습니다. IRSA를 설정하기 위해 다음 단계를 수행해야 합니다:

. 쿠버네티스에서 Service Account를 생성합니다.

. AWS IAM에서 Service Account를 위한 IAM 역할(Role)과 정책(Policy)을 생성합니다.

. 쿠버네티스 클러스터에서 IRSA 리소스를 생성하고 Service Account와 IAM 역할을 연결합니다.

. 파드 매니페스트에서 Service Account를 사용하도록 지정합니다.

IRSA를 사용하면 쿠버네티스 클러스터 내에서 AWS 리소스에 대한 권한을 더 정밀하게 제어할 수 있으며, 파드는 AWS API에 직접 액세스할 필요 없이 IAM 역할을 통해 안전하게 리소스에 접근할 수 있습니다. 이를 통해 보안을 강화하고 권한 관리를 개선할 수 있습니다.

IRSA 생성은 eksctl 명령어로 가능합니다. 하지만 코드가 아니라 향후 재사용 등의 관리 어려움이 있습니다. 따라서 테라폼 코드를 관리하는 것을 추천합니다.

LB Controller에서 사용하는 IRSA는 아래의 테라폼 모듈을 사용합니다.

IRSA.tf

module "load_balancer_controller_irsa_role" {
  source = "terraform-aws-modules/iam/aws//modules/iam-role-for-service-accounts-eks"

  role_name                              = "load-balancer-controller"
  attach_load_balancer_controller_policy = true

  oidc_providers = {
    ex = {
      provider_arn               = module.eks.oidc_provider_arn
      namespace_service_accounts = ["kube-system:aws-load-balancer-controller"]
    }
  }

  tags = local.tags
}

. oidc_providers.namespace_service_accounts 

AWS IAM과 Role에 연결할 Service Account 이름을 지정합니다. LB Controller에 사용할 이름은 일반적으로 변경하지 않고 aws-load-balancer-controller 그대로 사용합니다.
기존 EKS를 생성한 테라폼 코드에서 위 irsa.tf를 추가하여 LB Controller 용 Role과 Policy를 생성합니다.

tf plan -out planfile
tf apply planfile

적용이 완료되면 AWS 콘솔에서 생성된 리소스를 확인할 수 있습니다.

3. AWS LB Controller 및 External DNS Controller 설치

이제 IRSA 준비가 완료되었으므로 헬름을 이용하여 LB Controller, External DNS Controller를 설치합니다. 헬름 설치 방법은 기존과 동일합니다.

$ (⎈ |switch-oregon-stage:kube-system) helm repo add eks https://aws.github.io/eks-charts
$ (⎈ |switch-oregon-stage:kube-system) helm pull eks/aws-load-balancer-controller
$ (⎈ |switch-oregon-stage:kube-system) tar xvfz aws-load-balancer-controller-1.4.8.tgz
$ (⎈ |switch-oregon-stage:kube-system) cd aws-load-balancer-controller
$ (⎈ |switch-oregon-stage:kube-system) cp values.yaml ci/my-values.yaml

이제 aws load balancer controller 헬름을 설치합니다. 아래 my-values.yaml 파일과 헬름 차트는 필자의 깃헙에서 확인할 수 있습니다.

serviceAccount:
  create: true
  name: aws-load-balancer-controller
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::$ACCOUNT_ID:role/load-balancer-controller
clusterName: $CLSTER_NAME

. serviceAccount.name
IRSA 생성 시 사용한 aws-load-balancer-controller 이름을 동일하게 사용합니다.  

. serviceAccount.annotations
위에서 생성한 IRSA의 ROLE ARN 정보를 아래 스크린샷을 참고하여 입력합니다. IRSA – Roles 메뉴에서 load-balancer-controller를 검색하면 Role을 확인할 수 있습니다. 해당 Role의 상세 정보를 확인하면 ARN 정보를 확인할 수 있습니다.

. clusterName
각자 cluster 이름을 입력합니다.

위 my-values.yaml 기준으로 kube-system 네임스페이스에 설치합니다.

$ (⎈ |switch-singapore-test:kube-system) cd aws-load-balancer-controller/aws-load-balancer-controller-1.4.8 
$ (⎈ |switch-singapore-test:kube-system) helm install aws-load-balancer-controller -n kube-system -f my-values.yaml .
NAME: aws-load-balancer-controller
LAST DEPLOYED: Fri Jun  9 09:31:05 2023
NAMESPACE: kube-system
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
AWS Load Balancer controller installed!

설치가 완료되면 LB Controller 파드를 확인할 수 있습니다.

$ (⎈ |switch-singapore-test:kube-system) k get pod
NAME                                            READY   STATUS    RESTARTS   AGE
aws-load-balancer-controller-7654f65466-hjtc5   1/1     Running   0          50s
aws-load-balancer-controller-7654f65466-mmd98   1/1     Running   0          50s

설치한 LB Controller 동작 확인은 이 후 인그레스 실습에서 진행하겠습니다. 다음으로 AWS External DNS Controller를 설치합니다. 

AWS LB Controller와 동일하게 외부 Route 53 리소스를 제어하므로 External DNS Controller 용도의 IRSA 설정이 필요합니다.

module “external_dns_irsa_role” {
  source = “terraform-aws-modules/iam/aws//modules/iam-role-for-service-accounts-eks”

  role_name                     = “external-dns”
  attach_external_dns_policy    = true
  external_dns_hosted_zone_arns = [“arn:aws:route53:::hostedzone/{HOSTED_ZONE_ID}”]

  oidc_providers = {
    ex = {
      provider_arn               = module.eks.oidc_provider_arn
      namespace_service_accounts = [“kube-system:external-dns”]
    }
  }

  tags = local.tags
}

. external_dns_hosted_zone_arns 
Route 53에서 사전에 준비한 도메인의 {HOSTED_ZONE_ID} 정보를 아래 스크린샷 정보를 참고하여 입력합니다. AWS Route 53 콘솔에서 ‘Hosted zone details’ 메뉴를 선택하면 됩니다.

HOSTED_ZONE_ID 정보를 각자 정보로 변경하고 설치를 진행합니다.

수정한 코드로 테라폼 코드를 실행합니다. ‘tf plan’으로 미리 결과를 확인하고 의도한 상태이면 ‘tf apply’를 실행합니다.

tf plan -out planfile
tf apply planfile

IRSA 준비가 되었으므로 External DNS Controller 헬름 차트를 배포합니다. (필자 깃헙 소스 참조)

헬름 Value 파일

serviceAccount:
  create: true
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::${aws_account_id}:role/external-dns

 $EXTERNAL_DNS_ROLE_ARN
위에서 생성한 IRSA 실행 결과로 생성된 External DNS의 ROLE을 입력합니다. AWS IAM – Roles 에서 아래와 같이 ‘external-dns’를 검색한 결과를 아래 스크린샷을 참조하여 “arn:aws:iam:XXXXX”입력합니다.

준비한 헬름 Value 파일을 이용하여 헬름 차트를 배포합니다.

$ (⎈ |switch-singapore-test:kube-system) helm install external-dns -f my-values.yaml .
NAME: external-dns
LAST DEPLOYED: Tue Jul 11 09:12:49 2023
NAMESPACE: kube-system
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
***********************************************************************
* External DNS                                                        *
***********************************************************************
  Chart version: 1.12.2
  App version:   0.13.4
  Image tag:     registry.k8s.io/external-dns/external-dns:v0.13.4
***********************************************************************

External DNS Controller 파드가 정상 실행됩니다.

[(jerry-test:kube-system) external-dns-1.12.2]$ k get pod external-dns-5555f6796f-77n4d 
NAME                            READY   STATUS    RESTARTS   AGE
external-dns-5555f6796f-77n4d   1/1     Running   0          3m22s

external-dns-xxx 파드의 로그가 아래와 같이 “All records are already up to date” 이면 정상으로 배포된 것 입니다.

[(jerry-test:kube-system) external-dns-1.12.2]$ k logs -f external-dns-5555f6796f-77n4d 
time="2023-09-02T22:25:03Z" level=info msg="Applying provider record filter for domains: [jerryljh.me. .jerryljh.me.]"
time="2023-09-02T22:25:03Z" level=info msg="All records are already up to date"

4. 인그레스 실습

이제 준비가 완료되었습니다. 앞서 준비한 AWS LB Controller와 External DNS Controller를 사용하여 인그레스를 사용해보겠습니다. 테스트에 사용한 ‘echoservice’ 애플리케이션의 deployment, service 등 예제 코드는 필자의 깃허브 에서 확인할 수 있습니다.

deployment, service 매니페스트는 기본 설정이라 상세 설명은 생략합니다. 인그레스 매니페스는 아래와 같이 작성합니다.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: echoserver
  namespace: echoserver
  annotations:
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: ip
    alb.ingress.kubernetes.io/group.name: sg-external
    alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80}, {"HTTPS":443}]'
    alb.ingress.kubernetes.io/ssl-redirect: "443"
    alb.ingress.kubernetes.io/certificate-arn: $CERTIFICATE_ARN
    external-dns.alpha.kubernetes.io/hostname: $INGRESS_HOST
spec:
  ingressClassName: alb
  rules:
  - host: $INGRESS_HOST
    http:
      paths:
      - path: /echo-server
        pathType: Prefix
        backend:
          service:
            name: echoserver
            port:
              number: 80

. alb.ingress.kubernetes.io/target-type: ip
target-type으로 ‘instance’ 또는 ‘ip’ 가능합니다. 인스턴스를 지정하면 파드가 아니라 인스턴스가 실행하는 EKS 전체 노드의 노드포트로 트래픽을 전달합니다. 따라서 네트워크 홉이 한단계 증가합니다. IP로 지정하면 로드밸런서에서 파드의 IP로 트래픽 바로 전달합니다. ip를 옵션을 사용하기 위해서는 eks CNI로 aws vpc cni를 사용해야 합니다. 아마도 eks 환경이면 대부분 aws vpc cni를 사용할 것 같습니다.

. alb.ingress.kubernetes.io/group.name
그룹 이름으로 임의의 이름을 사용할 수 있습니다. ALB 그룹을 지정하지 않으며 개별 인그레스마다 로드밸런서를 별도로 생성합니다. 실무에서 인그레스를 많이 생성하므로 불필요한 비용 낭비가 발생할 수 있습니다. Security Group 별로 서비스를 구분하지 않거나 서비스 트래픽이 ALB가 처리할 수 없을만큼 매우 크지 않다면 동일한 ALB로 처리가 가능합니다. 그룹을 지정하여 인그레스마다 ALB를 별도로 만들지 않고 하나의 ALB로 여러 개의 인그레스를 처리합니다.

. alb.ingress.kubernetes.io/certificate-arn
로드밸런서에서 TLS 인증서를 처리하도록 각자 생성한 인증서 정보를 등록합니다. AWS 콘솔에서 ‘Certificate Manager’에서 아래 스크린샷을 참조하여 인증서의 ARN 정보를 입력합니다.

. external-dns.alpha.kubernetes.io/hostname, spec.rules.[]host:
인그레스가 처리할 도메인 정보를 입력합니다. 예를 들어서 www.myweb.com, www.jerryljh.me 등 각자 서비스의 도메인 정보를 입력합니다. 해당 도메인 정보는 이전 단계에서 설치한 External DNS Controller에 의하여 자동으로 AWS Route 53에 등록되고 해당 도메인이 바라보는 Target은 인그레스로 생성된 Load Balancer 정보로 역시 자동으로 매핑됩니다. 

. spec.ingressClassName: alb
인그레스가 생성하는 로드밸런서를 구분하기 위하여 Class 이름을 지정합니다. 우리는 AWS ALB를 사용할 예정이므로 ALB로 지정합니다. 

그럼 3개의 매니페스트 – ingress, deployment, service를 한꺼번에 배포합니다. 3개의 매니페스트가 위치한 디렉토리로 이동합니다.

# echoservice 매니페스트 파일이 위치한 디렉토리로 이동합니다.
$ (⎈ |switch-singapore-test:kube-system) cd private/k8s-class/aws-load-balancer-controller/aws-lb-controller-examples/
$ (⎈ |switch-singapore-test:kube-system) pwd 
/Users/jerry/private/k8s-class/aws-load-balancer-controller/aws-lb-controller-examples

echoservice 디렉토리 전체의 manifest를 실행합니다. k apply -f {디렉토리 이름}으로 지정하면 해당 디렉토리 아래의 전체 리소스가 한꺼번에 배포됩니다.

$ (⎈ |switch-singapore-test:kube-system) ls echoservice 
echoserver-deployment.yaml echoserver-ingress.yaml    echoserver-service.yaml
$ (⎈ |switch-oregon-stage:default) k apply -f echoservice/

별다른 이슈가 없다면 아래와 같이 리소스를 확인할 수 있습니다.

$ (⎈ |switch-oregon-stage:default) k get ing,pod,svc
NAME                                   CLASS   HOSTS                                 ADDRESS                                                                 PORTS   AGE
ingress.networking.k8s.io/echoserver   alb     www.XXXX.com                       k8s-XXXX.ap-northeast-2.elb.amazonaws.com   80      3d13h

NAME                              READY   STATUS    RESTARTS   AGE
pod/echoserver-7757d5ff4d-7m2fp   1/1     Running   0          3d13h

NAME                 TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)   AGE
service/echoserver   ClusterIP   172.20.198.114   <none>        80/TCP    3d13h

그럼 정상적으로 AWS Resource가 생성되었는지 확인합니다. 먼저 Route 53에 도메인이 자동으로 등록되었는지 확인합니다.

각자 생성한 도메인이 Route 53에 등록되었습니다. 도메인의 ‘A’ 레코드를 확인하면 Load Balancer로 매핑된 걸 확인할 수 있습니다.

다음은 ALB의 Target Group을 확인합니다. EC2 – Load balancers 메뉴를 확인하면 방금 생성한 로드밸런서를 확인할 수 있습니다.

로드밸런서를 선택하고 상세 메뉴에서 ‘Listeners and rules’를 확인합니다. ‘Rules’를 다시 선택합니다.

인그레스 매니페스트에서 작성한 호스트 이름과 Path(/echo-server)를 확인할 수 있습니다. Target Group을 확인하기 위하여 아래 스크린샷을 참조하여 ‘k8s-default-echoserver-xxxxx’를 선택합니다.

ALB가 바라보는 타겟 그룹 정보를 확인할 수 있습니다. 타겟의 개수, 정상 여부 등을 확인할 수 있습니다.

아래 상세 정보를 확인하면 IP를 확인할 수 있습니다.

해당 IP는 노드 IP가 아닌 파드의 IP로 ALB에서 바라보는 타겟이 파드임을 확인할 수 있습니다.

위 스크린샷에서 10.110.8.100은 echoserver 파드 IP입니다.

[(jerry-test:default) argo-cd-app-of-apps-qa]$ k get pod -o wide echoserver-65dfd67c69-pzjgr
NAME                          READY   STATUS    RESTARTS   AGE   IP             NODE                                              NOMINATED NODE   READINESS GATES
echoserver-65dfd67c69-pzjgr   1/1     Running   0          44h   10.110.8.100   ip-10-110-0-162.ap-northeast-2.compute.internal   <none>           <none>

만약 target-type: ip 가 아닌 instance 를 지정하거나 LB Controller를 사용하지 않았다면 아래의 같이 전체 노드의 노드포트가 Target Group으로 등록됩니다.

물론 브라우저에서 직접 확인하면 ‘echoserver’가 정상적으로 응답하는 것을 확인할 수 있습니다.

추가로 AWS에서 생성한 공인 인증서도 정상으로 등록된 것을 확인할 수 있습니다.

5. Argo-CD 인그레스 적용

그럼 실습을 바탕으로 실제 운영하는 Argo-CD에 인그레스를 적용하겠습니다. 앞선 3장에서 Port-forward를 이용하여 Argo-CD 접속하였습니다. 하지만 실제 운영 환경에서 Argo-CD는 개발자들도 접속하는 서비스라 ‘kubectl’ 명령어에 익숙하지 않는 사용자는 접속하기 어렵습니다. 인그레스를 사용하면 도메인 정보만으로 접속할 수 있으므로 Argo-CD 헬름 배포 시 인그레스 설정까지 같이 포함하여 배포합니다.

그럼 인그레스 설정을 포함한 헬름 Value 파일을 알아보겠습니다.

server:
  extraArgs:
  - --insecure
  ingress:
    enabled: true
    annotations:
      alb.ingress.kubernetes.io/scheme: internet-facing
      alb.ingress.kubernetes.io/target-type: ip
      alb.ingress.kubernetes.io/group.name: sg-external
      alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80}, {"HTTPS":443}]'
      alb.ingress.kubernetes.io/ssl-redirect: "443"
      alb.ingress.kubernetes.io/certificate-arn: $CERTIFICATE_ARN
      external-dns.alpha.kubernetes.io/hostname: $ARGOCD_HOST
    ingressClassName: "alb"
    hosts:
    - $ARGOCD_HOST
    paths:
    - /
configs:
  credentialTemplates:
    ssh-creds:
      url: git@github.com:junghoon2
      sshPrivateKey: |
        -----BEGIN OPENSSH PRIVATE KEY-----
        XXXX
        -----END OPENSSH PRIVATE KEY-----
  repositories:
    k8s-class:
      name: k8s-class
      url: git@github.com:junghoon2/k8s-class.git

. server.extraArgs: –insecure
AWS ALB에서 TLS 인증서를 처리하고 ALB와 Argo=CD 웹서버는 일반 HTTP 통신을 하므로 insecure 옵션을 추가합니다.

. server.ingress.alb.ingress.kubernetes.io/group.name
앞에서 예제로 생성한 ‘echoserver’와 동일한 그룹 이름을 지정합니다. 같은 ingress 그룹 이름을 지정하여 추가로 ALB를 생성하지 않고 기존 ALB를 같이 사용할 수 있습니다. 불필요한 ALB 낭비를 막을 수 있습니다.

. server.ingress.alb.ingress.kubernetes.io/certificate-arn
앞에서 생성한 인증서 ARN 정보를 입력합니다.

. server.ingress.external-dns.alpha.kubernetes.io/hostname
Argo-cd 접속에 사용할 도메인 정보를 입력합니다. 예를 들어 argocd.myweb.com 등 Argo-cd 용 별도로 도메인을 생성하거나 www.myweb.com/argocd 등 도메인은 동일하게 하고 Path로 서비스를 분리할 수 있습니다. 둘 다 사용할 수 있으나 필자는 Argo-cd 용 별도 도메인을 분리하는 것을 선호합니다. 유사하게 grafana.myweb.com, kafka-ui.myweb.com 등도 분리합니다.

. configs.credentialTemplates.ssh-creds
3장에서 사용한 ssh 키정보를 동일하게 입력합니다.

인그레스 정보를 포함한 헬름 Values 파일로 Argo-CD를 재배포 합니다.

[(jerry-test:argocd) argo-cd-5.14.1]$ helm upgrade argocd -f ci/ingress-values.yaml .
(생략)

이제 Port-forward 없이 도메인 주소를 입력하면 Argo-CD로 접속할 수 있습니다.

이상으로 이번 장에서 인그레스, AWS Load Balancer Controller, External DNS Controller를 알아보았습니다. AWS 에서 제공하는 LB Controller, DNS Controller를 사용하면 인그레스를 좀 더 편리하게 사용할 수 있습니다. 매니지드 쿠버네티스 서비스의 장점입니다.

인그레스는 현업에서 자주 사용하는 리소스입니다. 같은 설정이 반복되므로 여러번 경험하다보면 자연스럽게 알 수 있습니다.

해당 기술 블로그에 질문이 있으시면 언제든지 문의해 주세요. 직접 답변해 드립니다.
k8sqna@jennifersoft.com

참조
https://malwareanalysis.tistory.com/597

1.AWS Route 53 연결 방법 참조
2.AWS 인증서 생성 방법 참조