쿠버네티스 서비스와 플라넬

https://koreatstm.tistory.com/188

쿠버네티스

저번에 쿠버네티스의 기본 개념과 구조에 대해서 알아봤다. 이번에는 세부적인 내용을 뜯어보도록 하자

 

네트워크 연결

도커는 컨테이너 내부와 컨테이너 외부의 네트워크가 독립적이다.

쿠버네티스는 파드 내부의 네트워크를 공유하기에 같은 파드의 컨테이너는 동일 네트워크를 공유한다.

이때, 중요한 것은 파드의 네트워크와 로컬 컴퓨터의 네트워크는 독립적으로 분리된다.

따라서, 쿠버네티스로 파드에서 컨테이너(예: flask)를 띄우고 요청 했을 때, 외부에서 해당 컨테이너에서 응답이 없는 것이다.

 

이때, 외부에서 해당 컨테이너에 접속하려면 2가지 방법이 존재한다.

1. 파드 내부로 들어가서 접근하기
2. 파드의 내부 네트워크를 외부에서도 접속할 수 있도록 포트 포워딩 

 

파드 내부로 들어가서 접근하기

# kubectl exec -it [파드명] -- bash
또는
# kubectl exec -it [파드명] -- sh

---Pod 내부---
$ curl localhost:80

참고: mac은 80번 포트 사용시 sudo 권한 필요

쿠버네티스에서는 파드 내부의 네트워크를 컨테이너가 공유해서 같이 사용하기 때문에, 파드로 접속해서 요청을 보냈을 때 정상적으로 응답

 

포트포워딩

# kubectl port-forward pod/[파드명] [로컬에서의 포트]:[파드에서의 포트]
$ sudo kubectl port-forward pod/nginx-pod 30001:8080

 

이미지 풀 정책

• 쿠버네티스가 yaml 파일을 읽어들여 파드를 생성할 때, 이미지를 어떻게 Pull할지에 대한 정책
  • Always: 무조건 레지스트리(ECR, DockerHub)에서 가져옴
  • IfNotPresent: 로컬에서 이미지를 찾아서 가져오고, 없다면 레지스트리에서 가져옴
  • Never: 무조건 로컬에서 가져옴
• 만약 Manifest에서 이미지 풀 정책을 명시 하지 않을 경우
  • 이미지 태그가 latest or 명시 안 됨: Always
  • 이미지 태그가 latest가 아닐 경우: IfNotPresent

 

실제 서비스를 운영하다보면 트래픽이 증가하고 이럴 때 서버를 수평 확장 할 수 있다.

서버를 3대로 만들어서 실습해보자

 

순서

1. Dockerfile 작성하기
2. Dockerfile을 바탕으로 이미지 빌드하기
3. 이미지가 잘 생성됐는 지 확인하기
4. 매니페스트 파일 작성하기
   1. yaml파일에 metadata 이름 여러개해서 띄우기
   2. 이걸 수동으로하지말고 deployment를 사용
5. 매니페스트 파일을 기반으로 파드(Pod) 생성하기

 

 

flask-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: flask-pod-1
spec:
  containers:
    - name: flask-container
      image: flask-server:latest  # Flask 서버 이미지를 사용
      imagePullPolicy: IfNotPresent
      ports:
        - containerPort: 5000  # Flask 기본 포트

---
apiVersion: v1
kind: Pod
metadata:
  name: flask-pod-2
spec:
  containers:
    - name: flask-container
      image: flask-server:latest  # Flask 서버 이미지를 사용
      imagePullPolicy: IfNotPresent
      ports:
        - containerPort: 5000  # Flask 기본 포트

---
apiVersion: v1
kind: Pod
metadata:
  name: flask-pod-3
spec:
  containers:
    - name: flask-container
      image: flask-server:latest  # Flask 서버 이미지를 사용
      imagePullPolicy: IfNotPresent
      ports:
        - containerPort: 5000  # Flask 기본 포트

$ kubectl apply -f flask-pod.yaml

 

3개의 Flask 서버를 띄우는 데 성공했다. 만약 서버가 300개라면? 

이를 수동으로 조절하면 불편하다. 자동화 할 수 있는 부분은 자동화를 하는것이 좋다.

이를 위해 Deployment를 사용한다.

 

Deployment가 무엇인지 모른다면 참고

https://koreatstm.tistory.com/188#Deployments%20and%20ReplicaSets-1

쿠버네티스

 

다시 간단하게 정리하면

• Deployment: 파드를 묶어서 관리하기 쉽게 하는 기능
• 장점
  • 파드 수 지정 -> 100개 지정하면 100개 생성
  • 파드 종료 시 new 파드 생성 통한 정해진 파드 수 맞춰짐

Deployment > Replica Set > Pod 순으로 관리한다.

 

 

Flask-deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: flask-deployment
spec:
  replicas: 3  # 파드 3개로 설정
  selector:
    matchLabels:
      app: flask-app  # 앱의 라벨을 통해 파드를 선택
  template:
    metadata:
      labels:
        app: flask-app  # 라벨을 일치시켜서 파드를 선택
    spec:
      containers:
        - name: flask-container
          image: flask-server:latest  # Flask 서버 이미지를 사용
          imagePullPolicy: IfNotPresent
          ports:
            - containerPort: 5000  # Flask 기본 포트

• 백엔드 서버 3개를 각각의 파드에 띄웠다. 실제 요청을 보낼 때는 각 서버에 균등하게 트래픽이 분배되어야 한다. 그런데 사용자보고 여러 백엔드 서버에 알아서 균등하게 요청을 하라고 시킬 수는 없다.
• 따라서 파드 앞단에 알아서 여러 파드에 균등하게 요청을 분배해줄 무언가가 필요하다.  -> Service

 

서비스

 

그렇다면 컨테이너에 접속하려면 어떻게 해야할까?

쿠버네티스에서 컨테이너(파드)에 접속하려면 직접 접근하는 것이 아니라 서비스를 통해 접속해야 한다. 서비스는 엔드포인트를 제공하여 컨테이너에 대한 접근을 간접적으로 관리하며, 로드 밸런싱 기능도 수행한다.

 

서비스의 역할

 

역할 1: 컨테이너 접속을 위한 엔드포인트 제공

• 도커에서는 컨테이너 실행 시 호스트 컴퓨터의 포트와 컨테이너의 포트를 바인딩하여 접속한다.
• 하지만 쿠버네티스에서는 파드가 ReplicaSet과 Deployment에 의해 생성·삭제되며, 실행 위치도 변할 수 있다.
• 따라서, 서비스는 가상 IP와 엔드포인트를 제공하여 파드가 변경되더라도 일정한 방식으로 접근할 수 있도록 한다.

역할 2: 로드 밸런싱

• 서비스는 여러 개의 동일한 파드가 있을 때, 트래픽을 균등하게 분산하여 특정 파드에 부하가 집중되지 않도록 한다.
• 이를 통해 애플리케이션의 안정성을 높이고 성능을 최적화할 수 있다.

 

서비스 구조

서비스는 가상IP주소와 네트워크 주소 변환을 통해 작동한다.

• 가상 IP 주소: 서비스가 제공하는 내부 IP 주소이며, 클러스터 내에서만 사용 가능하다.
• 네트워크 주소 변환(NAT): 서비스에 접속하면 내부적으로 적절한 파드로 트래픽을 전달한다.
• 쿠버네티스가 할당하는 가상 IP는 물리적 네트워크 인터페이스에 바인딩되지 않으며 클러스터 내부에서만 라우팅되는 논리적인 주소
• 따라서, 클러스터 바깥에서는 해당 IP가 어디로 연결되는지 알 수 없으며 접근이 불가능하다.

왜 그런짓을?

• 내부 애플리케이션 간 통신을 효율적으로 관리하고, 변경되는 파드의 위치를 서비스가 자동으로 추적할 수 있도록 하기 위함이다.
• 클러스터 외부에서 접근이 필요하다면, NodePort나 LoadBalancer 같은 다른 서비스 유형을 사용해야 한다.
• 결과적으로, 사용자는 서비스의 IP와 포트를 이용해 접속하면 서비스가 이를 적절한 파드로 연결해준다.

 

서비스 유형과 특징

 

유형	특징	적합한 상황
ClusterIP (default)	- 클러스터 내부에서만 접근 가능 - 가상 IP를 부여하여 내부 트래픽을 라우팅	내부 마이크로서비스 간 통신
NodePort	- 각 노드의 고정된 포트를 통해 외부에서 접근 가능 - 클러스터IP + 노드의 IP + 지정된 포트 형식으로 접속	외부에서 직접 접근이 필요한 경우 (개발/테스트 환경)
LoadBalancer	- 클라우드 환경에서 외부 로드밸런서를 생성하여 서비스 연결 - NodePort + 외부 로드밸런서를 결합한 형태	AWS, GCP, Azure 등의 클라우드에서 운영할 때
ExternalName	- 내부 서비스가 아닌 외부 서비스(도메인)로 트래픽을 전달	외부 API 또는 외부 서비스와의 연동

 

서비스의 작동 과정

1. 클라이언트가 서비스의 가상 IP로 요청을 보낸다.
2. 쿠버네티스의 kube-proxy가 요청을 감지하고, 내부적으로 NAT을 수행하여 적절한 파드로 전달한다.
3. 파드는 요청을 처리하고 응답을 반환한다.
4. 서비스는 동일한 방식으로 응답을 클라이언트에게 전달한다.

 

실습

https://koreatstm.tistory.com/277#%EB%B0%B0%ED%8F%AC-1

쿠버네티스 로컬 실습

 

 

 

쿠버네티스 네트워크

 

ClusterIP 

• 기본 서비스 유형으로, 클러스터 내에서만 접근 가능한 가상 IP를 할당
• NodePort 사용 가능하나 클러스터의 모든 노드에 대해 지정된 포트를 부여하므로 포트 낭비
• 외부에서 접근할 수 없고, 오직 같은 클러스터 내의 파드들만 접근할 수 있음
• 서비스 내부 통신에 주로 사용되며, 외부와의 연결이 필요 없는 서비스들(예: 데이터베이스, 캐시 서버 등)에 적합

쿠버네티스에서 외부 트래픽을 내부로 연결하는 3가지 방법

 

NodePort 

 

• 각 노드의 특정 포트를 개방하여 외부에서 접근 가능하도록 함
• 클러스터IP:노드포트 형식으로 접근
• EX) http://<Node IP>:<NodePort> 로 접근
• 단점: 특정 노드가 다운되면 접근 불가
• 클러스터 내의 모든 노드에 특정 포트를 개방하여 외부에서 접근할 수 있게 한다.
  • 하지만, Auto-scailing이 일어나면 클러스터 내의 노드가 추가되거나 제거될 수 있기 때문에, 클라이언트 측에서 동적으로 변화하는 노드의 엔드포인트를 관리해야 하는 문제가 발생
    • 서비스 디스커버리: 이 문제를 해결하기 위해 클라이언트는 서비스 디스커버리 방식을 사용
    • 하지만 이는 추가적인 관리 복잡성을 야기하며, 클라이언트가 노드가 추가된 경우에 이를 자동으로 인식하고 적절히 연결하는 방식이 필요 -> LoadBalancer 사용
    • 왜 LoadBalancer가 적합한가?
      • 단일 IP 엔드포인트 제공: 단일 IP 주소 통해 서비스에 접근할 수 있도록 하여 노드가 추가되거나 제거될 때도 클라이언트는 이 단일 엔드포인트만을 참조하면 되기 때문에, 노드들의 네트워크 변화에 대한 걱정 없이 서비스를 안정적으로 사용가능
      • 자동 로드 밸런싱: 클러스터 내에서 다양한 노드와 파드에 트래픽을 분배하고, 오토 스케일링이 적용된 경우에도 안정적인 서비스를 제공가능

📌 예제: kubectl expose deployment my-app --type=NodePort --port=80

LoadBalancer (클라우드 환경에서 외부 트래픽 처리)

 

• 클라우드 환경(AWS, GCP, Azure)에서 외부 로드 밸런서를 생성하여 인터넷에서 접근 가능하도록 함
• NodePort 방식보다 더 안정적이고 부하 분산 가능
• 보통 퍼블릭 클라우드에서 LoadBalancer를 사용하면 자동으로 외부 IP가 할당됨

📌 예제: kubectl expose deployment my-app --type=LoadBalancer --port=80

Ingress (도메인 기반 트래픽 관리)

 

• 여러 서비스에 대한 도메인 기반 라우팅을 설정할 수 있음
• 예를 들어, example.com/api는 API 서비스로, example.com/web은 웹 서비스로 보낼 수 있음
• NodePort와 LoadBalancer를 사용하면 서비스마다 개별적으로 노출해야 하지만, Ingress는 하나의 엔드포인트로 여러 서비스 관리 가능
• 보통 Ingress Controller(NGINX, Traefik 등)가 필요함

 

정리해보자

• ClusterIP: 내부에서 내부 (클러스터 내의 다른 서비스들이 이 서비스를 접근하는 방식)
• NodePort, LoadBalancer, Ingress: 외부에서 내부 (외부에서 클러스터 내 서비스를 접근하는 방식)
• ExternalName: 내부에서 외부 (클러스터 내에서 외부 서비스에 접근하는 방식)

 

플라넬

 

개념

• 쿠버네티스 클러스터 내에서 파드 간 통신을 효율적으로 관리하는 네트워크 플러그인
• 파드 간의 IP 네트워크를 연결하여 쿠버네티스 내에서 파드들이 서로 통신할 수 있게 해준다.

 

Flannel과 서비스의 관계 및 차이점

 

1. Flannel (파드 간 통신)

• 쿠버네티스 클러스터 내에서 파드 간의 네트워크 통신을 관리
  • 각 파드는 고유의 IP 주소를 가지며, Flannel은 이 IP 주소를 네트워크에서 라우팅해 파드 간 통신을 가능하게 한다.
• 작동 원리: 클러스터에서 각 노드에 Flannel DaemonSet을 배포
  • 이를 통해 각 노드의 가상 네트워크를 설정하여 파드 간의 통신을 가능하게 한다.
• 서비스가 외부나 다른 파드에 대한 접근을 처리할 때, Flannel을 통해 각 파드가 서로 연결되어 있어야 요청을 전달할 수 있다.

2. 서비스 (파드 접근을 위한 엔드포인트 제공)

• 서비스는 외부나 클러스터 내에서 파드에 접근할 수 있는 단일 진입점(endpoint)을 제공
  • 파드는 클러스터 내에서 동적으로 생성되고 삭제되며, 이러한 파드들에 대해 서비스는 고정된 가상 IP를 할당하여 파드들의 주소 변경에 관계없이 안정적인 접근을 제공한다.
• 작동 원리: 클라이언트가 서비스의 IP로 요청을 보내면 kube-proxy가 해당 요청을 받아 서비스의 각 파드로 라우팅
  • 이때 서비스는 가상 IP와 네트워크 주소 변환 (NAT)을 통해 요청을 적절한 파드로 전달
•  서비스는 Flannel을 통해 통신하는 파드들에 대해 접근할 수 있는 방법을 제공하고, Flannel이 설정한 IP 네트워크를 기반으로 파드에 대한 요청을 라우팅한다.

 

핵심 정리

 

플라넬로 구축한 IP 네트워크가 없으면, 서비스는 엔드포인트에 접속을 같은 컴퓨터의 파드로만 연결할 수 있음

예를 들어, 클러스터의 한 노드에서 파드가 실행되고, 그 노드의 서비스가 다른 노드의 다른 파드에 연결하려고 할 때, Flannel 네트워크가 없으면 네트워크 연결이 이루어지지 않으며 그 서비스는 같은 노드에 있는 파드들만 대상으로 요청을 전달할 수 있다. 다른 노드에 있는 파드로의 요청은 불가능하다.

 

왜 그런가?

Flannel은 가상 네트워크를 제공하기 때문에 클러스터 내 여러 노드에서 실행되는 파드들이 서로 통신할 수 있게 도와준다. Flannel 네트워크가 없으면, 서비스는 클러스터 내 파드들이 위치한 동일 노드에만 접근할 수 있게 되고, 클러스터 내 다른 노드에서 실행 중인 파드로 요청을 보낼 수 없게 된다.

 

출처

https://www.harness.io/blog/kubernetes-services-explained

https://velog.io/@hoonki/%EC%BF%A0%EB%B2%84%EB%84%A4%ED%8B%B0%EC%8A%A4-%EC%84%9C%EB%B9%84%EC%8A%A4ClusterIP-NodePort-LoadBalancer%EC%99%80-%EC%9D%B8%EA%B7%B8%EB%A0%88%EC%8A%A4