노는 게 제일 좋아

AWS ALB로 접근 제어

접근 제어는 여러가지 방법이 있음 Security Group을 통한 IP ALB Listener Rule에서 CIDR 기반 필터 WAF를 ALB에 연결 Ingress Controller Annotation을 통한 IP 여기선 ALB - ingress를 이용한 접근 제어를 해보려고 함 왜?Security Group은 AWS resource라서 생성해야함-> 생성하면 삭제도 해야하고 관리해야함-> 나의 경우엔 영구적으로 필요한 것은 아니기 때문에 굳이?라는 생각Listener Rule-> 같은 AWS 리소스WAF-> 같은 리소스 리소스는 Terraform으로 생성하는 것이 규칙이기 때문에 진짜 임시로 하기 위해서 만든다는 것이 정말 비효율적이라고 생각했던 찰나에 ingress 등장사실 이 역시 ALB에..

주요 옵션Node Selector: 특정 레이블 노드에 배치Node Name: 특정 노드에 강제 배치Taints & Tolerations: 노드 접근 제어Node Affinity & Pod Affinity/Anti-Affinity: 조건 및 Pod 관계 기반 배치Topology Spread Constraints: 균등한 Pod 분산1. Node SelectorNode Selector는 Pod를 특정 레이블이 있는 노드에 배치하는 가장 간단한 방법spec: nodeSelector: disktype: ssd gpu-vendor: nvidia주요 활용 사례:SSD 디스크 노드에 데이터베이스 배치GPU 노드에 ML 워크로드 배치특정 CPU 아키텍처노드 선택특징: 레이블 key-value가 정확히 일..

1. 클라이언트 요청 및 DNS 쿼리클라이언트가 curl, 브라우저 등으로 service.example.com 요청 전송DNS 쿼리 수행: 권한 DNS 서버로부터 A/AAAA 레코드 응답 수신AWS: Amazon Route 53 권한 네임서버GCP: Google Cloud DNS 권한 네임서버 2. 클라우드 로드밸런서(LB) 처리외부 로드밸런서로 TCP 트래픽 수신L4 포워딩: 클라우드 로드밸런서가 수신한 TCP 세션을 Kubernetes 노드의 NodePort로 전달하는 과정이 과정을 통해 외부에서 들어온 연결이 특정 노드 포트로 ‘전환’되어 Service 트래픽이 클러스터 내부로 유입됨 Session Handoff 단계에서 클라이언트와 백엔드 노드 간의 연결 매핑 및 소스·대상 포트 정보가 유지되어 ..

Pod는 우리가 생각한 대로 동작함예를 들면 Pod 는 image tag, image repo를 입력하면 image를 pulling 함하지만 정확하게 구체적인 동작을 알지 못함어떻게 그렇게 할 수 있는 것인지?알아보자 Pod란Pod는 Kubernetes에서 가장 작은 배포 단위로, 하나 이상의 컨테이너를 그룹화하여 네트워크와 스토리지를 공유하는 구조 모든 컨테이너는 공통 IP, 볼륨, 네임스페이스를 공유각 Pod는 단일 네임스페이스에 속함기본적으로 하나의 컨테이너를 포함하되, sidecar 패턴 등으로 복수의 컨테이너를 구성 가능Pod가 생성될 때 자동으로 ServiceAccount와 연결됨 Pod를 만들 때, token을 집어넣으면 되지 않았을까?, 왜 ServiceAccount, Secret을 통해..

참으로 어이가 없는 에러가 아닐 수가 없다. 현상몇몇 정보들은 지운 로그이다.[WARNING] service.go: failed to list versions for entry: operation error S3: ListObjectVersions, https response error StatusCode: 403, api error AccessDenied: Access Denied 특정 파드 -> S3 접근할 때 발생하는 에러 예상 원인IRSA 할 때, SA에 연결된 Role이 문제? 또는 S3 정책의 문제라고 생각 실제 원인ListBucketVersions가 실제로 필요한 policy 이며버킷 대상으로 실행해야 하기에.../* 로 할 경우 객체만 필터링 되기 때문에 오류 발생 ??왜.. 이름이 다른..

Redis는 싱글스레드? Redis는 데이터 처리를 담당하는 메인 이벤트 루프가 싱글스레드로 동작하는 것 -> redis-client 와 싱글스레드로 동작함-> 싱글스레드이기 때문에 간섭, lock 없이도 빠르게 작동 가능함 하지만 백그라운드에서 동작하는 작업은 멀티스레드로 작동 -> 그렇기 때문에 우리가 redis prod 상황에서도 백업이 가능함더군다나 6.0부터 도입된 I/O 멀티스레딩: 클라이언트 요청을 처리할 때의 네트워크 I/O를 멀티스레드로 병렬 처리 가능 Redis는 Replica로 하면 다 된다? Replica(슬레이브)를 두면 읽기 부하를 분산할 수 있고, 장애 발생 시 failover도 가능한 것이 사실하지만 쓰기 부하는 절대 분산되지 않음 -> 쓰기는 여전히 Master에만 가..

kube-apiserver란?kube-apiserver는 Kubernetes 클러스터의 중앙 관리 지점으로, 모든 API 요청을 처리하고 클러스터 상태를 관리함다른 구성요소들은 API 서버를 통해 클러스터 정보를 업데이트하며, API 서버만이 etcd 데이터 저장소와 직접 상호작용함 아키텍처 및 구성요소 kube-apiserver는 다음과 같은 주요 구성요소로 이루어짐인터페이스 계층: RESTful API를 통해 클라이언트와 통신인증 및 권한 부여 계층: 요청의 인증과 권한을 검증어드미션 컨트롤러: 요청을 수락하거나 거부하는 정책을 적용데이터 저장소 계층: etcd와 상호작용하여 클러스터 상태를 저장하고 검색 기술kube-apiserver는 Go 언어로 작성Go 언어: 고성능의 병렬 처리를 지원하는 ..

https://kubernetes.io/ko/docs/concepts/overview/components/ Kubernetes 클러스터 개요Kubernetes 클러스터는 크게 **컨트롤 플레인(Control Plane)**과 **노드(Node)**로 나뉘며, 각 구성요소는 클러스터 상태 유지와 애플리케이션 실행 Kubernetes의 모든 컴포넌트는 API Server를 중심으로 유기적으로 동작 컨트롤 플레인 컴포넌트클러스터의 전반적인 상태를 관리하는 컴포넌트로 구성됨.kube-apiserverKubernetes의 중심 엔드포인트로, 모든 컴포넌트와 외부 요청을 받는 HTTP API 서버 역할 수행. 클러스터 상태에 대한 모든 요청과 명령은 여기서 처리됨. etcd클러스터 전반의 상태 데이터를 저장하는..

https://kubernetes.io/ko/docs/concepts/overview/ 쿠버네티스란 무엇인가? 전통적 배포단일 물리 서버 기반 실행하나의 물리 서버에서 여러 애플리케이션을 실행하는 방식.리소스 충돌 문제 발생특정 애플리케이션 인스턴스가 서버 자원을 독점함에 따라, 다른 애플리케이션 성능 저하 문제 발생.물리 서버 분리 실행 시도각 애플리케이션을 별도의 물리 서버에서 실행하려는 방식 도입. 하지만 리소스 활용률 저하 및 높은 유지 비용 문제 발생.가상화된 배포가상 머신(VM) 기술 도입단일 물리 서버에서 여러 VM을 실행하여 리소스를 효율적으로 분할하는 방식.격리성과 보안성 확보VM 간 애플리케이션 격리를 통해 정보 접근 제한 및 보안성 향상.유연한 리소스 활용 가능성 확보리소스를 클러스..

istio operator 설치istioctl 설치 - https://istio.io/latest/docs/setup/getting-started/#download이후 CR 정의 사용하는 이유 중 하나Istio Operator는 선언적 설정으로 변경 추적과 검증이 쉬워 GitOps와 통합이 용이하며, 설치와 업그레이드 관리가 간편   IstioOperator란?Kubernetes CR(Custom Resource)로 정의되며, Istio 서비스 메시의 모든 설정과 구성을 포함apiVersion: install.istio.io/v1alpha1kind: IstioOperatormetadata: namespace: istio-system # Istio 컴포넌트가 배포될 네임스페이스 name: custom..