모험가

EKS on Outposts - Local Cluster 배포 및 ELB 확인 본문

쿠버네티스/EKS

EKS on Outposts - Local Cluster 배포 및 ELB 확인

라리음 2025. 3. 21. 15:52

 

 

* 잘못된 정보들은 계속해서 수정할 예정이니 말씀 부탁드리겠습니다.

 

 

EKS Local Cluster란?

 

[출처] https://www.youtube.com/watch?v=zxTSKtQkF2M&ab_channel=ContainersfromtheCouch

 

EKS Local Cluster은 간단히 말씀드리면, EKS가 Control Plane을 완전관리형으로 AWS가 관리를 하고 사용자가 신경을 쓰지 않는다면 EKS Local Cluster은 Control Plane, Data Plane을 Outposts로 배포하여서 사용하는 형태입니다.

 

[출처] https://aws.amazon.com/ko/blogs/containers/amazon-eks-on-aws-outposts-now-supports-local-clusters/

 

 

 

EKS Local Cluster을 왜 사용하는가?

 

일반적인 EKS을 사용하게 된다면 AWS Region에 Control Plane을 사용합니다. 이는 Public에 클러스터를 구축하면 상관이 없지만 Outposts에 node를 내렸을 경우에는 AWS Region과 통신이 필요하고, 의존적임을 의미합니다. 편리하지만 만약 AWS Region과 통신이 끊기면 장애로도 연결될 수 있습니다. 이에 Outposts의 역할을 극대화하여 저지연 (IDC와의 물리적 연결), EKS를 사용함에도 더욱 Region과의 통신에 의존적이지 않는 클러스터를 제공합니다.

보통 보안에 민감한 정보들을 고객들이 소유하기 위해서 Outposts를 사용할 수도 있는데, Data Plane뿐만 아니라 Control Plane을 AWS Outposts에 배치하여 안정적이며 AWS Region과의 연결이 끊기더라도 원활한 서비스 운영을 위해서 Local Cluster을 운영합니다.

 

하지만 AWS Ouposts를 사용하여도 EKS Local Cluster만을 사용하지는 않습니다. Extended Cluster(Region과 outposts의 확장된 네트워크에 구축된 Cluster)을 사용할 수 있습니다. 이는 필요한 상황에 따라 방식을 선택할 수 있을 것 같습니다.

 

Extended Cluster vs Local Cluster

 

[출처] https://docs.aws.amazon.com/ko_kr/eks/latest/userguide/eks-outposts.html

 

 

그림과 같이 Extended Cluster은 Control Plane은 AWS Cloud에 배치하고 Data Plane만 Data Center내의 Outposts로 둡니다. 이는 평범한 EKS와 똑같이 사용하되 고객 소유의 Data Center에 데이터들을 적재함으로써 사용합니다.

 

Local Cluster은 Control Plane도 함께 Outposts에 배치함으로써 관리 포인트가 증가하지만 customize가 가능하며, AWS Region과 통신이 끊기더라도 API 서버가 내부에 있기에 안정적인 서비스가 가능합니다.

 

 

특징 Extended Cluster Local Cluster
Control Plane 위치 AWS Region Outposts
Control Plane
소유 계정		 AWS 계정 귀하의 계정
지역별 가용성 서비스 엔드포인트 참조 미국 동부(오하이오), 미국 동부(버지니아 북부), 미국 서부(캘리포니아 북부), 미국 서부(오리건), 아시아 태평양(서울), 아시아 태평양(싱가포르), 아시아 태평양(시드니), 아시아 태평양(도쿄), 캐나다(중부), 유럽(프랑크푸르트), 유럽(아일랜드), 유럽(런던), 중동(바레인), 남미(상파울루)
쿠버네티스
마이너 버전		 지원되는 Amazon EKS 버전 . 지원되는 Amazon EKS 버전 . (퍼블릭 EKS보다 버전 업데이트가 느림)
플랫폼 버전 각 Kubernetes 버전에 대한 Amazon EKS 플랫폼 버전 보기를 참조하세요 . AWS Outposts의 Kubernetes 및 Amazon EKS 플랫폼 버전 알아 보기
아웃포스트 폼 팩터 아웃포스트 랙 아웃포스트 랙
사용자 인터페이스 AWS Management Console, AWS CLI, Amazon EKS API, eksctlAWS CloudFormation 및 Terraform AWS Management Console, AWS CLI, Amazon EKS API, eksctlAWS CloudFormation 및 Terraform
관리되는 정책 AmazonEKSClusterPolicy 및 AWS 관리 정책: AmazonEKSServiceRolePolicy AmazonEKSLocalOutpostClusterPolicy 및 AWS 관리 정책: AmazonEKSLocalOutpostServiceRolePolicy
클러스터 VPC
및 서브넷		 VPC 및 서브넷에 대한 Amazon EKS 네트워킹 요구 사항 보기 AWS Outposts에서 Amazon EKS 클러스터에 대한 VPC 및 서브넷 생성을 참조하세요 .
클러스터
엔드포인트 액세스		 Public, Public&Private,
Private		 Only Private
Kubernetes API
서버 인증		 AWS Identity and Access Management(IAM) 및 OIDC IAM 및 x.509인증서
노드 유형 자체 관리만 가능 자체 관리만 가능
노드 컴퓨팅 유형 Amazon EC2 온디맨드 Amazon EC2 온디맨드
노드 저장 유형 Amazon EBS gp2
및 로컬 NVMe SSD		 Amazon EBS gp2 및 로컬 NVMe SSD
Amazon EKS 최적화된 AMI Amazon Linux, Windows 및 Bottlerocket Amazon Linux만 해당
IP 버전 IPv4 IPv4
추가 기능 Amazon EKS 추가 기능 또는 자체 관리 추가 기능 자체 관리형 애드온만 가능
기본 컨테이너 네트워크 인터페이스 Kubernetes용 Amazon VPC CNI 플러그인 Kubernetes용 Amazon VPC CNI 플러그인
Kubernetes 제어 평면 로그 Amazon CloudWatch 로그 Amazon CloudWatch 로그
부하 분산 AWS Load Balancer Controller를 사용하여 애플리케이션 로드 밸런서만 프로비저닝합니다(네트워크 로드 밸런서는 불가). AWS Load Balancer Controller를 사용하여 애플리케이션 로드 밸런서만 프로비저닝합니다(네트워크 로드 밸런서는 불가).
Secrets envelope encryption 기존 클러스터에서 KMS로 Kubernetes 비밀 암호화 참조 지원되지 않음
서비스 계정에 대한 IAM 역할(IRSA) 서비스 계정에 대한 IAM 역할 보기 지원되지 않음
문제 해결 Amazon EKS 클러스터 및 노드 문제 해결을 참조하세요 . AWS Outposts에서 로컬 Amazon EKS 클러스터 문제 해결을 참조하세요 .

 

 

 

Local Cluster은 확실히 Extended Cluster에 비해 제약적인 것을 확인할 수 있습니다.

Local Cluster에 지원되지 않는 것들은 무엇이 있을까요?

 

Features unsupported on local clusters

- 출처 : https://eksctl.io/usage/outposts/

 

 

위의 것들을 참고하면서 구축하시면 될 것 같습니다.

 

 

 

Local Cluster Control Plane 배포

 

* Outposts와 연결된 계정에서 진행하였습니다. 

 

 

콘솔

 

Outposts가 연결되어있으면, 그림과 같이 사용자 지정 구성으로 Cluster을 구성할 수 있습니다.

저는 콘솔이 아닌 eksctl을 이용해서 배포하겠습니다.

 

 

kubernetes 버전

 

특징으로는 일반적인 EKS와 kubernetes 버전 업데이트가 다르고 지원 기간도 다릅니다.

* 25년 3월 기준

EKS 일반 : 1.32

Local Cluster : 1.30

 

 

사전 준비 사항 

 

1. eksctl 설치

2. 클러스터 배포에 필요한 Role을 지닌 IAM User

3. Outposts와 연결된 VPC, Outposts내의 Subnet

4. 사용가능한 instance 타입 확인

 

cat >outpost-control-plane.yaml <<EOF
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig

metadata:
  name: workload-cluster
  region: region-code
  version: "1.30"

vpc:
  clusterEndpoints:
    privateAccess: true
  id: "vpc-vpc-ExampleID1"
  subnets:
    private:
      outpost-subnet-1:
        id: "subnet-subnet-ExampleID1"

outpost:
  controlPlaneOutpostARN: arn:aws:outposts:region-code:111122223333:outpost/op-uniqueid
  controlPlaneInstanceType: m5.xlarge
EOF

 

위와 같이 클러스터를 배포하기 위한 yaml 파일을 구성합니다.

# 배포
eksctl create cluster -f outpost-control-plane.yaml

 

 

결과 화면

 

addon과 같은 별도의 옵션을 주지 않았는데 DescribeAddon을 실패했다고 오류를 표출합니다.

그래도 controlplane을 생성하는 것에는 성공하였습니다.

콘솔 EC2 화면

 

 

kubectl로 노드와 파드의 정보를 확인해보겠습니다.

# 노드 확인
kubectl get nodes -o wide

# 파드 확인
kubectl get pod -A

노드 정보
파드 정보

 

 

Control Plane의 status가 모두 Not Ready입니다. 이유는 describe의 정보를 보겠습니다.

노드 정보

 

[출처] https://docs.aws.amazon.com/ko_kr/eks/latest/userguide/eks-outposts-local-cluster-create.html

 

컨트롤 플레인 인스턴스에서 워크로드가 예약되지 않도록 각 인스턴스는 node-role.eks-local.amazonaws.com/control-plane으로 테인트됩니다. 

 

 

 

 

콘솔에서도 클러스터를 확인할 수 있으며 addon과 같이 몇가지 탭이 보이지 않는 것을 볼 수 있습니다.

 

 

 

이제 worker node를 배포하겠습니다.

 

# NodeGroup 배포
eksctl create nodegroup --cluster my-cluster --name al-nodes --node-type instance-type \
    --nodes 2 --nodes-min 1 --nodes-max 3 --managed=false --node-volume-type gp2 --subnet-ids subnet-id

노드 정보
콘솔 화면

 

 

노드가 join되었음을 확인하였습니다. 이후 평범하게 사용하시면 됩니다.

 

# 간단한 디플로이먼트 배포
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Namespace
metadata:
  name: game-2048
---
apiVersion: apps/v1
kind: Deployment
metadata:
  namespace: game-2048
  name: deployment-2048
spec:
  selector:
    matchLabels:
      app.kubernetes.io/name: app-2048
  replicas: 2
  template:
    metadata:
      labels:
        app.kubernetes.io/name: app-2048
    spec:
      containers:
      - image: public.ecr.aws/l6m2t8p7/docker-2048:latest
        imagePullPolicy: Always
        name: app-2048
        ports:
        - containerPort: 80
EOJ

결과 화면

 

 

위에서 언급한 것과 같이 현재 Outposts에는 ALB를 지원하지만 NLB를 지원하지 않습니다.

 

간단한 테스트를 진행해봅니다.

 

# 디플로이먼트 & 서비스 생성
cat << EOF > echo-service-nlb.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: deploy-echo
spec:
  replicas: 2
  selector:
    matchLabels:
      app: deploy-websrv
  template:
    metadata:
      labels:
        app: deploy-websrv
    spec:
      terminationGracePeriodSeconds: 0
      containers:
      - name: aews-websrv
        image: k8s.gcr.io/echoserver:1.5
        ports:
        - containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
  name: svc-nlb-ip-type
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: ip
    service.beta.kubernetes.io/aws-load-balancer-scheme: internet-facing
    service.beta.kubernetes.io/aws-load-balancer-healthcheck-port: "8080"
    service.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled: "true"
spec:
  ports:
    - port: 80
      targetPort: 8080
      protocol: TCP
  type: LoadBalancer
  loadBalancerClass: service.k8s.aws/nlb
  selector:
    app: deploy-websrv
EOF
kubectl apply -f echo-service-nlb.yaml

 

# 확인
kubectl describe service svc-nlb-ip-type

# Warning  FailedDeployModel  0s                  service  Failed deploy model due to operation error Elastic Load Balancing v2: CreateLoadBalancer, https response error StatusCode: 400, RequestID: 2687ccc0-f052-44a4-85e1-3a559e6db92f, api error ValidationError: You cannot use Outposts subnets for load balancers of type 'network'

 

로그 내용

 

 

network 타입의 loadbalancer을 outposts subnet에 지원하지 않는다는 내용을 볼 수 있습니다.

 

 

이제 ALB를 배포하고 결과를 확인해봅니다.

 

# 게임 파드와 Service, Ingress 배포
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Namespace
metadata:
  name: game-2048
---
apiVersion: apps/v1
kind: Deployment
metadata:
  namespace: game-2048
  name: deployment-2048
spec:
  selector:
    matchLabels:
      app.kubernetes.io/name: app-2048
  replicas: 2
  template:
    metadata:
      labels:
        app.kubernetes.io/name: app-2048
    spec:
      containers:
      - image: public.ecr.aws/l6m2t8p7/docker-2048:latest
        imagePullPolicy: Always
        name: app-2048
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  namespace: game-2048
  name: service-2048
spec:
  ports:
    - port: 80
      targetPort: 80
      protocol: TCP
  type: NodePort
  selector:
    app.kubernetes.io/name: app-2048
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  namespace: game-2048
  name: ingress-2048
  annotations:
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: ip
spec:
  ingressClassName: alb
  rules:
    - http:
        paths:
        - path: /
          pathType: Prefix
          backend:
            service:
              name: service-2048
              port:
                number: 80
EOF
# 확인
[root@ip-xxx-xx-xx-xxx .kube]# kubectl get pod,svc,ingress -n game-2048
NAME                                  READY   STATUS    RESTARTS   AGE
pod/deployment-2048-85f8c7d69-5xdq4   1/1     Running   0          3d
pod/deployment-2048-85f8c7d69-bkrq2   1/1     Running   0          3d

NAME                   TYPE       CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE
service/service-2048   NodePort   10.100.40.100   <none>        80:31002/TCP   108s

NAME                                     CLASS   HOSTS   ADDRESS                                                                       PORTS   AGE
ingress.networking.k8s.io/ingress-2048   alb     *       k8s-game2048-ingress2-f970eb20ee-208786501.ap-northeast-2.elb.amazonaws.com   80      108s

결과 화면
콘솔 화면
서비스 확인

 

 

ALB는 결국 컴퓨팅을 이용해서 생성하기 때문에 Outposts의 리소스를 활용합니다.

LB를 생성할때마다 컴퓨팅을 한대씩 사용하기 때문에 group 및 slotting을 적합하게 하면 될 것 같습니다.

ELB Outposts 리소스 활용 화면

 

 

 

 

이렇게 EKS Local Cluster에 대해 알아보고 클러스터를 배포하였습니다.

control plane을 사용자가 관리할 수 있는 EKS Local Cluster 어떻게 생각하실까요?

 

 

 

참고 링크

 

https://www.youtube.com/watch?v=zxTSKtQkF2M&ab_channel=ContainersfromtheCouch

 

 

https://aws.amazon.com/ko/blogs/containers/amazon-eks-on-aws-outposts-now-supports-local-clusters/

 

Amazon EKS on AWS Outposts now supports local clusters | Amazon Web Services

Introduction Since its release, Amazon Elastic Kubernetes Service (Amazon EKS) has made it easier to run Kubernetes and container applications reliably at scale. With Amazon EKS on AWS Outposts, you can simplify application delivery onto on-premises AWS Ou

aws.amazon.com

 

https://docs.aws.amazon.com/ko_kr/eks/latest/userguide/eks-outposts.html

 

AWS Outposts를 사용한 Amazon EKS 온프레미스 배포 - Amazon EKS

이 페이지에 작업이 필요하다는 점을 알려 주셔서 감사합니다. 실망시켜 드려 죄송합니다. 잠깐 시간을 내어 설명서를 향상시킬 수 있는 방법에 대해 말씀해 주십시오.

docs.aws.amazon.com

 

 

https://eksctl.io/usage/outposts/

 

AWS Outposts Support - eksctl

The official CLI for Amazon EKS

eksctl.io

 

 

https://docs.aws.amazon.com/ko_kr/eks/latest/userguide/eks-outposts-local-cluster-create.html

 

AWS Outposts에 Amazon EKS 클러스터 배포 - Amazon EKS

이 페이지에 작업이 필요하다는 점을 알려 주셔서 감사합니다. 실망시켜 드려 죄송합니다. 잠깐 시간을 내어 설명서를 향상시킬 수 있는 방법에 대해 말씀해 주십시오.

docs.aws.amazon.com