본문 바로가기
AWS/EKS

[AEWS2] 1-1. Amazon EKS 소개

by okms1017 2024. 3. 9.
728x90

✍ Posted by Immersive Builder  Seong
 

1. Amazon EKS(Elastic Kubernetes Service) 

 
AWS에서 제공하는 쿠버네티스 컨테이너 오케스트레이션을 수행하는 관리형 서비스입니다. 
 

 

  • 쿠버네티스의 주요 작업을 담당하는 Control Plane의 가용성과 확장성을 관리합니다. 
  • 여러 가용영역에 Control Plane을 구성하여 고가용성을 보장합니다. 
  • Control Plane은 클러스터의 크기를 자동으로 조정하고, 비정상적인 인스턴스를 감지하고 교체하며, 자동화된 쿠버네티스 버전 업데이트 및 패치를 제공합니다. 
  • 컨테이너 이미지 저장소(Amazon ECR), 로드밸런서(ELB), 보안 인증(IAM) 등 다른 AWS 서비스와 통합이 가능합니다. 
  • AWS Management Console, AWS CLI, API, eksctl, kubectl, Terraform 도구를 사용하여 쿠버네티스 클러스터를 변경할 수 있습니다. 
  • Data Plane이 구동되는 Worker Node의 타입으로 Self-managed EC2, Managed node group, Amazon Fargate를 지원합니다. Amazon Fargate 서비스를 선택하면 EC2 생성 없이도 파드를 실행할 수 있습니다. 
  • 오픈소스 쿠버네티스 소프트웨어의 최신 버전을 실행하므로 쿠버네티스 커뮤니티에서 모든 기존 플러그인과 도구를 사용할 수 있습니다. 
  • 또한, 표준 쿠버네티스 어플리케이션을 Amazon EKS로 쉽게 마이그레이션할 수 있습니다. 

 

지원 버전 

  • v1.29.Y => Major.Minor.Patch 
  • 현재(24.03.07) 기준, 1.25 ~29 버전 표준 지원 및 1.23 ~24 버전 추가 지원 
  • 쿠버네티스 버전은 Amazon EKS 릴리스 이후 14개월 동안 표준 지원합니다. 
  • 표준 지원 종료 이전, 비용을 추가하여 해당 버전으로 12개월 연장 지원이 가능합니다. 
  • 평균 3개월 주기로 마이너 업데이트 버전을 제공하고 있습니다. 

Amazon EKS Kubernetes Release (24.03.07 기준)

 


2. EKS Architecture

Control Plane 

AWS Managed VPC, 3 AZs, 3 API NLBs(A-A), ETCD ELB 등 네트워크로 구성되며 AWS 책임 영역에 해당합니다. 
 

Amazon EKS Control Plane

  • API Server : 사용자 및 워커가 쿠버네티스 클러스터와 상호작용할 수 있는 엔드포인트로 쿠버네티스의 API 요청을 처리합니다. 최소 2대 이상의 인스턴스를 포함하는 오토스케일링 그룹으로 구성되어 있습니다. 
  • Cloud Controller : 클라우드와 쿠버네티스 환경을 연결하는 역할을 합니다.  
  • Controller Manager : 여러 컨트롤러의 실행 및 정지를 관리하고 쿠버네티스 클러스터를 정상적인 상태로 유지합니다. 
  • Scheduler : 파드를 시작할 노드를 계획하며 여러 조건을 고려하여 최적의 노드를 결정합니다. 
  • etcd : 쿠버네티스 클러스터와 관련된 정보를 저장하는 분산형 키-값(key-value) 저장소입니다. 최소 3대 이상의 인스턴스를 포함하는 오토스케일링 그룹으로 구성되어 있습니다. 

 

Data Plane 

Customer VPC, 3 AZs, 3 EKS owned ENIs, 3 Worker Nodes(Self-managed EC2, Managed node group, Amazon Fargate)
Worker Node의 타입에 따라 AWS 책임 영역과 고객의 책임 영역이 구분됩니다. Self-managed EC2를 선택하는 경우 고객의 책임 영역에 해당하며, Amazon Fargate를 선택하는 경우 AWS 책임 영역에 해당합니다. 
 
** Worker Node Type

  • Self-managed EC2 : Custom AMI를 이용하고 오토스케일링 그룹을 고객이 직접 관리합니다. OS 기본구성 및 패치에 대한 책임은 고객의 책임 영역에 해당합니다. 
  • Managed node group : 최신 EKS Optimized AMI를 사용하며 새로운 AMI 배포 및 구버전 AMI 제거 등을 모두 자동화하여 AWS에서 처리합니다. On-Demand 인스턴스와 Spot 인스턴스 유형을 제공합니다. 
  • AWS Fargate : 별도로 관리하는 EC2 인스턴스 없이 Fargate 환경에서 제공하는 Micro VM을 이용하여 파드별 VM을 할당합니다. 

 

Amazon EKS Data Plane

  • EKS owned ENI : Control Plane과 Data Plane 간에 통신하기 위한 네트워크 인터페이스입니다.
  • Pod : 쿠버네티스가 컨테이너를 관리하는 최소 단위로 하나 이상의 컨테이너로 구성됩니다. 
  • kubelet : Control Plane으로부터 PodSpec을 가져와 컨테이너 런타임 인터페이스에 접근하여 컨테이너를 모니터링하고 실행 및 정지합니다. 
  • kube-proxy : Control Plane에서 네트워크 구성을 가져온 다음, 파드 간 통신할 때 접근을 중계하고 주소변환 규칙을 변경합니다. 

 

클러스터 엔드포인트 - Public 

VPC 외부에서 클러스터 엔드포인트에 접근합니다. Worker Node에서 발생하는 트래픽은 클러스터 엔드포인트에 연결하기 위해 VPC 외부로 나갑니다. Worker Node에서 Public 도메인 제어부로 나가는 구간이 VPC 외부에 노출되므로 보안상 좋지 않습니다. 
 

Amazon EKS Cluster Endpoint - Public
Amazon EKS API 서버 엔드포인트 - Public

EKS owned ENI를 확인합니다. 
 

# kubelet, kube-proxy Peer Address 조회 => EKS Public Endpoint 
$ for i in $N1 $N2; do echo ">> node $i <<"; ssh ec2-user@$i sudo ss -tnp; echo; done
```
>> node 192.168.1.204 <<
State Recv-Q Send-Q Local Address:Port   Peer Address:Port Process                                               
ESTAB 0      0      192.168.1.204:44084  3.34.148.207:443   users:(("kubelet",pid=2931,fd=12))  
ESTAB 0      0      192.168.1.204:51246   3.38.61.180:443   users:(("kube-proxy",pid=3140,fd=7)) 
```
>> node 192.168.2.78 <<
State Recv-Q Send-Q Local Address:Port   Peer Address:Port Process
ESTAB 0      0       192.168.2.78:39258  3.34.148.207:443   users:(("kubelet",pid=2930,fd=24))
ESTAB 0      0       192.168.2.78:60226   3.38.61.180:443   users:(("kube-proxy",pid=3136,fd=7))
```

# Pod & Container 내부로 진입 
$ kubectl exec daemonsets/aws-node -it -n kube-system -c aws-eks-nodeagent -- bash
# EKS owned ENI 조회
$ for i in $N1 $N2; do echo ">> node $i <<"; ssh ec2-user@$i sudo ss -tnp; echo; done
```
>> node 192.168.1.204 <<
State Recv-Q Send-Q          Local Address:Port            Peer Address:Port Process                             
ESTAB 0      0      [::ffff:192.168.1.204]:10250 [::ffff:192.168.1.231]:60974 users:(("kubelet",pid=2931,fd=23))

 

EKS owned ENI

 

클러스터 엔드포인트 - Public Private 

Public과 동일하게 VPC 외부에서 클러스터 엔드포인트에 접근합니다. 반면, 클러스터 엔드포인트에 대한 Worker Node 트래픽은 VPC 내에서 유지됩니다. 즉, Worker Node에서 EKS owned ENI를 통해 API Server에 요청을 보내므로 Public 방식과 비교하여 보안성이 좋습니다.   
 

Amazon EKS Cluster Endpoint - Public Private

EKS 클러스터 엔드포인트를 Public Private 방식으로 변경합니다. 
 

# 클러스터 엔드포인트: Public -> Public + Private 변경 
$ aws eks update-cluster-config --region $AWS_DEFAULT_REGION --name $CLUSTER_NAME --resources-vpc-config endpointPublicAccess=true,publicAccessCidrs="$(curl -s ipinfo.io/ip)/32",endpointPrivateAccess=true
{
    "update": {
        "id": "b0e83602-284e-4719-90cb-3870887d1c79",
        "status": "InProgress",
        "type": "EndpointAccessUpdate",
        "params": [
            {
                "type": "EndpointPublicAccess",
                "value": "true"
            },
            {
                "type": "EndpointPrivateAccess",
                "value": "true"
            },
            {
                "type": "PublicAccessCidrs",
                "value": "[\"43.200.252.56/32\"]"
            }
        ],
        "createdAt": "2024-03-09T01:05:41.350000+09:00",
        "errors": []
    }
}

# Control Plane Security Group Rule 추가 
$ aws ec2 describe-security-groups --filters Name=group-name,Values=*ControlPlaneSecurityGroup* --query "SecurityGroups[*].[GroupId]" --output text
CPSGID=$(aws ec2 describe-security-groups --filters Name=group-name,Values=*ControlPlaneSecurityGroup* --query "SecurityGroups[*].[GroupId]" --output text)
echo $CPSGID
$ aws ec2 authorize-security-group-ingress --group-id $CPSGID --protocol '-1' --cidr 192.168.1.100/32
{
    "Return": true,
    "SecurityGroupRules": [
        {
            "SecurityGroupRuleId": "sgr-02cc6bc3e26b38b25",
            "GroupId": "sg-0cb425e1ff2be1103",
            "GroupOwnerId": "732659419746",
            "IsEgress": false,
            "IpProtocol": "-1",
            "FromPort": -1,
            "ToPort": -1,
            "CidrIpv4": "192.168.1.100/32"
        }
    ]
}

# kube-proxy rollout
$ kubectl rollout restart ds/kube-proxy -n kube-system
daemonset.apps/kube-proxy restarted

# kubelet 재시작 
$ for i in $N1 $N2; do echo ">> node $i <<"; ssh ec2-user@$i sudo systemctl restart kubelet; echo; done

# 모니터링1: 엔드포인트 IP 주소 변경 확인 
$ while true; do dig +short $APIDNS ; echo "------------------------------" ; date; sleep 1; done
------------------------------
3.34.148.207
3.38.61.180
------------------------------
192.168.1.231
192.168.2.210
------------------------------

# 모니터링2: kubelet, kube-proxy Peer Address 변경 확인 
$ while true; do ssh ec2-user@$N1 sudo ss -tnp | egrep 'kubelet|kube-proxy' ; echo ; ssh ec2-user@$N2 sudo ss -tnp | egrep 'kubelet|kube-proxy' ; echo "------------------------------" ; date; sleep 1; done
------------------------------
ESTAB 0      0      192.168.1.204:44084  3.34.148.207:443   users:(("kubelet",pid=2931,fd=12))                   
ESTAB 0      0      192.168.1.204:51246   3.38.61.180:443   users:(("kube-proxy",pid=3140,fd=7))                 

ESTAB 0      0      192.168.2.159:44226  3.34.148.207:443   users:(("kubelet",pid=2936,fd=23))                   
ESTAB 0      0      192.168.2.159:35120   3.38.61.180:443   users:(("kube-proxy",pid=3142,fd=7))                 
------------------------------
ESTAB 0      0      192.168.1.204:57828 192.168.1.231:443   users:(("kubelet",pid=212326,fd=26))                 
ESTAB 0      0      192.168.1.204:33480 192.168.2.210:443   users:(("kube-proxy",pid=209735,fd=7))               

ESTAB 0      0      192.168.2.159:36200 192.168.1.231:443   users:(("kubelet",pid=46270,fd=28))                  
ESTAB 0      0      192.168.2.159:45108 192.168.1.231:443   users:(("kube-proxy",pid=43615,fd=7))                
------------------------------

 

Amazon EKS API 서버 엔드포인트 - Public Private
로컬에서 API 서버 엔드포인트 확인

 

클러스터 엔드포인트 - Private 

클러스터 엔드포인트는 VPC를 통해서만 접근합니다. 클러스터 엔드포인트에 대한 Worker Node 트래픽은 VPC 내에서 유지됩니다. 
 

Amazon EKS Cluster Endpoint - Privarte

 


[출처]
1) Amazon EKS, 중요한 건 꺾이지 않는 안정성 - AWS Summit Seoul 2023 
2) https://docs.aws.amazon.com/ko_kr/eks/latest/userguide/what-is-eks.html 

 

Amazon EKS란 무엇입니까? - Amazon EKS

Amazon EKS란 무엇입니까? Amazon Elastic Kubernetes Service(Amazon EKS)는 Amazon Web Services(AWS)에 Kubernetes 컨트롤 플레인을 설치, 운영 및 유지 관리할 필요가 없는 관리형 서비스입니다. Kubernetes는 컨테이너

docs.aws.amazon.com

3) https://docs.aws.amazon.com/ko_kr/eks/latest/userguide/kubernetes-versions.html 

 

Amazon EKS Kubernetes 버전 - Amazon EKS

Amazon EKS Kubernetes 버전 Kubernetes는 새로운 기능, 디자인 업데이트, 버그 수정으로 빠르게 진화하고 있습니다. 커뮤니티에서는 평균 4개월에 한 번씩 새로운 Kubernetes 마이너 버전(예:1.29)을 릴리스합

docs.aws.amazon.com

4) AWS SA 강인호, Amazon EKS 마이그레이션 요점 정리.pdf 
5) 「그림으로 이해하는 가상화와 컨테이너」 5장 
6) https://docs.aws.amazon.com/ko_kr/eks/latest/userguide/eks-compute.html

 

Amazon EKS 노드 - Amazon EKS

노드는 클러스터를 생성할 때 선택한 서브넷과 동일한 VPC에 있어야 합니다. 하지만 노드가 동일한 서브넷에 있을 필요는 없습니다.

docs.aws.amazon.com

7) https://kubernetes.io/docs/concepts/architecture/control-plane-node-communication/

 

Communication between Nodes and the Control Plane

This document catalogs the communication paths between the API server and the Kubernetes cluster. The intent is to allow users to customize their installation to harden the network configuration such that the cluster can be run on an untrusted network (or

kubernetes.io

8) https://docs.aws.amazon.com/ko_kr/eks/latest/userguide/cluster-endpoint.html

 

Amazon EKS 클러스터 엔드포인트 액세스 제어 - Amazon EKS

다음 명령은 API 서버 엔드포인트에 대한 단일 IP 주소에서 프라이빗 액세스 및 퍼블릭 액세스를 활성화합니다. 203.0.113.5/32를 단일 CIDR 블록 또는 네트워크 액세스를 제한할 쉼표로 구분된 CIDR 블

docs.aws.amazon.com

 

728x90