[카테고리:] Kubernetes

In the Zabbix monitoring system, a warning alert occurred on the nvidia-container-toolkit pod of a GPU node.The pod status was CrashLoopBackOff. At first glance, it appeared to be a simple pod configuration issue.However, log analysis revealed that the root cause was a corruption of the containerd socket file type, which is part of Kubernetes’ container…

Zabbix 모니터링 시스템에서 GPU 노드의 nvidia-container-toolkit 파드에 경고 알람이 발생했다. 상태는 CrashLoopBackOff. 단순한 파드 설정 오류로 보였으나, 로그 분석 결과 Kubernetes의 컨테이너 런타임인 containerd의 소켓 파일 형상(Type) 변질이 근본 원인임이 밝혀졌다. 본 포스팅에서는 해당 이슈의 트러블슈팅 과정과 더불어, Kubernetes 및 GPU 환경에서 containerd가 수행하는 역할과 장애 발생 시의 영향도를 상세히 기술한다. 1. 배경 지식: Containerd의…

In Kubernetes environments, it’s common to see intermittent timeouts when using NodePort services, calling external APIs, or communicating between internal services.Pods appear healthy, nodes have available resources, and logs look clean—yet specific traffic paths intermittently drop packets for no obvious reason. When this happens repeatedly on Ubuntu-based Kubernetes nodes, the first thing to check is:…

Kubernetes 환경에서 NodePort, 외부 API 호출, 내부 서비스 간 통신이 간헐적으로 타임아웃 나는 경우가 있다.Pod도 정상이고, 노드 리소스도 여유 있고, 로그도 깨끗한데 특정 트래픽만 불규칙하게 drop되는 패턴이다. Ubuntu 기반 Kubernetes 노드에서 이런 현상이 반복될 때 가장 먼저 확인해야 하는 부분이 있다. 노드의 nf_conntrack 테이블이 한계에 도달했는지 여부다. Ubuntu는 기본적으로 적당한 conntrack 값을 제공하지만,Kubernetes 환경처럼 NAT이…

K8S Calico vs Cilium Among Kubernetes CNI plugins, the two names compared most often are Calico and Cilium.Both handle Pod-to-Pod communication, but their approaches could not be more different. Calico relies on traditional Linux networking — iptables and BGP — to build a simple and predictable L3 network.Cilium, on the other hand, uses eBPF to…

K8S Calico vs Cilium 쿠버네티스 네트워크 플러그인(CNI) 중 가장 자주 비교되는 두 이름, Calico와 Cilium.둘 다 Pod 간 통신을 책임지는 핵심 구성요소지만, 접근 방식은 완전히 다르다.Calico는 전통적인 리눅스 네트워킹 — iptables와 BGP를 이용해 단순하고 예측 가능한 L3 네트워크를 만든다.반면 Cilium은 eBPF를 기반으로 커널 수준에서 트래픽을 직접 제어하며, L7까지 관찰과 정책을 확장한다. 결국 이 비교는 “어떤…

Operating a Kubernetes cluster in a completely disconnected (air-gapped) environment requires more than just installation.All operational components — OS packages, container images, backup and recovery systems, and monitoring — must circulate entirely within the internal network. The following design illustrates a practical Kubernetes cluster architecture applicable to real-world air-gapped environments. 1. Overall Architecture This architecture…

외부 인터넷이 완전히 차단된 환경에서도(Air_Gapped) Kubernetes 클러스터를 안정적으로 운영하려면 단순히 클러스터를 설치하는 것만으로는 부족하다.운영체제 패키지, 컨테이너 이미지, 백업·복구, 모니터링 체계까지 내부망 내에서 완전하게 순환하도록 설계해야 한다. 아래의 구성은 실제 폐쇄망(Air-Gapped) 환경에서 적용 가능한 Kubernetes 클러스터 아키텍처의 예시다. 1. 전체 구조 개요 이 아키텍처는 보안 경계를 명확히 나눈 3계층 구조로 구성된다. 외부 사용자는 직접 내부망으로 접근할…

50-Node ML Kubernetes Cluster Design This document explains how to design a Kubernetes cluster optimized for machine learning workloads in an on-premises environment combining both CPU and GPU nodes.The core goals are efficient GPU resource utilization and high-performance I/O through a tiered storage architecture. 1. Overview The cluster consists of 50 nodes (15 GPU +…

50-node ML Kubernetes Cluster 설계 사례이 문서는 CPU와 GPU 노드가 혼합된 On-Prem 환경에서 ML 워크로드를 위한 Kubernetes Cluster를 어떻게 설계해야 하는지 설명한다.핵심 목표는 GPU 자원의 효율적 활용과 고성능 I/O를 위한 스토리지 계층화다. 1. 전체 구조 개요 클러스터는 총 50노드( GPU 15대 + CPU 35대 )로 구성된다.GPU 노드는 주로 학습(Training), CPU 노드는 전처리, 데이터 적재, 서빙(Serving)용으로…