🦓 EKS

Kubernetes의 컨트롤 플레인 또는 노드를 제공하는 AWS의 관리형 K8S 서비스즉, AWS에서 제공하는 탄력적으로 쿠버네티스를 관리할 수 있는 서비스이다.사실 쿠버네티스가 가장 주목받고, 컨테이너 오케스트레이션 툴의 1인자로써 올라선 만큼 AWS 뿐만 아닌

쿠버네티스 클러스터를 구성할 때, 마주쳤던 바로 그것💡 클러스터 엔드포인트 액세스에 대해서 알아보자.쿠버네티스의 엔트포인트 액세스란 쿠버네티스 API 서버에 대한 접근 방식이다.쉽게 말해, 사용자가 쿠버네티스 API 서버에 kubectl로 명령을 내릴 때, 어떤 방식

EKS를 배포하는 방법에는 3가지가 있다. 본 글에서는 이러한 배포를 하기 위한 사전작업인 IAM 사용자 생성 및 CloudFormation을 통한 인프라 배포를 수행할 것이다.

관리 콘솔을 통해서 EKS를 배포해보자.그림의 숫자를 보며 순서대로 진행된다.(1) 관리콘솔에서 EKS를 생성하면 컨트롤 플레인이 EKS 클러스터의 AWS Managed VPC영역에 생성된다.이 때 AWS가 컨트롤 플레인에 접근하여 etcd 생성, API 서버 생성 등

eksctl을 통해서 EKS를 배포해 보자.핵심은 myeks-host EC2에서 EKS 클러스터를 생성하는 명령어인 eksctl create cluster를 통해 EKS를 간편하게 생성하는 것이다.이러한 eksctl 명령을 통해서 EKS를 배포하게 되면 앞서 "콘솔환경

EKS 클러스터 구성에 따른 네트워크를 이해하기 위한 첫번째 관문인 Amazon VPC CNI에 대해서 알아보자.Amazon EKS는 Amazon VPC CNI 플러그인을 통해서 클러스터 네트워크 환경을 구성합니다.일반적으로 쿠버네티스 클러스터의 CNI로 거두되는 Ca

Amazon VPC CNI를 사용해서 EKS 환경을 구축할 때 인스턴스의 유형에 따른 파드의 생성 수량에 제한이 발생한다.노드에 정의된 파드의 max-pod 수는 넉넉해도, 실제 부여하고자 하는 IP 수 부족으로 파드에 IP를 할당하지 못해 파드를 생성하지 못하는 경우

Amazon VPC CNI로 구성된 네트워크 환경을 확인해보자.이러한 과정을 통해서 VPC CNI 동작과정에 대해서 실제로 어떻게 흘러가는지 알 수 있다.이러한 실습 환경을 구축하기 위해서는 YAML 다운로드를 통해서 CloudFormation 스택을 정의해서 생성하면

서비스와 인그레스 무엇이 다른지 살펴보고, 애플리케이션(파드)에 연결하여 각각의 방법으로 노출해보도록 하자.서비스란 무엇일까?공식 문서를 참고하면, 파드 집합에서 실행중인 애플리케이션을 네트워크 서비스로 노출하는 추상화 방법이라고 기술되어 있다.쉽게말해 다음과 같이 정

AWS LoadBalancer Controller 설치하는 과정과 Seriver 4계층 NLB와 Ingress 7계층 ALB에 대해서 알아보고 배포해 보자.

ExternalDNS란 무엇일까?ExternalName과 헷갈릴 수 있으니 잠깐 집고 넘어가자면..ExternalName은 클러스터 내부에서 외부 서비스의 DNS 이름을 통해 접속할 수 있도록 하는 서비스이다.예를 들어, 외부 RDS에 접근할 때 ExternalName

🖥️애플리케이션의 정상적인 동작을 위해서는 무엇이 필요할까?애플리케이션의 정상적인 동작을 위해서 애플리케이션의 데이터를 저장하고 유지하기 위한 📁데이터 지속성이 필요하다.즉, 컨테이너, 파드, 노드의 생명주기와 무관한 영구적으로 데이터를 저장할 수 있는 스토리지가

CloudFormation을 통해서 해당 인프라 전체를 구축했고, 다음과 같은 환경에서 진행된다.구축된 전체적인 환경은 다음과 같다.여기서 왼쪽을 보면 AWS EFS를 생성하고 작업용 베스천 호스트 EC2에 마운트하는 것을 확인할 수 있다.마운트 타겟은 3개의 가용영

영구 볼륨환경인 PV의 생성에 실제 스토리지가 생성되는 위치는 크게 2가지의 종류가 있다.이전 챕터에서 살펴본 것처럼 Local Path Provisioner와 같이 내부의 로컬 스토리지 영역을 사용할 수도 있고, 외부 스토리지 공급자(AWS EBS, EFS)를 사용할

본 과정은 AWS EBS CSI Driver 설치 및 구성이 완료된 상태에서 진행합니다.

EFS란 AWS에서 제공하는 파일스토리지로 EBS와 같이 별도의 스토리지 용량이 지정된 것이 아닌 Elastic하게 늘어나는 스토리지를 말한다.즉, 다수의 가용영역에서 다수의 사용자가 필요한 만큼의 스토리지를 사용할 수 있다.📈EBS는 단일 EC2 인스턴스에 마운트되

AWS EKS (Amazon Elastic Kubernetes Service) 옵저빌리티(Observability)는 EKS 클러스터의 가시성과 모니터링을 향상시키기 위한 개념과 도구들을 의미한다.

프로메테우스의 아키텍쳐는 확장성이나 고가용성의 문제가 있다. 프로메테우스는 클러스터링(여러 노드에 분산)이 되지 않아 단일 노드에서 모든 메트릭이 처리되므로 대규모 환경에서 성능 저하가 발생할 수 있다.또한 단일 노드의 문제가 발생하면, 해당 노드가 복구될 때까지 메트

Control Plane 로깅 AWS EKS 환경의 Control Plane의 로깅을 활성화 해보자. Control Plane의 로깅 기능을 활성화✅ 하면* 자동으로 CloudWatch가 생성*된다고 이전 글에서 설명한 바가 있다. Control Plane의 로깅

본 실습은 다음과 같은 환경에서 진행되었습니다.설치된 파드 정보설치된 파드의 이미지 정보 (AWS 공식계정 ID : 602401143452)이러한 이미지들은 AWS에서 정식으로 제공하고 지원하는 것이며, 사용자가 EKS 클러스터를 구성할 때 기본적으로 이러한 이미지를

노드 자체의 로그와 Data Plane의 로그 확인은 EKS에서 지원하지 않으므로 별도의 도구로 수집해야한다.또한 로그를 애플리케이션(컨테이너)에 저장하는 경우 심볼릭 링크로 연결된 노드의 /var/log/\* 위치의 로그가 컨테이가 지워질 시 함께 지워진다는 단점이

Prometeus🔥와 Grafana☀️를 설치하고, 시계열 데이터와 시스템 및 애플리케이션의 성능을 모니터링 해보자!프로메테우스와 그라파나에 대한 개념은 여기를 참고하라.이번 과정은 프로메테우스 스택을 이용해서 설치할 것이다.프로메테우스 스택이란, 프로메테우스 모니터

이전 학습에서 Prometheus🔥를 통해서 매트릭을 수집하고, Prometheus에서 제공하는 기본 Graph📊를 살펴보았다.하지만, 더욱 가시성 있고, 보기좋게 대시보드를 내 마음대로 구축할 수는 없을까? 바로 그라파나☀️를 사용해서 이를 구축할 수 있다!그라파