Perché la dismissione del registry k8s.gcr.io in virtù di registry.k8s.io è una buona notizia per gli utenti Kubernetes
Chi usa Kubernetes lo sa bene, il più famoso orchestratore di container del mondo è erogato esso stesso da dei container. Ora al netto di quanto faccia strano questa cosa…
Il punto è che nel frattempo molti altri player si sono offerti di erogare i container di Kubernetes, in primis Amazon, ed è inutile negare come lo sfruttamento di queste contribuzioni alternative a Google porterà benefici a tutti gli utilizzatori. Infatti la buona notizia è che la distribuzione geografica garantita dall’accoppiata Google/AWS consentirà di scaricare i contenuti da server più vicini, a maggior la velocità.
Ovviamente però è bene arrivare pronti al momento. Come ha annunciato Mahamed Ali in questo blog post sul blog di Kubernetes dal 3 aprile 2023 k8s.gcr.io verrà congelato, ossia non più alimentato con gli aggiornamenti, insomma, predisposto alla dismissione.
Fortunatamente esistono precise indicazioni in merito a come gestire questo passaggio, anche per via del fatto che il nuovo registry registry.k8s.io è attivo già dallo scorso novembre ed in futuro il suo utilizzo sarà l’unico disponibile.
In particolare la timeline relativa alle versioni di Kubernetes su k8s.gcr.io sarà la seguente:
k8s.gcr.iosarà congelato il 3 aprile 2023- Kubernetes 1.27 sarà rilasciato il 12 di aprile 2023 (e quindi non sarà in alcuna maniera sul vecchio repository)
- L’ultima release 1.23 di Kubernetes su
k8s.gcr.iosarà la 1.23 (1.23 sarà in ognu caso end-of-life prima del 3 aprile) - L’ultima release 1.24 di Kubernetes su
k8s.gcr.iosarà la 1.24.12 - L’ultima release 1.25 di Kubernetes su
k8s.gcr.iosarà la 1.25.8 - L’ultima release 1.26 di Kubernetes su
k8s.gcr.iosarà la 1.26.3
Quindi la prima cosa da fare per capire se si è impattati da questo cambiamento è interrogare i propri container e capire se qualcuno di questi dipende dal vecchio registry:
> kubectl get pods --all-namespaces -o jsonpath="{.items[*].spec.containers[*].image}" |\
tr -s '[[:space:]]' '\n' |\
sort |\
uniq -c
3 haproxy:2.1.4
1 kubernetesui/dashboard:v2.6.1
1 kubernetesui/metrics-scraper:v1.0.8
1 nginx:latest
3 osixia/keepalived:2.0.17
17 quay.io/cephcsi/cephcsi:canary
1 quay.io/jetstack/cert-manager-cainjector:v1.9.1
1 quay.io/jetstack/cert-manager-controller:v1.9.1
1 quay.io/jetstack/cert-manager-webhook:v1.9.1
1 quay.io/metallb/controller:v0.13.6
4 quay.io/metallb/speaker:v0.13.6
4 rancher/mirrored-flannelcni-flannel:v0.18.1
2 registry.k8s.io/coredns/coredns:v1.9.3
3 registry.k8s.io/etcd:3.5.6-0
1 registry.k8s.io/ingress-nginx/controller:v1.4.0@sha256:34ee929b111ffc7aa426ffd409af44da48e5a0eea1eb2207994d9e0c0882d143
2 registry.k8s.io/ingress-nginx/kube-webhook-certgen:v20220916-gd32f8c343@sha256:39c5b2e3310dc4264d638ad28d9d1d96c4cbb2b2dcfb52368fe4e3c63f61e10f
3 registry.k8s.io/kube-apiserver:v1.26.1
3 registry.k8s.io/kube-controller-manager:v1.26.1
4 registry.k8s.io/kube-proxy:v1.26.1
3 registry.k8s.io/kube-scheduler:v1.26.1
3 registry.k8s.io/sig-storage/csi-attacher:v4.0.0
4 registry.k8s.io/sig-storage/csi-node-driver-registrar:v2.5.1
3 registry.k8s.io/sig-storage/csi-provisioner:v3.3.0
3 registry.k8s.io/sig-storage/csi-resizer:v1.6.0
3 registry.k8s.io/sig-storage/csi-snapshotter:v6.1.0
In questo esempio non ci sono container relativi a k8s.gcr.io.
Altra verifica che si può fare è capire se nei manifest di configurazione delle macchine host di Kubernetes sono presenti immagini derivanti dal repository in dismissione, in questo modo:
[rasca@kubernetes-1 ~]$ sudo grep image: /etc/kubernetes/manifests/*
/etc/kubernetes/manifests/etcd.yaml: image: registry.k8s.io/etcd:3.5.6-0
/etc/kubernetes/manifests/haproxy.yaml: - image: haproxy:2.1.4
/etc/kubernetes/manifests/keepalived.yaml: - image: osixia/keepalived:2.0.17
/etc/kubernetes/manifests/kube-apiserver.yaml: image: registry.k8s.io/kube-apiserver:v1.26.1
/etc/kubernetes/manifests/kube-controller-manager.yaml: image: registry.k8s.io/kube-controller-manager:v1.26.1
/etc/kubernetes/manifests/kube-scheduler.yaml: image: registry.k8s.io/kube-scheduler:v1.26.1Ed anche in questo caso tutte le immagini delle componenti “core” sono scaricate da registry.k8s.io.
Com’è facile capire il nuovo registry è ormai lo standard per tutte le installazioni recenti, ma nel caso in cui si dovesse per qualsiasi ragione necessitare di utilizzare ancora k8s.gcr.io ci sono istruzioni in merito ben dettagliate, ben consci del fatto che si starà utilizzando una sorgente non aggiornata.
Raoul Scarazzini
Da sempre appassionato del mondo open-source e di Linux nel 2009 ho fondato il portale Mia Mamma Usa Linux! per condividere articoli, notizie ed in generale tutto quello che riguarda il mondo del pinguino, con particolare attenzione alle tematiche di interoperabilità, HA e cloud.
E, sì, mia mamma usa Linux dal 2009.
Se vuoi sostenerci, puoi farlo acquistando qualsiasi cosa dai diversi link di affiliazione che abbiamo nel nostro sito o partendo da qui oppure alcune di queste distribuzioni GNU/Linux che sono disponibili sul nostro negozio online, quelle mancanti possono essere comunque richieste, e su cui trovi anche PC, NAS e il ns ServerOne. Se ti senti generoso, puoi anche donarmi solo 1€ o più se vuoi con PayPal e aiutarmi a continuare a pubblicare più contenuti come questo. Grazie!
Hai dubbi o problemi? Ti aiutiamo noi!
Se vuoi rimanere sempre aggiornato, iscriviti al nostro canale Telegram.Se vuoi ricevere supporto per qualsiasi dubbio o problema, iscriviti alla nostra community Facebook o gruppo Telegram.
Cosa ne pensi? Fateci sapere i vostri pensieri nei commenti qui sotto.
Ti piace quello che leggi? Per favore condividilo con gli altri.
