Revert "Revert "Add support for running GCI on the GCE cloud provider""

[andyzheng0831]

This is for resubmitting the PR #25425, which was reverted due to breakage in GKE cluster intialization. The root cause is that /etc/gce.conf is incorrectly deleted. Compared with the previous PR, this one corrects the logic.

Test: (1) spin up a k8s cluster and gke cluster and verify kube-system pods all running. (2) Run e2e tests on k8s cluster and gke cluster.

One thing confusing me: two test fail in gke but all pass in oss k8s cluster.

• Services [It] should be able to create a functioning NodePort service
• KubeProxy [It] should test kube-proxy [Slow]

The second test case is more strange as the kubeproxy is running on ContainerVM-based node.

@roberthbailey do you know any potential reason for the different result in gke and k8s? For GKE e2e tests, I follow the instruction https://g3doc.corp.google.com/cloud/kubernetes/g3doc/dev/testing.md?cl=head#running-e2es-against-a-gke-cluster. I am not sure if I missed any configuration which led to the failures.

[andyzheng0831]

@k8s-bot unit test this issue #25539

[andyzheng0831]

@cjcullen told me the failed test cases may be caused by incorrect firewall. My cluster was created using gcloud containers command, instead of jenkins tests. After manually adding the needed firewall rules, the failed test cases all can pass.

It means that this PR can pass both k8s and GKE e2e tests.

[andyzheng0831]

@k8s-bot unit test this issue #25539

[roberthbailey]

@david-mcmahon -- the original PR had a release note but was reverted. Will it's release note show up in the next release or should this PR have a release note attached?

[andyzheng0831]

I just updated the PR by splitting it into two commits. One is for reverting the previous reversion of #25425 . Another is for fixing the issue in PR #25425

[roberthbailey]

Marking as e2e-not-required since the merge bot tests won't actually test this code (so there's no point in wasting cycles).

[roberthbailey]

lgtm

[david-mcmahon]

@roberthbailey Each PR has its own independent release note state and text.

In the case of an original, a revert and a revert-revert, I'd recommend release-note-none on the first two and some release-note label on the last one with an updated title (or release-note block). You could just leave the release note label on the first PR and add release-note-none to the last two, but ideally you'd want to use the last PR in the chain because it has all the history (for better accounting).

[andyzheng0831]

I will remove the commit "GCI: add support for CIDR allocator for NodeController" from this PR, as the original PR will be reverted shortly.

[andyzheng0831]

PR #25997 was abandoned. I add the support for CIDR allocator for NodeController back. The PR is ready

[andyzheng0831]

@roberthbailey I verified the PR in GKE cluster creation and kube-system pods. Also ran most e2e test cases in GCE and GKE. Please merge it and then let's monitor the gke CI jenkins.

[k8s-bot]

GCE e2e build/test passed for commit 6bb0a25.

• Build Log
• Test Artifacts
• Internal Jenkins Results

[roberthbailey]

@k8s-bot unit test this issue: #25967