Service 종류
쿠버네티스의 Service 리소스는 크게 4가지 타입으로 구별됩니다.
- ClusterIP
- Node Port
- Load Balancer
- External Name
ClusterIP
ClusterIP는 Service 리소스의 특정 타입을 지정하지 않을 경우 디폴트로 지정되는 타입으로 쿠버네티스 내부에서만 Pod에 접근할 때 사용합니다.
외부로 Pod를 노출하지 않기 때문에 쿠버네티스 클러스터 내부에서만 사용되는 Pod에 적합합니다.
ClusterIP타입의 Service를 Pod template 파일로 생성할 때 --expose, --port 80 옵션을 추가해줍니다.
$ kubectl run cluster-ip --image nginx --expose --port 80 \
--dry-run=client -o yaml > cluster-ip.yaml위 명령어를 실행하면 cluster-ip.yaml 파일이 생성되어 있습니다.
cluster-ip.yaml
💡 하나의 YAML파일에 여러 리소스를 명세할 땐
---를 구분자로 사용합니다.
위 소스에서는 두 줄로 생성되어 있는데 한 줄만 있어도 가능합니다.
Pod와 Service를 생성하고 조회하겠습니다.
ClusterIP으로 타입이 지정된 것을 확인할 수 있습니다.
NodePort
ClusterIP 타입은 클러스터 내부에서만 접근할 수 있습니다.
이번에는 클러스터 외부에서 접근할 수 있도록 NodePort 서비스를 만들어 보겠습니다.
NodePort 타입은 로컬 호스트의 특정 포트를 Service의 특정 포트와 연결시켜 외부트래픽을 받아올 수 있습니다.
type - NodePort로 지정합니다.
nodePort - 호스트 서버에서 사용할 포트입니다. (쿠버네티스에서 제공하는 범위는 30000-32767입니다.)
NodePort의 중요 기능으로 Pod가 위치한 노드 뿐만 아니라 클러스터 내의 모든노드에 포트를 오픈합니다. 여러 개의 노드가 있다면 아무 노드로 접근해도 지정한 Pod로 접근할 수 있습니다.
NodePort의 단점
- 신뢰성
- 노드가 사라지면 자동으로 다른 노드를 통해 접근이 불가능합니다.
- 어떤 노드가 살아있고 죽었는지 알 수 없습니다.
- 보안성
- 호스트 서버의 노드포트 대역(30000-32767)을 외부에 노출됩니다.
- 편리성
- 사용자가 각각의 서버 IP(master, worker ..)를 알고있어야 합니다.
이를 보완하기 위해서 존재하는 게 LoadBalancer입니다.
LoadBalancer
보안성
호스트 서버를 내부 네트워크에 두고 LoadBalancer만 외부 네트워크에 위치하여 well-known 포트로 서비스 끝점을 제공하여 네트워크 보안성을 보장합니다.
편리성
쿠버네티스는 여러 노드들의 생성 및 삭제를 자유롭게 수행하는데 그때마다 노드의 IP를 직접 알 필요 없이 LoadBalancer의 IP 또는 도메인 주소만 가지고 요청을 보낼 수 있어서 편리합니다.
ClusterIP가 Pod 단위의 안정적인 서비스 끝점을 제공한다면, LoadBalancer는 노드단위의 안정적인 서비스 끝점을 제공하는 것이라고 이해하시면 됩니다.
LoadBalancer를 생성해보겠습니다.
일반적으로 LoadBalancer는 클라우드 플랫폼(AWS, GCP 등)에서 제공해주는 것을 사용합니다.
저는 K3s를 사용하기때문에 가상의 로드밸런서를 사용하겠습니다.
타입만 LoadBalancer로 설정해주면 클러스터가 알아서 생성하고 호스트서버와 연결해줍니다.
k3s는 클라우드 플랫폼을 제공 받지 못합니다.
load-bal.yaml
기존 다른 서비스와는 다르게 EXTERNAL_IP가 생성됩니다. (예제에서는 10.0.1.4로 잡아주었습니다.)
k3s에서는 소프트웨어로 구현된 LoadBalancer가 있어서 호스트 서버의 IP와 동일하게 지정됩니다.
일반적으로 퍼블릭 클라우드에서 제공해주는 쿠버네티스 클러스터를 이용하면 클라우드 플랫폼을 제공 받기 때문에 각 플랫폼의 LoadBalancer의 IP/DNS를 확인할 수 있습니다.
curl <LoadBalancer IP>:<Service Port>
svclb-load-bal-xxx 이름의 Pod가 생겼는데 이것이 쿠버네티스가 소프트웨어로 구현한 가상 로드밸런서입니다.
삭제도 마찬가지로 쿠버네티스가 해당 LoadBalancer타입의 서비스가 삭제되면 알아서 삭제해줍니다.
ExternalName
ExternalName타입은 일반적인 셀렉터에 대한 서비스가 아니라 외부 DNS 주소에 대해서 클러스터 내부에서 사용할 별칭을 지정해줍니다.
external.yaml
외부 DNS주소인 google.com으로 연결할 수 있는 끝점을 생성하고 클러스터 내에서 google-svc라는 이름으로 사용합니다.
ExtenalName을 통해서 외부 서비스에 쿠버네티스 네트워킹 기능을 연결할때 사용합니다.
쿠버네티스 네트워크 모델의 특징
- 각 노드간 NAT 없이 통신이 가능해야 합니다.
- 각 Pod간 NAT 없이 통신이 가능해야 합니다.
- Node와 Pod간 NAT 없이 통신이 가능해야 합니다.
- 각 Pod는 고유의 IP를 부여받습니다.
- Pod IP는 클러스터 내부 어디서든 접근할 수 있습니다.
💡NAT란?
네트워크 주소 변환(Network Address Translation)
라우터 등의 장비를 통해 다수의 private IP를 하나의 public IP로 변환하는 기술
쿠버네티스에서는 컨테이너 네트워크 환경을 노드 단위의 네트워크 환경과 분리하여 고립도를 높이고, 결과적으로 Pod라는 독립적인 네트워크 환경을 구성하는 리소스를 만듭니다.
쿠버네티스의 모든 리소스는 다른 모든 리소스를 해당리소스의 고유 IP로 접근할 수 있습니다.
따라서 NAT에 따른 부작용을 걱정할 필요가 없습니다.
마치며..🖐️
쿠버네티스의 Service 리소스를 두개의 포스트로 나눠서 학습을 했습니다.
이를 통해서 쿠버네티스의 전반적인 네트워킹을 살펴보았습니다.
다음 포스트에서는 컨트롤러에 대해서 포스팅을 해보겠습니다.
Reference
https://kimjingo.tistory.com/150?category=981324
https://velog.io/@hidaehyunlee/%EC%BF%A0%EB%B2%84%EB%84%A4%ED%8B%B0%EC%8A%A4-%EC%95%84%ED%82%A4%ED%85%8D%EC%B2%98-2.-%EC%98%A4%EB%B8%8C%EC%A0%9D%ED%8A%B8-Objects
핵심만 콕! 쿠버네티스 - 유홍근
