Somaz의 IT 공부 일지

Kagent: Kubernetes에 AI Agent를 도입하기!

OverviewKubernetes 클러스터에서 장애가 발생했을 때, 우리는 어떻게 대응할까요?1. Slack 알림 확인2. kubectl로 파드 상태 확인3. 로그 확인4. Prometheus 메트릭 확인5. 에러 메시지를 ChatGPT에 복사/붙여넣기6. ChatGPT 제안 시도7. 또 다른 에러 발생8. 다시 ChatGPT로...9. 반복... 😫 이 과정이 익숙하신가요? 우리는 AI의 도움을 받지만, AI와 인프라 사이의 중간 다리 역할을 계속 해야 한다. AI는 우리 클러스터를 볼 수 없고, 우리는 AI가 제안한 것을 수동으로 실행해야 한다. Kagent는 이 문제를 해결한다. AI Agent가 Kubernetes 클러스터 내부에서 직접 실행되어, 스스로 문제를 진단하고, 해결책을 계획하고,..

Overview프로덕션 EKS 클러스터에서 Cluster Autoscaler를 Karpenter로 교체했다. 이 글에 실제로 어떻게 구성했는지를 그대로 정리했다.Cluster Autoscaler는 노드 그룹(node group) 단위로 동작한다. 인스턴스 타입을 고정한(혹은 몇 개로 제한한) Auto Scaling Group을 미리 만들어두면, 파드가 스케줄링되지 못할 때 CA가 ASG의 desired count를 올리고 새로 뜬 노드에 그 파드에 맞기를 기대하는 식이다. 그러다 보니 인스턴스 형태, taint, AZ에 따라 노드 그룹을 잘게 쪼개두게 되고, 그 그룹들을 균형 있게 유지하는 운영 부담까지 함께 떠안는다. Karpenter는 이 방식을 버린다. 펜딩 상태인 파드를 직접 들여다보고 실제 리..

OverviewKubernetes를 운영하다 보면 누구나 한 번쯤 마주하는 상황이 있다. 바로 `OOMKilled` (Out of Memory Killed) 에러이다. 파드가 설정된 메모리 제한(Limit)을 초과하여 강제로 종료되는 이 현상은, 많은 DevOps 엔지니어들에게 골치 아픈 문제이다. 대부분의 팀이 이 문제를 어떻게 해결할까요? "일단 메모리를 2배로 늘리고 다시 배포해보자"는 식의 주먹구구식 대응이 흔하다. 하지만 이는 근본적인 해결책이 아니며, 리소스 낭비와 비용 증가로 이어진다. 이 글에서는 OOMKilled 문제에 대한 체계적인 접근 방법과 실무에서 바로 적용할 수 있는 해결 전략을 다룬다. 단순히 리소스를 늘리는 것이 아니라, 왜 발생했는지 파악하고, 적정 리소스를 산정하며, ..

OverviewClaude Code를 쓰다 보면 `/command`, Skill, Subagent, Plugin 이 네 가지 개념이 계속 등장한다. 이름도 비슷하고 하는 일도 겹쳐 보여서 처음엔 구분이 잘 안 된다. 특히 슬래시 커맨드와 스킬은 최근 통합되면서 더 헷갈린다. 이 글에서는 다음을 정리한다.Command, Skills, Agents가 각각 무엇이고 어떻게 다른가같은 이름이 겹칠 때 어떤 게 우선되는가 (우선순위 규칙)Plugin으로 설치하면 기존 Skill과 어떻게 동작하는가 결론부터 말하면 이렇다. Command는 호출 단축키, Skill은 번들 가능한 프롬프트 능력, Agent는 격리된 컨텍스트를 가진 별도 인스턴스, Plugin은 이것들을 묶어서 배포하는 패키지다. 그리고 Plugin..

OverviewKubernetes 클러스터에서 외부 트래픽이 어떻게 내부 Pod까지 도달하는지 이해하는 것은 운영과 트러블슈팅에 필수적이다. 외부에서 들어오는 요청은 단순히 Pod에 직접 연결되는 것이 아니라, 여러 네트워크 컴포넌트를 거쳐 최종 목적지에 도달한다. 외부 트래픽은 먼저 Ingress Controller나 LoadBalancer를 통해 클러스터로 진입한다. 이후 Service 객체의 ClusterIP로 전달되는데, 이 Service는 실제 IP가 아닌 가상 IP이다. kube-proxy가 각 노드에서 iptables 또는 IPVS 규칙을 관리하며, Service IP로 오는 패킷을 실제 Pod IP로 DNAT(Destination NAT) 변환한다. 최종적으로 CNI(Container ..

OverviewCilium은 eBPF 기반의 차세대 CNI 플러그인으로, 기존 kube-proxy와 함께 사용하거나 완전히 대체할 수 있다. 이 문서는 Cilium + kube-proxy 혼합 환경에서 발생하는 특수한 상황과 문제 해결 방법을 다룬다. 해당 실습은 Kubernetes 내부 네트워크 완벽 분석: IPVS 모드 환경에서의 패킷 플로우 추적 글의 실습환경과 동일하다.2025.11.12 - [Container Orchestration/Kubernetes] - Kubernetes 내부 네트워크 완벽 분석: IPVS 모드 환경에서의 패킷 플로우 추적 환경 특성 파악./network-test-info.sh ====================================== Kubern..

Overview용량이 큰 영상 파일을 클라우드에 백업하거나 공유할 때, 화질을 거의 손해보지 않고 용량을 1/10 수준으로 줄일 수 있는 방법이 있다. 바로 ffmpeg를 이용한 재인코딩이다. 이 글에서는 Mac 환경에서 ffmpeg로 동영상을 압축하는 방법을 정리한다. H.264 CRF 23(빠르고 호환성 좋음)과 H.265 CRF 28(압축률 좋음) 두 가지 옵션을 다루고, 실제 1080p 영상들을 압축했을 때의 결과 데이터도 함께 공유한다.결론부터 말하면, 1080p 24fps 영상 기준 약 83~94% 용량 감소가 가능하다. 1. 환경 준비 1.1 ffmpeg 설치 확인Homebrew가 설치되어 있다면 ffmpeg 설치는 한 줄이면 끝난다.# 설치brew install ffmpeg# 설..

OverviewKubernetes 클러스터에서 발생하는 네트워크 문제를 해결하기 위해서는 내부 네트워크 구조를 정확히 이해해야 한다. 특히 온프레미스와 AWS 클러스터처럼 서로 다른 환경에서 동일한 문제가 발생할 때, tcpdump를 통한 패킷 분석은 필수적이다. 이 글에서는 kube-proxy IPVS 모드를 사용하는 환경에서 Kubernetes 네트워크의 내부 동작 원리와 실제 패킷 플로우를 tcpdump로 추적하는 방법을 상세히 다룬다. 또한 직접 따라할 수 있는 실습 예제를 통해 이론을 실전에 적용하는 방법을 알아본다. Kubernetes 네트워크 계층 구조Kubernetes 네트워크는 크게 세 가지 계층으로 구성된다. Node Network (물리 네트워크)노드 간 통신을 담당..

Overviewingress-nginx가 유지보수 모드로 전환되고 Kubernetes Gateway API가 v1.2로 GA되면서, 운영 중인 온프레미스 클러스터의 ingress-nginx 11개 인스턴스를 nginx-gateway-fabric(NGF) 2.0으로 이관했다. 전환 대상과 규모는 다음과 같다.항목 내용대상 클러스터 온프레미스 Kubespray (K8s v1.34)기존 Ingress 컨트롤러 ingress-nginx 11개 인스턴스 (기본 nginx 1개 + nginx-public-a~j 10개)LoadBalancer MetalLB L2 (내부 IP 14개 고정 할당)마이그레이션 대상 앱 infra 직배포 11개 + ArgoCD ApplicationSet 9개 + 별도 레포 2개전환 후 ..

OverviewClaude Code의 멀티 에이전트는 정확히는 Sub-agents (서브에이전트) 기능이다. 서브에이전트는 자체 시스템 프롬프트, 자체 컨텍스트 윈도우, 자체 도구 접근 권한, 자체 권한 모드를 가진 격리된 Claude 인스턴스로, 메인 대화 컨텍스트를 깨끗하게 유지하면서 특정 작업을 위임할 수 있다. DevOps 작업 (Terraform, Kubernetes, ArgoCD 등)에 바로 활용 가능한 구조다. 1. 핵심 개념서브에이전트의 가장 큰 가치는 컨텍스트 보존이다. 테스트 실행, 문서 조회, 로그 파일 처리는 상당한 컨텍스트를 소비하는데, 이를 서브에이전트에 위임하면 verbose한 출력은 서브에이전트 컨텍스트에 머물고 관련 요약만 메인 대화로 돌아온다. 또한 여러 서브에이..