Kubernetes의 Service - Kube proxy, DNS, Readiness Probe

혹시·2024년 11월 7일

K8S

목록 보기

11/11

Kubernetes에서의 kube-proxy 역할

Kubernetes의 kube-proxy는 클러스터 내에서 서비스의 네트워크 규칙을 설정하고 관리하는 역할을 합니다. kube-proxy는 각 노드에서 실행되며, IPVS 또는 iptables 모드를 선택하여 트래픽을 처리합니다. kube-proxy는 클러스터의 Control Plane과 Worker 노드 사이의 연결을 관리하여, 서비스가 올바르게 작동하도록 합니다

kube-proxy는 여러 모드에서 작동할 수 있는데, 그 중 두 가지가 바로 IPVS와 iptables입니다.

IPVS는 더 나은 성능과 확장성을 제공하는 로드 밸런싱 기술로, 대규모 클러스터에서의 네트워크 요청을 효율적으로 처리하는 데 유리합니다. 반면, iptables는 리눅스 커널의 방화벽 기능을 활용하여 기본적인 트래픽 관리 기능을 제공하지만, 많은 규칙이 있을 때 성능 저하가 발생할 수 있습니다.

IPVS는 iptables에 비해 훨씬 높은 성능을 자랑합니다. 특히, 트래픽이 많은 환경에서는 IPVS가 더 적합합니다. IPVS는 상황에 따라 적절한 로드 밸런싱 알고리즘을 선택하여 트래픽을 분산시킬 수 있으며, 이는 iptables의 단순 규칙 기반 접근 방식보다 훨씬 더 효율적입니다.

IPVS와 iptables의 구조

IPVS는 해시 테이블을 이용해 요청을 처리하며, 이를 통해 짧은 시간 안에 요청을 빠르게 라우팅할 수 있는 장점이 있습니다. 반면 iptables는 규칙 기반 시스템으로, 각 요청이 해당 규칙을 따르는지를 확인해야 합니다. 이러한 차이로 인해 IPVS는 더 복잡한 로드 밸런싱 알고리즘을 지원할 수 있으며, 높은 트래픽을 보다 효율적으로 처리할 수 있습니다

https://www.linkedin.com/pulse/iptables-vs-ipvs-kubernetes-vivek-grover

iptables 모드의 한계

iptables는 간단한 설정과 관리가 가능하지만, 많은 규칙이 있을 경우 성능이 급격히 떨어지는 문제가 있습니다. 예를 들어, 5000개 이상의 규칙이 등록된 경우, 네트워크 성능이 저하될 수 있습니다. 이러한 문제는 대규모 트래픽을 처리해야 하는 환경에서 큰 단점으로 작용할 수 있습니다

https://mokpolar.tistory.com/66

DNS

Kubernetes는 클러스터에서 실행 중인 pod에 대해 DNS 서비스를 제공한다. k8s 설치 시 시스템 구성 요소로 설치되며 Service의 클러스터 IP에 대한 DNS 이름도 제공한다.

alpaca와 deployment/service 생성

apiVersion: apps/v1
kind: Deployment
metadata:
  name: alpaca-prod
  labels:
    ver: "1"
    app: alpaca
    env: prod
spec:
  replicas: 3
  selector:
    matchLabels:
      app: alpaca
  template:
    metadata:
      labels:
        app: alpaca
        ver: "1"
        env: prod
    spec:
      containers:
      - name: kuard
        image: gcr.io/kuar-demo/kuard-amd64:1
        ports:
        - containerPort: 8080

---
apiVersion: v1
kind: Service
metadata:
  name: alpaca-service
spec:
  type: ClusterIP
  selector:
    app: alpaca
  ports:
  - port: 8080
    targetPort: 8080

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: bandicoot-prod
  labels:
    ver: "2"
    app: bandicoot
    env: prod
spec:
  replicas: 2
  selector:
    matchLabels:
      app: bandicoot
  template:
    metadata:
      labels:
        app: bandicoot
        ver: "2"
        env: prod
    spec:
      containers:
      - name: kuard
        image: gcr.io/kuar-demo/kuard-amd64:2
        ports:
        - containerPort: 9090

---
apiVersion: v1
kind: Service
metadata:
  name: bandicoot-service
spec:
  type: ClusterIP
  selector:
    app: bandicoot
  ports:
  - port: 9090
    targetPort: 9090
-------------------------------------------
kubectl apply -f deployment-services.yaml

Service에 햘당된 ip주소를 확인 후 alpaca deployment pod중 하나로 포트포워딩을 구성한다. -> http://localhost:48858/

kubectl get services -o wide
ALPACA_POD=$(kubectl get pods -l app=alpaca -o jsonpath='{.items[0].metadata.name}')
$ALPACA_POD
kubectl port-forward $ALPACA_POD 48858:8080

DNS Query 탭에서 name에 alpaca-prod를 입력하고 FQDN 값을 확인한다. 쿼리 응답에 표시되는 ip가 service의 cluster-ip열에 표시된 ip와 동일한지 확인한다.

네이밍 형식

Service 이름 + 네임스페이스 + 클러스터의 기본 도메인 이름

Probe

프로브는 쿠버네티스에서 컨테이너의 상태를 확인하는 방법입니다. Liveness Probe와 Readiness Probe 두 가지가 있으며, 각각의 역할이 다릅니다. Liveness Probe는 컨테이너가 정상적으로 작동하고 있는지를 확인하고, 문제가 발생할 경우 컨테이너를 재시작합니다. 반면, Readiness Probe는 컨테이너가 트래픽을 수신할 준비가 되었는지를 판단합니다.

Readiness Probe

<해당 Pod가 클라이언트 요청을 처리할 준비가 되었는지를 판단하는 메커니즘>
Readiness Probe는 Kubernetes에서 Pod의 가용성을 관리하는 데 중요한 역할을 하며, 적절한 설정과 모니터링을 통해 애플리케이션의 안정성을 유지할 수 있다.

Readiness Probe의 작동 원리

Readiness Probe는 주기적으로 컨테이너의 상태를 확인합니다. 이 프로브는 HTTP 요청, TCP 소켓, 또는 실행 가능한 명령어를 통해 작동할 수 있습니다. 예를 들어, HTTP 요청을 통해 "/ready" 엔드포인트에 접근하여 응답을 확인할 수 있습니다. 만약 응답이 성공적이라면, 해당 컨테이너는 트래픽을 수신할 준비가 된 것으로 간주됩니다. 반면, 실패할 경우 해당 컨테이너는 트래픽을 수신하지 않게 됩니다.

https://kubeops.net/blog/kubernetes-probes

Readiness Probe 설정 방법

쿠버네티스의 YAML 파일에서 readinessProbe 섹션을 추가하면 됩니다. 예를 들어, 다음과 같은 형식으로 설정할 수 있습니다:

kubectl edit deployments/alpaca-prod
---------------------------------------
spec:
 template:
	 spec:
 		containers:
 		- image: gcr.io/kuar-demo/kuard-amd64:1
 		  imagePullPolicy: IfNotPresent
 		  name: alpaca-prod
         readinessProbe:
 			httpGet:
 				path: /ready
 				port: 8080
 			periodSeconds: 2
 			initialDelaySeconds: 0
 			failureThreshold: 3
 			successThreshold: 1
		 ports:
		 - containerPort: 8080
		   protocol: TCP

http://localhost:48858에서 endpoint를 확인한다.
Endpoint는 Service가 트래픽을 프록시하는 백엔드 pod를 의미하고, readiness probe 에서 status 500을 발생시켜 endpoint가 변경되는 것을 볼 것이다.

ALPACA_POD=$(kubectl get pods -l app=alpaca -o jsonpath='{.items[0].metadata.name}')
kubectl port-forward $ALPACA_POD 48858:8080
kubectl get endpoints
kubectl get endpoints alpaca-prod --watch

Readiness probe 탭에서 프로브가 2초마다 실행하는 것을 확인
fail을 클릭하여 status 500 발생
bash 세션에서 특정 pod ip가 제거된 것 확인

status200 코드일 때 다시 3개가 표기 되는 것 확인

Readiness Probe의 활용 사례

Readiness Probe는 다양한 상황에서 유용하게 사용될 수 있습니다. 예를 들어, 데이터베이스 연결을 설정하는 데 시간이 걸리는 애플리케이션에서는 초기 로딩 시간이 필요합니다. 이 경우 Readiness Probe를 사용하여 애플리케이션이 완전히 준비될 때까지 트래픽을 수신하지 않도록 설정할 수 있습니다.