Kubernetes: rileva e gestisci automaticamente le API deprecate

Man mano che le funzionalità di Kubernetes si evolvono, anche le API devono evolvere per supportare i cambiamenti. Esistono regole precise pensate per garantire compatibilità e stabilità¹. Non succede a ogni release, ma prima o poi si dovrà passare alla nuova versione e al nuovo formato delle API, perché quelli vecchi non saranno più supportati.

Alcune API deprecate sono state mantenute attive nelle ultime versioni di K8s e con la release 1.16 di Kubernetes vengono rimosse definitivamente. Nello specifico, i seguenti API Group e versioni:

• Deployment — extensions/v1beta1, apps/v1beta1 e apps/v1beta2
• NetworkPolicy — extensions/v1beta1
• PodSecurityPolicy — extensions/v1beta1
• DaemonSet — extensions/v1beta1 e apps/v1beta2
• StatefulSet — apps/v1beta1 e apps/v1beta2
• ReplicaSet — extensions/v1beta1, apps/v1beta1 e apps/v1beta2

Se prova a creare una risorsa usando una di queste versioni con la 1.16, l'operazione fallirà senza appello.

Può passare in rassegna manualmente tutti i suoi manifest, ma è un'operazione che porta via parecchio tempo. È facile lasciarsi sfuggire qualcosa e diventa decisamente poco pratico se ha più team che fanno deployment sul cluster, o se non dispone di tutti i manifest aggiornati in un unico posto. Ed è qui che entra in gioco Kube-No-Trouble, alias kubent.

L'informazione su quale versione delle API sia stata usata per creare una determinata risorsa di norma non è accessibile, perché la risorsa viene sempre convertita e archiviata internamente nella versione di storage preferita. Tuttavia, se utilizza kubectl o Helm per il deployment, il manifest originale viene conservato anche all'interno del cluster: è proprio questo che possiamo sfruttare².

Il modo più semplice per installarlo è:

sh -c "$(curl -sSL 'https://git.io/install-kubent')"

Questo comando installa l'ultima versione di kubent in /usr/local/bin ³.

Configuri il context corrente di kubectl puntandolo al cluster da analizzare ed esegua lo strumento kubent:

Fig. 1: Esempio di output di kubent

Kubent si collega al cluster, recupera tutte le risorse potenzialmente interessate, le analizza e mostra un riepilogo di quelle effettivamente coinvolte.

Può anche usare il flag -f json per ottenere l'output in formato JSON, più adatto se vuole integrarlo nella sua pipeline CI/CD o elaborare i risultati a valle. Tutti i dettagli sulle opzioni di configurazione disponibili sono nel README del repository doitintl/kube-no-trouble.

In alcuni casi basta modificare l'apiVersion nel manifest; in altri, invece, la struttura potrebbe essere cambiata e richiedere modifiche. Tenga inoltre presente che molti valori predefiniti sono cambiati tra una versione e l'altra⁴: cambiando solo l'apiVersion e applicando lo stesso manifest otterrebbe risultati diversi. Per esempio, updateStrategy.type di StatefulSet è passato da OnDelete a RollingUpdate, con un comportamento molto differente.

Il comando kubectl convert, un tempo molto usato, è ora deprecato e potrebbe non convertire correttamente le risorse rispetto ai valori predefiniti appena citati.

L'approccio probabilmente migliore è semplicemente applicare le risorse (operazione già fatta se le ha rilevate con kubent) e recuperare la nuova versione dalle API: in questo modo la risorsa viene trasformata correttamente nella nuova versione. Avrà notato che kubectl è un po' imprevedibile riguardo alla versione che restituisce. Per richiedere una versione specifica delle API, usi la forma estesa:

kubectl get ingress.v1beta1.extensions -o yaml

Ci auguriamo che tutto ciò la aiuti a individuare e gestire l'uso di API deprecate nei suoi cluster Kubernetes, prima che possano creare grattacapi.

Lo strumento kubent è ancora ai primi passi: ci farebbe molto piacere ricevere commenti, suggerimenti e sapere se lo trova utile. Buon vento! ⛵⛵⛵

• [1] Il documento Deprecation Policy di Kubernetes definisce le modalità con cui le diverse parti del sistema possono essere rese obsolete e poi rimosse.
• [2] Si trova sotto forma di annotazione kubectl.kubernetes.io/last-applied-configuration nel caso di kubectl, oppure come ConfigMap o Secret nel caso di Helm.
• [3] Se, come me, non si fida degli script casuali pubblicati sui blog, scarichi l' ultima release per la sua piattaforma e la estragga dove preferisce.
• [4] Un ottimo articolo sull'argomento è Kubernetes 1.16 API deprecations and changed defaults di David Schweikert.

Riferimenti aggiuntivi:

• Kube-No-Trouble — repository GitHub di kubent — https://github.com/doitintl/kube-no-trouble
• Deprecated APIs Removed In 1.16: Here's What You Need To Know, blog post di Vallery Lancey — https://kubernetes.io/blog/2019/07/18/api-deprecations-in-1-16/