DevOps Colleague

kubectl로 CRD(CustomResourceDefinition)를 생성하면 Kubernetes API 서버에 새로운 “Custom API”가 등록됩니다.즉, kubectl create -f mycrd.yaml 같은 명령어로 CRD를 적용하면, Kubernetes는 해당 리소스를 공식 리소스처럼 인식하게 돼요. CRD를 생성하면 무슨 일이 벌어질까? 1. apiextensions.k8s.io/v1의 CRD 오브젝트가 etcd에 저장됨 2. Kubernetes API 서버가 동적으로 해당 CRD를 감지 3. 지정된 group, version, kind에 따라 새로운 RESTful API endpoint가 자동으로 생성됨 • 예: myresources.mygroup.example.com/v1 4. kub..

Kubebuilder와 Operator SDK는 둘 다 Kubernetes Operator를 Go 언어로 개발하기 위한 프레임워크이지만,역사적 배경과 구조적으로 다르면서도 현재는 거의 “합쳐졌다”고 볼 수 있어요.항목KubebuilderOperator SDK만든 곳Kubernetes SIG API Machinery (공식)Red Hat (Operator Framework 프로젝트)내부 구조controller-runtime 기반초기엔 다름, 현재는 Kubebuilder를 내부에 사용현재 관계독립 CLI + scaffolding 툴Kubebuilder 위에 Operator 관련 기능을 추가한 도구 Kubebuilder란? • Kubernetes 공식 SIG에서 개발한 Operator scaffolding 도..

client-go는 무엇인가? • client-go는 Kubernetes 프로젝트 하위에 있는 공식 Go 클라이언트 라이브러리 • 위치: https://github.com/kubernetes/client-go • 원래는 Kubernetes의 k8s.io/kubernetes 코드베이스 내부에 있던 것을 분리해서 라이브러리화한 것 • kubectl도 내부적으로 client-go를 사용해요만든 주체Kubernetes 프로젝트 (CNCF 산하, Go로 작성)관리 위치https://github.com/kubernetes/client-go소유권Kubernetes SIG API Machinery 팀라이선스Apache 2.0  • kubebuilder는 Kubernetes Operator를 Go로 쉽게 개발할 수 있게..

Calico와 Cilium은 둘 다 고급 Kubernetes 네트워크 플러그인이며, 보안 정책과 고성능 네트워킹을 제공하지만 철학과 기술 스택이 완전히 다릅니다.Calico는 전통적인 Linux 커널 기능(iptables, routing, BGP 등)을 기반으로 하고,Cilium은 eBPF (Extended Berkeley Packet Filter) 를 핵심으로 삼아 더 현대적인 접근 방식을 제공합니다.  Calico vs Cilium 비교 항목CalicoCilium기반 기술Linux 커널의 iptables, routing, BGPeBPF (커널 수준 가상 머신)eBPF 지원✅ (선택적 eBPF 지원)✅ 기본 eBPF 기반네트워크 모델L3 라우팅 또는 VXLAN 오버레이eBPF 기반 L3/L4/L7 aw..

Kubernetes는 다음과 같은 네트워크 요구 사항을 기본 가정으로 합니다:모든 Pod는 클러스터 내 다른 Pod와 통신 가능해야 한다.노드에서 실행 중인 모든 Pod는 동일한 IP 주소 체계를 공유해야 한다.NAT 없이 Pod 간 직접 통신이 가능해야 한다.이러한 요구사항을 충족시키기 위해 Kubernetes는 CNI 플러그인, Service IP, kube-proxy, Network Policy 등을 이용합니다. 주요 구성 요소1. CNI 플러그인Pod 간 통신을 위한 네트워크 인터페이스를 설정Pod에 IP를 할당하고 라우팅 설정을 적용예시: Calico, Flannel, Cilium, Weave 2. kube-proxyService 리소스의 가상 IP로 요청이 들어오면 실제 Pod IP로 라우팅되..

StatefulSet + headless service 조합은 Kubernetes에서 PostgreSQL처럼 상태(stateful)를 가진 애플리케이션을 배포하고, 노드 간 안정적인 네트워크 ID를 제공하는 핵심 메커니즘입니다.특히, PostgreSQL의 클러스터링 구성이나 장애조치(failover) 시 이 구조가 중요한 역할을 해요. ✅ 1. Headless Service란?apiVersion: v1kind: Servicemetadata: name: postgresspec: clusterIP: None # 👈 headless로 만듦 selector: app: postgres ports: - port: 5432 📌 핵심 특징:항목설명clusterIP: NoneCluster IP가 ..

Kubernetes Operator를 만들 때 Reconcile 루프를 일정 시간 후 다시 실행하도록 예약하는 메커니즘입니다.Kubernetes의 controller-runtime 라이브러리에서 주로 사용되고, 특히 외부 상태 동기화, 실패 재시도, 일정 주기 polling이 필요할 때 유용해요. 기본 개념: RequeueAfterreturn ctrl.Result{RequeueAfter: 30 * time.Second}, nil 이 코드는 다음과 같은 의미예요:"현재 리소스에 대해 30초 후에 다시 Reconcile을 호출해줘."즉, Reconcile을 강제로 예약해서 재호출하도록 만드는 기능입니다. 왜 필요할까?Reconcile() 함수는 일반적으로 리소스에 이벤트가 발생했을 때만 호출됩니다.하지만 다..

Kubernetes의 동작 철학 중 하나인 Level-Triggered 방식은 Kubernetes가 어떻게 상태를 감지하고 반응(reconcile) 하는지를 이해하는 데 아주 핵심적인 개념입니다.이걸 Edge-Triggered와 비교하면서 설명하면 훨씬 명확해져요. Kubernetes는 Level-Triggered 방식으로 동작하며,이는 Polling 기반 + 이벤트 알림을 혼합한 구조예요.핵심은 “현재 상태와 원하는 상태의 차이를 계속 관찰하고, 필요할 때만 동작”한다는 점입니다. 개념 정리구분Edge-TriggeredLevel-Triggered (K8s 방식)의미변화가 발생했을 때만 트리거됨원하는 상태와 현재 상태의 차이를 지속적으로 확인예시파일이 변경된 순간에만 이벤트 발생“이 파일이 이 상태인지”..