eks

EKS는 관리형 쿠버네티스로 AWS에서 제공하는 K8S 서비스이다. 오픈소스 특성상 유지보수가 어렵고 특정 스트림에서 에러가 났을 때 유지보수가 굉장히 어렵기때문에 관리형 서비스를 사용한다고 한다. 기존 K8S에서는 Control Plane을 노드로 지정해주어서 우리가

EKS 환경 작업을 하기 위한, Control Plane에 있는 API Server에 요청을 보내기 위한 작업공간이 필요한데 bastion host 라는 SSH Jump용 EC2를 개설한 뒤에 자격증명을 거치고 하는 세팅을 하기 복잡하기 때문에 간편하게 Cloud9을

실행 후 다시 확인IP 사용 개수 증설

이어서 ... Cloud9 세팅test : 여기서 기능 테스트를 시행deploy : 테스트가 완료된 제품을 프로덕트에 옮기기 전 통합 테스트product : 실제 배포 환경IP 사용 개수 증설기본적으로 kube-system에서 설치된 daemonset인 aws-node

EKS 환경에서 Ingress를 구성해보자. 여기서 위와 같이 ALBC 정책을 부여하니 Ingress 생성에 지장이 있었음. 아래 부분 삭제주의! Ingress Controller 는 NameSpace에 종속되지 않는 자원이다.따라서 다른 네임스페이스의 Ingress를

POD의 영구 저장소를 위해 DB 서버를 할당하는 것은 매우 비효율적인 일이다. 로그 저장, Kafka partition 보존 등을 위해 POD의 저장소를 영구 저장소에 옮겨야하는데 EKS환경에서 사용할 수 있는 볼륨으로 EBS와 EFS가 있다.나는 EFS를 선택했는데

EKS 환경에서 지속적 통합을 위한 Private Repository로 ECR을 선택했다. Docker Hub를 사용하지 않은 이유는 Private Repository를 위해 서버, 혹은 컨테이너를 띄워 서버 자원을 사용하고싶지 않았다. 관리 비용을 줄이기 위해 ECR

EKS 클러스터 환경에서 Kafka 클러스터를 구성하기 위해서는 단일 카프카 POD를 구성할 때와 많은 차이점이 있었다. 이에 대해 정리가 필요해 작성했다. 카프카 클러스터는 3개의 Zookeeper와 4개의 Kafka Borker가 필요하다. Zookeeper는 서로

EKS 환경에서 MongoDB를 사용할 일이 생겼다. 여러 시도를 하면서 결국 Cloud MongoDB 서비스를 사용하기로 했다. Mongo Atlas 시도했던 것들을 정리하면서 나중에 해결법을 찾아볼 것이다. 외부 연결을 위해 Service를 LoadBalancer