본문 바로가기
반응형

Kubernetes31

ArgoCD 배포 시 실패한 Pod는 삭제됐는데 ReplicaSet은 남아있다? 괜찮은 걸까? 쿠버네티스 환경에서 ArgoCD로 애플리케이션을 배포하다 보면, 실패한 Pod는 삭제됐는데 ReplicaSet(RS)은 계속 남아 있는 상황을 접할 수 있습니다. 처음에는 “이거 뭔가 잘못된 거 아닌가?” 싶지만, 사실은 정상적인 동작입니다. 이번 글에서는 왜 이런 현상이 발생하는지, ReplicaSet을 어떻게 관리해야 하는지 정리해 보겠습니다.1. ReplicaSet이 남는 이유Deployment의 기본 동작 원리쿠버네티스에서 Deployment(또는 Argo Rollouts)는 직접 Pod를 생성하지 않습니다. 대신 ReplicaSet을 생성하고, ReplicaSet이 파드를 관리합니다. 따라서 파드가 실패해 삭제되더라도 ReplicaSet은 그대로 남아 있으며, 필요 시 새 파드를 다시 만들 준비.. 2025. 8. 29.
Argo CD에서 “읽기 전용(READ-ONLY)” 사용자 만들기 (Helm/Terraform 예시) 로컬 계정 하나 만들고role:readonly 를 정의해 조회만 허용policy.default 를 role:readonly 로 두되, admin은 명시적으로 전권 매핑Helm values 로 관리하고, 적용 후 argocd-server 재시작 → 비밀번호/토큰 발급 → 권한 확인1) 개념 한 줄 요약Argo CD 권한은 Casbin 정책(policy.csv) 으로 정의합니다.p, , , , , allow|denyg, , role: (사용자→역할 매핑)policy.default 는 매핑되지 않은 사용자의 기본 역할입니다.deny가 allow를 이깁니다. 읽기 전용 역할에 굳이 deny 줄을 많이 넣기보다, “허용만 명시”하는 편이 안전합니다.admin은 반드시 명시 매핑하세요. 기본 역할이 readonly.. 2025. 8. 29.
Argo CD에서 이미지 변경 트리거 안되는 배포 트러블 슈팅 — GitOps + ECR 날짜태그 + Argo CD Image Updater + IRSA, 그리고 Helm으로 한 장 템플릿 감싸기까지이 글은 제가 실제로 겪은 “ECR 이미지가 바뀌었는데 Argo CD가 변화를 못 잡는다” 문제를 완전 종료한 과정 정리입니다.길지만, 그대로 따르면 끝납니다. (폴더 구조, Terraform, Helm, 어노테이션, GitHub Actions, 체크리스트 모두 포함)문제의 본질: Argo CD는 “Git 변경”만 본다컨테이너 이미지를 :latest 로 계속 덮어써도 Git 매니페스트가 그대로면 Argo CD는 “변화 없음”으로 봅니다.해결 핵심은 두 가지 중 하나:A안(불변 태그 + Git 반영): 매 빌드마다 새 태그(날짜/커밋SHA) 를 만들고, 그 태그를 Git에.. 2025. 8. 25.
ArgoCD + ALB + CloudFront 환경에서 HTTPS 리다이렉션 정리 쿠버네티스에서 ArgoCD와 여러 앱을 ALB(aws-load-balancer-controller) 뒤에 붙이고, 그 앞단에 CloudFront를 둔 구조를 쓰다 보면 HTTP→HTTPS 리다이렉션 충돌 문제가 자주 발생합니다. 이번 글에서는 실제 경험한 케이스와 함께, 왜 문제가 생기는지, 그리고 어떻게 정리하는 것이 좋은지 정리합니다.문제 상황ArgoCD, Grafana, Invitation 앱 등 여러 서비스가 같은 ALB 그룹(shared-alb) 을 공유.Invitation 앱의 Ingress에 리다이렉트 액션 (alb.ingress.kubernetes.io/actions.redirect-to-https) 이 설정되어 있었음.이 액션이 host 제한 없이 / catch-all 로 걸려 있어, 같.. 2025. 8. 24.
AWS ALB Ingress Controller – 포트 & Path 기반 라우팅 완전 정리 목차 쿠버네티스 환경에서 AWS ALB Ingress Controller를 사용하면, 하나의 ALB로 여러 서비스에 트래픽을 라우팅할 수 있습니다.이 글에서는 포트와 Path를 활용한 라우팅 개념부터 Terraform 예제, 그리고 포트 매핑 케이스별 매트릭스와 패킷 흐름까지 전부 정리합니다.1. ALB + Kubernetes에서 포트 흐름 이해하기ALB → Kubernetes Service → Pod 컨테이너 포트는 아래 4단계로 연결됩니다.[Client] ↓ Listener Port[ALB Listener] ↓ Target Group Port (Service Port)[Kubernetes Service] ↓ targetPort[Pod Container Port] 구분 설명예시ALB Li.. 2025. 8. 8.
AWS EKS에서 externalTrafficPolicy 설정에 따른 NLB 헬스체크 동작 차이: Ingress Controller vs 일반 서비스 AWS EKS에서 Kubernetes 서비스에 NLB(Network Load Balancer)를 연동할 때,externalTrafficPolicy 설정에 따라 NLB의 타겟 헬스체크 상태가 다르게 표시되는 현상을 종종 마주하게 됩니다.이 글에서는 특히 Ingress Controller를 사용할 때와 일반적인 서비스(e.g. echo-service)를 사용할 때externalTrafficPolicy=Cluster일 때의 동작이 왜 다르게 보이는지를 기술적으로 분석합니다.✅ externalTrafficPolicy 란?Kubernetes 서비스에서 외부로부터 들어온 트래픽을 어떻게 Pod에 전달할 것인지를 결정하는 설정입니다. 설정 값설명Cluster트래픽이 도달한 노드에 파드가 없어도 kube-proxy가 .. 2025. 8. 7.
일반 서비스 (echo-service)와 Ingress Controller의 차이 ingress controller 를 nlb를 쓸때 자주 사용하는데 이게 주로 nginx 써드파티를 쓰다보니 자세한 설명이 자주 없더군요.그래서 일반 service와 nginx controller를 한번 정리해보았습니다.✅ 핵심 차이: 서비스 대상(엔드포인트) 의 구조가 다르기 때문 항목일반 서비스 (echo-service)Ingress Controller서비스 대상 (selector)일반 파드 (예: echo)NGINX Ingress Controller 자체가 파드 대상NodePort 요청 시 처리 방식kube-proxy가 어디든 있는 echo 파드로 라우팅 가능NodePort → Ingress Pod → 라우팅외부 트래픽 최종 종착지echo 파드NGINX 컨트롤러가 프록시처럼 중간 처리요청 처리 실패.. 2025. 8. 7.
AWS EKS NGINX Ingress Controller - hostNetwork에 따른 NLB 헬스체크 정상/비정상 분석 다음은 2~3일간 이론상 ingress 에서 동작해야하는 동작이 동작하지 않을때의 오류 해결입니다... AWS EKS 환경에서 ingress-nginx를 Helm으로 배포하고, type: LoadBalancer와 NLB(Network Load Balancer)를 함께 사용하여 외부 트래픽을 수신하도록 구성했습니다. 이때 externalTrafficPolicy: Local을 설정하여 클라이언트 IP를 보존하는 설정을 적용했습니다.하지만 이상한 현상이 발생했습니다:Ingress Controller가 하나의 노드에만 배포되어 있음에도, NLB의 Target Group에서 두 노드 모두 헬스체크가 성공하는 현상 발생.이는 이론적으로 맞지 않습니다. externalTrafficPolicy: Local이라면 Ing.. 2025. 8. 6.
Helm으로 Fluent Bit 배포 시 커스텀 ConfigMap 설정이 적용되지 않는 이유와 해결 방법 문제 상황AWS EKS 환경에서 Fluent Bit을 Helm과 Terraform으로 배포를 helm을 통해서 fluentbit 을 설치했는데 파드의 로그가 모두 쌓였다. 특정 로그 (예: kube-proxy, aws-for-fluent-bit, prometheus) 를 제외하고자 아래와 같은 custom ConfigMap을 구성했다: resource "kubernetes_config_map" "fluentbit_config" { metadata { name = "fluentbit-custom-config" namespace = "logging" } data = { "fluent-bit.conf" = 그리고 Helm으로 다음과 같이 적용resource "helm_releas.. 2025. 7. 29.
[kubernetes] kubectl alias 설정하기 Windowspowershell이나 cmd에서 notepad $profile 에 저장하면된다. # kubectl 명령어를 위한 함수 정의function k { kubectl $args }function kg { kubectl get $args }function kd { kubectl describe $args }function kf { kubectl config set-context $args }function kgp { kubectl get pod $args }function kgs { kubectl get svc $args }function ka { kubectl apply $args }function kc { kubectl create $args }function kr { kubectl delete.. 2025. 1. 23.
[kubernetes] IPVS에 대해 알아보자! Kubernetes의 IPVS 모드는 네트워크 트래픽 라우팅을 위해 **Linux 커널의 IP 가상 서버(IPVS, IP Virtual Server)**를 사용하는 kube-proxy의 실행 모드 중 하나입니다. IPVS는 iptables보다 더 효율적이고 고성능의 트래픽 처리와 부하 분산 기능을 제공합니다.IPVS란?**IP Virtual Server (IPVS)**는 Linux 커널에서 제공하는 L4(Transport Layer) 부하 분산 기술입니다.네트워크 트래픽을 가상 IP 주소(Virtual IP)로 받아 백엔드 서버(Pod 등)로 분산합니다.Connection Tracking 기능을 통해 상태 기반(stateful) 연결 관리가 가능합니다.주요 특징:부하 분산 알고리즘 지원.고속 패킷 처리... 2024. 12. 21.
Kubernetes의 Node Scheduling Kubernetes의 Node Scheduling은 클러스터에서 Pod가 실행될 적절한 Node를 선택하는 과정입니다. Kubernetes Scheduler가 이를 담당하며, 특정 Pod가 실행될 Node를 결정하기 위해 다양한 조건과 제약을 고려합니다.Node Scheduling의 주요 과정Scheduling 후보 Node 필터링 (Filtering)Scheduler는 클러스터 내에서 실행 가능한 Node를 찾기 위해 필터링 과정을 수행합니다.예를 들어, 다음 조건에 맞지 않는 Node는 제외됩니다:Node가 충분한 리소스(CPU, 메모리 등)를 가지고 있는지.Pod의 nodeSelector, nodeAffinity, 또는 taints에 맞는 Node인지.Node 상태가 Ready인지.적합한 Node .. 2024. 12. 19.
반응형