0.12 release: remove legacy networking (less is more) #1451
Conversation
k8s-ci-robot
added
size/XXL
|
I've run a couple of manual tests - 1st upgrading my 0.10.x cluster to this release with canal networking and then an update where I change the networking to 'flannel' and both worked successfully. This change requires that the legacy 'useCalico' setting be removed from cluster.yaml. |
Codecov Report
@@ Coverage Diff @@
## master #1451 +/- ##
==========================================
- Coverage 38.26% 38.13% -0.14%
==========================================
Files 74 74
Lines 4565 4555 -10
==========================================
- Hits 1747 1737 -10
Misses 2576 2576
Partials 242 242
Continue to review full report at Codecov.
|
core/controlplane/config/config.go
Outdated
| if c.Kubernetes.Networking.SelfHosting.Typha && c.Kubernetes.Networking.SelfHosting.Type != "canal" { | ||
| return fmt.Errorf("networkingdaemonsets - you can only enable typha when deploying type 'canal'") | ||
| } | ||
| if (c.Kubernetes.Networking.SelfHosting.Type != "canal") && (c.Kubernetes.Networking.SelfHosting.Type != "flannel") { |
There was a problem hiding this comment.
Bit of a picky comment, but can we keep if statement style consistent.
if (c.Kubernetes.Networking.SelfHosting.Type != "canal") && (c.Kubernetes.Networking.SelfHosting.Type != "flannel"){ can be replaced by
if c.Kubernetes.Networking.SelfHosting.Type != "canal" && c.Kubernetes.Networking.SelfHosting.Type != "flannel" right?
There was a problem hiding this comment.
Sure - that makes sense, have updated!
| networking: | ||
| selfHosting: | ||
| enabled: true # false will fall back to legacy coreos flannel/etcd2 installation | ||
| type: canal # either "canal" or "flannel" | ||
| typha: false # enable for type 'canal' for 50+ node clusters |
There was a problem hiding this comment.
Do we have any reasons not to enable typha by default btw?
There was a problem hiding this comment.
Typha is only needed on larger clusters with 50+ nodes.
There was a problem hiding this comment.
Would the purpose of avoiding it when unnecessary is to reduce num of moving parts?
I just wondered if it would be a good idea to enable it by default if it doesn't have any bad side-effect, so that users won't suffer from degraded performance after reaching 50+ nodes
There was a problem hiding this comment.
I'm a little worried about trying to set it automatically because that would mean I would have to count the nodes in the nodepools and make allowances for possible cluster auto-scaling. With it off by default, a cluster admin with a growing cluster and seeing high loads on their apiservers will hopefully have had some time to start getting acquainted with the cluster.yaml file and settings.
There was a problem hiding this comment.
Makes sense. Thanks a lot for clarifying!
…1451) The 0.11 release completed the migration from legacy flannel and calico networking to the newer Self Hosting 'canal' or 'flannel' networking daemonsets. This change is clean up all of the **old code** for that supports the legacy flannel and calico installation and which enabled the migration from legacy to the network daemonsets and makes self-hosting always enabled. The worker nodes no longer have to have any knowledge/access to the etcd servers as SelfHosting uses the kubernetes api for storage. This simplifies kube-aws, which is always nice! :)
The 0.11 release completed the migration from legacy flannel and calico networking to the newer Self Hosting 'canal' or 'flannel' networking daemonsets.
This change is clean up all of the old code for that supports the legacy flannel and calico installation and which enabled the migration from legacy to the network daemonsets and makes self-hosting always enabled. The worker nodes no longer have to have any knowledge/access to the etcd servers as SelfHosting uses the kubernetes api for storage.
This simplifies kube-aws, which is always nice! :)