일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
- IRSA
- helm_release
- assumerole
- node group
- route53
- clusterrolebinding
- aws ses #aws lambda
- instances failed to join cluster
- Pipeline
- jenkins
- Terraform
- httpasswd
- Gateway
- docker
- NAT
- 코드커버리지
- 에이전트 유형
- fruition
- 추가 보안 그룹
- aws-loadbalacner-controller
- ingestion
- 테라폼
- Docker0
- Service Account
- saa-c03 #saa #aws certified solutions architect - associate
- kubernetes
- 에이전트 구성
- s3
- Amazon CloudWatch
- 클러스터 보안 그룹
- Today
- Total
cloudwithbass
[K8S] EKS Basics 본문
Udemy의 Rocking Kubernetes with Amazon EKS, Fargate, And DevOps 강의의 Section2 내용과 더불어, 제가 따로 공부한 내용을 정리했습니다.
목차
1. What is EKS?
EKS란?
- Amazon EKS는 AWS 관리형 서비스입니다.
- AWS가 컨트롤 플레인의 고가용성을 유지해 주고, Unhealtyh Control Plane Instances를 감지하고 교체합니다.
EKS의 필요성
- Section 1에서 쿠버네티스는 크게 컨트롤 플레인과 데이터 플레인으로 구성되는 것을 알았습니다.
- 만약 컨트롤 플레인이 다운된다면 쿠버네티스는 정상적으로 동작하지 않을 것입니다.
- 따라서 컨트롤 플레인의 고가용성을 유지해야 합니다.
따라서 EKS를 사용하면 컨트롤 플레인을 관리할 필요가 없습니다.
그렇다면, 데이터 플레인은 어떻게 관리해야 할까요?
다음과 같은 세 가지 옵션이 있습니다.
- Amazon EC2: Self Managed Node Group
사용자 정의 AMI를 사용할 수 있습니다.
모든 관리 작업을 직접 해야하므로 운영 오버헤드가 증가합니다. - Amazon EC2: Managed Node Group
AWS가 인스턴스 관리, 보안 패치, 버전 관리 등을 자동으로 처리합니다.
수백, 수천 개의 노드를 직접 관리하는 것은 힘드므로 좋은 선택지입니다. - AWS Fargate
아래는 Managed Node Group과 Fargate를 보안, 확장성, 네트워크, 비용 측면에서 비교한 글입니다.
상황에 따라 다른 옵션을 선택해야 합니다.
주요 차이점은, Fargate가 더 관리할 일이 적지만 가격은 '훨씬' 비싸다는 것입니다. (하루 12시간 실행 시)
https://www.mobiquity.com/insights/four-differences-between-eks-fargate-and-node-managed
2. What is eksctl?
- EKS 클러스터를 동작시키기 위한 CLI 도구입니다.
- VPC, 서브넷, 노드 그룹 등을 추상화해줍니다.
- 따라서 AWS 콘솔보다 클러스터를 간단하고 빠르게 구성할 수 있습니다.
3. what is kubectl?
- kubernetes 리소스를 조작하는 cli 도구입니다.
- eksctl은 EKS Cluster에서만 작동하지만, kubectl은 EKS, GKE 등에서도 작동합니다.
4. EKSCTL 실습
aws configure 명령을 통해 aws에 로그인합니다.
IAM user를 생성해서 액세스 키를 생성하고, 입력하면 됩니다.
성공적으로 클러스터를 생성한 모습
5. Helm Chart
- 위와 같은 application을 배포한다고 가정하겠습니다.
- 이 application을 배포하기 위해선 frontService, WebServer, backService, Database를 모두 배포해야 합니다.
- 네 개정돈 배포할 수 있겠지만, 그 수가 늘어난다면 아주 복잡하고 번거로워질 것입니다.
- helm chart를 이용하면 이 번거로운 일을 하나의 명령으로 해결할 수 있습니다.
6. Helm 실습
헬름 공식 문서에 따라 ubuntu에 helm을 설치합니다.
다음 명령을 통해 helm에 가장 기본적으로 사용되는 레포지토리인 stable을 추가합니다.
그 외 레포지토리는 Artifact Hub에서 검색할 수 있습니다.
helm repo add stable https://charts.helm.sh/stable
helm repo update
이제 helm search repo 명령으로 레포지토리 내에서 차트를 검색할 수 있습니다.
여기서 차트란, 시각적 지표가 아닌 쿠버네티스 리소스를 정의하는 파일들의 모음 의미합니다.
helm pull bitnami/nginx --untar=true 명령을 수행하면 레포지토리에서 nginx 폴더를 다운로드합니다.
tree 명령을 통해 확인한 nginx의 구조는 아래 사진과 같습니다.
쿠버네티스 리소스를 정의하는 .tpl과 .yaml 파일들을 확인할 수 있습니다.
helm install [이름] bitnami/nginx 명령을 통해 다운 받은 차트를 쿠버네티스에 배포할 수 있습니다.
hlem-nginx는 임의로 지정한 이름입니다.
이제 kubectl get service 명령으로 nginx의 서비스가 배포된 것을 확인할 수 있습니다.
로드밸런서의 ip주소에 접속 시 성공적으로 nginx를 확인할 수 있습니다.
'Kubernetes' 카테고리의 다른 글
[Kubernetes] DNS Deep Dive in Kubernetes with CoreDNS (1) | 2024.11.17 |
---|---|
[Kubernetes] ★Ingress란?, alb-ingress-controller 사용하기 (0) | 2024.08.11 |
[k8s] Kubernetes Basics (0) | 2024.07.28 |
[k8s] 로컬에 kubectl 환경 구성하기 (0) | 2024.07.27 |