밥벌이코딩

MetalLB + Ingress-Nginx를 활용한 온프레미스 L4/L7 로드밸런싱 구축 가이드

1. 전체 아키텍처 구성도 2. 구축 단계별 가이드 1단계: MetalLB (L4 로드밸런서) 설치쿠버네티스 순정 상태에서 LoadBalancer 타입의 서비스를 사용하기 위해 L4 로드밸런싱을 제공하는 MetalLB를 설치# 1. MetalLB 네임스페이스 및 컴포넌트 일괄 설치 (v0.13+ 기준)kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.13.12/config/manifests/metallb-native.yaml# 2. 설치 완료 확인 (Controller 및 Speaker Pod가 Running 상태인지 확인)kubectl get pods -n metallb-system 2단계: MetalLB IP Pool 및 L..

S3 온디맨드 백업 실패: "Bucket already has continuous backup enabled for another vault"

증상S3 버킷에 온디맨드 백업을 실행하면 아래 메시지와 함께 작업 실패Bucket {bucket_name} already has continuous backup enabled for another vaultBackup job failed. AWS Backup 콘솔 > 작업 > 백업 작업을 보면 같은 리소스에 대한 작업이 여러 번 연속으로 실패 상태로 남아 있음다시 시도해도 결과는 같음 원인버킷은 이미 **다른 Backup Vault에 연속 백업(Continuous backup / PITR)**이 걸려 있음​S3 버킷 하나에는 연속 백업을 한 Vault에만 연결할 수 있음​그런데 온디맨드 백업을 다른 Vault로 실행하자, AWS Backup이 연속 백업을 새 Vault에 또 연결하려고 하면서 요청을 거부..

1단계: 증상 파악 - Pod 이벤트에서 Read-only file system 에러 확인 kubectl describe pod 2단계: mount flag 확인 (참고용 — 100% 신뢰하지 말 것)- rw로 나와도 실제 쓰기가 되는지는 별개이므로, 여기서 끝내지 않고 반드시 3단계로 진행kubectl exec -- cat /proc/mounts | grep 3단계: Pod 내에서 직접 write 테스트 (가장 확실한 검증)kubectl exec -- touch /write-test- 성공 → 다른 원인(subPath, securityContext, volumeMounts 순서 등)으로 좁혀서 재확인- Read-only file system으로 실패 → 4단계로 - 같은 PVC를 쓰는 다른 파드..

버킷 -> 관리 -> 수명 주기 규칙 정책 스토리지 클래스 간에 객체의 현재 버전 전환 (현재 활발히 사용 중인 '최신 파일'을 더 저렴한 저장소로 옮기는 작업)- 설명: 자주 쓰지 않는 파일을 S3 Standard(비쌈)에서 Standard-IA(조금 저렴)나 Glacier(매우 저렴)로 자동 이동- 특징: 파일은 그대로 목록에 보이지만, 뒤에서 저장되는 물리적인 위치만 변경 스토리지 클래스 간에 객체의 이전 버전 전환 (수정되거나 삭제되어 '뒤로 밀려난 과거 버전'들을 저렴한 저장소로 옮기는 작업)- 설명: 버전 관리가 켜진 버킷에서만 작동하며, 구버전 파일들을 Glacier 같은 아카이브 저장소로 이동- 용도: "과거 이력 데이터는 거의 볼 일이 없으니 가장 싼 곳에 보관하고 싶을 때" 사용..

구조는 아래 이미지와 같다. 호출 → Ingress → Envoy Service → Envoy Pod(로그 기록) → Backend Service → Pod 테스트용 백앤드 서비스 생성kubectl create deployment service-1 --image=nginx --replicas=1kubectl create deployment service-2 --image=nginx --replicas=1kubectl create deployment service-3 --image=nginx --replicas=1kubectl expose deployment service-1 --port=80 --target-port=80kubectl expose deployment service-2 --port=80..

canary ⇒ 특정 pod에 설정한 weight만큼의 비율만 호출하게 하는 기능 ingress + deploy + svc 조합이 2개가 필요함 [Ingress - Stable / Canary] | ┌──────────┴──────────┐ | | 90% 10% | | [test-service] [test-canary-service] | | [Stable Pod1] [Canary Pod1] ..

특정 서비스를 호출할 때 해당 서비스에서어떤 버전의 TLS를 지원하냐에 따라 개발을 달리해야 할 때가 있다.특정 서비스에서 TLS 지원이 가능한 범위를 확인하기 위해선 아래 명령어를 통해 확인이 가능하다.#TLS 1.0 확인openssl s_client -connect {domain}:{port} -tls1#TLS 1.1 확인openssl s_client -connect {domain}:{port} -tls1_1#TLS 1.2 확인openssl s_client -connect {domain}:{port} -tls1_2#TLS 1.3 확인openssl s_client -connect {domain}:{port} -tls1_3 호출했을 때 결과값을 통해서 지원 가능한 버전 확인이 가능하다.

1. Node에 AmazonEC2ContainerRegistryReadOnly 권한을 추가(단 eks와 ecr이 같은 계정에 있는 경우만 가능하다) 2. Secret 생성 후 deployment에 연결kubectl create secret generic aws-registry --from-file=.dockerconfigjson=/home/kuber/config.json --type=kubernetes.io/dockerconfigjson이런식으로 secret을 만들어서 사용하면 됨

S3 온디맨드 백업 진행 시 아래 오류가 발생 Bucket {s3-name} already has continuous backup enabled for another vault Backup job failed. 해당 오류 메시지 내용은해당 S3 버킷은 이미 다른 Backup Vault에 연속 백업(Continuous backup / PITR) 이 활성화돼 있기 때문에새 온디맨드 백업을 다른 Vault로 또 걸려고 하니까 거절되고 결과 상태가 “만료됨(Expired)” 으로 뜬 것 해당 S3가 포함된 백업 룰에서 Enable continuous backups for point-in-time recovery (PITR) 부분을체크해제해도 되지만 전체 적용되므로 해당되는 S3만 연속 복구 시점의 연결을 해제함..

EC2 > Load balancers > Action > Edit load balancer atributes S3 URI 입력 해당 LB 선택 후 엑세르 로그 S3 위치 부분에 위에서 설정한 S3가 연결되어 있는지 확인