하이브리드 노드 사전 요구 사항 설정
하이브리드 노드 사전 요구 사항 설정
Amazon EKS Hybrid Nodes를 사용하기 위한 온프레미스 연결, 인프라, 운영 체제, IAM 자격 증명 공급자 등 사전 요구 사항을 설명합니다.
출처: 문서
본문
Amazon EKS Hybrid Nodes를 사용하려면 온프레미스 환경과 AWS 사이의 개인 연결, 지원되는 운영 체제를 가진 베어 메탈 서버 또는 가상 머신, AWS IAM Roles Anywhere 또는 AWS Systems Manager(SSM) 하이브리드 활성화가 구성되어 있어야 합니다. 하이브리드 노드 수명 주기 전반에 걸쳐 이러한 사전 요구 사항을 관리하는 책임은 사용자에게 있습니다.
- 온프레미스 환경과 AWS 사이의 하이브리드 네트워크 연결
- 물리적 또는 가상 머신 형태의 인프라
- 하이브리드 노드와 호환되는 운영 체제
- 구성된 온프레미스 IAM 자격 증명 공급자
하이브리드 네트워크 연결
Amazon EKS 컨트롤 플레인과 하이브리드 노드 사이의 통신은 클러스터 생성 중 전달한 VPC와 서브넷을 통해 라우팅되며, 이는 Amazon EKS에서 컨트롤 플레인과 노드 네트워킹의 기존 메커니즘을 기반으로 합니다. 온프레미스 환경을 VPC에 연결하는 여러 문서화된 옵션에는 AWS Site-to-Site VPN, AWS Direct Connect, 자체 VPN 연결이 있습니다. 하이브리드 네트워크 연결에 이러한 솔루션을 사용하는 방법은 AWS Site-to-Site VPN 및 AWS Direct Connect 사용자 가이드를 참조하세요.
최적의 경험을 위해 AWS 리전에 대한 하이브리드 노드 연결에 최소 100 Mbps의 안정적인 네트워크 연결과 최대 200ms 왕복 지연 시간을 권장합니다. 이는 대부분의 사용 사례를 수용하는 일반 지침이며 엄격한 요구 사항은 아닙니다. 대역폭과 지연 시간 요구 사항은 하이브리드 노드 수와 애플리케이션 이미지 크기, 애플리케이션 탄력성, 모니터링 및 로깅 구성, 다른 AWS 서비스에 저장된 데이터 접근에 대한 애플리케이션 의존성 같은 워크로드 특성에 따라 달라질 수 있습니다. 프로덕션에 배포하기 전에 자체 애플리케이션과 환경으로 테스트하여 네트워킹 설정이 워크로드 요구 사항을 충족하는지 검증할 것을 권장합니다.
온프레미스 네트워크 구성
Amazon EKS 컨트롤 플레인이 하이브리드 노드에서 실행되는 kubelet 및 선택적으로 하이브리드 노드에서 실행되는 웹훅(webhooks)과 통신할 수 있도록 Amazon EKS 컨트롤 플레인에서 온프레미스 환경으로의 인바운드 네트워크 액세스를 활성화해야 합니다. 또한 하이브리드 노드와 그 위에서 실행되는 구성 요소가 Amazon EKS 컨트롤 플레인과 통신할 수 있도록 온프레미스 환경에서 아웃바운드 네트워크 액세스를 활성화해야 합니다. 이 통신을 AWS Direct Connect, AWS Site-to-Site VPN 또는 자체 VPN 연결에 완전히 비공개로 유지하도록 구성할 수 있습니다.
온프레미스 노드 및 Pod 네트워크에 사용하는 CIDR(Classless Inter-Domain Routing) 범위는 IPv4 RFC-1918 또는 CGNAT 주소 범위를 사용해야 합니다. 온프레미스 라우터는 온프레미스 노드 및 선택적으로 Pod에 대한 경로로 구성되어야 합니다. 방화벽과 온프레미스 환경에서 활성화해야 하는 전체 필수 포트 및 프로토콜 목록을 포함한 온프레미스 네트워크 요구 사항에 대한 자세한 내용은 온프레미스 네트워킹 구성을 참조하세요.
EKS 클러스터 구성
지연 시간을 최소화하려면 온프레미스 또는 엣지 환경에 가장 가까운 AWS 리전에 Amazon EKS 클러스터를 만들 것을 권장합니다. RemoteNodeNetwork와 RemotePodNetwork라는 두 API 필드를 통해 Amazon EKS 클러스터 생성 중 온프레미스 노드 및 Pod CIDR을 전달합니다. 온프레미스 네트워크 팀과 논의하여 온프레미스 노드 및 Pod CIDR을 식별해야 할 수 있습니다. 노드 CIDR은 온프레미스 네트워크에서 할당되고, Pod CIDR은 CNI에 오버레이 네트워크를 사용하는 경우 사용하는 CNI(Container Network Interface)에서 할당됩니다. Cilium과 Calico는 기본적으로 오버레이 네트워크를 사용합니다.
RemoteNodeNetwork 및 RemotePodNetwork 필드를 통해 구성한 온프레미스 노드 및 Pod CIDR은 Amazon EKS 컨트롤 플레인이 VPC를 통해 하이브리드 노드에서 실행되는 kubelet과 Pod로 트래픽을 라우팅하도록 구성하는 데 사용됩니다. 온프레미스 노드 및 Pod CIDR은 서로, 클러스터 생성 중 전달한 VPC CIDR, Amazon EKS 클러스터의 서비스 IPv4 구성과 겹칠 수 없습니다. 또한 온프레미스 라우터가 트래픽을 라우팅할 수 있도록 Pod CIDR은 각 EKS 클러스터에 고유해야 합니다.
Amazon EKS Kubernetes API 서버 엔드포인트에 공용 또는 프라이빗 엔드포인트 접근을 사용할 것을 권장합니다. "Public and Private"을 선택하면 Amazon EKS Kubernetes API 서버 엔드포인트가 VPC 외부에서 실행되는 하이브리드 노드에 대해 항상 공용 IP로 해석되어 하이브리드 노드가 클러스터에 조인하지 못할 수 있습니다. 공용 엔드포인트 접근을 사용하면 Kubernetes API 서버 엔드포인트가 공용 IP로 해석되고 하이브리드 노드에서 Amazon EKS 컨트롤 플레인으로의 통신이 인터넷을 통해 라우팅됩니다. 프라이빗 엔드포인트 접근을 선택하면 Kubernetes API 서버 엔드포인트가 프라이빗 IP로 해석되고 하이브리드 노드에서 Amazon EKS 컨트롤 플레인으로의 통신이 대부분의 경우 AWS Direct Connect 또는 AWS Site-to-Site VPN인 개인 연결 링크를 통해 라우팅됩니다.
VPC 구성
Amazon EKS 클러스터 생성 중 전달하는 VPC의 라우팅 테이블에 가상 프라이빗 게이트웨이(VGW) 또는 트랜짓 게이트웨이(TGW)를 대상으로 하는 온프레미스 노드 및 선택적으로 Pod 네트워크에 대한 경로를 구성해야 합니다. 예시는 아래와 같습니다. REMOTE_NODE_CIDR과 REMOTE_POD_CIDR을 온프레미스 네트워크의 값으로 바꾸세요.
| 목적지 | 대상 | 설명 |
|---|---|---|
| 10.226.0.0/16 | local | VPC 내에서 라우팅되는 VPC 로컬 트래픽 |
| REMOTE_NODE_CIDR | tgw-abcdef123456 | 온프레미스 노드 CIDR, 트래픽을 TGW로 라우팅 |
| REMOTE_POD_CIDR | tgw-abcdef123456 | 온프레미스 Pod CIDR, 트래픽을 TGW로 라우팅 |
보안 그룹 구성
클러스터를 만들 때 Amazon EKS는 eks-cluster-sg-로 이름이 지정된 보안 그룹을 생성합니다. 이 Cluster Security Group의 인바운드 규칙은 변경할 수 없지만 아웃바운드 규칙은 제한할 수 있습니다. 하이브리드 노드에서 실행되는 kubelet 및 선택적으로 웹훅이 Amazon EKS 컨트롤 플레인에 연결할 수 있도록 클러스터에 추가 보안 그룹을 추가해야 합니다. 이 추가 보안 그룹에 필요한 인바운드 규칙은 아래와 같습니다. REMOTE_NODE_CIDR과 REMOTE_POD_CIDR을 온프레미스 네트워크의 값으로 바꾸세요.
| 이름 | 보안 그룹 규칙 ID | IP 버전 | 유형 | 프로토콜 | 포트 범위 | 소스 |
|---|---|---|---|---|---|---|
| On-prem node inbound | sgr-abcdef123456 | IPv4 | HTTPS | TCP | 443 | REMOTE_NODE_CIDR |
| On-prem pod inbound | sgr-abcdef654321 | IPv4 | HTTPS | TCP | 443 | REMOTE_POD_CIDR |
인프라
하이브리드 노드로 사용할 베어 메탈 서버 또는 가상 머신이 있어야 합니다. 하이브리드 노드는 기본 인프라에 대해 애그노스틱하며 x86 및 ARM 아키텍처를 지원합니다. Amazon EKS Hybrid Nodes는 bring your own infrastructure 접근 방식을 따르며, 하이브리드 노드에 사용하는 베어 메탈 서버 또는 가상 머신을 프로비저닝하고 관리하는 책임은 사용자에게 있습니다. 엄격한 최소 자원 요구 사항은 없지만 하이브리드 노드에 최소 1 vCPU와 1GiB RAM을 가진 호스트를 사용할 것을 권장합니다.
운영 체제
Bottlerocket, Amazon Linux 2023(AL2023), Ubuntu, RHEL이 하이브리드 노드의 노드 운영 체제로 지속적으로 검증됩니다. Bottlerocket은 VMware vSphere 환경에서만 AWS에서 지원됩니다. AL2023은 Amazon EC2 외부에서 실행될 때 AWS Support 요금제로 포함되지 않습니다. AL2023은 온프레미스 가상화 환경에서만 사용할 수 있으며 자세한 내용은 Amazon Linux 2023 사용자 가이드를 참조하세요. AWS는 Ubuntu 및 RHEL 운영 체제와의 하이브리드 노드 통합을 지원하지만 운영 체제 자체에 대한 지원은 제공하지 않습니다.
운영 체제 프로비저닝과 관리는 사용자 책임입니다. 하이브리드 노드를 처음 테스트할 때는 이미 프로비저닝된 호스트에서 Amazon EKS Hybrid Nodes CLI(nodeadm)를 실행하는 것이 가장 쉽습니다. 프로덕션 배포의 경우 nodeadm을 골든 운영 체제 이미지에 포함하고 호스트 시작 시 호스트가 Amazon EKS 클러스터에 자동으로 조인하도록 systemd 서비스로 실행하도록 구성할 것을 권장합니다.
온프레미스 IAM 자격 증명 공급자
Amazon EKS Hybrid Nodes는 Amazon EKS 클러스터로 인증하기 위해 AWS SSM 하이브리드 활성화 또는 AWS IAM Roles Anywhere가 프로비저닝한 임시 IAM 자격 증명을 사용합니다. Amazon EKS Hybrid Nodes CLI(nodeadm)와 함께 AWS SSM 하이브리드 활성화 또는 AWS IAM Roles Anywhere 중 하나를 사용해야 합니다. 온프레미스 환경에 CA(Certificate Authority)가 있는 기존 PKI(Public Key Infrastructure)와 인증서가 없다면 AWS SSM 하이브리드 활성화를 사용할 것을 권장합니다. 온프레미스에 기존 PKI와 인증서가 있다면 AWS IAM Roles Anywhere를 사용하세요.
Amazon EC2에서 실행되는 노드용 Amazon EKS 노드 IAM 역할과 유사하게 하이브리드 노드를 Amazon EKS 클러스터에 조인하는 데 필요한 권한을 가진 Hybrid Nodes IAM Role을 생성합니다. AWS IAM Roles Anywhere를 사용하는 경우 AWS IAM Roles Anywhere가 Hybrid Nodes IAM Role을 수임(assume)하도록 허용하는 신뢰 정책을 구성하고 AWS IAM Roles Anywhere 프로필에 Hybrid Nodes IAM Role을 수임 가능한 역할로 구성합니다. AWS SSM을 사용하는 경우 AWS SSM이 Hybrid Nodes IAM Role을 수임하도록 허용하는 신뢰 정책을 구성하고 Hybrid Nodes IAM Role로 하이브리드 활성화를 생성합니다. 필수 권한으로 Hybrid Nodes IAM Role을 만드는 방법은 하이브리드 노드 자격 증명 준비를 참조하세요.