CloudNet@ 가시다님이 진행하는 쿠버네티스 네트워크 스터디 KANS 3기 내용을 정리한 글입니다. CoreDNS쿠버네티스에서는 서비스를 생성하면 해당 서비스 명이 도메인 명이 되어 호출이 가능해진다. 이것을 가능하게 해주는것은 coredns로 쿠버네티스를 설치하면 kube-system에 가면 들어있는 도메인 서버이다. 플러그인도 다양하게 있어서 기본 설정 이외에도 플러그인으로 추가하여 기능을 확장할 수도 있습니다. https://coredns.io/ CoreDNS: DNS and Service Discovery coredns.io 기본 설정 이해하기처음에 쿠버네티스를 설정하면 다음과 같이 설정되어있습니다..:53 { # CoreDNS가..
CloudNet@ 가시다님이 진행하는 쿠버네티스 네트워크 스터디 KANS 3기 내용을 정리한 글입니다. 이전 글에서 Istio의 Gateway API를 다뤘다면, 이번에는 Cilium의 Gateway API에 대해 살펴보려 합니다. Gateway API에 대해 더 알고 싶으신 분들은 이전 글을 참고해 주세요. Cilium의 Gateway APICilium의 Gateway API는 다른 Ingress 컨트롤러들과는 크게 다른 부분이 Cilium에서는 네트워크 스택과 깊이 통합된다는 것입니다. 무슨말이냐면 보통의 Gateway API는 gateway 생성시 Deployment 형태로 설치되고 LoadBalancer를 통해 트래픽을 처리하지만, Cilium가 네트워크 관리 도구(CNI)이기 때문에 Gatewa..
CloudNet@ 가시다님이 진행하는 쿠버네티스 네트워크 스터디 KANS 3기 내용을 정리한 글입니다. Istio는 서비스 메쉬 내에서 트래픽을 제어하기 위한 다양한 기능들을 제공해왔습니다. 반면, Gateway API는 표준화된 인터페이스를 제공하는 것을 목표로 하다 보니, 아직 Istio가 제공하던 모든 기능을 담기에는 한계가 있는 것 같습니다. 이번 글에서는 Istio를 사용하여 Gateway API를 직접 설치해보고, 기존 Istio의 트래픽 제어 방식과 비교해보려고 합니다. Istio 와 Gateway API 비교 📦 리소스 별 비교Istio에서 Gateway와 VirtualService는 서비스 메쉬의 트래픽을 관리하는 핵심 리소스입니다. Gateway는 외부에서 들어오는 트래픽을 받는..
CloudNet@ 가시다님이 진행하는 쿠버네티스 네트워크 스터디 KANS 3기 내용을 정리한 글입니다. Gateway APIIngress를 많이 사용하지 않았지만, 현재 회사에서 운영 중인 서비스 메시 정책들을 모두 Ingress로 변환하라는 요청이 들어온다면 매우 길고 복잡한 Ingress들이 다수 발생할 것 같습니다. 심지어 TCP/UDP 프로토콜로 개발된 서비스들도 일부 존재하기 때문에, Ingress만으로는 이 모든 서비스들을 처리하는 것이 불가능합니다. 운영하고 있는 쿠버네티스 클러스터는 큰 규모는 아니지만, 그럼에도 불구하고 이러한 다양한 요구 사항들이 발생하고 있습니다. 더 큰 규모의 클러스터를 운영하는 조직에서는 이러한 문제들이 더욱 빈번하게 나타날 것이며, 당연히 Ingress에 대한 개..
CloudNet@ 가시다님이 진행하는 쿠버네티스 네트워크 스터디 KANS 3기 내용을 정리한 글입니다. Ingress기존의 쿠버네티스에 존재하던 NodePort 및 LoadBalancer의 경우 단순한 로드밸런서 외에는 아무런 기능을 하지 못했다. 이러한 한계점을 보완하고자 나온 것이 Ingress이다. 하지만 이 Ingress에는 단점이 많이 존재함으로 만약 처음 공부하고 계신 분이라면 Gateway API를 먼저 알아보는 것을 추천한다. Ingress도 한계점이 많아 새롭게 만들어진것이 Gateway API이다. 그래서 심지어 Ingress에는 더 이상 기능이 추가 되지 않는다. 기본적으로 쿠버네티스에서 만들어진 서비스라는 객체는 L4레이어에서 동작하는 로드밸런서라고 생각하면 좋을 것 같다. ..
쿠버네티스 클러스터 관련하여 다양한 테스트를 하다 보면 네트워크 대역이 다른 두 개의 클러스터가 필요할 때가 있다.단순히 파드나 서비스 대역이 다른 것이 아닌, 노드 대역을 다르게 설정하려면 Docker 컨테이너의 네트워크 대역이 달라야 한다.Docker 컨테이너 네트워크 생성green 클러스터를 위한 네트워크 브리지를 하나 생성한다.docker network create --subnet=172.18.0.0/16 green-net 이번에는 다른 클러스터를 위한 blue 네트워크 브리지를 생성한다.docker network create --subnet=172.19.0.0/16 blue-net 생성 후 확인하면 브리지 네트워크가 생성된 것을 볼 수 있다. green 클러스터 생성하기 환경변수를 이용하여 실..
Maglev는 Google에서 개발한 로드밸런싱 알고리즘으로, 백엔드 서버 간의 부하를 효율적으로 분산하는 역할을 합니다. 핵심 아이디어Maglev의 핵심 아이디어는 다음과 같습니다:소수 M 크기의 해시 테이블(슬롯)을 만든다.각 백엔드에 대해 “슬롯에 들어갈 순서”를 (offset, skip)으로 계산해시 테이블에 차례로 백엔드를 배정해 나가며, 슬롯이 이미 차 있으면 다음 순서로 건너뛴다. Maglev 동작 상세하게 살펴보기초기 설정 lb에 달려있는 백엔드가 이렇게 3개있고 이렇게 해시 테이블의 사이즈가 7일때 해시 알고리즘 2개를 이용해서 해시 테이블을 구성합니다. 오프셋 계산을 위한 해시 알고리즘 얼마만큼 건너뛸건지를 계산할 해시 알고리즘 이렇게 해서 다음과 같이 먼저 각각의 백엔드 값을 ..
cilium 설치하기 cilium install --version 1.17.1 -n kube-system \ --set kubeProxyReplacement=true \ --set k8sServiceHost=${API_SERVER_IP} \ --set k8sServicePort=${API_SERVER_PORT} \ --set hubble.enabled=true \ --set hubble.relay.enabled=true \ --set hubble.ui.enabled=true \ --set prometheus.enabled=true \ --set operator.prometheus.enabled=true \ --set hubble.metrics.enableOpenMetrics=true \ ..
CloudNet@ 가시다님이 진행하는 쿠버네티스 네트워크 스터디 KANS 3기 내용을 정리한 글입니다. IPVS 모드IPVS 는 리눅스 커널에서 동작하는 소프트웨어 로드밸런서이다. 백엔드(플랫폼)으로 Netfilter 를 사용하며, TCP/UDP 요청을 처리 할 수 있다. PVS는 L4 계층에서 동작하며, 다양한 로드 밸런싱 알고리즘을 통해 서비스 요청을 여러 백엔드 서버로 분산시켜 트래픽을 효율적으로 관리합니다. 이를 통해 대규모 트래픽 환경에서도 안정적인 서비스를 제공하며, 고성능 로드 밸런싱을 필요로 하는 Kubernetes 클러스터에서 주로 사용됩니다. IPVS 모드는 커널 레벨에서 직접 작동하기 때문에 빠르고 확장성 있는 네트워크 트래픽 처리가 가능합니다. iptables 의 rule 기반 처리..
cilium에서는 egress gateway를 지원하는데 별도의 파드가 뜨는 방식이 아닌 노드를 egress 노드로 만들어서 해당 노드에 설정되어있는 아이피로 변환시키는 방법을 사용합니다. 한번 직접 테스트를 해보도록 하겠습니다. kind: ClusterapiVersion: kind.x-k8s.io/v1alpha4nodes:- role: control-plane- role: worker- role: worker- role: workernetworking: disableDefaultCNI: true # kind cni 설치 안하기 kubeProxyMode: "none" # kube-proxy 설치 안하게 하기 바로 kind로 클러스터 생성하고 cilium도 설치해 줍니다. API_SERVER=$(..
어느 날 잘 동작하던 nginx가 갑자기 DNS 리졸빙에 실패하면서 에러가 발생했습니다. nginx를 proxy로 사용하고 있었는데, 특정 서비스로 요청을 보내지 못하고 DNS를 해결하지 못하는 문제가 발생했습니다. 🚨 이슈nginx의 proxy_pass로 설정된 도메인으로의 요청이 갑자기 모두 실패하기 시작했습니다.could not be resolved (110: Operation timed out) 🔍 원인CoreDNS의 재시작이 문제의 원인이었습니다. CoreDNS가 재시작되었지만, nginx는 이전에 연결되어 있던 CoreDNS 정보를 계속 참조했습니다. 이로 인해 nginx는 UDP 통신을 통해 사라진 CoreDNS로 요청을 시도했고, 그 결과 conntrack 테이블에는 이미 삭제된 Cor..
Selective Service Node Exposure는 서비스를 생성하고 그 서비스를 통해 트래픽을 받을 수 있는 노드를 설정 할 수 있는 기능입니다. 1.17버전 부터 사용이 가능합니다. 아래의 그림에서 처럼 서비스의 annotations에 정의되어있는 service.cilium.io/node의 값과 같은 값을 갖고 있는 노드에서만 해당 서비스로 호출이 가능합니다. 서비스가 아닌 파드아이피로 직접 호출할 때에는 어디에서든지 통신이 가능합니다. 직접 테스트 해보기노드에 라벨을 붙이고 나면 cilium과 오퍼레이터를 재시작 해야하기 때문에 이번엔 클러스터 생성할 때 부터 라벨을 붙여보겠습니다.cat > labeled-cilium.yaml 라벨이 잘 들어가져있나 확인해봅니다. cilium을 설치합..
클러스터 만들기우선 멀티클러스터 구성을 위한 클러스터 2개를 생성해야합니다. 아래의 그림과 같은 구성으로 클러스터를 만들 예정입니다. Blue 클러스터 생성하기파일을 구분짓기 쉽기 위해 blue 폴더 내에 만들었습니다.# blud/config.yamlkind: ClusterapiVersion: kind.x-k8s.io/v1alpha4nodes: - role: control-plane - role: worker - role: worker - role: workernetworking: disableDefaultCNI: true kubeProxyMode: "none" podSubnet: "10.1.0.0/16" serviceSubnet: "10.2.0.0/16" 아래의 명령어로 blue 클러스터..
irqbalance와 CPU Pinning의 원리시스템에서 발생하는 하드웨어 인터럽트(IRQ)는 프로세서가 작업을 수행하는 동안 네트워크 패킷 처리, 디스크 I/O 등 다양한 작업을 중단시키는 역할을 한다. irqbalance는 이러한 인터럽트를 여러 CPU 코어에 분산시켜 특정 코어에 과부하가 걸리지 않도록 도와준다. 하지만 모든 환경에서 항상 효과적이지는 않다. 특히 Cilium과 같이 높은 네트워크 성능이 필요한 경우, 인터럽트가 무작위로 여러 코어에 분산되면 캐시 미스가 발생하고 인터럽트 처리 지연이 늘어나면서 성능이 저하될 수 있다. 이러한 문제를 해결하기 위해 CPU Pinning을 적용하면 특정 NIC 인터럽트를 특정 CPU 코어에 고정할 수 있다. 이를 통해 CPU 코어와 메모리 간의 캐시..
Calico를 사용하는 환경에서 BIRD 프로세스에 문제가 발생하면 라우팅 정보가 제대로 전달되지 않아 네트워크 성능 저하나 장애가 발생할 수 있다. 이러한 상황을 진단하기 위해 BIRD 프로세스의 상태를 분석하는 것이 중요한데, 이를 위해 SIGUSR1 신호를 보내면 BIRD의 상세 상태와 라우팅 테이블 정보를 덤프할 수 있다. 이 글에서는 호스트에서 컨테이너 내부의 BIRD 프로세스에 SIGUSR1 신호를 보내는 방법을 단계별로 설명한다. 호스트에서 BIRD 프로세스 찾기우선 호스트에서 pidof 명령어를 사용해 BIRD 프로세스의 PID를 찾는다.pidof bird 이렇게 하면 호스트에서 BIRD 프로세스의 PID를 얻을 수 있다. 컨테이너 내부의 PID 찾기다음으로, 해당 PID를 사용하여 /pr..
Metric Server는 쿠버네티스 클러스터의 자원 사용량(CPU, 메모리 등)을 수집해주는 필수적인 구성 요소 중 하나입니다. HPA(Horizontal Pod Autoscaler)나 kubectl top 명령어를 사용하려면 Metric Server가 설치되어 있어야 합니다. 하지만 기본적으로 쿠버네티스 클러스터에는 Metric Server가 포함되어 있지 않습니다. 이 문서에서는 Metric Server 설치 여부를 확인하는 방법과 설치하는 방법에 대해 설명합니다. 설치 여부 확인Metric Server가 클러스터에 설치되어 있는지 확인하려면 다음 명령어를 실행합니다쿠버네티스 클러스터의 각 노드에 대한 실시간 자원을 보여주는 명령어입니다.kubectl top nodes 결과 - Metric Ser..
지난 AWSKRUG 플랫폼엔지니어링 밋업에서 소개받은 KEDA에 대해 설명해볼까 합니다. 쿠버네티스에는 Auto Scaling을 위한 Horizontal Pod Autoscaling이 있습니다. 하지만 이 기본적인 HPA(Horizontal Pod Autoscaler)는 CPU나 메모리 사용량만을 기준으로 확장 정책을 설정할 수 있습니다. 이러한 한계를 극복하기 위해 등장한 것이 바로 KEDA(Kubernetes Event-driven Autoscaling)입니다. KEDA란?KEDA는 Kubernetes에 이벤트 기반 확장 기능을 추가하는 오픈소스 프로젝트입니다. KEDA는 애플리케이션 워크로드를 이벤트 매개 변수에 따라 동적으로 확장하거나 축소할 수 있도록 지원하며, 클라우드 네이티브 애플리케이션을..
istio를 멀티 클러스터 환경으로 구성하기 위해서는 두 클러스터가 동일한 ca를 사용해야한다.이번 글에서는 istio 멀티 클러스터 구성을 위한 인증서 구성 방법에 대해 작성해보려고 한다.root-ca 생성하기istioctl 설치 파일을 다운받으면 해당 파일 내에 tools라는 폴더가 존재한다. 만약 내 환경에 어디있는지 모르겠다면 istio github의 최상위에 tools라는 폴더가 존재한다. 해당 폴더 아래에 certs라는 폴더가 있다. 🗂️ 여기를 다운받자.https://github.com/istio/istio/tree/master/tools/certs istio/tools/certs at master · istio/istioConnect, secure, control, and observe ..
CloudNet@ 가시다님이 진행하는 쿠버네티스 네트워크 스터디 KANS 3기 내용을 정리한 글입니다. 서비스에는 로드밸런스 타입과 다르게 수동으로 외부 IP를 할당하여 노출시킬 수 있는 방법이 있습니다. 외부 IP는 쿠버네티스 클러스터에서 IP 할당을 관리하지 않습니다. 직접 테스트해보기kind를 통해 여러 개의 노드로 구성된 클러스터를 생성하고, 가상의 IP를 하나 생성하여 연결해보겠습니다. 이제 pod와 서비스를 각각 생성하겠습니다.# 파드 생성하기 kubectl run nginx --image=nginx:latest# 서비스 생성하기kubectl expose pod nginx --port 80 이렇게 생성하면 ClusterIP로 설정되기 때문에 여기에 external IP를 추가해보겠습니다.ex..
CloudNet@ 가시다님이 진행하는 쿠버네티스 네트워크 스터디 KANS 3기 내용을 정리한 글입니다. LoadBalancer 란NodePort는 각 노드의 특정 포트를 통해 외부 트래픽을 전달합니다. 이 방식의 장점은 클러스터 외부에서 접근이 가능하다는 점이지만, 고정된 IP가 없고 포트 범위에 제약이 있어 대규모 서비스나 고가용성이 필요한 경우 한계가 있습니다. 반면, LoadBalancer는 클라우드 환경에서 자동으로 로드밸런서를 생성해 고정된 외부 IP를 제공합니다. 이를 통해 여러 파드에 트래픽을 효율적으로 분산할 수 있습니다. 그러나 이 방식을 사용하려면 클라우드 프로바이더와의 연동이 필요합니다. 클라우드 환경에서는 이 연동이 자동화되어 매우 편리하지만, 온프레미스 환경이나 특정 네트워크 구성..