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 fino ad oggi le immagini di questi container core sono state erogate in autonomia dal progetto stesso, tramite il registry k8s.gcr.io che, come suggerisce il nome (gcr, Google Cloud Registry), è proprietà di Google. Nel frattempo però, vista la crescita del progetto, 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.

Proprio con questo intento è stato creato registry.k8s.io, un registry indipendente, che dovrebbe facilitare le contribuzioni terze. Ed è qui la buona notizia: la distribuzione geografica garantita dall’accoppiata Google/AWS consentirà di scaricare i contenuti da server più vicini, a maggior la velocità.

Ma per far questo il registry k8s.gcr.io andrà prima dismesso, ed è 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.io sarà 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.io sarà 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.io sarà la 1.24.12
• L’ultima release 1.25 di Kubernetes su k8s.gcr.io sarà la 1.25.8
• L’ultima release 1.26 di Kubernetes su k8s.gcr.io sarà 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.1

Ed 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.