본문 바로가기

DevSecOps

 (51)
도커 이미지 매니페스트 및 레이어 구조 이해 1. 정의도커 이미지는 단일 파일이 아닌 Union Mount File System을 기반으로 한 여러 개의 읽기 전용(Read-only) 레이어의 집합이며, 이에 대한 메타데이터는 Manifest 파일과 Config 파일에 정의되어 있다.2. Union Mount File System과 GraphDriver 구조도커는 GraphDriver(주로 overlay2)를 통해 여러 계층의 파일 시스템을 하나의 통합된 뷰(View)로 제공한다. docker inspect 명령어를 통해 해당 컨테이너의 파일 시스템 경로를 확인할 수 있으며, 구조는 다음과 같다.Lower Directory (LowerDir):이미지의 레이어들이 위치하는 곳.모든 레이어는 Read-only(읽기 전용)이다.여러 개의 레이어가 존재할..
도커 라이프사이클 및 이미지/컨테이너 명령어 정리 1. 정의도커(Docker)의 라이프사이클은 **이미지(Image)**를 기반으로 **컨테이너(Container)**를 생성, 실행, 정지, 삭제 및 저장하는 일련의 과정을 의미한다. 2. 이미지 및 레지스트리 관리 (Image & Registry)이미지는 컨테이너 실행에 필요한 파일과 설정값을 포함한 불변의 템플릿이다.레지스트리(Registry): 도커 이미지를 저장하고 배포하는 공간(예: Docker Hub).Pull & Push:pull: 원격 레지스트리에서 로컬로 이미지를 다운로드함.push: 로컬에 생성된 이미지를 원격 레지스트리에 업로드함.rmi: 로컬에 저장된 도커 이미지를 삭제(Remove Image)함. 컨테이너가 해당 이미지를 참조 중일 경우 삭제가 불가능함.3. 컨테이너 생명주기 (C..
Kubernetes Rolling Update 시 Readiness Probe, Graceful Shutdown, Termination Grace Period Kubernetes Rolling Update. Readiness Probe, Graceful Shutdown, Termination Grace PeriodPod 롤링 업데이트의 무중단을 결정하는 핵심 세 가지입니다. Readiness Probe는 트래픽 유입 여부를 판단합니다. Graceful Shutdown은 종료 시 커넥션 드레인을 보장합니다. TerminationGracePeriodSeconds는 강제 종료까지 허용 시간을 정의합니다.1. Readiness Probe. 트래픽 유입 결정역할. 컨테이너가 요청을 안전하게 처리할 준비가 되었는지 판별합니다. 실패 시 해당 Pod는 Service 대상에서 제외됩니다.권장. 외부 의존성까지 포함한 실제 처리 가능 상태를 검사합니다. 예시는 DB 연결, 큐..
AWS Security Group for Pods AWS Security Group for Pods 정리Amazon EKS에서는 AWS VPC CNI의 확장 기능을 통해 Pod 단위로 Security Group을 직접 할당할 수 있습니다. 이를 Security Group for Pods (SGP)라고 하며, 기존에는 노드 단위로만 보안 그룹을 적용할 수 있었던 제약을 보완합니다. 즉, 워크로드(Pod)마다 네트워크 경계를 분리해 더 세밀한 보안 제어가 가능합니다.1. 동작 원리Pod ENI 할당. VPC CNI가 Pod에 ENI를 직접 붙여주고, 해당 ENI에 보안 그룹을 매핑IAM Role for Service Account(IRSA). Pod에 할당할 보안 그룹 권한 부여를 위해 IRSA를 사용Security Group Policy CRD. Kube..
Amazon VPC CNI와 Kubernetes Network Policy Amazon VPC CNI와 Kubernetes Network PolicyAmazon EKS에서 기본적으로 사용되는 Amazon VPC CNI(Container Network Interface) 플러그인은 Pod에 직접 VPC의 ENI(Elastic Network Interface)와 IP를 할당하는 구조를 사용합니다. 이로 인해 Pod가 클러스터 내부 전용 IP가 아닌 VPC 네이티브 IP를 가지게 되며, AWS 보안 그룹(Security Group) 및 VPC 네트워크 제어와 자연스럽게 연계되는 장점이 있습니다. 하지만 순수 Kubernetes Network Policy 지원은 제한적이며, CNI 구성에 따라 별도의 구현이 필요합니다.1. VPC CNI의 기본 동작Pod IP = VPC IP. Pod..
Kubernetes Network Policy 보안 관점 정리 Kubernetes Network Policy 보안 관점 정리Kubernetes Network Policy는 Pod 간 트래픽을 제어하기 위한 보안 기능입니다. 기본적으로 Kubernetes는 모든 Pod 간 통신을 허용하기 때문에, 민감한 워크로드를 보호하려면 네트워크 정책을 명시적으로 정의해야 합니다. 보안 관점에서 Network Policy는 제로 트러스트 네트워킹(Zero Trust Networking)의 핵심 도구로 활용됩니다.1. 기본 개념기본 동작. 네트워크 정책이 없으면 모든 Ingress(들어오는 트래픽)와 Egress(나가는 트래픽)가 허용됩니다.정책 적용. 특정 네임스페이스에 배포된 Pod에만 정책이 적용됩니다.선언적 제어. 허용 규칙(allow rule)만 정의할 수 있으며, 정의하..
EKS Fully Private에서 ENI별 Security Group 베스트 프랙티스 EKS Fully Private에서 ENI별 Security Group 베스트 프랙티스완전 프라이빗 EKS 아키텍처에서 EKS-owned ENI, Worker Node ENI, VPC Endpoint ENI, 운영용 호스트 ENI(myeks-host)에 적용할 Security Group(SG) 규칙을 정리합니다. 원칙은 최소 권한, 보안그룹 참조 기반, 인터넷 무노출입니다.요약 테이블대상 ENI부착 SG주요 Inbound주요 Outbound비고EKS-owned ENI(컨트롤플레인 ENI)sg-eks-controlplane443/TCP. 소스 sg-eks-nodes, sg-myeks-host10250/TCP. 대상 sg-eks-nodes443/TCP. 대상 sg-eks-nodes, sg-vpce-*API ..
Amazon EKS Fully Private Cluster 아키텍처 VPC Endpoint와 PrivateLink로 API Server 및 엔드포인트 프라이빗 액세스 구현인터넷 게이트웨이와 NAT 없이도 운영 가능한 완전 프라이빗 EKS를 설계합니다. 클러스터 API 서버는 Private Access 전용으로 열고, 워커 노드는 필요한 AWS 서비스에 VPC Endpoint로만 접근합니다. 외부 VPC·온프레미스에서 관리용 접근이 필요하면 AWS PrivateLink를 사용해 프라이빗 경로로만 접속합니다.핵심 설계 원칙클러스터 엔드포인트. endpointPrivateAccess=true, endpointPublicAccess=false. VPC 내부 DNS로만 해석됩니다.네트워크. 퍼블릭 서브넷 미사용. 프라이빗 서브넷, VPC DNS 활성화, IGW·NAT 비사용.엔드..
Kubernetes 클러스터 오토스케일링 - Cluster Autoscaler vs Karpenter Kubernetes 클러스터 오토스케일링 - Cluster Autoscaler vs Karpenter앞서 살펴본 HPA, VPA, KEDA는 파드(Pod) 단위의 오토스케일링입니다. 하지만 파드를 아무리 늘려도 클러스터에 충분한 노드(서버)가 없으면 배포되지 않습니다. 이를 해결하기 위한 것이 노드 오토스케일링(Node Autoscaling)이고, Kubernetes에서는 대표적으로 Cluster Autoscaler(CA)와 Karpenter 두 가지 방식이 있습니다.Cluster Autoscaler (CA)CA는 Kubernetes에서 가장 먼저 등장한 기본 노드 오토스케일러입니다. 파드를 배치할 공간이 부족한 경우, 노드 그룹(ASG)을 확장하거나 축소합니다.기본 동작 방식파드가 스케줄되지 못하면 →..
Kubernetes 오토스케일링 - HPA, VPA, KEDA Kubernetes 오토스케일링 - HPA, VPA, KEDAKubernetes에서 워크로드(Deployment, StatefulSet 등)를 안정적으로 운영하려면 자원 사용량에 따라 자동으로 스케일링되는 구조가 필요합니다. 이 기능을 담당하는 것이 HPA, VPA, KEDA입니다.이 글에서는 각 스케일링 방식이 어떤 역할을 하고, 어떤 상황에서 어떤 도구를 선택해야 하는지 이해하기 쉽게 설명합니다.1. HPA (Horizontal Pod Autoscaler)가장 널리 쓰이는 Kubernetes 기본 오토스케일링 기능입니다. Pod 수를 자동으로 늘리거나 줄이는 방식으로 작동합니다.기본 동작 방식CPU 사용률, 메모리 사용률, 또는 사용자 정의 메트릭(Prometheus 등)을 기반으로 판단스케일링 주기..

티스토리툴바