AWS Outposts에 Amazon EKS 클러스터 배포하기

이 주제에서는 Outpost에서 로컬 클러스터를 실행할 때 고려할 사항에 대한 개요를 제공해요. 또한 Outpost에 로컬 클러스터를 배포하는 방법에 대한 지침도 제공합니다.

중요: 이러한 고려 사항은 관련 Amazon EKS 설명서에 반영되어 있지 않습니다. 다른 Amazon EKS 설명서 주제가 여기의 고려 사항과 충돌한다면 여기의 고려 사항을 따르세요.

이 고려 사항은 변경될 수 있고 자주 변경될 수 있어요. 따라서 이 주제를 정기적으로 검토하는 것이 좋습니다.

출처: 문서

본문

많은 고려 사항이 AWS Cloud에서 클러스터를 생성할 때의 고려 사항과 다릅니다.

로컬 클러스터는 Outpost 랙만 지원합니다. 단일 로컬 클러스터는 단일 논리적 Outpost를 구성하는 여러 물리적 Outpost 랙에 걸쳐 실행될 수 있어요. 단일 로컬 클러스터는 여러 논리적 Outposts에 걸쳐 실행될 수 없습니다. 각 논리적 Outpost에는 단일 Outpost ARN이 있습니다.
로컬 클러스터는 Outpost의 계정에서 Kubernetes 제어 플레인을 실행하고 관리합니다. Kubernetes 제어 플레인 인스턴스에서 워크로드를 실행하거나 Kubernetes 제어 플레인 구성 요소를 수정할 수 없어요. 이러한 노드는 Amazon EKS 서비스가 관리합니다. Kubernetes 제어 플레인에 대한 변경 사항은 패칭 같은 자동 Amazon EKS 관리 작업을 통해 지속되지 않습니다.
로컬 클러스터는 자체 관리형 애드온과 자체 관리형 Amazon Linux 노드 그룹을 지원합니다. Kubernetes용 Amazon VPC CNI 플러그인, kube-proxy, CoreDNS 애드온은 로컬 클러스터에 자동으로 설치됩니다.
로컬 클러스터는 Outposts에서 Amazon EBS를 사용해야 합니다. Outpost에는 Kubernetes 제어 플레인 스토리지용 Amazon EBS가 있어야 해요. Outposts는 Amazon EBS gp2 볼륨만 지원합니다.
Amazon EBS가 지원하는 Kubernetes PersistentVolumes는 Amazon EBS CSI 드라이버를 사용해 지원됩니다.
로컬 클러스터의 제어 플레인 인스턴스는 stacked 고가용성 토폴로지로 설정됩니다. 쿼럼을 유지하려면 3개의 제어 플레인 인스턴스 중 2개가 항상 정상이어야 해요. 쿼럼이 손실되면 AWS 지원에 문의하세요. 새 관리형 인스턴스를 활성화하려면 일부 서비스 측 작업이 필요할 수 있습니다.

사전 조건

Outposts 배포 옵션, 용량 고려 사항에 따라 AWS Outposts의 Amazon EKS 클러스터용 인스턴스 유형 및 배치 그룹 선택, VPC 요구 사항 및 고려 사항에 익숙해야 합니다.
기존 Outpost가 있어야 합니다. 자세한 내용은 AWS Outposts란 무엇인가요?를 참고하세요.
컴퓨터 또는 AWS CloudShell에 kubectl 명령줄 도구가 설치되어 있어야 합니다. 버전은 클러스터의 Kubernetes 버전과 같거나 최대 한 마이너 버전 이전 또는 이후일 수 있어요. 예를 들어 클러스터 버전이 1.29라면 kubectl 버전 1.28, 1.29 또는 1.30을 사용할 수 있습니다. kubectl을 설치하거나 업그레이드하려면 kubectl 및 eksctl 설정을 참고하세요.
디바이스 또는 AWS CloudShell에 AWS Command Line Interface(AWS CLI) 버전 2.12.3 이상 또는 버전 1.27.160 이상이 설치되고 구성되어 있어야 합니다. 현재 버전을 확인하려면 aws --version | cut -d / -f2 | cut -d ' ' -f1을 사용하세요. yum, apt-get, macOS용 Homebrew 같은 패키지 관리자는 종종 최신 AWS CLI 버전보다 몇 버전 뒤처집니다. 최신 버전을 설치하려면 AWS Command Line Interface 사용 설명서의 설치 및 aws configure로 빠른 구성을 참고하세요. AWS CloudShell에 설치된 AWS CLI 버전도 최신 버전보다 몇 버전 뒤처질 수 있습니다. 업데이트하려면 AWS CloudShell 사용 설명서의 홈 디렉토리에 AWS CLI 설치를 참고하세요.
Amazon EKS 클러스터를 create하고 describe할 수 있는 권한이 있는 IAM 보안 주체(사용자 또는 역할)여야 합니다. 자세한 내용은 Outpost에 로컬 Kubernetes 클러스터 생성 및 모든 클러스터 나열 또는 설명을 참고하세요.
로컬 Amazon EKS 클러스터가 생성되면 클러스터를 생성한 IAM 보안 주체가 영구적으로 추가됩니다. 이 보안 주체는 특히 Kubernetes RBAC 권한 부여 테이블에 관리자로 추가됩니다. 이 엔터티는 system:masters 권한을 가져요. 이 엔터티의 자격 증명은 클러스터 구성에 표시되지 않습니다. 따라서 클러스터를 생성한 엔터티를 기록해 두고 절대 삭제하지 않아야 합니다. 처음에는 서버를 생성한 보안 주체만 kubectl을 사용해 Kubernetes API 서버에 호출할 수 있어요. 콘솔을 사용해 클러스터를 생성한다면 클러스터에서 kubectl 명령을 실행할 때 동일한 IAM 자격 증명이 AWS SDK 자격 증명 체인에 있는지 확인하세요. 클러스터가 생성된 후에는 다른 IAM 보안 주체에 클러스터 액세스 권한을 부여할 수 있습니다.

Amazon EKS 로컬 클러스터 생성

이 페이지에 설명된 다음 도구로 로컬 클러스터를 생성할 수 있어요.

eksctl
AWS Management Console

AWS CLI, Amazon EKS API, AWS SDK, AWS CloudFormation 또는 Terraform을 사용해 Outposts에 클러스터를 생성할 수도 있습니다.

eksctl로 로컬 클러스터 생성

디바이스 또는 AWS CloudShell에 eksctl 명령줄 도구 버전 0.215.0 이상을 설치합니다. eksctl을 설치하거나 업데이트하려면 eksctl 설명서의 설치를 참고하세요.
다음 내용을 디바이스에 복사합니다. 다음 값을 바꾸고 수정된 명령을 실행해 outpost-control-plane.yaml 파일을 생성합니다.
- region-code를 클러스터를 생성하려는 지원되는 AWS 리전으로 바꿉니다.
- my-cluster를 클러스터 이름으로 바꿉니다. 이름에는 영숫자 문자(대소문자 구분)와 하이픈만 포함할 수 있어요. 영숫자 문자로 시작해야 하며 100자보다 길 수 없습니다. 이름은 클러스터를 생성하는 AWS 리전과 AWS 계정 내에서 고유해야 합니다.
- vpc-ExampleID1과 subnet-ExampleID1을 기존 VPC와 서브넷의 ID로 바꿉니다. VPC와 서브넷은 AWS Outposts의 Amazon EKS 클러스터용 VPC 및 서브넷 생성의 요구 사항을 충족해야 합니다.
- uniqueid를 Outpost의 ID로 바꿉니다.
- m5.large를 Outpost에서 사용할 수 있는 인스턴스 유형으로 바꿉니다. 인스턴스 유형을 선택하기 전에 용량 고려 사항에 따라 AWS Outposts의 Amazon EKS 클러스터용 인스턴스 유형 및 배치 그룹 선택을 참고하세요. 제어 플레인 인스턴스 3개가 배포됩니다. 이 수는 변경할 수 없습니다.

cat >outpost-control-plane.yaml <<EOF
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
  name: my-cluster
  region: region-code
outpost:
  controlPlanePlacement:
    groupName: uniqueid
  instanceType: m5.large
vpc:
  subnets:
    - id: subnet-ExampleID1
      outpostArn: arn:aws:outposts:region-code:111122223333:outpost/uniqueid
EOF

AWS Outposts 지원 및 구성 파일 스키마에 대한 자세한 내용은 eksctl 설명서를 참고하세요.

이전 단계에서 만든 구성 파일을 사용해 클러스터를 생성합니다. eksctl은 클러스터를 배포하기 위해 Outpost에 VPC와 하나의 서브넷을 생성해요.

eksctl create cluster -f outpost-control-plane.yaml

클러스터 프로비저닝에는 몇 분이 걸립니다. 클러스터가 생성되는 동안 여러 줄의 출력이 나타납니다. 마지막 출력 줄은 다음 예시 줄과 유사합니다.

[✓]  EKS cluster "my-cluster" in "region-code" region is ready

팁: eksctl로 클러스터를 생성할 때 지정할 수 있는 대부분의 옵션을 보려면 eksctl create cluster --help 명령을 사용하세요. 사용 가능한 모든 옵션을 보려면 config 파일을 사용할 수 있어요. 자세한 내용은 eksctl 설명서의 구성 파일 사용 및 구성 파일 스키마를 참고하세요. GitHub에서 구성 파일 예시를 찾을 수 있습니다.

eksctl 명령은 클러스터를 생성한 IAM 보안 주체(사용자 또는 역할)에 대한 액세스 항목을 자동으로 생성하고 해당 IAM 보안 주체에 클러스터의 Kubernetes 개체에 대한 관리자 권한을 부여해요. 클러스터 생성자가 클러스터의 Kubernetes 개체에 대한 관리자 액세스를 갖기를 원하지 않는다면 이전 구성 파일에 bootstrapClusterCreatorAdminPermissions: false(metadata, vpc, outpost와 동일한 수준) 텍스트를 추가하세요. 이 옵션을 추가했다면 클러스터 생성 후 최소 하나의 IAM 보안 주체에 대한 액세스 항목을 생성해야 하며, 그렇지 않으면 어떤 IAM 보안 주체도 클러스터의 Kubernetes 개체에 액세스할 수 없습니다.

AWS Management Console로 클러스터 생성

Amazon EKS 요구 사항을 충족하는 기존 VPC와 서브넷이 필요합니다. 자세한 내용은 AWS Outposts의 Amazon EKS 클러스터용 VPC 및 서브넷 생성을 참고하세요.

이미 로컬 클러스터 IAM 역할이 있거나 eksctl로 클러스터를 생성할 예정이라면 이 단계를 건너뛸 수 있어요. 기본적으로 eksctl은 역할을 생성해 줍니다.

다음 명령을 실행해 IAM 신뢰 정책 JSON 파일을 생성합니다.

{
  "Version":"2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "ec2.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

Amazon EKS 클러스터 IAM 역할을 생성합니다. IAM 역할을 생성하려면 역할을 생성하는 IAM 보안 주체에 iam:CreateRole 작업(권한)이 할당되어야 해요.

aws iam create-role --role-name myAmazonEKSLocalClusterRole --assume-role-policy-document file://"eks-local-cluster-role-trust-policy.json"

AmazonEKSLocalOutpostClusterPolicy라는 Amazon EKS 관리형 정책을 역할에 연결합니다. IAM 정책을 IAM 보안 주체에 연결하려면 정책을 연결하는 보안 주체에 다음 IAM 작업(권한) 중 하나가 할당되어야 합니다: iam:AttachUserPolicy 또는 iam:AttachRolePolicy.

aws iam attach-role-policy --policy-arn arn:aws:iam::aws:policy/AmazonEKSLocalOutpostClusterPolicy --role-name myAmazonEKSLocalClusterRole

Amazon EKS 콘솔을 엽니다.
콘솔 화면 상단에서 지원되는 AWS 리전을 선택했는지 확인합니다.
클러스터 추가(Add cluster)를 선택한 다음 생성(Create)을 선택합니다.
클러스터 구성(Configure cluster) 페이지에서 다음 필드에 값을 입력하거나 선택합니다.
- Kubernetes control plane location — AWS Outposts를 선택합니다.
- Outpost ID — 제어 플레인을 생성할 Outpost의 ID를 선택합니다.
- Instance type — 인스턴스 유형을 선택합니다. Outpost에서 사용할 수 있는 인스턴스 유형만 표시됩니다. 드롭다운 목록에서 각 인스턴스 유형은 해당 인스턴스 유형이 권장되는 노드 수를 설명해요. 인스턴스 유형을 선택하기 전에 용량 고려 사항에 따라 AWS Outposts의 Amazon EKS 클러스터용 인스턴스 유형 및 배치 그룹 선택을 참고하세요. 모든 복제본이 동일한 인스턴스 유형으로 배포됩니다. 클러스터가 생성된 후에는 인스턴스 유형을 변경할 수 없어요. 제어 플레인 인스턴스 3개가 배포됩니다. 이 수는 변경할 수 없습니다.
- Name — 클러스터 이름입니다. AWS 계정에서 고유해야 해요. 이름에는 영숫자 문자(대소문자 구분)와 하이픈만 포함할 수 있습니다. 영숫자 문자로 시작해야 하며 100자보다 길 수 없어요. 이름은 클러스터를 생성하는 AWS 리전과 AWS 계정 내에서 고유해야 합니다.
- Kubernetes version — 클러스터에 사용할 Kubernetes 버전을 선택합니다. 이전 버전을 사용해야 하는 경우가 아니라면 최신 버전을 선택하는 것이 좋습니다.
- Cluster service role — 이전 단계에서 생성한 Amazon EKS 클러스터 IAM 역할을 선택해 Kubernetes 제어 플레인이 AWS 리소스를 관리할 수 있게 합니다.
- Kubernetes cluster administrator access — 클러스터를 생성하는 IAM 보안 주체(역할 또는 사용자)가 클러스터의 Kubernetes 개체에 대한 관리자 액세스 권한을 갖도록 하려면 기본값(허용)을 수락하세요. Amazon EKS는 IAM 보안 주체에 대한 액세스 항목을 생성하고 액세스 항목에 클러스터 관리자 권한을 부여해요. 액세스 항목에 대한 자세한 내용은 EKS 액세스 항목으로 IAM 사용자에게 Kubernetes 액세스 권한 부여를 참고하세요.
클러스터를 생성하는 보안 주체가 아닌 다른 IAM 보안 주체가 Kubernetes 클러스터 개체에 대한 관리자 액세스를 갖도록 하려면 허용 안 함(disallow) 옵션을 선택하세요. 클러스터 생성 후 액세스 항목을 생성할 IAM 권한이 있는 모든 IAM 보안 주체는 Kubernetes 클러스터 개체에 액세스해야 하는 모든 IAM 보안 주체에 대한 액세스 항목을 추가할 수 있어요. 필요한 IAM 권한에 대한 자세한 내용은 서비스 권한 부여 참조의 Amazon Elastic Kubernetes Service에서 정의한 작업을 참고하세요. 허용 안 함 옵션을 선택하고 액세스 항목을 생성하지 않으면 어떤 IAM 보안 주체도 클러스터의 Kubernetes 개체에 액세스할 수 없습니다.
- Tags — (선택 사항) 클러스터에 태그를 추가합니다. 자세한 내용은 태그로 Amazon EKS 리소스 구성을 참고하세요. 이 페이지를 완료하면 다음(Next)을 선택합니다.
네트워킹 지정(Specify networking) 페이지에서 다음 필드에 값을 선택합니다.
- VPC — 기존 VPC를 선택합니다. VPC에는 클러스터, 모든 노드, 생성하려는 기타 Kubernetes 리소스에 사용할 수 있는 충분한 수의 IP 주소가 있어야 해요. VPC는 VPC 요구 사항 및 고려 사항의 요구 사항을 충족해야 합니다.
- Subnets — 기본적으로 이전 필드에서 지정한 VPC의 모든 사용 가능한 서브넷이 미리 선택됩니다. 선택한 서브넷은 서브넷 요구 사항 및 고려 사항의 요구 사항을 충족해야 해요.
- Security groups — (선택 사항) Amazon EKS가 생성하는 네트워크 인터페이스에 연결하려는 보안 그룹을 하나 이상 지정합니다. Amazon EKS는 클러스터와 VPC 간의 통신을 활성화하는 보안 그룹을 자동으로 생성해요. Amazon EKS는 이 보안 그룹과 선택한 모든 보안 그룹을 생성하는 네트워크 인터페이스에 연결합니다. Amazon EKS가 생성하는 클러스터 보안 그룹에 대한 자세한 내용은 클러스터용 Amazon EKS 보안 그룹 요구 사항 보기를 참고하세요. Amazon EKS가 생성하는 클러스터 보안 그룹의 규칙을 수정할 수 있어요. 자신의 보안 그룹을 추가하기로 선택하면 클러스터 생성 후 선택한 보안 그룹을 변경할 수 없습니다. 온프레미스 호스트가 클러스터 엔드포인트와 통신하려면 클러스터 보안 그룹에서 인바운드 트래픽을 허용해야 합니다. 인그레스 및 이그레스 인터넷 연결이 없는 클러스터(프라이빗 클러스터라고도 함)의 경우 다음 중 하나를 수행해야 해요.
  - 필요한 VPC 엔드포인트와 연결된 보안 그룹을 추가합니다. 필요한 엔드포인트에 대한 자세한 내용은 AWS 서비스에 대한 서브넷 액세스의 인터페이스 VPC 엔드포인트 사용을 참고하세요.
  - Amazon EKS가 생성한 보안 그룹을 수정해 VPC 엔드포인트와 연결된 보안 그룹의 트래픽을 허용합니다. 이 페이지를 완료하면 다음(Next)을 선택합니다.
관측성 구성(Configure observability) 페이지에서 켤 메트릭 및 제어 플레인 로깅 옵션을 선택적으로 선택할 수 있어요. 기본적으로 각 로그 유형은 꺼져 있습니다.
- Prometheus 메트릭 옵션에 대한 자세한 내용은 1단계: Prometheus 메트릭 켜기를 참고하세요.
- 제어 플레인 로깅 옵션에 대한 자세한 내용은 제어 플레인 로그를 CloudWatch Logs로 보내기를 참고하세요. 이 페이지를 완료하면 다음(Next)을 선택합니다.
검토 및 생성(Review and create) 페이지에서 이전 페이지에서 입력하거나 선택한 정보를 검토합니다. 변경해야 한다면 편집(Edit)을 선택하세요. 만족하면 생성(Create)을 선택합니다. 클러스터가 프로비저닝되는 동안 상태(Status) 필드에 CREATING이 표시됩니다.

클러스터 프로비저닝에는 몇 분이 걸립니다.

Amazon EKS 로컬 클러스터 보기

클러스터가 생성된 후 생성된 Amazon EC2 제어 플레인 인스턴스를 볼 수 있어요.

aws ec2 describe-instances --query 'Reservations[*].Instances[*].{Name:Tags[?Key==`Name`]|[0].Value}' | grep my-cluster-control-plane

출력 예시는 다음과 같습니다.

"Name": "my-cluster-control-plane-id1"
"Name": "my-cluster-control-plane-id2"
"Name": "my-cluster-control-plane-id3"

각 인스턴스에는 워크로드가 제어 플레인 인스턴스에 예약되지 않도록 node-role.eks-local.amazonaws.com/control-plane 테인트가 적용됩니다. 테인트에 대한 자세한 내용은 Kubernetes 설명서의 테인트 및 톨러레이션을 참고하세요. Amazon EKS는 로컬 클러스터의 상태를 지속적으로 모니터링합니다. 보안 패치와 비정상 인스턴스 복구 같은 자동 관리 작업을 수행해요. 로컬 클러스터가 클라우드에서 연결이 끊기면 재연결 시 클러스터가 정상 상태로 복구되도록 작업을 완료합니다.

eksctl로 클러스터를 생성했다면 이 단계를 건너뛸 수 있어요. eksctl이 이 단계를 대신 완료합니다. kubectl config 파일에 새 컨텍스트를 추가해 kubectl이 클러스터와 통신할 수 있게 합니다. 파일을 생성하고 업데이트하는 방법에 대한 지침은 kubeconfig 파일을 생성해 kubectl을 EKS 클러스터에 연결을 참고하세요.

aws eks update-kubeconfig --region region-code --name my-cluster

출력 예시는 다음과 같습니다.

Added new context arn:aws:eks:region-code:111122223333:cluster/my-cluster to /home/username/.kube/config

로컬 클러스터의 Kubernetes API 서버에 연결하려면 서브넷의 로컬 게이트웨이에 액세스하거나 VPC 내에서 연결해야 해요. Outpost 랙을 온프레미스 네트워크에 연결하는 방법에 대한 자세한 내용은 AWS Outposts 사용 설명서의 랙용 로컬 게이트웨이 작동 방식을 참고하세요. Direct VPC Routing을 사용하고 Outpost 서브넷에 로컬 게이트웨이로 가는 경로가 있다면 Kubernetes 제어 플레인 인스턴스의 프라이빗 IP 주소가 로컬 네트워크에서 자동으로 브로드캐스트됩니다. 로컬 클러스터의 Kubernetes API 서버 엔드포인트는 Amazon Route 53(Route 53)에 호스팅됩니다. API 서비스 엔드포인트는 퍼블릭 DNS 서버가 Kubernetes API 서버의 프라이빗 IP 주소로 확인할 수 있어요.

로컬 클러스터의 Kubernetes 제어 플레인 인스턴스는 클러스터 수명 주기 동안 변경되지 않는 고정 프라이빗 IP 주소를 가진 정적 탄력적 네트워크 인터페이스로 구성됩니다. Kubernetes API 서버와 상호 작용하는 시스템은 네트워크 단절 중에 Route 53에 연결되지 않을 수 있어요. 이 경우 지속적인 운영을 위해 정적 프라이빗 IP 주소로 /etc/hosts를 구성하는 것이 좋습니다. 또한 로컬 DNS 서버를 설정하고 Outpost에 연결하는 것도 권장합니다. 자세한 내용은 AWS Outposts 설명서를 참고하세요. 클러스터와 통신이 설정되었는지 확인하려면 다음 명령을 실행합니다.

kubectl get svc

출력 예시는 다음과 같습니다.

NAME         TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
kubernetes   ClusterIP   10.100.0.1           443/TCP   28h

(선택 사항) AWS Cloud와 단절된 상태일 때 로컬 클러스터에 대한 인증을 테스트합니다. 지침은 네트워크 단절을 위해 AWS Outposts 로컬 Amazon EKS 클러스터 준비를 참고하세요.

내부 리소스

Amazon EKS는 클러스터에 다음 리소스를 생성합니다. 이 리소스는 Amazon EKS 내부용입니다. 클러스터가 제대로 작동하려면 이러한 리소스를 편집하거나 수정하지 마세요.

다음 미러 Pod:

aws-iam-authenticator-node-hostname
eks-certificates-controller-node-hostname
etcd-node-hostname
kube-apiserver-node-hostname
kube-controller-manager-node-hostname
kube-scheduler-node-hostname

다음 자체 관리형 애드온:

kube-system/coredns
kube-system/
kube-proxy(첫 노드를 추가할 때까지 생성되지 않음)
kube-system/aws-node(첫 노드를 추가할 때까지 생성되지 않음). 로컬 클러스터는 클러스터 네트워킹에 Kubernetes용 Amazon VPC CNI 플러그인을 사용합니다. 제어 플레인 인스턴스(aws-node-controlplane-*라는 Pod)의 구성을 변경하지 마세요. 플러그인이 새 네트워크 인터페이스를 생성하는 시기의 기본값을 변경하는 데 사용할 수 있는 구성 변수가 있습니다. 자세한 내용은 GitHub의 설명서를 참고하세요.

다음 서비스:

default/kubernetes
kube-system/kube-dns

eks.system이라는 PodSecurityPolicy

eks:system:podsecuritypolicy라는 ClusterRole

eks:system이라는 ClusterRoleBinding

클러스터 보안 그룹에 추가로 Amazon EKS는 eks-local-internal-do-not-use-or-edit-cluster-name-uniqueid라는 이름의 보안 그룹을 AWS 계정에 생성합니다. 이 보안 그룹은 제어 플레인 인스턴스에서 실행되는 Kubernetes 구성 요소 간에 트래픽이 자유롭게 흐를 수 있게 합니다.

권장되는 다음 단계

클러스터를 생성한 IAM 보안 주체에 AWS Management Console에서 Kubernetes 리소스를 볼 수 있는 필수 권한을 부여합니다.
IAM 엔터티에 클러스터 액세스 권한을 부여합니다. 엔터티가 Amazon EKS 콘솔에서 Kubernetes 리소스를 보도록 하려면 엔터티에 필수 권한을 부여하세요.
클러스터에 대한 로깅을 구성합니다.
네트워크 단절 중에 발생하는 상황을 숙지합니다.
클러스터에 노드를 추가합니다.
etcd에 대한 백업 계획을 설정하는 것을 고려합니다. Amazon EKS는 로컬 클러스터의 etcd 자동 백업 및 복원을 지원하지 않아요. 자세한 내용은 Kubernetes 설명서의 etcd 클러스터 백업을 참고하세요. 두 가지 주요 옵션은 etcdctl을 사용해 스냅샷 생성을 자동화하거나 Amazon EBS 스토리지 볼륨 백업을 사용하는 것입니다.

더 알아보기 (Learn more)

공식 문서