agent, defaults: enable remote node identity by default

[tklauser]

We already set enable-remote-node-identity: true in the Helm charts [1] since it was introduced for Cilium 1.7, see commit 0b27e79 ("helm: Enable remote-node identity for all new deployments by default").

Update the default value for the agent flag as well, so it is reflected in the flag usage.

[1]

cilium/install/kubernetes/cilium/values.yaml

Lines 1726 to 1728 in 95e0919

	# -- Enable use of the remote node identity.
	# ref: https://docs.cilium.io/en/v1.7/install/upgrade/#configmap-remote-node-identity
	remoteNodeIdentity: true

Remote node identities are enabled by default in the Cilium agent. They have already been enabled by default in the Helm charts since Cilium version 1.7.

[tklauser]

/test

Job 'Cilium-PR-K8s-1.26-kernel-net-next' failed:

Click to show.

Test Name

K8sDatapathConfig Host firewall With VXLAN and endpoint routes

Failure Output

FAIL: Failed to reach 192.168.56.12:80 from testclient-9hkwx

Jenkins URL: https://jenkins.cilium.io/job/Cilium-PR-K8s-1.26-kernel-net-next/1812/

If it is a flake and a GitHub issue doesn't already exist to track it, comment /mlh new-flake Cilium-PR-K8s-1.26-kernel-net-next so I can create one.

[tklauser]

/test-runtime

#23997 https://jenkins.cilium.io/job/Cilium-PR-Runtime-net-next/6059/

[tklauser]

/test-1.26-net-next

#15455 https://jenkins.cilium.io/job/Cilium-PR-K8s-1.26-kernel-net-next/1812/

[pippolo84]

🚀

[joestringer]

This should probably be release-noted as well, just in case it causes some upgrade headache for someone. I think that historically we have tried to keep the cilium-agent defaults the same without changing in order to attempt to allow users to avoid configuring every new setting whenever they upgrade to the newer Helm charts. That's partly what the upgradeCompatibility flag stuff is about. I don't think the implementation for that upgradeCompatibility flag is really the best option, we should probably just set the expectation that upon upgrade users need to set options to retain compatibility during upgrade... but that's a whole other topic. The least we can do is make sure that the upgrade guide documents all changing defaults.

[tklauser]

This should probably be release-noted as well, just in case it causes some upgrade headache for someone. I think that historically we have tried to keep the cilium-agent defaults the same without changing in order to attempt to allow users to avoid configuring every new setting whenever they upgrade to the newer Helm charts. That's partly what the upgradeCompatibility flag stuff is about. I don't think the implementation for that upgradeCompatibility flag is really the best option, we should probably just set the expectation that upon upgrade users need to set options to retain compatibility during upgrade... but that's a whole other topic. The least we can do is make sure that the upgrade guide documents all changing defaults.

Thanks for providing that context. I've added a release note to this PR's description.