YG Tech Blog

이 글에서는 CiliumClusterwideNetworkPolicy를 사용하여 네임스페이스에 상관없이 클러스터 전체 범위의 네트워크 정책을 적용하는 방법에 대해 알아보겠습니다. 지금까지 살펴본 Cilium 네트워크 정책들이 주로 특정 네임스페이스 내에서 적용되었다면, 이번에는 클러스터 전체에 적용되는 글로벌 정책을 통해 여러 네임스페이스에 걸친 일관된 보안 규칙을 구현하는 방법을 실습합니다. matchLabels를 활용한 타겟 선택 방법과 함께 실무에서 유용하게 활용할 수 있는 다양한 클러스터 전체 정책 패턴을 살펴보겠습니다.📌 CiliumClusterwideNetworkPolicy의 필요성✅ 기존 네트워크 정책의 한계지금까지 살펴본 CiliumNetworkPolicy는 해당 리소스가 생성된 네임스페이..

이 글에서는 Cilium의 CIDR과 Entity 기반 네트워크 정책을 통해 외부 접근을 정밀하게 제어하는 방법을 살펴봅니다. 앞서 살펴본 L3/L4 및 L7 정책들이 주로 클러스터 내부 통신을 제어하는 데 중점을 두었다면, 이번에는 외부 네트워크와의 통신을 세밀하게 관리하는 방법을 실습합니다. 특정 IP 대역만 허용하거나, world, host, remote-node와 같은 사전 정의된 엔터티들에 대한 접근 제어를 수행하는 방법을 배우고, 이를 통해 쿠버네티스 클러스터의 보안을 한층 더 강화할 수 있습니다.📌 CIDR 기반 정책의 이해✅ CIDR(Classless Inter-Domain Routing)이란?CIDR은 IP 주소를 할당하고 라우팅하기 위한 방법으로, IP 주소와 그 뒤에 슬래시('/')..

1️⃣ 개요Job 리소스를 구성할 때 많이 사용되는 두 가지 설정이 있습니다:backoffLimit: 실패 시 재시도 횟수activeDeadlineSeconds: Job 전체 실행의 최대 허용 시간이 두 옵션은 비슷해 보이지만 완전히 다른 기준으로 Job의 생존을 제어합니다.이 글에서는 두 항목의 차이점과 함께, 실제 운영 환경에서 어떻게 조합하는 것이 효과적인지 전략적으로 설명합니다.2️⃣ 두 설정의 차이 정리 항목 backoffLimit activeDeadlineSeconds 기준실패 횟수실행 시간작동 대상실패한 Pod 기준Job 전체 기준목적최대 재시도 횟수 제한무한 실행 방지 (타임아웃)기본값6없음 (무제한)제어 방법실패마다 1회 증가Job 생성 시부터 시간 카운트✅ 두 설정은 병렬로 작동하며..

1️⃣ 개요Kubernetes에서 Job 리소스는 일회성 작업 또는 반복 불필요한 처리 작업을 위해 사용됩니다.하지만 Pod이 중간에 실패하거나, 예외 상황이 발생했을 때 Job이 실패로 끝나지 않도록 구성하는 전략이 중요합니다.이번 글에서는 Job 리소스가 Pod 실패 상황에서 어떻게 반응하는지, 그리고성공 보장을 위한 재시도 설정 방법에 대해 자세히 살펴보겠습니다.2️⃣ Job 기본 개념 요약 항목 설명 목적1회성 또는 완료 시 종료되는 작업 실행기본 Pod 수1개완료 기준지정된 수의 completions 도달 시실패 대응기본적으로 실패한 Pod은 자동 재시도되지 않음 (명시 필요)✅ 즉, Job을 신뢰성 있게 구성하려면 명시적으로 재시도 조건을 설정해야 합니다.3️⃣ 재시도 전략 설정 항목들 설정..

1️⃣ 개요Kubernetes에서 Pod을 배포하는 대표적인 리소스로는 ReplicaSet과 DaemonSet이 있습니다.둘 다 여러 개의 Pod을 생성하는 역할을 하지만, Pod의 배포 방식과 목적은 완전히 다릅니다.이 글에서는 DaemonSet과 ReplicaSet의 개념적 차이, 스케줄링 방식, 운영 목적의 차이점을 비교하여둘 중 어떤 리소스를 선택해야 하는지 명확히 이해할 수 있도록 구성하였습니다.2️⃣ 역할 차이 요약 항목 DaemonSet ReplicaSet Pod 수 조절 방식노드 수에 따라 자동 결정 (1개/노드)수동으로 .spec.replicas 수 지정배포 대상클러스터의 모든 노드 (혹은 특정 조건의 노드)스케줄링 가능한 노드 중 임의 선택목적노드 기반 작업 (모니터링, 로그 수집 ..

1️⃣ 개요Kubernetes 클러스터에서는 각 노드 및 Pod의 리소스 사용량(CPU, 메모리 등)을 수집하여 모니터링하는 것이 중요합니다.이를 위해 Metrics Server를 설치하고, 각 노드의 리소스를 주기적으로 수집하여 외부 시스템으로 전달하는 구조를 구성할 수 있습니다.이 글에서는 DaemonSet을 활용하여 Metrics Server의 정보를 기반으로 각 노드의 리소스를 수집하고, 이를 가공하거나 외부에 전송하는 방식을 설명합니다.2️⃣ Metrics Server란? 항목 설명 역할Kubernetes에서 CPU, 메모리 등 리소스 사용량을 수집하고 제공하는 컴포넌트데이터 소스각 노드의 Kubelet에서 제공하는 /metrics/resource API활용 위치kubectl top, HPA(..

1️⃣ 개요DaemonSet은 클러스터의 모든 노드에 Pod을 하나씩 자동으로 배포하는 구조입니다.하지만 다양한 이유로 인해 특정 노드에 DaemonSet Pod이 배포되지 않거나, 실패한 상태로 남는 경우가 있습니다.이 글에서는 DaemonSet이 일부 노드에 정상적으로 배포되지 않았을 때 이를 자동으로 감지하고, 복구하는 방법에 대해 설명합니다.2️⃣ DaemonSet이 노드에 배포되지 않는 주요 원인 유형 설명 Taint/Toleration 불일치해당 노드에 Taint가 설정되어 있고, DaemonSet이 이를 Toleration하지 않음NodeSelector/NodeAffinity 조건 불일치노드의 라벨 조건과 맞지 않아 스케줄링에서 제외됨리소스 부족CPU, 메모리 부족으로 스케줄링 불가Pod ..

1️⃣ 개요DaemonSet은 모든 노드에 동일한 Pod을 배포하지만, 노드 환경에 따라 조금씩 다른 설정이 필요할 때가 있습니다.예를 들어, 로그 수집 대상 경로나 디바이스 경로가 노드마다 다를 수 있고,클러스터 관리자가 ConfigMap을 통해 설정을 주기적으로 갱신해야 할 수도 있습니다.이 글에서는 DaemonSet과 ConfigMap을 연동하여 노드별 구성을 적용하거나 설정 변경에 유연하게 대응하는 방법을 정리합니다.2️⃣ ConfigMap 기본 사용 방식apiVersion: v1kind: ConfigMapmetadata: name: log-configdata: log_level: "INFO" log_path: "/var/log/messages"📌 설명이 ConfigMap은 로그 수집기의 ..

1️⃣ 개요Kubernetes 환경에서 DaemonSet은 노드 단위의 작업을 자동화하거나, 시스템 이벤트를 감지하는 데 활용됩니다.특히, 노드에서 발생하는 이벤트를 수집하고 분석하는 로직을 DaemonSet으로 구성하면모든 노드에서 일어나는 다양한 이벤트를 빠르게 파악할 수 있습니다.이번 글에서는 DaemonSet을 통해 Kubernetes 이벤트 감지 및 알림용 에이전트를 구성하는 방법을 설명합니다.2️⃣ 이벤트 감지 에이전트 구성 목적 감지 항목 예시 활용 목적 Pod OOMKilled, CrashLoopBackOff장애 대응 자동화노드 NotReady 이벤트노드 상태 모니터링PersistentVolume 오류스토리지 이슈 조기 감지컨테이너 ImagePullBackOffCI/CD 문제 추적✅ 위 ..

1️⃣ 개요Kubernetes 클러스터는 클라우드 또는 온프레미스 환경에서 여러 Zone 또는 Region에 걸쳐 구성될 수 있습니다.이때 DaemonSet을 클러스터 전체가 아닌 **특정 영역(Zone 또는 Region)**에만 배포하고 싶은 경우,Node Affinity를 활용하여 스케줄링 대상을 제한할 수 있습니다.이번 글에서는 DaemonSet Pod이 특정 Zone/Region에만 배포되도록 제어하는 방법과 설정 전략을 소개합니다.2️⃣ Zone / Region 설정 키Kubernetes에서는 클라우드 환경이나 클러스터 구성 도구를 통해 자동으로 아래 라벨이 노드에 추가됩니다. 라벨 키 설명 topology.kubernetes.io/zone노드가 위치한 Zone 정보topology.kuberne..