Creating a cluster with kubeadm

General Discussions
1

Hello,

Im creating a cluster with kubeadm, during Initializing your control-plane node,

Containerd runtime,kubeadm,kubelet installed succcessfully

Im getting below error:

[root@controlplane-01 ~]# kubeadm init --apiserver-advertise-address 172.16.5.82 --pod-network-cidr “10.10.0.0/16” --upload-certs
I1013 15:27:34.065153 26173 version.go:261] remote version is much newer: v1.34.1; falling back to: stable-1.33
[init] Using Kubernetes version: v1.33.5
[preflight] Running pre-flight checks
[WARNING Firewalld]: firewalld is active, please ensure ports [6443 10250] are open or your cluster may not function correctly
[preflight] Pulling images required for setting up a Kubernetes cluster
[preflight] This might take a minute or two, depending on the speed of your internet connection
[preflight] You can also perform this action beforehand using ‘kubeadm config images pull’
W1013 15:27:35.820165 26173 checks.go:846] detected that the sandbox image “registry.k8s.io/pause:3.8” of the container runtime is inconsistent with that used by kubeadm.It is recommended to use “registry.k8s.io/pause:3.10” as the CRI sandbox image.
error execution phase preflight: [preflight] Some fatal errors occurred:
[ERROR ImagePull]: failed to pull image registry.k8s.io/kube-apiserver:v1.33.5: failed to pull image registry.k8s.io/kube-apiserver:v1.33.5: failed to pull and unpack image : failed to copy: httpReadSeeker: failed open: failed to do request: Get tls: failed to verify certificate: x509: certificate signed by unknown authority (possibly because of “x509: cannot verify signature: insecure algorithm SHA1-RSA (temporarily override with GODEBUG=x509sha1=1)” while trying to verify candidate authority certificate “FG101E4Q17000658”)

….

….

…

Im able to curl registry . k8s . io

[root@controlplane-01 ~]# curl -v https://registry.k8s.io

  • Trying 34.96.108.209:443…
  • Connected (34.96.108.209) port 443 (#0)
  • ALPN, offering h2
  • ALPN, offering http/1.1
  • CAfile: /etc/pki/tls/certs/ca-bundle.crt
  • TLSv1.0 (OUT), TLS header, Certificate Status (22):
  • TLSv1.3 (OUT), TLS handshake, Client hello (1):
  • TLSv1.2 (IN), TLS header, Certificate Status (22):
  • TLSv1.3 (IN), TLS handshake, Server hello (2):
  • TLSv1.2 (IN), TLS header, Finished (20):
  • TLSv1.2 (IN), TLS header, Unknown (23):
  • TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
  • TLSv1.3 (IN), TLS handshake, Certificate (11):
  • TLSv1.3 (IN), TLS handshake, CERT verify (15):
  • TLSv1.3 (IN), TLS handshake, Finished (20):
  • TLSv1.2 (OUT), TLS header, Finished (20):
  • TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
  • TLSv1.2 (OUT), TLS header, Unknown (23):
  • TLSv1.3 (OUT), TLS handshake, Finished (20):
  • SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
  • ALPN, server accepted to use h2
  • Server certificate:
  • start date: Aug 24 23:27:51 2025 GMT
  • expire date: Nov 23 00:23:46 2025 GMT
  • issuer: C=US; O=Google Trust Services; CN=WR3
  • SSL certificate verify ok.
  • Using HTTP2, server supports multi-use
  • Connection state changed (HTTP/2 confirmed)
  • Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
  • TLSv1.2 (OUT), TLS header, Unknown (23):
  • TLSv1.2 (OUT), TLS header, Unknown (23):
  • TLSv1.2 (OUT), TLS header, Unknown (23):
  • Using Stream ID: 1 (easy handle 0x561261068660)
  • TLSv1.2 (OUT), TLS header, Unknown (23):

GET / HTTP/2
Host:
user-agent: curl/7.76.1
accept: /

  • TLSv1.2 (IN), TLS header, Unknown (23):

  • TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):

  • TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):

  • old SSL session ID is stale, removing

  • TLSv1.2 (IN), TLS header, Unknown (23):

  • TLSv1.2 (OUT), TLS header, Unknown (23):

  • TLSv1.2 (IN), TLS header, Unknown (23):

  • TLSv1.2 (IN), TLS header, Unknown (23):
    < HTTP/2 307
    < content-type: text/html; charset=utf-8
    < location:
    < x-cloud-trace-context: 41e1478d394297db7fa67d43b9ced033
    < date: Mon, 13 Oct 2025 11:36:39 GMT
    < server: Google Frontend
    < content-length: 81
    < via: 1.1 google
    < alt-svc: h3=“:443”; ma=2592000,h3-29=“:443”; ma=2592000
    <

  • TLSv1.2 (IN), TLS header, Unknown (23):
    Temporary Redirect.

  • TLSv1.2 (IN), TLS header, Unknown (23):

  • TLSv1.2 (OUT), TLS header, Unknown (23):

  • Connection #0 to host left intact

Anyone faced this issue?

2

Hi there, could it be an outdated certificate store on your nodes? Is it possible that nodes are behind a proxy (transparent) ?