This message was deleted.

Just as a follow-up. These are the labels and annotations on the node:

Labels:             <http://beta.kubernetes.io/arch=amd64|beta.kubernetes.io/arch=amd64>
                    <http://beta.kubernetes.io/instance-type=k3s|beta.kubernetes.io/instance-type=k3s>
                    <http://beta.kubernetes.io/os=linux|beta.kubernetes.io/os=linux>
                    <http://kubernetes.io/arch=amd64|kubernetes.io/arch=amd64>
                    <http://kubernetes.io/hostname=phchbs-st32018|kubernetes.io/hostname=phchbs-st32018>
                    <http://kubernetes.io/os=linux|kubernetes.io/os=linux>
                    <http://node-role.kubernetes.io/control-plane=true|node-role.kubernetes.io/control-plane=true>
                    <http://node-role.kubernetes.io/master=true|node-role.kubernetes.io/master=true>
                    <http://node.kubernetes.io/instance-type=k3s|node.kubernetes.io/instance-type=k3s>
Annotations:        <http://alpha.kubernetes.io/provided-node-ip|alpha.kubernetes.io/provided-node-ip>: <MY-IPV4>
                    <http://csi.volume.kubernetes.io/nodeid|csi.volume.kubernetes.io/nodeid>: {"<http://driver.longhorn.io|driver.longhorn.io>":"phchbs-st32018"}
                    <http://flannel.alpha.coreos.com/backend-data|flannel.alpha.coreos.com/backend-data>: {"VNI":1,"VtepMAC":"7e:65:80:f9:9f:cb"}
                    <http://flannel.alpha.coreos.com/backend-type|flannel.alpha.coreos.com/backend-type>: vxlan
                    <http://flannel.alpha.coreos.com/kube-subnet-manager|flannel.alpha.coreos.com/kube-subnet-manager>: true
                    <http://flannel.alpha.coreos.com/public-ip|flannel.alpha.coreos.com/public-ip>: <MY-IPV4>
                    <http://k3s.io/hostname|k3s.io/hostname>: phchbs-st32018
                    <http://k3s.io/internal-ip|k3s.io/internal-ip>: <MY-IPV4>
                    <http://k3s.io/node-args|k3s.io/node-args>:
                      ["server","--disable","traefik","--flannel-iface","ens160","--data-dir","/opt/k3s","--prefer-bundled-bin","--resolv-conf","/etc...
                    <http://k3s.io/node-config-hash|k3s.io/node-config-hash>: VWJ7GMRNIEVMZ5NDM7NJVQP7REBOJBVASIV4F273RFU4UY3GQXIA====
                    <http://k3s.io/node-env|k3s.io/node-env>:
                      {"K3S_DATA_DIR":"/opt/k3s/data/3fcd4fcf3ae2ba4d577d4ee08ad7092538cd7a7f0da701efa2a8807d44a25f66","K3S_KUBECONFIG_MODE":"644"}
                    <http://node.alpha.kubernetes.io/ttl|node.alpha.kubernetes.io/ttl>: 0
                    <http://volumes.kubernetes.io/controller-managed-attach-detach|volumes.kubernetes.io/controller-managed-attach-detach>: true

Did you upgrade directly from 1.26 to 1.29, or did you step through 1.27 and 1.28 first?

I upgraded directly from 1.26 to 1.29. To upgrade I usually run

k3s-killall.sh

first, and then re-run the installer with the new k3s version desired. Should I go through each version instead? The cluster is ipv4 only and I checked from the k3s service logs (systemd) that only ipv4 CIDR ranges are passed as

--service-cluster-ip-range

or

--cluster-cidr

To give you a better overview, the node is behind a company proxy configured using the default

http_proxy/https_proxy

variables. Since the upgrade, it seems that all the networking operations are trying to resolve the proxy domain using ipv6 and that is failing. The workaround I found so far is to use the proxy IP directly instead of the domain, but I'm not sure it won't change in the future and I didn't have this issue before the upgrade, although I was using the same proxy.

I can’t say I’ve ever seen the outcome you’re describing due to skipping minors though.

This is

ip addr

from a random nginx pod in the cluster (sorry for the screenshot but I can't copy/paste on this node)

This is all client behavior and not controlled by Kubernetes, but normally it will resolve both A and AAAA and then use whichever ones are appropriate for the available address families.

> This is all client behavior and not controlled by Kubernetes I see the same behaviour also for Kubernetes operations like image pulling though.

You said it wasn’t affecting things that run on the node itself?

You're right, I was considering containerd as part of kubernetes itself but I get your point here. I confirm though that it doesn't happen on the OS, outside of containerd. The same commands I tested, such as

curl

or

ping

would fail in the pods but not on the node itself, and I get the same dns lookup errors in containerd when pulling images