Azure CNI Support about gardener-extension-provider-azure HOT 6 CLOSED

Why would we do that? And what's with network policies? We would have to keep Calico, still. And what with homogenous clusters? We can't support special solutions for the various infrastructures until extensibility is done and the community helps with this as well.

from gardener-extension-provider-azure.

In the meantime we have confirmed the network performance. Pod-to-pod communication is almost as fast as node-to-node communication and matches the max/peak performance for the machine type/class. So there is not much if anything to be gained. In addition we noticed the low default of only 30 pods per node with Azure CNI. Don't know why, but this too looks like a step back. Are there and serious/good reasons? What are the benefits, please, so that we can make an informed decision @marwinski?

from gardener-extension-provider-azure.

We are currently facing unknown network issues on Azure, meaning we cannot yet pinpoint the root cause. Anyway we (meaning @vasu1124 and myself) are looking for sponsored projects where Azure CNI is actually required. I consider this to be a good reason.
Anyhow Azure CNI would undoubtedly break some of our homogeneity, true and not nice so might remain a research project.

from gardener-extension-provider-azure.

We decided that the cluster networking part will also be covered with extensibility, i.e. the extension controllers will be responsible for which CNI plugin will be deployed. First, Azure will deploy calico as of today, but it's way easier to change it in the future without breaking/influencing the others.

from gardener-extension-provider-azure.

@marwinski The plan as of today was to go and switch from the free basic to the standard Azure LBs with proper SLAs. There are multiple good reasons for that according to @dkistner anyway (see https://github.com/gardener/gardener/issues/243#issuecomment-483417334) and so @zanetworker offered to do that next. As for Azure CNI, we can't expect performance improvements as the performance team was pretty happy with the current performance (close to theoretical max) and there was the 30 pods limitation we have not investigated and maybe more topics. I agree that if we cannot pinpoint the problem (after we have also explored the LB option), that desperate measures like switching to Azure CNI may be valid. For now however, while we still have other and simpler options, I would say let's explore those first before we switch one bag of issues/can of worms with another.

from gardener-extension-provider-azure.

I consider LBs a very different topic. I have little opinion on this but it is probably a good idea to switch. As for the networking issues we are digging into this for 7 days already with little hope to find anything soon (test landscape broken due to Azure issues (200 - internal error, disk attach failures again), problem happening only sporadically). Looking back - Azure CNI would probably have been easier to evaluate.

from gardener-extension-provider-azure.