끊임없이 노력하는 엔지니어를 꿈꾸며 끊임없이 노력하는 엔지니어를 꿈꾸며

Terraform의 AWS 모듈을 활용해서 EKS를 구성해 보도록 하겠습니다. 수작업을 Code로 완전히 자동화 합니다. Human Error 방지와 멱등성을 완벽하게 보장하며 그리인해서 경제적인 이득까지 얻을 수 있으니 ㅎㅎ 총 10개의 Module로 분리해 놓았습니다. 1. init 2. Region 3. VPC 4. Internet Gateway 5. Subnet 6. Routing Table 7. Routing Table Association 8. Security Group 9. EKS Cluster 10. EKS WorkNode 생성 순서 입니다. 1. init 1.1. Terraform AWS 버젼 지정, 현재 최신버전은 5.7.0 terraform { required_providers { a..

AWS의 AutoScale에서 더 이상 Launch Configuration을 지원하지 않습니다. Launch Template을 사용하셔야 합니다. 별다른 것은 없으니 한 번 살펴보시기 바랍니다. 이전 작성한 ami 이미지에 디스크 용량등을 설정하는 작업입니다. 주의 하실 점은 userdata 작성시 반드시 암호화해서 작업을 하셔야 합니다. Have a nice day!

이번 시간에는 생성한 EKS 클러스터를 LoadBalancer에 연결해 보도록 하겠습니다. 1. manifest 파일 생성 및 적용 2. Object 확인 3. LoadBalancer 생성 4. 확인 5. Cluster 삭제 순으로 진행합니다. 1. manifest 파일 생성 및 적용 1.1. 작업디렉토리 생성 및 이동 # mkdir load # cd load 1.2. namespace 생성 1.2.1. 노트패드로 notepad name.yml 네임스페이스 web생성 apiVersion: v1 kind: Namespace metadata: name: web 1.3. Deployment 생성 1.3.1. 노드패드로 dep.yml 이름의 Deployment 생성 apiVersion: apps/v1 kind:..

EKS를 활용하면 외부(GCP, Azure, Tanzu, Onpremis 등) K8S Cluster를 등록해서 관리할 수 있습니다.물론 한계는 있습니다만 그래도 단일 환경에서 모니터링이 가능하다면 꽤 괜찮은 방법일 듯 합니다.역할 설정들이 까다롭기는 하지만 최대한 쉽게 풀어보려 합니다.프로젝트에 활용하시면 좋을 듯! 우선 결론부터 보여드리면 이렇게 EKS의 클러스터가 아닌 Other Cluster로 나타난다는 점입니다.매력적이죠! 그럼 시작하겠습니다.  1. 역할 생성2. 정책 연결3. Cluster 등록4. 확인순서로 진행하겠습니다.https://docs.aws.amazon.com/ko_kr/eks/latest/userguide/eks-connector.html Amazon EKS Connector -..

HPA의 필수 요소인 Metrics Server설치에 대해서 알아보겠습니다. 1. 정의 1.1. K8S에 내장된 자동 확장 파이프라인을 위한 컨테이너 리소스 메트릭의 확장 가능하고 효율적인 소스. 1.2. Kubelets에서 메트릭 리소스를 수집, 이를 Metrics API 를 통해 K8S apiserver에 노출하여 Horizontal Pod Autoscaler 및 Vertical Pod Autoscaler 에서 사용 가능하게 함. 1.3. Metrics API는 에서 액세스할 수도 있으므로 kubectl top자동 크기 조정 파이프라인을 더 쉽게 디버깅할 수 있습니다. Metrics Server는 자동 확장 목적이 아닙니다. 예를 들어 메트릭을 모니터링 솔루션에 전달하거나 모니터링 솔루션 메트릭의 소..

에고 하루 하루 따라가기 벅차니 힘이 부치는 듯! 능력밖의 일을 하려니 힘이 들 수 밖에! 즐겨야 하는데....... 그림 그리려 못간지 꽤 됐는데 전에 그려놓고 올리지 못한 그림들! 마저 또 해봐야지! 근데 맨날 이러면 소는 누가 키우나?

오늘은 K8S의 AutoScaling기능을 담당하는 HPA(Horizontal Pod Autoscaling: 이하 HPA)에 대해서 살펴보겠습니다. 1. HPA 의의 1.1. 워크로드 리소스(예: Deployment또는 StatePullSet)를 자동으로 업데이트하며, 워크로드의 크기를 수요에 맞게 자동으로 스케일링. 1.2. 수평 스케일링은 부하 증가에 대해 파드를 더 배치하는 것을 뜻함. 1.3. 부하량이 줄어들고, 파드의 수가 최소 설정값 이상인 경우, HorizontalPodAutoscaler는 워크로드 리소스(디플로이먼트, 스테이트풀셋, 또는 다른 비슷한 리소스)에게 스케일 다운을 지시. 1.4. HPA는 크기 조절이 불가능한 오브젝트(예: Daemonset)에는 적용할 수 없음. 1.5. HA..

emptyDir은 임시 볼륨입니다. 생명주기가 pod와 동일 동일 pod내에 복수개의 Container가 존재한다면 모든 Container가 공유합니다. pod존재하는 node에 특정 위치에 volume의 name으로 존재합니다. /var/lib/kubelet/pods/45df9acf-d3d5-466a-b213-25c200470c44/volumes/kubernetes.io~empty-dir 45df9acf-d3d5-466a-b213-25c200470c44는 임의의 문자열입니다. pod와 생명주기가 동일하다는 점 잊지마세요. pod내의 container가 삭제 되더라도 해당 volume은 존재합니다. 자세한 내용은 나중에 포스팅 합니다.