**이 페이지 개선에 도움 주기**
이 사용자 가이드에 기여하려면 모든 페이지의 오른쪽 창에 있는 **GitHub에서 이 페이지 편집** 링크를 선택합니다.
# 하이브리드 노드에 대한 사전 조건 설정
Amazon EKS Hybrid Nodes를 사용하려면 온프레미스 환경에서 지원되는 운영 체제가 있는 AWS, 베어 메탈 서버 또는 가상 머신으로의 프라이빗 연결과 AWS IAM Roles Anywhere 또는 AWS Systems Manager(SSM) 하이브리드 활성화가 구성되어 있어야 합니다. 하이브리드 노드 수명 주기 전반에 걸쳐 이러한 사전 조건을 관리할 책임은 사용자에게 있습니다.
+ 온프레미스 환경과 AWS 간의 하이브리드 네트워크 연결
+ 물리적 또는 가상 머신 형태의 인프라
+ 하이브리드 노드와 호환되는 운영 체제
+ 구성된 온프레미스 IAM 자격 증명 공급자
![\[하이브리드 노드 네트워크 연결.\]](http://docs.aws.amazon.com/ko_kr/eks/latest/userguide/images/hybrid-prereq-diagram.png)
## 하이브리드 네트워크 연결
Amazon EKS 컨트롤 플레인과 하이브리드 노드 간의 통신은 클러스터 생성 중에 전달하는 VPC와 서브넷을 통해 라우팅되며, 이는 컨트롤 플레인에서 노드 네트워킹을 위한 Amazon EKS의 [기존 메커니즘](https://aws.github.io/aws-eks-best-practices/networking/subnets/)을 기반으로 합니다. AWS Site-to-Site VPN, AWS Direct Connect 또는 자체 VPN 연결을 포함하여 온프레미스 환경을 VPC와 연결하는 데 사용할 수 있는 몇 가지 [문서화된 옵션](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/network-to-amazon-vpc-connectivity-options.html)이 있습니다. 하이브리드 네트워크 연결에 이러한 솔루션을 사용하는 방법에 대한 자세한 내용은 [AWS Site-to-Site VPN](https://docs.aws.amazon.com/vpn/latest/s2svpn/VPC_VPN.html) 및 [AWS Direct Connect](https://docs.aws.amazon.com/directconnect/latest/UserGuide/Welcome.html) 사용 설명서를 참조하세요.
최적의 경험을 위해 AWS 리전의 하이브리드 노드 연결에 최소 100Mbps 및 최대 200ms의 왕복 지연 시간을 제공하는 안정적인 네트워크 연결을 권장합니다. 이는 대부분의 사용 사례에 적용되는 일반적인 지침이지만 엄격한 요구 사항은 아닙니다. 대역폭 및 지연 시간 요구 사항은 하이브리드 노드 수와 애플리케이션 이미지 크기, 애플리케이션 탄력성, 모니터링 및 로깅 구성, 다른 AWS 서비스에 저장된 데이터에 대한 애플리케이션 종속성과 같은 워크로드 특성에 따라 달라질 수 있습니다. 네트워킹 설정이 워크로드의 요구 사항을 충족하는지 확인하려면 프로덕션에 배포하기 전에 자체 애플리케이션 및 환경을 사용하여 테스트하는 것이 좋습니다.
## 온프레미스 네트워크 구성
Amazon EKS 컨트롤 플레인에서 온프레미스 환경으로의 인바운드 네트워크 액세스를 활성화해야 Amazon EKS 컨트롤 플레인이 하이브리드 노드에서 실행 중인 `kubelet`와 통신하고, 선택적으로 하이브리드 노드에서 실행 중인 웹후크와 통신할 수 있습니다. 또한 Amazon EKS 컨트롤 플레인과 통신하려면 하이브리드 노드 및 해당 노드에서 실행되는 구성 요소에 대해 아웃바운드 네트워크 액세스를 활성화해야 합니다. AWS Direct Connect, AWS Site-to-Site VPN 또는 자체 VPN 연결에 대해 완전히 비공개로 유지되도록 이 통신을 구성할 수 있습니다.
온프레미스 노드 및 포드 네트워크에 사용하는 CIDR(Classless Inter-Domain Routing) 범위는 IPv4 RFC-1918 또는 CGNAT 주소 범위를 사용해야 합니다. 온프레미스 라우터는 온프레미스 노드와 선택적으로 포드에 대한 경로로 구성되어야 합니다. 방화벽과 온프레미스 환경에서 활성화해야 하는 필수 포트와 프로토콜의 전체 목록을 포함하여 온프레미스 네트워크 요구 사항에 대한 자세한 내용은 [온프레미스 네트워킹 구성](hybrid-nodes-networking.md#hybrid-nodes-networking-on-prem)을 참조하세요.
## EKS 클러스터 구성
지연 시간을 최소화하려면 온프레미스 또는 엣지 환경에 가장 가까운 AWS 리전에서 Amazon EKS 클러스터를 생성하는 것이 좋습니다. Amazon EKS 클러스터를 생성하는 동안 온프레미스 노드 및 포드 CIDR을 두 개의 API 필드인 `RemoteNodeNetwork` 및 `RemotePodNetwork`를 통해 전달합니다. 온프레미스 네트워크 팀과 상의하여 온프레미스 노드 및 포드 CIDR을 식별해야 할 수 있습니다. 노드 CIDR은 온프레미스 네트워크에서 할당되고 포드 CIDR은 CNI에 오버레이 네트워크를 사용하는 경우, 사용하는 컨테이너 네트워크 인터페이스(CNI)에서 할당됩니다. Cilium과 Calico는 기본적으로 오버레이 네트워크를 사용합니다.
`RemoteNodeNetwork` 및 `RemotePodNetwork` 필드를 통해 구성하는 온프레미스 노드 및 포드 CIDR은 VPC를 통해 하이브리드 노드에서 실행되는 `kubelet`과 포드로 트래픽을 라우팅하도록 Amazon EKS 컨트롤 플레인을 구성하는 데 사용됩니다. 온프레미스 노드 및 포드 CIDR은 서로, 클러스터 생성 중에 전달하는 VPC CIDR 또는 Amazon EKS 클러스터의 서비스 IPv4 구성과 중첩될 수 없습니다. 또한 온프레미스 라우터가 트래픽을 라우팅할 수 있도록 포드 CIDR이 각 EKS 클러스터에 고유해야 합니다.
Amazon EKS Kubernetes API 서버 엔드포인트에 퍼블릭 또는 프라이빗 엔드포인트 액세스 중 하나를 사용하는 것이 좋습니다. '퍼블릭 및 프라이빗'을 선택하면 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 구성
온프레미스 노드의 라우팅 테이블에 있는 경로와 선택적으로 가상 프라이빗 게이트웨이(VGW) 또는 전송 게이트웨이(TGW)를 대상으로 하는 포드 네트워크로 Amazon EKS 클러스터 생성 중에 전달하는 VPC를 구성해야 합니다. 예를 들면 다음과 같습니다. `REMOTE_NODE_CIDR` 및 `REMOTE_POD_CIDR`을 온프레미스 네트워크의 값으로 바꿉니다.
| 대상 주소 | 대상 | 설명 |
| --- | --- | --- |
| 10.226.0.0/16 | 로컬 | VPC 내의 VPC 경로에 대한 로컬 트래픽 |
| REMOTE\$1NODE\$1CIDR | tgw-abcdef123456 | 온프레미스 노드 CIDR, 트래픽을 TGW로 라우팅 |
| REMODE\$1POD\$1CIDR | tgw-abcdef123456 | 온프레미스 포드 CIDR, 트래픽을 TGW로 라우팅 |
## 보안 그룹 구성
클러스터를 생성할 때 Amazon EKS에서 `eks-cluster-sg--`라는 보안 그룹을 만듭니다. 이 클러스터 보안 그룹의 인바운드 규칙은 변경할 수 없지만 아웃바운드 규칙을 제한할 수 있습니다. 하이브리드 노드에서 실행되는 kubelet와 선택적으로 웹후크가 Amazon EKS 컨트롤 플레인에 연결할 수 있게 하려면 클러스터에 보안 그룹을 추가해야 합니다. 이 추가 보안 그룹에 필요한 인바운드 규칙은 다음과 같습니다. `REMOTE_NODE_CIDR` 및 `REMOTE_POD_CIDR`을 온프레미스 네트워크의 값으로 바꿉니다.
| 이름 | 보안 그룹 규칙 ID | IP 버전 | Type | 프로토콜 | 포트 범위 | 소스 |
| --- | --- | --- | --- | --- | --- | --- |
| 온프레미스 노드 인바운드 | sgr-abcdef123456 | IPv4 | HTTPS | TCP | 443 | REMOTE\$1NODE\$1CIDR |
| 온프레미스 포드 인바운드 | sgr-abcdef654321 | IPv4 | HTTPS | TCP | 443 | REMOTE\$1POD\$1CIDR |
## 인프라
하이브리드 노드로 사용할 수 있는 베어 메탈 서버 또는 가상 머신이 있어야 합니다. 하이브리드 노드는 기본 인프라에 구애받지 않으며 x86 및 ARM 아키텍처를 지원합니다. Amazon EKS Hybrid Nodes는 '자체 인프라 구축' 접근 방식을 따르며, 이 방식에서 하이브리드 노드에 사용하는 베어 메탈 서버 또는 가상 머신의 프로비저닝 및 관리는 사용자의 책임입니다. 엄격한 최소 리소스 요구 사항은 없지만 하이브리드 노드에 대해 최소 1개의 vCPU 및 1GiB RAM이 있는 호스트를 사용하는 것이 좋습니다.
## 운영 체제
Bottlerocket, Amazon Linux 2023(AL2023), Ubuntu 및 RHEL은 하이브리드 노드의 노드 운영 체제로 사용하기 위해 지속적으로 검증됩니다. Bottlerocket은 VMware vSphere 환경에서만 AWS에서 지원됩니다. AL2023은 Amazon EC2 외부에서 실행되는 경우 AWS 지원 플랜의 적용을 받지 않습니다. AL2023은 온프레미스 가상화 환경에서만 사용할 수 있습니다. 자세한 내용은 [Amazon Linux 2023 사용 설명서](https://docs.aws.amazon.com/linux/al2023/ug/outside-ec2.html)를 참조하세요. AWS는 Ubuntu 및 RHEL 운영 체제와의 하이브리드 노드 통합을 지원하지만 운영 체제 자체에 대한 지원은 제공하지 않습니다.
운영 체제 프로비저닝 및 관리는 사용자의 책임입니다. 하이브리드 노드를 처음 테스트하는 경우 이미 프로비저닝된 호스트에서 Amazon EKS Hybrid Nodes CLI(`nodeadm`)를 실행하는 것이 가장 쉽습니다. 프로덕션 배포의 경우 호스트 시작 시 호스트를 Amazon EKS 클러스터에 자동으로 조인하기 위해 systemd 서비스로 실행되도록 구성된 `nodeadm`을 골든 운영 체제 이미지에 포함하는 것이 좋습니다.
## 온프레미스 IAM 자격 증명 공급자
Amazon EKS Hybrid Nodes는 AWS SSM 하이브리드 활성화 또는 AWS IAM Roles Anywhere에서 프로비저닝한 임시 IAM 자격 증명을 사용하여 Amazon EKS 클러스터로 인증합니다. Amazon EKS Hybrid Nodes CLI(`nodeadm`)와 함께 AWS SSM 하이브리드 활성화 또는 AWS IAM Roles Anywhere를 사용해야 합니다. 인증 기관(CA)이 있는 기존 퍼블릭 키 인프라(PKI)와 온프레미스 환경에 대한 인증서가 없는 경우 AWS SSM 하이브리드 활성화를 사용하는 것이 좋습니다. 온프레미스에 기존 PKI 및 인증서가 있는 경우 AWS IAM Roles Anywhere를 사용합니다.
Amazon EC2에서 실행되는 노드의 [Amazon EKS 노드 IAM 역할](create-node-role.md)과 마찬가지로 하이브리드 노드를 Amazon EKS 클러스터에 조인하는 데 필요한 권한이 있는 하이브리드 노드 IAM 역할을 생성합니다. AWS IAM Roles Anywhere를 사용하는 경우 AWS IAM Roles Anywhere가 하이브리드 노드 IAM 역할을 수임하고 하이브리드 노드 IAM 역할을 수임 가능한 역할로 사용하여 AWS IAM Roles Anywhere 프로필을 구성하도록 허용하는 신뢰 정책을 구성합니다. AWS SSM을 사용하는 경우 AWS SSM이 하이브리드 노드 IAM 역할을 수임하고 하이브리드 노드 IAM 역할을 사용하여 하이브리드 활성화를 생성하도록 서용하는 신뢰 정책을 구성합니다. 필요한 권한을 가진 하이브리드 노드 IAM 역할을 생성하는 방법은 [하이브리드 노드에 대한 자격 증명 준비](hybrid-nodes-creds.md) 섹션을 참조하세요.
# 하이브리드 노드용 네트워킹 준비
이 주제에서는 Amazon EKS 클러스터를 생성하고 하이브리드 노드를 연결하기 전에 구성해야 하는 네트워킹 설정에 대한 개요를 제공합니다. 이 안내서에서는 [AWS Site-to-Site VPN](https://docs.aws.amazon.com/vpn/latest/s2svpn/SetUpVPNConnections.html), [AWS Direct Connect](https://docs.aws.amazon.com/directconnect/latest/UserGuide/Welcome.html) 또는 자체 VPN 솔루션을 사용하여 하이브리드 네트워크 연결에 대한 사전 요구 사항을 충족했다고 가정합니다.
![\[하이브리드 노드 네트워크 연결.\]](http://docs.aws.amazon.com/ko_kr/eks/latest/userguide/images/hybrid-prereq-diagram.png)
## 온프레미스 네트워킹 구성
### 최소 네트워크 요구 사항
최적의 경험을 위해 AWS 리전의 하이브리드 노드 연결에 최소 100Mbps 및 최대 200ms의 왕복 지연 시간을 제공하는 안정적인 네트워크 연결을 권장합니다. 이는 대부분의 사용 사례에 적용되는 일반적인 지침이지만 엄격한 요구 사항은 아닙니다. 대역폭 및 지연 시간 요구 사항은 하이브리드 노드 수와 애플리케이션 이미지 크기, 애플리케이션 탄력성, 모니터링 및 로깅 구성, 다른 AWS 서비스에 저장된 데이터에 대한 애플리케이션 종속성과 같은 워크로드 특성에 따라 달라질 수 있습니다. 네트워킹 설정이 워크로드의 요구 사항을 충족하는지 확인하려면 프로덕션에 배포하기 전에 자체 애플리케이션 및 환경을 사용하여 테스트하는 것이 좋습니다.
### 온프레미스 노드 및 포드 CIDR
하이브리드 노드에 사용할 노드 및 포드 CIDR과 해당 노드에서 실행되는 워크로드를 식별합니다. 노드 CIDR은 온프레미스 네트워크에서 할당되고 포드 CIDR은 CNI에 오버레이 네트워크를 사용하는 경우 컨테이너 네트워크 인터페이스(CNI)에서 할당됩니다. `RemoteNodeNetwork` 및 `RemotePodNetwork` 필드를 사용하여 EKS 클러스터를 생성할 때 온프레미스 노드 CIDR과 포드 CIDR을 입력으로 전달합니다. 온프레미스 노드 CIDR은 온프레미스 네트워크에서 라우팅 가능해야 합니다. 온프레미스 포드 CIDR 라우팅 가능성에 대한 자세한 내용은 다음 섹션을 참조하세요.
온프레미스 노드 및 포드 CIDR 블록은 다음 요구 사항을 충족해야 합니다.
1. `IPv4` RFC-1918 범위 중 하나(`10.0.0.0/8`, `172.16.0.0/12` 또는 `192.168.0.0/16`) 또는 RFC 6598에 의해 정의된 CGNAT 범위 내(`100.64.0.0/10`)에 있어야 합니다.
1. 서로, EKS 클러스터의 VPC CIDR 또는 Kubernetes 서비스 `IPv4` CIDR과 중첩되지 않습니다.
### 온프레미스 포드 네트워크 라우팅
EKS Hybrid Nodes를 사용할 때 일반적으로 클라우드와 온프레미스 환경 간에 완전한 클러스터 통신 및 기능을 사용할 수 있도록 온프레미스 네트워크에서 온프레미스 포드 CIDR을 라우팅할 수 있게 만드는 것이 좋습니다.
**라우팅 가능한 포드 네트워크**
온프레미스 네트워크에서 포드 네트워크를 라우팅할 수 있게 만들 수 있는 경우 아래 지침을 따르세요.
1. 온프레미스 포드 CIDR을 사용하여 EKS 클러스터의 `RemotePodNetwork` 필드를 구성하고, 온프레미스 포드 CIDR을 사용하여 VPC 라우팅 테이블을 구성하고, 온프레미스 포드 CIDR을 사용하여 EKS 클러스터 보안 그룹을 구성합니다.
1. Border Gateway Protocol(BGP), 정적 경로 또는 기타 사용자 지정 라우팅 솔루션을 포함하여 온프레미스 네트워크에서 온프레미스 포드 CIDR을 라우팅 가능하도록 하는 데 몇 가지 기법을 사용할 수 있습니다. BGP는 사용자 지정 또는 수동 라우팅 구성이 필요한 대체 솔루션보다 더 확장성이 뛰어나고 관리하기 쉽기 때문에 권장되는 솔루션입니다. AWS는 포드 CIDR을 알리는 데 Cilium 및 Calico의 BGP 기능을 지원합니다. 자세한 내용은 [하이브리드 노드에 대한 CNI 구성](hybrid-nodes-cni.md) 및 [라우팅 가능한 원격 포드 CIDR](hybrid-nodes-concepts-kubernetes.md#hybrid-nodes-concepts-k8s-pod-cidrs) 섹션을 참조하세요.
1. EKS 컨트롤 플레인이 웹후크에 할당된 포드 IP 주소와 통신할 수 있으므로 웹후크가 하이브리드 노드에서 실행될 수 있습니다.
1. 클라우드 노드에서 실행되는 워크로드는 동일한 EKS 클러스터의 하이브리드 노드에서 실행되는 워크로드와 직접 통신할 수 있습니다.
1. AWS Application Load Balancer, Amazon Managed Service for Prometheus 등의 다른 AWS 서비스는 하이브리드 노드에서 실행되는 워크로드와 통신하여 네트워크 트래픽의 균형을 맞추고 포드 지표를 스크래핑할 수 있습니다.
**라우팅 불가능한 포드 네트워크**
온프레미스 네트워크에서 포드 네트워크를 라우팅할 수 있게 만들 수 *없는* 경우 아래 지침을 따르세요.
1. 웹후크는 EKS 컨트롤 플레인에서 웹후크에 할당된 포드 IP 주소로 연결해야 하므로 하이브리드 노드에서 웹후크를 실행할 수 없습니다. 이 경우 하이브리드 노드와 동일한 EKS 클러스터의 클라우드 노드에서 웹후크를 실행하는 것이 좋습니다. 자세한 내용은 [하이브리드 노드용 웹후크 구성](hybrid-nodes-webhooks.md)을 참조하세요.
1. 클라우드 노드에서 실행되는 워크로드는 클라우드 노드에 VPC CNI를 사용하고 하이브리드 노드에 Cilium이나 Calico를 사용할 때 하이브리드 노드에서 실행되는 워크로드와 직접 통신할 수 없습니다.
1. 서비스 트래픽 분산을 사용하여 트래픽이 시작되는 영역에 트래픽을 로컬로 유지합니다. 서비스 트래픽 분산에 대한 자세한 내용은 [서비스 트래픽 분산 구성](hybrid-nodes-webhooks.md#hybrid-nodes-mixed-service-traffic-distribution)을 참조하세요.
1. 온프레미스 호스트를 떠나는 포드 트래픽에 대해 송신 매스커레이드 또는 네트워크 주소 변환(NAT)을 사용하도록 CNI를 구성합니다. 이 기능은 Cilium에서 기본적으로 활성화되어 있습니다. Calico에서는 `natOutgoing`을 `true`로 설정해야 합니다.
1. AWS Application Load Balancer, Amazon Managed Service for Prometheus 등의 다른 AWS 서비스는 하이브리드 노드에서 실행되는 워크로드와 통신할 수 없습니다.
### 하이브리드 노드 설치 및 업그레이드 중에 필요한 액세스
호스트에 하이브리드 노드 종속성을 설치하는 설치 프로세스 중에 다음 도메인에 액세스할 수 있어야 합니다. 이 프로세스는 운영 체제 이미지를 빌드할 때 한 번 수행하거나 런타임 시 각 호스트에서 수행할 수 있습니다. 여기에는 초기 설치와 하이브리드 노드의 Kubernetes 버전을 업그레이드할 때도 포함됩니다.
일부 패키지는 OS의 기본 패키지 관리자를 사용하여 설치됩니다. AL2023 및 RHEL의 경우 `yum` 명령은 `containerd`, `ca-certificates`, `iptables` 및 `amazon-ssm-agent`를 설치하는 데 사용됩니다. Ubuntu의 경우 `apt`는 `containerd`, `ca-certificates` 및 `iptables`를 설치하는 데 사용되고, `snap`은 `amazon-ssm-agent`를 설치하는 데 사용됩니다.
| 구성 요소 | URL | 프로토콜 | 포트 |
| --- | --- | --- | --- |
| EKS 노드 아티팩트(S3) | https://hybrid-assets.eks.amazonaws.com | HTTPS | 443 |
| [EKS 서비스 엔드포인트](https://docs.aws.amazon.com/general/latest/gr/eks.html) | https://eks.*region*.amazonaws.com | HTTPS | 443 |
| [ECR 서비스 엔드포인트](https://docs.aws.amazon.com/general/latest/gr/ecr.html) | https://api.ecr.*region*.amazonaws.com | HTTPS | 443 |
| EKS ECR 엔드포인트 | 리전별 엔드포인트는 [Amazon EKS 추가 기능에 대한 Amazon 컨테이너 이미지 레지스트리 보기](add-ons-images.md) 섹션을 참조하세요. | HTTPS | 443 |
| SSM 바이너리 엔드포인트 1 | https://amazon-ssm-*region*.s3.*region*.amazonaws.com | HTTPS | 443 |
| [SSM 서비스 엔드포인트](https://docs.aws.amazon.com/general/latest/gr/ssm.html) 1 | https://ssm.*region*.amazonaws.com | HTTPS | 443 |
| IAM Anywhere 바이너리 엔드포인트 2 | https://rolesanywhere.amazonaws.com | HTTPS | 443 |
| [IAM Anywhere 서비스 엔드포인트](https://docs.aws.amazon.com/general/latest/gr/rolesanywhere.html) 2 | https://rolesanywhere.*region*.amazonaws.com | HTTPS | 443 |
| 운영 체제 패키지 관리자 엔드포인트 | 패키지 리포지토리 엔드포인트는 OS별로 다르며 지리적 리전에 따라 다를 수 있습니다. | HTTPS | 443 |
**참고**
1 AWS SSM 엔드포인트에 대한 액세스는 온프레미스 IAM 자격 증명 공급자에 AWS SSM 하이브리드 활성화를 사용하는 경우에만 필요합니다.
2 AWS IAM 엔드포인트에 대한 액세스는 온프레미스 IAM 자격 증명 공급자에 AWS IAM Roles Anywhere를 사용하는 경우에만 필요합니다.
### 지속적인 클러스터 작업에 필요한 액세스
지속적인 클러스터 작업을 위해서는 온프레미스 방화벽에 대한 다음 네트워크 액세스가 필요합니다.
**중요**
CNI 선택에 따라 CNI 포트에 대한 추가 네트워크 액세스 규칙을 구성해야 합니다. 자세한 내용은 [Cilium documentation](https://docs.cilium.io/en/stable/operations/system_requirements/#firewall-rules) 및 [Calico documentation](https://docs.tigera.io/calico/latest/getting-started/kubernetes/requirements#network-requirements)를 참조하세요.
| Type | 프로토콜 | Direction | 포트 | 소스 | Destination | 사용법 |
| --- | --- | --- | --- | --- | --- | --- |
| HTTPS | TCP | 아웃바운드 | 443 | 원격 노드 CIDR | EKS 클러스터 IP 1 | kubelet에서 Kubernetes API 서버로 |
| HTTPS | TCP | 아웃바운드 | 443 | 원격 포드 CIDR | EKS 클러스터 IP 1 | 포드에서 Kubernetes API 서버로 |
| HTTPS | TCP | 아웃바운드 | 443 | 원격 노드 CIDR | [SSM 서비스 엔드포인트](https://docs.aws.amazon.com/general/latest/gr/ssm.html) | 5분마다 SSM 하이브리드 활성화 자격 증명 새로 고침 및 SSM 하트비트 |
| HTTPS | TCP | 아웃바운드 | 443 | 원격 노드 CIDR | [IAM Anywhere 서비스 엔드포인트](https://docs.aws.amazon.com/general/latest/gr/rolesanywhere.html) | IAM Roles Anywhere 자격 증명 새로 고침 |
| HTTPS | TCP | 아웃바운드 | 443 | 원격 포드 CIDR | [STS 리전 엔드포인트](https://docs.aws.amazon.com/general/latest/gr/sts.html) | 포드에서 STS 엔드포인트로, IRSA에만 필요 |
| HTTPS | TCP | 아웃바운드 | 443 | 원격 노드 CIDR | [Amazon EKS 인증 서비스 엔드포인트](https://docs.aws.amazon.com/general/latest/gr/eks.html) | 노드에서 Amazon EKS 인증 엔드포인트로, Amazon EKS Pod Identity에만 필요 |
| HTTPS | TCP | 인바운드 | 10250 | EKS 클러스터 IP 1 | 원격 노드 CIDR | Kubernetes API 서버에서 kubelet으로 |
| HTTPS | TCP | 인바운드 | 웹후크 포트 | EKS 클러스터 IP 1 | 원격 포드 CIDR | Kubernetes API 서버에서 웹후크로 |
| HTTPS | TCP, UDP | 인바운드, 아웃바운드 | 53 | 원격 포드 CIDR | 원격 포드 CIDR | 포드와 CoreDNS 간. 클라우드에서 CoreDNS 복제본을 1개 이상 실행하는 경우 CoreDNS가 실행 중인 VPC에 대한 DNS 트래픽을 허용해야 합니다. |
| 사용자 정의 | 사용자 정의 | 인바운드, 아웃바운드 | 앱 포트 | 원격 포드 CIDR | 원격 포드 CIDR | 포드 간 |
**참고**
1 EKS 클러스터의 IP입니다. Amazon EKS 탄력적 네트워크 인터페이스에 대한 다음 섹션을 참조하세요.
### Amazon EKS 네트워크 인터페이스
Amazon EKS는 클러스터 생성 중에 전달하는 VPC의 서브넷에 네트워크 인터페이스를 연결하여 EKS 컨트롤 플레인과 VPC 간의 통신을 활성화합니다. Amazon EKS가 생성하는 네트워크 인터페이스는 Amazon EC2 콘솔에서 또는 AWS CLI를 사용하여 클러스터를 생성한 후에 찾을 수 있습니다. Kubernetes 버전 업그레이드와 같이 EKS 클러스터에 변경 사항이 적용되면 원래 네트워크 인터페이스가 삭제되고 새 네트워크 인터페이스가 생성됩니다. 클러스터 생성 중에 전달하는 서브넷에 대해 제한된 서브넷 크기를 사용하여 Amazon EKS 네트워크 인터페이스의 IP 범위를 제한할 수 있습니다. 이렇게 하면 알려진 제한된 IP 세트에 대한 인바운드/아웃바운드 연결을 허용하도록 온프레미스 방화벽을 쉽게 구성할 수 있습니다. 네트워크 인터페이스가 생성되는 서브넷을 제어하려면 클러스터를 생성하거나 클러스터를 생성한 후 서브넷을 업데이트할 때 지정하는 서브넷 수를 제한할 수 있습니다.
Amazon EKS에서 프로비저닝한 네트워크 인터페이스에는 `Amazon EKS your-cluster-name ` 형식에 대한 설명이 있습니다. Amazon EKS가 프로비저닝하는 네트워크 인터페이스의 IP 주소를 찾는 데 사용할 수 있는 AWS CLI 명령은 아래 예제를 참조하세요. `VPC_ID`를 클러스터 생성 중에 전달하는 VPC의 ID로 바꿉니다.
```
aws ec2 describe-network-interfaces \
--query 'NetworkInterfaces[?(VpcId == VPC_ID && contains(Description,Amazon EKS))].PrivateIpAddress'
```
## AWS VPC 및 서브넷 설정
Amazon EKS에 대한 기존 [VPC 및 서브넷 요구 사항](network-reqs.md)은 하이브리드 노드가 있는 클러스터에 적용됩니다. 또한 VPC CIDR은 온프레미스 노드 및 포드 CIDR과 중첩될 수 없습니다. 온프레미스 노드와 선택적으로 포드 CIDR에 대해 VPC 라우팅 테이블에서 경로를 구성해야 합니다. 이 경로는 일반적으로 가상 프라이빗 게이트웨이(VGW) 또는 전송 게이트웨이(TGW)인 하이브리드 네트워크 연결에 사용 중인 게이트웨이로 트래픽을 라우팅하도록 설정되어야 합니다. TGW 또는 VGW를 사용하여 VPC를 온프레미스 환경에 연결하는 경우 VPC에 대한 TGW 또는 VGW 연결을 생성해야 합니다. VPC는 DNS 호스트 이름과 DNS 확인을 모두 지원해야 합니다.
다음 단계에서는 AWS CLI를 사용합니다. AWS Management Console에서 또는 AWS CloudFormation, AWS CDK, Terraform과 같은 다른 인터페이스를 사용하여 이러한 리소스를 생성할 수도 있습니다.
### 1단계: VPC 생성
1. 다음 명령을 실행하여 VPC를 생성합니다. VPC\$1CIDR을 RFC 1918(프라이빗), CGNAT(RFC 6598) 또는 비RFC 1918/비CGNAT(퍼블릭)(예: 10.0.0.0/16)인 IPv4 CIDR 범위로 바꿉니다. 참고: EKS 요구 사항인 DNS 확인은 기본적으로 VPC에 대해 활성화됩니다.
```
aws ec2 create-vpc --cidr-block VPC_CIDR
```
1. VPC의 DNS 호스트 이름을 활성화합니다. 참고로 DNS 확인은 기본적으로 VPC에 대해 활성화됩니다. `VPC_ID`를 이전 단계에서 생성한 VPC의 ID로 바꿉니다.
```
aws ec2 modify-vpc-attribute --vpc-id VPC_ID --enable-dns-hostnames
```
### 2단계: 서브넷 생성
서브넷을 2개 이상 생성합니다. Amazon EKS는 클러스터 네트워크 인터페이스에 이러한 서브넷을 사용합니다. 자세한 내용은 [Subnets requirements and considerations](network-reqs.md#network-requirements-subnets)을 참조하세요.
1. 다음 명령을 사용하여 AWS 리전의 가용 영역을 찾을 수 있습니다. `us-west-2`를 해당 리전으로 바꿉니다.
```
aws ec2 describe-availability-zones \
--query 'AvailabilityZones[?(RegionName == us-west-2)].ZoneName'
```
1. 서브넷을 만듭니다. `VPC_ID`를 VPC의 ID로 바꿉니다. `SUBNET_CIDR`을 서브넷의 CIDR 블록(예: 10.0.1.0/24)으로 바꿉니다. `AZ`를 서브넷이 생성될 가용 영역(예: us-west-2a)으로 바꿉니다. 생성하는 서브넷은 2개 이상의 서로 다른 가용 영역에 있어야 합니다.
```
aws ec2 create-subnet \
--vpc-id VPC_ID \
--cidr-block SUBNET_CIDR \
--availability-zone AZ
```
### (선택 사항) 3단계: Amazon VPC Transit Gateway(TGW) 또는 AWS Direct Connect 가상 프라이빗 게이트웨이(VGW)에 VPC 연결
TGW 또는 VGW를 사용하는 경우 VPC를 TGW 또는 VGW에 연결합니다. 자세한 내용은 [Amazon VPC attachments in Amazon VPC Transit Gateways](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-vpc-attachments.html) 또는 [AWS Direct Connect virtual private gateway associations](https://docs.aws.amazon.com/vpn/latest/s2svpn/how_it_works.html#VPNGateway).를 참조하세요.
**전송 게이트웨이**
다음 명령을 실행하여 전송 게이웨이를 연결합니다. `VPC_ID`를 VPC의 ID로 바꿉니다. `SUBNET_ID1` 및 `SUBNET_ID2`를 이전 단계에서 생성한 서브넷의 ID로 바꿉니다. `TGW_ID`를 TGW의 ID로 바꿉니다.
```
aws ec2 create-transit-gateway-vpc-attachment \
--vpc-id VPC_ID \
--subnet-ids SUBNET_ID1 SUBNET_ID2 \
--transit-gateway-id TGW_ID
```
**가상 프라이빗 게이트웨이**
다음 명령을 실행하여 전송 게이웨이를 연결합니다. `VPN_ID`를 VGW의 ID로 바꿉니다. `VPC_ID`를 VPC의 ID로 바꿉니다.
```
aws ec2 attach-vpn-gateway \
--vpn-gateway-id VPN_ID \
--vpc-id VPC_ID
```
### (선택 사항) 4단계: 라우팅 테이블 생성
VPC의 기본 라우팅 테이블을 수정하거나 사용자 지정 라우팅 테이블을 생성할 수 있습니다. 다음 단계에서는 온프레미스 노드 및 포드 CIDR에 대한 경로가 포함된 사용자 지정 라우팅 테이블을 생성합니다. 자세한 내용은 [Subnet route tables](https://docs.aws.amazon.com/vpc/latest/userguide/subnet-route-tables.html)을 참조하세요. `VPC_ID`를 VPC의 ID로 바꿉니다.
```
aws ec2 create-route-table --vpc-id VPC_ID
```
### 5단계: 온프레미스 노드 및 포드에 대한 경로 생성
각 온프레미스 원격 노드의 라우팅 테이블에서 경로를 생성합니다. VPC의 기본 라우팅 테이블을 수정하거나 이전 단계에서 생성한 사용자 지정 라우팅 테이블을 사용할 수 있습니다.
아래 예제에서는 온프레미스 노드 및 포드 CIDR에 대한 경로를 생성하는 방법을 보여줍니다. 이 예제에서는 전송 게이트웨이(TGW)를 사용하여 VPC를 온프레미스 환경에 연결합니다. 온프레미스 노드와 포드 CIDR이 여러 개인 경우 각 CIDR에 대해 단계를 반복합니다.
+ 인터넷 게이트웨이 또는 가상 프라이빗 게이트웨이(VGW)를 사용하는 경우 `--transit-gateway-id`를 `--gateway-id`로 바꿉니다.
+ `RT_ID`를 이전 단계에서 생성한 라우팅 테이블의 ID로 바꿉니다.
+ `REMOTE_NODE_CIDR`을 하이브리드 노드에 사용할 CIDR 범위로 바꿉니다.
+ `REMOTE_POD_CIDR`을 하이브리드 노드에서 실행되는 포드에 사용할 CIDR 범위로 바꿉니다. 포드 CIDR 범위는 온프레미스 오버레이 네트워크를 가장 일반적으로 사용하는 컨테이너 네트워킹 인터페이스(CNI) 구성에 해당합니다. 자세한 내용은 [하이브리드 노드에 대한 CNI 구성](hybrid-nodes-cni.md) 섹션을 참조하세요.
+ `TGW_ID`를 TGW의 ID로 바꿉니다.
**원격 노드 네트워크**
```
aws ec2 create-route \
--route-table-id RT_ID \
--destination-cidr-block REMOTE_NODE_CIDR \
--transit-gateway-id TGW_ID
```
**원격 포드 네트워크**
```
aws ec2 create-route \
--route-table-id RT_ID \
--destination-cidr-block REMOTE_POD_CIDR \
--transit-gateway-id TGW_ID
```
### (선택 사항) 6단계: 서브넷을 라우팅 테이블에 연결
이전 단계에서 사용자 지정 라우팅 테이블을 생성한 경우 이전 단계에서 생성한 각 서브넷을 사용자 지정 라우팅 테이블과 연결합니다. VPC 기본 라우팅 테이블을 수정하는 경우 서브넷이 VPC의 기본 라우팅 테이블과 자동으로 연결되며 이 단계를 건너뛸 수 있습니다.
이전 단계에서 생성한 각 서브넷에 대해 다음 명령을 실행합니다. `RT_ID`를 이전 단계에서 생성한 라우팅 테이블로 바꿉니다. `SUBNET_ID`를 서브넷의 ID로 바꿉니다.
```
aws ec2 associate-route-table --route-table-id RT_ID --subnet-id SUBNET_ID
```
## 클러스터 보안 그룹 고려 사항
지속적인 클러스터 작업을 위해서는 EKS 클러스터 보안 그룹에 대한 다음 액세스 권한이 필요합니다. Amazon EKS는 원격 노드 및 포드 네트워크가 구성된 클러스터를 생성하거나 업데이트할 때 하이브리드 노드에 필요한 **인바운드** 보안 그룹 규칙을 자동으로 생성합니다. 보안 그룹은 기본적으로 모든 **아웃바운드** 트래픽을 허용하므로 Amazon EKS는 하이브리드 노드에 대한 클러스터 보안 그룹의 **아웃바운드** 규칙을 자동으로 수정하지 않습니다. 클러스터 보안 그룹을 사용자 지정하려면 다음 표의 규칙으로 트래픽을 제한할 수 있습니다.
| Type | 프로토콜 | Direction | 포트 | 소스 | Destination | 사용법 |
| --- | --- | --- | --- | --- | --- | --- |
| HTTPS | TCP | 인바운드 | 443 | 원격 노드 CIDR | 해당 사항 없음 | Kubelet에서 Kubernetes API 서버로 |
| HTTPS | TCP | 인바운드 | 443 | 원격 포드 CIDR | 해당 사항 없음 | CNI가 포드 트래픽에 NAT를 사용하지 않을 때 K8s API 서버에 대한 액세스가 필요한 포드입니다. |
| HTTPS | TCP | 아웃바운드 | 10250 | 해당 사항 없음 | 원격 노드 CIDR | Kubernetes API 서버에서 Kubelet으로 |
| HTTPS | TCP | 아웃바운드 | 웹후크 포트 | 해당 사항 없음 | 원격 포드 CIDR | Kubernetes API 서버에서 웹후크로(하이브리드 노드에서 웹후크를 실행하는 경우) |
**중요**
**보안 그룹 규칙 제한**: Amazon EC2 보안 그룹에는 기본적으로 최대 60개의 인바운드 규칙이 있습니다. 클러스터 보안 그룹이 이 제한에 근접하면 보안 그룹 인바운드 규칙이 적용되지 않을 수 있습니다. 이 경우 누락된 인바운드 규칙에 수동으로 추가해야 할 수 있습니다.
**CIDR 정리 책임**: EKS 클러스터에서 원격 노드 또는 포드 네트워크를 제거하는 경우 EKS는 해당 보안 그룹 규칙을 자동으로 제거하지 않습니다. 사용자가 직접 보안 그룹 규칙에서 사용하지 않은 원격 노드 또는 포드 네트워크를 수동으로 제거해야 합니다.
Amazon EKS에서 생성하는 클러스터 보안 그룹에 대한 자세한 내용을 알아보려면 [클러스터에 대한 Amazon EKS 보안 그룹 요구 사항 보기](sec-group-reqs.md) 부분을 참조하세요.
### (선택 사항) 수동 보안 그룹 구성
추가 보안 그룹을 생성하거나 자동으로 생성된 규칙을 수정해야 하는 경우 다음 명령을 참조로 사용할 수 있습니다. 기본적으로 아래 명령은 모든 아웃바운드 액세스를 허용하는 보안 그룹을 생성합니다. 위의 규칙만 포함하도록 아웃바운드 액세스를 제한할 수 있습니다. 아웃바운드 규칙을 제한하려는 경우 변경된 규칙을 프로덕션 클러스터에 적용하기 전에 모든 애플리케이션 및 포드 연결을 철저히 테스트하는 것이 좋습니다.
+ 첫 번째 명령에서 `SG_NAME`을 보안 그룹의 이름으로 변경
+ 첫 번째 명령에서 `VPC_ID`를 이전 단계에서 생성한 VPC의 ID로 변경
+ 두 번째 명령에서 `SG_ID`를 첫 번째 명령에서 생성한 보안 그룹의 ID로 변경
+ 두 번째 명령에서 `REMOTE_NODE_CIDR` 및 `REMOTE_POD_CIDR`을 하이브리드 노드 및 온프레미스 네트워크의 값으로 변경
```
aws ec2 create-security-group \
--group-name SG_NAME \
--description "security group for hybrid nodes" \
--vpc-id VPC_ID
```
```
aws ec2 authorize-security-group-ingress \
--group-id SG_ID \
--ip-permissions '[{"IpProtocol": "tcp", "FromPort": 443, "ToPort": 443, "IpRanges": [{"CidrIp": "REMOTE_NODE_CIDR"}, {"CidrIp": "REMOTE_POD_CIDR"}]}]'
```
# 하이브리드 노드용 운영 체제 준비
Bottlerocket, Amazon Linux 2023(AL2023), Ubuntu 및 RHEL은 하이브리드 노드의 노드 운영 체제로 사용하기 위해 지속적으로 검증됩니다. Bottlerocket은 VMware vSphere 환경에서만 AWS에서 지원됩니다. AL2023은 Amazon EC2 외부에서 실행되는 경우 AWS 지원 플랜의 적용을 받지 않습니다. AL2023은 온프레미스 가상화 환경에서만 사용할 수 있습니다. 자세한 내용은 [Amazon Linux 2023 사용 설명서](https://docs.aws.amazon.com/linux/al2023/ug/outside-ec2.html)를 참조하세요. AWS는 Ubuntu 및 RHEL 운영 체제와의 하이브리드 노드 통합을 지원하지만 운영 체제 자체에 대한 지원은 제공하지 않습니다.
운영 체제 프로비저닝 및 관리는 사용자의 책임입니다. 하이브리드 노드를 처음 테스트하는 경우 이미 프로비저닝된 호스트에서 Amazon EKS Hybrid Nodes CLI(`nodeadm`)를 실행하는 것이 가장 쉽습니다. 프로덕션 배포의 경우 호스트 시작 시 호스트를 Amazon EKS 클러스터에 자동으로 조인하기 위해 systemd 서비스로 실행되도록 구성된 `nodeadm`을 운영 체제 이미지에 포함하는 것이 좋습니다. Bottlerocket을 vSphere의 노드 운영 체제로 사용하는 경우 Bottlerocket은 하이브리드 노드에 필요한 종속성을 이미 포함하고 호스트 시작 시 구성한 클러스터에 자동으로 연결되므로 `nodeadm`을 사용할 필요가 없습니다.
## 버전 호환성
아래 표는 하이브리드 노드의 노드 운영 체제로 사용할 수 있도록 호환되고 검증된 운영 체제 버전을 나타냅니다. 이 표에 포함되지 않은 다른 운영 체제 변형 또는 버전을 사용하는 경우 하이브리드 노드와 운영 체제 변형 또는 버전의 호환성은 AWS 지원에 포함되지 않습니다. 하이브리드 노드는 기본 인프라에 구애받지 않으며 x86 및 ARM 아키텍처를 지원합니다.
| 운영 체제 | 버전 |
| --- | --- |
| Amazon Linux | Amazon Linux 2023(AL2023) |
| Bottlerocket | Kubernetes v1.28 이상을 실행하는 v1.37.0 이상의 VMware 변형 |
| Ubuntu | Ubuntu 20.04, Ubuntu 22.04, Ubuntu 24.04 |
| Red Hat Enterprise Linux | RHEL 8, RHEL 9 |
## 운영 체제 고려 사항
### 일반
+ Amazon EKS Hybrid Nodes CLI(`nodeadm`)를 사용하여 하이브리드 노드 구성 요소 및 종속성의 설치 및 구성을 간소화할 수 있습니다. 운영 체제 이미지 빌드 파이프라인 중에 또는 각 온프레미스 호스트의 런타임에 `nodeadm install` 프로세스를 실행할 수 있습니다. `nodeadm`이 설치하는 구성 요소에 대한 자세한 내용은 [하이브리드 노드 `nodeadm` 참조](hybrid-nodes-nodeadm.md) 섹션을 참조하세요.
+ 온프레미스 환경에서 프록시를 사용하여 인터넷에 연결하는 경우 설치 및 업그레이드 프로세스에서 프록시를 사용하도록 패키지 관리자를 구성하기 위해 추가 운영 체제 구성이 필요합니다. 자세한 내용은 [하이브리드 노드용 프록시 구성](hybrid-nodes-proxy.md) 섹션을 참조하세요.
### Bottlerocket
+ Bottlerocket 노드를 연결하는 단계 및 도구는 다른 운영 체제의 단계와 다르며 [하이브리드 노드 연결](hybrid-nodes-join.md)의 단계 대신 [Bottlerocket을 실행하는 하이브리드 노드 연결](hybrid-nodes-bottlerocket.md)에서 별도로 다룹니다.
+ Bottlerocket의 단계에서는 하이브리드 노드 CLI 도구인 `nodeadm`을 사용하지 않습니다.
+ Bottlerocket 버전 v1.37.0 이상의 VMware 변형만 EKS Hybrid Nodes에서 지원됩니다. Bottlerocket의 VMware 변형은 Kubernetes 버전 v1.28 이상에서 사용할 수 있습니다. [다른 Bottlerocket 변형](https://bottlerocket.dev/en/os/1.36.x/concepts/variants)은 하이브리드 노드 운영 체제로 지원되지 않습니다. 참고: Bottlerocket의 VMware 변형은 x86\$164 아키텍처에서만 사용할 수 있습니다.
### Containered
+ Containerd는 표준 Kubernetes 컨테이너 런타임이며 하이브리드 노드와 모든 Amazon EKS 노드 컴퓨팅 유형에 대한 종속성입니다. Amazon EKS Hybrid Nodes CLI(`nodeadm`)는 `nodeadm install` 프로세스 중에 Containered 설치를 시도합니다. `--containerd-source` 명령줄 옵션을 사용하여 `nodeadm install` 런타임에 Containered 설치를 구성할 수 있습니다. 유효한 옵션은 `none`, `distro`, `docker`입니다. RHEL을 사용하는 경우 `distro`는 유효한 옵션이 아니며 Docker의 리포지토리에서 Containered 빌드를 설치하도록 `nodeadm`을 구성하거나 Containered를 수동으로 설치할 수 있습니다. AL2023 또는 Ubuntu를 사용하는 경우는 `nodeadm`은 기본적으로 운영 체제 배포에서 Containered를 설치합니다. nodeadm이 Containered를 설치하지 않게 하려면 `--containerd-source none` 옵션을 사용합니다.
### Ubuntu
+ Ubuntu 24.04를 사용하는 경우 Containered 버전을 업데이트하거나 포드가 올바르게 종료되게 하는 수정 사항을 채택하도록 AppArmor 구성을 변경해야 할 수 있습니다. [Ubuntu \$12065423](https://bugs.launchpad.net/ubuntu/+source/containerd-app/\+bug/2065423)을 참조하세요. AppArmor 프로필에 변경 사항을 적용하려면 재부팅해야 합니다. 최신 버전의 Ubuntu 24.04에는 패키지 관리자에 수정 사항이 포함되어 업데이트된 Containered 버전이 있습니다(Containered 버전 1.7.19 이상).
### ARM
+ ARM 하드웨어를 사용하는 경우 EKS kube-proxy 추가 기능 버전 1.31 이상을 실행하려면 Cryptography Extension(ARMv8.2\$1crypto)이 포함된 ARMv8.2 호환 프로세서가 필요합니다. Raspberry Pi 5 이전의 모든 Raspberry Pi 시스템과 Cortex-A72 기반 프로세서는 이 요구 사항을 충족하지 않습니다. 해결 방법으로 2026년 7월에 확장 지원이 종료될 때까지 EKS kube-proxy 추가 기능 1.30 버전을 계속 사용하거나, [Kubernetes 릴리스 일정](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html)을 참조하거나, 업스트림의 사용자 지정 kube-proxy 이미지를 사용할 수 있습니다.
+ kube-proxy 로그의 다음 오류 메시지는 이 비호환성을 나타냅니다.
```
Fatal glibc error: This version of Amazon Linux requires a newer ARM64 processor compliant with at least ARM architecture 8.2-a with Cryptographic extensions. On EC2 this is Graviton 2 or later.
```
## 운영 체제 이미지 구축
Amazon EKS가 제공하는 [Packer 템플릿 예제](https://github.com/aws/eks-hybrid/tree/main/example/packer)를 사용하여 호스트 시작 시 실행되도록 구성하고 `nodeadm`을 포함하는 운영 체제 이미지를 생성할 수 있습니다. 이 프로세스는 각 호스트에서 하이브리드 노드 종속성을 개별적으로 가져오지 않도록 하고 하이브리드 노드 부트스트랩 프로세스를 자동화하기 위해 권장됩니다. Packer 템플릿 예제를 Ubuntu 22.04, Ubuntu 24.04, RHEL 8 또는 RHEL 9 ISO 이미지와 함께 사용하고 OVA, Qcow2 또는 원시 형식으로 이미지를 출력할 수 있습니다.
### 사전 조건
Packer 템플릿 예제를 사용하기 전에 Packer를 실행 중인 시스템에 다음이 설치되어 있어야 합니다.
+ Packer 버전 1.11.0 이상. Packer 설치에 대한 지침은 Packer 설명서에서 [Install Packer](https://developer.hashicorp.com/packer/tutorials/docker-get-started/get-started-install-cli)를 참조하세요.
+ OVA를 빌드하는 경우 VMware vSphere 플러그인 1.4.0 이상
+ `Qcow2`를 빌드하거나 원시 이미지인 경우 QEMU 플러그인 버전 1.x
### 환경 변수 설정
Packer 빌드를 실행하기 전에 Packer를 실행 중인 시스템에서 다음 환경 변수를 설정합니다.
**일반**
모든 운영 체제 및 출력 형식으로 이미지를 빌드하려면 다음 환경 변수를 설정해야 합니다.
| 환경 변수 | Type | 설명 |
| --- | --- | --- |
| PKR\$1SSH\$1PASSWORD | 문자열 | Packer는 `ssh_username` 및 `ssh_password` 변수를 사용하여 프로비저닝 시 생성된 시스템으로 SSH를 적용합니다. 이는 각 OS의 시작 또는 사용자 데이터 파일 내에서 초기 사용자를 생성하는 데 사용되는 암호와 일치해야 합니다. 기본값은 OS에 따라 '빌더' 또는 'ubuntu'로 설정됩니다. 암호를 설정할 때 일치하는 해당 `ks.cfg` 또는 `user-data` 파일 내에서 암호를 변경해야 합니다. |
| ISO\$1URL | 문자열 | 사용할 ISO의 URL입니다. 서버에서 다운로드할 웹 링크 또는 로컬 파일의 절대 경로일 수 있습니다. |
| ISO\$1CHECKSUM | 문자열 | 제공된 ISO에 대한 관련 체크섬입니다. |
| CREDENTIAL\$1PROVIDER | 문자열 | 하이브리드 노드의 자격 증명 공급자입니다. 유효한 값은 SSM 하이브리드 활성화의 경우 `ssm`(기본값), IAM Roles Anywhere의 경우 `iam`입니다. |
| K8S\$1VERSION | 문자열 | 하이브리드 노드용 Kubernetes 버전(예: `1.31`)입니다. 지원되는 Kubernetes 버전은 [Amazon EKS 지원 버전](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html)을 참조하세요. |
| NODEADM\$1ARCH | 문자열 | `nodeadm install`용 아키텍처입니다. `amd` 또는 `arm`을 선택합니다. |
**RHEL**
RHEL을 사용하는 경우 다음 환경 변수를 설정해야 합니다.
| 환경 변수 | Type | 설명 |
| --- | --- | --- |
| RH\$1USERNAME | 문자열 | RHEL 구독 관리자 사용자 이름 |
| RH\$1PASSWORD | 문자열 | RHEL 구독 관리자 암호 |
| RHEL\$1VERSION | 문자열 | 사용 중인 Rhel iso 버전입니다. 유효한 값은 `8` 또는 `9`입니다. |
**Ubuntu**
Ubuntu별 환경 변수는 필요하지 않습니다.
**vSphere**
VMware vSphere OVA를 빌드하는 경우 다음 환경 변수를 설정해야 합니다.
| 환경 변수 | Type | 설명 |
| --- | --- | --- |
| VSPHERE\$1SERVER | 문자열 | vSphere 서버 주소 |
| VSPHERE\$1USER | 문자열 | vSphere 사용자 이름 |
| VSPHERE\$1PASSWORD | 문자열 | vSphere 암호 |
| VSPHERE\$1DATACENTER | 문자열 | vSphere 데이터 센터 이름 |
| VSPHERE\$1CLUSTER | 문자열 | vSphere 클러스터 이름 |
| VSPHERE\$1DATASTORE | 문자열 | vSphere 데이터 저장소 이름 |
| VSPHERE\$1NETWORK | 문자열 | vSphere 네트워크 이름 |
| VSPHERE\$1OUTPUT\$1FOLDER | 문자열 | 템플릿의 vSphere 출력 폴더 |
**QEMU**
| 환경 변수 | Type | 설명 |
| --- | --- | --- |
| PACKER\$1OUTPUT\$1FORMAT | 문자열 | QEMU 빌더의 출력 형식입니다. 유효 값은 `qcow2` 및 `raw`입니다. |
**템플릿 확인**
빌드를 실행하기 전에 환경 변수를 설정한 후 다음 명령을 사용하여 템플릿을 확인합니다. 템플릿에 다른 이름을 사용하는 경우 `template.pkr.hcl`을 바꿉니다.
```
packer validate template.pkr.hcl
```
### 이미지 빌드
다음 명령을 사용하여 이미지를 빌드하고 `-only` 플래그를 사용하여 이미지의 대상 및 운영 체제를 지정합니다. 템플릿에 다른 이름을 사용하는 경우 `template.pkr.hcl`을 바꿉니다.
**vSphere OVA**
**참고**
vSphere와 함께 RHEL을 사용하는 경우 시작 파일을 OEMDRV 이미지로 변환하고 부팅할 ISO로 전달해야 합니다. 자세한 내용은 EKS 하이브리드 노드 GitHub 리포지토리의 [Packer Readme](https://github.com/aws/eks-hybrid/tree/main/example/packer#utilizing-rhel-with-vsphere)를 참조하세요.
**Ubuntu 22.04 OVA**
```
packer build -only=general-build.vsphere-iso.ubuntu22 template.pkr.hcl
```
**Ubuntu 24.04 OVA**
```
packer build -only=general-build.vsphere-iso.ubuntu24 template.pkr.hcl
```
**RHEL 8 OVA**
```
packer build -only=general-build.vsphere-iso.rhel8 template.pkr.hcl
```
**RHEL 9 OVA**
```
packer build -only=general-build.vsphere-iso.rhel9 template.pkr.hcl
```
**QEMU**
**참고**
빌더 호스트와 일치하지 않는 특정 호스트 CPU의 이미지를 빌드하는 경우 호스트 CPU와 일치하는 이름에 대한 [QEMU](https://www.qemu.org/docs/master/system/qemu-cpu-models.html) 설명서를 참조하고 다음 명령을 실행할 때 `-cpu` 플래그를 호스트 CPU 이름과 함께 사용합니다.
**Ubuntu 22.04 Qcow2 / 원시**
```
packer build -only=general-build.qemu.ubuntu22 template.pkr.hcl
```
**Ubuntu 24.04 Qcow2 / 원시**
```
packer build -only=general-build.qemu.ubuntu24 template.pkr.hcl
```
**RHEL 8 Qcow2 / 원시**
```
packer build -only=general-build.qemu.rhel8 template.pkr.hcl
```
**RHEL 9 Qcow2 / 원시**
```
packer build -only=general-build.qemu.rhel9 template.pkr.hcl
```
### 사용자 데이터를 통해 nodeadm 구성 전달
Cloud-init을 통해 사용자 데이터에서 `nodeadm`에 대한 구성을 전달하여 호스트 시작 시 하이브리드 노드를 구성하고 EKS 클러스터에 자동으로 연결할 수 있습니다. 다음은 VMware vSphere를 하이브리드 노드의 인프라로 사용할 때 이를 수행하는 방법의 예입니다.
1. GitHub의 [govc readme](https://github.com/vmware/govmomi/blob/main/govc/README.md) 지침에 따라 `govc` CLI를 설치합니다.
1. 이전 섹션에서 Packer 빌드를 실행하고 템플릿을 프로비저닝한 후 다음을 사용하여 템플릿을 복제하고 여러 노드를 생성할 수 있습니다. 하이브리드 노드에 사용하기 위해 생성하는 새 VM마다 템플릿을 복제해야 합니다. 아래 명령에서 다음 변수를 해당 환경의 값으로 바꿉니다. 아래 명령의 `VM_NAME`은 `metadata.yaml` 파일을 통해 VM의 이름을 주입할 때 `NODE_NAME`으로 사용됩니다.
```
govc vm.clone -vm "/PATH/TO/TEMPLATE" -ds="YOUR_DATASTORE" \
-on=false -template=false -folder=/FOLDER/TO/SAVE/VM "VM_NAME"
```
1. 새로운 각 VM에 대한 템플릿을 복제한 후 VM에 대한 `userdata.yaml` 및 `metadata.yaml`을 생성합니다. VM은 동일한 `userdata.yaml` 및 `metadata.yaml`을 공유할 수 있으며 아래 단계에서 VM별로 이를 채웁니다. `nodeadm` 구성은 `userdata.yaml`의 `write_files` 섹션에서 생성 및 정의됩니다. 아래 예제에서는 AWS SSM 하이브리드 활성화를 하이브리드 노드의 온프레미스 자격 증명 공급자로 사용합니다. `nodeadm` 구성에 대한 자세한 내용은 [하이브리드 노드 `nodeadm` 참조](hybrid-nodes-nodeadm.md) 섹션을 참조하세요.
**userdata.yaml:**
```
#cloud-config
users:
- name: # username for login. Use 'builder' for RHEL or 'ubuntu' for Ubuntu.
passwd: # password to login. Default is 'builder' for RHEL.
groups: [adm, cdrom, dip, plugdev, lxd, sudo]
lock-passwd: false
sudo: ALL=(ALL) NOPASSWD:ALL
shell: /bin/bash
write_files:
- path: /usr/local/bin/nodeConfig.yaml
permissions: '0644'
content: |
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
cluster:
name: # Cluster Name
region: # AWS region
hybrid:
ssm:
activationCode: # Your ssm activation code
activationId: # Your ssm activation id
runcmd:
- /usr/local/bin/nodeadm init -c file:///usr/local/bin/nodeConfig.yaml >> /var/log/nodeadm-init.log 2>&1
```
**metadata.yaml:**
환경에 대한 `metadata.yaml`을 생성합니다. `"$NODE_NAME"` 변수 형식은 후속 단계의 값으로 채워지므로 파일에 그대로 둡니다.
```
instance-id: "$NODE_NAME"
local-hostname: "$NODE_NAME"
network:
version: 2
ethernets:
nics:
match:
name: ens*
dhcp4: yes
```
1. 다음 명령을 사용하여 `userdata.yaml` 및 `metadata.yaml` 파일을 `gzip+base64` 문자열로 추가합니다. 생성하는 각 VM에 대해 다음 명령을 실행해야 합니다. `VM_NAME`을 업데이트 중인 VM의 이름으로 바꿉니다.
```
export NODE_NAME="VM_NAME"
export USER_DATA=$(gzip -c9 metadata.yaml.tmp
export METADATA=$(gzip -c9
Amazon EKS Hybrid Nodes는 AWS SSM 하이브리드 활성화 또는 AWS IAM Roles Anywhere에서 프로비저닝한 임시 IAM 자격 증명을 사용하여 Amazon EKS 클러스터로 인증합니다. Amazon EKS Hybrid Nodes CLI(`nodeadm`)와 함께 AWS SSM 하이브리드 활성화 또는 AWS IAM Roles Anywhere를 사용해야 합니다. AWS SSM 하이브리드 활성화와 AWS IAM Roles Anywhere를 둘 다 사용해서는 안 됩니다. 인증 기관(CA)이 있는 기존 퍼블릭 키 인프라(PKI)와 온프레미스 환경에 대한 인증서가 없는 경우 AWS SSM 하이브리드 활성화를 사용하는 것이 좋습니다. 온프레미스에 기존 PKI 및 인증서가 있는 경우 AWS IAM Roles Anywhere를 사용합니다.
## 하이브리드 노드 IAM 역할
하이브리드 노드를 Amazon EKS 클러스터에 연결하려면 먼저 하이브리드 노드 자격 증명에 대해 AWS SSM 하이브리드 활성화 또는 AWS IAM Roles Anywhere와 함께 사용할 IAM 역할을 생성해야 합니다. 클러스터를 생성한 후 이 역할을 Amazon EKS 액세스 항목 또는 `aws-auth` ConfigMap 항목과 함께 사용하여 IAM 역할을 Kubernetes 역할 기반 액세스 제어(RBAC)에 매핑합니다. 하이브리드 노드 IAM 역할을 Kubernetes RBAC와 연결하는 방법에 대한 자세한 내용은 [하이브리드 노드에 대한 클러스터 액세스 준비](hybrid-nodes-cluster-prep.md) 섹션을 참조하세요.
하이브리드 노드 IAM 역할에는 다음과 같은 권한이 있어야 합니다.
+ `nodeadm`이 `eks:DescribeCluster` 작업을 사용하여 하이브리드 노드를 연결할 클러스터에 대한 정보를 수집하는 권한. `eks:DescribeCluster` 작업을 활성화하지 않으면 `nodeadm init` 명령에 전달하는 노드 구성에서 Kubernetes API 엔드포인트, 클러스터 CA 번들, 서비스 IPv4 CIDR을 전달해야 합니다.
+ `nodeadm`이 `eks:ListAccessEntries` 작업을 사용하여 하이브리드 노드를 연결할 클러스터에서 액세스 항목을 나열하는 권한. `eks:ListAccessEntries` 작업을 활성화하지 않으면 `nodeadm init` 명령을 실행할 때 `--skip cluster-access-validation` 플래그를 전달해야 합니다.
+ [AmazonEC2ContainerRegistryPullOnly](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEC2ContainerRegistryPullOnly.html) 정책의 정의에 따라 kubelet이 Amazon Elastic Container Registry(Amazon ECR)의 컨테이너 이미지를 사용할 수 있는 권한입니다.
+ AWS SSM을 사용하는 경우 [https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonSSMManagedInstanceCore.html](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonSSMManagedInstanceCore.html) 정책에 정의된 대로 `nodeadm init`에서 AWS SSM 하이브리드 활성화를 사용할 수 있는 권한.
+ AWS SSM을 사용하는 경우 `nodeadm uninstall`에서 인스턴스 등록을 취소하기 위해 `ssm:DeregisterManagedInstance` 작업과 `ssm:DescribeInstanceInformation` 작업을 사용할 수 있는 권한입니다.
+ (선택사항) Amazon EKS Pod Identity 에이전트에서 `eks-auth:AssumeRoleForPodIdentity` 작업을 사용하여 포드에 대한 보안 인증 정보를 검색할 수 있는 권한.
## AWS SSM 하이브리드 활성화 설정
AWS SSM 하이브리드 활성화를 설정하기 전에 하이브리드 노드 IAM 역할을 생성하고 구성해야 합니다. 자세한 내용은 [하이브리드 노드 IAM 역할 생성](#hybrid-nodes-create-role) 섹션을 참조하세요. AWS Systems Manager 사용 설명서의 [하이브리드 활성화를 생성하여 Systems Manager에 노드 등록](https://docs.aws.amazon.com/systems-manager/latest/userguide/hybrid-activation-managed-nodes.html) 지침에 따라 하이브리드 노드에 대한 AWS SSM 하이브리드 활성화를 생성합니다. 수신한 활성화 코드와 ID는 호스트를 Amazon EKS 클러스터에 하이브리드 노드로 등록할 때 `nodeadm`과 함께 사용됩니다. 하이브리드 노드용 Amazon EKS 클러스터를 생성하고 준비한 후 나중에 이 단계로 돌아갈 수 있습니다.
**중요**
활성화를 생성한 방법에 따라, Systems Manager는 활성화 코드 및 ID를 콘솔이나 명령 창에 즉시 반환합니다. 이 정보를 복사하여 안전한 장소에 보관하십시오. 콘솔에서 벗어나거나 명령 창을 닫으면 이 정보가 손실될 수 있습니다. 이 정보가 손실하면 새로운 정품 인증을 생성해야 합니다.
기본적으로 AWS SSM 하이브리드 활성화는 24시간 동안 활성화됩니다. 또는 `2024-08-01T00:00:00`과 같은 타임스탬프 형식으로 하이브리드 활성화를 생성할 때 `--expiration-date`를 지정할 수 있습니다. AWS SSM을 자격 증명 공급자로 사용하는 경우 하이브리드 노드의 노드 이름은 구성할 수 없으며 AWS SSM에서 자동으로 생성됩니다. AWS Systems Manager 콘솔의 Fleet Manager에서 AWS SSM 관리형 인스턴스를 보고 관리할 수 있습니다. 추가 비용 없이 AWS 리전별로 계정당 최대 1,000개의 표준 [하이브리드 활성화 노드](https://docs.aws.amazon.com/systems-manager/latest/userguide/activations.html)를 등록할 수 있습니다. 그러나 1,000개 이상의 하이브리드 노드를 등록하려면 고급 인스턴스 티어를 활성화해야 합니다. [Amazon EKS Hybrid Nodes 요금](https://aws.amazon.com/eks/pricing/)에 포함되지 않은 고급 인스턴스 티어를 사용하는 경우 요금이 부과됩니다. 자세한 내용은 [AWS Systems Manager 요금](https://aws.amazon.com/systems-manager/pricing/)을 참조하세요.
하이브리드 노드 IAM 역할을 사용하여 AWS SSM 하이브리드 활성화를 생성하는 방법은 아래 예제를 참조하세요. 하이브리드 노드 자격 증명에 AWS SSM 하이브리드 활성화를 사용하는 경우 하이브리드 노드의 이름은 `mi-012345678abcdefgh` 형식을 가지며 AWS SSM에서 프로비저닝한 임시 자격 증명은 1시간 동안 유효합니다. AWS SSM을 자격 증명 공급자로 사용하는 경우 노드 이름 또는 자격 증명 기간을 변경할 수 없습니다. 임시 자격 증명은 AWS SSM에 의해 자동으로 교체되며 교체는 노드 또는 애플리케이션의 상태에 영향을 주지 않습니다.
EKS 클러스터당 하나의 AWS SSM 하이브리드 활성화를 사용하여 AWS SSM 하이브리드 활성화와 연결된 인스턴스만 등록 취소할 수 있도록 하이브리드 노드 IAM 역할의 AWS SSM `ssm:DeregisterManagedInstance` 권한 범위를 조정하는 것이 좋습니다. 이 페이지의 예제에서는 EKS 클러스터 ARN이 있는 태그가 사용되며, 이 태그를 사용하여 AWS SSM 하이브리드 활성화를 EKS 클러스터에 매핑할 수 있습니다. 또는 권한 경계 및 요구 사항에 따라 AWS SSM 권한을 조정하는 기본 태그와 방법을 사용할 수 있습니다. 아래 명령의 `REGISTRATION_LIMIT` 옵션은 AWS SSM 하이브리드 활성화를 사용할 수 있는 시스템 수를 제한하는 데 사용되는 정수입니다(예: `10`).
```
aws ssm create-activation \
--region AWS_REGION \
--default-instance-name eks-hybrid-nodes \
--description "Activation for EKS hybrid nodes" \
--iam-role AmazonEKSHybridNodesRole \
--tags Key=EKSClusterARN,Value=arn:aws:eks:AWS_REGION:AWS_ACCOUNT_ID:cluster/CLUSTER_NAME \
--registration-limit REGISTRATION_LIMIT
```
AWS SSM 하이브리드 활성화에 사용할 수 있는 구성 설정에 대한 자세한 내용은 [하이브리드 활성화를 생성하여 Systems Manager에 노드 등록](https://docs.aws.amazon.com/systems-manager/latest/userguide/hybrid-activation-managed-nodes.html)의 지침을 검토하세요.
## AWS IAM Roles Anywhere 설정
IAM Roles Anywhere 사용 설명서의 [IAM Roles Anywhere 시작하기](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/getting-started.html)의 지침에 따라 하이브리드 노드 IAM 역할에 대한 임시 IAM 자격 증명에 사용할 트러스트 앵커 및 프로필을 설정합니다. 프로필을 생성할 때 역할을 추가하지 않고도 프로필을 생성할 수 있습니다. 이 프로필을 생성하고, 다음 단계로 돌아가서 하이브리드 노드 IAM 역할을 생성한 다음 생성한 후 프로필에 역할을 추가할 수 있습니다. 또는 이 페이지의 뒷부분에 있는 AWS CloudFormation 단계를 사용하여 하이브리드 노드에 대한 IAM Roles Anywhere 설정을 완료할 수 있습니다.
하이브리드 노드 IAM 역할을 프로필에 추가할 때 AWS IAM Roles Anywhere 콘솔의 **프로필 편집** 페이지 하단의 **사용자 지정 역할** 세션 이름 패널에서** 사용자 지정 역할 세션 이름 수락**을 선택합니다. 이는 `CreateProfile` API의 [acceptRoleSessionName](https://docs.aws.amazon.com/rolesanywhere/latest/APIReference/API_CreateProfile.html#rolesanywhere-CreateProfile-request-acceptRoleSessionName) 필드에 해당합니다. 이렇게 하면 부트스트랩 프로세스 중에 `nodeadm`으로 전달하는 구성에서 하이브리드 노드의 사용자 지정 노드 이름을 제공할 수 있습니다. `nodeadm init` 프로세스 중에 사용자 지정 노드 이름을 전달해야 합니다. 프로필을 생성한 후 사용자 지정 역할 세션 이름을 수락하도록 프로필을 업데이트할 수 있습니다.
AWS IAM Roles Anywhere 프로필의 [durationSeconds](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/authentication-create-session#credentials-object) 필드를 통해 AWS IAM Roles Anywhere로 자격 증명 유효 기간을 구성할 수 있습니다. 기본 지속 시간은 1시간이고 최대 12시간입니다. 하이브리드 노드 IAM 역할의 `MaxSessionDuration` 설정은 AWS IAM Roles Anywhere 프로필의 `durationSeconds` 설정보다 커야 합니다. `MaxSessionDuration`에 대한 자세한 내용은 [UpdateRole API documentation](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_UpdateRole.html)를 참조하세요.
인증 기관(CA)에서 생성하는 시스템별 인증서와 키는 각 하이브리드 노드의 `/etc/iam/pki` 디렉터리에 배치하고 인증서는 `server.pem`, 키는 `server.key`의 파일 이름으로 저장해야 합니다.
## 하이브리드 노드 IAM 역할 생성
이 섹션의 단계를 실행하려면 AWS 콘솔 또는 AWS CLI를 사용하는 IAM 보안 주체에 다음 권한이 있어야 합니다.
+ `iam:CreatePolicy`
+ `iam:CreateRole`
+ `iam:AttachRolePolicy`
+ AWS IAM Roles Anywhere를 사용하는 경우
+ `rolesanywhere:CreateTrustAnchor`
+ `rolesanywhere:CreateProfile`
+ `iam:PassRole`
### AWS CloudFormation
아직 하지 않은 경우 AWS CLI를 설치하고 구성합니다. [최신 버전의 AWS CLI 설치 또는 업데이트](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)를 참조하세요.
**AWS SSM 하이브리드 활성화 단계**
CloudFormation 스택은 위에 설명된 권한을 사용하여 하이브리드 노드 IAM 역할을 생성합니다. CloudFormation 템플릿은 AWS SSM 하이브리드 활성화를 생성하지 않습니다.
1. 하이브리드 노드용 AWS SSM CloudFormation 템플릿을 다운로드합니다.
```
curl -OL 'https://raw.githubusercontent.com/aws/eks-hybrid/refs/heads/main/example/hybrid-ssm-cfn.yaml'
```
1. 다음과 같은 옵션으로 `cfn-ssm-parameters.json`을 생성합니다.
1. `ROLE_NAME`을 하이브리드 노드 IAM 역할의 이름으로 바꿉니다. 기본적으로 이름을 지정하지 않으면 CloudFormation 템플릿은 `AmazonEKSHybridNodesRole`을 생성하는 역할의 이름으로 사용합니다.
1. `TAG_KEY`을 AWSSSM 하이브리드 활성화를 생성할 때 사용한 AWS SSM 리소스 태그 키로 바꿉니다. 태그 키와 태그 값의 조합은 하이브리드 노드 IAM 역할이 AWS SSM 하이브리드 활성화와 연결된 AWS SSM 관리형 인스턴스의 등록을 취소할 수 있도록 허용하는 `ssm:DeregisterManagedInstance`의 조건에서 사용됩니다. CloudFormation 템플릿에서 `TAG_KEY`의 기본값은 `EKSClusterARN`입니다.
1. `TAG_VALUE`를 AWS SSM 하이브리드 활성화를 생성할 때 사용한 AWS SSM 리소스 태그 값으로 바꿉니다. 태그 키와 태그 값의 조합은 하이브리드 노드 IAM 역할이 AWS SSM 하이브리드 활성화와 연결된 AWS SSM 관리형 인스턴스의 등록을 취소할 수 있도록 허용하는 `ssm:DeregisterManagedInstance`의 조건에서 사용됩니다. `TAG_KEY`의 기본값인 `EKSClusterARN`을 사용하는 경우 EKS 클러스터 ARN을 `TAG_VALUE`로 전달합니다. EKS 클러스터 ARN의 형식은 ` arn:aws:eks:AWS_REGION:AWS_ACCOUNT_ID:cluster/CLUSTER_NAME`입니다.
```
{
"Parameters": {
"RoleName": "ROLE_NAME",
"SSMDeregisterConditionTagKey": "TAG_KEY",
"SSMDeregisterConditionTagValue": "TAG_VALUE"
}
}
```
1. CloudFormation 스택 배포 `STACK_NAME`을 CloudFormation 스택의 이름으로 바꿉니다.
```
aws cloudformation deploy \
--stack-name STACK_NAME \
--template-file hybrid-ssm-cfn.yaml \
--parameter-overrides file://cfn-ssm-parameters.json \
--capabilities CAPABILITY_NAMED_IAM
```
**AWS IAM Roles Anywhere의 단계**
CloudFormation 스택은 사용자가 구성한 인증 기관(CA)을 사용하여 AWS IAM Roles Anywhere 트러스트 앵커를 생성하고, AWS IAM Roles Anywhere 프로필을 생성하고, 앞서 설명한 권한을 사용하여 하이브리드 노드 IAM 역할을 생성합니다.
1. 인증 기관(CA)을 설정하려면
1. AWS 프라이빗 CA 리소스를 사용하려면 [AWS 프라이빗 인증 기관 콘솔](https://console.aws.amazon.com/acm-pca/home)을 엽니다. [AWS 프라이빗 CA 사용 설명서](https://docs.aws.amazon.com/privateca/latest/userguide/PcaWelcome.html)의 지침을 따릅니다.
1. 외부 CA를 사용하려면 CA에서 제공하는 지침을 따릅니다. 이후 단계에서 인증서 본문을 제공합니다.
1. 퍼블릭 CA에서 발급된 인증서는 트러스트 앵커로 사용할 수 없습니다.
1. 하이브리드 노드용 AWS IAM Roles Anywhere CloudFormation 템플릿을 다운로드합니다.
```
curl -OL 'https://raw.githubusercontent.com/aws/eks-hybrid/refs/heads/main/example/hybrid-ira-cfn.yaml'
```
1. 다음과 같은 옵션으로 `cfn-iamra-parameters.json`을 생성합니다.
1. `ROLE_NAME`을 하이브리드 노드 IAM 역할의 이름으로 바꿉니다. 기본적으로 이름을 지정하지 않으면 CloudFormation 템플릿은 `AmazonEKSHybridNodesRole`을 생성하는 역할의 이름으로 사용합니다.
1. `CERT_ATTRIBUTE`를 호스트를 고유하게 식별하는 시스템당 인증서 속성으로 바꿉니다. 사용하는 인증서 속성은 클러스터에 하이브리드 노드를 연결할 때 `nodeadm` 구성에 사용하는 nodeName과 일치해야 합니다. 자세한 내용은 [하이브리드 노드 `nodeadm` 참조](hybrid-nodes-nodeadm.md)을 참조하세요. 기본적으로 CloudFormation 템플릿은 `${aws:PrincipalTag/x509Subject/CN}`을 `CERT_ATTRIBUTE`로 사용하며, 이는 시스템별 인증서의 CN 필드에 해당합니다. 또는 `$(aws:PrincipalTag/x509SAN/Name/CN}`을 `CERT_ATTRIBUTE`로 전달할 수 있습니다.
1. `CA_CERT_BODY`를 줄 바꿈 없이 CA의 인증서 본문으로 바꿉니다. `CA_CERT_BODY`는 PEM(Privacy Enhanced Mail) 형식이어야 합니다. PEM 형식의 CA 인증서가 있는 경우 CA 인증서 본문을 `cfn-iamra-parameters.json` 파일에 배치하기 전에 줄 바꿈과 BEGIN CERTIFICATE 및 END CERTIFICATE 줄을 제거합니다.
```
{
"Parameters": {
"RoleName": "ROLE_NAME",
"CertAttributeTrustPolicy": "CERT_ATTRIBUTE",
"CABundleCert": "CA_CERT_BODY"
}
}
```
1. CloudFormation 템플릿을 배포합니다. `STACK_NAME`을 CloudFormation 스택의 이름으로 바꿉니다.
```
aws cloudformation deploy \
--stack-name STACK_NAME \
--template-file hybrid-ira-cfn.yaml \
--parameter-overrides file://cfn-iamra-parameters.json
--capabilities CAPABILITY_NAMED_IAM
```
### AWS CLI
아직 하지 않은 경우 AWS CLI를 설치하고 구성합니다. [최신 버전의 AWS CLI 설치 또는 업데이트](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)를 참조하세요.
**EKS 설명 클러스터 정책 생성**
1. 다음 콘텐츠를 가진 `eks-describe-cluster-policy.json`이라는 파일을 생성합니다:
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"eks:DescribeCluster"
],
"Resource": "*"
}
]
}
```
1. 다음 명령을 사용하여 정책을 생성합니다.
```
aws iam create-policy \
--policy-name EKSDescribeClusterPolicy \
--policy-document file://eks-describe-cluster-policy.json
```
**AWS SSM 하이브리드 활성화 단계**
1. 다음 콘텐츠를 가진 `eks-hybrid-ssm-policy.json`이라는 파일을 생성합니다: 이 정책은 `ssm:DescribeInstanceInformation` 및 `ssm:DeregisterManagedInstance` 두 작업에 대한 권한을 부여합니다. 이 정책은 신뢰 정책에 지정한 리소스 태그를 기반으로 AWS SSM 하이브리드 활성화와 연결된 AWS SSM 관리형 인스턴스에 대한 `ssm:DeregisterManagedInstance` 권한을 제한합니다.
1. `AWS_REGION`을 AWS SSM 하이브리드 활성화를 위한 AWS 리전으로 바꿉니다.
1. `AWS_ACCOUNT_ID`를 AWS 계정 ID로 바꿉니다.
1. `TAG_KEY`을 AWSSSM 하이브리드 활성화를 생성할 때 사용한 AWS SSM 리소스 태그 키로 바꿉니다. 태그 키와 태그 값의 조합은 하이브리드 노드 IAM 역할이 AWS SSM 하이브리드 활성화와 연결된 AWS SSM 관리형 인스턴스의 등록을 취소할 수 있도록 허용하는 `ssm:DeregisterManagedInstance`의 조건에서 사용됩니다. CloudFormation 템플릿에서 `TAG_KEY`의 기본값은 `EKSClusterARN`입니다.
1. `TAG_VALUE`를 AWS SSM 하이브리드 활성화를 생성할 때 사용한 AWS SSM 리소스 태그 값으로 바꿉니다. 태그 키와 태그 값의 조합은 하이브리드 노드 IAM 역할이 AWS SSM 하이브리드 활성화와 연결된 AWS SSM 관리형 인스턴스의 등록을 취소할 수 있도록 허용하는 `ssm:DeregisterManagedInstance`의 조건에서 사용됩니다. `TAG_KEY`의 기본값인 `EKSClusterARN`을 사용하는 경우 EKS 클러스터 ARN을 `TAG_VALUE`로 전달합니다. EKS 클러스터 ARN의 형식은 ` arn:aws:eks:AWS_REGION:AWS_ACCOUNT_ID:cluster/CLUSTER_NAME`입니다.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "ssm:DescribeInstanceInformation",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "ssm:DeregisterManagedInstance",
"Resource": "arn:aws:ssm:us-east-1:123456789012:managed-instance/*",
"Condition": {
"StringEquals": {
"ssm:resourceTag/TAG_KEY": "TAG_VALUE"
}
}
}
]
}
```
1. 다음 명령을 사용하여 정책을 생성합니다.
```
aws iam create-policy \
--policy-name EKSHybridSSMPolicy \
--policy-document file://eks-hybrid-ssm-policy.json
```
1. `eks-hybrid-ssm-trust.json`이라는 이름의 파일을 만듭니다. `AWS_REGION`을 AWS SSM 하이브리드 활성화의 AWS 리전으로 바꾸고 `AWS_ACCOUNT_ID`를 AWS 계정 ID로 바꿉니다.
```
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"",
"Effect":"Allow",
"Principal":{
"Service":"ssm.amazonaws.com"
},
"Action":"sts:AssumeRole",
"Condition":{
"StringEquals":{
"aws:SourceAccount":"123456789012"
},
"ArnEquals":{
"aws:SourceArn":"arn:aws:ssm:us-east-1:123456789012:*"
}
}
}
]
}
```
1. 다음 명령을 사용하여 역할을 생성합니다.
```
aws iam create-role \
--role-name AmazonEKSHybridNodesRole \
--assume-role-policy-document file://eks-hybrid-ssm-trust.json
```
1. 이전 단계에서 생성한 `EKSDescribeClusterPolicy`와 `EKSHybridSSMPolicy`를 연결합니다. `AWS_ACCOUNT_ID`를 AWS 계정 ID로 바꿉니다.
```
aws iam attach-role-policy \
--role-name AmazonEKSHybridNodesRole \
--policy-arn arn:aws:iam::AWS_ACCOUNT_ID:policy/EKSDescribeClusterPolicy
```
```
aws iam attach-role-policy \
--role-name AmazonEKSHybridNodesRole \
--policy-arn arn:aws:iam::AWS_ACCOUNT_ID:policy/EKSHybridSSMPolicy
```
1. `AmazonEC2ContainerRegistryPullOnly` 및 `AmazonSSMManagedInstanceCore` AWS 관리형 정책을 연결합니다.
```
aws iam attach-role-policy \
--role-name AmazonEKSHybridNodesRole \
--policy-arn arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryPullOnly
```
```
aws iam attach-role-policy \
--role-name AmazonEKSHybridNodesRole \
--policy-arn arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore
```
**AWS IAM Roles Anywhere의 단계**
AWS IAM Roles Anywhere를 사용하려면 하이브리드 노드 IAM 역할을 생성하기 전에 AWS IAM Roles Anywhere 트러스트 앵커를 설정해야 합니다. 자세한 내용은 [AWS IAM Roles Anywhere 설정](#hybrid-nodes-iam-roles-anywhere) 섹션을 참조하세요.
1. `eks-hybrid-iamra-trust.json`이라는 이름의 파일을 만듭니다. `TRUST_ANCHOR ARN`을 [AWS IAM Roles Anywhere 설정](#hybrid-nodes-iam-roles-anywhere) 단계에서 생성한 트러스트 앵커의 ARN으로 바꿉니다. 이 신뢰 정책의 조건은 역할 세션 이름이 하이브리드 노드에 설치된 x509 인증서의 CN과 일치하는 경우에만 AWS IAM Roles Anywhere가 하이브리드 노드 IAM 역할을 수임하여 임시 IAM 자격 증명을 교환하는 기능을 제한합니다. 또는 다른 인증서 속성을 사용하여 노드를 고유하게 식별할 수 있습니다. 신뢰 정책에서 사용하는 인증서 속성은 `nodeadm` 구성에서 설정한 `nodeName`과 일치해야 합니다. 자세한 내용은 [하이브리드 노드 `nodeadm` 참조](hybrid-nodes-nodeadm.md)을 참조하세요.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "rolesanywhere.amazonaws.com"
},
"Action": [
"sts:TagSession",
"sts:SetSourceIdentity"
],
"Condition": {
"StringEquals": {
"aws:PrincipalTag/x509Subject/CN": "${aws:PrincipalTag/x509Subject/CN}"
},
"ArnEquals": {
"aws:SourceArn": "arn:aws:rolesanywhere:us-east-1:123456789012:trust-anchor/TA_ID"
}
}
},
{
"Effect": "Allow",
"Principal": {
"Service": "rolesanywhere.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"sts:RoleSessionName": "${aws:PrincipalTag/x509Subject/CN}",
"aws:PrincipalTag/x509Subject/CN": "${aws:PrincipalTag/x509Subject/CN}"
},
"ArnEquals": {
"aws:SourceArn": "arn:aws:rolesanywhere:us-east-1:123456789012:trust-anchor/TA_ID"
}
}
}
]
}
```
1. 다음 명령을 사용하여 역할을 생성합니다.
```
aws iam create-role \
--role-name AmazonEKSHybridNodesRole \
--assume-role-policy-document file://eks-hybrid-iamra-trust.json
```
1. 이전 단계에서 생성한 `EKSDescribeClusterPolicy`를 연결합니다. `AWS_ACCOUNT_ID`를 AWS 계정 ID로 바꿉니다.
```
aws iam attach-role-policy \
--role-name AmazonEKSHybridNodesRole \
--policy-arn arn:aws:iam::AWS_ACCOUNT_ID:policy/EKSDescribeClusterPolicy
```
1. `AmazonEC2ContainerRegistryPullOnly` AWS 관리형 정책을 연결합니다.
```
aws iam attach-role-policy \
--role-name AmazonEKSHybridNodesRole \
--policy-arn arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryPullOnly
```
### AWS Management Console
**EKS 설명 클러스터 정책 생성**
1. [Amazon IAM 콘솔](https://console.aws.amazon.com/iam/home)을 엽니다.
1. 왼쪽 탐색 창에서 **정책**을 선택합니다.
1. **정책** 페이지에서 **정책 생성**을 선택합니다.
1. 권한 지정 페이지의 서비스 선택 패널에서 EKS를 선택합니다.
1. **DescribeCluster**에 대한 작업을 필터링하고 **DescribeCluster** 읽기 작업을 선택합니다.
1. **다음**을 선택합니다.
1. **검토 및 생성** 페이지에서
1. 정책에 **정책 이름**(예: `EKSDescribeClusterPolicy`)을 입력합니다.
1. **정책 생성**을 선택합니다.
**AWS SSM 하이브리드 활성화 단계**
1. [Amazon IAM 콘솔](https://console.aws.amazon.com/iam/home)을 엽니다.
1. 왼쪽 탐색 창에서 **정책**을 선택합니다.
1. **정책** 페이지에서 **정책 생성**을 선택합니다.
1. **권한 지정** 페이지의 **정책 편집기** 오른쪽 상단에서 **JSON**을 선택합니다. 다음 조각을 붙여 넣습니다. `AWS_REGION`을 AWS SSM 하이브리드 활성화의 AWS 리전으로 바꾸고 `AWS_ACCOUNT_ID`를 AWS 계정 ID로 바꿉니다. `TAG_KEY` 및 `TAG_VALUE`를 AWS SSM 하이브리드 활성화를 생성할 때 사용한 AWS SSM 리소스 태그 키로 바꿉니다.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "ssm:DescribeInstanceInformation",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "ssm:DeregisterManagedInstance",
"Resource": "arn:aws:ssm:us-east-1:123456789012:managed-instance/*",
"Condition": {
"StringEquals": {
"ssm:resourceTag/TAG_KEY": "TAG_VALUE"
}
}
}
]
}
```
1. **다음**을 선택합니다.
1. **검토 및 생성** 페이지에서
1. 정책에 **정책** 이름(예: `EKSHybridSSMPolicy`)을 입력합니다.
1. **정책 생성**을 선택하세요.
1. 왼쪽 탐색 창에서 **역할**을 선택합니다.
1. **역할** 페이지에서 **역할 생성**을 선택합니다.
1. **신뢰할 수 있는 엔터티 선택** 페이지에서 다음을 수행합니다.
1. **신뢰할 수 있는 엔터티 유형 섹션**에서 **사용자 지정 신뢰 정책**을 선택합니다. 사용자 지정 신뢰 정책 편집기에 다음을 붙여 넣습니다. `AWS_REGION`을 AWS SSM 하이브리드 활성화의 AWS 리전으로 바꾸고 `AWS_ACCOUNT_ID`를 AWS 계정 ID로 바꿉니다.
```
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"",
"Effect":"Allow",
"Principal":{
"Service":"ssm.amazonaws.com"
},
"Action":"sts:AssumeRole",
"Condition":{
"StringEquals":{
"aws:SourceAccount":"123456789012"
},
"ArnEquals":{
"aws:SourceArn":"arn:aws:ssm:us-east-1:123456789012:*"
}
}
}
]
}
```
1. [Next]를 선택합니다.
1. **권한 추가** 페이지에서 사용자 지정 정책을 연결하거나 다음과 같이 합니다.
1. **정책 필터링** 상자에 `EKSDescribeClusterPolicy` 또는 위에서 생성한 정책의 이름을 입력합니다. 검색 결과의 정책 이름 왼쪽에 있는 확인란을 선택합니다.
1. **정책 필터링** 상자에 `EKSHybridSSMPolicy` 또는 위에서 생성한 정책의 이름을 입력합니다. 검색 결과의 정책 이름 왼쪽에 있는 확인란을 선택합니다.
1. **필터 정책** 상자에 `AmazonEC2ContainerRegistryPullOnly`를 입력합니다. 검색 결과의 `AmazonEC2ContainerRegistryPullOnly` 왼쪽에 있는 확인란을 선택합니다.
1. **필터 정책** 상자에 `AmazonSSMManagedInstanceCore`를 입력합니다. 검색 결과의 `AmazonSSMManagedInstanceCore` 왼쪽에 있는 확인란을 선택합니다.
1. **다음**을 선택합니다.
1. **이름, 검토 및 생성** 페이지에서 다음을 수행합니다.
1. **역할 이름**에 역할의 고유한 이름(예: `AmazonEKSHybridNodesRole`)을 입력합니다.
1. **설명(Description)**에서 현재 텍스트를 설명이 포함된 텍스트(예: `Amazon EKS - Hybrid Nodes role`)로 바꿉니다.
1. **역할 생성**을 선택합니다.
**AWS IAM Roles Anywhere의 단계**
AWS IAM Roles Anywhere를 사용하려면 하이브리드 노드 IAM 역할을 생성하기 전에 AWS IAM Roles Anywhere 트러스트 앵커를 설정해야 합니다. 자세한 내용은 [AWS IAM Roles Anywhere 설정](#hybrid-nodes-iam-roles-anywhere) 섹션을 참조하세요.
1. [Amazon IAM 콘솔](https://console.aws.amazon.com/iam/home)을 엽니다.
1. 왼쪽 탐색 창에서 **역할**을 선택합니다.
1. **역할** 페이지에서 **역할 생성**을 선택합니다.
1. **신뢰할 수 있는 엔터티 선택** 페이지에서 다음을 수행합니다.
1. **신뢰할 수 있는 엔터티 유형 섹션**에서 **사용자 지정 신뢰 정책**을 선택합니다. 사용자 지정 신뢰 정책 편집기에 다음을 붙여 넣습니다. `TRUST_ANCHOR ARN`을 [AWS IAM Roles Anywhere 설정](#hybrid-nodes-iam-roles-anywhere) 단계에서 생성한 트러스트 앵커의 ARN으로 바꿉니다. 이 신뢰 정책의 조건은 역할 세션 이름이 하이브리드 노드에 설치된 x509 인증서의 CN과 일치하는 경우에만 AWS IAM Roles Anywhere가 하이브리드 노드 IAM 역할을 수임하여 임시 IAM 자격 증명을 교환하는 기능을 제한합니다. 또는 다른 인증서 속성을 사용하여 노드를 고유하게 식별할 수 있습니다. 신뢰 정책에서 사용하는 인증서 속성은 nodeadm 구성에서 설정한 nodeName과 일치해야 합니다. 자세한 내용은 [하이브리드 노드 `nodeadm` 참조](hybrid-nodes-nodeadm.md)을 참조하세요.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "rolesanywhere.amazonaws.com"
},
"Action": [
"sts:TagSession",
"sts:SetSourceIdentity"
],
"Condition": {
"StringEquals": {
"aws:PrincipalTag/x509Subject/CN": "${aws:PrincipalTag/x509Subject/CN}"
},
"ArnEquals": {
"aws:SourceArn": "arn:aws:rolesanywhere:us-east-1:123456789012:trust-anchor/TA_ID"
}
}
},
{
"Effect": "Allow",
"Principal": {
"Service": "rolesanywhere.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"sts:RoleSessionName": "${aws:PrincipalTag/x509Subject/CN}",
"aws:PrincipalTag/x509Subject/CN": "${aws:PrincipalTag/x509Subject/CN}"
},
"ArnEquals": {
"aws:SourceArn": "arn:aws:rolesanywhere:us-east-1:123456789012:trust-anchor/TA_ID"
}
}
}
]
}
```
1. [Next]를 선택합니다.
1. **권한 추가** 페이지에서 사용자 지정 정책을 연결하거나 다음과 같이 합니다.
1. **정책 필터링** 상자에 `EKSDescribeClusterPolicy` 또는 위에서 생성한 정책의 이름을 입력합니다. 검색 결과의 정책 이름 왼쪽에 있는 확인란을 선택합니다.
1. **필터 정책** 상자에 `AmazonEC2ContainerRegistryPullOnly`를 입력합니다. 검색 결과의 `AmazonEC2ContainerRegistryPullOnly` 왼쪽에 있는 확인란을 선택합니다.
1. **다음**을 선택합니다.
1. **이름, 검토 및 생성** 페이지에서 다음을 수행합니다.
1. **역할 이름**에 역할의 고유한 이름(예: `AmazonEKSHybridNodesRole`)을 입력합니다.
1. **설명(Description)**에서 현재 텍스트를 설명이 포함된 텍스트(예: `Amazon EKS - Hybrid Nodes role`)로 바꿉니다.
1. **역할 생성**을 선택합니다.
# 하이브리드 노드를 사용하여 Amazon EKS 클러스터 생성
이 주제에서는 사용 가능한 옵션에 대한 개요와 하이브리드 노드 지원 Amazon EKS 클러스터를 생성할 때 고려해야 할 사항을 설명합니다. EKS Hybrid Nodes는 표준 및 확장 지원을 포함하여 클라우드 노드가 있는 Amazon EKS 클러스터와 동일한 [Kubernetes 버전 지원](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html)을 제공합니다.
EKS Hybrid Nodes를 사용할 계획이 없는 경우 [Amazon EKS 클러스터 생성](create-cluster.md)의 기본 Amazon EKS 클러스터 생성 설명서를 참조하세요.
## 사전 조건
+ [하이브리드 노드에 대한 사전 조건 설정](hybrid-nodes-prereqs.md)가 완료되었습니다. 하이브리드 노드 지원 클러스터를 생성하기 전에 온프레미스 노드와 선택적으로 포드 CIDR을 식별하고, EKS 요구 사항 및 하이브리드 노드 요구 사항에 따라 VPC 및 서브넷을 생성하고, 온프레미스와 선택적으로 포드 CIDR에 대한 인바운드 규칙이 있는 보안 그룹을 지정해야 합니다. 이러한 사전 조건에 대한 자세한 내용은 [하이브리드 노드용 네트워킹 준비](hybrid-nodes-networking.md) 섹션을 참조하세요.
+ 장치에 최신 버전의 AWS Command Line Interface(AWS CLI)가 설치 및 구성되어 있습니다. 현재 버전을 확인하려면 `aws --version`을 사용합니다. yum, apt-get 또는 macOS용 Homebrew와 같은 패키지 관리자는 최신 버전 AWS CLI 이전에 나온 버전이 몇 가지 있을 때도 있습니다. 최신 버전을 설치하려면 AWS Command Line Interface 사용 설명서의 [최신 버전의 AWS CLI 설치 또는 업데이트](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) 및 [AWS CLI 설정 구성](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config)을 참조하세요.
+ IAM 역할을 생성하고 정책을 연결하며 EKS 클러스터를 생성하고 설명할 권한이 있는 [IAM 보안 주체](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles#iam-term-principal)
## 고려 사항
+ 클러스터는 클러스터 인증 모드에 `API` 또는 `API_AND_CONFIG_MAP`을 사용해야 합니다.
+ 클러스터는 IPv4 주소 패밀리를 사용해야 합니다.
+ 클러스터는 퍼블릭 또는 프라이빗 클러스터 엔드포인트 연결을 사용해야 합니다. Amazon EKS Kubernetes API 서버 엔드포인트는 VPC 외부에서 실행되는 하이브리드 노드의 퍼블릭 IP로 확인되므로 클러스터는 '퍼블릭 및 프라이빗' 클러스터 엔드포인트 연결을 사용할 수 없습니다.
+ OIDC 인증은 하이브리드 노드가 있는 EKS 클러스터에서 지원됩니다.
+ 기존 클러스터의 하이브리드 노드 구성을 추가, 변경 또는 제거할 수 있습니다. 자세한 내용은 [기존 Amazon EKS 클러스터에서 하이브리드 노드 활성화 또는 구성 수정](hybrid-nodes-cluster-update.md) 섹션을 참조하세요.
## 1단계: 클러스터 IAM 역할 만들기
이미 클러스터 IAM 역할이 있거나 `eksctl` 또는 AWS CloudFormation을 사용하여 클러스터를 생성하려는 경우 이 단계를 건너뛸 수 있습니다. 기본적으로 `eksctl` 및 AWS CloudFormation 템플릿은 클러스터 IAM 역할을 생성합니다.
1. 다음 명령을 실행하여 IAM 신뢰 정책 JSON 파일을 생성합니다.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "eks.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
1. Amazon EKS 클러스터 IAM 역할을 생성합니다. 필요한 경우 eks-cluster-role-trust-policy.json 앞에 이전 단계에서 파일을 작성한 컴퓨터의 경로를 붙입니다. 명령은 사용자가 이전 단계에서 생성한 신뢰 정책을 역할에 연결합니다. [IAM 역할](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles#iam-term-principal)을 생성하려면 역할을 생성하는 IAM 보안 주체에 `iam:CreateRole` 작업(권한)을 할당해야 합니다.
```
aws iam create-role \
--role-name myAmazonEKSClusterRole \
--assume-role-policy-document file://"eks-cluster-role-trust-policy.json"
```
1. Amazon EKS 관리형 정책을 할당하거나 사용자 지정 정책을 생성할 수 있습니다. 사용자 지정 정책에서 사용해야 하는 최소 권한은 [Amazon EKS 노드 IAM 역할](create-node-role.md)을(를) 참조하십시오. Amazon EKS 관리형 `AmazonEKSClusterPolicy`를 역할에 연결합니다. IAM 정책을 [IAM 보안 주체](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles#iam-term-principal)에 연결하려면 정책을 연결하는 보안 주체에 `iam:AttachUserPolicy` 또는 `iam:AttachRolePolicy`의 IAM 작업(권한) 중 하나를 할당해야 합니다.
```
aws iam attach-role-policy \
--policy-arn arn:aws:iam::aws:policy/AmazonEKSClusterPolicy \
--role-name myAmazonEKSClusterRole
```
## 2단계: 하이브리드 노드 지원 클러스터 생성
다음을 사용하여 클러스터를 만들 수 있습니다.
+ [eksctl](#hybrid-nodes-cluster-create-eksctl)
+ [AWS CloudFormation](#hybrid-nodes-cluster-create-cfn)
+ [AWS CLI](#hybrid-nodes-cluster-create-cli)
+ [AWS Management Console](#hybrid-nodes-cluster-create-console)
### 하이브리드 노드 지원 클러스터 생성- eksctl
`eksctl` 명령줄 도구의 최신 버전을 설치해야 합니다. `eksctl`을 설치 또는 업그레이드하려면 `eksctl` 설명서에서 [설치](https://eksctl.io/installation)를 참조하세요.
1. `cluster-config.yaml`을 생성하여 하이브리드 노드 지원 Amazon EKS IPv4 클러스터를 정의합니다. `cluster-config.yaml`에서 다음과 같은 교체를 수행합니다. 전체 설정 목록은 [eksctl 설명서](https://eksctl.io/getting-started/)를 참조하세요.
1. `CLUSTER_NAME`를 클러스터 이름으로 바꿉니다. 이름에는 영숫자(대소문자 구분)와 하이픈만 사용할 수 있습니다. 영숫자로 시작해야 하며 100자 이하여야 합니다. 이름은 클러스터를 생성하는 AWS 리전과 AWS 계정 내에서 고유해야 합니다.
1. `AWS_REGION`을 클러스터를 생성할 AWS 리전으로 바꿉니다.
1. `K8S_VERSION`를 모든 [Amazon EKS 지원 버전](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html)으로 변경합니다.
1. [하이브리드 노드에 대한 자격 증명 준비](hybrid-nodes-creds.md)의 단계에서 구성한 자격 증명 공급자를 기반으로 `CREDS_PROVIDER`를 `ssm` 또는 `ira`로 바꿉니다.
1. AWS IAM Roles Anywhere를 자격 증명 공급자로 사용하는 `ira`로 자격 증명 공급자가 설정된 경우 `CA_BUNDLE_CERT`를 바꿉니다. CA\$1BUNDLE\$1CERT는 CA(인증 기관) 인증서 본문이며 CA 선택에 따라 달라집니다. 인증서는 PEM(Privacy Enhanced Mail) 형식이어야 합니다.
1. `GATEWAY_ID`를 VPC에 연결할 가상 프라이빗 게이트웨이 또는 전송 게이트웨이의 ID로 바꿉니다.
1. `REMOTE_NODE_CIDRS`를 하이브리드 노드의 온프레미스 노드 CIDR로 바꿉니다.
1. `REMOTE_POD_CIDRS`를 하이브리드 노드에서 실행되는 워크로드의 온프레미스 포드 CIDR로 바꾸거나 하이브리드 노드에서 웹후크를 실행하지 않는 경우 구성에서 라인을 제거합니다. 포드 트래픽이 온프레미스 호스트에서 나갈 때 CNI가 포드 IP 주소에 네트워크 주소 변환(NAT) 또는 매스커레이딩을 사용하지 않는 경우 `REMOTE_POD_CIDRS`를 구성해야 합니다. 하이브리드 노드에서 웹후크를 실행하는 경우 `REMOTE_POD_CIDRS`를 구성해야 합니다. [하이브리드 노드용 웹후크 구성](hybrid-nodes-webhooks.md)에서 자세한 내용을 참조하세요.
1. 온프레미스 노드 및 포드 CIDR 블록은 다음 요구 사항을 충족해야 합니다.
1. IPv4 RFC-1918 범위 중 하나(`10.0.0.0/8`, `172.16.0.0/12` 또는 `192.168.0.0/16`) 또는 RFC 6598에 의해 정의된 CGNAT 범위 내(`100.64.0.0/10`)에 있어야 합니다.
1. 서로, 클러스터의 `VPC CIDR` 또는 Kubernetes 서비스 IPv4 CIDR과 중첩되지 않습니다.
```
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
name: CLUSTER_NAME
region: AWS_REGION
version: "K8S_VERSION"
remoteNetworkConfig:
iam:
provider: CREDS_PROVIDER # default SSM, can also be set to IRA
# caBundleCert: CA_BUNDLE_CERT
vpcGatewayID: GATEWAY_ID
remoteNodeNetworks:
- cidrs: ["REMOTE_NODE_CIDRS"]
remotePodNetworks:
- cidrs: ["REMOTE_POD_CIDRS"]
```
1. 다음 명령을 실행합니다.
```
eksctl create cluster -f cluster-config.yaml
```
클러스터 프로비저닝에는 몇 분 정도 걸립니다. 클러스터가 생성되는 동안 여러 줄의 출력이 나타납니다. 출력의 마지막 줄은 다음 예제와 유사합니다.
```
[✓] EKS cluster "CLUSTER_NAME" in "REGION" region is ready
```
1. [3단계: kubeconfig 업데이트](#hybrid-nodes-cluster-create-kubeconfig) 항목을 계속 진행합니다.
### 하이브리드 노드 지원 클러스터 생성-AWS CloudFormation
CloudFormation 스택은 사용자가 지정하는 `RemoteNodeNetwork` 및 `RemotePodNetwork`를 사용하여 EKS 클러스터 IAM 역할과 EKS 클러스터를 생성합니다. CloudFormation 템플릿에 노출되지 않은 EKS 클러스터의 설정을 사용자 지정해야 하는 경우 CloudFormation 템플릿을 수정합니다.
1. CloudFormation 템플릿을 다운로드하십시오.
```
curl -OL 'https://raw.githubusercontent.com/aws/eks-hybrid/refs/heads/main/example/hybrid-eks-cfn.yaml'
```
1. `cfn-eks-parameters.json`을 생성하고 각 값에 대한 구성을 지정합니다.
1. `CLUSTER_NAME`: 생성할 EKS 클러스터의 이름입니다.
1. `CLUSTER_ROLE_NAME`: 생성할 EKS 클러스터 IAM 역할의 이름입니다. 템플릿의 기본값은 'EKSClusterRole'입니다.
1. `SUBNET1_ID`: 사전 조건 단계에서 생성한 첫 번째 서브넷의 ID입니다.
1. `SUBNET2_ID`: 사전 조건 단계에서 생성한 두 번째 서브넷의 ID입니다.
1. `SG_ID`: 이전 단계에서 만든 보안 그룹 ID입니다.
1. `REMOTE_NODE_CIDRS`: 하이브리드 노드에 대한 온프레미스 노드 CIDR입니다.
1. `REMOTE_POD_CIDRS`: 하이브리드 노드에서 실행되는 워크로드에 대한 온프레미스 포드 CIDR입니다. 포드 트래픽이 온프레미스 호스트에서 나갈 때 CNI가 포드 IP 주소에 네트워크 주소 변환(NAT) 또는 매스커레이딩을 사용하지 않는 경우 `REMOTE_POD_CIDRS`를 구성해야 합니다. 하이브리드 노드에서 웹후크를 실행하는 경우 `REMOTE_POD_CIDRS`를 구성해야 합니다. [하이브리드 노드용 웹후크 구성](hybrid-nodes-webhooks.md)에서 자세한 내용을 참조하세요.
1. 온프레미스 노드 및 포드 CIDR 블록은 다음 요구 사항을 충족해야 합니다.
1. IPv4 RFC-1918 범위 중 하나(`10.0.0.0/8`, `172.16.0.0/12` 또는 `192.168.0.0/16`) 또는 RFC 6598에 의해 정의된 CGNAT 범위 내(`100.64.0.0/10`)에 있어야 합니다.
1. 서로, 클러스터의 `VPC CIDR` 또는 Kubernetes 서비스 IPv4 CIDR과 중첩되지 않습니다.
1. `CLUSTER_AUTH`: 클러스터의 클러스터 인증 모드입니다. 유효 값은 `API` 및 `API_AND_CONFIG_MAP`입니다. 템플릿의 기본값은 `API_AND_CONFIG_MAP`입니다.
1. `CLUSTER_ENDPOINT`: 클러스터의 클러스터 엔드포인트 연결입니다. 유효한 값은 '퍼블릭' 또는 '프라이빗'입니다. 템플릿의 기본값은 프라이빗입니다. 즉, VPC 내에서만 Kubernetes API 엔드포인트에 연결할 수 있습니다.
1. `K8S_VERSION`: 클러스터에 사용할 Kubernetes 버전입니다. [Amazon EKS supported versions](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html)을 참조하세요.
```
{
"Parameters": {
"ClusterName": "CLUSTER_NAME",
"ClusterRoleName": "CLUSTER_ROLE_NAME",
"SubnetId1": "SUBNET1_ID",
"SubnetId2": "SUBNET2_ID",
"SecurityGroupId" "SG_ID",
"RemoteNodeCIDR": "REMOTE_NODE_CIDRS",
"RemotePodCIDR": "REMOTE_POD_CIDRS",
"ClusterAuthMode": "CLUSTER_AUTH",
"ClusterEndpointConnectivity": "CLUSTER_ENDPOINT",
"K8sVersion": "K8S_VERSION"
}
}
```
1. CloudFormation 스택 배포 `STACK_NAME`을 CloudFormation 스택의 이름으로 바꾸고 `AWS_REGION`을 클러스터를 생성할 AWS 리전으로 바꿉니다.
```
aws cloudformation deploy \
--stack-name STACK_NAME \
--region AWS_REGION \
--template-file hybrid-eks-cfn.yaml \
--parameter-overrides file://cfn-eks-parameters.json \
--capabilities CAPABILITY_NAMED_IAM
```
클러스터 프로비저닝에는 몇 분 정도 걸립니다. 다음 명령을 사용하여 스택의 상태를 확인할 수 있습니다. `STACK_NAME`을 CloudFormation 스택의 이름으로 바꾸고 `AWS_REGION`을 클러스터를 생성할 AWS 리전으로 바꿉니다.
```
aws cloudformation describe-stacks \
--stack-name STACK_NAME \
--region AWS_REGION \
--query 'Stacks[].StackStatus'
```
1. [3단계: kubeconfig 업데이트](#hybrid-nodes-cluster-create-kubeconfig) 항목을 계속 진행합니다.
### 하이브리드 노드 지원 클러스터 생성-AWS CLI
1. 다음 명령을 실행하여 하이브리드 노드 지원 EKS 클러스터를 생성합니다. 명령을 실행하기 전에 다음을 실제 설정으로 바꿉니다. 전체 설정 목록은 [Amazon EKS 클러스터 생성](create-cluster.md) 설명서를 참조하세요.
1. `CLUSTER_NAME`: 생성할 EKS 클러스터의 이름입니다.
1. `AWS_REGION`: 클러스터가 생성될 AWS 리전입니다.
1. `K8S_VERSION`: 클러스터에 사용할 Kubernetes 버전입니다. 지원되는 Amazon EKS 버전을 참조하세요.
1. `ROLE_ARN`: 클러스터에 대해 구성한 Amazon EKS 클러스터 역할입니다. 자세한 내용은 Amazon EKS 클러스터 IAM 역할을 참조하세요.
1. `SUBNET1_ID`: 사전 조건 단계에서 생성한 첫 번째 서브넷의 ID입니다.
1. `SUBNET2_ID`: 사전 조건 단계에서 생성한 두 번째 서브넷의 ID입니다.
1. `SG_ID`: 이전 단계에서 만든 보안 그룹 ID입니다.
1. 클러스터 액세스 인증 모드에서 `API` 및 `API_AND_CONFIG_MAP`을 사용할 수 있습니다. 아래 명령에서 클러스터 액세스 인증 모드는 `API_AND_CONFIG_MAP`으로 설정됩니다.
1. `endpointPublicAccess` 및 `endpointPrivateAccess` 파라미터를 사용하여 클러스터의 Kubernetes API 서버 엔드포인트에 대한 퍼블릭 및 프라이빗 액세스를 활성화하거나 비활성화할 수 있습니다. 아래 명령에서 `endpointPublicAccess`는 false로 설정되고 `endpointPrivateAccess`는 true로 설정됩니다.
1. `REMOTE_NODE_CIDRS`: 하이브리드 노드에 대한 온프레미스 노드 CIDR입니다.
1. `REMOTE_POD_CIDRS` (선택 사항): 하이브리드 노드에서 실행되는 워크로드에 대한 온프레미스 포드 CIDR입니다.
1. 온프레미스 노드 및 포드 CIDR 블록은 다음 요구 사항을 충족해야 합니다.
1. IPv4 RFC-1918 범위 중 하나(`10.0.0.0/8`, `172.16.0.0/12` 또는 `192.168.0.0/16`) 또는 RFC 6598에 의해 정의된 CGNAT 범위 내(`100.64.0.0/10`)에 있어야 합니다.
1. 서로, Amazon EKS 클러스터의 `VPC CIDR` 또는 Kubernetes 서비스 IPv4 CIDR과 중첩되지 않습니다.
```
aws eks create-cluster \
--name CLUSTER_NAME \
--region AWS_REGION \
--kubernetes-version K8S_VERSION \
--role-arn ROLE_ARN \
--resources-vpc-config subnetIds=SUBNET1_ID,SUBNET2_ID,securityGroupIds=SG_ID,endpointPrivateAccess=true,endpointPublicAccess=false \
--access-config authenticationMode=API_AND_CONFIG_MAP \
--remote-network-config '{"remoteNodeNetworks":[{"cidrs":["REMOTE_NODE_CIDRS"]}],"remotePodNetworks":[{"cidrs":["REMOTE_POD_CIDRS"]}]}'
```
1. 클러스터를 프로비저닝하는 데 몇 분 정도 걸립니다. 다음 명령을 사용하여 클러스터의 상태를 쿼리할 수 있습니다. `CLUSTER_NAME`을 생성 중인 클러스터의 이름으로 바꾸고 `AWS_REGION`을 클러스터가 생성 중인 AWS 리전으로 바꿉니다. 반환되는 출력이 `ACTIVE`가 되면 다음 단계로 진행하세요.
```
aws eks describe-cluster \
--name CLUSTER_NAME \
--region AWS_REGION \
--query "cluster.status"
```
1. [3단계: kubeconfig 업데이트](#hybrid-nodes-cluster-create-kubeconfig) 항목을 계속 진행합니다.
### 하이브리드 노드 지원 클러스터 생성 - AWS Management Console
1. [Amazon EKS 콘솔](https://console.aws.amazon.com/eks/home#/clusters)에서 Amazon EKS 콘솔을 엽니다.
1. 클러스터 추가를 선택하고 생성을 선택합니다.
1. 클러스터 구성 페이지에서 다음 필드를 입력합니다.
1. **이름** - 클러스터의 이름 이름에는 영숫자(대소문자 구분)와 하이픈, 밑줄만 사용할 수 있습니다. 영숫자로 시작해야 하며 100자 이하여야 합니다. 이름은 클러스터를 생성하는 AWS 리전과 AWS 계정 내에서 고유해야 합니다.
1. **클러스터 IAM 역할**-생성한 Amazon EKS 클러스터 IAM 역할을 선택하여 Kubernetes 컨트롤 플레인이 사용자 대신 AWS 리소스를 관리하게 할 수 있습니다.
1. **Kubernetes 버전(Kubernetes version)** - 클러스터에 대해 사용할 Kubernetes 버전 이전 버전이 필요한 경우가 아니면 최신 버전을 선택하는 것이 좋습니다.
1. **업그레이드 정책**-확장 또는 표준을 선택합니다.
1. **확장:** 이 옵션은 릴리스 날짜 이후 26개월 동안 Kubernetes 버전을 지원합니다. 연장 지원 기간에는 표준 지원 기간이 종료된 후 시작되는 시간당 추가 비용이 발생합니다. 확장 지원이 종료되면 클러스터가 다음 버전으로 자동 업그레이드됩니다.
1. **표준:** 이 옵션은 릴리스 날짜 이후 14개월 동안 Kubernetes 버전을 지원합니다. 추가 비용은 없습니다. 표준 지원이 종료되면 클러스터가 다음 버전으로 자동 업그레이드됩니다.
1. **클러스터 액세스**-클러스터 관리자 액세스를 허용하거나 허용하지 않도록 선택하고 인증 모드를 선택합니다. 하이브리드 노드 지원 클러스터에는 다음 인증 모드가 지원됩니다.
1. **EKS API**: 클러스터는 EKS 액세스 항목 API에서만 인증된 IAM 보안 주체를 가져옵니다.
1. **EKS API 및 ConfigMap**: 클러스터는 EKS 액세스 항목 API와 `aws-auth` ConfigMap 모두에서 인증된 IAM 보안 주체를 가져옵니다.
1. **비밀 암호화(Secrets encryption)** - (선택 사항) KMS 키를 사용하여 Kubernetes 비밀의 비밀 암호화를 사용 설정하도록 선택합니다. 클러스터를 생성한 후에도 이 기능을 사용 설정할 수 있습니다. 이 기능을 사용 설정하기 전에 [기존 클러스터에서 KMS를 사용하여 Kubernetes 비밀 암호화](enable-kms.md)의 정보를 숙지해야 합니다.
1. **ARC 영역 전환** - 이 기능을 활성화하면 EKS는 클러스터를 ARC 영역 전환에 등록하여 영역 전환을 통해 애플리케이션 트래픽을 AZ에서 다른 위치로 전환할 수 있습니다.
1. **태그**-(선택사항) 클러스터에 태그를 추가합니다. 자세한 내용은 [태그를 사용하여 Amazon EKS 리소스 구성](eks-using-tags.md) 섹션을 참조하세요.
1. 이 페이지를 모두 완료하면 **다음**을 선택합니다.
1. **네트워킹 지정** 페이지에서 다음 필드의 값을 선택합니다.
1. **VPC**-[VPC 및 서브넷에 대한 Amazon EKS 네트워킹 요구 사항 보기](network-reqs.md) 및 [Amazon EKS Hybrid Nodes 요구 사항](hybrid-nodes-prereqs.md)을 충족하는 기존 VPC를 선택합니다. VPC를 선택하기 전에 VPC, 서브넷, 하이브리드 노드에 대한 Amazon EKS 네트워킹 요구 사항 보기의 모든 요구 사항과 고려 사항을 숙지하는 것이 좋습니다. 클러스터 생성 후에는 사용하려는 VPC를 변경할 수 없습니다. 목록에 기존 VPC가 없는 경우 먼저 VPC를 생성해야 합니다. 자세한 내용은 [Amazon EKS 클러스터에 대한 Amazon VPC 생성](creating-a-vpc.md) 및 [Amazon EKS Hybrid Nodes 네트워킹 요구 사항](hybrid-nodes-prereqs.md)을 참조하세요.
1. **서브넷**-기본적으로 이전 필드에서 지정한 VPC에서 사용 가능한 모든 서브넷이 사전 선택됩니다. 두 개 이상을 선택해야 합니다.
1. **보안 그룹** – (선택사항) 생성하는 네트워크 인터페이스에 Amazon EKS가 연결하려는 보안 그룹을 하나 이상 지정합니다. 지정하는 보안 그룹 중 하나 이상에 온프레미스 노드와 선택적으로 포드 CIDR에 대한 인바운드 규칙이 있어야 합니다. 자세한 내용은 [Amazon EKS Hybrid Nodes networking requirements](hybrid-nodes-networking.md)을 참조하세요. 보안 그룹 선택 여부에 관계없이 Amazon EKS는 클러스터와 VPC 간에 통신을 사용 설정할 수 있는 보안 그룹을 생성합니다. Amazon EKS는 이 보안 그룹과 사용자가 선택한 보안 그룹을 생성하는 네트워크 인터페이스에 연결합니다. Amazon EKS가 생성하는 클러스터 보안 그룹에 대한 자세한 내용은 [클러스터에 대한 Amazon EKS 보안 그룹 요구 사항 보기](sec-group-reqs.md) 섹션을 참조하세요. Amazon EKS가 생성하는 클러스터 보안 그룹의 규칙을 수정할 수 있습니다.
1. **클러스터 IP 주소 패밀리 선택**-하이브리드 노드 지원 클러스터의 경우 IPv4를 선택해야 합니다.
1. (선택 사항) **Kubernetes 서비스 IP 주소 범위 구성**을 선택하고 **서비스 IPv4 범위**를 지정합니다.
1. **하이브리드 노드를 활성화하도록 원격 네트워크 구성을 선택**하고 하이브리드 노드에 대한 온프레미스 노드와 포드 CIDR을 지정합니다.
1. 포드 트래픽이 온프레미스 호스트에서 나갈 때 CNI가 포드 IP 주소에 네트워크 주소 변환(NAT) 또는 매스커레이딩을 사용하지 않는 경우 원격 포드 CIDR을 구성해야 합니다. 하이브리드 노드에서 웹후크를 실행하는 경우 원격 포드 CIDR을 구성해야 합니다.
1. 온프레미스 노드 및 포드 CIDR 블록은 다음 요구 사항을 충족해야 합니다.
1. IPv4 RFC-1918 범위 중 하나(`10.0.0.0/8`, `172.16.0.0/12` 또는 `192.168.0.0/16`) 또는 RFC 6598에 의해 정의된 CGNAT 범위 내(`100.64.0.0/10`)에 있어야 합니다.
1. 서로, 클러스터의 `VPC CIDR` 또는 Kubernetes 서비스 IPv4 CIDR과 중첩되지 않습니다.
1. **클러스터 엔드포인트 액세스**에서 옵션을 선택합니다. 클러스터를 생성한 후에는 이 옵션을 변경할 수 있습니다. 하이브리드 노드 지원 클러스터의 경우 퍼블릭 또는 프라이빗을 선택해야 합니다. 기본값이 아닌 옵션을 선택하기 전에 옵션과 그 의미를 숙지해야 합니다. 자세한 내용은 [클러스터 API 서버 엔드포인트](cluster-endpoint.md) 섹션을 참조하세요.
1. 이 페이지를 모두 완료하면 **다음**을 선택합니다.
1. (선택사항) 관찰성 **구성** 페이지에서 설정할 지표 및 컨트롤 플레인 로깅 옵션을 선택합니다. 기본적으로 각 로그 유형은 해제되어 있습니다.
1. Prometheus 지표 옵션에 자세한 내용은 [Prometheus를 사용한 클러스터 지표 모니터링](prometheus.md) 섹션을 참조하세요.
1. EKS 컨트롤 로깅 옵션에 대한 자세한 내용은 [CloudWatch Logs에 컨트롤 플레인 로그 전송](control-plane-logs.md) 섹션을 참조하세요.
1. 이 페이지를 모두 완료하면 **다음**을 선택합니다.
1. **추가 기능 선택** 페이지에서 클러스터에 추가할 추가 기능을 선택합니다.
1. 필요한 만큼 **Amazon EKS 애드온** 및 **AWS 마켓플레이스 애드온**을 선택할 수 있습니다. 하이브리드 노드와 호환되지 않는 Amazon EKS 추가 기능은 '하이브리드 노드와 호환되지 않음'으로 표시되며 추가 기능에는 하이브리드 노드에서 실행되지 않게 하는 반선호도 규칙이 있습니다. 자세한 내용은 하이브리드 노드용 추가 기능 구성을 참조하세요. 설치하려는 **AWS 마켓플레이스 애드온**이 목록에 없는 경우 검색창에 텍스트를 입력하여 사용 가능한 **AWS 마켓플레이스 애드온**을 검색할 수 있습니다. **카테고리**, **공급업체** 또는 **요금 모델**로 검색한 다음에 검색 결과 중에서 추가 기능을 선택할 수도 있습니다.
1. CoreDNS, kube-proxy와 같은 일부 추가 기능은 기본적으로 설치됩니다. 기본 추가 기능을 비활성화하면 Kubernetes 애플리케이션 실행 기능에 영향을 미칠 수 있습니다.
1. 이 페이지를 모두 완료하면 `Next`을 선택합니다.
1. **선택한 추가 기능 설정 구성** 페이지에서 설치할 버전을 선택합니다.
1. 클러스터 생성 후 언제든지 최신 버전으로 업데이트할 수 있습니다. 클러스터 생성 후 각 추가 기능의 구성을 업데이트할 수 있습니다. 추가 기능 구성에 대한 자세한 내용은 [Amazon EKS 추가 기능 업데이트](updating-an-add-on.md) 섹션을 참조하세요. 하이브리드 노드와 호환되는 추가 기능 버전은 [하이브리드 노드에 대한 추가 기능 구성](hybrid-nodes-add-ons.md) 섹션을 참조하세요.
1. 이 페이지를 모두 완료하면 다음을 선택합니다.
1. **검토 및 생성** 페이지에서 이전 페이지에서 입력하거나 선택한 정보를 검토합니다. 변경해야 하는 경우 **편집**을 선택합니다 만족하는 경우 **생성**을 선택합니다. 클러스터가 프로비저닝되는 동안 **상태** 필드에는 **생성 중**이 표시됩니다. 클러스터 프로비저닝에는 몇 분 정도 걸립니다.
1. [3단계: kubeconfig 업데이트](#hybrid-nodes-cluster-create-kubeconfig) 항목을 계속 진행합니다.
## 3단계: kubeconfig 업데이트
`eksctl`을 사용하여 클러스터를 생성한 경우 이 단계를 건너뛸 수 있습니다. 이는 `eksctl`이 사용자 대신 이 단계를 이미 완료했기 때문입니다. `kubectl` 구성 파일에 새 컨텍스트를 추가하여 이 클러스터와 통신하도록 `kubectl`을 활성화합니다. 파일 생성 및 업데이트 방법에 대한 자세한 내용을 알아보려면 [Kubeconfig 파일을 생성하여 kubectl을 EKS 클러스터에 연결](create-kubeconfig.md) 부분을 참조하세요.
```
aws eks update-kubeconfig --name CLUSTER_NAME --region AWS_REGION
```
예제 출력은 다음과 같습니다.
```
Added new context arn:aws:eks:AWS_REGION:111122223333:cluster/CLUSTER_NAME to /home/username/.kube/config
```
다음 명령을 실행하여 클러스터와의 통신을 확인합니다.
```
kubectl get svc
```
예제 출력은 다음과 같습니다.
```
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.100.0.1 443/TCP 28h
```
## 4단계: 클러스터 설정
다음 단계로 하이브리드 노드가 클러스터에 조인할 수 있도록 액세스를 활성화하려면 [하이브리드 노드에 대한 클러스터 액세스 준비](hybrid-nodes-cluster-prep.md) 섹션을 참조하세요.
# 기존 Amazon EKS 클러스터에서 하이브리드 노드 활성화 또는 구성 수정
이 주제에서는 사용 가능한 옵션에 대한 개요를 제공하고 Amazon EKS 클러스터의 하이브리드 노드 구성을 추가, 변경 또는 제거할 때 고려해야 할 사항을 설명합니다.
Amazon EKS 클러스터에서 하이브리드 노드를 사용할 수 있게 하려면 `RemoteNetworkConfig` 구성에서 온프레미스 노드와 포드 네트워크(선택 사항)의 IP 주소 CIDR 범위를 추가합니다. EKS는 이 CIDR 목록을 사용하여 클러스터와 온프레미스 네트워크 간의 연결을 활성화합니다. 클러스터 구성을 업데이트할 때의 전체 옵션 목록은 *Amazon EKS API 참조*의 [UpdateClusterConfig](https://docs.aws.amazon.com/eks/latest/APIReference/API_UpdateClusterConfig.html)를 참조하세요.
클러스터의 EKS Hybrid Nodes 네트워킹 구성에 대해 다음 작업 중 하나를 수행할 수 있습니다.
+ [원격 네트워크 구성을 추가하여 기존 클러스터에서 EKS Hybrid Nodes를 활성화합니다.](#hybrid-nodes-cluster-enable-existing)
+ [기존 클러스터에서 원격 노드 네트워크나 원격 포드 네트워크를 추가, 변경 또는 제거합니다.](#hybrid-nodes-cluster-update-config)
+ [모든 원격 노드 네트워크 CIDR 범위를 제거하여 기존 클러스터에서 EKS Hybrid Nodes를 비활성화합니다.](#hybrid-nodes-cluster-disable)
## 사전 조건
+ 하이브리드 노드에 대해 Amazon EKS 클러스터를 활성화하기 전에 환경이 [하이브리드 노드에 대한 사전 조건 설정](hybrid-nodes-prereqs.md)에 요약되어 있고 [하이브리드 노드용 네트워킹 준비](hybrid-nodes-networking.md), [하이브리드 노드용 운영 체제 준비](hybrid-nodes-os.md) 및 [하이브리드 노드에 대한 자격 증명 준비](hybrid-nodes-creds.md)에 자세히 설명된 요구 사항을 충족하는지 확인합니다.
+ 클러스터는 IPv4 주소 패밀리를 사용해야 합니다.
+ 클러스터는 클러스터 인증 모드에 `API` 또는 `API_AND_CONFIG_MAP`을 사용해야 합니다. 클러스터 인증 모드를 수정하는 프로세스는 [액세스 항목을 사용하도록 인증 모드 변경](setting-up-access-entries.md)에 설명되어 있습니다.
+ Amazon EKS Kubernetes API 서버 엔드포인트에 퍼블릭 또는 프라이빗 엔드포인트 액세스 중 하나만 사용하는 것이 좋습니다. '퍼블릭 및 프라이빗'을 선택하면 Amazon EKS Kubernetes API 서버 엔드포인트가 항상 VPC 외부에서 실행되는 하이브리드 노드의 퍼블릭 IP로 확인되므로 하이브리드 노드가 클러스터에 조인하지 못할 수 있습니다. 클러스터에 대한 네트워크 액세스를 수정하는 프로세스는 [클러스터 API 서버 엔드포인트](cluster-endpoint.md)에 설명되어 있습니다.
+ 장치에 최신 버전의 AWS Command Line Interface(AWS CLI)가 설치 및 구성되어 있습니다. 현재 버전을 확인하려면 `aws --version`을 사용합니다. yum, apt-get 또는 macOS용 Homebrew와 같은 패키지 관리자는 최신 버전 AWS CLI 이전에 나온 버전이 몇 가지 있을 때도 있습니다. 최신 버전을 설치하려면 AWS 명령줄 인터페이스 사용 설명서의 [최신 버전의 AWS CLI 설치 또는 업데이트](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) 및 [AWS CLI 설정 구성](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config)을 참조하세요.
+ Amazon EKS 클러스터에서 [UpdateClusterConfig](https://docs.aws.amazon.com/eks/latest/APIReference/API_UpdateClusterConfig.html)를 직접적으로 호출할 수 있는 권한이 있는 [IAM 위탁자](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles#iam-term-principal)입니다.
+ 하이브리드 노드와 호환되는 버전으로 추가 기능을 업데이트합니다. 하이브리드 노드와 호환되는 추가 기능 버전은 [하이브리드 노드에 대한 추가 기능 구성](hybrid-nodes-add-ons.md) 섹션을 참조하세요.
+ 하이브리드 노드와 호환되지 않는 추가 기능을 실행하는 경우 하이브리드 노드에 배포를 방지하는 다음 선호도 규칙이 추가 기능 [DaemonSet](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/) 또는 [배포](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/)에 있는지 확인합니다. 아직 없으면 다음 선호도 규칙을 추가합니다.
```
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: eks.amazonaws.com/compute-type
operator: NotIn
values:
- hybrid
```
## 고려 사항
`remoteNetworkConfig` JSON 객체는 업데이트 중 다음과 같은 동작을 합니다.
+ 지정하지 않은 구성의 기존 부분은 변경되지 않습니다. `remoteNodeNetworks` 또는 `remotePodNetworks` 중 하나를 지정하지 않는 경우 해당 부분은 동일하게 유지됩니다.
+ CIDR의 `remoteNodeNetworks` 또는 `remotePodNetworks` 목록 중 하나를 수정하는 경우 최종 구성에서 원하는 CIDR의 전체 목록을 지정해야 합니다. `remoteNodeNetworks` 또는 `remotePodNetworks` CIDR 목록 중 하나에 대한 변경 사항을 지정하는 경우 업데이트 중 EKS가 원래 목록을 대체합니다.
+ 온프레미스 노드 및 포드 CIDR 블록은 다음 요구 사항을 충족해야 합니다.
1. IPv4 RFC-1918 범위 중 하나(10.0.0.0/8, 172.16.0.0/12 또는 192.168.0.0/16) 중 하나 또는 RFC 6598에 의해 정의된 CGNAT 범위 내(`100.64.0.0/10`)에 있어야 합니다.
1. 서로, Amazon EKS 클러스터의 모든 VPC CIDR 또는 Kubernetes 서비스 IPv4 CIDR과 중첩되지 않아야 합니다.
## 기존 클러스터에서 하이브리드 노드 활성화
다음을 사용하여 기존 클러스터에서 EKS Hybrid Nodes를 활성화할 수 있습니다.
+ [AWS CloudFormation](#hybrid-nodes-cluster-enable-cfn)
+ [AWS CLI](#hybrid-nodes-cluster-enable-cli)
+ [AWS Management Console](#hybrid-nodes-cluster-enable-console)
### 기존 클러스터에서 EKS Hybrid Nodes 활성화 - AWS CloudFormation
1. 클러스터에서 EKS Hybrid Nodes를 활성화하려면 CloudFormation 템플릿에 `RemoteNodeNetwork`와 `RemotePodNetwork`(선택 사항)를 추가하고 스택을 업데이트합니다. `RemoteNodeNetwork`는 최대 하나의 `Cidrs` 항목이 포함된 목록이고, `Cidrs`는 여러 IP CIDR 범위의 목록입니다.
```
RemoteNetworkConfig:
RemoteNodeNetworks:
- Cidrs: [RemoteNodeCIDR]
RemotePodNetworks:
- Cidrs: [RemotePodCIDR]
```
1. 계속해서 [하이브리드 노드에 대한 클러스터 액세스 준비](hybrid-nodes-cluster-prep.md)로 이동하세요.
### 기존 클러스터에서 EKS Hybrid Nodes 활성화 - AWS CLI
1. 다음 명령을 실행하여 EKS 클러스터의 EKS Hybrid Nodes에 대해 `RemoteNetworkConfig`를 활성화합니다. 명령을 실행하기 전에 다음을 실제 설정으로 바꿉니다. 전체 설정 목록은 *Amazon EKS API 참조*의 [UpdateClusterConfig](https://docs.aws.amazon.com/eks/latest/APIReference/API_UpdateClusterConfig.html)를 참조하세요.
1. `CLUSTER_NAME`: 업데이트할 EKS 클러스터의 이름입니다.
1. `AWS_REGION`: EKS 클러스터가 실행 중인 AWS 리전입니다.
1. `REMOTE_NODE_CIDRS`: 하이브리드 노드에 대한 온프레미스 노드 CIDR입니다.
1. `REMOTE_POD_CIDRS` (선택 사항): 하이브리드 노드에서 실행되는 워크로드에 대한 온프레미스 포드 CIDR입니다.
```
aws eks update-cluster-config \
--name CLUSTER_NAME \
--region AWS_REGION \
--remote-network-config '{"remoteNodeNetworks":[{"cidrs":["REMOTE_NODE_CIDRS"]}],"remotePodNetworks":[{"cidrs":["REMOTE_POD_CIDRS"]}]}'
```
1. 클러스터를 업데이트하는 데 몇 분 정도 걸립니다. 다음 명령을 사용하여 클러스터의 상태를 쿼리할 수 있습니다. `CLUSTER_NAME`을 수정 중인 클러스터의 이름으로 바꾸고 `AWS_REGION`을 클러스터가 실행되고 있는 AWS 리전으로 바꿉니다. 반환되는 출력이 `ACTIVE`가 되면 다음 단계로 진행하세요.
```
aws eks describe-cluster \
--name CLUSTER_NAME \
--region AWS_REGION \
--query "cluster.status"
```
1. 계속해서 [하이브리드 노드에 대한 클러스터 액세스 준비](hybrid-nodes-cluster-prep.md)로 이동하세요.
### 기존 클러스터에서 EKS Hybrid Nodes 활성화 - AWS Management Console
1. [Amazon EKS 콘솔](https://console.aws.amazon.com/eks/home#/clusters)에서 Amazon EKS 콘솔을 엽니다.
1. 클러스터 이름을 선택하여 클러스터 정보를 표시합니다.
1. **네트워킹** 탭을 선택하고 **관리**를 선택합니다.
1. 드롭다운에서 **원격 네트워크**를 선택합니다.
1. **하이브리드 노드를 활성화하도록 원격 네트워크 구성을 선택**하고 하이브리드 노드에 대한 온프레미스 노드와 포드 CIDR을 지정합니다.
1. **변경 사항 저장**을 선택하여 종료합니다. 클러스터가 **활성** 상태로 돌아갈 때까지 기다립니다.
1. 계속해서 [하이브리드 노드에 대한 클러스터 액세스 준비](hybrid-nodes-cluster-prep.md)로 이동하세요.
## 기존 클러스터에서 하이브리드 노드 구성 업데이트
다음 중 하나를 사용하여 기존 하이브리드 클러스터에서 `remoteNetworkConfig`를 수정할 수 있습니다.
+ [AWS CloudFormation](#hybrid-nodes-cluster-update-cfn)
+ [AWS CLI](#hybrid-nodes-cluster-update-cli)
+ [AWS Management Console](#hybrid-nodes-cluster-update-console)
### 기존 클러스터에서 하이브리드 구성 업데이트 - AWS CloudFormation
1. 새 네트워크 CIDR 값으로 CloudFormation 템플릿을 업데이트합니다.
```
RemoteNetworkConfig:
RemoteNodeNetworks:
- Cidrs: [NEW_REMOTE_NODE_CIDRS]
RemotePodNetworks:
- Cidrs: [NEW_REMOTE_POD_CIDRS]
```
**참고**
`RemoteNodeNetworks` 또는 `RemotePodNetworks` CIDR 목록을 업데이트할 때 모든 CIDR(신규 및 기존)을 포함합니다. EKS는 업데이트 중 전체 목록을 대체합니다. 업데이트 요청에서 이러한 필드를 생략하면 기존 구성이 유지됩니다.
1. 수정된 템플릿으로 CloudFormation 스택을 업데이트하고 스택 업데이트가 완료될 때까지 기다립니다.
### 기존 클러스터에서 하이브리드 구성 업데이트 - AWS CLI
1. 원격 네트워크 CIDR을 수정하려면 다음 명령을 실행합니다. 값을 실제 설정으로 바꿉니다.
```
aws eks update-cluster-config
--name CLUSTER_NAME
--region AWS_REGION
--remote-network-config '{"remoteNodeNetworks":[{"cidrs":["NEW_REMOTE_NODE_CIDRS"]}],"remotePodNetworks":[{"cidrs":["NEW_REMOTE_POD_CIDRS"]}]}'
```
**참고**
`remoteNodeNetworks` 또는 `remotePodNetworks` CIDR 목록을 업데이트할 때 모든 CIDR(신규 및 기존)을 포함합니다. EKS는 업데이트 중 전체 목록을 대체합니다. 업데이트 요청에서 이러한 필드를 생략하면 기존 구성이 유지됩니다.
1. 계속 진행하기 전에 클러스터가 활성화됨 상태로 돌아갈 때까지 기다립니다.
### 기존 클러스터에서 하이브리드 구성 업데이트 - AWS Management Console
1. [Amazon EKS 콘솔](https://console.aws.amazon.com/eks/home#/clusters)에서 Amazon EKS 콘솔을 엽니다.
1. 클러스터 이름을 선택하여 클러스터 정보를 표시합니다.
1. **네트워킹** 탭을 선택하고 **관리**를 선택합니다.
1. 드롭다운에서 **원격 네트워크**를 선택합니다.
1. 필요에 따라 `Remote pod networks - Optional` 및 `Remote node networks`에서 CIDR을 업데이트합니다.
1. **변경 사항 저장**을 선택하고 클러스터 상태가 **활성**으로 돌아갈 때까지 기다립니다.
## 기존 클러스터에서 하이브리드 노드 비활성화
다음을 사용하여 기존 클러스터에서 EKS Hybrid Nodes를 비활성화할 수 있습니다.
+ [AWS CloudFormation](#hybrid-nodes-cluster-disable-cfn)
+ [AWS CLI](#hybrid-nodes-cluster-disable-cli)
+ [AWS Management Console](#hybrid-nodes-cluster-disable-console)
### 기존 클러스터에서 EKS Hybrid Nodes 비활성화 - AWS CloudFormation
1. 클러스터에서 EKS Hybrid Nodes를 비활성화하려면 CloudFormation 템플릿에서 `RemoteNodeNetworks`와 `RemotePodNetworks`를 빈 어레이로 설정하고 스택을 업데이트합니다.
```
RemoteNetworkConfig:
RemoteNodeNetworks: []
RemotePodNetworks: []
```
### 기존 클러스터에서 EKS Hybrid Nodes 비활성화 - AWS CLI
1. 다음 명령을 실행하여 EKS 클러스터에서 `RemoteNetworkConfig`를 제거합니다. 명령을 실행하기 전에 다음을 실제 설정으로 바꿉니다. 전체 설정 목록은 *Amazon EKS API 참조*의 [UpdateClusterConfig](https://docs.aws.amazon.com/eks/latest/APIReference/API_UpdateClusterConfig.html)를 참조하세요.
1. `CLUSTER_NAME`: 업데이트할 EKS 클러스터의 이름입니다.
1. `AWS_REGION`: EKS 클러스터가 실행 중인 AWS 리전입니다.
```
aws eks update-cluster-config \
--name CLUSTER_NAME \
--region AWS_REGION \
--remote-network-config '{"remoteNodeNetworks":[],"remotePodNetworks":[]}'
```
1. 클러스터를 업데이트하는 데 몇 분 정도 걸립니다. 다음 명령을 사용하여 클러스터의 상태를 쿼리할 수 있습니다. `CLUSTER_NAME`을 수정 중인 클러스터의 이름으로 바꾸고 `AWS_REGION`을 클러스터가 실행되고 있는 AWS 리전으로 바꿉니다. 반환되는 출력이 `ACTIVE`가 되면 다음 단계로 진행하세요.
```
aws eks describe-cluster \
--name CLUSTER_NAME \
--region AWS_REGION \
--query "cluster.status"
```
### 기존 클러스터에서 EKS Hybrid Nodes 비활성화 - AWS Management Console
1. [Amazon EKS 콘솔](https://console.aws.amazon.com/eks/home#/clusters)에서 Amazon EKS 콘솔을 엽니다.
1. 클러스터 이름을 선택하여 클러스터 정보를 표시합니다.
1. **네트워킹** 탭을 선택하고 **관리**를 선택합니다.
1. 드롭다운에서 **원격 네트워크**를 선택합니다.
1. `Remote node networks` 및 `Remote pod networks - Optional`에서 **하이브리드 노드를 사용하도록 원격 네트워크 구성**을 선택하고 모든 CIDR을 제거합니다.
1. **변경 사항 저장**을 선택하여 종료합니다. 클러스터가 **활성** 상태로 돌아갈 때까지 기다립니다.
# 하이브리드 노드에 대한 클러스터 액세스 준비
하이브리드 노드를 Amazon EKS 클러스터에 연결하기 전에 Kubernetes 권한이 있는 하이브리드 노드 IAM 역할을 활성화하여 클러스터에 조인해야 합니다. 하이브리드 노드 IAM 역할 생성 방법에 대한 자세한 내용은 [하이브리드 노드에 대한 자격 증명 준비](hybrid-nodes-creds.md) 섹션을 참조하세요. Amazon EKS는 IAM 보안 주체를 Kubernetes 역할 기반 액세스 제어(RBAC), Amazon EKS 액세스 항목, `aws-auth` ConfigMap과 연결하는 두 가지 방법을 지원합니다. Amazon EKS 액세스 관리에 대한 자세한 내용은 [IAM 사용자 및 역할에 Kubernetes API에 대한 액세스 권한 부여](grant-k8s-access.md) 섹션을 참조하세요.
아래 절차에 따라 하이브리드 노드 IAM 역할을 Kubernetes 권한과 연결합니다. Amazon EKS 액세스 항목을 사용하려면 클러스터가 `API` 또는 `API_AND_CONFIG_MAP` 인증 모드로 생성되어야 합니다. `aws-auth` ConfigMap을 사용하려면 클러스터가 `API_AND_CONFIG_MAP` 인증 모드로 생성되어야 합니다. 하이브리드 노드 지원 Amazon EKS 클러스터에는 `CONFIG_MAP` 전용 인증 모드가 지원되지 않습니다.
## 하이브리드 노드 IAM 역할에 Amazon EKS 액세스 항목 사용
IAM 역할과 함께 사용할 수 있는 하이브리드 노드의 Amazon EKS 액세스 항목 유형인 HYBRID\$1LINUX가 있습니다. 이 액세스 항목 유형에서는 사용자 이름이 system:node:\$1\$1SessionName\$1\$1으로 자동 설정됩니다. 액세스 항목 생성에 대한 자세한 내용은 [액세스 항목 생성](creating-access-entries.md) 섹션을 참조하세요.
### AWS CLI
1. 장치에 최신 버전의 AWS CLI가 설치 및 구성되어 있어야 합니다. 현재 버전을 확인하려면 `aws --version`을 사용합니다. yum, apt-get 또는 macOS용 Homebrew와 같은 패키지 관리자는 최신 버전 AWS CLI 이전에 나온 버전이 몇 가지 있을 때도 있습니다. 최신 버전을 설치하려면 AWS 명령줄 인터페이스 사용 설명서에서 설치 및 aws config를 사용하여 빠른 구성을 참조하세요.
1. 다음 명령을 사용하여 액세스 항목을 생성합니다. CLUSTER\$1NAME을 클러스터 이름으로 바꾸고 HYBRID\$1NODES\$1ROLE\$1ARN을 [하이브리드 노드에 대한 자격 증명 준비](hybrid-nodes-creds.md)의 단계에서 생성한 역할의 ARN으로 바꿉니다.
```
aws eks create-access-entry --cluster-name CLUSTER_NAME \
--principal-arn HYBRID_NODES_ROLE_ARN \
--type HYBRID_LINUX
```
### AWS Management Console
1. [Amazon EKS 콘솔](https://console.aws.amazon.com/eks/home#/clusters)에서 Amazon EKS 콘솔을 엽니다.
1. 하이브리드 노드 지원 클러스터의 이름을 선택합니다.
1. **액세스** 탭을 선택합니다.
1. **액세스 항목 생성**을 선택합니다.
1. **IAM 보안 주체**의 경우 [하이브리드 노드에 대한 자격 증명 준비](hybrid-nodes-creds.md)의 단계에서 생성한 하이브리드 노드 IAM 역할을 선택합니다.
1. **유형**에서 **하이브리드 Linux**를 선택합니다.
1. (선택사항) **태그**에서 액세스 항목에 레이블을 할당합니다. 예를 들어, 태그가 동일한 모든 리소스를 더 쉽게 찾을 수 있습니다.
1. **검토 및 생성 건너뛰기**를 선택합니다. 하이브리드 Linux 액세스 항목에 정책을 추가하거나 액세스 범위를 변경할 수 없습니다.
1. 액세스 항목의 구성을 검토합니다. 문제가 있는 것 같으면 **이전**을 선택하여 이전 단계로 돌아가서 오류를 수정합니다. 구성이 올바르면 **생성**을 선택합니다.
## 하이브리드 노드 IAM 역할에 aws-auth ConfigMap 사용
다음 단계에서는 [하이브리드 노드에 대한 자격 증명 준비](hybrid-nodes-creds.md)의 단계에서 생성한 하이브리드 노드 IAM 역할의 ARN으로 `aws-auth` ConfigMap을 생성하거나 업데이트합니다.
1. 클러스터에 대한 기존 `aws-auth` ConfigMap이 있는지 확인합니다. 특정 `kubeconfig` 파일을 사용하는 경우 `--kubeconfig` 플래그를 사용합니다.
```
kubectl describe configmap -n kube-system aws-auth
```
1. `aws-auth` ConfigMap이 표시되면 필요에 따라 이를 업데이트합니다.
1. 편집을 위해 ConfigMap을 엽니다.
```
kubectl edit -n kube-system configmap/aws-auth
```
1. 필요에 따라 새 `mapRoles` 항목을 추가합니다. `HYBRID_NODES_ROLE_ARN`을 하이브리드 노드 IAM 역할의 ARN으로 바꿉니다. 참고로 `{{SessionName}}`은 ConfigMap에 저장할 올바른 템플릿 형식입니다. 다른 값으로 바꾸지 마세요.
```
data:
mapRoles: |
- groups:
- system:bootstrappers
- system:nodes
rolearn: HYBRID_NODES_ROLE_ARN
username: system:node:{{SessionName}}
```
1. 파일을 저장하고 텍스트 편집기를 종료합니다.
1. 클러스터에 대한 기존 `aws-auth` ConfigMap이 없는 경우 다음 명령을 사용하여 생성합니다. `HYBRID_NODES_ROLE_ARN`을 하이브리드 노드 IAM 역할의 ARN으로 바꿉니다. `{{SessionName}}`은 ConfigMap에 저장할 올바른 템플릿 형식입니다. 다른 값으로 바꾸지 마세요.
```
kubectl apply -f=/dev/stdin <<-EOF
apiVersion: v1
kind: ConfigMap
metadata:
name: aws-auth
namespace: kube-system
data:
mapRoles: |
- groups:
- system:bootstrappers
- system:nodes
rolearn: HYBRID_NODES_ROLE_ARN
username: system:node:{{SessionName}}
EOF
```