helm chart: upgrade with the same value (ipFamilyPolicy=RequireDualStack) not possible #11068
Comments
|
This issue is currently awaiting triage. If Ingress contributors determines this is a relevant issue, they will accept it by applying the The Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
k8s-ci-robot
added
needs-triage
This hints that a very clear targeted test is needed to be done by a developer to triage this |
|
/remove-kind bug cc @Gacko |
k8s-ci-robot
added
triage/needs-information
|
That's not AWS, that's Oracle Cloud. I cannot test this, but I rather feel like that's an error produced by the according load balancer / cloud controller, so nothing caused by the chart or us. |
|
Yup, that error is coming from Kubernetes itself: https://github.com/kubernetes/kubernetes/blob/dc3f5ec6ccb9855dfa99f4c1078625df5fdfab6a/pkg/registry/core/service/storage/alloc.go#L184 |
|
To make things clear, I do not use oracle load balancers but metallb ^^ |
|
According to the code, this error message happens when you're handing in an |
|
What's the deal then if the error comes from Kubernetes? Shouldn't the helm template render exactly the same values for the yaml files that get send to the kubernetes api? In this case, kubernetes shouldn't do anything but rather reply with "ok", desired state already reached. To verify, I dumped the current service as a yaml file and tried to push it straight as it is again with "kubectl apply -f": Does the nginx helm-chart admission controller permanently update the resource? Because I needed maybe 5 seconds between getting the yaml output and sending it again. Or is it a missing kubernetes feature/bug? If yes, I can close this issue and raise one on kubernetes side :) |
|
The |
|
Thanks! I will try to ask why this behaviour is desired on the kubernetes side :) |
|
@Gacko I will reopen this issue, as I am pretty sure, that the error message is misleading, because I ran helm with # Source: ingress-nginx/templates/controller-service.yaml
apiVersion: v1
kind: Service
metadata:
labels:
helm.sh/chart: ingress-nginx-4.10.0
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/instance: ingress-nginx
app.kubernetes.io/version: "1.10.0"
app.kubernetes.io/part-of: ingress-nginx
app.kubernetes.io/managed-by: Helm
app.kubernetes.io/component: controller
name: ingress-nginx-controller
namespace: ingress-nginx
spec:
type: LoadBalancer
ipFamilyPolicy: RequireDualStack
ipFamilies:
- IPv4
ports:
(...)The problem might be, that the |
|
The check in the code compares the old The Ingress NGINX chart has a property Unfortunately Kubernetes is maybe not complaining about that on creation and just adds Sorry that I didn't figure that earlier! I guess you're expecting to just set Of course setting So in the end I don't think there is a one-fits-all default behavior we can implement and one always needs to configure both, cc @strongjz @rikatz in case you are more into the whole "Kubernetes on Dual Stack" topic. 🙂 |
|
Just tested it. Indeed, setting the ipFamilies resolves my problem. I guess there is no need to catch this edge case, since it was a user error. But at least it is now documented here in an issue so others can find it 😄 Thanks a lot for your help! |
avoid kubernetes/ingress-nginx#11068 the chart implicitly assumes IPv4 only, even when RequireDualStack
avoid kubernetes/ingress-nginx#11068 the chart implicitly assumes IPv4 only, even when RequireDualStack
What happened:
Tried to upgrade a helm-installation with the exact same values used during installation. Reproduced this with a new cluster and installation:
What you expected to happen:
The upgrade should do nothing, but just work.
One might wonder, why I want to do this: The command is part of an idempotent script that should always define the desired end status.
NGINX Ingress controller version (exec into the pod and run nginx-ingress-controller --version.):
Kubernetes version (use
kubectl version):Environment:
Oracle cloud ARM server, 4 cores 24GB RAM
uname -a):Please mention how/where was the cluster created like kubeadm/kops/minikube/kind etc.kubeadm
kubectl versionsee above
kubectl get nodes -o widehelm ls -A | grep -i ingresshelm -n <ingresscontrollernamespace> get values <helmreleasename>N/A
N/A
kubectl describe ingressclasseskubectl -n <ingresscontrollernamespace> get all -A -o widekubectl -n <ingresscontrollernamespace> describe po <ingresscontrollerpodname>kubectl -n <ingresscontrollernamespace> describe svc <ingresscontrollerservicename>kubectl -n <appnamespace> get all,ing -o wideN/A
kubectl -n <appnamespace> describe ing <ingressname>N/A
N/A
kubectl describe ...of any custom configmap(s) created and in useN/A
How to reproduce this issue:
Already described above :)
Anything else we need to know:
It might be also some misunderstanding on my side. Anyhow, I wasn't able to find anything similar in the issues here, so at least if someone else stumbles on this in the future, it might be helpful :)
The text was updated successfully, but these errors were encountered: