kubeadm should warn about missing podSubnet/clusterCIDR

[NeilW]

BUG REPORT

Versions

kubeadm version (use kubeadm version):
kubeadm version: &version.Info{Major:"1", Minor:"11", GitVersion:"v1.11.0", GitCommit:"91e7b4fd31fcd3d5f436da26c980becec37ceefe", GitTreeState:"clean", BuildDate:"2018-06-27T20:14:41Z", GoVersion:"go1.10.2", Compiler:"gc", Platform:"linux/amd64"}
Environment:

• Kubernetes version (use kubectl version):
  Client Version: version.Info{Major:"1", Minor:"11", GitVersion:"v1.11.0", GitCommit:"91e7b4fd31fcd3d5f436da26c980becec37ceefe", GitTreeState:"clean", BuildDate:"2018-06-27T20:17:28Z", GoVersion:"go1.10.2", Compiler:"gc", Platform:"linux/amd64"}
  Server Version: version.Info{Major:"1", Minor:"11", GitVersion:"v1.11.0", GitCommit:"91e7b4fd31fcd3d5f436da26c980becec37ceefe", GitTreeState:"clean", BuildDate:"2018-06-27T20:08:34Z", GoVersion:"go1.10.2", Compiler:"gc", Platform:"linux/amd64"}
• Cloud provider or hardware configuration:
  brightbox
• OS (e.g. from /etc/os-release):
  Ubuntu 18.04 LTS
• Kernel (e.g. uname -a):
  Linux srv-jlhyq 4.15.0-23-generic Updating kubeadm manifests #25-Ubuntu SMP Wed May 23 18:02:16 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
• Others:

What happened?

Without a pod subnet specified, or a specific clusterCIDR specified you get:

W0720 13:06:36.713799       1 proxier.go:311] clusterCIDR not specified, unable to distinguish between internal and external traffic

from kube-proxy and masquerade facilities will be affected

What you expected to happen?

The clusterCIDR should be given to kube-proxy, or a warning issued during init

Given the number of CNI plugins that require a subnet specification there should be at least a warning from kubeadm about the impact of failing to tell the system what addresses the pods will be using.

How to reproduce it (as minimally and precisely as possible)?

kubeadm init without a podSubnet

Anything else we need to know?

There appears to be a bit of a battle going on between the top down allocation of system's addresses and the bottom up discovery of the system's addresses, with bits of each leaking into the instructions. Perhaps a pre-flight check is required to ensure consistency.

[stealthybox]

I agree this check is necessary.
It's very easy to produce unworkable configurations.

[xlgao-zju]

/assign
I'd like to take this issue. We just print a warning or fail the init, when the podSubnet/serviceSubnet is missing?

[stealthybox]

bump @xlgao-zju -- are you still working on this? :)
cheers!

[xlgao-zju]

@stealthybox Sorry for the delay. I had some personal stuff... I will fix this issue ASAP.
And as I asked should we just print a warning or fail the init, when the podSubnet/serviceSubnet is missing? WDYT?
cc @neolit123

[neolit123]

@xlgao-zju
i haven't looked at this. possibly @NeilW or @stealthybox can provide the right details required by the good first issue label - e.g. what has to be changed and where.

[neolit123]

/lifecycle active

[NeilW]

Given it produces unworkable configs, I would fail the init if it is not specified.

[stealthybox]

@NeilW, do you know if this is true with previous versions of kubernetes/kubeadm?

[stealthybox]

commented on PR: kubernetes/kubernetes#68682 (comment)

[NeilW]

I don't I'm afraid. I've only used this on the 1.11 cycle

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[neolit123]

/lifecycle frozen

[rosti]

I think, that this issue and the possible solutions to it should be discussed at some of the next kubeadm office hours meetings.

[ericsgagnon]

still an issue on v1.13. Upgrading from v1.12 to v1.13 using the kubeadm upgrade guide wiped my pod subnet and restarted all my pods in a cidr outside my weave subnet in an intranet with collisions.

[rajibmitra]

I would like to work on this if its still pending , please let me know.

[neolit123]

@rajibmitra this PR was already sent, but we didn't decide on how to handle this check properly:
kubernetes/kubernetes#68682

[astrieanna]

/remove-help

because the way to handle the check still hasn't been decided (or hasn't been documented on this issue).

[timothysc]

@astrieanna - unless you are actively engaging with the subproject on helping to triage the backlog with that team I'm going to politely ask you to stop. Contribex are guidelines, not policy. help wanted is used to indicate to external contributors that we are not actively working on it, and if they are interested they may need to investigate to find an optimal path and work with the team.

[neolit123]

The clusterCIDR should be given to kube-proxy, or a warning issued during init

Given the number of CNI plugins that require a subnet specification there should be at least a warning from kubeadm about the impact of failing to tell the system what addresses the pods will be using.

we actually closed the only attempt to add a warning for this as the implementation was not very clean and there was no consensus.

overall an explicit podSubnet is not mandatory for CNI as a whole, but some plugins just require it.

if a plugin requires it, it is outlined both in ours and their docs, thus it becomes an operator mistake if the CIDR is not passed.

given the CNI plugin step is outside of kubeadm, a warning about not having a podSubnet value different from the default is not something we want to show.

i'm going to close this ticket as part of triage but also would like to note that i have not seen any recent triage/support reports where users miss passing the CNI required CIDR.