이번에는 EKS
를 활용해 Wordpress
를 배포하고 모니터링 환경을 구축하는 실습을 진행하겠습니다.
EKS
와 Kubernetes
에 대해 잘 모르시는 분들께서는 이 글들을 참고해 주세요.
또, 이 실습을 진행하기 전에 RDS
와 EFS
의 사용법을 알아둘 필요가 있습니다.
- AWS EKS
- Wordpress + MariaDB
- Wordpress의 저장소로 EFS 사용
- MariaDB는 RDS로 생성
- Grafana + Prometheus
EKS
를 통해 Kubernetes
환경에 Wordpress 애플리케이션을 배포하겠습니다.
배포한 뒤, Grafana
와 Prometheus
를 배포해 모니터링을 수행하겠습니다.
먼저 EKS Cluster
를 구축할 네트워크를 구성하겠습니다.
VPC : 10.0.0.0/16
bastion-Subnet : 10.0.0.0/24
EKS-Subnet-01 : 10.0.2.0/24
EKS-Subnet-02 : 10.0.3.0/24
VPC
와 Subnet
의 CIDR은 위와 같습니다.
EKS-VPC라는 이름의 VPC
를 생성하였습니다.
다음으로 3개의 Subnet
을 구성하겠습니다.
Bastion Subnet
은 EKS
에 접근하기 위한 bastion server
를 위해 생성해주었습니다.
EKS Cluster
에 접근하는 것은 동일한 VPC
내부에 bastion server
를 통해서만 가능하도록 할 예정입니다.
이제 라우팅 테이블을 설정하겠습니다.
bastion server
가 존재하는 Bastion Subnet
은 Public Subnet
이며 외부로 향하는 트래픽은 Internet Gateway
를 통해 밖으로 나갑니다.
EKS
의 Worker Node
들이 생성될 EKS-Subnet
들은 Private Subnet
입니다.
같은 VPC
에서 로컬 통신은 가능하지만, 외부에서 직접 접근은 불가능하며 외부로 나갈때는 NAT Gateway
를 통해 밖으로 나갑니다.
다음은 보안그룹
(Security Group
, 이하 SG
)을 구성하겠습니다.
2개의 보안그룹
을 생성하겠습니다.
- 로컬 환경에서
bastion server
에 ssh 접근을 위한보안그룹
bastion server
에서EKS Cluster
에 접근하기 위한보안그룹
먼저 로컬 환경에서 bastion server
에 ssh로 접근할 수 있도록 보안그룹
을 생성하겠습니다.
보안그룹
의 이름은 Bastion SG
로 하겠습니다.
bastion server
는 EKS
에 접근할 수 있기 때문에 보안을 위해 접근제어 정책을 적용해야 합니다.
현재 작업을 진행하고 있는 환경에서만 접근이 가능하도록 소스를 내 IP로 설정해 SSH 연결에 대한 정책을 적용해 줍니다.
다음은 bastion server
에서 EKS Cluster
에 명령을 내리기 위해 필요한 포트에 대해 정의하겠습니다.
AWS 백서를 보면 필요한 포트에 대한 정보가 정의되어 있습니다.
443/TCP
, 10250/TCP
, 53/TCP
, 53/UDP
에 대한 룰이 필요합니다.
EKS
의 특징과 Kubernetes
의 컴포넌트에 대한 이해가 있으신 분들은 눈치채셨을지도 모르지만, 443/TCP
는 kube-api-server
컴포넌트가 동작할 때 사용하는 포트입니다.
보안그룹
의 이름은 Bastion-EKS-SG
로 하고 위에서 정의한 포트에 대해 룰을 생성했습니다.
소스에 입력된 보안그룹
은 bastion server
에 적용할 Bastion-SG
입니다.
AWS
의 어떤 서비스를 사용하던, 가장 먼저 해야할 일은 권한에 대한 설정입니다.
먼저, IAM
에서 역할을 만들어 줍시다.
EKS
에서는 크게 두 가지 역할이 필요합니다.
EKS Cluster
와 EKS WorkerNode
가 가져야 하는 역할입니다.
eks-cluster-role
- AmazonEKSClusterPolicy
- AmazonEKSServicePolicy
eks-worker-role
- AmazonEKSWorkerNodePolicy
- AmazonEC2ContainerRegistryReadOnly
- CloudWatchLogsFullAccess
- AmazonEKS_CNI_Policy
- AmazonRoute53FullAccess
- AmazonElasticFileSystemFullAccess
eks-cluster-role
과 eks-worker-role
이라는 두 역할을 만들고, 위에 나열된 정책들을 적용시켜 줍니다.
이제 EKS Cluster
생성하고 명령을 전달할 EC2
bastion 서버를 생성해 주겠습니다.
스펙은 아래와 같습니다.
bastion EC2
- Type : t2.micro
- OS : Amazon Linux 2
- Disk : 8GB
- Subnet : bation Subnet
EC2
서버가 생성되면 putty와 같은 툴을 통해 로그인 해 줍니다.
Amazon Linux에는 awscli
가 기본적으로 설치되어 있습니다.
aws configure
명령어를 통해 IAM 계정으로 로그인을 진행합니다.
저는 Admin권한을 가지고 있는 계정으로 로그인 하겠습니다.
IAM
에서 로그인하고자하는 계정의 액세스 키를 만들어 줍니다.
$ aws configure
AWS Access Key ID [None]:
AWS Secret Access Key [None]:
Default region name [None]:
Default output format [None]:
그 다음 aws configure
명령어를 실행하고 요청하는 데이터들을 입력해줍니다.
다음으로 EKS
를 활용하기 위한 도구들을 설치하겠습니다.
# kubelet이 기본적으로 참고하는 config 파일이 위치할 경로 생성
$ mkdir -p ~/.kube
# kubectl 설치
# curl -LO "https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectl"
# 위의 명령어로 수행시 최신버전 설치
# 실습에서는 EKS가 Kubernetes 1.21을 사용할 것이므로 1.21 버전을 명시적으로 설치
$ curl -LO https://dl.k8s.io/release/v1.21.0/bin/linux/amd64/kubectl
$ chmod +x ./kubectl
$ sudo mv ./kubectl /usr/bin/kubectl
# kubectl 명령어 동작 확인
$ kubectl version --short --client
다음은 EKS Cluster
를 생성해 주겠습니다.
먼저 AWS Console
에서 클러스터 추가 버튼을 선택해 Cluster
생성 화면에 진입해줍니다.
Cluster
구성 창에서 Cluster
의 이름을 입력하고 클러스터 서비스 역할에 위에서 생성한 eks-cluster-role
을 넣어줍니다.
Console
에서 자동으로 필요한 정책이 적용된 IAM
역할을 필터링 해주기 때문에 만약 eks-cluster-role
을 생성하지 않았다면 서비스 역할에 아무것도 나오지 않습니다.
다음은 네트워킹에 대한 설정입니다.
VPC
: EKS-VPC
Subnet
: EKS-Subnet-01
, EKS-Subnet-02
보안그룹
: Bastion-EKS-SG
1번 에서 생성한 VPC
및 Subnet
, 보안그룹
정보를 입력해줍니다.
클러스터 엔드포인트 액세스에 대한 설정은 관리자가 어떤 위치에서 EKS Cluster
를 조작할 수 있는지 설정하는 것입니다.
Public
으로 설정할 경우 외부에서 직접적으로 EKS Cluster
에 명령어를 입력할 수 있으며, Private
으로 설정할 경우 VPC
내부에 서버를 하나 생성하고 그 서버를 통해 명령어를 수행해야 합니다.
이번엔 Private
으로 설정하여 VPC
내부에 bastion server
에서만 EKS Cluster
에 접근할 수 있도록 하겠습니다.
다음으로는 Cluster
내부에서 사용할 네트워크와 관련된 컴포넌트들의 버전을 설정해야합니다.
기본값으로 설정해 주겠습니다.
이제 거의 다 왔습니다!
Control Plane
의 모든 컴포넌트들에 대해 로깅을 설정하겠습니다.
이제 EKS Cluster
가 생성되는 것을 기다리면 됩니다.
EKS Cluster
생성이 완료되었으면 EKS Cluster
가 생성되면서 AWS
환경에 어떤 변화가 생겼는지 확인해 보겠습니다.
먼저 EKS
가 생성이 될 때, EKS Cluster
에 적용될 보안그룹
이 생성됩니다.
생성된 Security Group
의 네이밍 규칙을 살펴보면
eks-cluster-sg-{ EKS Cluster 이름
} - 난수값 인것을 확인할 수 있습니다.
해당 보안그룹
의 인바운드 규칙을 보면 어떤 보안그룹
을 소스로하는 모든 트래픽에 대해 허용하는 룰이 있습니다.
과연 저 소스부분에 있는 보안그룹
은 무엇일까요?
보안그룹
id로 조회를 하면 알 수 있습니다.
조회 결과 자기 자신인것을 알 수 있습니다.
자신과 같은 보안그룹
에서 오는 모든 요청을 받겠다는 의미입니다.
EKS
의 ENI
도 생성되었습니다.
bastion server
가 EKS
에 명령어를 전달하기 위해서는 EKS
에 접근할 통로가 필요하기 때문입니다.
이 ENI
는 EKS
생성 과정에서 네트워크 설정과 함께 적용한 Bastion-EKS-SG
와 EKS Cluster
가 생성되면서 자동으로 만들어진 eks-cluster-sg-EKS-Cluster-1625236358
이 적용되어 있는 것을 확인할 수 있습니다.
bastion server
는 EKS Cluster
의 Endpoint
로 접속을 시도하고, 해당 Endpoint
는 이 ENI
에 연결되어 있으며, EKS Cluster
는 Bastion-EKS-SG
에 의해 bastion server
에서 온 요청을 수행합니다.