Kubernetes Object [Part 03]

▶ 지난 포스팅

Kubernetes Object [Part 01] — 하늘을 나는 펭귄

Kubernetes Object [Part 01]

Kubernetes Object [Part 02] — 하늘을 나는 펭귄

Kubernetes Object [Part 02]

 

01. Service Object

Pods 내부에서 Application을 배포하려면, Network 서비스로 외부에 노출시키는 추상화 개념이 있어야된다 !!

 

💁‍♂️ Service란?

• Pod 집합과 같은 어플리케이션에 접근 경로나 Service Discovery를 제공.
• Pod를 외부 네트워크에 연결하고, pod로의 연결을 로드밸런싱 하는 네트워크 오브젝트
• [service name].[namespace name].svc.cluster.local 이라는 FQDN이 생성된다.
• service에 연결되는 pods들은 Label Selector에 의해 정의된다.

■ 기본 yaml 구조

Service는 추상적인 객체이며 실제 객체인 Pod를 Labels 기반으로 Discovery

 

즉, Service의 Domain으로 Pods들을 호출한다.

pod 생성시 기본적으로 FQDN이 자동으로 생성되는 것은 아니다.

 

1. Pod 자체에 기본적으로 고정된 FQDN이 생성 되지는 않는다.

• Pod는 동적으로 IP가 할당되고 Pod 이름을 기반으로 DNS레코드가 자동적으로 생성되지만 이 DNS이름은 Cluster 내부적으로만 유효하며, Pod마다 고유한 이름이 부여된다.

2. Service가 생성되면 해당 Service 이름을 기반으로 FQDN이 생성된다.

• 예를들어, nginx-service라는 이름의 service가 default 네임스페이스에 생성되었다면 Cluster 내부 DNS에서 nginx.-service.default.svc.cluster.local과 같은 FQDN이 생성된다.

 

■ 동작 방식

 

1. client가 http://nginx-service/로 요청을 보낸다.

2. Cluster 내부 DNS가 nginx-service라는 이름을 Service IP로 해석하여 service로 전달.

3. Service는 app.kubernetes.io/name=proxy 라는 Label Selector를 통해 여러 Pods를 관리하고 있다가

들어온 요청을 이 Label에 가진 Pods들 중 하나로 로드밸런싱

4. client는 ip나 이름을 알 필요 없이 service 이름(FQDN)을 통해 접근할 수 있다.

 

 

---

01. Cluster IP

• kubernetes 클러스터 내부에서만 통신이 가능한 internal network 가상 IP가 할당됨.
• service - pod간 통신은 kube-proxy가 담당한다.
• 외부에서 호출할 일이 없는 backend app에서 많이 사용한다.

 

이 service ip로 들어오는 요청은 kube-proxy에 의해 해당 서비스가 관리하는 Pods들로 로드밸런싱 된다.

 

■ 사용 사례

• Cluster 내부의 MicroService간 통신 (예시: Frontend pods → Backend pods 통신)
• Database나 Cash와 같이 Cluster 외부에서 직접 접근할 필요가 없는 내부 Service.

 

02. NodePort

• NAT를 이용해 클러스터 내 Node의 고정된 Port를 갖는 IP로 service를 노출한다.
• Node Port의 범위는 30000 - 32767 사이에서 Kubernetes가 자동으로 할당하거나 사용자가 지정 가능하다.
• 외부 트래픽을 서비스에 전달하는 가장 기본적인 방법이다.
• 클러스터 외부에서 접근은 [Node IP]:[Node Port]

NodePort를 외부로 개방하여 해당 Port로 들어오는 트래픽을 Service내 Pod로 포워딩.

 

■ 사용 사례

• 개발 및 테스팅 환경에서 임시적으로 외부에 접근할 필요가 있을때
• 소규모 Cluster에서 Web Server나 Application을 외부에 노출할때

 

03. LoadBalancer

• 클라우드 환경(AWS, Azure, GCP)에서 가장 일반적으로 사용되는 외부 노출방식.
• 클라우드 공급자의 로드밸런서를 이용해 service를 외부로 노출한다.
• 외부 로드밸런서를 사용하기 때문에 SPOF에 강하다.
• L4 (TCP), L7 (HTTP) Layer를 통해 서비스 노출.

SPOF (Single Point Of Failure) 란?

시스템 내에서 하나의 구성 요소가 고장나면 전체 시스템이 멈추거나 서비스가 중단되는 지점을 말한다.

 

쉽게 예를 들자면, Network 구성이 이중화 구성이 아닌 단일 구성.

내부적으로 Service의 NodePort를 사용하여 트래픽을 Cluster 내부의 해당 Pod로 전달.

 

■ 사용 사례

• production 환경에서 Web Application이나 API 서비스를 안정적이고 확장 가능하게 외부에 노출시킬때 사용
• Public IP를 통해 외부 사용자가 Application에 접근해야할때

■ 특징

 

1. 고가용성(HA) 구성 : 로드밸런서로 인해 여러 인스턴가 이중화 구성으로 운영되어 하나의 서버에 장애가 발생해도

다른 서버가 Traffic을 처리하므로 서비스 중단을 방지한다.

 

2. 분산된 인프라 : 외부 로드밸런서는 여러 가용영역 (Availability Zone)에 걸쳐 분산 배치되어, 특정 영역에서

장애가 발생되어도 서비스는 유지된다.

 

---

[ 실습 ] NodePort Service 생성 확인

■ 서비스 생성

# deployment 생성 & 확인
kubectl create deployment nginx-deploy --image=nginx
kubectl get deployment

# Node Port로 서비스 노출
kubectl expose deployment/nginx-deploy --name nginx-svc --type="NodePort" --port 80

# 서비스 확인
kubectl get svc -o wide
kubectl get pods --show-labels

 

■ 테스트 파드 생성

• background로 실행시키고, curl 명령어가 포함된 경량 이미지인 Pod 생성.

kubectl run curl -it --rm --image=curlimages/curl -- sh
curl nginx-svc.default.svc.cluster.local

 

■ NodePort 서비스 호출

# node를 출력하여 ip 확인 목적
kubectl get nodes

# 테스트 파드 진입
kubectl run curl -it --rm --image=curlimages/curl -- sh
curl ip-10-0-143-224.ap-northeast-2.compute.internal:30440

 

아까 학습한 대로, FQDN으로 호출시켜도 되고 service를 생성했으므로 [node ip]:[node port] 방식으로도 접근 가능하다.

 

---

02. Ingress

Service 앞단에서 Smart Router 및 entry point 역할을 하는 오브젝트

• 외부에서 접근 가능한 LoadBalancing, SSL Termination 등을 통해 Service에 대한 HTTP 기반 접근 제공.
• 클러스터에 하나 이상의 실행중인 Ingress Controller가 필요하다. (aws-lb-controller , nginx-ingress 등)

💁‍♂️ 왜 Ingress가 필요할까?

대외 webapp을 만들었다고 가정하였을때, 단순히 NodePort를 이용해 서비스를 노출하면 사용자가 30000이상의

포트 넘버를 기억하고 접근해야 한다.

 

따라서 일반적으로는 proxy를 두고 80 port → NodePort로 포워딩을 하는 layer를 생성

ingress controller가 proxy-server 역할을 담당하여 service 라우팅

 

가장 큰 장점은 Service들이 늘어나게 되면 다양한 path에 대해 단일 endpoint를 지원.

 

■ Ingress 기본 yaml 구조

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
spec:
  rules:
  - host: example.com
    http:
      paths:
      - path: /shop
        pathType: Prefix
        backend:
          service:
            name: shop-service
            port:
              number: 80
      - path: /blog
        pathType: Prefix
        backend:
          service:
            name: blog-service
            port:
              number: 80

• example.com/shop은 shop-service로, example.com/blog는 blog-service로 라우팅 하는 규칙.

 

■ 요약

• Ingress는 Kubernetes Cluster 외부에서 HTTP/HTTPS 요청을 받아 내부서비스로 라우팅하는 역할.
• 호스팅명과 경로 기반 라우팅, TLS 지원 등 다양한 기능을 지원.
• 여러 서비스에 대한 단일 진입점 역할을 하여 클러스터 네트워크 환경을 효율적으로 관리.

+ Ingress Controller를 사용 시 운영환경에서 많은 옵션을 주기 위해 "annotations"을 활용한다 !!!

 

 

너무 간단하게 다뤄봐서 아쉬운 점이 크다 ... 조만간 Side Project를 진행하여 한번에 실습을 진행해볼게요.

To be continue.