[CKA] Networking - 3

CKA (https://www.credly.com/org/the-linux-foundation/badge/cka-certified-kubernetes-administrator)

Ingress

• 서비스와 인그레스의 차이는 무엇이며 언제 어떤 것을 사용해야할까?
• 먼저 간단히 서비스를 다시 살펴보고 인스레스를 살펴보자
• 예를 들어 온라인 스토어를 운영하는 회사를 위해 쿠버네티스에 응용 프로그램을 배포중이라고 가정해보자. 응용프로그램은 myonlinestore.com으로 배포되어 있다.
• 외부에서 이 온라인 스토어로 접근하기 위해서는 http://www.myonlinestore.com 으로 접근해야 한다. 이는 보통 NodePort를 이용해서 http://10.58.10.1:38080 이런 식으로 접근한다.
• 프로덕션 레벨의 애플리케이션을 배포한 적 있다면 트래픽을 전달하는 것 외에 수행해야 할 많은 작업이 있다.
• 예를 들어 사용자가 매번 IP 주소를 입력하는 것을 원하지 않아 DNS 서버를 구성해 사용자가 노드의 IP를 입력하지 않고도 애플리케이션에 액세스할 수 있도록 하기도 한다.
• 사용자는 이제 myonlinestore.com:38080을 사용해 애플리케이션에 액세스할 수 있다.
• 이제 사용자가 포트 번호를 기억하지 않아도 접근하게 하고싶다. 그러나 서비스 노드 포트는 30000 번대 이상인 고 번호 포트만 할당할 수 있다. 따라서 DNS 서버와 클러스터 간에 추가적인 계층을 가져와 포트 80으로 들어오는 요청을 노드의 포트 38080으로 프록시하는 프록시 서버를 생성할 수도 있다.
• GCP와 같은 퍼블릭 클라우드 환경에서는 NodePort를 생성하는 대신 로드 밸런서 유형의 서비스를 생성할 수 있다. 이렇게 하면 GCP에 트래픽을 라우팅하기 위한 네트워크 로드 밸런서를 프로비저닝 하는 요청을 보내고, 요청을 받은 GCP는 자동으로 모든 노드에서 서비스 포트로 트래픽을 라우팅할 수 있도록 구성된 로드 밸런서를 배포한 다음 해당 정보를 쿠버네티스에 반환한다.
• 로드 밸런서에는 애플리케이션에 액세스할 수 있도록 사용자에게 제공할 수 있는 외부 IP가 있다. 이 경우 DNS를 외부 IP로 지정하고 사용자는 myonlinestroe.com을 사용해 애플리케이션에 액세스할 수 있다.

• 이후 회사가 성장해 비디오 스트리밍 서비스가 추가 되었고, 사용자가 myonlinestore.com/watch 로 이동해 새 비디오 스트리밍 서비스에 액세스할 수 있기를 원한다.
• 또한 이전 애플리케이션은 myonlinestore.com/wear 에서 액세스할 수 있게하고 싶다.
• 개발자들은 새로운 비디오 스트리밍 애플리케이션을 완전히 다른 애플리케이션으로 개발해 기존 애플리케이션과는 관련이 없으나, 동일한 클러스터 리소스를 공유하기 위해 새로운 애플리케이션을 동일한 클러스터 내 별도의 디플로이먼트로 배포한다.
• video-service 라는 로드 밸런서 유형의 서비스를 생성하고, 포트 38282를 프로비저닝하고 클라우드에 네트워크 로드 밸런서를 프로비저닝 한다.
• 각각의 로드 밸런서는 각각 비용이 지불되고 많은 로드 밸런서를 보유하면 많은 비용이 청구될 수 있어 역효과다.
• 그래서 사용자가 입력하는 URL을 기반으로 로드 밸런서 간의 트래픽을 지시하기 위해서는 또 다른 프록시 또는 로드 밸런서가 필요하다.
• 그리고 애플리케이션에 SSL을 활성화 해 사용자가 HTTPS를 사용해 애플리케이션에 액세스할 수 있어야한다.
• 위와 같은 모든 요구사항을 충족하기 위해서 Ingress를 사용하면 된다.

• Ingress를 사용하면 사용자가 클러스터 내에서 기반을 둔 URL을 기반으로 서로 다른 서비스로 경로를 구성할 수 있는 단일 외부 액세스 가능한 URL을 사용자에게 제공할 수 있고, 동시에 SSL 보안을 구현할 수도 있다.
• 간단히 말해 Ingress를 쿠버네티스 클러스터에 내장된 레이어 7 로드 밸런서로 생각할 수 있으며, 네이티브 쿠버네티스 프리미티브를 사용하여 구성할 수 있다.
• 인그레스를 사용하여도 여전히 외부에서 액세스하기 위해선 expose를 해야한다. 그래서 노드 포트로 구성하거나 클라우드 네이티브 로드 밸런서로 게시해야 하지만 단 한번의 구성일 뿐이다.

• 인그레스가 없었다면 nginx 또는 HA Proxy 또는 Traefik과 같은 로드 밸런싱 솔루션을 사용할 것이다.
• Ingress는 쿠버네티스에서 위와 같은 로드 밸런싱 솔루션과 같은 방식으로 구현된다.
• 먼저 지원되는 솔루션을 배포하고(nginx, haproxy, traefik 등등) 그 다음 일련의 규칙을 지정하여 Ingress를 구성한다.
• 배포한 솔루션은 Ingress 컨트롤러라고 하며 구성한 일련의 규칙은 Ingress 리소스라고 한다.
• 인그레스 리소스는 이전에 파드, 디플로이먼트, 서비스를 만들 때 사용한 정의 파일을 사용하여 생성된다.
• 쿠버네티스에는 기본적으로 내장된 인그레스 컨트롤러가 없다. Ingress 컨트롤러를 배포해야한다. 종류로는 GCE(Google의 레이어 7 HTTP 로드 밸런서), Nginx, Contour, HAProxy, Traefik 및 Istio이다.
• 이중 GCE와 Nginx는 현재 쿠버네티스 프로젝트에서 지원 및 유지 관리되고 있다.

• Ingress 컨트롤러는 또 다른 로드 밸런서 또는 Nginx 서버가 아니다. 인그레스 컨트롤러에는 쿠버네티스 클러스터를 모니터링하여 새로운 정의 또는 Ingress 리소스를 구성하고 Nginx 서버를 그에 맞게 설정하는 추가 지능이 설정되어 있다.
• nginx controller는 쿠버네티스에서 딱 한번 배포되는 단일 배포로 구현된다. 따라서 하나의 레플리카와 간단한 파드 정의 템플릿이 있는 nginx Ingress Controller라는 배포 정의 파일로 시작한다.
• ingress controller의 이미지를 설정하고, 이미지 내에서 nginx 프로그램은 /nginx-ingress-controller에 저장되므로 nginx controller 서비스를 시작하는 명령으로 전달해야한다.
• 이전에 nginx를 사용해봤다면, 로그 저장 경로, keep-alive 임계 값, SSL 설정, 세션 타임 아웃 등과 같은 구성 옵션이 있음을 알고 있을 것이다.
• 이 구성 데이터를 Nginx Controller Image에서 분리하려면 configmap 객체를 만들고 해당 객체를 전달해야한다.
• 이때 configmap 객체에는 빈 객체여도 상관은 없다. 나중에 구성 설정을 수정하기 쉽게 configmap에 추가하기만 하면 된다.

• Nginx 컨트롤러의 이름과 배포된 네임스페이스를 전달하는 두 개의 환경 변수를 전달해야한다. Nginx 서비스는 이러한 정보를 파드 내에서 config 데이터를 읽기 위해 필요로 한다.
• 마지막으로 Ingress 컨트롤러에서 사용되는 포트를 지정해야한다. 위 이미지의 경우 80과 443이다.
• 그 다음 외부에 Ingress 컨트롤러를 expose하기 위해 서비스가 필요하다.

• Ingress 레이블 셀렉터로 유형이 NodePort인 서비스를 만든다.

• 그리고 이 모든 작업들을 수행하기 위해서는 올바른 권한 세트를 가진 서비스 계정이 필요하다. 이를 위해 올바른 역할 및 역할 바인딩을 가진 서비스 계정을 생성한다.

• 결론적으로 인그레스 컨트롤러를 구성하기 위해 위와 같은 오브젝트들을 생성해주어야한다.

• 인그레스 리소스는 인그레스 컨트롤러에 적용되는 규칙 및 config의 집합이다.
• 모든 수신 트래픽을 단일 애플리케이션으로 전달하거나 URL을 기반으로 트래픽을 다른 응용 프로그램으로 라우팅하는 규칙을 구성할 수 있다.
• 따라서 사용자가 myonlinestore.com/wear로 이동하면 하나의 애플리케이션으로 라우팅되거나 사용자가 watch. myonlinestore.com 을 방문하면 비디오 앱으로 라우팅되는 등의 규칙을 구성할 수 있다.

• 인그레스 리소스는 쿠버네티스 정의 파일을 사용하여 생성된다.
• apiVersion은 extensions/v1beta1이다.
• spec 아래에 backend 가 있다. backend 섹션은 트래픽이 어디로 라우팅 될지를 정의한다. 따라서 단일 백엔드면 실제로 규칙이 없는 것과 같다. serviceName과 servicePort를 간단히 지정할 수 있다.

• 트래픽을 라우팅하려는 다른 조건에 따라 트래픽을 라우팅하려면 규칙을 사용한다. 각 규칙 내에서 다양한 경로를 처리할 수 있게끔할 수 있다.

• 각 호스트 또는 도메인 이름에 대한 맨 위의 규칙이 있으며 각 규칙 내에서 URL에 기반하여 트래픽을 라우팅하는 다양한 경로를 설정할 수 있다.
• describe할 시 Rules 항목을 통해 확인 가능하다.

• 또한 host 필드를 설정해 도메인 이름으로 트래픽을 분리할 수 있다.
• 호스트 필드를 지정하지 않으면 해당 규칙을 통해 들어오는 모든 트래픽을 수락하는 것으로 간주한다. 이 경우 하나의 백엔드 경로만 각 규칙에 있음을 유의해야한다.
• 이 경로는 URL path 와 관계없이 이러한 도메인 이름에서 오는 모든 트래픽을 적절한 백엔드로 라우팅한다.