Kubernetes & Amazon EKS Training

한국어

English
中文
日本語
Español

한국어

English
中文
日本語
Español

Appearance

AWS 통합 ​

이 문서에서는 Amazon EKS 환경에서 Istio를 AWS 서비스와 통합하는 방법을 다룹니다.

목차 ​

  1. AWS Load Balancer 통합
  2. Istio vs 다른 솔루션 비교
  3. EKS 특화 최적화
  4. 모범 사례

AWS Load Balancer 통합 ​

Istio Ingress Gateway를 AWS Load Balancer와 통합하여 외부 트래픽을 처리할 수 있습니다.

Network Load Balancer (NLB) 통합 ​

NLB는 Layer 4 (TCP/UDP) 로드 밸런서로, 높은 성능과 낮은 지연시간이 필요한 경우 적합합니다.

NLB 아키텍처 ​

NLB 설정 ​

1. AWS Load Balancer Controller 설치

bash
# IAM 정책 생성
curl -o iam_policy.json https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/main/docs/install/iam_policy.json

aws iam create-policy \
    --policy-name AWSLoadBalancerControllerIAMPolicy \
    --policy-document file://iam_policy.json

# IRSA 설정
eksctl create iamserviceaccount \
  --cluster=my-cluster \
  --namespace=kube-system \
  --name=aws-load-balancer-controller \
  --attach-policy-arn=arn:aws:iam::<AWS_ACCOUNT_ID>:policy/AWSLoadBalancerControllerIAMPolicy \
  --override-existing-serviceaccounts \
  --approve

# Helm으로 컨트롤러 설치
helm repo add eks https://aws.github.io/eks-charts
helm repo update

helm install aws-load-balancer-controller eks/aws-load-balancer-controller \
  -n kube-system \
  --set clusterName=my-cluster \
  --set serviceAccount.create=false \
  --set serviceAccount.name=aws-load-balancer-controller

2. NLB를 사용하는 Istio Ingress Gateway 설정

yaml
# istio-ingress-nlb.yaml
apiVersion: v1
kind: Service
metadata:
  name: istio-ingressgateway
  namespace: istio-system
  annotations:
    # NLB 설정
    service.beta.kubernetes.io/aws-load-balancer-type: "external"
    service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: "ip"
    service.beta.kubernetes.io/aws-load-balancer-scheme: "internet-facing"

    # TLS 설정
    service.beta.kubernetes.io/aws-load-balancer-ssl-cert: "arn:aws:acm:region:account:certificate/cert-id"
    service.beta.kubernetes.io/aws-load-balancer-ssl-ports: "443"
    service.beta.kubernetes.io/aws-load-balancer-backend-protocol: "tcp"

    # 헬스 체크 설정
    service.beta.kubernetes.io/aws-load-balancer-healthcheck-protocol: "http"
    service.beta.kubernetes.io/aws-load-balancer-healthcheck-port: "15021"
    service.beta.kubernetes.io/aws-load-balancer-healthcheck-path: "/healthz/ready"

    # 추가 설정
    service.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled: "true"
    service.beta.kubernetes.io/aws-load-balancer-proxy-protocol: "*"
spec:
  type: LoadBalancer
  selector:
    app: istio-ingressgateway
    istio: ingressgateway
  ports:
  - name: status-port
    port: 15021
    protocol: TCP
    targetPort: 15021
  - name: http2
    port: 80
    protocol: TCP
    targetPort: 8080
  - name: https
    port: 443
    protocol: TCP
    targetPort: 8443

3. Gateway 리소스 설정

yaml
apiVersion: networking.istio.io/v1
kind: Gateway
metadata:
  name: my-gateway
  namespace: istio-system
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 443
      name: https
      protocol: HTTPS
    tls:
      mode: SIMPLE
      credentialName: my-tls-secret
    hosts:
    - "myapp.example.com"
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "myapp.example.com"
    tls:
      httpsRedirect: true

NLB 장점 ​

  • 높은 성능: 초당 수백만 요청 처리
  • 낮은 지연시간: Layer 4에서 동작하여 빠른 응답
  • 고정 IP: Elastic IP 할당 가능
  • 프로토콜 지원: TCP, UDP, TLS
  • 비용 효율적: ALB보다 저렴

NLB 사용 시나리오 ​

  • WebSocket, gRPC 등 장시간 연결이 필요한 경우
  • 초당 수백만 요청을 처리해야 하는 경우
  • 고정 IP가 필요한 경우
  • TLS 종료를 Istio에서 수행하려는 경우

Application Load Balancer (ALB) 통합 ​

ALB는 Layer 7 (HTTP/HTTPS) 로드 밸런서로, 고급 라우팅 기능이 필요한 경우 적합합니다.

ALB 아키텍처 ​

ALB 설정 ​

1. Ingress 리소스로 ALB 생성

yaml
# istio-ingress-alb.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: istio-ingress
  namespace: istio-system
  annotations:
    # ALB 설정
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: ip
    alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80}, {"HTTPS": 443}]'
    alb.ingress.kubernetes.io/ssl-redirect: '443'

    # ACM 인증서
    alb.ingress.kubernetes.io/certificate-arn: arn:aws:acm:region:account:certificate/cert-id

    # 헬스 체크
    alb.ingress.kubernetes.io/healthcheck-protocol: HTTP
    alb.ingress.kubernetes.io/healthcheck-port: '15021'
    alb.ingress.kubernetes.io/healthcheck-path: /healthz/ready
    alb.ingress.kubernetes.io/healthcheck-interval-seconds: '15'
    alb.ingress.kubernetes.io/healthcheck-timeout-seconds: '5'
    alb.ingress.kubernetes.io/success-codes: '200'
    alb.ingress.kubernetes.io/healthy-threshold-count: '2'
    alb.ingress.kubernetes.io/unhealthy-threshold-count: '2'

    # 추가 설정
    alb.ingress.kubernetes.io/load-balancer-attributes: idle_timeout.timeout_seconds=60
    alb.ingress.kubernetes.io/target-group-attributes: deregistration_delay.timeout_seconds=30
spec:
  ingressClassName: alb
  rules:
  - host: "myapp.example.com"
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: istio-ingressgateway
            port:
              number: 80

2. 경로 기반 라우팅

yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: istio-ingress-path-based
  namespace: istio-system
  annotations:
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: ip
spec:
  ingressClassName: alb
  rules:
  - host: "api.example.com"
    http:
      paths:
      - path: /v1
        pathType: Prefix
        backend:
          service:
            name: istio-ingressgateway
            port:
              number: 80
  - host: "admin.example.com"
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: istio-ingressgateway
            port:
              number: 80

ALB 장점 ​

  • 고급 라우팅: Path, Header, Query String 기반 라우팅
  • WAF 통합: AWS WAF로 보안 강화
  • 인증 통합: Cognito, OIDC 통합
  • ACM 통합: 인증서 자동 관리
  • 컨테이너 최적화: ECS, EKS에 최적화

ALB 사용 시나리오 ​

  • HTTP/HTTPS 전용 트래픽
  • 경로 기반 라우팅이 필요한 경우
  • WAF 보안이 필요한 경우
  • 여러 도메인을 단일 로드 밸런서에서 처리하는 경우

NLB vs ALB 비교 ​

특성NLBALB
OSI LayerLayer 4 (TCP/UDP)Layer 7 (HTTP/HTTPS)
성능초당 수백만 요청초당 수만 요청
지연시간매우 낮음낮음
고정 IP지원 (Elastic IP)미지원
TLS 종료TCP로 전달 (Istio에서 처리)ALB에서 처리 가능
라우팅IP/Port 기반Path, Host, Header 기반
WAF 통합불가가능
비용저렴상대적으로 비쌈
WebSocket네이티브 지원지원
gRPC네이티브 지원HTTP/2 필요
권장 사용높은 성능, WebSocket, gRPCHTTP 라우팅, WAF, 인증

Istio vs 다른 솔루션 비교 ​

Istio vs VPC Lattice ​

VPC Lattice는 AWS의 관리형 애플리케이션 네트워킹 서비스입니다.

아키텍처 비교 ​

기능 비교 ​

특성IstioVPC Lattice
관리 주체자체 관리 (Self-managed)AWS 관리형 (Fully-managed)
사이드카필요 (Sidecar 또는 Ambient)불필요
리소스 오버헤드높음 (각 파드에 Envoy)낮음 (사이드카 없음)
복잡도높음낮음
학습 곡선가파름완만함
트래픽 관리매우 고급 (세밀한 제어)기본적 (충분한 기능)
mTLS자동, 세밀한 제어지원
Observability풍부한 메트릭, 트레이스기본 메트릭
Fault Injection지원미지원
Circuit Breaker세밀한 제어기본 기능
Rate LimitingLocal + Global기본 기능
Multi-cluster강력한 지원VPC 간 연결
크로스 계정복잡간단 (네이티브 지원)
비용컴퓨팅 비용 (EC2)서비스 사용 비용
벤더 종속없음 (오픈소스)AWS 종속
Kubernetes 전용예아니오 (EC2, Lambda 등)

언제 Istio를 선택할까? ​

Istio가 적합한 경우:

  1. 세밀한 트래픽 제어 필요
    • Canary 배포, A/B 테스트, Traffic Mirroring
    • 복잡한 라우팅 규칙 (Header, Cookie 기반 등)
    • Fault Injection으로 Chaos Engineering
  2. 강력한 보안 요구사항
    • 서비스 간 자동 mTLS 암호화
    • 세밀한 권한 부여 정책
    • JWT 검증, RBAC
  3. 고급 관찰성 필요
    • 상세한 메트릭 (Latency P50/P95/P99)
    • 분산 추적 (Jaeger, Zipkin)
    • 서비스 토폴로지 시각화 (Kiali)
  4. 멀티 클러스터 메시
    • 여러 EKS 클러스터 간 통신
    • 클러스터 간 페일오버
    • 글로벌 로드 밸런싱
  5. 벤더 독립성
    • 다른 클라우드 또는 온프레미스로 이동 가능성
    • Kubernetes 표준 사용

예제: Istio의 고급 트래픽 관리

yaml
apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
  - reviews
  http:
  # Header 기반 라우팅
  - match:
    - headers:
        user-agent:
          regex: ".*Mobile.*"
    route:
    - destination:
        host: reviews
        subset: mobile-v2
  # Canary 배포 (10%)
  - match:
    - headers:
        x-canary:
          exact: "true"
    route:
    - destination:
        host: reviews
        subset: v3
      weight: 10
    - destination:
        host: reviews
        subset: v2
      weight: 90
  # Traffic Mirroring
  - route:
    - destination:
        host: reviews
        subset: v2
    mirror:
      host: reviews
      subset: v3
    mirrorPercentage:
      value: 100

언제 VPC Lattice를 선택할까? ​

VPC Lattice가 적합한 경우:

  1. 간단한 서비스 연결
    • 기본적인 로드 밸런싱과 라우팅만 필요
    • 빠른 구현이 중요
  2. 낮은 운영 오버헤드
    • AWS 관리형 서비스 선호
    • 사이드카 관리 부담 없음
  3. 크로스 VPC/계정 통신
    • 여러 AWS 계정 간 서비스 연결
    • VPC 피어링 없이 통신
  4. 혼합 환경
    • EKS + EC2 + Lambda 혼합 환경
    • Kubernetes만이 아닌 다양한 컴퓨팅 사용
  5. 비용 최적화
    • 사이드카 리소스 비용 절감
    • 작은 규모의 서비스

Istio + VPC Lattice 함께 사용하기 ​

두 솔루션은 상호 배타적이지 않으며, 함께 사용할 수 있습니다:

사용 사례:

  • 클러스터 내부: Istio로 세밀한 트래픽 관리와 보안
  • 클러스터 간/크로스 계정: VPC Lattice로 간단한 연결
  • 혼합 환경: Istio 클러스터와 Lambda/EC2 연결에 VPC Lattice 사용

Istio vs Cilium (eBPF 기반) ​

Cilium은 eBPF를 사용하는 Kubernetes 네트워킹 및 보안 솔루션입니다.

아키텍처 비교 ​

특성IstioCilium
기술 스택Envoy Proxy (사이드카)eBPF (커널 레벨)
주요 목적Service MeshCNI + Service Mesh
네트워킹Kubernetes CNI 위에 동작CNI 자체를 제공
성능좋음매우 우수 (커널 레벨)
리소스 사용높음 (사이드카)낮음 (커널 레벨)
L7 기능매우 강력기본적
관찰성풍부함Hubble (기본적)
학습 곡선가파름가파름
성숙도높음중간 (Service Mesh 기능)

기능 비교 ​

기능IstioCilium
Network PolicyKubernetes + IstioKubernetes + Cilium (더 강력)
L7 Load Balancing매우 세밀함기본적
mTLS자동, 세밀한 제어지원
Traffic Management매우 고급기본적
ObservabilityPrometheus, Jaeger, KialiHubble
성능좋음우수
Multi-cluster강력함Cluster Mesh

언제 무엇을 선택할까? ​

Istio 선택:

  • L7 트래픽 관리가 핵심 요구사항
  • 강력한 서비스 메시 기능 필요
  • 풍부한 관찰성과 디버깅 도구 필요

Cilium 선택:

  • CNI 교체를 고려 중
  • 네트워크 보안이 주 관심사
  • 성능 최적화가 중요
  • eBPF 기술 활용 원함

함께 사용:

  • Cilium을 CNI로, Istio를 Service Mesh로 사용 가능
  • 단, 기능 중복과 복잡도 증가 고려 필요

EKS 특화 최적화 ​

IAM Roles for Service Accounts (IRSA) 통합 ​

Istio 워크로드가 AWS 서비스에 안전하게 접근할 수 있도록 IRSA를 설정합니다.

IRSA 설정 ​

bash
# 1. OIDC 프로바이더 생성
eksctl utils associate-iam-oidc-provider \
    --cluster my-cluster \
    --approve

# 2. IAM 정책 생성
cat <<EOF > app-policy.json
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:GetObject",
                "s3:ListBucket"
            ],
            "Resource": [
                "arn:aws:s3:::my-bucket",
                "arn:aws:s3:::my-bucket/*"
            ]
        }
    ]
}
EOF

aws iam create-policy \
    --policy-name MyAppS3Policy \
    --policy-document file://app-policy.json

# 3. Service Account에 IAM Role 연결
eksctl create iamserviceaccount \
    --cluster my-cluster \
    --namespace default \
    --name my-app-sa \
    --attach-policy-arn arn:aws:iam::<ACCOUNT_ID>:policy/MyAppS3Policy \
    --approve

Istio와 IRSA 사용 ​

yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-app-sa
  namespace: default
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::<ACCOUNT_ID>:role/my-app-role
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
  namespace: default
spec:
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      serviceAccountName: my-app-sa  # IRSA 사용
      containers:
      - name: app
        image: my-app:latest
        env:
        - name: AWS_REGION
          value: us-west-2

AWS Certificate Manager (ACM) 통합 ​

ACM 인증서를 Istio Gateway에서 사용하는 방법입니다.

NLB에서 TLS 종료 ​

yaml
apiVersion: v1
kind: Service
metadata:
  name: istio-ingressgateway
  namespace: istio-system
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-type: "external"
    service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: "ip"
    service.beta.kubernetes.io/aws-load-balancer-ssl-cert: "arn:aws:acm:region:account:certificate/cert-id"
    service.beta.kubernetes.io/aws-load-balancer-ssl-ports: "443"
    service.beta.kubernetes.io/aws-load-balancer-backend-protocol: "tcp"
spec:
  type: LoadBalancer
  selector:
    istio: ingressgateway
  ports:
  - name: https
    port: 443
    targetPort: 8443

Istio에서 TLS 종료 (ACM Private CA) ​

bash
# 1. ACM Private CA에서 인증서 발급
aws acm-pca issue-certificate \
    --certificate-authority-arn arn:aws:acm-pca:region:account:certificate-authority/ca-id \
    --csr file://csr.pem \
    --signing-algorithm "SHA256WITHRSA" \
    --validity Value=365,Type="DAYS"

# 2. Kubernetes Secret 생성
kubectl create secret tls my-tls-secret \
    --cert=certificate.pem \
    --key=private-key.pem \
    -n istio-system

# 3. Gateway에서 사용
yaml
apiVersion: networking.istio.io/v1
kind: Gateway
metadata:
  name: my-gateway
  namespace: istio-system
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 443
      name: https
      protocol: HTTPS
    tls:
      mode: SIMPLE
      credentialName: my-tls-secret  # ACM 인증서
    hosts:
    - "myapp.example.com"

CloudWatch Container Insights 통합 ​

Istio 메트릭을 CloudWatch로 전송하여 통합 모니터링을 구현합니다.

CloudWatch Agent 설정 ​

bash
# 1. IAM 정책 연결
eksctl create iamserviceaccount \
    --cluster my-cluster \
    --namespace amazon-cloudwatch \
    --name cloudwatch-agent \
    --attach-policy-arn arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy \
    --approve

# 2. CloudWatch Agent 설치
kubectl apply -f https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/k8s-deployment-manifest-templates/deployment-mode/daemonset/container-insights-monitoring/cloudwatch-namespace.yaml

kubectl apply -f https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/k8s-deployment-manifest-templates/deployment-mode/daemonset/container-insights-monitoring/cwagent/cwagent-serviceaccount.yaml

Prometheus 메트릭 스크래핑 ​

yaml
# prometheus-config.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: prometheus-config
  namespace: amazon-cloudwatch
data:
  prometheus.yaml: |
    global:
      scrape_interval: 1m
      scrape_timeout: 10s

    scrape_configs:
    # Istio Control Plane 메트릭
    - job_name: 'istiod'
      kubernetes_sd_configs:
      - role: endpoints
        namespaces:
          names:
          - istio-system
      relabel_configs:
      - source_labels: [__meta_kubernetes_service_name, __meta_kubernetes_endpoint_port_name]
        action: keep
        regex: istiod;http-monitoring

    # Envoy 사이드카 메트릭
    - job_name: 'envoy-stats'
      metrics_path: /stats/prometheus
      kubernetes_sd_configs:
      - role: pod
      relabel_configs:
      - source_labels: [__meta_kubernetes_pod_container_port_name]
        action: keep
        regex: '.*-envoy-prom'
      - source_labels: [__address__, __meta_kubernetes_pod_annotation_prometheus_io_port]
        action: replace
        regex: ([^:]+)(?::\d+)?;(\d+)
        replacement: $1:15090
        target_label: __address__

CloudWatch Logs Insights 쿼리 ​

sql
-- Istio 에러 로그 분석
fields @timestamp, @message
| filter @logStream like /istio-proxy/
| filter @message like /error/
| sort @timestamp desc
| limit 100

-- 요청 지연시간 분석
fields @timestamp, request_duration_ms
| filter @logStream like /istio-proxy/
| stats avg(request_duration_ms), max(request_duration_ms), pct(request_duration_ms, 95) by bin(5m)

EKS 최적화 설정 ​

1. Pod Resources 최적화 ​

yaml
# Envoy 사이드카 리소스 최적화
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  meshConfig:
    defaultConfig:
      proxyMetadata:
        # EKS 최적화
        ISTIO_META_DNS_CAPTURE: "true"
        ISTIO_META_DNS_AUTO_ALLOCATE: "true"
  values:
    global:
      proxy:
        resources:
          requests:
            cpu: 100m
            memory: 128Mi
          limits:
            cpu: 2000m
            memory: 1024Mi
        # Connection pool 설정
        concurrency: 2

2. Cluster Autoscaler 고려 ​

yaml
# Istio Gateway Autoscaling
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: istio-ingressgateway
  namespace: istio-system
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: istio-ingressgateway
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 80
  - type: Resource
    resource:
      name: memory
      target:
        type: Utilization
        averageUtilization: 80

3. Pod Disruption Budget ​

yaml
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: istio-ingressgateway
  namespace: istio-system
spec:
  minAvailable: 1
  selector:
    matchLabels:
      app: istio-ingressgateway

모범 사례 ​

1. 로드 밸런서 선택 가이드 ​

NLB 사용:

  • gRPC, WebSocket 등 장시간 연결
  • 초당 수백만 요청 처리
  • 고정 IP 필요
  • TLS 종료를 Istio에서 수행

ALB 사용:

  • HTTP/HTTPS 전용
  • 경로 기반 라우팅
  • WAF 보안 필요
  • Cognito 인증 통합

2. TLS 종료 위치 ​

로드 밸런서에서 종료 (권장):

  • ACM 인증서 자동 갱신
  • 관리 용이
  • Istio 부하 감소

Istio에서 종료:

  • 엔드 투 엔드 암호화 필요
  • 세밀한 TLS 정책 제어
  • mTLS 사용

3. 비용 최적화 ​

  • Spot 인스턴스: Istio Gateway 워크로드에 활용
  • Graviton 인스턴스: ARM 기반으로 비용 절감
  • 리소스 제한: 사이드카 리소스 적절히 설정
  • Ambient Mode: 사이드카 오버헤드 제거 고려

4. 보안 ​

  • IRSA: IAM 역할로 AWS 서비스 접근
  • Security Group: 최소 권한 원칙
  • mTLS: 서비스 간 암호화 활성화
  • Network Policy: Cilium 또는 Calico와 함께 사용

5. 모니터링 ​

  • CloudWatch: 통합 로그 및 메트릭
  • X-Ray: 분산 추적
  • Prometheus + Grafana: 상세 메트릭
  • Kiali: 서비스 메시 시각화

다음 단계 ​

AWS 통합을 완료했다면 다음 문서를 참고하세요:

  1. Traffic Management: 고급 트래픽 관리 기능
  2. Security: mTLS 및 인증/권한 부여
  3. Observability: 메트릭, 로그, 트레이스 수집

참고 자료 ​