Logo JUNIPER NETWORKSIngegneria
Semplicità

Note di rilascio
Note sulla versione: Rete di contrail nativa del cloud 23.2
Pubblicato
Numero di telefono: 2023-06-30

Contenuto nascondere
1 Introduzione
2 Cosa c'è di nuovo
3 Integrazioni testate
4 Contenitore Tags
5 Questioni aperte
6 Problemi risolti
7 Richiesta di supporto tecnico
8 Cronologia delle revisioni
9 Documenti / Risorse
9.1 Riferimenti

Introduzione

Juniper Cloud-Native Contrail® Networking (CN2) è una soluzione SDN nativa del cloud che fornisce funzionalità di rete avanzate agli ambienti di rete cloud containerizzati. CN2 è ottimizzato per ambienti orchestrati da Kubernetes e può essere utilizzato per connettere, isolare e proteggere carichi di lavoro e servizi cloud senza soluzione di continuità su cloud privati, pubblici e ibridi.
Queste note di rilascio accompagnano la versione 23.2 di CN2. Descrivono nuove funzionalità, limitazioni, requisiti di compatibilità della piattaforma, comportamenti noti e problemi risolti in CN2.
Vedere il Rete di contrail nativa del cloud (CN2) pagina per un elenco completo di tutta la documentazione CN2.

Cosa c'è di nuovo

Scopri le nuove funzionalità introdotte nella versione 2 di CN23.2.

CN2 su Rancher RKE2

CN2 su Kubernetes a monte

  • A partire dalla versione 23.2, CN2 è supportato su Kubernetes v1.26.

Configura Kubernetes

  • Classi di priorità: a partire dalla versione 23.2, CN2 supporta le classi di priorità per i componenti critici di CN2. CN2 introduce l'oggetto PriorityClass, che consente di mappare una priorità, sotto forma di valore intero, al nome di una classe di priorità. I componenti essenziali di CN2 utilizzano queste classi predefinite in modo che kube-scheduler dia priorità a questi pod per la pianificazione e l'allocazione delle risorse.
    [Vedere Classi di priorità per componenti critici].
  • Pianificazione dei pod multi-cluster: a partire dalla versione 2 di CN23.2, CN2 supporta la pianificazione dei pod con riconoscimento della rete per distribuzioni multi-cluster. CN2 introduce il controller MetricsConfig e il controller CentralCollector. Questi controller riconciliano e gestiscono una CR del raccoglitore di metriche personalizzate e una CR del raccoglitore centrale. Queste risorse personalizzate consentono al contrail-scheduler di pianificare pod multi-cluster in base a parametri di rete importanti.
    [Vedere Pianificazione dei pod per distribuzioni multi-cluster ].

Rete virtuale avanzata

  • Convergenza rapida: a partire dalla versione 23.2, CN2 supporta la convergenza rapida. CN2 fornisce una soluzione SDN che offre la virtualizzazione della rete a livello di nodo di calcolo tramite rete overlay. In un SDN, gli errori possono verificarsi nell'overlay o nell'underlay. Il vRouter rileva, corregge e propaga qualsiasi errore ai gateway utilizzando controlli di integrità. La convergenza rapida migliora il tempo di convergenza in caso di guasti in un cluster gestito da CN2.
    [Vedere Configurare la convergenza veloce in CN2].
  • Graceful Restart e Graceful Restart di lunga durata: a partire dalla versione 23.2, è possibile configurare il Graceful Restart e il Graceful Restart di lunga durata (LLRG) in CN2. LLGR è un meccanismo utilizzato per preservare i dettagli di instradamento per un periodo di tempo più lungo in caso di guasto di un peer. Il riavvio graduale e LLGR garantiscono che i percorsi appresi non vengano immediatamente eliminati e ritirati dai peer pubblicizzati. Invece, i percorsi vengono mantenuti e contrassegnati come obsoleti. Di conseguenza, se le sessioni vengono ripristinate e i percorsi vengono riapresi, l'impatto complessivo sulla rete è ridotto al minimo.
    [Vedere Configura il riavvio grazioso e il riavvio grazioso di lunga durata].
  • Controllo dello stato BFD per sessioni BGPaaS: a partire dalla versione 2 di CN23.2, è possibile configurare il controllo dello stato di inoltro e rilevamento bidirezionale (BFD) per le sessioni BGP as a Service (BGPaaS).
    Quando configuri il controllo dello stato BFD, associ il servizio di controllo dello stato a un oggetto BBGaaS.
    Questa associazione attiva la creazione di sessioni BFD a tutti i vicini BBGaaS per quel servizio.
    Se la sessione BFD si interrompe, la sessione BGPaaS risultante termina e le rotte vengono ritirate.
    [Vedere Configura il controllo dello stato BFD per le sessioni BBGaaS].
  • Persistenza per flussi con carico bilanciato: a partire dalla versione 23.2, CN2 supporta la persistenza del flusso. La persistenza del flusso aiuta a ridurre al minimo la rimappatura del flusso tra i gruppi ECMP in un sistema con carico bilanciato. La viscosità del flusso riduce il flusso che viene rimappato e mantiene il flusso con il percorso originale quando il membro del gruppo ECMP cambia. Quando un flusso è interessato da una modifica di un membro, il vRouter riprogramma la tabella di flusso e ribilancia il flusso.
    [Vedere Vischiosità per flussi con carico bilanciato].

Analisi

  • Estendi TLS all'analisi: a partire dalla versione 23.2, puoi abilitare i certificati TLS per i componenti di analisi in CN2. TLS è un protocollo di sicurezza utilizzato per lo scambio di certificati, l'autenticazione reciproca e le cifre di negoziazione per proteggere il flusso da potenziali tamperrare e origliare. Per impostazione predefinita, il certificato e i segreti per il piano di controllo e vRouter vengono generati automaticamente nel gestore certificati Contrail. Quando installi i componenti con Helm, il gestore certificati crea automaticamente i certificati e i segreti necessari per ciascun componente analitico.
    [Vedere Estendi l'analisi TLS].
  • Mirroring del traffico basato sul flusso: a partire dalla versione 2 di CN23.2, CN2 può eseguire il mirroring selettivo del traffico di rete sulla base del flusso quando vRouter è in modalità flusso. Questo flusso di traffico di rete è specificato dalla politica di sicurezza e viene inviato all'analizzatore di rete che monitora e analizza i dati. L'analizzatore di rete è specificato con la risorsa mirrorDestination. Supporta anche la risorsa mirrorDestination presente all'esterno del cluster.
    Se la policy di sicurezza definisce SecondaryAction a livello di regola, viene eseguito il mirroring dei flussi corrispondenti alle regole con destinazione mirror.
    [Vedere Mirroring basato sul flusso].

Condotte CN2
CN2 Pipelines è uno strumento CI/CD che consente ai flussi di lavoro basati su GitOps di automatizzare la configurazione, i test e la qualificazione di CN2. CN2 Pipelines viene eseguito insieme ai cluster CN2 a partire dalla versione 2 di CN23.1 (Tech Preview). Nella versione 23.2, CN2 Pipelines supporta le funzioni di rete dei contenitori del cliente (CNF), genera automaticamente token di connessione per l'autenticazione, rileva i nodi del cluster in modo dinamico e utilizza i dati rilevati durante l'esecuzione del test.
[Vedere Guida alle pipeline CN2 per GitOps].

Integrazioni testate

A partire dalla versione 2 di CN23.1, le piattaforme supportate sono ora documentate in Integrazioni testate CN2. Questo documento include integrazioni completamente testate e convalidate da Juniper, comprese NIC testate e altri componenti software.

Contenitore Tags

Contenitore tags sono necessari per identificare l'immagine files da scaricare dal Contrail Container Registry durante l'installazione o l'aggiornamento di Contrail Networking.
Le procedure per accedere al Contrail Container Registry sono fornite direttamente da Juniper Networks. La posizione del files nel Contrail Container Registry sono cambiati per il software CN2 a partire dalla versione 22.4. Per ottenere le credenziali di accesso all'anagrafe o se hai domande in merito file posizioni all'interno del registro, inviare un'e-mail a: contrail-registry@juniper.net.
La tabella seguente fornisce il contenitore tag nome per l'immagine files per CN2 versione 23.2.

Tabella 1: Contenitore Tag—Versione 23.2

Piattaforma dell'orchestratore Contenitore Tag
• Kubernetes 1.26, 1.25.5, 1.23.9, 1.24.3
• Red Hat OpenShift 4.12.13, 4.12.0, 4.10.31, 4.8.39
• Amazon EKS v1.24.10-eks-48e63af
•RKE2 v1.27.1+rke2r1		 23.2.0.156

Questioni aperte

Informazioni sui problemi aperti in questa versione per CN2.

Itinerario generale

  • CN2-3429: quando il NAT di origine dell'infrastruttura è abilitato in uno spazio dei nomi isolato, il traffico scorre tra i pod negli spazi dei nomi isolati e tra i pod negli spazi dei nomi isolati e non isolati. Soluzione alternativa: non configurare il NAT di origine dell'infrastruttura su uno spazio dei nomi isolato.

Caratteristiche generali

  • CN2-3256: i carichi di lavoro cSRX con interfacce secondarie non sono compatibili con CN2.
  • CN2-6327: Quando il mirroring dell'interfaccia è abilitato con l'opzione juniperheader, viene eseguito il mirroring solo dei pacchetti in uscita.
    Soluzione alternativa: disabilitare l'opzione juniperheader per eseguire il mirroring dei pacchetti sia in uscita che in ingresso.
  • CN2-5916: quando 4 interfacce sono configurate in un'interfaccia bond su una scheda NIC X710, si verifica un leaf mbuf con calo del traffico.
    Soluzione alternativa: limitare due interfacce in una configurazione bond per una scheda NIC X710.
  • CN2-10346: Quando si riavvia un pod vRouter su nodi in modalità kernel in cui vhost0 è installato su interfacce bond, l'indirizzo IP bond viene assegnato a un'interfaccia secondaria bond anziché a un'interfaccia primaria bond.
    Eseguire il seguente script per la soluzione alternativa:
    Bond-patch.txt
    testo · 982 B
    #!/bin/bash
    imposta -x
    slave_list=($(ip addr show | grep SLAVE | awk ‘{ print $2 }’ | sed ‘s/://'))Cronologia delle revisioni per lo slave in “${slave_list[@]}”; Fare
    SE=$’ ‘
    bond=$(ip addr show dev ${slave} | grep SLAVE | awk -F'master ‘ '{print $2}' | awk -F'
    ‘ ‘{stampa $1}’)
    SE=$’\n’
    route_list=($(ip route show | grep ${slave}))
    per il percorso in "${route_list[@]}"; Fare
    echo "percorso: ${percorso}"
    new_route=$(echo ${route} | sed “s/${slave}/${bond}/g”)
    route_cmd=$(echo “ip route replace ${new_route}” | sed -e 's|[“'\”]||g')
    valutazione ${route_cmd}
    Fatto
    ipv4=$(ip addr show dev ${slave} | grep 'inet ' | awk '{ print $2 }')
    ipv6=$(indirizzo ip mostra dev ${slave} | grep 'inet6 ' | awk '{ print $2 }')
    echo “slave: ‘${slave}’, vincolo: ‘${bond}’, ipv4: ‘${ipv4}’, ipv6: ‘${ipv6}'”
    if [[ -n “$ipv4” ]]; Poi
    indirizzo ip del ${ipv4} dev ${slave}
    indirizzo ip aggiungi ${ipv4} dev ${bond}
    fi
    if [[ -n “$ipv6” ]]; Poi
    indirizzo ip del ${ipv6} dev ${slave}
    indirizzo ip aggiungi ${ipv6} dev ${bond}
    fi
  • CN2-13314: L'istanza del servizio gateway (GSI) non funziona con un ASN a 4 byte.
    Soluzione alternativa: utilizzare un ASN a 2 byte quando si connettono carichi di lavoro tramite il servizio GSI.

Red Hat OpenShift

Integrazione CN2 Apstra

  • CN2-13607: In una distribuzione CN2 Apstra, Apstra impiega diversi minuti per creare una rete virtuale in uno scenario in scala.

CN2 e Kubernetes

  • CN2-4508: La sottorete della rete virtuale Contrail creata tramite NAD non può avere un gateway definito dall'utente.

Soluzione alternativa: nessuna.

  • CN2-4822: Non è possibile configurare oggetti BGPaaS sui nodi che ospitano il controller Contrail e i nodi di lavoro sullo stesso host fisico.
    Soluzione alternativa: nessuna. Le distribuzioni di produzione eseguono i nodi di lavoro e il controller Kubernetes in diversi host fisici.
  • CN2-8728: quando distribuisci CN2 su istanze AWS EC2, eseguendo il traffico del servizio Kubernetes e
    Il traffico del percorso dati contrail su interfacce diverse non è supportato.
    Soluzione alternativa: non distribuire Kubernetes e il traffico dati sulla stessa interfaccia in AWS.
  • CN2-10351: KubeVirt v0.58.0 non supporta imagePullSecret, richiesto per estrarre immagini dal sistema sicuro registro: enterprise-hub.juniper.net/contrail-container-prod/.
    Seguire questi passaggi per la soluzione alternativa:
    1. Installa Docker.
    2. Creare un registro locale non sicuro.
    3. Riavviare la finestra mobile.
    4. Scarica i contenitori richiesti. I contenitori si trovano a Rilascio Userspace CNI - supporto dell'interfaccia dpdkvhostuser Juniper/kubevirT. Questi contenitori vengono archiviati come risorse.
    5. Caricare i contenitori.
    6. Tag ed eseguire il push dei contenitori nel nuovo registro non sicuro.
    7. Scarica operator.yaml e cr.yaml.
    8. Modifica kubevirt-operator.yaml per utilizzare il tuo registro non sicuro.
  • CN2-14895: I pod vengono distribuiti più della capacità VMI dei nodi.
    Quando uno strumento di pianificazione pod personalizzato è configurato con la capacità VMI massima come soglie, se i pod vengono pianificati uno dopo l'altro in rapida successione, è possibile che vengano distribuiti più pod rispetto alla soglia configurata. Ciò è dovuto al ritardo nella sincronizzazione dei dati tra il nodo e l'analisi.
    Soluzione alternativa: la pianificazione aggiuntiva dei pod sui nodi occupati verrà interrotta entro pochi secondi una volta sincronizzati i dati VMI tra i nodi e l'analisi.
  • CN2-15530: si osserva una perdita di pacchetti nella persistenza del flusso CN2 quando si passa da uno a più pod (da non ECMP a ECMP).
    Durante lo scale up la vischiosità del flusso è applicabile solo all'interno del gruppo ECMP. L'aumento da uno a più pod non mantiene la viscosità del flusso.
    Soluzione alternativa: iniziare con un minimo di 2 carichi di lavoro e aumentare la scalabilità.
  • CN2-15461: La sessione BFD non si avvia quando il controllo dello stato è associato a 2 oggetti BBGaaS.
    Soluzione alternativa: negli ambienti in cui BFD viene utilizzato con BBGaaS, se è configurata la policy del firewall, assicurarsi che le regole della policy consentano la porta 4784 (pacchetti BFD).

Sicurezza

  • CN2-4642: In CN2, la politica di rete utilizza il riservato tags applicazione e spazio dei nomi. Questi tags conflitto con le risorse riservate di Contrail.
    Soluzione alternativa: non utilizzare le etichette dell'applicazione e dello spazio dei nomi per identificare le risorse del pod e dello spazio dei nomi.
  • CN2-10012: Se la politica di rete ha una regola Nega tutto, rimuoverla aggiornando la politica non funziona.
    Soluzione alternativa: eliminare la policy e aggiungerla nuovamente.

Condotte CN2

  • CN2-15876: I test vengono attivati ​​quando files in una cartella diversa da quella specificata in YAML file directory sono impegnate. La cartella cn2networkconfig è specificata invalues.yaml come directory per commit e files sono test uniti che dovrebbero essere attivati. Argo CD supporta solo la sincronizzazione dal percorso specificato nel grafico Helm come parte dell'avvio della pipeline CN2.
    Soluzione alternativa: eseguire il commit solo nella directory cn2networkconfig.
  • CN2-16034: Gli oggetti CN2 creati automaticamente mettono Argo fuori sincronizzazione dopo il commit. La creazione di un NAD avvia il router virtuale e le sottoreti contrassegnate come non sincronizzate da Argo.
    Soluzione alternativa: aggiungere Resource.Exclusions: in charts/argocd/templates/argocd_sa.yaml Soluzione alternativa aggiunta al grafico Helm:
    APIVersione: v1
    tipo: ConfigMap
    metadati:
    spazio dei nomi: argocd
    etichette:
    app.kubernetes.io/name:argocd-cm
    app.kubernetes.io/part-of:argocd
    nome: argocd-cm
    dati:
    risorse.esclusioni: |
    – Gruppi API:
    – “*”
    tipi:
    – Rete virtuale
    gruppi:
    – “*”
    timeout.riconciliazione: 2s

Problemi risolti

È possibile ricercare le limitazioni risolte con questa versione all'indirizzo:
Problemi risolti nella versione 2 di CN23.2.
Utilizza le credenziali di accesso del supporto Juniper per view la lista. Se non disponi di un account Juniper Support, puoi registrarne uno Qui.

Richiesta di supporto tecnico

Il supporto tecnico per il prodotto è disponibile tramite il Centro di assistenza tecnica Juniper Networks (JTAC).
Se sei un cliente con un contratto di supporto Juniper Care o Partner Support Services attivo, o sei coperto da garanzia e hai bisogno di supporto tecnico post-vendita, puoi accedere ai nostri strumenti e risorse online o aprire un caso con JTAC.

Strumenti e risorse online di auto-aiuto
Per una risoluzione rapida e semplice dei problemi, Juniper Networks ha progettato un portale self-service online chiamato Customer Support Center (CSC) che fornisce le seguenti funzionalità:

Creazione di una richiesta di servizio con JTAC
È possibile creare una richiesta di servizio con JTAC su Web o per telefono.

Per le opzioni internazionali o di chiamata diretta nei paesi senza numeri verdi, vedere https://support.juniper.net/support/requesting-support/

Cronologia delle revisioni

  • 30 giugno 2023—Revisione 6
  • 30 marzo 2023—Revisione 5
  • 19 dicembre 2022—Revisione 4
  • 23 settembre 2022—Revisione 3
  • 22 giugno 2022—Revisione 2
  • 02 maggio 2022: revisione 1, versione iniziale

Juniper Networks, il logo Juniper Networks, Juniper e Junos sono marchi registrati di Juniper Networks, Inc. negli Stati Uniti e in altri paesi. Tutti gli altri marchi, marchi di servizio, marchi registrati o marchi di servizio registrati sono di proprietà dei rispettivi proprietari. Juniper Networks non si assume alcuna responsabilità per eventuali inesattezze presenti nel presente documento. Juniper Networks si riserva il diritto di cambiare, modificare, trasferire o altrimenti rivedere questa pubblicazione senza preavviso. Copyright © 2023 Juniper Networks, Inc. Tutti i diritti riservati.

Logo JUNIPER NETWORKS

Documenti / Risorse

Rete Contrail nativa del cloud CN2 di JUNIPER NETWORKS [pdf] Istruzioni
CN2 Rete di Contrail nativa del cloud, CN2, Rete di Contrail nativa del cloud, Rete di Contrail nativa, Rete di Contrail

Riferimenti

Lascia un commento

Il tuo indirizzo email non verrà pubblicato. I campi obbligatori sono contrassegnati *