김마늘의 테크 레시피

Cilium Study의 긴 여정이 드디어 마지막 주제에 도달했습니다. 우리는 CNI의 기본부터 서비스 메시, 성능 튜닝에 이르기까지 Cilium이 제공하는 강력한 기능들을 단계별로 학습했습니다. 이 모든 기술의 정점에는 바로 '보안' 이 있습니다. 동적이고 예측 불가능한 클라우드 네이티브 환경에서, 어떻게 우리의 애플리케이션과 데이터를 안전하게 보호할 수 있을까요?이번 마지막 포스팅에서는 기존의 경계 기반 보안 모델의 한계를 짚어보고, Cilium이 제로 트러스트(Zero Trust) 원칙을 어떻게 네트워크 정책에 구현하는지 살펴봅니다. 또한, 네트워크를 넘어 커널 레벨의 행위까지 감지하고 차단하는 eBPF 기반의 혁신적인 런타임 보안 솔루션, Tetragon의 세계로 깊이 들어가 보겠습니다.1. 경계..

지금까지 우리는 Cilium의 다양한 네트워킹 및 보안 기능을 학습하며 강력한 쿠버네티스 클러스터를 구축하는 방법을 익혔습니다. 하지만 클러스터의 규모가 수백, 수천 개의 노드로 확장되고 수만 개의 파드가 동작하는 대규모 환경이 되면, 우리는 새로운 도전에 직면하게 됩니다. 바로 '성능' 입니다. 응답이 느려지는 API 서버, 원인 모를 파드 생성 실패, 간헐적인 네트워크 드롭 등은 클러스터의 안정성을 심각하게 위협할 수 있습니다.이번 7주차 스터디에서는 대규모 클러스터에서 발생할 수 있는 다양한 성능 병목 지점을 진단하고, 이를 해결하기 위한 구체적인 튜닝 전략을 심층적으로 다루고자 합니다. Kubernetes 컨트롤 플레인의 심장인 kube-apiserver와 etcd의 동작 원리부터 Cilium 데..

지난 5주차 스터디에서는 BGP와 ClusterMesh를 통해 클러스터의 경계를 넘어 외부 네트워크, 그리고 다른 클러스터와 통신하는 방법을 다루었습니다. 클러스터의 '남-북(North-South)' 트래픽과 클러스터 간 통신을 마스터한 셈이죠. 이제 우리의 시선은 다시 클러스터 내부로, 마이크로서비스 간의 복잡하고 동적인 '동-서(East-West)' 트래픽으로 향합니다. 바로 서비스 메시(Service Mesh) 의 영역입니다.이번 포스팅에서는 서비스 메시의 기본 개념부터 시작하여, 기존의 Sidecar 모델이 가졌던 한계와 이를 eBPF로 극복하는 Cilium의 혁신적인 접근법을 심층적으로 분석합니다. 또한, Ingress의 차세대 표준인 Gateway API와 강력한 워크로드 신원 증명 프레임워크..

지난 4주차 스터디에서는 Cilium의 LB-IPAM과 L2 Announcement 기능을 통해 온프레미스 환경에서도 LoadBalancer 타입의 서비스를 외부에 노출하는 방법을 알아보았습니다. L2 통신을 통해 외부 트래픽을 클러스터로 인입시키는 편리한 방법이었죠. 하지만 L2 통신은 동일 네트워크 대역이라는 한계를 가집니다. 만약 우리 클러스터가 여러 네트워크 대역에 걸쳐 있거나, 외부 라우터와 더 지능적으로 경로를 교환해야 한다면 어떻게 해야 할까요?이번 포스팅에서는 L3 라우팅 프로토콜의 표준인 BGP(Border Gateway Protocol) 를 Cilium과 연동하여 동적으로 라우팅 정보를 교환하는 방법을 알아보고, 한 걸음 더 나아가 여러 쿠버네티스 클러스터를 하나의 거대한 클러스터처럼 ..

지난 3주차 스터디에서는 IPAM, 라우팅, 마스커레이딩 등 파드 간 통신을 가능하게 하는 쿠버네티스 네트워킹의 내부 동작 원리를 깊이 있게 살펴보았습니다. 이제 클러스터라는 우리만의 세상 안에서 통신하는 법을 익혔으니, 드디어 클러스터 외부의 사용자들이 우리 애플리케이션을 만날 수 있도록 문을 열어줄 시간입니다.이번 포스팅에서는 쿠버네티스에서 외부 트래픽을 처리하는 핵심 관문인 Service의 동작 원리를 알아보고, Cilium이 제공하는 강력한 LoadBalancer 기능을 통해 온프레미스 환경에서도 클라우드처럼 서비스를 외부에 노출하는 방법을 자세히 다뤄보겠습니다.1. 쿠버네티스 Service 다시 보기: 왜 필요할까?쿠버네티스에서 파드는 언제든지 사라지고 다시 생성될 수 있는 '임시적인' 존재입니..

지난 스터디에서는 Hubble과 Grafana를 통해 클러스터의 네트워크 흐름과 시스템 상태를 관찰하는 방법을 알아보았습니다. 이제는 한 걸음 더 나아가, 그 내부에서 실제로 어떤 일들이 벌어지고 있는지 심층적으로 파헤쳐 볼 시간입니다. "파드들은 어떻게 IP 주소를 할당받을까?", "다른 노드에 있는 파드와는 어떻게 통신할까?", "클러스터 외부로는 어떻게 나갈까?"와 같은 근본적인 질문들에 답을 찾아보겠습니다.이번 포스팅에서는 Cilium이 쿠버네티스 네트워킹의 핵심 요소들을 어떻게 처리하는지, 그 세부 동작 원리를 중심으로 정리해 보겠습니다.1. IPAM: 파드에게 IP 주소를 나눠주는 방법IPAM(IP Address Management)은 새로 생성되는 파드에 IP 주소를 할당하고 관리하는 중요한..

[Cilium Study] 2주차 - 1. Cilium Hubble을 통한 네트워크 관측지난 1주 차 포스팅에서는 Cilium과 eBPF의 기본 개념을 맛보고, 복잡한 iptables의 세계에서 벗어날 수 있다는 희망을 보았습니다. 하지만 CNI를 설치하고 클러스터가 잘 동작한다고 해서 모든 것을tech-recipe.tistory.com 이전 Hubble 포스팅에서는 네트워크 흐름을 실시간으로 관찰하는 방법에 대해 알아보았습니다. 하지만 시스템의 상태를 지속적으로 추적하고 잠재적인 문제를 감지하기 위해서는 수치화된 데이터를 수집하고 분석하는 과정이 필수적입니다. 이것이 바로 모니터링(Monitoring) 의 영역입니다. 이번 포스팅에서는 Cilium 환경에서 모니터링 시스템의 표준으로 자리 잡은 Prom..

지난 포스팅에서는 Cilium과 eBPF의 기본 개념에 대해 다루었습니다. CNI가 정상적으로 배포되어 클러스터가 동작하더라도, 파드 간의 네트워크 흐름이나 적용된 정책을 직관적으로 파악하기는 어렵습니다. 이러한 내부 동작을 시각적으로 확인하고 분석하기 위해서는 별도의 관측 도구가 필요합니다. Cilium 환경에서 이 역할을 수행하는 것이 바로 Hubble(허블) 입니다. Hubble은 Cilium에 특화된 관측 가능성(Observability) 플랫폼으로, 이번 포스팅에서는 Hubble을 설치하고 활용하여 쿠버네티스 네트워크를 관찰하는 방법에 대해 알아보겠습니다.1. Hubble 소개 Hubble은 Cilium과 eBPF를 기반으로 구축된 분산 네트워킹 및 보안 관측 플랫폼입니다. eBPF를 직접 활용..

[Cilium Study] 1 주 차 - 2. CNI와 Kubernetes 네트워킹에서 이어집니다. [Cilium Study] 1주차 - 2. CNI와 Kubernetes 네트워킹이전 포스팅 [Ciliu Study] 1주 차 - 1. 실습 환경 구성에서 이어집니다. [Cilium Study] 1주차 - 1. 실습 환경 구성'가시다'님의 [Cilium Study] 1기의 내용을 정리하는 시리즈 구성의 포스팅을 시작하려고 합니tech-recipe.tistory.comiptables의 복잡한 작동 방식 지난 포스팅 말미에 'webpod' Service의 ClusterIP에 대한 라우팅 규칙에 대해서 잠깐 살펴보았습니다. 그 내용을 다시 복기해보면 다음과 같습니다.# webpod svc의 clsuter ip에 ..

이전 포스팅 [Ciliu Study] 1주 차 - 1. 실습 환경 구성에서 이어집니다. [Cilium Study] 1주차 - 1. 실습 환경 구성'가시다'님의 [Cilium Study] 1기의 내용을 정리하는 시리즈 구성의 포스팅을 시작하려고 합니다. 이번 스터디를 통해 Kubernetes의 Network에 대해 깊이 이해할 수 있기를 희망합니다. 본 포스팅은 [Ciliumtech-recipe.tistory.com 실습 환경인 VirtualBox와 Vagrant에 대해서는 어느 정도 파악이 완료되었습니다. 이제 본격적으로 CNI와 Kubernetes 네트워킹에 대해서 이해해 보는 시간을 가져보겠습니다.Kubernetes network model의 핵심 원칙 Services, Load Balancing, ..