쿠버네티스(네트워크2)

6) ExternalName 서비스 생성

노드포트, 로드밸런서와 다르게 외부에서 접근하기 위한 서비스 종류가 아닌 내부 파드가 외부의 특정 FQDN에 쉽게 접근하기 위한 서비스다.

심지어 접속하기 위한 외부 FQDN 주소가 바뀌더라도, CNAME은 그대로 유지할 수 있어 애플리케이션을 다시 작성하거나 빌드 하지 않아도 된다.

 

vim myapp-svc-extname.yaml

외뷔 FQDN은 example.com이며 이에 대한 CNAME은 example 이름을 제공하는 서비스 이다. 파드와 매칭하지 않기 때문에 레이블 셀렉터는 없다.

 

외부 이름 서비스를 생성해보자

kubecttl create -f myapp-svc-extname.yaml

 

 

7) ExternalName 서비스 확인

kubectl get service example

서비스 타입은 ExternalName이며, 외부IP에는 example.com의 FQDN이 할당되어 있다.

즉, 파드는 example CNAME을 사용하면 example.com의 주소를 알 수 있다.

 

임시 파드를 생성해서 DNS에 질의해보자

kubectl run nettool -it -image=ghcr.io/c1t1d

0s7/network=multitool --rm bash

host example

exit

 

8) 컨트롤러 및 서비스 삭제

kubectl delete replicasets.apps,services --all >>>현재 클러스터에 있는 모든 ReplicaSet과 Service를 삭제할 수 있습니다.

 

 

5.4 인그레스

앞에서 서비스를 외부에 노출시키는 방법인 nodeport 와 loadbalancer서비스 타입에 대해 살펴보았음. 마지막으로 서비스를 노출시키는 방법이 하나가 더있다. 이것이 인그레스 컨트롤러다.

 

쿠버테니스 외부에 노풀시켜야할 서비스가 많을 경우, NodePort은 각 서비스마다 전용의 노드의 포트를 할당해야 하고, LoadBalancer의 경우 외부 로드밸런서가 각 서비스마다 프로비저닝 되어야 한다. 그러나 인그레서는 HTTP 요청의 주소를 구분해 하나의 인그레스 리소스를 이용해 각 서비스에 라우팅할 수 있다.

 

클라이언트 >>> 인그레서 >>> 라우팅규칙 >>> 서비스 >>> 파드

 

노드포트 및 노르벨런서 서비스는 osi 레이어 4(TCP/UDP)에서 작동하지만, 인그레스 리소스는 OSI 레이어 7(HTTP/HTTPS)에서 작동한다. 세션 쿠키 기반의 세션 어피니티를 가지고 있다.

 

** 인그레스 컨트롤러는 Nginx HTTP서버와 리버스 프록시 기능을 통해 제공되며, 인그레스 컨트롤러는 노드의 개수만큼 각 노드에 실행한다.

kubectl get po -n ingress-nginx -o wide

 

 

1) 인그레스 생성

인그레서 api 그룹은 networking.ks8.io 이며, 버전은 v1이다. 종류는 ingress로 선언.

vim myapp-ing.yaml

.spec.defaultBackend.service.name : 라우팅할 기본 백엔드 서비스 이름, 규칙에 매칭되지 않는 트래픽은 기본 백엔드로 전송됨

.spec.defaultBackend.service.port.number : 라우팅할 기본 백엔드 서비스의 포트

.spec.rules.host : url호스트

.spec.rules.http.paths.path : url의경로

.spec.rules.http.paths.pathType : url의 경로 유형

.spec.rules.http.paths.path.backend : 라우팅할 서비스 백엔드

.spec.rules.http.paths.path.backen.service.name :라우팅할서비스이름

.spec.rules.http.paths.path.backen.service.port.number :서비스포트

 

외부에서 myapp.example.com FQDN 주소를 통해 인그레스 리소스에 접속하면, 인그레스 리소스는 백엔드 서비스인myapp-svc-np 서비스에 라우팅하며, myapp-svc-np 서비스는 레이블 셀렉터에 매핑된 파드로 라우팅해줌

 

레플리카셋 컨트롤러와 NodePort서비스를 생성한다

kubectl create -f myapp-rs-exp.yaml -f myapp-svc-np.yaml

인그레스 리소스를 생성한다

kubectl create -f myapp-ing.yaml

 

 

2) 인그레스 리소스 확인

kubectl get ingresses.networking.k8s.io

할당된 인그레스 리소스 IP는 쿠버네티스 클러스터의 노드 IP다.

 

인그레스 리소스의 상세 정보를 확인

kubectl describe ingresses.networking.k8s.io myapp-ing

인그레스 리소스에 myapp.example.como 주소로 접근시 myapp-svc-np서비스로 라우팅하게 된다!!

 

그러나 현재 외부 DNS가 없기 때문에 myapp.example.com FQDN의 A레코드를 반환하지 못함... 그러므로 curl 명령의 --resolve 옵션을 사용해 해당 FQDN의 주소를 ip로 변환하는 옵션을 사용해야 한다.

curl --resolve myapp.example.com:80:192.168.56.21 http://myapp.example.com/\?detail\=header 

 

 

3) 다중 경로 인그레스

지금까지는 하나의 인그레스를 하나의 서비스만 노출시켰다. 그러나 인그레스는 하나의 인그레스 리소스로 다중 서비스를 노출시킬 수 있다.

 

(1) 같은 FQDN의 다중 경로 인그레스

- http://myapp.example.com/web1 

- http://myapp.example.com/web2

다중 서비스용 인그레스 구성 예제

vim myapp-ing-multi-paths.yaml

 

인그레스 리소스를 생성해보자.

kubectl create - f myapp-ing-multi-paths.yaml

인그레스의 룰을 확인해보자

kubectl describe ingresses.networking.k8s.io myapp-ing-mpath

 

 

4) 컨트롤러, 서비스 및 인그레스 리소스 삭제

kubectl delete ingersses.networking.k8s.io --all

kubectl delete replicasests.apps,services --all

 

 

 

5.6 헤드리스 서비스

서비스는 파드 레이블 셀렉터에 의해 파드 그룹을 서비스의 엔드포인트에 등록하고, 기본적으로 부하 부산을 한다.

 

그러나 항상 부하 분산이 필요한 것만은 아님!!! 클라이언트 측 파드가 서버 측 서비스를 통해 각각 모든 개별 서버 파드로 접근해야할 필요도 있다.

 

서비스 리소스 자체의 ip(cluster ip)가 아닌, 각각의 파드의 주소를 확인하여 개별적으로 접근할 필요가 있다는 의미이다. 이를 헤드리스 서비스라 한다.

 

ex) db를 실행하고 있는 컨트롤러에 의해 두 개의 데이터베이스 파드가 있고, 이 데이터베이스를 실행하고 있는 파드는 고가용성을 이유로 마스터(읽기/쓰기) 파드랑 슬레이브(읽기 전용) 파드로 나눠져 있는 경우

 

기존의 서비스는 부하 분산기능을 가지고 있어 어떤 파드에 접근할 것인지 결정을 못함, 이경우 데이터베이스에 쓰기를 해야하는 경우 어떻게 할것??? ㅋㅋ 이런 경우에 헤드리스 서비스가 필요하다