hyuckang의 블로그

1. Kubernets를 사용하는 환경과 종류 Kubernetes를 사용할 수 있는 환경 2가지 → On-premise와 Cloud On-premise 환경에서 Kubenertes를 구축하는 방법 공식 배포 버전의 쿠버네티스로 직접 구축 → 네이티브 쿠버네티스 또는 바닐라 쿠버네티스라고 합니다. VMware Tanzu, Redhat의 OpenShift 등의 솔루션으로 구축 (참고)Amazon EKS Anywhere를 이용하여 EKS를 On-premise에 설치 할 수도 있습니다. Public Cloud 환경에서 Kubernetes를 사용하는 방법 AWS의 EKS(Elastic Kubernetes Service) Azure의 AKS(Azure Kubernetes Service) Google의 GKE(Goo..

Kubernetes는 새로운 기능, 디자인 업데이트, 버그 수정으로 빠르게 진화하고 있습니다. 이에 EKS는 이러한 변화를 반영하기 위해 새로운 버전을 지원하고, 오래된 버전에 대한 지원을 중단합니다. AWS는 Kubernetes 버전이 EKS에 출시된 후 14개월 동안 Standard support(표준 지원)를 지원합니다. Standard support가 종료되면 자동으로 최대 12개월 동안 Extended support(확장 지원)가 적용(추가 비용 발생)됩니다. 이를 통해 minor 버전을 최대 26개월까지 사용할 수 있습니다. Extended support까지 종료가 되면 EKS 클러스터는 현재 지원되는 가장 오래된 버전으로 자동 업그레이드 됩니다. 2024년 초에 extened support가..

엣지 로케이션과 리저널 엣지 캐시 엣지 로케이션(edge locations) 또는 POP(point of presence) 사용자와 가장 가까운 캐시로 사용자에게 콘텐츠를 직접 제공 CloudFront Functions은 POP에서 동작 리저널 엣지 캐시(regional edge caches) 엣지 로케이션과 오리진 사이에 존재 Lambda@Edges는 리저널 엣지에서 동작 CF 동작 방식 CF는 POP에 컨텐츠가 없다면 리저널 엣지 캐시에서 객체를 가져와 캐싱하고 리저널 엣지에도 객체가 없다면 오리진에서 리저널 엣지로, 리저널 엣지에서 POP으로 캐싱하고 컨텐츠를 전달합니다. 캐시 무효화를 하게 되면 POP과 리저널 엣지 캐시 모두에서 객체가 제거되고, 다음에 사용자가 객체를 요청할 때 오리진에서 객체..

Verified Access 등장 배경 대부분의 기업 고객이 AWS 내의 어플리케이션에 접근하려면 VPN과 기업에서 관리하는 장비를 사용하여야 합니다. 이는 결국 여러가지 정책을 여러 팀에서 관리하게 만들고, 어플리케이션에 접근하지 못하는 문제를 여러 포인트에서 찾게끔 만듭니다. Verified Access는 Zero Trust에 기반하여 VPN 없이 웹브라우저로만 어플리케이션에 접근 할 수 있도록 해줍니다. AVA(AWS Verified Access)는 유저가 어플리케이션에 접근할 때 Trust Provider에서 가져온 정보와 정책을 비교하여 어플리케이션에 대한 액세스 권한을 부여합니다. AVA는 모든 액세스 시도를 로깅합니다. 사용 예시 주요 컴포넌트 VA instance 어플리케이션 액세스 요청을..

VPC Lattice 등장 배경 최근 비용을 절감하고 프로그램을 빠르게 확장할수 있는 서비스 지향 아키텍처가 대중화되고 있으며, 서비스 지향 아키텍처를 구현하는 가장 효과적인 방법은 다중 Account와 다중 VPC을 사용하는 것입니다. 다중 Account와 다중 VPC 전략에서 Account와 VPC가 서비스 간의 경계(Boundary)라고 생각할수 있지만 인증을 고하려면서 적절한 경계를 구축하기는 어렵습니다. 그렇기 때문에 일반적인 네트워크 복잡성과는 또 다른 네트워크 복잡성을 불러일으킬 수 있습니다. VPC 피어링, TGW, 프라이빗 링크, SG, NACL 등을 사용하여 현대화 된 아키텍처를 구축할 수 있지만, 단일 실패지점이 되거나 IP 기반의 통제만으로는 중장기적으로 인증되고 인가된 서비스가 연..

구성도 Route 53을 활용해 Primary / Secondary Health Check를 설정하고 failover routing을 구성합니다. 평상시에는 DNS Lookup이 Primary EC2로 되지만 Primary health check가 Unhealthy 상태가 되면 DNS가 Secondary로 failover 되고, Healthy 상태로 돌아오면 DNS가 Primary로 failback 됩니다. Route 53 Health Check 설정하기 Route 53 → Health checks → Create health check 사진과 같이 Primary / Secondary 2개의 Health check를 구성합니다. 별도의 알람은 설정하지 않습니다. Health Check가 Healthy인걸..

구성도 ALB는 HTTPS(443)으로 요청을 받으면 대상 그룹(target group)에 HTTP(80)으로 전달하여 SSL 종단점 역할을 수행합니다. (SSL Termination) route53는 hyuckang.link의 네임서버이며, one.hyuckang.link와 two.hyuckang.link는 hyuckang-alb를 가리키고 있습니다. SSL 인증서 발급받기 Certificate type으로 Request a public certificate를 선택합니다. Domain names로 *.hyuckang.link를 입력하고, Select validation method로 DNS validation을 선택합니다. Certificates로 돌아가 Status가 Pending validation..

Boto3란? Boto3는 Python용 AWS SDK로 Botocore(Python SDK와 CLI 사이의 공유되는 라이브러리), Boto3(Python SDK 구현 패키지) 두가지 주요 패키지로 구성되어 있습니다. (AWS CLI는 Botocore로 구현되어 있습니다.) AWS SDK를 사용하면 AWS 서비스들에 대한 객체지향(object-oriented) API 뿐만 아니라 저수준의 접근(low-level access)이 가능합니다. Boto3 SDK Features client : AWS 서비스에 대한 저수준의 인터페이스(a low-level interface)를 제공하고 서비스 API와 1:1에 가깝게 매핑 resource : AWS 서비스에 대한 객체 지향 인터페이스(an object-orie..

CodeBuild이란? CodeBuild는 소스코드를 컴파일하고 테스트를 실행하여 배포 가능한 패키지를 만들어주는 완전 관리형 빌드 서비스로 대표적인 CI(Continuous Integration) 서비스입니다. CodeBuild는 빌드 요청이 생성되면 즉시 빌드가 시작되고, 빌드 볼륨에 따라 인프라가 자동으로 확장/축소가 됩니다. CodeBuild의 특징 빌드 프로젝트(build project)는 빌드를 실행하는 방법을 정의한 것이며 소스코드 위치, 빌드 환경, 실행할 빌드 명령, 빌드 출력물의 저장 위치등을 포함합니다. 빌드 아티팩트(build artifacts)는 빌드에 의해 생성된 파일입니다. 일반적으로 배포 패키지, WAR 파일, 로그파일 등이 포함됩니다. 빌드 환경(build environme..

CodeCommit이란? Git 기반의 레포지토리 서비스로 소스를 저장하고 제어할 수 있는 기능을 제공하며 기존 Git 도구와 연동 가능한 완전 관리형 소스 제어 서비스 CodeCommit의 특징 레포지토리에 저장된 데이터는 Key Management Service(KMS)을 통해 자동으로 암호화되고, 첫번째 리포지토리를 생성하면 AWS가 관리하는 CodeCommit 키가 자동으로 생성된다. IAM, CloudTrail, CloudWatch와 연동하여 레포지토리 접근을 제어하거나 모니터링 할 수 있습니다. CodeCommit은 resoure-level permissions(리소스 수준 권한)을 지원합니다. 이를 통해 git pull, git push등의 작업에 대해 제어가 가능합니다. 또한 작업에 대해 ..