1. Ingress 의 역할
Kubernetes 인그레스(Ingress)에 대하여 알아보기 위해, 먼저 웹 서비스를 kubernetes 클러스터에 배포하는 시나리오를 가정해보자.
웹서버를 개발하여 배포/운영하는 사용자는, 소스 코드를 작성하고 빌드 후에 도커 이미지를 빌드하여 파드로 구성한다. Persistent layer(영속 영역)의 처리를 위하여, 데이터베이스가 필요하며 이 또한 클러스터 안에 파드로 구동한다.
클러스터 내부에서 web service 파드가 database 파드에 접근하기 위하여, database 파드를 가리키는 서비스를 ClusterIP 타입으로 생성한다. ClusterIP는 클러스터 내부 IP로 노출되는 서비스 타입으로 클러스터 안에서만 접근할 수 있으며, kubernetes 서비스 객체의 기본 타입이다.
Database 파드와 달리 web service 파드의 경우, 클러스터 외부의 사용자가 접속할 수 있어야 한다. 이를 위해서 서비스를 NodePort 타입으로 생성한다. NodePort 타입의 서비스로 파드를 노출할 경우, 클러스터 내 모든 노드의 IP에 해당 포트가 노출 되며, 이 NodePort 가 가리키는 ClusterIP가 자동으로 생성된다. 사용자는 <NodeIP>:<NodePort> 의 형태로 클러스터 외부에서 web service 에 접근할 수 있다.
이제 사용자는 http://<NodeIP>:<NodePort> 와 같은 형식으로 web service를 이용할 수 있다. 하지만 실제 운영환경에서 제공되는 서비스의 경우 이와 같이 사용자가 IP나 Port를 입력하고 접속하는 경우는 거의 없으며, 사용자의 편의를 위하여 url 을 사용하고 포트 또한 브라우저 기본 포트인 80 포트를 사용한다.
이를 위해 DNS(Domain name server) 를 사용하여 특정 URL을 IP 로 매핑시켜 줄 수 있다. 또한 proxy server를 사용하여 80 포트로 들어온 연결을 특정 포트로 전달해준다. 이렇게 하면 사용자는, IP:Port에 비해 이해하기 쉬운 URL 을 통하여 kubernetes cluster 내부의 web service 에 접속할 수 있다.
GCP 와 같은 Cloud Service Provider(클라우드 서비스 제공자. 이하 CSP)에서 Type : LoadBalancer 를 지원하는 경우, 위 그림의 초록색 영역에 해당하는 부분을 kubernetes 서비스 타입으로 대체할 수 있다. LoadBalancer 타입으로 서비스를 생성하는 경우 내부적으로 ClusterIP와 NodePort 가 생성된다.
여기서 web service 의 규모가 더 커지게 되는 경우를 고려해보자. 동일한 URL을 사용하면서 subpath로 파생 서비스를 구현할 경우, 자원의 효율성을 위하여 동일 클러스터 내에 다른 파드로 2번째 web service를 구동하게 된다. 이렇게 클러스터내에 여러 서비스가 있고 동일 상품의 URL을 사용하게 되면, 다시 Loadbalancer(이하 LB) 들의 앞단에 LB가 하나 더 생기게 되고, 여기에서 subpath에 따라 각 상품의 LB로 분기하게 된다.
새로운 상품이 추가가 되면, 가장 앞단의 LoadBalancer 의 설정이 변경되어야 한다. 또한 개별 상품의 대하여 HTTP가 아닌 HTTPS 연결을 지원해야 하는 수요도 있는데, 이 경우에는 application 설정에서 지원하거나, proxy server, LB 등 여러 depth에서 구현될 수 있다. 실제 운영 상품의 경우 다양한 상품에 서로 다른 요구사항들이 발생하게 되는데 위와 같은 구성의 경우 상품이 증가할수록 복잡도도 증가하게 된다.
이러한 구성의 복잡도를 줄이기 위해 kubernetes 에서는 Ingress 리소스를 제공한다. Ingress 는 사용자가 외부에서 접근할 수 있는 단일 URL을 통하여 클러스터 내의 어플리케이션에 접근할 수 있게 해준다. 사용자가 접근하는 이 URL은 kubernetes 내의 다른 서비스로 라우팅 될 수 있으며, SSL 의 처리도 지원한다. 달리 말해 ingress는, kubernetes 클러스터에 내장된 7계층 로드밸런서라고 볼 수 있다.
2. Ingress 의 구성
전술한 내용처럼, Ingress 는 프록시 역할을 수행하여, 특정 Port 로 들어오는 연결을 다른 port로 전달해주는 역할을 수행하며, 부하 분산을 위한 로드밸런싱 기능, SSL 연결 등을 지원한다. Ingress 의 구성에 대해 알아보기 위해 '만약 Ingress 를 사용하지 않는다면', 이와 같은 기능들을 어떻게 구현할지 생각해보자.
Nginx 나 Haproxy, traefik 과 같은 프록시 기능을 지원하는 솔루션을 선정한 후에, 1) Kubernetes 클러스터에 파드로 구동하게 될 것이다. 그리고 2) 각 솔루션의 설정 파일들을 통해 트래픽을 관리하는 룰을 적용하게 된다.
Ingress 는 위와 동일한 방식으로 구현된다. Nginx 등의 솔루션을 선택하는 부분이 Ingress controller 를 선택하여 구동하는 부분으로 구현되며, Solution Config 를 통하여 룰을 관리하는 부분은, 룰마다 Ingress 객체를 생성하여 관리하는 부분에 해당한다.
Kubernetes 는 클러스터의 설치과정에서 '기본적으로(by default)' Ingress Controller 를 설치하지 않는다. Ingress Controller 에는 여러 종류가 있으며, 사용자가 Kubernetes 클러스터를 설치한 후에 이 중 특정 Controller 를 선택하여 설치할 수 있다.
3. Ingress Controller
Kubernetes 에서 사용가능한 Ingress Controller 에는 여러 종류가 있다. GCP 의 GCP Load Balanacer(GCE) , Nginx, Contour, Traefik, Haproxy, Istion 등이 있으며 이 중에서 GCP Load Balancer와 Nginx 의 경우 Kubernetes 프로젝트에서 제공되고 관리되고 있다.
물론 여기서 사용되는, 예를 들어 Nginx 를 Ingress controller 로 사용한다고 할 경우, Nginx 가 그 원래의 기능으로 로드밸런싱 만을 수행한다기보다는, Kubernetes 의 기능에 포함되어 클러스터 전체를 관리하는 역할도 담당하게 된다.
다음으로 Ingress Controller 를 구동(설치)하는 과정에 대해 알아본다.
'소프트웨어 아키텍처 > Kubernetes' 카테고리의 다른 글
| [Kubernetes security] Container 나 Pod 의 실행 유저 지정하기 (0) | 2022.11.17 |
|---|---|
| Kubernetes 와 Seccomp (0) | 2022.09.23 |
| Kubernetes package binary 파일 정합성 확인하기 (0) | 2022.07.25 |
| Kubectl 명령어의 Proxy, Port-Forward 기능 (0) | 2022.07.15 |
| Kubelet authenticatoin/authoziation (0) | 2022.07.14 |
댓글