EKS Logging EKS에서도 로깅을 확인 할 수가 있는데 보통 해당 로그에 대해서는 비활성화가 되어 있기 때문에 활성화를 eks 명령어를 통해서 활성화를 해줘야한다. 아니면 웹에서도 활성화가 가능하다 . 나의 로그 그룹을 확인하고 해당 그룹에 대한 로그들을 Cloud Watch를 통해서 확인을 할 수가 있다. 컨테이너 파드 로깅 사용 리전의 인증서 ARN확인을 하는데 아무것도 뜨지 않느다... 일단 해당 nginx에서는 필요가 없는 거 같으니 넘어가고 추후 수정을 해보자.... 설정을 잘못했나 싶어서 CloudFormation을 재배포 했지만 똑같이 인증 정보가 나타나지 않음 아래의 서비스를 배포 service: type: NodePort networkPolicy: enabled: false ing..

본문 파드의 내부 데이터는 기본적으로 파드가 종료되면 그걸로 끝 ! 전부 삭제되어 버림 똑같은 파드를 재시작해도 데이터는 연동되지 않음 파드는 Stateless 애플리케이션이다 그래서 파드가 죽어도 작업했던 데이터를 보존하기 위해서 나온 것이 PV( Persistent Volume ) 해당 PV는 Stateful 애플리케이션으로 상태를 보존한다. PV는 어느 노드에서도 연결해서 사용 가능 Ex) NFS , Aws EBS 그리고 PV를 파드가 생성될 때 자동으로 마운트해주는 기능을 동적 프로비저닝 이라고 한다. 기본 컨테이너에서 아무런 설정을 하지 않으면 임시 파일 시스템을 사용하기 때문에 파드가 종료되면 기존 데이터가 다 삭제가 되어진다. busybox 파드를 만들고 해당 파드에 다음과 같은 글을 입력한..

해당 포스팅은 가시다님의 AWES 2기 스터디 내용을 토대로 작성했습니다. 네트워크 구성도 변수 세팅 # 노드 IP 확인 및 PrivateIP 변수 지정 N1=$(kubectl get node --label-columns=topology.kubernetes.io/zone --selector=topology.kubernetes.io/zone=ap-northeast-2a -o jsonpath={.items[0].status.addresses[0].address}) N2=$(kubectl get node --label-columns=topology.kubernetes.io/zone --selector=topology.kubernetes.io/zone=ap-northeast-2b -o jsonpath={.ite..

해당 포스팅은 가시다님의 AWES 2기 스터디 내용을 토대로 작성했습니다. EKS 아키텍쳐 컨트롤 플레인 영역은 AWS의 VPC에서 관리하고 있고 해당 영역이 마스터 쪽이니까 마스터가 나의 워커노드에 명령을 내리거나 모니터링을 하려면 내 VPC랑도 연결이 필요하다. 그렇기 때문에 EKS에서는 가용 영역 마다 EKS owned ENI( 내 소유가 아니라 AWS 소유 )라는 네트워크 인터페이스를 통해서 가용영역 내에 있는 워커노드와 AWS VPC에 있는 api-server와 통신을 한다. 위 그림도 확인해보면 가용영역 마다 EKS owned ENI가 있고 이를 통해 API서버랑 통신을 할 수 있다. 관리형 노드 그룹 내에 있는 경우 EKS 최적화의 AMI( OS ) 를 사용할 수 있어서 사용에 최적화가 되어..

서론 AEWS 스터디 참가하면서 쿠버네티스에 대한 개념도 잘 기억이 안 나기도 하고 일요일에 참가 내용 복습 겸 쿠버네티스의 특징과 개념 및 구성요소에 대해 정리를 해보고자 한다. 쿠버네티스란?? 컨테이너 인프라 환경에서 컨테이너를 모니터링하고 제어하는 시스템 컨테이너를 하나만 관리한다면 모르겠지만 사용자들에게 서비스를 제공할 때 여러 서버들을 동시에 운영할텐데 엔지니어가 그 모든 컨테이너들을 다 명령어 치면서 관리하고 서버 다운되면 명령어로 다시 켜고 하는 것은 매우 매우 비효율적이기 때문에 쿠버네티스라는 시스템을 사용하여 서비스를 제공하게 된다. 기능 내용 Auto Scaling 컨테이너 리소스를 모니터링 하여 바라는 상태를 유지 Self-Healing Infra 부하, 장애, 에러 등 대비 자가 복..

서론 쿠버네티스가 나온 배경과 왜 쿠버네티스를 쓰는가에 대해서 정리를 해보고자 한다. 컨테이너의 등장 애플리케이션을 실행 방법에 대해서는 총 3가지로 나눌 수 있다. 1) 온프레미스 2) 가상 환경 3) 컨테이너 총 3가지가 있는데 현재 일본에서는 컨테이너 방식으로의 서비스는 그렇게 많이 보이고 있지 않는 거 같다. 보통 클라우드 서비스를 사용하여 애플리케이션을 서비스하고 해당 인프라를 컨테이너 환경으로 바꾸자라는 인식은 있지만 역시 공수도 많이 들고 해당 기술자 역시 많이 없기 때문에 주변에서 자주 사용하지 않는 거 같다. 컨테이너 장점 1) 사이즈가 작고 가볍다. - 호스트 OS의 커널을 공유하기 때문에 가상 머신보다 더 적은 시스템 리소스를 사용하며 용량도 적게 차지함 2) 다양한 환경에서도 동일한..

서론 지난 번에 만들어 둔 거 같은 도메인이 만료가 되어 있어서 도메인 구입부터 Route53 네임서버 연결까지 정리하려고 한다. cafe24에서 등록한 거 썼을 때 네임서버 수정이 안 되는 원인 모를 에러가 있어서 이번에는 가비아에서 도메인을 구입한 후 Route53에 연결하려고 한다. 외부 도메인 Route53에 설정하기 1) 외부 도메인을 구입 - 가비아를 사용하여 도메인을 따로 구입함 2) Route53에 접속 후 호스팅 영역을 클릭 3) 호스팅 영역 생성을 클릭 3) 구입한 도메인을 넣어주고 호스팅 영역을 생성 4) 생성된 레코드의 라우팅 대상을 확인하고 복사 5) 외부 도메인 사이트에서 네임서버 값들을 Route53에서 복사해둔 값으로 갱신하기 - 네임서버 값들 중 마지막 점은 삭제 6) 보통..

서론 스터디 준비를 위해 루트 사용자가 아닌 관리자 권한을 가진 유저를 생성을 해야한다. 분명 만들었던 기억이 나는데 역시 순서가 헷갈리니까 포스팅을 통해 정리를 해보고자 한다. 사용자 그룹 생성 1) IAM 서비스 이동한 뒤 사용자가 속할 사용자 그룹을 클릭 2) 그룹 생성을 클릭 3) 그룹 이름을 지정한 뒤 해당 그룹의 권한을 'AdministratorAcess'로 설정 4) 사용자 그룹 생성 확인 사용자 생성 1) 사용자를 클릭 2) 사용자 생성을 클릭 3) 사용자 정보를 입력 4) 권한 설정을 그룹에 해당하도록 설정하고 앞에 만들어둔 사용자 그룹을 선택 5) 설정한 사용자의 정보를 확인한 후 생성 6) 생성한 사용자의 정보를 확인 및 csv파일 보관하기 7) 생성한 IAM사용자로 콘솔 로그인하기 ..

서론 스터디 준비 및 지금까지 AWS 계정을 여러개 사용하다가 하나로 통일하는 과정에서 프리티어 가입 과정을 정리하고자 한다. 솔직히 간단한 건데 나중에 확인을 위해서 간단간단하게 정리한다. 본문 1) AWS 회원가입 사이트에 접속 후 루트 사용자 메일 주소와 계정 이름을 입력 2) 메일에서 확인 코드 확인 후 입력 3) 루트 사용자 비밀번호 입력 - 로그인 시 사용 4) 사용자 개인 정보 입력 5) AWS 결제 정보 입력 - 추후 프리티어 종료후 결제 되는 카드 정보 6) AWS 자격 증명을 위해 휴대폰 정보 입력 및 보안 검사 -> 문자로 오는 확인 코드 입력하기 7) Support 플랜 선택 - 기본을 선택 8) 가입 완료 참고 https://portal.aws.amazon.com/billing/s..