EKS 네트워크 아키텍처 현황

쿠버네티스 공식 문서 기반으로 네트워킹 및 로드 밸런싱을 스터디하고 있습니다. 관련해서 현재 사용 현황을 정리해 보았습니다. Amazon EKS 네트워크 아키텍처를 고민하는 분들께 도움이 되었으면 합니다.

EKS VPC CNI

EKS 사용하면 당연히(?) VPC CNI를 사용합니다.

장점

• 파드와 노드의 IP 대역이 동일하여 다른 노드의 파드와 통신 시 NAT 등의 추가 과정없이 바로 통신 가능합니다.

주의사항

• 파드 네트워크 대역을 /24가 아닌 /20 등으로 넓게 할당합니다. EKS 업그레이드 등 작업 시 IP가 부족한 경우가 발생할 수 있습니다.
• 당연히 Private Subnet 대역에 파드 배포합니다.

EKS ALB와 LB Controller

장점

• target-type: ip 옵션을 사용하여 네트워크 홉 수를 줄일 수 있습니다. 성능 개선과 디버깅에 용이합니다.

아쉬운점

• NGINX Ingress Controller가 지원하는 리다이렉트 기능 등을 사용할 수 없습니다.
• 현재는 Host URL로 분리하여 이 기능이 필요하지 않지만, 필요 시 새로운 Gateway API 기능으로 해결할 수 있습니다.

Ingress Group

장점

• LB 비용을 줄일 수 있습니다. 하지만, Rule 등록은 100개가 한계이므로 이를 초과할 경우 나누어야 합니다.

External DNS Controller

추가적인 Route 53 작업이 필요 없어 편리합니다.

Ingress 헬름 설정 예시

ingress:
  enabled: true
  className: "alb"
  annotations:
    alb.ingress.kubernetes.io/certificate-arn: arn:xxxx
    alb.ingress.kubernetes.io/listen-ports: '[{"HTTP":80,"HTTPS":443}]'
    alb.ingress.kubernetes.io/actions.ssl-redirect: '{"Type": "redirect", "RedirectConfig": {"Protocol": "HTTPS", "Port": "443", "StatusCode": "HTTP_301"}}'
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: ip
    alb.ingress.kubernetes.io/subnets: subnet-xxxx
    alb.ingress.kubernetes.io/security-groups: sg-xxxx   
    alb.ingress.kubernetes.io/healthcheck-path: /actuator/health/readiness
    alb.ingress.kubernetes.io/healthcheck-interval-seconds: '5'
    alb.ingress.kubernetes.io/healthcheck-timeout-seconds: '3'
    alb.ingress.kubernetes.io/unhealthy-threshold-count: '3'
    alb.ingress.kubernetes.io/success-codes: '200'
    alb.ingress.kubernetes.io/actions.response-404: '{"type":"fixed-response","fixedResponseConfig":{"contentType":"text/plain","statusCode":"404","messageBody":"404 page not found"}}'
    alb.ingress.kubernetes.io/group.name: xxxx.xxxx.xxxx
  hosts:
    - host: xxxx
      paths:
        - path: /
          pathType: Prefix
          backend:
            service:
              name: xxxx
              port:
                number: 80
  tls: []

AWS Client VPN

계정 별 사용자 당 과금 기준이라 비용이 저렴하지 않습니다.

개발자 전부가 사용하지는 않습니다.

내부 직원 연결 용도의 Ingress는 scheme을 전부 internal로 변경하고 싶으나, VPN을 전부 사용하지 못하는 관계로 현재는 internet-facing을 사용하고 Security Group으로 접속을 제한하고 있습니다.

 

이전 회사에서는 WireGuard 기반 Tailscale VPN을 사용하여 저렴하고 편리하게 사용했습니다.

EKS API 서버 연결도 내부 연결로만 제한하여 사용하였습니다.

Network Policy

테스트는 정상적으로 완료하였으나 실제로는 사용하지 않았습니다.

아쉬운점

• ALB IP 네트워크 대역을 지정할 수 없습니다. 보안 요구 사항으로 Network Policy를 반드시 적용해야 할 경우, ALB는 포트만 지정하고 적용해야 할 것 같습니다.

네트워크 관련 Addon 사용

VPC CNI, kube-proxy, CoreDNS를 Addon 으로 사용하고 있으며, CoreDNS는 AutoScaling과 Do-Not-Evict 옵션을 지정했습니다.

{
  "autoScaling": {
    "enabled": true,
    "minReplicas": 3,
    "maxReplicas": 5
  },
  "nodeSelector": {
    "priority": "high"
  },
  "podAnnotations": {
    "karpenter.sh/do-not-disrupt": "true"
  }
}

 

장점

• Terraform 코드로 관리하여 EKS 업그레이드 시 함께 업그레이드할 수 있습니다. 버전은 latest 옵션을 지정했습니다.

가용 영역 (AZ)

개발 EKS는 비용 절감을 목적으로 단일 AZ를 사용합니다.

운영은 3개 AZ 인데, 2개만 사용해도 되지 않을까 싶습니다.

Topology Aware Routing

9개 이상 실행하는 파드들이 많지 않아 적용하지 않았습니다.

서로 다른 계정, VPC 간 연결

AWS 서로 다른 계정 간 VPC 내부 통신으로 설정해야 하나, (게으름으로) 일부 External 통신 설정을 유지하고 있습니다.

TGW, VPC Peering 사용 중

(게으름으로) 기존 VPC Peering 구성을 변경하지 않았습니다.

VPC, Subnet 구분

각 서비스별로 VPC를 구분하고, DB, Public, Private, Intra 등으로 Subnet을 세분화했습니다.