OpenNJet KIC V2.0 lançado!

[Shenzhen] Yuanchuanghui: 17h26, o salão de festas está esperando por você.”

NGINX evolui para nuvem nativa, tudo em OpenNJet

Visão geral

OpenNJet KIC (Kubernetes Ingress Controller) é baseado nas características dinâmicas e na implementação de alto desempenho do proxy OpenNJet. Compense as deficiências do nginx em cenários nativos da nuvem. Fornece recursos avançados de gerenciamento de tráfego, como localização dinâmica, roteamento de host/caminho, balanceamento de carga, upstream dinâmico, publicação canário, terminação TLS/SNI, TCP/UDP, WebSocket, etc.

Principais características desta versão:

Suporta processamento de fragmentação Ingress/VS CR
Integração de suporte com ADC
Suporta operações de cabeçalho HTTP
Suporta proxy TCP
Suporte para namespace cruzado
Suporte a proxy WebSocket
Suporta proxy UDP
Suporta NJet VS/Accesslog dinâmico
Suporte à verificação de integridade ativa do TCP
Apoie o ajuste dinâmico do número de processos de trabalho

Este artigo fornece uma breve introdução a esses novos recursos.

O diagrama de arquitetura é o seguinte:

Visão geral dos novos recursos

Processamento de fragmentação Ingress/VS CR

Existem KICs especiais para processar diferentes recursos do Ingress/VS. Este é o mecanismo de fragmentação do KIC.

Diferentes recursos do Ingress/VS são identificados por ingressClass. Os recursos do Ingress podem ser identificados pela anotação kubernetes.io/ingress.class ou spec.ingressClassName, e os recursos do VS podem ser identificados por spec.ingressClassName.

Observe que cada KIC neste mecanismo de fragmentação é chamado de um tipo de KIC e corresponde ao IngressClass individualmente. Em um cluster k8s, se houver vários KICs Njet, vários objetos IngressClass precisarão ser criados. Cada tipo de KIC pode ter múltiplas cópias (correspondendo a vários pods na arquitetura k8s).

O mecanismo de fragmentação faz com que cada KIC tenha seus próprios recursos do Ingress/VS nos quais está interessado, em vez de todos os recursos do Ingress/VS no cluster k8s. O objetivo é resolver o problema de que um único tipo de KIC não consegue suportar a pressão da configuração completa.

Integrar com ADC

Depois que o KIC for integrado ao ADC, o ADC poderá servir como LB front-end do KIC, gerenciando o tráfego do cliente por meio do ADC e, em última análise, balanceando a carga para os serviços do KIC. KIC completou as seguintes funções:

Registro de nome de domínio ADC: KIC registra no ADC os nomes de domínio de serviços no cluster k8s gerenciados por KIC, como serviços gerenciados por meio de entrada k8s e vs CR. Esta função permite que os clientes façam solicitações diretamente através de nomes de domínio (o servidor DNS do ADC precisa ser configurado como servidor DNS padrão).
Registro ADC SlbPool: KIC registra o pool de aplicativos (nodeIP+nodePort) associado ao serviço KIC com ADC. Esta função permite que o ADC roteie para o serviço KIC.
Registro ADC VS: KIC registra um VS com ADC e o associa ao pool de aplicativos criado na segunda etapa. Esta função permite que o cliente acesse diretamente o VS, para que o ADC possa servir como LB front-end do KIC.

O VIP no ADC VS corresponde ao nome de domínio do serviço gerido pela KIC.
O VIP no ADC VS é um IP de rede pública, que pode ser acessado diretamente por clientes externos.

Estrutura geral

Gráfico de cena:

Diagrama da arquitetura de interação:

Manipulação de cabeçalho HTTP

A operação do cabeçalho OpenNJet KIC pode modificar o cabeçalho da solicitação do cliente e operar no cabeçalho de resposta do serviço proxy. Incluindo cabeçalhos definidos pelo usuário e cabeçalhos definidos na especificação HTTP.

Proxy TCP

O proxy KIC TCP pode fazer proxy de serviços TCP upstream. O proxy TCP fornece recursos de balanceamento de carga. O proxy TCP é totalmente implementado dinamicamente e não requer OpenNJet para executar uma operação de recarga.

O serviço TCP com proxy terá sua própria porta de escuta. Quanto mais serviços com proxy, mais portas precisam ser escutadas. Na implementação tradicional do Nginx, cada nova escuta requer configuração de recarga. O método implementa o proxy do serviço TCP. O design específico é o seguinte:

A configuração do fluxo OpenNJet pré-escuta uma porta 12003 (a porta monitorada pelo serviço proxy TCP será redirecionada para 12003).
KIC gera regras de iptables por meio da API definida pelo cliente e redireciona a porta de serviço TCP solicitada para a porta 12003 por meio de regras de iptables.
A "porta de serviço TCP" que o fluxo OpenNJet acessa por meio do cliente corresponde ao upstream configurado antecipadamente pelo cliente por meio da API. Este processo é correspondido através do mapa de fluxo.
O fluxo OpenNJet envia a solicitação do cliente ao servidor no upstream que corresponde com sucesso (o balanceamento de carga é implementado pelo fluxo lua).

As regras do iptables e as atualizações do conteúdo do mapa são atualizadas dinamicamente usando API, evitando operações de recarga.

A configuração do OpenNJet é implementada da seguinte forma:

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

A porta solicitada pelo cliente é sempre a porta do listener no TransportServer.
A porta não pode ser usada pelo serviço de proxy porque será usada internamente pelo KIC. A descrição está descrita na tabela a seguir:

porta	ilustrar
80	proxy HTTP
443	proxy https
12001	Plano de controle OpenNJet
12002	tcp lua a montante
12003	Porta proxy TCP
12004	Porta proxy UDP
8080	stub_status e http lua upstream
8081	Porta de preparação do pod KIC

Entre namespaces

O Ingress integrado do K8s só pode lidar com o roteamento de serviços no mesmo ns e não pode realizar operações cross-ns. O recurso de configuração entre namespaces resolve essa limitação.

Além do Ingress oferecer suporte à configuração entre namespaces, o VS também oferece suporte à configuração entre ns. Os usuários podem escolher de acordo com suas próprias circunstâncias.

O Ingress implementa esta função por meio de diferentes tipos de Ingress. O próprio Ingress não tem conceito de tipo. Nós o expressamos adicionando a anotação "njet.org.cn/mergeable-ingress-type". As anotações podem assumir valores da tabela a seguir:

valor	ilustrar	Observação
mestre	Entrada principal	um
lacaio	DoIngress	Pode ser múltiplo, associado ao Ingress mestre por meio do host

O mestre e o subordinado do mesmo host podem estar no mesmo ns ou em ns diferentes.

Além da configuração cross-ns, você pode escolher esta função quando um host possui um grande número de caminhos e a manutenção de um único Ingress é complicada, você também pode escolher esta função para gerenciar caminhos.

O VS CR tem a mesma função do Ingress, mas o método de implementação é diferente. O VS CR executa a configuração cross-ns referenciando um recurso de sub-roteamento. A sub-rota é uma string no formato ns/nome, que é usada para representar o VSR. recursos. VSR é um CR K8s, um novo CR introduzido para esse recurso.

Proxy WebSocket

WebSocket é um protocolo de camada de aplicativo independente baseado em TCP e um protocolo de comunicação full-duplex. Seu único relacionamento com HTTP é que seu handshake é interpretado pelo servidor HTTP como uma solicitação de atualização HTTP. Quando o handshake termina, não tem nada a ver com HTTP. O protocolo tem duas partes: handshake e transferência de dados. A fase de handshake é mostrada na figura abaixo:

O Ingress implementa esta função adicionando anotações, que expressamos adicionando a anotação "njet.org.cn/websocket-services".

Nome da anotação	formato de valor	descrever
njet.org.cn/websocket-services	service,service2 (nomes de serviços separados por vírgula)	Suporte para websocket

VS não requer nenhuma configuração.

Proxy UDP

O proxy KIC UDP pode fazer proxy de serviços UDP upstream. O proxy UDP fornece recursos de balanceamento de carga. O proxy UDP é implementado de forma totalmente dinâmica e não requer OpenNJet para executar uma operação de recarga.

A implementação do proxy de serviço UDP é basicamente a mesma que o proxy de serviço TCP, exceto que a configuração do fluxo OpenNJet pré-escuta uma porta 12004 (a porta monitorada pelo serviço proxy UDP será redirecionada para 12004), enquanto o TCP pré-escuta uma porta 12003. Para obter instruções detalhadas, consulte Proxy TCP.

A configuração do OpenNJet é implementada da seguinte forma:

map $njtmesh_port \$stream_upstream_udp {
}

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

NJet Dinâmico VS

Em comparação com a primeira versão, alteramos a abordagem de servidor único e de vários locais para obter correspondência de cabeçalho de host HTTP e correspondência de caminho para a abordagem de vários servidores e locais. Usamos o padrão nginx server_name para implementar a correspondência de cabeçalho de host, mas. atualizou dinamicamente a configuração Sim, nenhuma operação de recarga é necessária. A segunda versão não adiciona recursos adicionais para Ingress e VirtualServer.

Log de acesso dinâmico

A função KIC Accesslog permite aplicar políticas de accesslog (incluindo status do switch e caminho do arquivo de accesslog) individualmente a um determinado aplicativo. As configurações globais também podem ser feitas através do ConfigMap njet-config, mas "aplicar a política de accesslog individualmente a um aplicativo" tem uma prioridade mais alta.

Verificação de integridade proativa do TCP

Para recursos do Servidor de Transporte, há suporte para configurar uma porta TCP. A verificação de integridade ativa detectará se a porta TCP está escutando normalmente de acordo com o intervalo de verificação configurado, e o backend estará online e offline com base nos resultados da verificação.

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

As instruções de configuração são as seguintes:

Campo	descrever	tipo	É obrigatório?
habilitar	Se deve ativar a verificação de integridade, padrão falso	boleano	Não
intervalo	O intervalo entre verificações. O padrão é 5	corda	Não
falhar	Após algumas falhas, você será considerado offline. Padrão 1 vez	inteiro	Não
passes	Será considerado online após vários sucessos. Padrão 1 vez	inteiro	Não
porta	O porto onde o serviço de verificação de saúde está localizado	inteiro	Não
tempo esgotado	Tempo limite de conexão da verificação de integridade	corda	Não

Ajuste dinâmico do número do processo de trabalho

Suporta a configuração do número de processos de trabalho de instâncias njet por meio de recursos do ConfigMap Após a atualização dos itens de configuração no ConfigMap, o número de processos de trabalho será modificado dinamicamente.

Itens de configuração	ilustrar	Tipo de campo	valor padrão	Observação
processos de trabalho	Número de processos de trabalho (valores permitidos 1 - 512)	Corda	O padrão é o número de processos gerados automaticamente por auto com base no número de núcleos da CPU.

Link de referência

Manual do usuário OpenNJetKIC

Endereço do código-fonte OpenNJet KIC

O mecanismo de aplicativo NJet atinge recursos exclusivos de carregamento de configuração dinâmica em tempo de execução por meio da reconstrução do kernel e é uma nova geração de mecanismo de aplicativo da Web de alto desempenho . O NJet possui recursos de processamento de plano de dados de alto desempenho e programa múltiplas funções auxiliares, como clustering, alta disponibilidade, verificações de integridade ativas e APIs declarativas por meio da estrutura de serviço copiloto CoPilot exclusiva do NJet para facilitar a expansão de funções e isolar pares de funções de gerenciamento/controle devidos. ao impacto no plano de dados, o desempenho do mecanismo de aplicação NJet excede três vezes o desempenho do mecanismo de aplicação Envoy recomendado pela CNCF. Site oficial do grupo de correio