search

sighupio / fury-kubernetes-networking

Kubernetes Fury Distribution Networking Core Module: CNI and Network management features for Kubernetes Clusters
BSD 3-Clause "New" or "Revised" License
9 stars 3 forks source link

eks-policy-only Installation crd doesn't specify the image of the subresources that the operator will create #54

Closed lzecca78 closed 1 year ago

lzecca78 commented 1 year ago

Hi everyone 👋 , during a cluster setup with the dear @FedericoAntoniazzi , because of some corner cases that we've hit, we have found out that the workloads created by the Installation crds, have images belonging to docker.io instead of the sighup registry: This is an example, but can be applied to all resources created by the tigera operator when an Installation crd is declared:

  Warning  Failed     5m36s (x4 over 7m9s)   kubelet            Failed to pull image "docker.io/calico/kube-controllers:v3.24.1": rpc error: code = Unknown desc = Error response from daemon: toomanyrequests: You have reached your pull rate limit. You may increase the limit by authenticating and upgrading: https://www.docker.com/increase-rate-limit

As far as I saw, there is a crd ImageSet that could be useful for this purpose . I just want to track this in order to solve this issue later.

ralgozino commented 1 year ago

I'm 100% sure that the on-prem variant replaces the registry properly.

Most probably we missed adding something like what we do for on-prem:

https://github.com/sighupio/fury-kubernetes-networking/blob/f9592126bb1d887888f08d03d055f244ba2600d2/katalog/tigera/on-prem/custom-resources.yaml#L13-L15

nutellinoit commented 1 year ago

I was writing the same @ralgozino said

lzecca78 commented 1 year ago

thanks to both, I've opened the PR anyway for fixing the eks-policy-only 👍

ralgozino commented 1 year ago

fixed by #55