AWS EKS에서 ALB를 이용해 여러 서비스를 연결하기 위해서는 TargetGroupBinding을 사용합니다. TargetGroupBinding을 사용하는 목적은 다음과 같습니다.

제가 이 페이지에서 사용하고자 하는 목적은 1번 단일 ALB에서 여러 서비스를 라우팅하기 위해 사용합니다.

1. *단일 ALB에서 여러 서비스 라우팅 * : 하나의 ALB를 통해 여러 서비스로 트래픽을 분배하여 비용을 절감하고 관리 복잡성을 줄입니다.

2.** 유연한 트래픽 제어 ** : 서비스별로 개별 Target Group을 설정하여, 특정 서비스의 트래픽을 원하는 방식으로 분배할 수 있습니다.

3.** EKS 네이티브 통합** : ALB의 Target Group과 EKS의 서비스(Pod)간 직접적인 연결을 설정하여, Ingress 리소스를 사용하지 않고도 ALB를 통해 EKS의 서비스와 원활하게 연동할 수 있습니다.

Target Group Binding 방법

AWS LoadBalancer Controller 애드온 설치

로드 밸런서 컨트롤러 에드온이 있어야 Kubernetes 리소스(Ingress, Service 등)를 자동으로 AWS의 로드 밸런서(Target Group)와 매핑할 수 있습니다.

AWS Load Balancer Controller IAM Policy 다운로드

AWS 로드 밸런서 컨트롤러의 IAM 정책을 다운로드합니다.

curl -O https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/v2.12.0/docs/install/iam_policy.json

다운 받은 위 Policy를 "AWSLoadBalancerControllerIAMPolicy"라는 명칭으로 IAM Policy 생성합니다.

EKS 서비스 어카운트 생성 및 정책 연결

eksctl create iamserviceaccount --cluster=<Cluster Name> --namespace=kube-system --name=aws-load-balancer-controller --attach-policy-arn=<AWSLoadBalancerControllerIAMPolicy_ARN> --approve

Addon 옵션 지정 및 helm 설치

# helm add
helm repo add eks https://aws.github.io/eks-charts

# helm update
helm repo update eks

# helm install
helm install aws-load-balancer-controller eks/aws-load-balancer-controller \
--version <Chart_Version> -n kube-system \
--set clusterName=<Cluster_Name> \
--set vpcId=<VPC_ID> \
--set region=ap-northeast-2 --set serviceAccount.create=false \
--set serviceAccount.name=aws-load-balancer-controller \
--set enableShield=false \
--set enableWaf=false \
--set enableWafv2=false \
--set createIngressClassResource=true --set ingressClass=alb

Target Group Binding yaml 파일 작성

tgb yaml 파일을 작성하여 배포하면 완료!!!!

apiVersion: elbv2.k8s.aws/v1beta1
kind: TargetGroupBinding
metadata:
  name: kafka-ui-tgb
  namespace: kafka
spec:
  serviceRef:
    name: kafka-ui
    port: 80
  targetGroupARN: <Target_Group_ARN>
  targetType: ip

AWS EKS를 생성하고, 노드 및 파드에 접속하여 공부해보면서 OIDC가 생성 되면 , IAM Identity Center 에 등록하곤 했었는데요. 문득 OIDC 가 뭐고 이걸 왜 등록 해야하는지에 대해 궁금해졌습니다. 그래서 이것이 어떤 역할을 하게 되는지에 대해서 작성해보려 합니다.

OIDC의 역할

EKS를 생성하면 OIDC 제공자(OpenID Connect Provider) 가 자동으로 생성됩니다. 이 OIDC 제공자는 Kubernetes API 서버가 AWS IAM과 연동할 수 있도록 해주는데요.

Kubernetes 내부에서는 kubectl 명령어를 실행할 때 IAM 사용자의 역할(Role)을 기반으로 인증을 수행해야 합니다. 기본적으로 EKS 클러스터는 IAM 인증을 사용하지만, IAM 자체는 Kubernetes 네이티브 RBAC(Role-Based Access Control)를 모릅니다.

그래서 OIDC를 이용해 IAM과 Kubernetes의 인증 체계를 연결하는 방식으로 동작하게 됩니다.

IAM Identity Center를 추가하는 이유

IAM Identity Center(기존 SSO)를 EKS OIDC와 연동하면 AWS IAM Identity Center 사용자가 EKS에 접근할 수 있습니다. 이러한 이유로 EKS 생성 후 OIDC를 Identity Center에 추가해줘야 하는데요.

OIDC를 통해 EKS가 AWS IAM과 연동됨. → "EKS가 AWS IAM 역할(Role)을 사용할 수 있음"을 의미.

IAM Identity Center를 사용하면, AWS IAM 역할을 통해 EKS에 접근 가능 → 즉, AWS IAM Identity Center에서 특정 사용자나 그룹을 IAM Role에 매핑하면, 해당 사용자는 kubectl을 사용하여 EKS에 접근 가능.

IAM Role과 Kubernetes RBAC 연결 → IAM Role이 EKS의 Kubernetes RBAC와 연결되면, 해당 Role을 가진 사용자는 kubectl로 클러스터를 관리할 수 있음.

OIDC 등록 전

EKS에 자동 할당 되어 있는 OIDC를 Identity Center에 등록하지 않고 Kubectl 명령어를 입력해보겠습니다. 아래 명령어로 pod, node에 대한 어떤 정보도 가져오지 못합니다.

OIDC 등록 후

Identity Center에 등록 후 이전에는 되지 않던 kubectl 명령어가 동작하는 것 확인 가능합니다.

결론

100번의 이론 설명보다 1번의 실습이 더 이해하기가 편하죠 :) OIDC는 Kubernetes에서 AWS IAM을 통한 접근을 가능하게 해주는 인증 방식이다!! _OIDC 덕분에 AWS IAM으로 kubernetes에 로그인할 수 있다_👍

Terraform을 통해 EKS Cluster 생성 및 Add-on 설치 시에 아래와 같이 내가 방금 Terraform을 통해 생성한 EKS Cluster가 없다는 ERROR가 발생하여, Add-on 설치를 실패했다는 로그가 나온다.

Error: creating EKS Add-On (alin-test-cluster:vpc-cni): ResourceNotFoundException: No cluster found for name: alin-test-cluster. │ { │ RespMetadata: { │ StatusCode: 404, │ RequestID: "27b9e182-4dc9-4cd7-a2e9-efaa0a858699" │ }, │ ClusterName: "alin-test-cluster", │ Message_: "No cluster found for name: alin-test-cluster." │ } │ │ with aws_eks_addon.vpc_cni, │ on main.tf line 39, in resource "aws_eks_addon" "vpc_cni": │ 39: resource "aws_eks_addon" "vpc_cni" { │

에러 원인

내 코드에서 Add-on 설치 부분을 보면 단순히 Cluster와 어떤 Add-on인지에 대해서만 명시되어 있다. Terraform을 통한 EKS Cluster가 생성 되기 전 Add-on 설치가 먼저 이루어지는 바람에 Add-on 설치가 실패된 것이다.

###############################################################################
# EKS Add-on
################################################################################
resource "aws_eks_addon" "vpc_cni" {
  cluster_name  = var.eks_cluster_name
  addon_name    = "vpc-cni"
  addon_version = var.vpc_cni_version

}

해결 방법

depens_on 을 사용하여 EKS Cluster가 생성 된 후 Add-on이 설치될 수 있도록 한다.

###############################################################################
# EKS Add-on
################################################################################
resource "aws_eks_addon" "vpc_cni" {
  cluster_name  = var.eks_cluster_name
  addon_name    = "vpc-cni"
  addon_version = var.vpc_cni_version
  depends_on  = [aws_eks_cluster.eks_cluster]

}

Terraform 생성 로그를 보면 depens_on을 사용하여 종속성을 명시해준 이후에 Cluster 생성 후 Add-on이 설치되는 것을 확인할 수 있었다.

depends_on 에서 []의 의미

depens_on 이라는 블록을 사용하게 되면 Value에 중괄호 []를 사용하여 작성하게 되는데요. 이 중괄호는 여러 개의 리소스에 의존할 수 있기 때문에 리스트(Slice) 형태로 입력 받습니다.

depends_on = [
  aws_eks_cluster.eks_cluster,
  aws_iam_role.eks_role
]

위 코드와 같이 여러 개의 의존성을 가질 수 있다라고 알고 있으면 됩니다.

테라폼을 시작해보고는 싶은데 어디서부터 어떻게 시작해야할지 모르는 '나'와 이 글을 읽는 분들께 테라폼을 AWS와 연동하고, AWS 내에 동작하는 리소스를 생성하기 위한 방법을 정리합니다.

뭐부터 시작해야할까?

테라폼 코드를 무작정 작성할 수는 없으니 아래와 같이 단계별로 진행해보려 합니다.

1. 테라폼 설치하기
2. 코드 디렉토리 트리 구성하기
3. 구조 모듈화를 통한 관리 방식 수립하기
4. 트리 구조에 맞게 코드 작성하기

목표

테라폼 코드 작성 전 저는 아래와 같은 목표를 갖고 작업 진행 예정입니다. 이를 바탕으로 이 페이지에서는 기본적인 트리구조와 모듈화를 통한 관리 방식 수립 부분 까지만 진행해보도록 하겠습니다.

• 초기 인프라 구축 자동화: 네트워크부터 애플리케이션 인프라까지 Terraform으로 완전 자동화된 배포 가능 여부 검증
• 기존 인프라 활용 자동화: 이미 존재하는 네트워크를 활용하여 신규 리소스 배포 및 삭제의 효율성 검증
• 운영 리소스 변경 및 업그레이드: 운영 중인 리소스의 버전 업데이트 및 세부 설정 변경 시 안정성 및 운영 효율성 평가
• CI/CD 파이프라인 연계 가능성 검토: Terraform을 GitOps와 연계하여 자동화 배포 및 변경 관리가 가능하도록 테스트

1. 테라폼 설치하기

테라폼을 사용하기 위해서는 테라폼과 AWS CLI를 설치해야합니다. 각자의 환경에 맞는 Terraform과 CLI를 설치하도록 합니다.

👉🏻[테라폼 설치] (https://developer.hashicorp.com/terraform/install) 👉🏻[AWS CLI 설치] (https://docs.aws.amazon.com/ko_kr/cli/latest/userguide/getting-started-install.html)

2. 코드 디렉토리 트리 구성하기

트리 구조는 아래와 같습니다. 트리 구조를 이렇게 짠 이유는 운영까지 고려하여 영향도를 최소화 하고 운영 편의성을 높이기 위해 리소스 별로 상세하게 나누었습니다.

terraform ├─ 100_network ├─── 101_network_default ├───── main.tf ├───── variables.tf ├───── versions.tf ├───── output.tf ├───── locals.tf ├─── 102_network_gw ├─── 103_network_vep ├─── 104_network_routing ├─── 105_network_sg_rule ├─ 200_compute ├─ 300_eks ├─ 400_s3 ├─ 500_rds ├─ 600_iam ├─── 601_iam_policy ├─── 602_iam_rule ...

3. 구조 모듈화를 통한 관리 방식 수립하기

각 리소스 내에 있는 tf 파일들은 각자의 역할에 따라 구분되어 있습니다. 이 파일들을 어떻게 사용하느냐에 따라 운영의 편리함을 구분지을 수 있다고 생각합니다.

그래서 저는 테라폼을 통한 리소스 구성 시 variables.tf 파일만 수정하도록 관리 방식을 수립했습니다.

[main.tf] (주요 리소스 정의)

• 인프라의 주요 리소스를 선언하는 파일로, AWS 서비스(EKS, RDS, EC2 등)를 구성하는 코드가 포함됩니다.
• 변경을 최소화 하기 위하여 이 파일은 운영 및 구축 시 변경하지 않아도 되도록 설계합니다.

[variables.tf] (입력 변수 정의)

• Terraform 코드에서 사용할 변수들을 정의하는 파일입니다.
• 프로젝트의 유연성을 높이며, 특정 값(VPC ID, 인스턴스 유형 등)을 변경할 때 이 파일만 수정하면 됩니다.

[versions.tf] (버전 관리)

• Terraform 및 필요한 provider(AWS 등)의 버전을 지정하는 파일입니다.
• 특정 버전을 명시하여 환경 간 일관성을 유지하고, 호환성을 일관되게 유지하는 역할을 합니다.

[output.tf](출력 변수 정의)

• Terraform 실행 후 생성된 리소스의 중요한 정보를 출력하는 파일입니다.
• 예를 들어, 생성된 EC2의 Public IP, RDS 엔드포인트, ALB 주소 등을 출력하도록 설정할 수 있습니다.

[locals.tf](로컬 변수 정의)

• locals 블록을 사용하여 반복적으로 사용되는 값이나 계산된 값을 정의하는 파일입니다.
• 자주 사용되는 값을 정의해놓고 사용하면 편리한 사용이 가능합니다.

1. Redis의 상태를 직관적으로 모니터링하고 관리하기 위해 사용합니다.
2. Key-Value 데이터를 쉽게 조회하고, 데이터 변경 및 삭제 작업을 편리하게 수행하기 위해 활용됩니다.
3. 성능 분석 및 최적화를 통해 Redis의 효율적인 운영을 지원합니다.

Redis Insight를 사용하는 이유

1. GUI 기반 도구로 CLI 없이도 Redis 데이터를 쉽게 탐색하고 관리할 수 있습니다.
2. 실시간으로 Redis 성능 지표를 확인하고 문제를 빠르게 진단할 수 있습니다.
3. 복잡한 명령어 없이도 데이터 시각화 및 성능 튜닝이 가능하여 운영 효율성을 높입니다.

1.Redis Insight 설치하기

Redis 모니터링을 위한 UI 툴인 Redis Insight를 설치합니다.

1.1 Redis Insight yaml 파일 작성하기

저는 테스트이기 때문에 퍼블릭 이미지를 가져와서 작업했습니다. 그리고 IP는 0.0.0.0으로 설정하여 외부 어디에서건 접근 가능하도록 설정했습니다. 추후 고도화 시에 IP를 제한하는 작업을 하려 합니다.

  # redis-insight-deployment.yaml

  namespace: redis
  name: redis-insight
  labels:
    app: redis-insight
spec:
  replicas: 1
  selector:
    matchLabels:
      app: redis-insight
  template:
    metadata:
      labels:
        app: redis-insight
    spec:
      containers:
        - name: redis-insight
          image: redislabs/redisinsight:latest
          ports:
            - containerPort: 5540
          env:
            - name: RI_APP_HOST
              value: "0.0.0.0"
            - name: RI_APP_PORT
              value: "5540"
      imagePullSecrets:
        - name: regcred
---
apiVersion: v1
kind: Service
metadata:
  name: redis-insight-service
  namespace: redis
spec:
  selector:
    app: redis-insight
  ports:
    - protocol: TCP
      port: 80
      targetPort: 5540
  type: ClusterIP

1.2 Redis Insight yaml 배포하기

yaml 파일을 만들었으니 배포해야죠!

kubectl apply -f redis-insight-deployment.yaml

1.3 Redis Insight Pod 정상 확인

아래 이미지와 같이 redis Namespace 대상을 설치가 됐다면 redis-insight 설치는 완료되었습니다.

2. Ingress ALB와 연결하기

Redis Insight를 외부에서 접근하기 위해서는 Public한 자원에 올리던지, Ingress ALB를 통해 접근하던지 2가지의 방법이 있습니다. 저는 Private한 자원에 설치 했기 때문에 Ingress ALB를 통한 접근이 필요합니다.

2.1 Ingress 리소스 생성

저는 간단한 테스트를 위해 80포트로만 통신할 예정이라 80 포트를 사용하는 yaml 파일을 작성했습니다. ALB_DNS_Name에 EKS Ingress ALB의 DNS Name을 넣어줍니다.

# redis-insight-ingress.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  namespace: redis
  name: redis-insight-ingress
  annotations:
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: ip
    alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80}]'
spec:
  rules:
    - host: <ALB_DNS_Name>
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: redis-insight-service
                port:
                  number: 5540

2.2 Ingress yaml 파일 배포

kubectl apply -f redis-insight-ingress.yaml

2.3 ALB 주소 확인

정상적으로 배포되었는지 확인하고 마무리합니다.

kubectl get ingress -n redis

3. 도메인을 통한 UI 접속

ALB 도메인을 통해 Redis Insight 접속을 시도해봅니다.

3.1 Target Group 생성

아래 옵션을 선택하여 TG을 생성합니다.

• IP Addresses 선택
• HTTP
• 5440
• EKS와 동일한 VPC

3.2 Target 연결

Target IP를 연결할 때는 EKS의 노드가 아닌 POD의 IP를 연결해줘야합니다. -o wide 명령어를 통해 POD IP를 알아냅니다. Register하면 끝!

kubectl get po -n redis -o wide

3.3 ALB에 TG 붙이기

아래 이미지와 같이 특정 도메인을 붙여 복잡한 DNS Name으로 접근 하는 것이 아닌 지정한 도메인을 통한 접근이 되게 합니다.

Redis Insight UI 접속

완료!!! Redis-insight 도메인으로 접속 시에 정상 통신 되는 것을 확인 합니다. 제가 설치에 대한 부분만 넣고 ALB, EKS 방화벽에 대한 부분은 생략하였는데요.

포트별 흐름을 간단히 정리해봤습니다. 상세 내용은 아래 설명을 읽어주세요. 사용자 → ALB(80) → EKS (5540) → Kafka (5540)

사용자 (80) 사용자가 웹 브라우저나 HTTP 클라이언트를 통해 포트 80을 사용하여 접속합니다. 이때 사용자가 접속하는 도메인(예: redis-ui.example.com)을 통해 ALB로 요청이 전달됩니다. ** ALB (80)** ALB(AWS Application Load Balancer)는 외부에서 들어오는 트래픽을 받아서, 내부 EKS 클러스터로 전달합니다. ALB는 80번 포트로 요청을 받아서, EKS에 설정된 Ingress 리소스를 통해 redis-insight-service로 요청을 포워딩합니다. EKS (5540) EKS에서 Ingress Controller가 ALB로부터 받은 요청을 처리하고, 해당 요청을 redis-insight-service로 전달합니다. redis-insight-service는 내부에서 5540번 포트를 사용하고, ALB는 80번 포트로 외부와 통신하므로, ALB는 요청을 80번 포트로 받고, EKS의 서비스는 5540번 포트로 처리합니다. RedisInsight Pod (5540) redis-insight-service는 5540번 포트에서 Redis Insight UI를 제공하고 있습니다. EKS에서 서비스가 해당 포트를 사용하여 Redis와 연결된 UI 서비스를 제공하고, 데이터를 처리합니다.

이 페이지에서는 Amazon EKS(Amazon Elastic Kubernetes Service) 환경에 Kafka UI를 설치하는 방법에 대해 자세히 다룹니다. EKS 클러스터에 Kafka UI를 설치하고, 이를 통해 Kafka 클러스터의 상태를 쉽게 조회하고 관리할 수 있도록 합니다.

Kafka UI를 사용하는 이유

Kafka UI는 Kafka 클러스터를 관리하고 모니터링할 수 있는 강력한 웹 기반 도구로, Kafka 브로커, 토픽, 파티션 등 다양한 리소스를 직관적으로 관리할 수 있게 해줍니다. Kafka를 운영하는 데 있어, 명령줄 인터페이스(CLI)만으로는 부족한 경우가 많습니다. 이 때 Kafka UI를 활용하면 관리가 훨씬 수월해지고, 실시간 모니터링도 가능해집니다.

1. LoadBalancer Controller 설치

외부에서 접속 시에 Ingress ALB를 통한 접속이 필요하기 때문에 LoadBalancer Controller Add-on 설치가 필요합니다.

1.1 AWS LoadBalancer Controller IAM Policy 다운로드

curl -O https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/v2.11.0/docs/install/iam_policy.json

1.2 IAM Policy 생성

저는 SSO를 통해 인증/접근하기 때문에 --profile 부분을 추가했습니다.

aws iam create-policy \
    -- profile <SSO Profile name>
    --policy-name AWSLoadBalancerControllerIAMPolicy \
    --policy-document file://iam_policy.json

1.3 Service Account 생성

profile, cluster_name,policy_arn 부분을 수정해줍니다.

eksctl create iamserviceaccount \
  --cluster=<cluster_name> \
  --region=<AWS_Region> \
  --namespace=kube-system \
  --name=aws-load-balancer-controller \
  --role-name AmazonEKSLoadBalancerControllerRole \
  --attach-policy-arn=<policy_arn> \
  --approve

1.4 EKS Chart Helm 리포지토리 추가

helm repo add eks https://aws.github.io/eks-charts

1.5 로컬 리포지토리 업데이트

helm repo update eks

1.6 LoadBalancer Controller 버전 확인

helm을 통해 LB 컨트롤러 설치 시에는 CHART 버전 확인이 필수 입니다. APP Version이 아닌** CHART Version**을 기억해야합니다.

helm search repo eks/aws-load-balancer-controller --versions

1.7 LoadBalancer Controller 설치

helm install aws-load-balancer-controller eks/aws-load-balancer-controller 
--version <CHART_Version> -n kube-system \
--set clusterName=<Cluster_Name> \
--set vpcId=<VPC_DI> \
--set region=<AWS_Region> \
--set serviceAccount.create=false \
--set serviceAccount.name=aws-load-balancer-controller \
--set enableShield=false \
--set enableWaf=false \
--set enableWafv2=false \
--set createIngressClassResource=true \
--set ingressClass=alb

1.8 설치 확인하기

LoadBalancer가 제대로 설치되었는지 확인하고 마무리합니다. 많이 한 것 같은데 아직 멀었습니다.. Kakfa-UI는 설치도 하지 못했네요 :<

kubectl get po -n kube-system

2. Kafka UI 설치하기

이 페이지에서는 Yaml 파일을 통한 Kafka UI 설치를 해보겠습니다. Helm을 통한 설치도 있지만 저는 오류가 너무 많이 나서... Yaml 파일을 통한 설치로 노선을 변경했습니다!

2.1 Kafka UI Yaml 파일 작성하기

저는 Public 이미지를 가져오도록 설정했습니다. Private 이미지를 써야하는 분들은 "image" 부분을 Private 이미지로 수정해주시면 됩니다.

# kafka-ui-deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: kafka-ui
  namespace: kafka
spec:
  replicas: 1
  selector:
    matchLabels:
      app: kafka-ui
  template:
    metadata:
      labels:
        app: kafka-ui
    spec:
      containers:
        - name: kafka-ui
          image: provectuslabs/kafka-ui:latest
          ports:
            - containerPort: 8080
          env:
            - name: KAFKA_CLUSTERS_0_NAME
              value: "local"
            - name: KAFKA_CLUSTERS_0_BOOTSTRAPSERVERS
              value: "<BootStrap Endpoint:9092>"
---
apiVersion: v1
kind: Service
metadata:
  name: kafka-ui
  namespace: kafka
spec:
  selector:
    app: kafka-ui
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
  type: ClusterIP

2.2 Kafka UI 배포

kubectl apply -f kafka-ui-deployment.yaml

2.3 Kafka UI Pod 정상 확인

아래 이미지와 같이 Kafka namespace 대상으로 설치가 됐다면 Kafka 설치는 완료되었습니다.

3. Ingress ALB와 연결하기

Kafka-UI를 외부에서 접근하기 위해서는 Public한 자원에 올리던지, Ingress ALB를 통해 접근하던지 2가지의 방법이 있습니다. 저는 Private한 자원에 설치를 했기 때문에 Ingress ALB를 통한 접근이 필요합니다.

3.1 서브넷 태깅하기

EKS(Amazon Elastic Kubernetes Service)에서 ALB(Application Load Balancer)를 자동으로 생성하고 관리할 수 있도록 서브넷을 태깅해야 합니다. EKS에 할당 된 서브넷 대상으로 kubernetes.io/role/elb TAG가 붙어있는지 확인해야합니다.

aws ec2 describe-subnets --filters "Name=vpc-id,Values=<VPC_ID>"

해당 태그가 없다면 붙여줍니다. Subnet ID는 EKS에 할당되어있는 서브넷 모두 적용시켜줍니다.

aws ec2 create-tags --resources <Subnet_ID> --tags Key=kubernetes.io/role/elb,Value=1

3.2 Ingress 리소스 생성

저는 간단한 테스트를 위해 80포트로만 통신할 예정이라 80 포트를 사용하는 yaml 파일을 작성했습니다. ALB_DNS_Name에 EKS Ingress ALB의 DNS Name을 넣어줍니다.

# kafka-ui-ingress.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: kafka-ui-ingress
  namespace: kafka
  annotations:
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: ip
    alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80}]'
    alb.ingress.kubernetes.io/group.name: kafka-ui-ingress-group
spec:
  ingressClassName: alb
  rules:
    - host: <ALB_DNS_Name>
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: kafka-ui
                port:
                  number: 80

3.3 Ingress Yaml 파일 배포

kubectl apply -f kafka-ui-ingress.yaml

3.4 ALB 주소 확인

정상적으로 배포되었는지 확인하고 마무리합니다.

kubectl get ingress -n kafka

4. 도메인을 통한 UI 접속

ALB 도메인을 통해 Kafka UI 접속을 시도해봅니다.

4.1 Target Group 생성

아래 옵션을 선택하여 TG을 생성합니다.

• IP Addresses 선택
• HTTP
• 8080
• EKS와 동일한 VPC

4.2 Target 연결

Target IP를 연결할 때는 EKS의 노드가 아닌 POD의 IP를 연결해줘야합니다. -o wide 명령어를 통해 POD IP를 알아냅니다. Register하면 끝!

kubectl get po -n kafka -o wide

4.3 ALB에 TG 붙이기

아래 이미지와 같이 특정 도메인을 붙여 복잡한 DNS Name으로 접근 하는 것이 아닌 지정한 도메인을 통한 접근이 되게 합니다.

Kafka UI 접속

진짜 완료!!! kafka-ui 도메인으로 접속 시에 정상 통신 되는 것 확인 합니다. 제가 설치에 대한 부분만 넣고 ALB, EKS 방화벽에 대한 부분은 생략하였는데요.

포트별 흐름을 정리해봤습니다. 상세 내용은 아래 설명을 읽어주세요.

사용자 → ALB(80) → EKS (8080) → Kafka (8080)

사용자 (80): 사용자가 웹 브라우저나 다른 HTTP 클라이언트를 통해 포트 80을 사용하여 접속합니다. 이 때 사용자가 접속하는 도메인(예: kafka-ui.example.com)을 통해 ALB로 요청이 전달됩니다.

ALB (80): ALB(AWS Application Load Balancer)는 외부에서 들어오는 트래픽을 받아서, 요청을 내부 EKS 클러스터로 전달합니다. ALB는 80번 포트로 요청을 받아서, EKS에 설정된 Ingress 리소스를 통해 해당 서비스로 요청을 포워딩합니다. EKS (8080): EKS에서 Ingress Controller가 ALB로부터 받은 요청을 처리하고, 해당 요청을 kafka-ui-service로 전달합니다. 이 서비스는 내부에서 8080번 포트를 사용하고, ALB는 80번 포트로 외부와 통신하므로, ALB는 요청을 80번 포트로 받고, EKS의 서비스는 8080번 포트로 처리합니다. Kafka (8080): kafka-ui-service는 8080번 포트에서 Kafka UI를 제공하고 있습니다. EKS에서 서비스가 해당 포트를 사용하여 Kafka와 연결된 서비스를 통해 UI를 제공하고 데이터를 처리합니다.

API Gateway란?

클라이언트와 백엔드 서비스 사이에서 API 요청을 관리하고 라우팅하는 역할을 하는 서비스이다.

간단히 비유를 들어서 설명하자면 API G/W는 음식점의 홀서빙 담당자라고 생각하면 이해가 쉽다. 고객의 요청을 받고, 그에 적합한 주문을 주방으로 전달해주고 음식이 완성되면 고객한테 완성된 음식을 전달해주는 역할을 한다.

AWS API Gateway의 종류

AWS API G/W 에는 3가지의 종류가 있다. 이 3개의 API Gateway에 대해서 알아보도록 하자 쉽게!!

1. RESTful API

2. WebSocket API

3. HTTP API

1. RESTful API

REST는 "Representational State Transfer" 의 약어로 이를 이해하기 위해서는 HTTP Method에 대해서 이해를 하고 있어야 한다. RESTful API는 HTTP Method를 사용하여 리소스에 접근하고 상태 변경 및 조회한다.

HTTP Method

HTTP 메소드는 클라이언트와 서버 간의 요청-응답에서 어떤 작업을 수행할 것인지 명시하는 HTTP 프로토콜의 동작을 정의한다.

• GET : 데이터 조회
• POST : 데이터 생성
• PUT : 데이터 수정
• DELETE : 데이터 삭제

위 Method를 사용하여 요청을 보내게 되고 이에 맞는 작업을 수행하게 된다.

예시)

GET /Users : 사용자 목록을 조회 POST /Users : 새로운 사용자 생성 PUT /users/123 : ID가 123인 사용자의 정보를 수정 DELETE /Users/123 : ID가 123인 사용자를 삭제

특징

• 확장성을 요구하는 MSA(Micro Service Architecture) 환경에서 많이 사용된다.
• 데이터 조회/수정/삭제 등의 기본적인 CRUD 작업을 할 때 유용하다.
• 웹 및 모바일 애플리케이션에서 데이터 교환에 많이 사용한다.
• 요청-응답 방식: 클라이언트가 서버로 요청을 보내면 서버는 응답을 반환합니다. 이 과정이 단방향(one-way)이다.

2. WebSocket API

WebSocket은 양방향 통신을 지원하는 프로토콜로, 실시간 애플리케이션에서 주로 사용된다.

특징

• 양방향 통신 : 클라이언트와 서버 간에 실시간으로 양방향 통신이 가능하다.
• 지속적인 연결 : 연결을 한 번만 설정하면 지속적으로 데이터를 주고 받을 수 있어, 상태 유지가 가능하다.
• 낮은 지연 시간 : 데이터를 실시간으로 주고 받기 때문에 빠르고 효율적이다.
• 메시지 기반 : 메시지 단위로 데이터를 전송하며, 요청-응답 방식이 아니다.

예시

실시간 채팅 애플리케이션에서 사용자가 메시지를 보내면 서버가 즉시 응답을 반환하고, 서버가 다른 사용자의 메시지를 실시간으로 푸시한다. 또한 온라인 게임에서 실시간으로 플레이어 간 상호작용을 처리한다.

3. HTTP API

HTTP API는 HTTP 프로토콜을 사용하여 데이터를 주고받는 API를 의미한다. RESTful 방식의 복잡한 작업 방식이 아닌, 단순한 요청/응답 처리 시에 사용 되는 API 이다.

사용하는 이유

• 단순한 API 설계 : HTTPS API는 HTTPS 프로토콜을 기반으로 하며, 매우 직관적이고 구현하기 쉽다.
• RESTful 설계가 필요 없을 때 : RESTful 설계가 필요 없는 단순한 요청/응답 처리가 필요할 때 유리하다.
• 웹서버와의 연동 : 웹 서버나 프록시 서버와의 연동에서 사용한다. HTTP 프로토콜만으로도 충분한 통신이 가능하다.

최종 정리

권한 설정 방식

1. HTTPS 방식 (Github 계정과 Personal Access Token 사용)
2. SSH 방식 (SSH 키를 생성하여 등록)

Personal Access Token(PAT) 생성

1. Github 로그인 후 > Developer Settings

2. Personal access tokens > Tokens(classic)

[권한]

• repo(모든 리포지토리 권한)
• workflow (GitHub Actions 사용 시)
• write:packages(패키지 푸시 시)

** 생성된 Token은 복사해서 저장한다. 다시 볼 수 없으니 잘 저장해놓기**

기존 자격증명 삭제하기(Window)

기존에 등록되어 있는 자격증명이 있는 경우 git push가 되지 않았다. 아래 그림과 같이 접속해서, 필요없는 git 자격증명을 삭제해주면 된다.

1. 현재 Git 상태 확인

먼저, 로컬과 원격 저장소의 상태를 확인

git remote -v

2. 원격 저장소(origin)가 잘못된 경우

git remote remove origin
git remote add origin https://github.com/YOUR_USERNAME/YOUR_REPOSITORY.git

3. 깃으로 코드 올리기

git push origin main

4. 강제로 푸시해야 하는 경우

강제 푸시는 위 최후의 보루!

git push --force origin main

그럼에도 발생한 에러...

git push origin main warning: ----------------- SECURITY WARNING ---------------- warning: | TLS certificate verification has been disabled! | warning: --------------------------------------------------- warning: HTTPS connections may not be secure. See https://aka.ms/gcm/tlsverify for more information. To https://github.com/clouderling/amplify-repo.git ! [rejected] main -> main (fetch first) error: failed to push some refs to 'https://github.com/clouderling/amplify-repo.git' hint: Updates were rejected because the remote contains work that you do hint: not have locally. This is usually caused by another repository pushing hint: to the same ref. You may want to first integrate the remote changes hint: (e.g., 'git pull ...') before pushing again. hint: See the 'Note about fast-forwards' in 'git push --help' for details.

해결 방법

1. TLS 인증서 검증 활성화 (보안 강화)

git config --global http.sslVerify true

2. 원격 저장소와 로컬 저장소 동기화

git pull --rebase origin main

결과

AWS Direct Connect를 사용하고 있는 환경이며, 동일 랜딩존에 신규 Account가 생성 되었을 때 기존 AWS Direct Connect에 연결하기 위한 실습입니다.

Direct Connect 정보 확인

KINX/LG - 메인/백업 회선의 역할이며 1G로 이중화 되어 연결 되어 있다.

AWS Resource Access Manager(RAM)를 통해 Account 공유

DX의 TGW를 Shared resources로 선택하고 이에 필요한 Managed Permission을 할당해주었다. Shared principals 에서 공유하고자 하는 신규 Account Number를 추가해주면 된다.

공유 된 자원 신규 Account에서 확인

공유 된 자원은 RAM에서 확인 가능하다.

Transit G/W Attachment 생성

공유된 TGW를 대상으로 Attachment를 만듭니다. TGW Attachment를 붙일 서브넷을 지정해주는데요. 해당 서브넷은 TGW가 위치할 서브넷입니다.

신규 Account의 Route table 추가

새로 붙인 TGW를 타고 통신할 대상을 추가해주면 됩니다. 제가 추가한 1,2번 대역은 회사 데이터센터에서 광고 받고 있는 대역입니다. AWS > 데이터센터로 TGW를 타고 트래픽이 흐를 수 있게 하기 위한 작업입니다.

(Private Subnet에는 모두 적용해주었습니다.)

TGW Route table 생성

TGW의 Route table은 총 2개를 만들게 됩니다.

• Direct Connect 용 RT
• 신규 Account 용 RT

제 계정은 이미 DX를 사용하고 있었기 때문에 DX RT은 만들어져 있습니다.

Direct Connect 용 RT 상세

Associations에는 DX GW를 붙여줍니다. propagations에서는 전파된 VPC 목록과 DX G/W 목록을 확인할 수 있습니다. (해당 대역들은 데이터센터에서 DX로 광고한 목록들 입니다.)

신규 Account 용 RT 생성

DX-TGW를 대상으로 한 TGW RT을 생성합니다.

신규 RT에는 신규 Account의 VPC가 연결시켜 주고,

Propagation을 확인해보면 DX G/W가 전파되어 있을 것 입니다.

Multi Account 간 통신 설정 (Option)

해당 설정은 optional한 설정입니다. 저는 Account A와 Account B가 서로 통신이 되어야 했기 때문에 RT에 전파를 추가하였습니다.

 dev-rt에 prod attachment를 전파해주었습니다.
 dev 계정 > prod 계정으로 통신이 되기 위함입니다. 다만, prod > dev로는 통신이 되지 않는 단방향 설정입니다.

Transit gateway associations 설정

허용되는 접두사 목록에 통신할 VPC 대역을 추가합니다. 입력된 허용된 접두사는 같거나 더 작은 CIDR을 허용하는 필터 역할을 합니다.