Problemi noti per Kubernetes Engine (OKE)

Le proprietà dei nuovi nodi di lavoro che iniziano in un pool di nodi non riflettono le modifiche più recenti alle proprietà del pool di nodi. La causa probabile è l'uso degli attributi quantityPerSubnet e subnetIds non più validi quando si utilizza l'operazione API UpdateNodePoolDetails per aggiornare le proprietà del pool di nodi.

Procedere in uno dei seguenti modi:

• Iniziare a utilizzare l'attributo nodeConfigDetails quando si utilizza l'operazione API UpdateNodePoolDetails. Innanzitutto, ridimensionare il pool di nodi su 0 utilizzando quantityPerSubnet. Quindi interrompere l'utilizzo degli attributi subnetIds e quantityPerSubnet e utilizzare l'attributo nodeConfigDetails.
• Contattare il Supporto Oracle per riavviare il componente backend responsabile della sincronizzazione (il componente tenant-agent).

Quando avvii il dashboard Kubernetes, in alcune situazioni potresti riscontrare messaggi di errore "net/http: TLS handshake timeout" e "reimpostazione della connessione da parte del peer" nel tuo browser Web. Questo problema è stato osservato solo nei cluster appena creati che eseguono Kubernetes versione 1.11. Per i dettagli su un problema Kubernetes correlato, vedere https://github.com/kubernetes/dashboard/issues/3038.

1. In una finestra del terminale, immettere:

   $ kubectl -n kube-system port-forward svc/kubernetes-dashboard 8443:443

2. Nel browser Web, andare a https://localhost:8443

Quando si utilizza un token Kubeconfig versione 2.0.0 per accedere alle versioni Helm/Tiller precedenti alla versione 2.11, si riceverà uno dei seguenti errori:

• Error: Unauthorized
• Error: could not get Kubernetes client: exec plugin: invalid apiVersion "client.authentication.k8s.io/v1beta1"

Aggiornare Helm/Tiller come indicato di seguito.

1. In una finestra di terminale, scaricare un token Kubeconfig versione 1.0.0 immettendo il comando seguente:

   $ oci ce cluster create-kubeconfig --token-version=1.0.0 --cluster-id=<cluster_ocid>

2. Identificare la chiave dell'area da utilizzare per specificare il registro di Oracle Cloud Infrastructure Registry nell'area del cluster (vedere Disponibilità per area). Ad esempio, se il cluster si trova nell'area orientale degli Stati Uniti (Ashburn), iad è la chiave dell'area da utilizzare per specificare il registro in tale area.

3. Aggiornare Tiller immettendo il seguente comando:

   $ helm init --upgrade -i <region-key>.ocir.io/odx-oke/oke-public/tiller:v2.14.3

   dove <region-key> è la chiave identificata nel passo precedente.

4. In un browser, accedere a https://helm.sh/docs/using_helm/#installing-the-helm-client e seguire le istruzioni per scaricare e installare il file binario del client Helm.

5. Dopo aver aggiornato Helm/Tiller, scaricare un token Kubeconfig versione 2.0.0 immettendo il comando seguente:

   $ oci ce cluster create-kubeconfig --token-version=2.0.0 --cluster-id=<cluster_ocid>

La release Kubernetes Engine 1.8.0 includeva un miglioramento della sicurezza per migliorare la forza di cifratura sul kubelet in esecuzione sui nodi di lavoro dei clienti. I nuovi nodi di lavoro creati tra il 20 agosto 2019 e il 16 settembre 2019 includono questa configurazione. Il nuovo set di cifrature non consente connessioni al kubelet tramite http/2. Questa limitazione influisce sul server delle metriche e anche sull'Autoscaler pod orizzontale che dipende dal server delle metriche.

Per ogni nodo di lavoro esistente, a sua volta:

1. Impedire ai nuovi pod di avviare ed eliminare i pod esistenti sul nodo di lavoro immettendo kubectl drain <node_name>. Ulteriori informazioni

   • informazioni sull'uso di kubectl, vedere Accesso a un cluster tramite Kubectl
   • informazioni sul comando di rimozione, vedere drain nella documentazione di Kubernetes

   Consigliato: sfrutta i budget di interruzione dei pod appropriati per la tua applicazione per garantire che durante l'operazione di rimozione sia in esecuzione un numero sufficiente di pod di replica.

2. Eliminare il nodo di lavoro, ad esempio terminandolo nella console.
3. Attendere l'avvio di un nodo di lavoro sostitutivo.

I nodi di lavoro sostitutivi includono nuove impostazioni per abilitare la comunicazione con il kubelet.

Quando un nuovo pod viene avviato su un nodo di lavoro in un cluster, in alcune situazioni il pod non riesce a eseguire il MOUNT di tutti i volumi collegati al nodo a causa di timeout e viene visualizzato un messaggio simile al seguente:

Unable to mount volumes for pod "<pod_name>(<pod_uid>)": timeout expired waiting for volumes to attach or mount for pod "<namespace>"/"<pod_name>". list of unmounted volumes=[<failed_volume>]. list of unattached volumes=[<… list of volumes >]

Una delle possibili cause identificate per questo problema è se la specifica pod include un campo fsGroup nel campo securityContext. Se il contenitore è in esecuzione su un nodo di lavoro come utente non root, l'impostazione del campo fsGroup nel file securityContext può causare timeout a causa del numero di file in cui Kubernetes deve apportare modifiche alla proprietà (vedere https://github.com/kubernetes/kubernetes/issues/67014).

Se la specifica pod non include un campo fsgroup nel file securityContext, la causa è sconosciuta.

Se la specifica pod include il campo fsgroup nel file securityContext e il contenitore sta eseguendo un utente non root, considerare le seguenti soluzioni:

• Rimuovere il campo fsgroup dal securityContext.
• Utilizzare il campo supplementalGroups nel file securityContext (anziché fsgroup) e impostare supplementalGroups sull'identificativo del volume.
• Modificare la specifica pod in modo che il contenitore venga eseguito come root.

Se la specifica pod non include il campo fsgroup nel file securityContext o se il contenitore è già in esecuzione come root, è necessario riavviare o sostituire il nodo di lavoro. Ad esempio, arrestando e avviando l'istanza, riavviando l'istanza o terminando l'istanza in modo che venga avviata una nuova istanza. Attenersi alle istruzioni riportate in Arresto, avvio o riavvio di un'istanza o Arresto di un'istanza in base alle esigenze per utilizzare la console o l'API. In alternativa, è possibile utilizzare i comandi CLI, ad esempio l'esempio riportato di seguito per terminare un'istanza.

$ INSTANCE_OCID=$(kubectl get node <name> -ojsonpath='{.spec.providerID}')
$ oci compute instance terminate --instance-id $INSTANCE_OCID

dove <name> è il nome del nodo di lavoro, derivato dalla proprietà Indirizzo IP privato dell'istanza (ad esempio, 10.0.10.5).

Quando si utilizza il servizio di gestione del sistema operativo per gestire gli aggiornamenti e le patch del sistema operativo sulle istanze di Oracle Cloud Infrastructure, si verificano alcune situazioni in cui i pool di nodi cluster creati da Kubernetes Engine non vengono messi in linea.

Sono possibili due soluzioni:

• Soluzione 1: se si desidera utilizzare la gestione del sistema operativo per gestire le istanze di Oracle Cloud Infrastructure, abilitare Oracle Enterprise Linux nella gestione del sistema operativo. Vedere Gestione delle origini software.
• Soluzione 2: se non si desidera utilizzare Gestione del sistema operativo per gestire le istanze di Oracle Cloud Infrastructure, assicurarsi che non vi siano criteri che consentano l'esecuzione di Gestione del sistema operativo. In particolare, rimuovere il criterio che concede a un gruppo dinamico di istanze l'accesso al servizio di gestione del sistema operativo. Vedere Impostazione dei criteri per la gestione del sistema operativo.

/ # nslookup www.oracle.com
;; reply from unexpected source: 10.244.0.167#53, expected 10.96.5.5#53
;; reply from unexpected source: 10.244.0.167#53, expected 10.96.5.5#53
;; reply from unexpected source: 10.244.0.167#53, expected 10.96.5.5#53
;; connection timed out; no servers could be reached 

Per verificare questo problema, aprire una finestra del terminale sull'istanza ed eseguire il comando seguente:

sudo /usr/sbin/lsmod | grep br_netfilter 

Se non vengono restituiti risultati, il modulo kernel Bridge Netfilter non viene abilitato. Il modulo kernel Bridge Netfilter è necessario per mascherare il traffico VxLAN per i pod Kubernetes.

Abilitare il modulo kernel Bridge Netfilter. Aprire una finestra del terminale sull'istanza ed eseguire i comandi riportati di seguito.

sudo modprobe br_netfilter 
sudo sh -c 'echo "br_netfilter" > /etc/modules-load.d/br_netfilter.conf'

Quando si utilizza il networking pod nativo VCN, l'indirizzo IP del client di origine delle richieste in entrata a un pod potrebbe non essere conservato come previsto. Al contrario, le richieste in entrata ricevute tramite un servizio Kubernetes di tipo LoadBalancer con externalTrafficPolicy: Local impostato nel file manifest potrebbero essere visualizzate come provenienti dall'indirizzo IP del nodo di lavoro.

Per le richieste TCP in entrata ricevute tramite un servizio Kubernetes di tipo LoadBalancer con l'annotazione oci.oraclecloud.com/load-balancer-type: "lb" nel file manifesto, ottenere l'indirizzo IP del client di origine dall'intestazione X-Forwarded-For o X-Real-IP.

Quando si utilizza il networking pod nativo VCN, i pod potrebbero non essere in grado di comunicare sulla rete se è stata specificata una forma Bare Metal per i nodi di lavoro in uno o più pool di nodi nel cluster.

Specificare una forma VM per i nodi di lavoro in ogni pool di nodi del cluster quando si utilizza la rete pod nativa VCN.

Quando si utilizza il networking pod nativo VCN, il numero massimo di pod per nodo di lavoro in un pool di nodi potrebbe essere limitato a 31, indipendentemente dal numero di OCPU specificate per la forma flessibile selezionata per il pool di nodi.

Se si desidera più di 31 pod per nodo di lavoro in un pool di nodi, selezionare una forma diversa per i nodi di lavoro nel pool di nodi.

Quando si utilizza il networking pod nativo VCN, i pod in esecuzione sui nodi di lavoro connessi a una subnet pod con un blocco CIDR esterno al primo blocco CIDR specificato per la VCN potrebbero non essere in grado di comunicare con i servizi Kubernetes.

Crea subnet pod con blocchi CIDR all'interno del primo blocco CIDR specificato per la VCN.

Quando si utilizza lo script Node Doctor per risolvere i problemi dei nodi, lo script potrebbe visualizzare un messaggio di errore di eccezione simile al seguente:

FileNotFoundError: [Errno 2] No such file or directory: '/home/opc/vendor/pip…

Lo script Node Doctor probabilmente continuerà a essere eseguito e, dopo aver visualizzato il messaggio Generating node doctor bundle, genera un output di risoluzione dei problemi.

Il problema è in fase di verifica e risoluzione. Nel frattempo, se lo script Node Doctor visualizza il messaggio Generating node doctor bundle, l'output della risoluzione dei problemi è ancora valido.

Se non si desidera che lo script Node Doctor visualizzi il messaggio di errore di eccezione FileNotFoundError: [Errno 2]..., aggiornare lo script Node Doctor immettendo:

node-doctor.sh --update

Per ulteriori informazioni sullo script Node Doctor e su come aggiornarlo, vedere Risoluzione dei problemi relativi ai nodi per i cluster Kubernetes mediante lo script Node Doctor.

Se un cluster utilizza il networking pod nativo VCN e dispone sia di un pod del carico di lavoro che di un pod CoreDNS in esecuzione sullo stesso nodo di lavoro, la risoluzione DNS a volte non riesce perché il traffico non è corretto NATed.

Su 2023-03-21 è stato rilasciato un aggiornamento al plugin CNI di networking pod nativo VCN OCI che ha risolto questo problema. Seguire le istruzioni riportate nella sezione Aggiornamento del plugin CNI Networking pod VCN nativo OCI per distribuire l'aggiornamento.

Se un cluster utilizza il networking pod nativo VCN e dispone di nodi di lavoro su cui è in esecuzione Oracle Linux 8 (OL8), i pod talvolta non vengono avviati su uno dei nodi di lavoro. Il problema presenta le seguenti caratteristiche:

• Il nodo di lavoro sta eseguendo un'immagine OL8.
• I pod correlati alla rete host vengono eseguiti come previsto sul nodo di lavoro, ma tutti gli altri pod non vengono avviati.
• I log Crictl contengono il messaggio Adding address to IPVLAN parent device (che indica che un indirizzo IP viene collegato alla VNIC secondaria del nodo di lavoro), seguito dal messaggio di errore Error adding secondary VNIC IP.
• L'esecuzione del comando ip address di Linux sul nodo di lavoro indica che una o più VNIC secondarie non dispongono di un indirizzo IP collegato.
• Tutti (o la maggior parte) altri nodi di lavoro funzionano come previsto.

Una probabile causa identificata per questo problema è correlata a NetworkManager, che gestisce i dispositivi di rete e le connessioni. In alcuni casi, NetworkManager scollega l'indirizzo IP collegato a una o più VNIC secondarie del nodo di lavoro, causando l'errore del plugin CNI di networking pod VCN nativo OCI.

Su 2023-03-21 è stato rilasciato un aggiornamento al plugin CNI di networking pod nativo VCN OCI che ha risolto questo problema. Seguire le istruzioni riportate nella sezione Aggiornamento del plugin CNI Networking pod VCN nativo OCI per distribuire l'aggiornamento.

Se hai specificato Oracle Linux 8.7 o Oracle Linux 8.8 per un pool di nodi (selezionando un'immagine della piattaforma Oracle Linux 8.7 o Oracle Linux 8.8 o un'immagine del nodo di lavoro OKE creata sopra Oracle Linux 8.7 o Oracle Linux 8.8), lo stato dei nodi di lavoro del pool di nodi potrebbe cambiare in modo imprevisto in NotReady. Il problema presenta le seguenti caratteristiche:

• I nodi di lavoro eseguono Oracle Linux 8.7 o Oracle Linux 8.8.
• I nodi di lavoro eseguono Kubernetes versione 1.24.1, 1.25.4 o 1.26.2. (I nodi di lavoro che eseguono Kubernetes versione 1.25.12, 1.26.7 e 1.27 non sono interessati.)
• I pod di breve durata vengono spesso distribuiti sui nodi di lavoro.
• Anche i pod distribuiti sui nodi di lavoro nel pool di nodi potrebbero rimanere nello stato ContainerCreating per un periodo di tempo più lungo del previsto.

Il problema è in fase di verifica e risoluzione.

Nel frattempo, se si verifica questo problema, utilizzare una delle seguenti soluzioni alternative più adatte alle proprie esigenze:

• Specificare un'immagine Oracle Linux 7 per il pool di nodi.
• Specificare un'immagine Oracle Linux 8.6 (o un'immagine Oracle Linux 8 precedente) per il pool di nodi.
• Specificare una versione successiva di Kubernetes per il pool di nodi. (I nodi di lavoro che eseguono Kubernetes versione 1.25.12, 1.26.7 e 1.27 non sono interessati.)

Per ottenere gli OCID delle immagini che non vengono più visualizzate nella console, effettuare le operazioni riportate di seguito.

• Immagini della piattaforma: Visualizza tutte le immagini Oracle Linux 7.x e tutte le immagini Oracle Linux 8.x
• Immagini dei nodi di lavoro OKE: vedere Tutte le immagini Oracle Linux 7.x dei nodi di lavoro OKE e Tutte le immagini Oracle Linux 8.x dei nodi di lavoro OKE

Nei cluster creati prima del 26 giugno 2023 che utilizzano il networking pod nativo VCN, potrebbe verificarsi un ritardo nel provisioning dei nuovi nodi di lavoro.

Quando si esegue il bootstrap dei nodi di lavoro con il plugin CNI di networking pod nativo VCN OCI, Kubernetes Engine distribuisce una risorsa personalizzata Kubernetes (la risorsa NativePodNetwork o NPN) su ogni istanza di computazione. Quando viene eseguito correttamente il bootstrap di un nodo di lavoro, il motore Kubernetes fornisce lo stato SUCCESS alla risorsa NPN associata all'istanza di computazione.

In alcuni casi, se un'istanza di computazione viene arrestata prima che Kubernetes Engine dia lo stato SUCCESS alla risorsa NPN associata, la risorsa NPN rimane in stato BACKOFF o IN_PROGRESS a tempo indeterminato. L'esistenza di tali risorse 'stale' può ritardare il provisioning di nuovi nodi di lavoro.

Il problema viene risolto nei cluster creati dopo 2023-06-26. Per risolvere il problema nei cluster creati prima di 2023-06-26, eseguire un'azione una tantum per eliminare le risorse non più valide seguendo le istruzioni riportate in questa sezione.

Prima di iniziare, assicurarsi che il sistema soddisfi i prerequisiti riportati di seguito.

• l'interfaccia CLI OCI è installata (vedere Installazione dell'interfaccia CLI)
• l'interfaccia CLI OCI è configurata (vedere Configurazione dell'interfaccia CLI)
• jq è stato scaricato e installato (vedere https://jqlang.github.io/jq/download/)
• esiste un criterio IAM che concede almeno l'autorizzazione INSTANCE_READ, ad esempio Allow group <group-name> to manage instance-family in <location> (vedere Crea criterio richiesto per i gruppi)
• i file kubeconfig appropriati sono accessibili per consentire di utilizzare kubectl per gestire i cluster che utilizzano il plugin CNI di networking pod VCN nativo OCI (vedere Accesso a un cluster mediante Kubectl)

Identificare ed eliminare le risorse non più valide come indicato di seguito.

1. Verificare che il sistema soddisfi tutti i prerequisiti riportati di seguito.
   1. Salvare lo script seguente in un file denominato pre-req-check.sh:

      #!/bin/bash
      echo Validating cluster access to get npn resources
      ACTIVE_RESOURCES=($(kubectl get npn -o json | jq '[.items[] | select(.status.state == "SUCCESS")]' | jq -r '.[] | .metadata.name'))
      if [[ -z "$ACTIVE_RESOURCES" ]] || [ ${#ACTIVE_RESOURCES[@]} == 0 ]
      then
        echo No active NPN resources found. Make sure you have cluster access and this is an OCI VCN-Native CNI cluster. '\'nPlease check prerequisites and retry.
        exit
      fi
       
      cr_name=${ACTIVE_RESOURCES[0]}
      echo Validating access to get compute instance
      INSTANCE_ID=$(kubectl get npn $cr_name -o json | jq -r '. | .spec.id')
      INSTANCE_STATE=$(oci compute instance get --instance-id $INSTANCE_ID | jq -r '. | .data."lifecycle-state"')
       
      if [[ -z "$INSTANCE_STATE" ]]
      then
        echo Unable to get instance details, please check prerequisites and retry.
      else
        echo All prerequisites in place, please proceed to cleaning up stale resources.
      fi

   2. Eseguire lo script pre-req-check.sh immettendo:

      sh pre-req-check.sh

2. Identificare le risorse NPN che sono possibili candidati per l'eliminazione perché non hanno lo stato SUCCESSO:
   1. Eseguire l'output di una lista di risorse NPN che non hanno lo stato SUCCESS in un file di testo denominato potential_stale_resources.txt immettendo:

      kubectl get npn -o json | jq '[.items[] | select(.status.state != "SUCCESS")]' | jq -r '.[] | .metadata.name' >> potential_stale_resources.txt

   2. Facoltativamente, visualizzare l'elenco delle risorse NPN candidate in potential_stale_resources.txt immettendo:

      cat potential_stale_resources.txt

      Ad esempio, potential_stale_resources.txt può contenere:

      anyhqljth4...trq
      anyhqljth4...snq
      anyhqljth4...qhq

3. Identificare le risorse NPN non più valide da eliminare determinando quali risorse NPN candidate sono associate a istanze di computazione non disponibili o arrestate:
   1. Salvare lo script seguente in un file denominato get_stale_resources.sh:

      #!/bin/bash
      resources=$1
      echo Reading resources from $1
      while read  -r cr_name
      do
        echo verifying NPN resource $cr_name
        INSTANCE_ID=$(kubectl get npn $cr_name -o json | jq -r '. | .spec.id')
        if [  -z $INSTANCE_ID ]
        then
          echo Unable to get npn resource details. Please check prerequisites and retry from step 2.
          exit
        fi
        echo Associated instance is $INSTANCE_ID
        INSTANCE_STATE=$(oci compute instance get --instance-id $INSTANCE_ID | jq -r '. | .data."lifecycle-state"')
        if [  -z $INSTANCE_STATE ]
        then
          # check for 404 for tombstoned instances
          STATUS=$(oci compute instance get --instance-id $INSTANCE_ID 2>&1 | tail -n +2 | jq .status)
          if [ $STATUS == 404 ]
          then
            echo 404 getting instance $INSTANCE_ID, Instance has been tombstoned. Adding resource $cr_name to stale_resources.txt '\'n
            echo $cr_name >> stale_resources.txt
          fi
        else
          echo Instance $INSTANCE_ID in $INSTANCE_STATE state
          if [ $INSTANCE_STATE == "TERMINATED" ]
          then
            echo Adding resource $cr_name to stale_resources.txt '\'n
            echo $cr_name >> stale_resources.txt
          else
            echo Instance $INSTANCE_ID not terminated. '\'nSkipping resource $cr_name '\'n
          fi
        fi
      done < $1

   2. Eseguire lo script get_stale_resources.sh immettendo:

      sh get_stale_resources.sh potential_stale_resources.txt

      Lo script get_stale_resources.sh identifica le risorse NPN non più valide da eliminare, restituisce i messaggi sullo schermo e scrive i nomi delle risorse NPN non più valide in un file denominato stale_resources.txt. Ad esempio:

      Reading resources from potential_stale_resources.txt
      verifying NPN resource anyhqljth4...trq
      Associated instance is ocid1.instance.oc1.phx.anyhqljth4...trq
      Instance ocid1.instance.oc1.phx.anyhqljth4...trq in RUNNING state
      Instance ocid1.instance.oc1.phx.anyhqljth4...trq not terminated.
      Skipping resource anyhqljth4...trq
       
      verifying NPN resource anyhqljth4...snq
      Associated instance is ocid1.instance.oc1.phx.anyhqljth4...snq
      Instance ocid1.instance.oc1.phx.anyhqljth4...snq in TERMINATED state
      Adding resource anyhqljth4...snq to stale_resources
       
      verifying NPN resource anyhqljth4...qhq
      Associated instance is ocid1.instance.oc1.phx.anyhqljth4...qhq
      ServiceError:
      {
          "client_version": "Oracle-PythonSDK/2.104.2, Oracle-PythonCLI/3.29.0",
          "code": "NotAuthorizedOrNotFound",
          "logging_tips": "Please run the OCI CLI command using --debug flag to find more debug information.",
          "message": "instance ocid1.instance.oc1.phx.anyhqljth4...qhq not found",
          "opc-request-id": "CCB8D1925...38ECB8",
          "operation_name": "get_instance",
          "request_endpoint": "GET https://iaas.us-phoenix-1.oraclecloud.com/20160918/instances/ocid1.instance.oc1.phx.anyhqljth4...qhq",
          "status": 404,
          "target_service": "compute",
          "timestamp": "2023-06-27T20:24:28.992241+00:00",
          "troubleshooting_tips": "See [https://docs.oracle.com/iaas/Content/API/References/apierrors.htm] for more information about resolving this error. If you are unable to resolve this issue, run this CLI command with --debug option and contact Oracle support and provide them the full error message."
      }
      404 getting instance ocid1.instance.oc1.phx.anyhqljth4...qhq, Instance has been tombstoned
      Adding resource anyhqljth4...qhq to stale_resources

   3. Facoltativamente, visualizzare la lista delle risorse NPN non più valide in stale_resources.txt immettendo:

      cat stale_resources.txt

      Ad esempio, stale_resources.txt può contenere:

      anyhqljth4...snq
      anyhqljth4...qhq

4. Eliminare le risorse NPN non più valide elencate nel file stale_resources.txt:
   1. Salvare lo script seguente in un file denominato delete_stale_resources.sh:

      #!/bin/bash
      resources=$1
      echo Reading resources from $1
      while read -r cr_name
      do
          echo Deleting $cr_name
          kubectl delete npn $cr_name
      done < $1

   2. Eseguire lo script delete_stale_resources.sh immettendo:

      sh delete_stale_resources.sh stale_resources.txt

      Lo script delete_stale_resources.sh elimina le risorse NPN non più valide elencate nel file stale_resources.txt e restituisce i messaggi di elaborazione sullo schermo. Ad esempio:

      Reading resources from stale_resources.txt
      Deleting anyhqljth4...snq
      nativepodnetwork.oci.oraclecloud.com "anyhqljth4...snq" deleted

5. Come buona prassi, eliminare i file stale_resources.txt e potential_stale_resources.txt creati in precedenza.

Quando si specifica una forma Arm per un nodo virtuale, i pod pianificati sul nodo vengono eseguiti sui processori Arm come previsto. Tuttavia, se si esamina il nodo virtuale utilizzando il comando kubectl describe node o l'API Kubernetes, la proprietà Architecture del nodo indica AMD64, anche se i pod pianificati sul nodo vengono eseguiti sui processori Arm.

Il problema è in fase di verifica e risoluzione.

Nel frattempo, se si verifica questo problema, ignorare il valore della proprietà Architecture del nodo virtuale.

Quando Kubernetes Engine esegue il provisioning di un load balancer OCI per un servizio Kubernetes di tipo LoadBalancer, il load balancer non dispone della protezione di eliminazione abilitata.

Se in seguito si utilizza la console, l'interfaccia CLI o l'interfaccia API per abilitare la protezione di eliminazione per il load balancer, al Cloud-controller-manager non solo viene impedito di eliminare il load balancer, ma non è anche possibile aggiornare le proprietà del load balancer.

Il problema è in fase di verifica e risoluzione.

Nel frattempo, non utilizzare la console, l'interfaccia CLI o l'interfaccia API per abilitare la protezione di eliminazione per un load balancer.

Tenere presente che l'uso della console, dell'interfaccia CLI o dell'interfaccia API per modificare i load balancer OCI di cui è stato eseguito il provisioning da Kubernetes Engine non è consigliato (per ulteriori informazioni, vedere Definizione dei servizi Kubernetes di tipo LoadBalancer).

Le nuove versioni del plugin CNI di networking pod VCN nativo OCI vengono in genere rilasciate nei realm OC1, OC2 e OC3.

Tuttavia, il 3 settembre 2024 il plugin CNI di networking pod VCN nativo OCI versione 2.2.0, contenente miglioramenti a livello di sicurezza e prestazioni, è stato rilasciato solo nel realm OC1.

Il 4 ottobre 2024, il plugin CNI di networking pod VCN nativo OCI versione 2.2.2 è stato rilasciato nei realm OC1, OC2 e OC3, contenenti ulteriori miglioramenti.

Pertanto, tra il 3 settembre 2024 e il 4 ottobre 2024:

• I nuovi cluster creati nei realm OC2 e OC3 hanno utilizzato la versione precedente del plugin CNI di networking pod VCN nativo OCI, vale a dire la versione 2.1.0.
• Nel caso di cluster esistenti nei realm OC2 e OC3, anche se si era specificato che si desiderava che Oracle distribuisse automaticamente gli aggiornamenti al plugin CNI di networking pod VCN nativo OCI su un cluster, la versione 2.2.0 non era stata distribuita su tali cluster.

Indipendentemente dal fatto che tu o Oracle siate responsabili della distribuzione degli aggiornamenti al plugin CNI Pod Networking VCN nativo OCI, gli aggiornamenti vengono applicati solo al successivo riavvio dei nodi di lavoro.

Di conseguenza, nei realm OC2 e OC3 potrebbero essere presenti cluster in cui è ancora in esecuzione il plugin CNI di networking pod nativo VCN OCI versione 2.1.0.

Per usufruire dei miglioramenti apportati ai plugin CNI di networking pod nativo VCN OCI versioni 2.2.0 e 2.2.2, si consiglia di aggiornare qualsiasi cluster in OC2 o OC3 per utilizzare la versione 2.2.2.

Il plugin CNI di networking pod VCN nativo OCI versione 2.2.0 non verrà rilasciato nei realm OC2 e OC3, anche se è possibile selezionare la versione 2.2.0 nella console.

Se si abilita il plugin CNI di networking pod VCN nativo OCI per un cluster avanzato nel realm OC2 o OC3 e si specifica che si desidera scegliere la versione del componente aggiuntivo da distribuire, non selezionare la versione 2.2.0. Selezionare invece la versione 2.2.2 (o successiva). Se si seleziona la versione 2.2.0 per un cluster avanzato nei realm OC2 e OC3, tenere presente che i nodi di lavoro non verranno creati e il cluster non funzionerà.

Per ulteriori informazioni, vedere Uso del plugin CNI di networking pod VCN nativo OCI per il networking pod.

Quando si utilizza un cluster Kubernetes creato da Kubernetes Engine, è possibile che si verifichino ritardi imprevisti quando il cluster interagisce con il server API Kubernetes (ad esempio risposte lente ai comandi kubectl).

Se si utilizza un computer client con una versione precedente dell'interfaccia CLI OCI e/o Python installata, questi picchi intermittenti di latenza kube-apiserver potrebbero essere dovuti a un problema noto di prestazioni dell'interfaccia CLI OCI. Questo problema di prestazioni è stato osservato con Python versione 3.6 in particolare.

Per impostazione predefinita, il file kubeconfig creato da Kubernetes Engine per un cluster contiene un comando CLI OCI per generare un token (il comando OCI ce cluster generate-token). Il token viene utilizzato per autenticare le richieste al kube-apiserver. Al momento, ogni richiesta kube-apiserver attiva un richiamo dell'interfaccia CLI OCI per eseguire il comando per generare il token. È questo richiamo dell'interfaccia CLI OCI che potrebbe essere interessato dal problema noto relativo alle prestazioni dell'interfaccia CLI OCI.

Per confermare che la latenza di kube-apiserver è causata dal problema noto di prestazioni dell'interfaccia CLI OCI, individuare e visualizzare il file kubeconfig utilizzato dal client. Nella sezione users del file kubeconfig, individuare l'utente associato al cluster in questione. Supponendo che non siano state apportate modifiche al file kubeconfig per utilizzare un account di servizio (vedere Aggiunta di un token di autenticazione account di servizio a un file Kubeconfig), la sezione user contiene il comando di generazione del token CLI OCI nel seguente formato YAML:

- name: <user-name>
  user:
    exec:
      apiVersion: client.authentication.k8s.io/v1beta1
      args:
      - ce
      - cluster
      - generate-token
      - --cluster-id
      - <your-cluster-ocid>
      - --region
      - <your-region>
      command: oci
      env: []

Per confermare che la latenza kube-apiserver è causata dal problema di prestazioni noto, utilizzare il comando seguente per restituire il tempo impiegato dall'interfaccia CLI OCI per eseguire il comando di generazione del token:

time oci ce cluster generate-token --cluster-id <your-cluster-ocid> --region <your-region>

Se il tempo impiegato per eseguire il comando è vicino alla latenza kube-apiserver osservata, è possibile che si verifichi il problema di prestazioni noto.

Assicurarsi di utilizzare la versione stabile più recente dell'interfaccia CLI OCI, insieme a una versione supportata di Python (vedere Installazione manuale nella documentazione dell'interfaccia CLI OCI).

Se si utilizza Python versione 3.6, si consiglia di eseguire l'aggiornamento a una versione Python più recente.

Se non è possibile eseguire l'aggiornamento a una versione Python più recente, disabilitare l'importazione di tutti i servizi (il funzionamento predefinito) e importare in modo selettivo solo i singoli servizi e moduli necessari. È noto che l'importazione selettiva dei servizi migliora le prestazioni di Python versione 3.6. Per ulteriori informazioni, vedere Abilita importazioni di servizi selettivi per Python 3.6.

Quando si esegue l'upgrade di un pool di nodi esistente a Kubernetes versione 1.33.1 in un cluster creato utilizzando Kubernetes Engine, è possibile che i carichi di lavoro eseguiti in precedenza ora riscontrino problemi e restituiscano messaggi di errore come Too many open files.

Una possibile causa è che nei pool di nodi che eseguono Kubernetes versione 1.33.1, il limite relativo predefinito per i file aperti (ulimit nofile) all'interno dei container è stato ridotto a 1024. I carichi di lavoro dipendenti implicitamente da un limite predefinito precedentemente più elevato potrebbero pertanto riscontrare problemi.

Il limite relativo predefinito per i file aperti (ulimit nofile) all'interno dei container è stato ridotto a 1024 a causa di una modifica nel runtime dei container CRI-O. Kubernetes versione 1.33.1 utilizza CRI-O versione 1.33. In CRI-O versione 1.33, il parametro LimitNOFILE non è più impostato in modo esplicito nel file di servizio systemd CRI-O. Di conseguenza, il limite relativo predefinito di sistema (in genere 1024) ora si applica ai file aperti all'interno dei container. Per ulteriori informazioni, vedere https://github.com/cri-o/cri-o/pull/8962.

Il problema è in fase di test e risoluzione al lavoro. Nel frattempo, ci sono due possibili soluzioni:

• Soluzione 1: creare uno script di inizializzazione cloud personalizzato per aumentare ulimit nofile. Ad esempio:

  #!/bin/bash
  mkdir -p /etc/crio/crio.conf.d
  echo "[crio]" > /etc/crio/crio.conf.d/11-default.conf
  echo "  [crio.runtime]" >> /etc/crio/crio.conf.d/11-default.conf
  echo "    default_ulimits=[\"nofile=262144:262144\"]" >> /etc/crio/crio.conf.d/11-default.conf
  curl --fail -H "Authorization: Bearer Oracle" -L0 http://169.254.169.254/opc/v2/instance/metadata/oke_init_script | base64 --decode >/var/run/oke-init.sh
  sudo bash /var/run/oke-init.sh

  Si noti che nofile=262144:262144 è un esempio. Impostare nofile su un valore appropriato per il carico di lavoro. Per ulteriori informazioni sulla creazione di script di inizializzazione cloud personalizzati, vedere Uso di script di inizializzazione personalizzati di inizializzazione Cloud-init per l'impostazione dei nodi gestiti.

• Soluzione 2: eseguire temporaneamente il downgrade della versione di Kubernetes in esecuzione nel pool di nodi a Kubernetes versione 1.32, fino a quando non sarà disponibile una risoluzione permanente.