OpenNJet KIC V2.0 출시!

[심천] Yuanchuanghui: 오후 5시 26분, 파티홀이 여러분을 기다리고 있습니다.”

NGINX, 클라우드 네이티브로 진화, All in OpenNJet

개요

OpenNJet KIC(Kubernetes Ingress Controller)는 OpenNJet 프록시의 동적 특성과 고성능 구현을 기반으로 합니다. 클라우드 네이티브 시나리오에서 nginx의 단점을 보완합니다. 동적 위치, 호스트/경로 라우팅, 로드 밸런싱, 동적 업스트림, 카나리아 게시, TLS 종료/SNI, TCP/UDP, WebSocket 등 풍부한 트래픽 관리 기능을 제공합니다.

이 버전의 주요 기능:

샤딩 처리 Ingress/VS CR 지원
ADC와의 통합 지원
HTTP 헤더 작업 지원
TCP 프록시 지원
네임스페이스 간 지원
WebSocket 프록시 지원
UDP 프록시 지원
동적 NJet VS/Accesslog 지원
TCP 활성 상태 확인 지원
작업자 프로세스 수의 동적 조정 지원

이 문서에서는 이러한 새로운 기능에 대해 간략하게 소개합니다.

아키텍처 다이어그램은 다음과 같습니다.

새로운 기능 개요

샤딩 처리 수신/VS CR

다양한 Ingress/VS 리소스를 처리하기 위한 특수 KIC가 있습니다. 이것이 바로 KIC 샤딩 메커니즘입니다.

다양한 Ingress/VS 리소스는 ingressClass로 식별할 수 있습니다. Ingress 리소스는 kubernetes.io/ingress.class 또는 spec.ingressClassName 주석으로 식별할 수 있으며, VS 리소스는 spec.ingressClassName으로 식별할 수 있습니다.

이 샤딩 메커니즘의 각 KIC는 KIC 유형이라고 하며 IngressClass에 일대일로 대응합니다. k8s 클러스터에서 Njet KIC가 여러 개 있는 경우 IngressClass 개체를 여러 개 생성해야 합니다. 각 유형의 KIC에는 여러 복사본이 있을 수 있습니다(k8s 아키텍처의 여러 포드에 해당).

샤딩 메커니즘을 통해 각 KIC는 k8s 클러스터의 모든 Ingress/VS 리소스가 아닌 관심 있는 자체 Ingress/VS 리소스를 갖게 됩니다. 단일 유형의 KIC가 전체 구성의 압력을 견딜 수 없는 문제를 해결하는 것을 목표로 합니다.

ADC와 통합

KIC가 ADC와 통합되면 ADC는 KIC의 프런트 엔드 LB 역할을 하여 ADC를 통해 클라이언트 트래픽을 관리하고 궁극적으로 KIC 서비스에 대한 로드 밸런싱을 수행할 수 있습니다. KIC는 다음과 같은 기능을 완료했습니다.

ADC 도메인 이름 등록: KIC는 k8s 수신 및 vs CR을 통해 관리되는 서비스와 같이 KIC가 관리하는 k8s 클러스터의 서비스 도메인 이름을 ADC에 등록합니다. 이 기능을 사용하면 클라이언트가 도메인 이름을 통해 직접 요청할 수 있습니다(ADC의 DNS 서버를 기본 DNS 서버로 구성해야 함).
ADC SlbPool 등록: KIC는 KIC 서비스와 관련된 응용 프로그램 풀(nodeIP+nodePort)을 ADC에 등록합니다. 이 기능을 사용하면 ADC가 KIC 서비스로 라우팅할 수 있습니다.
ADC VS 등록: KIC는 VS를 ADC에 등록하고 이를 2단계에서 생성한 애플리케이션 풀과 연결하는 기능을 통해 클라이언트가 VS에 직접 접근할 수 있도록 하여 ADC가 KIC의 프런트엔드 LB 역할을 할 수 있도록 합니다.

ADC VS의 VIP는 KIC가 관리하는 서비스의 도메인 이름에 해당합니다.
ADC VS의 VIP는 외부 클라이언트가 직접 접근할 수 있는 공용 네트워크 IP입니다.

전체 구조

장면 그래프:

상호작용 아키텍처 다이어그램:

HTTP 헤더 조작

OpenNJet KIC 헤더 작업은 클라이언트 요청 헤더를 수정하고 프록시된 서비스의 응답 헤더에서 작업할 수 있습니다. 사용자 정의 헤더와 HTTP 사양에 정의된 헤더를 포함합니다.

TCP 프록시

KIC TCP 프록시는 업스트림 TCP 서비스를 프록시할 수 있습니다. TCP 프록시는 로드 밸런싱 기능을 제공합니다. TCP 프록시는 완전히 동적으로 구현되며 다시 로드 작업을 수행하기 위해 OpenNJet이 필요하지 않습니다.

프록시된 TCP 서비스에는 자체 수신 포트가 있습니다. 프록시된 서비스가 많을수록 수신해야 하는 포트가 더 많아집니다. 기존 Nginx 구현에서는 다시 로드 문제를 해결하기 위해 포트 전달을 사용합니다. . 이 방법은 TCP 서비스의 프록시를 구현합니다. 구체적인 디자인은 다음과 같습니다.

OpenNJet 스트림 구성은 12003 포트를 미리 수신합니다(프록시 TCP 서비스에서 모니터링하는 포트는 12003으로 리디렉션됩니다).
KIC는 고객이 정의한 API를 통해 iptables 규칙을 생성하고, iptables 규칙을 통해 요청된 TCP 서비스 포트를 포트 12003으로 리디렉션합니다.
OpenNJet 스트림이 클라이언트를 통해 접속하는 "TCP 서비스 포트"는 고객이 API를 통해 미리 구성한 업스트림과 일치합니다. 이 과정은 스트림 맵을 통해 일치됩니다.
OpenNJet 스트림은 성공적으로 일치하는 업스트림의 서버에 클라이언트 요청을 보냅니다(로드 밸런싱은 스트림 lua에 의해 구현됨).

iptables 규칙 및 지도 콘텐츠 업데이트는 API를 사용하여 동적으로 업데이트되므로 다시 로드 작업이 필요하지 않습니다.

OpenNJet 구성은 다음과 같이 구현됩니다.

 map $njtmesh_port \$stream_upstream {
 }
 
 server {
 listen 12003 mesh;
 set $proxy_upstream_name \$stream_upstream;
 proxy_pass upstream_balancer;
 }

클라이언트가 요청한 포트는 항상 TransportServer의 리스너 포트입니다.
이 포트는 KIC에서 내부적으로 사용되므로 프록시 서비스에서 사용할 수 없습니다. 설명은 다음 표에 설명되어 있습니다.

포트	설명하다
80	http 프록시
443	https 프록시
12001	OpenNJet 제어 평면
12002	TCP 루아 업스트림
12003	TCP 프록시 포트
12004	UDP 프록시 포트
8080	stub_status 및 http lua 업스트림
8081	KIC 포드 준비 포트

네임스페이스 전반에 걸쳐

K8s의 내장 Ingress는 동일한 ns의 서비스 라우팅만 처리할 수 있으며 교차 ns 작업을 수행할 수 없습니다. 네임스페이스 간 구성 기능은 이 제한 사항을 해결합니다.

VS는 크로스 네임스페이스 구성을 지원하는 Ingress 외에도 크로스 ns 구성도 지원합니다. 사용자는 자신의 상황에 따라 선택할 수 있습니다.

Ingress는 다양한 Ingress 유형을 통해 이 기능을 구현합니다. Ingress 자체에는 유형 개념이 없습니다. "njet.org.cn/mergeable-ingress-type" 주석을 추가하여 표현합니다. 주석은 다음 표의 값을 취할 수 있습니다.

값	설명하다	주목
주인	메인 인그레스	하나
미니언	FromIngress	여러 개일 수 있으며 호스트를 통해 마스터 Ingress와 연결됨

동일한 호스트의 마스터와 미니언은 동일한 ns에 있을 수도 있고 다른 ns에 있을 수도 있습니다.

Cross-ns 구성 외에도 이 기능을 선택하여 호스트에 경로 수가 많고 단일 Ingress 유지 관리가 복잡한 경우 이 기능을 선택하여 경로를 관리할 수도 있습니다.

VS CR은 Ingress와 기능은 동일하지만 구현 방법이 다릅니다. 하위 라우팅 리소스를 참조하여 Cross-ns 구성을 수행하며, 하위 경로는 VSR을 나타내는 데 사용됩니다. VSR은 이 기능을 위해 도입된 새로운 CR인 K8s CR입니다.

WebSocket 프록시

WebSocket은 독립적인 TCP 기반 애플리케이션 계층 프로토콜이자 전이중 통신 프로토콜입니다. HTTP와의 유일한 관계는 핸드셰이크가 HTTP 서버에 의해 HTTP 업그레이드 요청으로 해석된다는 것입니다. 핸드셰이크가 끝나면 HTTP와 아무 관련이 없습니다. 프로토콜은 핸드셰이크와 데이터 전송이라는 두 부분으로 구성됩니다. 핸드셰이크 단계는 아래 그림에 나와 있습니다.

Ingress는 "njet.org.cn/websocket-services" 주석을 추가하여 표현하는 주석을 추가하여 이 기능을 구현합니다.

주석 이름	값 형식	설명하다
njet.org.cn/websocket-services	service,service2(쉼표로 구분된 서비스 이름)	웹소켓 지원

VS에는 구성이 필요하지 않습니다.

UDP 프록시

KIC UDP 프록시는 업스트림 UDP 서비스를 프록시할 수 있습니다. UDP 프록시는 로드 밸런싱 기능을 제공합니다. UDP 프록시는 완전히 동적으로 구현되며 다시 로드 작업을 수행하기 위해 OpenNJet이 필요하지 않습니다.

UDP 서비스 프록시 구현은 기본적으로 TCP 서비스 프록시와 동일합니다. 단, OpenNJet 스트림 구성이 12004 포트를 미리 수신하는 반면(프록시 UDP 서비스에서 모니터링하는 포트는 12004로 리디렉션됨) TCP는 다음 포트를 미리 수신합니다. 12003 포트. 자세한 지침은 TCP 프록시를 참조하세요.

OpenNJet 구성은 다음과 같이 구현됩니다.

map $njtmesh_port \$stream_upstream_udp {
}

server {
listen 12004 udp mesh;
set $proxy_upstream_name $stream_upstream_udp;
proxy_pass upstream_balancer;
}

다이나믹 NJet VS

첫 번째 버전과 비교하여 HTTP 호스트 헤더 일치 및 경로 일치를 달성하기 위해 단일 서버 및 다중 위치 접근 방식을 다중 서버 및 다중 위치 접근 방식으로 변경했지만 호스트 헤더 일치를 구현하기 위해 nginx 표준 server_name을 사용했습니다. 구성을 동적으로 업데이트했습니다. 예, 다시 로드 작업이 필요하지 않습니다. 두 번째 버전은 Ingress 및 VirtualServer에 대한 추가 기능을 추가하지 않습니다.

동적액세스로그

KIC Accesslog 기능을 사용하면 특정 애플리케이션에 개별적으로 액세스 로그 정책(스위치 상태 및 액세스 로그 파일 경로 포함)을 적용할 수 있습니다. njet-config ConfigMap을 통해 전역 설정을 할 수도 있지만 "액세스 로그 정책을 애플리케이션에 개별적으로 적용"하는 것이 우선순위가 더 높습니다.

TCP 사전 상태 확인

전송 서버 리소스의 경우 TCP 포트를 구성하는 것이 지원됩니다. 활성 상태 확인은 구성된 확인 간격에 따라 TCP 포트가 정상적으로 수신 중인지 여부를 감지하고 확인 결과에 따라 백엔드가 온라인 및 오프라인 상태가 됩니다.

apiVersion: k8s.njet.org/v1alpha1
 kind: TransportServer
 metadata:
 name: testapp-tcp
 spec:
 listener:
 name: test-tcp
 protocol: TCP
 upstreams:
 - name: testapp1
 service: testapp
 port: 80
 healthCheck:
 enable: true
 interval: 20s
 timeout: 5s
 fails: 1
 passes: 1
 port: 83
 action:
 pass: testapp1

구성 지침은 다음과 같습니다.

필드	설명하다	유형	필수인가요?
~할 수 있게 하다	상태 확인 활성화 여부, 기본값은 false	부울	아니요
간격	검사 사이의 간격입니다. 기본값은 5입니다.	끈	아니요
실패하다	몇 번 실패하면 오프라인으로 간주됩니다. 기본 1회	정수	아니요
패스	여러 번의 성공 후에 온라인으로 고려될 것입니다. 기본 1회	정수	아니요
포트	헬스체크 서비스가 위치한 항구	정수	아니요
시간 초과	상태 확인 연결 시간 초과	끈	아니요

동적 작업자 프로세스 번호 조정

ConfigMap 리소스를 통해 njet 인스턴스의 작업자 프로세스 수 구성을 지원합니다. ConfigMap의 구성 항목이 업데이트되면 작업자 프로세스 수가 동적으로 수정됩니다.

구성 항목	설명하다	필드 유형	기본값	주목
작업자 프로세스	작업자 프로세스 수(허용값 1~512)	끈	기본값은 CPU 코어 수에 따라 자동으로 생성되는 프로세스 수입니다.

참고 링크

OpenNJetKIC 사용자 매뉴얼

OpenNJet KIC 소스 코드 주소

NJet 애플리케이션 엔진은 커널 재구성을 통해 고유한 런타임 동적 구성 로딩 기능을 달성하며 차세대 고성능 웹 애플리케이션 엔진 입니다 . NJet은 고성능 데이터 플레인 처리 기능을 갖추고 있으며 NJet의 고유한 부조종사 CoPilot 서비스 프레임워크를 통해 클러스터링, 고가용성, 활성 상태 확인 및 선언적 API와 같은 여러 보조 기능을 예약하여 기능 확장을 촉진하고 관리/제어 기능 쌍을 분리합니다. 데이터 플레인에 미치는 영향까지 NJet 애플리케이션 엔진의 성능은 CNCF에서 권장하는 Envoy 애플리케이션 엔진의 3배를 초과합니다. 메일 그룹 공식 홈페이지