Ingress 컨트롤러: 새로운 이름, 익숙한 기능

구어체 표현. 이러한 단어와 문구는 지역 특유의 의미를 가지고 있어 해당 지역 출신이 아닌 사람들에게는 혼란스러울 수 있습니다. 예를 들어, 외출 중이거나 목이 마르면 탄산음료를 찾습니다. 당신은 아마 (스코니가 아니라고 추측하면서) 분수대를 찾고 있을 겁니다. 위스콘신에서는 마일이 아닌 시간으로 거리를 측정합니다. 신호등은 '멈추고 가세요' 신호입니다. 그게 당신이 하는 일이잖아요.

제 남편이 가장 좋아하는 웃음거리는 (그는 원주민이 아니지만) "한 번만 와봐"입니다. 저는 그것이 저와 제가 사용하는 아이들에게 의미가 있는 것 이상으로 설명하려고 하지 않을 것입니다. 그리고 우리는 "Up North"가 방향이 아니라 화자에게 특정할 수 있는 위치이지만 "모든 것에서 벗어나기 위해 가는 장소"를 설명하는 모든 위스콘신 원주민에게 공통적인 의미를 지닌 장소라는 것을 본능적으로 이해합니다.

당신은 다른 곳에서 자랐기 때문에 당신만의 목록이 있을 것입니다. 하지만 여기는 제 블로그니까, 제 블로그를 자유롭게 사용할 수 있죠.

하지만 오늘의 요점은 의미론 자체에 대한 수업이 아니라, 바로 우리 집 주변에서 일어나는 보다 지역적인 현상에 의미론을 적용하는 것에 대한 것입니다. 적어도 당신의 뒷마당이 당신의 조직이었다면요.

컨테이너와 그에 필수적인 자동화된 클러스터링 제어 시스템(종종 오케스트레이션이라고 함)의 등장은 의도치 않게 주 경계선의 한쪽에서 다른 쪽으로 구어체 표현을 강제로 사용하게 만드는 결과를 낳았습니다. 그건 그렇고, 앱 개발을 IT 분야에 적용한 거예요.

컨테이너 구어체의 흥미로운 사례

확장에 필요한 유연성과 안정성을 달성하는 데 필요한 많은 기능은 이전에 프로덕션 전용이었던 특정 서비스를 컨테이너 "환경"으로 마이그레이션하는 것을 의미했습니다. 이러한 기능은 이제 가벼운 통합(API 및 메시지 대기열)을 사용하여 해당 환경에 "내장"되어 있으며, 지금까지 완전히 구현된 클라우드 컴퓨팅 환경에서만 실현할 수 있었던 자동 확장 및 고가용성 애플리케이션을 구현합니다.

이를 통해 부하 분산 기능은 작은 데몬 형태의 서비스를 통해 포드/노드에 기본적으로 제공됩니다. 그다지 발전된 것은 아니지만(네트워크 부하 분산 기능보다 약간 더 나은 수준이라고 할 수 있음) 설계된 대로의 기능을 수행합니다. 이러한 서비스는 원한다면 플러그인이 가능하며(실제로 플러그인되기도 함) 다른 프로젝트(오픈 소스 및 공급업체 제공)에서 더욱 고급 기능(그리고 알고리즘)을 활용할 수 있게 해줍니다.

하지만 이러한 부하 분산 기능 자체로는 우리가 궁극적으로 찾고 있는(그리고 프로덕션 환경에서 필요로 하는) 확장성과 고가용성을 실현할 수 없습니다. 또한 HTTP(L7) 스마트 기능이 필요한 API를 라우팅할 수도 없습니다. 마이크로서비스로 뒷받침되고 API 퍼사드로 대표되는 최신 애플리케이션을 효율적으로 확장하려면 이것이 필요합니다. 우리는 더욱 강력한 해결책이 필요합니다.

여기서 인그레스 컨트롤러가 등장합니다. 이는 URI와 HTTP 헤더를 기반으로 유입 트래픽을 분석하고 지시하여 애플리케이션 계층 라우팅과 확장성을 가능하게 하는 "로드 밸런서"입니다.

인그레스 컨트롤러를 만든(그리고 나중에 사용한) 개발자들이 트래픽 관리나 애플리케이션 전송, 콘텐츠 전환/라우팅이라고 부르는 것을 기본적으로 재생성한 것입니다. 우리는 수년에 걸쳐 netops와 dev(ops) 분야에서 다양한 용어를 사용해 왔습니다. 앱 라우팅과 페이지 라우팅도 개발자가 L7 라우팅을 설명하는 데 사용하는 용어입니다. 이 개념은 두 그룹 모두에게 생소하지 않습니다. 하지만 그 용어, 즉 구어체는 그렇습니다.

인 그레스 컨트롤러 는 컨테이너 클러스터 내의 적절한 (가상) 서비스로 요청을 라우팅하는 역할을 담당합니다. 해당 서비스는 또 다른 로드 밸런싱 프록시일 수도 있고 컨테이너 시스템에 특화된 구성일 수도 있습니다. 어느 경우 든 인그레스 컨트롤러 의 역할은 HTTP 요청의 HTTP 헤더 내의 계층 7(HTTP) 값을 기반으로 트래픽을 라우팅하는 것입니다. 일반적으로 이는 URI이지만 호스트 이름이거나 다른 사용자 정의 값(예: 버전 번호나 API 키)일 수도 있습니다.

인그레스 컨트롤러가 헤더에서 값을 추출하면 리소스 파일에 기술된 정책을 사용하여 값을 배포하는 방법을 결정합니다. 균등하게 분배할 수도 있고, 75%를 한 서비스 버전에 보내고 25%를 다른 서비스 버전에 보낼 수도 있습니다. 이 방법은 매우 유연합니다. 인 그레스 컨트롤러는 모니터링(상태 및 상태) 책임을 더 가지고 있으며, "죽은" 서비스에 요청을 분배하지 않도록 매우 조심해야 합니다.

익숙한 내용인가요, 넷톱스? 그렇습니다. 기본적으로 이는 스마트(L7 지원) 프록시(BIG-IP 등)의 기능이기 때문입니다.

이제 둘이 어떻게 같은지 알았으니, 몇 가지 차이점도 있다는 걸 확신시켜드리겠습니다. 특히, 인그레스 컨트롤러 는 선언적으로 구성됩니다. 즉, 해당 구성은 컨트롤러 자체 외부에 있는 리소스 파일의 설명에 따라 결정됩니다. 이는 유입 트래픽을 제어하고 지시하는 기존의 스마트 프록시와는 다릅니다. 기존의 스마트 프록시는 환경에 대한 권위 있는 소스입니다. 유입 컨트롤러가 아닙니다. 그것은 구현에 있어서 유연성을 허용하는 일종의 "추상화 계층" 역할을 하는 파일을 다른 곳에서 찾습니다. 즉, 해당 구성 요소(또는 보완 구성 요소)가 이를 읽고 해석한 후 해당 설명에 적합한 구성을 만들어야 합니다. 그리고 이를 최신 상태로 유지해야 합니다. 컨테이너화된 환경의 유입 제어 변동성은 시스템 내부의 깊은 곳의 변동성보다 적지만, 그래도 변화하므로 주의해야 합니다.

모든 것을 종합해 보면, 인그레스 컨트롤러는 외부에서 컨테이너화된 환경 내부의 적절한 리소스로 요청을 애플리케이션 계층으로 라우팅하는 역할을 담당합니다. 이는 스마트 로드 밸런서의 정의와 같습니다.

이름은 바뀌었지만 기능은 거의 변함이 없습니다.